hack3rs.ca network-security

/learning/tools/nmap :: tool-guide-2

defender@hack3rs:~/learning/tools$ open nmap

Nmap

Discovery & audit

Nmap is the nmap network scanner defenders reach for when they need to know what a network is actually exposing. Use it to find hosts, audit open ports, validate firewall rules, and catch exposure drift before someone else does.

how-to-learn-this-tool-like-a-defender

Work through the stages in order. Each one builds on the previous. Skipping straight to 'run a command' without knowing what the output means is how analysts end up misreading evidence under pressure.

$Name the specific question this tool answers — and one question it cannot answer alone.
$Run the simplest command in a lab against a host you control; read every field in the output before moving on.
$Identify which output fields are direct evidence and which are inferences the tool made on your behalf.
$Pull a second source — a log, a PCAP, a SIEM event — that either confirms or contradicts what the tool reported.
$Write down the exact command you ran, what you expected, what you got, and what you are doing next.

preflight-checklist-before-using-tool

$Confirm in writing: who authorized this, what hosts are in scope, and what the maximum acceptable impact is.
$State the question you are trying to answer — not 'run the tool' but 'confirm whether port 443 is open on 10.10.20.15'.
$Name the second source you will use if the tool output is ambiguous (log, PCAP, CMDB, another tool).
$Record the start time, the host or interface you ran it on, and the exact command — enough for another analyst to reproduce it.
$Know what normal output looks like for this host before you run anything in anger.

how-experts-read-output

$Field recognition: identify the two or three fields that directly answer your question and ignore the rest for now.
$Scope check: confirm the output covers the host, interface, and time window you intended — not a cached or adjacent result.
$Evidence type: is this a direct observation (packet captured, port open) or an inference the tool made (service guessed from banner)?
$Correlation: name the one other source — a log line, a PCAP stream, a CMDB entry — that would confirm or contradict this.
$Decision: close the question, escalate with evidence, refine the scope, or collect another source — pick one and do it.

official-links

open docs Official Nmap documentation hub book / guide Nmap reference guide and manual pages NSE docs Nmap Scripting Engine script documentation

ethical-use-and-defense-scope

Scan only systems and ranges you own or have explicit written authorization to assess. Even a basic nmap port scan can trigger alerts, disrupt fragile devices, or violate policy if run without coordination.

Treat Nmap as a defensive validation tool, not a probe for third-party infrastructure. Before scanning production assets, define target scope, timing, scan intensity, and the name of the person who approved it.

When scanning sensitive environments — legacy systems, OT/IoT, medical devices, critical services — coordinate with owners and use the least intrusive scan that still answers the question. Write down what you ran and why.

tool-history-origin-and-purpose

$When created: First released in 1997 (published in Phrack in September 1997).
$Why it was created: Administrators and security practitioners needed a reliable way to discover hosts and services, validate exposure, and test network reachability without juggling multiple narrow tools.

Gordon 'Fyodor' Lyon created Nmap to consolidate scattered port-scanning techniques into one flexible free tool with a consistent interface for network exploration and security auditing.

why-defenders-still-use-it

People use Nmap because it is a practical baseline tool for host discovery, service enumeration, version checks, and change validation. It is useful for both quick audits and repeatable scanning workflows when used safely and with authorization.

How the tool evolved

+Expanded from simple port scanning into host discovery, service/version detection, OS detection, scripting (NSE), and output formats for automation.
+Adopted widely across blue team, red team, sysadmin, and network engineering workflows.
+Remains relevant because it answers foundational exposure and reachability questions quickly.

when-this-tool-is-a-good-fit

+Validate internet-facing exposure after firewall or load balancer changes.
+Test segmentation by running the same targeted checks from multiple source zones and comparing results.
+Build and maintain service inventories to feed vulnerability management and hardening workflows.
+Confirm remediation — scan again after a risky port or service should have been removed.

when-to-use-another-tool-or-source

!When you need host process/user context, pair with endpoint or OS logs.
!When you need ownership and business impact, pair with CMDB/ticketing/asset context.
!When the tool output is ambiguous, validate using a second evidence source before concluding.
!When production risk is high, test in a lab first and use change coordination.

1. What Nmap Solves for Defenders

The core questions Nmap answers are simple: which hosts are up, which ports are open, what services are running, and what changed since the last scan. Those are not simple problems in practice — network diagrams go stale, CMDB entries drift, and deployed services accumulate without documentation.

