Check your interpretation before a second scan
| Illustrative observation | Supported statement | Still unresolved |
|---|---|---|
| 22/tcp open, service label ssh; no -sV used | The scan reported an open TCP port 22 from this scanner. | The label may come from the port database; the actual application and build need evidence. |
| 443/tcp filtered | Nmap could not determine open versus closed under these conditions. | Which device or rule filtered traffic, and whether the application exists. |
| 80/tcp closed | The probe received a response consistent with a closed TCP port. | Whether the state changes later or differs from another authorized vantage point. |
| No response during discovery | This discovery attempt did not identify a responding host. | Whether the VM is powered off, misaddressed, filtered or on another segment. |
Practice answer: “This limited TCP run reported port 22 open. I have not identified the software build, assessed UDP or established a vulnerability.” Compare that with “SSH is vulnerable”: the latter needs evidence this output does not supply.
Before rerunning, retain the original file and write the one question the next command will answer. If comparing results, hold the target, vantage point and port set constant unless one of those is the intended variable. Use the recon entry generator to keep both attempts distinct.
Documentation: Nmap states and their observation limits. This proposed procedure has not been independently run in a VM for this update.
Choose the next check from what remains unknown
After a first result, write one unresolved question. A name inferred from a port number is not the same observation as a response to a version probe. Keep the exact command and selected transport with the output before deciding whether a further permitted check is useful. Use the Kioptrix workflow below for staged collection; do not treat a first TCP sample as coverage of UDP or all ports. Source and scope.
For a first Nmap scan in Kali Linux, use one confirmed lab address, a limited port selection and a saved output file. Then explain what the result shows—and what it leaves unknown—before adding more options.
This guide covers authorized lab practice. The example address below is illustrative, not an invitation to scan that address on your own network. Replace it only after identifying your actual lab target. No personal scanning history, measured speed improvement or certification outcome is claimed.
Start with one question and one authorized target
Choose a question small enough to answer: “Which commonly scanned TCP ports respond on this lab VM from my Kali guest?” That is different from asking whether the whole machine is secure.
Before opening the terminal, record the target address, who controls it, the permitted activity and a place to save results. A private-looking IP address can belong to your router, another guest or a work device. Identify the VM from its console and network configuration rather than assuming an address is yours.
Lesson 1 – Separate the lab from everyday systems
Use a scanner guest and one disposable target guest. Keep personal files and credentials out of the vulnerable target, and confirm how to restore it. A snapshot helps recovery; it does not prevent network exposure.
Oracle’s VirtualBox networking guide distinguishes internal networking from host-only networking: internal networking connects selected guests, while host-only also connects the host. NAT allows outbound connections; bridged networking attaches a guest to the physical network. A mode’s name alone does not verify your whole setup.
Inspect every enabled adapter and any routing or forwarding path. An isolated adapter does not undo exposure through a second adapter. Separate an update workflow from the vulnerable lab, and verify the boundary again after changing settings.
If using a Kioptrix target, the Kioptrix beginner lab guide explains release compatibility, isolation and a first practice path. A hosted provider’s rules and target scope need separate review.
Lesson 2 – Distinguish hosts, ports and services
A host is an addressed system. A port is a numbered endpoint for a transport protocol. A service is the application responding there. A familiar port number suggests a convention, not proof of which application or version is running.
The official port-state guide explains that states describe what Nmap observes from its current position. A firewall or a different scan vantage point can change the result.
- open: a service is accepting the relevant communication. This does not establish a vulnerability.
- closed: the port is reachable, but no application is listening there.
- filtered: filtering prevents Nmap from deciding whether the port is open.
- open|filtered: Nmap cannot distinguish those two possibilities for that scan.
Keep the protocol with the number: 53/tcp and 53/udp are different observations. This introductory workflow does not assess UDP services.
Lesson 3 – Run a limited scan and save the result
Once the target and boundary are confirmed, the following is a suggested first exercise. It is not a scan performed for this article.
nmap -F -oN first-scan.txt 192.168.56.101-F selects a smaller port set. With the usual frequency data, it scans 100 commonly used ports rather than the usual 1,000; custom service data can change that selection. See Nmap’s port-selection documentation. It does not mean “all ports,” “all services” or “guaranteed fast.”
-oN writes normal output to the named file, as described in the output reference. Use a new filename for a later run so you preserve the first observation; output files are overwritten by default.
Add service detection only for a reason
nmap -sV -p 22,80 -oN service-check.txt 192.168.56.101This example selects TCP ports 22 and 80; use ports relevant to your approved exercise rather than copying them blindly. -sV sends additional probes to identify services and versions. Consult the version-detection guide; a reported version still needs interpretation before any vulnerability claim.
Keep host discovery separate
nmap -sn 192.168.56.0/24Use this example only if the entire subnet is your approved lab scope. Nmap’s host-discovery documentation explains that -sn discovers responding hosts without a subsequent port scan. It does not enumerate their services, and missed responses do not establish that every unlisted address is unused.
Why default scripts are a separate decision
The NSE reference identifies -sC as the default script set and warns that some default scripts are intrusive. Review the selected scripts and permission before adding them. Do not use an unknown script bundle simply because a tutorial calls it a baseline.
Lesson 4 – Plan scope and timing without guessing
There is no reliable completion-time estimate from just hosts × ports ÷ an assumed probe rate. Discovery, retransmissions, response delays, filtering, version probes and scripts add different work. The earlier arithmetic widget has been removed because its result could be mistaken for a scan-duration or load guarantee.
Start with a small approved run, record its elapsed time and options, and use that observation to plan the next exercise. A different target or network may behave differently. Nmap’s timing reference explains why aggressive rate settings can reduce accuracy or create more retransmissions.
These checks are a reminder, not a safety certificate or readiness score. They do not run a scan or transmit the checklist anywhere.
Lesson 5 – Read findings without claiming a vulnerability
Illustrative output, not a result collected for this article:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp filtered httpsWrite an observation first: “From this scanner, port 22 was reported open.” Then write the unanswered question: “Is that the service intended by the lab configuration?” Do not jump from a port label to a claim of weak authentication, a specific software version or exploitability.
If results are unexpected, check the target address, VM state, adapter assignment and recorded options before increasing scan scope. Preserve the original output so you can explain a later difference.
Lesson 6 – Keep a repeatable record
- Scope: record the approved target and the question.
- Run: save the exact command, tool version, date and vantage point.
- Interpret: separate observed states from service guesses and untested risks.
- Follow up: choose one permitted check that addresses a remaining question.
- Review: save the next run separately and explain what changed.
A useful note might read: “Limited TCP scan of my isolated target; two open ports observed. Other TCP ports and UDP were not assessed. Next step: inspect an expected web service within the lab scope.” This is a hypothetical note, not a finding about a real host.
Lesson 7 – Confirm permission and stopping conditions
Permission to use a network is not automatically permission to scan every device on it. For a shared, employer, campus or hosted environment, confirm the target list, allowed techniques, timing, contact and stopping conditions before scanning. Legal and contractual requirements depend on the actual situation; this tutorial does not provide a blanket legal conclusion.
Stop if you discover that a target is outside scope, see disruption or cannot explain where traffic is going. Keep logs and ask the responsible owner to clarify before continuing. A local lab reduces some risks, but “nothing bad can happen” is not a guarantee.
A Flexible Seven-Session Practice Plan
These are optional sessions, not seven mandatory days or promised completion times. Repeat or shorten a session as needed.
- Identify one target, check compatibility and draw the network boundary.
- Confirm adapters and target address; write the scan question.
- Run a limited authorized scan and save the output.
- Explain each reported state and list what was not assessed.
- Review service detection and decide whether a targeted follow-up is useful.
- Use discovery only within an approved range; compare it with a port scan.
- Write a short summary, including uncertainty and the next permitted task.
Seven Checks to Keep Beside Your Terminal
- Identify the actual target.
- Confirm scope and permission.
- Inspect the network boundary.
- Understand each selected option.
- Preserve output and context.
- Separate observations from conclusions.
- Choose one justified follow-up.
Common First-Scan Questions
Why does a scan say the host seems down?
Check the address, whether the guest is running and its network attachment. Discovery responses can be filtered. Do not treat this message as proof that no system exists, or automatically expand the scan to other addresses.
Does an open port mean the host is insecure?
No. It is an observation about a responding endpoint. Whether that service is intended, appropriately configured or vulnerable requires additional authorized evidence.
Do I need every option in one command?
No. Use the options required for your current question. Keep service detection, scripts and wider target ranges as separate decisions you can explain.
How long will the scan take?
There is no universal duration. Measure a small approved run and record its conditions. A simple arithmetic estimate cannot account for the target’s responses or all enabled scan features.
Can I use the example address unchanged?
Only if you independently confirm that it is your authorized target. An address appearing in a tutorial does not grant permission or make the device disposable.
Is a lab completely safe?
No. Check isolation, every adapter and recovery arrangements. Avoid sensitive data in vulnerable guests and follow the platform’s rules.
Your Next Practice Task
Identify one authorized lab host, write a narrow question and choose a limited command you understand. Save the output and explain the result before adding options.
Reviewed October 16, 2026. This revision checked command meanings and network-mode distinctions against the linked Nmap and Oracle documentation. Examples and sample output are illustrative; no live target was scanned for this review. Existing images are retained as illustrations, not evidence of a personal test or exam result.