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.

Port ScannerNetworkCLI

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

Beginner

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.1

Perform 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.

Intermediate

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/24

Use 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.

Advanced

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.10

Create 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