When documentation disagrees with reality, Nmap is the direct observation method. You scan and see what is actually reachable, which is often different from what the diagram says.

The strongest recurring use is not one-off discovery — it is change detection over time. A new open port, a changed banner, or a newly reachable host can mean drift, a misconfiguration, shadow IT, or a deployment someone forgot to document.

2. Defensive Scanning Strategy and Scope Control

Write down why you are scanning before you start. Inventory update, firewall rule verification, post-change exposure check, remediation validation, segmentation test — each purpose leads to different options and a different acceptable level of intrusiveness.

Split your work into phases: host discovery, then targeted port checks, then service/version enumeration, then scripted validation if needed. Running a heavy scan when a simple reachability check would answer the question wastes time and generates noise.

Keep a scan log. Date, operator, purpose, target ranges, exact command, and findings. This makes results auditable, explains scanner traffic to your monitoring team, and saves you when someone asks "why was nmap running at 3 a.m."

3. Interpreting Results Without Overconfidence

Nmap infers service versions from banners, protocol responses, and fingerprint signatures. Those banners can be customized, proxied, or disabled. When a version result surprises you, treat it as a hypothesis to validate — not a confirmed fact.

Port states require the same skepticism. Filtered, closed, and open|filtered mean different things depending on the firewall rules and middleboxes in the path. The scanner can only report what it sees from its vantage point.

Pair Nmap output with firewall logs, system logs, and at least one manual check before writing a remediation ticket. The scan starts the conversation; it does not end it.

4. NSE and Safe Scripted Validation

The Nmap Scripting Engine handles banner collection, protocol queries, certificate inspection, and other validation tasks. In defensive work, use scripts with documented behavior and a clear reason — not broad categories like "default" or "vuln" run without understanding what fires.

Some NSE scripts are noisy or inappropriate for production systems. Read the script documentation, test it against a lab host first, and coordinate with owners before expanding usage on sensitive infrastructure.

A practical defensive habit is to maintain a small, approved set of NSE scripts for recurring validation work: banner collection, TLS certificate checks, specific protocol identification. Standardization keeps results comparable across scans.

5. Using Nmap for Segmentation and Firewall Validation

Firewall policy reviews often stay abstract — rules on paper that nobody has tested from the right source segment. Nmap makes them concrete. Run the same targeted port checks from each network zone (user, server, admin, guest) and compare the results to the intended access matrix.

If a rule should block user-to-management access, an Nmap test from the user segment tells you whether it actually does. That is a more reliable answer than trusting a config review alone.

Repeat the same checks after every change window. This turns network control validation into a regression test habit. It also gives you a clear before/after record if something unexpected opens up.

6. Operationalizing Nmap Results

Raw scan output is not the deliverable. The deliverable is scan output tagged with asset ownership and role context. A new open port on a dev host is a different conversation than the same port on an internet-facing identity server — the scan result alone cannot tell you which matters more.

Track deltas between scans rather than reviewing full outputs every time. A diff between last week and this week shows you exactly what changed. This reduces review time and focuses attention where it belongs.

Feed Nmap findings into your vulnerability management queue, your hardening checklist, and your firewall change review process. Discovery is the first step in a workflow, not the end product.

7. Learning Nmap as a Defensive Practitioner

Start with a handful of safe, targeted commands and understand the output before adding options. Learn what open, closed, filtered, and open|filtered each mean in context — not just the definitions, but what they imply about the firewall and host behavior between you and the target.

Practice in a lab where you control the services. Change what is running and watch how the scan changes. That feedback loop builds intuition about scan accuracy, banner behavior, and how firewalls and proxies affect what Nmap reports.

Document a standard scan procedure for your team: which profiles are approved, when to coordinate with owners, what to record, and how results should feed into remediation. Good nmap software usage is as much about repeatable process as it is about command syntax.

scenario-teaching-playbooks

Work through each scenario step by step. The goal is to practice making decisions with the tool — not just executing commands — so the workflow becomes automatic before you need it under pressure.

1. Validate internet-facing exposure after firewall or load balancer changes.

Suggested starting block: Host Discovery And Targeted Checks

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

2. Test segmentation by running the same targeted checks from multiple source zones and comparing results.

Suggested starting block: Service / Version Validation

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

3. Build and maintain service inventories to feed vulnerability management and hardening workflows.

Suggested starting block: Safer Workflow And Output Handling

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

