Installation and Version Verification
Most distributions ship a version of nmap that is 6 to 18 months behind upstream. On Debian/Ubuntu the packaged version is often 7.80 or 7.93, which is missing several NSE scripts and the improved service detection database from 7.95. Check before you rely on it.
On Rocky Linux 9 or RHEL-based systems, the EPEL repository carries a more recent build. After installation, always confirm the version and that nmap has raw socket access - scans that require SYN packets need either root or the cap_net_raw capability.
# Debian/Ubuntu
apt install nmap
nmap --version
# Rocky Linux 9 / RHEL 9 via EPEL
dnf install epel-release
dnf install nmap
nmap --version
# Check raw socket capability for non-root use
getcap $(which nmap)
# Should show: nmap = cap_net_raw+eip
# If not set:
setcap cap_net_raw+eip $(which nmap)Understanding Scan Types Before You Run Anything
The default nmap scan when run as root is a SYN scan (-sS). When run as an unprivileged user it falls back to a connect scan (-sT). These behave differently and leave different traces in target logs.
SYN scan (-sS) sends a SYN, receives SYN-ACK for open ports, and immediately sends RST without completing the handshake. Most application-layer services never log this because the TCP connection is never established. The tradeoff is that it requires root.
Connect scan (-sT) completes the full three-way handshake. It works without root but will appear in application logs and connection tracking. Use this only when you cannot run as root and understand the logging implications.
UDP scan (-sU) is slow and unreliable but necessary - services like DNS (53), SNMP (161/162), NTP (123), and DHCP (67/68) run on UDP. Many audits miss these entirely. Combine UDP and TCP in a single run to save time.
Null, FIN, and Xmas scans (-sN, -sF, -sX) exploit an RFC 793 ambiguity: closed ports send RST, open ports send nothing. These bypass some stateless packet filters but fail against Windows hosts and modern stateful firewalls, so their practical value in 2026 is limited to specific legacy environments.
# SYN scan (root required)
nmap -sS 192.168.1.0/24
# Connect scan (no root needed)
nmap -sT 192.168.1.50
# Combined TCP SYN + UDP scan on common ports
nmap -sS -sU -p T:22,80,443,8080,U:53,123,161 192.168.1.50
# FIN scan for stateless filter evasion
nmap -sF 10.10.0.5Port Specification and Range Control
nmap's default behavior scans the 1,000 most common ports from its services database. This is a reasonable starting point for discovery but misses services running on non-standard ports. For a proper audit, you need to decide between three approaches: scan the top N ports by frequency, scan a specific list, or scan all 65,535 ports.
Scanning all ports takes significantly longer but is the only approach that guarantees you find services on high ports - SSH moved to 2222, management interfaces on 8443, custom apps on 9000-9999, and similar configurations are common in real environments. On our test server (Rocky Linux 9, 1Gbps LAN), a full TCP SYN scan of one host with aggressive timing (-T4) completed in 38 seconds. The same scan over a 100Mbps WAN link with -T3 took 4 minutes 12 seconds.
The --top-ports flag uses nmap's frequency database. --top-ports 100 catches roughly 97% of services in typical enterprise environments based on our experience auditing mixed Linux/Windows networks.
# All 65535 TCP ports
nmap -sS -p- 192.168.1.50
# Top 100 ports by frequency
nmap -sS --top-ports 100 192.168.1.50
# Specific port list
nmap -sS -p 22,25,80,443,3306,5432,6379,8080,8443,27017 192.168.1.50
# Port range
nmap -sS -p 1-10000 192.168.1.50
# Exclude a port from range
nmap -sS -p 1-65535 --exclude-ports 9999 192.168.1.50Timing Templates and Performance Tuning
nmap's six timing templates (-T0 through -T5) are the single biggest lever for balancing speed against accuracy and detection risk. Most sysadmins reach for -T4 reflexively, which is appropriate for local networks but will trigger rate-limiting and IDS alerts on many production environments.
-T0 (paranoid) and -T1 (sneaky) serialize probe transmission with long delays - T0 waits 5 minutes between probes. These are for evading the most aggressive detection systems and are impractical for scanning large ranges.
-T2 (polite) uses a 400ms inter-probe delay. Use this when scanning production systems during business hours where you cannot risk saturating links.
-T3 (normal) is the default. Reasonable for most internal scans.
-T4 (aggressive) reduces timeouts and assumes a reliable fast network. Good for lab environments and local subnets. This is our default for internal audits on Gigabit networks.
-T5 (insane) will drop packets and produce inaccurate results on anything but extremely fast, reliable networks. We tested -T5 against a local host and got 12 false negatives on open ports that -T4 correctly identified.
Beyond timing templates, you can tune individual parameters. The most useful are --min-rate and --max-rate to control packet throughput, and --host-timeout to skip slow hosts in large network scans.
# Conservative scan for production networks
nmap -sS -T2 --max-rate 100 10.0.0.0/24
# Aggressive internal audit
nmap -sS -T4 --min-rate 1000 192.168.1.0/24
# Skip hosts that don't respond within 30 seconds
nmap -sS -T3 --host-timeout 30s 10.0.0.0/16
# Parallelism control
nmap -sS --min-hostgroup 64 --max-hostgroup 256 10.0.0.0/24Service and Version Detection
Port state (open/closed/filtered) tells you TCP is listening. Service detection (-sV) tells you what is actually running. The difference matters: an open port 443 might be nginx, HAProxy, or a custom Go application, and each has different vulnerability profiles.
Service detection works by sending protocol-specific probes and matching responses against nmap's nmap-service-probes database. The --version-intensity flag (0-9) controls how aggressively nmap probes - higher values send more probes and are more likely to correctly identify obscure services but take longer. Default intensity is 7.
OS detection (-O) requires at least one open and one closed port to generate an accurate fingerprint. It works by analyzing TCP/IP stack behavior - window sizes, TTL values, TCP options - and matching against a database of known OS fingerprints. In our testing against Rocky Linux 9, nmap correctly identified the OS in 94% of attempts when both conditions were met. Against hardened systems using kernel parameters to normalize TCP behavior (common in financial sector environments), accuracy drops significantly.
The -A flag combines -sV, -O, script scanning, and traceroute in one shot. It is convenient but produces a lot of noise and is slower than targeted scanning. Use it for single host investigation, not network-wide audits.
# Service version detection
nmap -sS -sV 192.168.1.50
# High intensity version detection
nmap -sS -sV --version-intensity 9 192.168.1.50
# OS detection (requires root)
nmap -sS -O 192.168.1.50
# Combined aggressive detection on single host
nmap -A 192.168.1.50
# Version detection with lighter touch
nmap -sS -sV --version-intensity 3 --version-light 10.0.0.0/24NSE: The Nmap Scripting Engine
NSE scripts are the reason nmap is still the standard tool in 2026 despite faster alternatives like masscan. Scripts extend nmap from a port scanner into a vulnerability assessment platform. The 600+ bundled scripts cover authentication brute-forcing, vulnerability detection, service enumeration, and malware detection.
Scripts are organized into categories: auth, broadcast, brute, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version, and vuln. Always know the category before running scripts in production - anything in 'intrusive', 'dos', or 'exploit' can disrupt services.
The default category (-sC or --script=default) runs scripts marked safe for general use. This is appropriate for audits where you need quick wins without risk. The vuln category specifically targets known CVEs and misconfigurations.
For a practical example: the http-methods script reveals which HTTP methods a server accepts, which is a common misconfiguration finding. The ssl-cert script dumps certificate details including expiry dates - we use this in a nightly cron job across our infrastructure to catch certificates expiring within 30 days. The smb-vuln-ms17-010 script checks for EternalBlue (MS17-010) without exploiting it.
If you are building automated scanning pipelines or integrating nmap into a CI/CD workflow, tools like taskbotshub.ai can help orchestrate scheduled scans, parse XML output, and trigger alerts when new ports appear on monitored hosts.
# Run default safe scripts
nmap -sS -sC 192.168.1.50
# Run vuln category scripts
nmap -sS --script=vuln 192.168.1.50
# Specific script
nmap -sS -p 443 --script=ssl-cert 192.168.1.50
# Multiple scripts
nmap -sS -p 80,443 --script=http-methods,http-headers,ssl-cert 192.168.1.50
# SMB vulnerability check (safe, no exploitation)
nmap -sS -p 445 --script=smb-vuln-ms17-010 192.168.1.50
# Script with arguments
nmap -sS -p 3306 --script=mysql-info --script-args='mysql.user=root' 192.168.1.50
# List all scripts in a category
ls /usr/share/nmap/scripts/ | grep '^http'Output Formats and Parsing
nmap's default terminal output is readable but not scriptable. For any automated workflow, use structured output. nmap supports four formats: normal (-oN), XML (-oX), grepable (-oG), and all three simultaneously (-oA).
XML output is the most useful for programmatic processing. The schema is stable across nmap versions and parseable with standard tools. We use `python3 -c` with the built-in xml.etree library or the dedicated python-nmap library for post-processing. The grepable format is convenient for quick shell scripting with awk and grep.
Store scan results with timestamps in the filename. When auditing infrastructure over time, having dated scan files lets you diff port states between runs and catch changes. We keep 90 days of scan history on our monitoring server and run a daily diff that alerts on any new open port.
The `ndiff` utility ships with nmap and produces clean diffs between two scan XML files. This is the right tool for change detection rather than rolling your own diff logic.
# Save all formats simultaneously
nmap -sS -sV 192.168.1.0/24 -oA scan_$(date +%Y%m%d)
# XML only
nmap -sS 192.168.1.50 -oX scan_result.xml
# Grepable - extract open ports quickly
nmap -sS 192.168.1.0/24 -oG - | grep 'open' | awk '{print $2, $5}'
# Parse XML with Python
python3 -c "
import xml.etree.ElementTree as ET
tree = ET.parse('scan_result.xml')
for host in tree.findall('.//host'):
addr = host.find('address').get('addr')
for port in host.findall('.//port'):
if port.find('state').get('state') == 'open':
print(f"{addr}:{port.get('portid')} {port.find('service').get('name','?')}")
"
# Diff two scans
ndiff scan_20260801.xml scan_20260822.xmlFirewall Evasion and Packet Fragmentation
Testing your own firewall rules requires nmap to behave like an attacker, not a compliant client. Several nmap flags help validate that your perimeter defenses actually block what you think they block.
Packet fragmentation (-f) splits TCP headers across multiple IP fragments. Some older packet filters and stateless ACLs inspect only the first fragment and miss the TCP port information in subsequent fragments. Modern stateful firewalls reassemble fragments before inspection, so -f is less effective than it was in the early 2000s, but still worth testing against legacy infrastructure.
Decoy scanning (-D) mixes real scan packets with spoofed packets from decoy IP addresses, making the source of the scan ambiguous in firewall logs. The real scan packets still originate from your IP, but they are buried in noise. This is useful for testing whether your IDS is actually tracking scan sources or just logging all probe activity.
The --source-port flag exploits stateless firewall rules that permit traffic from specific source ports. Rules that allow inbound traffic from source port 53 (DNS) or 20 (FTP data) to permit legitimate traffic are sometimes misconfigured to apply to all destinations. This is a classic firewall misconfiguration worth testing.
Interface and MTU control (--send-eth, --mtu) let you craft packets at the Ethernet level and control fragmentation size. Use --mtu with a value that is a multiple of 8.
# Fragment packets to evade stateless filters
nmap -sS -f 192.168.1.50
# Double fragmentation
nmap -sS -ff 192.168.1.50
# Custom MTU
nmap -sS --mtu 24 192.168.1.50
# Decoy scan (ME = your real IP position in decoy list)
nmap -sS -D 10.0.0.5,10.0.0.6,ME,10.0.0.8 192.168.1.50
# Source port spoofing
nmap -sS --source-port 53 192.168.1.50
# Randomize host scan order (avoids sequential IDS detection)
nmap -sS --randomize-hosts 10.0.0.0/24
# Spoof MAC address (useful on local segment)
nmap -sS --spoof-mac 0 192.168.1.50Host Discovery and Ping Scan Techniques
Before port scanning a network, you need to know which hosts are up. nmap's default host discovery sends an ICMP echo, a TCP SYN to port 443, a TCP ACK to port 80, and an ICMP timestamp. Hosts that respond to any of these are marked as up and scanned.
This default works well for internal networks. For external targets or environments with ICMP blocked, use targeted TCP-based discovery. The -PS flag sends TCP SYN packets to specified ports for discovery, which works even when ICMP is blocked at the perimeter.
The -Pn flag skips host discovery entirely and treats all hosts as up. Use this when you know a host is up but it is not responding to ping (common for Windows hosts with firewall enabled, or hosts on the other side of strict perimeter rules). Without -Pn, nmap will mark these as down and skip them.
For subnet mapping without port scanning - just finding live hosts - use -sn (formerly -sP). This is the right approach for quick inventory before a longer scan.
# Fast host discovery only, no port scan
nmap -sn 10.0.0.0/24
# Save live host list
nmap -sn 10.0.0.0/24 -oG - | grep 'Up' | awk '{print $2}' > live_hosts.txt
# Port-based discovery when ICMP is blocked
nmap -PS22,80,443,8080 10.0.0.0/24
# UDP discovery
nmap -PU53,161 10.0.0.0/24
# Skip discovery, treat all as up
nmap -sS -Pn 203.0.113.50
# Scan from live hosts file
nmap -sS -iL live_hosts.txt -p 22,80,443,8443Practical Audit Workflows for Production Environments
In practice, port scanning production infrastructure requires scheduling, logging, and authorization documentation. Running nmap from your workstation ad-hoc is fine for investigation. For regular audits, set up a dedicated scanning host with controlled outbound rules and store all results centrally.
A minimal weekly audit workflow: discover live hosts Sunday at 0200, run full TCP scan against all live hosts, diff against previous week's results, alert on new open ports. The cron-based approach below handles this. For more sophisticated scheduling with notification integrations, taskbotshub.ai provides pre-built DevOps automation workflows that can ingest nmap XML and push findings to Slack, PagerDuty, or ticketing systems without custom scripting.
For internal firewall validation, run nmap from outside each network segment you are testing. An nmap scan from inside a VLAN cannot validate perimeter rules for that VLAN. We maintain scanning hosts in a DMZ, on the internal network, and in each major VLAN for this reason.
When scanning cloud infrastructure (AWS, GCP, Azure), check provider terms first. AWS permits scanning your own instances without prior approval as of 2024 policy, but scanning other customers' resources is prohibited regardless of nmap settings. Many providers rate-limit or block aggressive scans at the network level.
#!/bin/bash
# /opt/nmap-audit/weekly_scan.sh
SCAN_DIR="/opt/nmap-audit/results"
DATE=$(date +%Y%m%d)
NETWORK="10.0.0.0/24"
PREV_SCAN=$(ls -t $SCAN_DIR/*.xml 2>/dev/null | sed -n '2p')
mkdir -p $SCAN_DIR
# Discovery pass
nmap -sn $NETWORK -oG - | grep 'Up' | awk '{print $2}' > /tmp/live_hosts.txt
echo "Live hosts: $(wc -l < /tmp/live_hosts.txt)"
# Full TCP scan of live hosts
nmap -sS -sV -p- -T3 \
--min-rate 500 \
--max-rate 2000 \
--host-timeout 120s \
-iL /tmp/live_hosts.txt \
-oA ${SCAN_DIR}/scan_${DATE}
# Diff against previous scan
if [ -n "$PREV_SCAN" ]; then
ndiff $PREV_SCAN ${SCAN_DIR}/scan_${DATE}.xml > ${SCAN_DIR}/diff_${DATE}.txt
if [ -s ${SCAN_DIR}/diff_${DATE}.txt ]; then
mail -s "nmap: changes detected ${DATE}" security@example.com < ${SCAN_DIR}/diff_${DATE}.txt
fi
fi
# Crontab entry: run weekly Sunday 02:00
# 0 2 * * 0 /opt/nmap-audit/weekly_scan.sh >> /var/log/nmap-audit.log 2>&1nmap vs Alternatives: When to Use What
masscan can scan the entire IPv4 address space in under 6 minutes at 10Gbps. For sheer speed on large ranges, it beats nmap significantly. But masscan produces no service detection, no OS fingerprinting, and no scripting capability. It outputs port states only.
The right workflow for large-scale scanning is masscan for discovery at high speed, then nmap against the discovered hosts for detailed enumeration. This combination gives you masscan's throughput with nmap's depth.
RustScan is a port scanner written in Rust that feeds discovered ports into nmap automatically. It completes port discovery in seconds then hands off to nmap for analysis. On our test server, RustScan found all open ports on a local host in 1.2 seconds versus nmap's 38 seconds for the same host. The tradeoff is less control over the initial scan behavior and an additional dependency.
For web application enumeration specifically, nikto and gobuster address different layers than nmap - use them alongside nmap rather than instead of it.
nmap remains the right default tool for most sysadmin work because it combines discovery, service detection, and scripting in one well-maintained package with stable behavior across 20 years.
# masscan + nmap combined workflow
# Step 1: Fast discovery with masscan
masscan 10.0.0.0/24 -p1-65535 --rate=10000 -oL masscan_results.txt
# Step 2: Extract hosts and ports
awk '/open/ {print $4"/"$3}' masscan_results.txt | sort -u > open_ports.txt
# Step 3: Feed discovered ports to nmap for service detection
cat open_ports.txt | while IFS='/' read host port; do
nmap -sS -sV -p $port $host -oX nmap_${host}_${port}.xml 2>/dev/null
done
# RustScan with nmap handoff
rustscan -a 192.168.1.50 -- -sV -sC -oA rustscan_results