Practical documentation · Authorized use only
Nmap
Nmap is a flexible network discovery and service-inventory tool. Its value is disciplined scope, explicit scan intent, carefully chosen timing, structured output, and human interpretation—not a single aggressive command copied from the Internet.
Start safely and get useful results
Best for
- • Authorized host and service inventory
- • Change validation and exposure review
Not for
- • Unapproved scanning
- • Treating version detection as exploit confirmation
Before you run anything
- • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
- • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.
Practical workflows
Inventory known ports on one approved host
Scenario: Validate a local training VM after a firewall change.
nmap -sT -sV -p 22,80,443 -oA nmap-localhost 127.0.0.1Perform TCP connect and service detection on explicit ports, saving normal, XML, and grepable evidence.
Expected use: Expect port state and service hypotheses; compare them with the authorized service inventory.
Perform a bounded subnet inventory
Scenario: An approved test VLAN needs a low-impact TCP exposure baseline.
nmap -sT -T3 --top-ports 100 -oA nmap-vlan 192.0.2.0/24Use moderate timing and a limited top-port set on the documented test subnet.
Expected use: Expect host and port observations; investigate differences with network owners before escalating.
Use XML as a repeatable evidence format
Scenario: Feed an approved inventory into a reporting workflow without parsing terminal text.
nmap -sT -sV -oX nmap.xml 192.0.2.10Create structured XML for a single scoped host, retaining the exact command and version.
Expected use: Schema-friendly data supports comparison, but still requires review for false positives and transient state.
Interpret results like an analyst
- • filtered commonly means a packet was blocked or dropped, not that the port is closed.
- • Service/version evidence must be confirmed with authenticated inventory or owner input before vulnerability correlation.
Common mistakes and operating tips
Avoid
- • Using -A or high timing templates without considering impact and authorization.
- • Assuming -Pn makes a host reachable; it only skips host discovery.
Operational discipline
- • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
- • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.
Verify against the current upstream
Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.
Open authoritative upstream documentation