4. Confirm remediation — scan again after a risky port or service should have been removed.

Suggested starting block: Host Discovery And Targeted Checks

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

cli-workflows

Lab-safe commands for authorized environments. Run each one, read the output, and note what field or value tells you something useful before moving to the next.

cli-walkthroughs-with-expected-output

One command per block, with sample output. Study the output before you run the command yourself — you should recognize what you are looking at when it appears on your screen.

Host Discovery And Targeted Checks

Beginner

Command

nmap -sn 10.10.20.0/24

Example Output

Nmap scan report for 10.10.20.15
Host is up (0.003s latency).

$ how to read it: Read the key fields — host, port, protocol, state — then ask whether the output answers the question you started with. If it raises a new question instead, collect a second source before drawing a conclusion.

Service / Version Validation

Intermediate

Command

nmap -sV --version-light 10.10.20.15

Example Output

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH
443/tcp open  https   nginx

Safer Workflow And Output Handling

Advanced

Command

nmap -sS -T2 --max-retries 2 -oA scans/web01-audit 10.10.20.15

Example Output

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.10.20.15
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.2
80/tcp  open  http    nginx 1.24
443/tcp open  https   nginx 1.24
Nmap done: 1 IP address (1 host up) scanned in 28.17 seconds
# Output written to scans/web01-audit.{nmap,gnmap,xml}

command-anatomy-and-expert-usage

Each card explains what the command is for, what can go wrong, and what the output means. Syntax is easy to look up; knowing which command to reach for — and what to ignore in the output — is the skill worth building.

Host Discovery And Targeted Checks

Beginner

Command

nmap -sn 10.10.20.0/24

Command Anatomy

$Base command: nmap
$Primary arguments/options: -sn 10.10.20.0/24
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

Nmap scan report for 10.10.20.15
Host is up (0.003s latency).

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Host Discovery And Targeted Checks

Beginner

Command

nmap -Pn -p 22,80,443 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: -Pn -p 22,80,443 10.10.20.15
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.10.20.15
Host is up (assumed up due to -Pn).
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
Nmap done: 1 IP address (1 host up) scanned in 4.12 seconds

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Host Discovery And Targeted Checks

Beginner

Command

nmap -sS -p- --top-ports 1000 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: -sS -p- --top-ports 1000 10.10.20.15
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Medium: scanning can trigger alerts or stress fragile services; use approved scope and timing.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.10.20.15
PORT      STATE  SERVICE
22/tcp    open   ssh
80/tcp    open   http
443/tcp   open   https
8080/tcp  open   http-proxy
65535/tcp closed unknown
Nmap done: 1 IP address (1 host up) scanned in 62.43 seconds

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service / Version Validation

Intermediate

Command

nmap -sV --version-light 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: -sV --version-light 10.10.20.15
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH
443/tcp open  https   nginx

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service / Version Validation

Intermediate

Command

nmap -sV --version-all 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: -sV --version-all 10.10.20.15
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH
443/tcp open  https   nginx

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service / Version Validation

Intermediate

Command

nmap --script=banner,ssl-cert -p 443 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: --script=banner,ssl-cert -p 443 10.10.20.15
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.10.20.15
PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=lab.example.com
|           issuer: commonName=Example Lab CA
|           notBefore: 2026-01-01T00:00:00
|           notAfter:  2027-01-01T00:00:00
| banner: HTTP/1.1 200 OK
|_Server: nginx/1.24.0

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Safer Workflow And Output Handling

Advanced

Command

nmap -sS -T2 --max-retries 2 -oA scans/web01-audit 10.10.20.15

Command Anatomy

$Base command: nmap
$Primary arguments/options: -sS -T2 --max-retries 2 -oA
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Discovery, reachability testing, or service/version validation.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 10.10.20.15
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 9.2
80/tcp  open  http    nginx 1.24
443/tcp open  https   nginx 1.24
Nmap done: 1 IP address (1 host up) scanned in 28.17 seconds
# Output written to scans/web01-audit.{nmap,gnmap,xml}

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Safer Workflow And Output Handling

Advanced

Command

grep "open" scans/web01-audit.gnmap

Command Anatomy

$Base command: grep
$Primary arguments/options: "open" scans/web01-audit.gnmap
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

Host: 10.10.20.15 ()   Ports: 22/open/tcp//ssh//OpenSSH 9.2/, 80/open/tcp//http//nginx 1.24/, 443/open/tcp//https//nginx 1.24/

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Safer Workflow And Output Handling

