I’ve used Nmap on more networks than I can count — home labs, corporate environments I was authorized to assess, CTF ranges, and troubleshooting sessions where I just needed to know what was actually alive on a subnet. It’s the one tool that never leaves my toolkit, and over the years I’ve built up a working memory of flags and syntax that I rely on constantly. This is that knowledge, organized into one place, so I stop digging through old notes every time I need a scan I haven’t run in a few months.
This guide covers host discovery, port scanning techniques, service and OS detection, the Nmap Scripting Engine (NSE), timing controls, output formats, and the troubleshooting habits that keep me out of trouble — plus the legal and ethical boundary I never cross.
A note before anything else: Nmap is a powerful tool, and scanning networks or systems you don’t own or don’t have explicit written authorization to test is illegal in most jurisdictions. Everything below assumes you’re scanning your own infrastructure, a lab environment, or a target you have documented permission to assess.
Table of Contents
- Installing Nmap
- Basic Syntax and Target Specification
- Host Discovery (Ping Scanning)
- Port Specification
- Port Scanning Techniques
- Service and Version Detection
- OS Detection
- Nmap Scripting Engine (NSE)
- Timing and Performance
- Firewall/IDS Evasion Techniques
- Output Formats
- Common Real-World Scan Combinations
- Security Auditing Use Cases
- Best Practices
- Common Mistakes I See
- Troubleshooting
- FAQs
- Interview Questions
- Printable Quick-Reference Summary
- Official Documentation Links
1. Installing Nmap
| OS | Command |
|---|---|
| Debian/Ubuntu | sudo apt install nmap |
| RHEL/CentOS/Fedora | sudo dnf install nmap |
| macOS (Homebrew) | brew install nmap |
| Windows | Download installer from nmap.org (includes Zenmap GUI) |
| Verify install | nmap --version |
I always confirm the version after install, since some NSE scripts and features are version-dependent, and older repo packages can lag behind the current release significantly.
2. Basic Syntax and Target Specification
The general syntax I keep in my head is:
nmap [scan type] [options] [target]
| Target Format | Example | Meaning |
|---|---|---|
| Single IP | nmap 192.168.1.10 | Scans one host |
| Hostname | nmap example.local | Resolves and scans |
| Range | nmap 192.168.1.1-50 | Scans a range of hosts |
| CIDR block | nmap 192.168.1.0/24 | Scans entire subnet |
| Multiple targets | nmap 192.168.1.10 192.168.1.20 | Scans specific hosts |
| From file | nmap -iL targets.txt | Reads targets from a file |
| Exclude hosts | nmap 192.168.1.0/24 --exclude 192.168.1.5 | Skips specific host(s) |
| Random targets | nmap -iR 10 | Scans 10 random public hosts (avoid unless testing) |
3. Host Discovery (Ping Scanning)
Before I scan ports, I usually want to know what’s actually alive on the network.
| Command | Purpose |
|---|---|
nmap -sn 192.168.1.0/24 | Ping scan only — no port scan, just discovery |
nmap -PR 192.168.1.0/24 | ARP ping scan (fast, reliable on local subnets) |
nmap -PS22,80,443 192.168.1.0/24 | TCP SYN ping to specific ports |
nmap -PA80 192.168.1.0/24 | TCP ACK ping |
nmap -PU53 192.168.1.0/24 | UDP ping |
nmap -PE 192.168.1.0/24 | ICMP echo ping |
nmap -Pn 192.168.1.10 | Skips host discovery entirely, treats host as up |
I reach for -Pn constantly when scanning hosts I know are alive but that have ICMP blocked by a firewall — without it, Nmap will report the host as down and skip it entirely.
Example output from a basic discovery scan:
Nmap scan report for 192.168.1.1
Host is up (0.0021s latency).
Nmap scan report for 192.168.1.15
Host is up (0.0034s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.21 seconds
4. Port Specification
| Command | Purpose |
|---|---|
nmap -p 80 target | Scan a single port |
nmap -p 22,80,443 target | Scan specific ports |
nmap -p 1-1000 target | Scan a port range |
nmap -p- target | Scan all 65535 ports |
nmap -p U:53,T:80 target | Mix UDP and TCP port scans |
nmap -F target | Fast scan — top 100 common ports only |
nmap --top-ports 20 target | Scan the 20 most common ports |
When time is short, I lean on -F or --top-ports to get a fast read on a host before committing to a full -p- sweep, which can take a long time on a large or filtered network.
5. Port Scanning Techniques
| Flag | Scan Type | Notes |
|---|---|---|
-sS | TCP SYN scan (“half-open”) | Default for privileged users; fast and relatively stealthy |
-sT | TCP connect scan | Completes full handshake; used when raw sockets aren’t available (no root) |
-sU | UDP scan | Slower, but necessary for services like DNS, SNMP, DHCP |
-sA | ACK scan | Used to map firewall rule sets, not to find open ports |
-sW | Window scan | Similar to ACK but examines TCP window size |
-sM | Maimon scan | Exploits BSD-derived TCP stack quirks |
-sN | TCP Null scan | No flags set — used for firewall/IDS evasion testing |
-sF | TCP FIN scan | Sets only the FIN flag |
-sX | TCP Xmas scan | Sets FIN, PSH, URG flags (“lit up like a Christmas tree”) |
Example SYN scan:
nmap -sS 192.168.1.10
Expected output:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3306/tcp closed mysql
-sS is my default go-to when I have root/administrator privileges, since it’s faster than a full TCP connect scan and doesn’t complete the handshake, which historically logged less noisily on some systems (though modern IDS/IPS tools catch it just fine).
6. Service and Version Detection
nmap -sV 192.168.1.10
nmap -sV --version-intensity 5 192.168.1.10
nmap -A 192.168.1.10
| Flag | Purpose |
|---|---|
-sV | Detects service/version running on open ports |
--version-intensity 0-9 | Controls how aggressively Nmap probes for version info |
--version-light | Faster, less thorough version detection |
--version-all | Tries every probe for the most accurate result |
-A | Enables OS detection, version detection, script scanning, and traceroute all at once |
Example output:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp open http Apache httpd 2.4.52
I use -sV any time I need to know exactly what’s running behind a port, since “port 80 open” tells me far less than “Apache 2.4.52” when I’m checking for known vulnerabilities.
7. OS Detection
nmap -O 192.168.1.10
nmap -O --osscan-guess 192.168.1.10
| Flag | Purpose |
|---|---|
-O | Attempts to fingerprint the target’s operating system |
--osscan-guess | Makes Nmap guess more aggressively when results are ambiguous |
--osscan-limit | Limits OS detection to promising targets only (at least one open and one closed port) |
Example output:
Running: Linux 5.X
OS CPE: cpe:/o:linux:linux_kernel:5
OS details: Linux 5.0 - 5.14
OS detection relies on subtle TCP/IP stack behaviors and isn’t always perfectly accurate, especially against hardened or virtualized hosts, so I treat the result as a strong hint rather than ground truth.
8. Nmap Scripting Engine (NSE)
The NSE is where Nmap goes from “port scanner” to “vulnerability and enumeration platform.” Scripts live in categories like auth, default, discovery, vuln, safe, and intrusive.
| Command | Purpose |
|---|---|
nmap -sC target | Runs default safe scripts |
nmap --script=default target | Same as -sC |
nmap --script=vuln target | Runs vulnerability-detection scripts |
nmap --script=http-title target | Runs a single named script |
nmap --script=smb-os-discovery target | Enumerates SMB/OS info on Windows hosts |
nmap --script-updatedb | Updates the local script database |
nmap --script-help=<script> | Shows help/description for a specific script |
Example combining detection with scripting:
nmap -sV -sC -p 80,443 192.168.1.10
I reach for --script=vuln during authorized security assessments to get a quick read on known CVEs affecting detected service versions, but I never run it against production systems without change-control approval — some vuln scripts are intrusive enough to cause instability on fragile legacy services.
9. Timing and Performance
| Flag | Speed | Use Case |
|---|---|---|
-T0 | Paranoid | Extremely slow, used to evade IDS detection |
-T1 | Sneaky | Very slow, evasion-focused |
-T2 | Polite | Slower, reduces network load |
-T3 | Normal | Default timing |
-T4 | Aggressive | Faster, assumes a reliable, fast network |
-T5 | Insane | Fastest, may sacrifice accuracy on unstable networks |
Additional performance controls I use:
nmap --min-rate 500 target
nmap --max-retries 2 target
nmap --host-timeout 30m target
For internal networks with good connectivity, -T4 is my default. On WAN links or unstable connections, I drop to -T2 or -T3 to avoid false negatives from dropped probes.
10. Firewall/IDS Evasion Techniques
These are legitimate techniques for authorized penetration testing to understand how well a firewall or IDS is actually protecting a network — not something to use outside a scope-approved engagement.
| Flag | Purpose |
|---|---|
-f | Fragments packets to slip past simple packet filters |
-D RND:10 | Uses decoy IPs to obscure the real scan source |
-S <spoofed-IP> | Spoofs the source IP (requires matching routing setup) |
-g 53 | Uses a specific source port (e.g., 53, mimicking DNS) to bypass weak filtering |
--data-length 25 | Appends random data to packets to alter their signature |
--mtu <value> | Sets a custom MTU when fragmenting |
I’ll only ever use decoys or spoofing in a lab or an engagement where the client has explicitly signed off — spoofed-source scans can also break things for other systems on the path if used carelessly.
11. Output Formats
| Command | Purpose |
|---|---|
nmap -oN scan.txt target | Normal text output |
nmap -oX scan.xml target | XML output (good for parsing/automation) |
nmap -oG scan.gnmap target | Grepable output |
nmap -oA scan_results target | Outputs in all three formats at once with the same base filename |
nmap -v target | Verbose output |
nmap -vv target | Extra verbose output |
nmap -d target | Debug output |
I default to -oA on any scan I’ll want to reference later or feed into another tool — having the XML available means I can parse results programmatically instead of scraping text output.
12. Common Real-World Scan Combinations
These are the exact commands I actually type most often:
# Quick "what's alive" sweep of a subnet
nmap -sn 192.168.1.0/24
# Fast common-port scan with service detection
nmap -sV -F 192.168.1.10
# Full TCP port sweep with default scripts and OS detection
nmap -A -p- 192.168.1.10
# Stealthier SYN scan with slower timing for a sensitive network
nmap -sS -T2 192.168.1.0/24
# UDP scan of common service ports (DNS, SNMP, NTP, etc.)
nmap -sU --top-ports 20 192.168.1.10
# Vulnerability-focused scan on a specific web server
nmap -sV --script=vuln -p 80,443 192.168.1.10
# Full audit with all output formats saved
nmap -A -T4 -oA full_audit 192.168.1.0/24
13. Security Auditing Use Cases
- Asset inventory —
-snsweeps to confirm every device on a subnet is documented and expected. - Attack surface review — full port scans (
-p-) to catch services running on non-standard ports that a quick scan would miss. - Patch verification —
-sVcomparisons before and after a patching cycle to confirm version changes took effect. - Firewall rule validation —
-sAACK scans to confirm a firewall is actually filtering the ports it’s supposed to. - Rogue device detection — scheduled discovery scans compared against a known-good asset list to flag unauthorized devices.
- Compliance evidence — timestamped, saved scan output (
-oA) as documentation for audits like PCI-DSS or internal security reviews.
14. Best Practices
- Always get written authorization before scanning any network you don’t personally own.
- Start with discovery scans before diving into full port sweeps — it saves time and reduces unnecessary traffic.
- Use
-sVand-Osparingly against fragile or legacy systems; some devices (older printers, industrial control systems) can misbehave under heavy probing. - Save output in multiple formats (
-oA) so you can both read it and parse it later. - Throttle timing (
-T2or lower--min-rate) on production networks during business hours. - Keep the NSE script database updated (
--script-updatedb) before relying on vulnerability scripts. - Cross-reference version detection results against a CVE database rather than assuming a version number alone confirms exploitability.
- Document scope explicitly — IP ranges, time windows, and approved scan types — before starting any assessment.
15. Common Mistakes I See
- Running
-p-full scans against large subnets without adjusting timing, leading to scans that take hours longer than necessary. - Forgetting
-Pnwhen scanning hosts that block ICMP, and concluding (incorrectly) that the host is down. - Assuming a closed or filtered port result is the same thing — they’re not, and the distinction matters for firewall troubleshooting.
- Running
-sUUDP scans with default timing and giving up before they finish — UDP scans are inherently much slower than TCP scans. - Using
-Aby default on every scan without considering that it triggers a lot of active, sometimes noisy, probing. - Scanning networks without authorization, even “just to check,” which can carry real legal consequences.
- Not saving output, then needing to re-run a scan that already took twenty minutes.
16. Troubleshooting
Scan returns “all ports filtered” — Likely a firewall is dropping probes silently. Try -Pn to skip host discovery, or -sA to check if it’s stateful filtering versus a genuinely offline host.
Scan is taking far too long — Increase --min-rate, reduce the port range, bump the timing template up (-T4), or check if a UDP scan is the culprit (UDP is inherently slow due to how it handles non-responses).
Nmap requires root/administrator privileges — SYN scans (-sS) and OS detection (-O) require raw socket access. Run with sudo on Linux/macOS or as Administrator on Windows, or fall back to -sT if elevated privileges aren’t available.
Results look inconsistent between runs — Network congestion, IDS/IPS rate-limiting, or a target’s own rate-limiting can cause this. Try --max-retries and a slower timing template to stabilize results.
Version detection isn’t identifying a service — Increase --version-intensity up to 9, or use --version-all for the most exhaustive probe set.
17. FAQs
Is Nmap illegal to use? Nmap itself is completely legal software. Using it to scan networks or systems you don’t own or don’t have explicit permission to test can be illegal depending on your jurisdiction. Always get authorization first.
What’s the difference between a SYN scan and a connect scan? A SYN scan (-sS) sends a SYN packet and doesn’t complete the TCP handshake, making it faster and requiring raw socket privileges. A connect scan (-sT) completes the full handshake using the OS’s normal networking stack, which works without elevated privileges but is slower and more visible in logs.
Why is my UDP scan so slow? UDP is connectionless, so Nmap can’t rely on a simple SYN/ACK response to confirm a port is open. It has to wait for ICMP “port unreachable” responses (for closed ports) or time out entirely (for open|filtered ports), which is inherently slower than TCP scanning.
What does “filtered” mean in scan results, versus “closed”? “Closed” means a port responded, confirming the host is reachable but nothing is listening. “Filtered” means Nmap couldn’t determine the port’s state because a firewall or ACL is blocking the probe.
Can Nmap detect every operating system accurately? No. OS detection relies on statistical fingerprinting of TCP/IP stack behavior and works best against hosts with at least one open and one closed port. Heavily firewalled or virtualized hosts can return inaccurate or inconclusive results.
What’s the safest scan type to run against production systems? A slower-timed, default-script TCP SYN or connect scan (-sS -T2 -sC) with limited port ranges is generally the least disruptive. Vulnerability scripts and aggressive/full scans should be scheduled with change-control approval.
18. Interview Questions
- Explain the difference between a TCP SYN scan and a TCP connect scan, and when you’d use each.
- Why does a UDP scan take longer than a TCP scan?
- What’s the difference between “filtered,” “closed,” and “open” port states in Nmap output?
- How would you use Nmap to identify potentially vulnerable service versions on a network?
- What are the risks of running an aggressive Nmap scan (
-A,-T5) against a production environment? - Explain what the Nmap Scripting Engine is and give an example of when you’d use a vulnerability script versus a discovery script.
- How does host discovery differ on a local subnet versus scanning across the internet?
- What legal and ethical considerations should precede any Nmap scan?
- How would you interpret an OS detection result with low confidence?
- Describe how you’d design a scan strategy for auditing a large enterprise network without disrupting production traffic.
19. Printable Quick-Reference Summary
| Task | Command |
|---|---|
| Ping sweep a subnet | nmap -sn 192.168.1.0/24 |
| Skip host discovery | nmap -Pn target |
| Scan top 100 ports fast | nmap -F target |
| Scan all ports | nmap -p- target |
| SYN scan | nmap -sS target |
| TCP connect scan | nmap -sT target |
| UDP scan | nmap -sU target |
| Service/version detection | nmap -sV target |
| OS detection | nmap -O target |
| Aggressive all-in-one scan | nmap -A target |
| Default NSE scripts | nmap -sC target |
| Vulnerability scripts | nmap --script=vuln target |
| Set timing template | nmap -T4 target |
| Save all output formats | nmap -oA filename target |
| Fragment packets (evasion) | nmap -f target |
20. Official Documentation Links
- Official Nmap Reference Guide: https://nmap.org/book/man.html
- Nmap Scripting Engine Documentation: https://nmap.org/book/nse.html
- Nmap NSE Script Library: https://nmap.org/nsedoc/
- Nmap Official Download Page: https://nmap.org/download.html
- Nmap Network Scanning Book (Gordon Lyon): https://nmap.org/book/
I keep this cheat sheet open in a tab any time I’m running a scan I haven’t done in a while — even after years of using Nmap regularly, there’s always a flag combination I forget. Save it, print it, or fork it into your own notes, and adjust the scan combinations to match the environments you actually work in.