Build a four-part isolated lab
A useful beginner lab has four parts: the host computer, a hypervisor such as VirtualBox, an analyst machine such as Kali Linux and a deliberately vulnerable target created for training. The analyst and target communicate on an isolated virtual network. The host keeps the lab controlled and stores notes and snapshots.
- Confirm that the host has enough memory and disk space for two virtual machines.
- Download operating-system images only from the publisher's official site and verify checksums when provided.
- Create the analyst VM and update it before isolating the lab.
- Create or import the training target from its official project source.
- Place both VMs on the same host-only or internal network.
- Take clean snapshots before testing.
- Record the lab subnet, VM names and purpose in a scope note.
Rapid7 describes Metasploitable3 as a VM built with vulnerabilities for training. That is precisely why it must remain isolated and must never be bridged casually onto an organisation's normal network.
Choose the virtual network mode deliberately
| Mode | Typical reach | Beginner use |
|---|---|---|
| NAT | VM can usually reach outward through the host | Useful for controlled updates, then disconnect the vulnerable target |
| Host-only | Host and selected VMs communicate without normal external routing | Good default for a two-VM practice lab |
| Internal network | Only VMs on the named internal segment communicate | Strong isolation when host access is not required |
| Bridged | VM appears on the physical network | Avoid for deliberately vulnerable targets |
Do not assume the label alone guarantees isolation. After configuration, test routing from each VM. The target should not have an unintended route to production or the internet. If temporary internet access is needed for an update, remove it immediately afterward and take a fresh snapshot.
Collect a baseline before scanning
On the analyst VM, record identity, address and route information. On Linux, these read-only commands help establish context:
whoami
pwd
ip -br addr
ip route
ip neighOn the target, a local socket command such as ss -tulpen can show listening services. Availability and required privileges vary by system. Save the output in your lab notes. This creates a local reference against which the scanner's external view can be compared.
Use neutral placeholders in reusable notes. Replace <LAB_SUBNET> and <LAB_TARGET_IP> only with addresses confirmed inside your authorised isolated lab. Never paste an unfamiliar public address into a training command.
Move from broad discovery to narrow evidence
Nmap's official reference guide documents target syntax, host discovery and scan options. Beginners should start with the smallest question that can answer the lab objective.
1. Discover hosts on the authorised lab subnet
nmap -sn <LAB_SUBNET>Compare the result with the VMs you expect to be running. A missing host may be asleep, blocked, misaddressed or on another virtual network. It is not proof that the system does not exist.
2. Test one expected TCP port
nmap -p 80 <LAB_TARGET_IP>This asks a narrow question: what state does the scanner observe for TCP port 80? The official Nmap guide explains six possible states: open, closed, filtered, unfiltered, open|filtered and closed|filtered. Open means an application is accepting connections; it does not mean the service is vulnerable.
3. Identify the service on a known open port
nmap -sV -p <KNOWN_OPEN_PORT> <LAB_TARGET_IP>Nmap's version detection documentation explains how probes can identify a service and possible version. Treat the output as evidence to validate, not a vulnerability verdict. Software may be backported, proxied, configured unusually or intentionally misleading.
| State | Practical interpretation |
|---|---|
| Open | An application is accepting a connection on the port |
| Closed | The host responded, but no application is listening there |
| Filtered | A network control prevents the scanner from deciding whether the port is open |
| Unfiltered | The port is reachable, but the selected scan cannot decide open versus closed |
| Open|filtered | The scan cannot distinguish open from filtered |
| Closed|filtered | The scan cannot distinguish closed from filtered |
Triangulate evidence with three views
A defensible lab conclusion compares three sources:
- Nmap: what an external analyst VM observes.
- Local socket state: what the target reports is listening.
- Wireshark: which packets were exchanged and how they were answered.
Suppose Nmap reports TCP port 80 open, the target's socket list shows a process listening on port 80, and Wireshark shows the expected connection exchange. These observations support the conclusion that a service is reachable in the lab. They still do not establish a vulnerability. If the three views disagree, investigate address selection, firewalls, protocol choice, scan timing, service binding and virtual network configuration.
Use the Wireshark for Beginners guide to capture on the correct interface, apply display filters and record packet-level evidence without altering the original capture.
Write a finding that separates fact from inference
A beginner report should be short enough to review and precise enough to repeat.
| Field | Example |
|---|---|
| Scope | Named analyst VM, target VM and isolated lab subnet |
| Question | Is the expected web service reachable from the analyst VM? |
| Method | Narrow TCP port check, local socket comparison and packet observation |
| Observation | Scanner reported open; target reported a listener; packets showed a completed exchange |
| Conclusion | The service was reachable during the test window |
| Limit | No vulnerability or production exposure was established |
Avoid inflated phrases such as "system compromised" when you only observed a listening port. A strong report states what was tested, what was seen, what it means and what it does not prove.
Safe troubleshooting
| Problem | Check first |
|---|---|
| VMs cannot reach each other | Confirm both use the same named virtual network and correct subnet |
| Target address changes | Recheck ip -br addr and document the new lab address |
| Nmap reports filtered | Inspect firewall rules and packets before changing scan intensity |
| Service expected but closed | Confirm the process is running and bound to the correct interface |
| Capture shows no traffic | Select the interface that carries the isolated-lab packets |
Do not respond to uncertainty by running broad aggressive options. Narrow the question, verify the route and inspect the evidence. This habit is more valuable than memorising switches.
Frequently asked questions
Is an open port proof of a vulnerability?
No. It proves only that an application accepted a connection during the observation. Vulnerability claims need separate authorised evidence.
Which network mode is safest for a vulnerable target?
Host-only or internal networking is normally safer. Verify the resulting routes and never bridge a deliberately vulnerable target onto production.
May I scan a public IP for practice?
No. Use only your own isolated lab or a system for which you have explicit permission and a defined scope.
Why compare three tools?
Nmap, local socket tools and Wireshark provide different views. Comparing them reduces guesswork and teaches evidence-based analysis.