Advanced

Command

diff -u old.gnmap scans/web01-audit.gnmap || true

Command Anatomy

$Base command: diff
$Primary arguments/options: -u old.gnmap scans/web01-audit.gnmap || true
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

--- old.gnmap
+++ scans/web01-audit.gnmap
@@ -3 +3 @@
-Host: 10.10.20.15 () Ports: 22/open/tcp, 80/open/tcp
+Host: 10.10.20.15 () Ports: 22/open/tcp, 80/open/tcp, 443/open/tcp
# 443 is new — verify with asset owner

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Host Discovery And Targeted Checks

nmap -sn 10.10.20.0/24
nmap -Pn -p 22,80,443 10.10.20.15
nmap -sS -p- --top-ports 1000 10.10.20.15

Service / Version Validation

nmap -sV --version-light 10.10.20.15
nmap -sV --version-all 10.10.20.15
nmap --script=banner,ssl-cert -p 443 10.10.20.15

Safer Workflow And Output Handling

nmap -sS -T2 --max-retries 2 -oA scans/web01-audit 10.10.20.15
grep "open" scans/web01-audit.gnmap
diff -u old.gnmap scans/web01-audit.gnmap || true

defensive-use-cases

$Validate internet-facing exposure after firewall or load balancer changes.
$Test segmentation by running the same targeted checks from multiple source zones and comparing results.
$Build and maintain service inventories to feed vulnerability management and hardening workflows.
$Confirm remediation — scan again after a risky port or service should have been removed.

common-mistakes

$Scanning production without coordinating with owners and notifying the monitoring team.
$Running a heavy scan when a simple targeted port check would answer the question.
$Treating a banner-derived version guess as a confirmed fact without manual validation.
$Running broad NSE script categories without reading what each script actually does.

expert-habits-for-free-self-study

Free teaching resource. The loop that makes analysts better: ask a precise question, collect evidence, read it carefully, validate against a second source, document what you found, and repeat with a harder question.

$Pick the least disruptive command that can still answer the question — then run that one first.
$Before you look at output, write one sentence stating what you expect to see.
$Mark each output field as 'observed' or 'inferred by tool' before acting on it.
$Save the exact command with flags and target — not a paraphrase — so another analyst can run the same thing.
$During a quiet period, capture what normal output looks like from key hosts; store those samples where you can find them during an incident.
$When you escalate, include the command output, the timestamp, and one sentence on why it matters — not just 'looks suspicious'.

knowledge-check

?What question is this tool best suited to answer first?
?What permissions or scope approvals are needed before using it?
?Which second evidence source should you pair with it for higher confidence?
?What does normal output look like for your environment?

teaching-answer-guide

Show teaching hints

#Start from the tool’s role and the scenario you are investigating.
#Never rely on one tool alone for high-confidence incident decisions.
#Document normal output patterns during calm periods so anomalies are easier to spot.
#Prefer lab validation for new commands, rules, or scans before production use.

practice-plan

# Build a baseline host and service inventory in a small lab subnet.
# Run the same targeted port checks from two different source segments and note the differences.
# Compare two scans over time, produce a delta, and write owner-focused notes on what changed.
# Define one standard scan profile your team could use repeatedly for routine exposure audits.

related-learning-modules

Study the core concepts and workflows behind this tool so your usage stays evidence-driven and repeatable.

open /learning/nmap-scanning-strategy-safe-validation-workflows Nmap Scanning Strategy and Safe Validation Workflows open /learning/subnetting-nat-firewall-policy-segmentation Subnetting, NAT, Firewall Policy Logic, and Segmentation Basics open /learning/exploit-informed-remediation-and-asset-criticality-tagging Exploit-Informed Remediation and Asset Criticality Tagging

related-threat-workflows

See where this tool fits into threat-specific detection, triage, and remediation workflows.

open /threats/exposed-services-and-remote-access-weaknesses Exposed services and remote access weaknesses open /threats/vulnerability-exploitation-and-misconfiguration-abuse Vulnerability exploitation and misconfiguration abuse

related-tools-in-this-path

Continue within the same guided track. These tools are commonly studied next in the path(s) this page belongs to.

Network Ops Path

open path

open tcpdump tcpdump open wireshark-tshark Wireshark / TShark open ncat Ncat open socat socat

<- previous tool Wireshark / TShark -> next tool Zeek