Nmap with Linux: Network Scanning from the Command Line

If you manage Linux systems or work in security, Nmap is one of the first tools you should know. Originally released on September 1, 1997 as "The Art of Port Scanning" in Phrack Magazine Issue 51 -- a roughly 2,000-line C program whose source code was embedded directly in the article -- Nmap has evolved over nearly three decades into the definitive open-source utility for network discovery and security auditing. Gordon "Fyodor" Lyon, the tool's creator and ongoing maintainer, has described the project's trajectory from a simple port scanner to a full network assessment platform. The latest stable release, version 7.99 (March 26, 2026), integrates updated IPv4 and IPv6 OS fingerprints, upgrades core libraries including OpenSSL 3.0.19, and adds VPN virtual adapter scanning support on Windows -- and it still runs from the same command line where it started.

This guide walks through how to install Nmap on Linux, how the major scan types work at the packet level, how to extract useful information with version detection and OS fingerprinting, and how to extend Nmap's capabilities with the Nmap Scripting Engine. The goal is practical: by the end, you should be able to run intelligent scans, interpret the results, and know which options to reach for in different situations.

Installing Nmap on Linux

Every major Linux distribution packages Nmap in its default repositories, so installation typically requires a single command. The trade-off is that distribution packages are sometimes behind the latest release. Ubuntu 22.04 LTS ships Nmap 7.80, Ubuntu 24.04 LTS includes 7.94, and Fedora 42 provides 7.92. Debian 12 (Bookworm) includes 7.93, while Debian 13 (Trixie) ships 7.95. If you need version 7.99 features -- including the reverse-DNS performance fix, VPN adapter support, and updated OS fingerprint database -- you will need to compile from source or use Nmap's official RPM packages.

Debian and Ubuntu

$ sudo apt update
$ sudo apt install nmap

RHEL, Fedora, Rocky Linux, AlmaLinux

$ sudo dnf install nmap

Arch Linux

$ sudo pacman -S nmap

After installation, verify everything is working:

$ nmap --version
Nmap version 7.99 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.4.8 openssl-3.0.19 libssh2-1.11.1
               libz-1.3.2 libpcre2-10.47 libpcap-1.10.6
               nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Compiling from Source

If you need the absolute latest release or want to enable optional features, compiling from source is straightforward. Install the build dependencies first, then download and build:

# Install build dependencies (Debian/Ubuntu)
$ sudo apt install build-essential libssl-dev libssh2-1-dev libpcap-dev

# Download and extract
$ wget https://nmap.org/dist/nmap-7.99.tar.bz2
$ tar xjf nmap-7.99.tar.bz2
$ cd nmap-7.99

# Configure, build, install
$ ./configure
$ make
$ sudo make install

How Nmap Works: The Scanning Process

An Nmap scan follows a predictable sequence of phases. Understanding these phases helps you choose the right options and interpret what the output means.

The process starts with target enumeration, where Nmap resolves hostnames and expands any CIDR ranges or IP lists into individual addresses. Next comes host discovery -- Nmap determines which targets are online before spending time port scanning offline hosts. By default, Nmap sends an ICMP echo request, a TCP SYN to port 443, a TCP ACK to port 80, and an ICMP timestamp request. If any of these probes get a response, the host is considered up.

After discovery, Nmap moves to the port scanning phase, probing individual ports to determine their state. Ports are classified as open (a service is actively listening), closed (reachable but no service is listening), filtered (a firewall or network obstacle is preventing Nmap from reaching the port), or open|filtered (Nmap cannot determine whether the port is open or filtered). By default, Nmap scans the 1,000 most commonly used ports based on empirical data from scanning tens of millions of Internet addresses. This is a frequent source of confusion: the default scan is not ports 1 through 1,000. It is the 1,000 ports with the highest observed open frequency in Nmap's nmap-services dataset. Port 8080 (HTTP alternate) is included in the default scan while port 900 is not, because real-world data shows 8080 open far more often. The distinction matters when you need complete coverage -- use -p- to scan all 65,535 ports.

Optional phases include version detection (-sV), which probes open ports to identify the service and its version, OS detection (-O), which analyzes TCP/IP stack behavior to fingerprint the operating system, and script scanning (-sC), which runs default NSE scripts against discovered services.

Port Scan Types

Nmap supports more than a dozen scan techniques. Each one manipulates TCP, UDP, or IP packets differently to extract information under different conditions. The scan type you choose depends on your privilege level, the network environment, and what you need to learn.

TCP SYN Scan (-sS)

SYN scan is the default when Nmap runs with root privileges. It sends a TCP packet with the SYN flag set -- the first step of the three-way handshake. If the target responds with SYN/ACK, the port is open. If it responds with RST, the port is closed. If no response comes back, the port is filtered.

The key detail is that Nmap never completes the handshake. After receiving the SYN/ACK, the operating system on the scanning machine sends a RST packet to tear down the half-open connection. This makes SYN scanning faster than a full connect scan and less likely to appear in application-level logs, since many services only log fully established connections. You will see SYN scan referred to as "stealth scan" in many online resources and even in Nmap's own output (which labels it "TCP SYN Stealth Scan"). That label dates back to the late 1990s when it was broadly accurate -- application-level logging was the primary detection method, and half-open connections evaded it. In modern networks, this label is misleading: any competent IDS/IPS, netflow collector, or stateful firewall will detect and log SYN scans without difficulty. The term persists in documentation and tooling for historical reasons, but treat SYN scan as faster and lighter rather than invisible. This guide uses the accurate framing throughout.

TCP Connect Scan (-sT)

Connect scan is the fallback when raw socket access is not available -- when you run Nmap without root privileges. Instead of crafting raw packets, Nmap uses the operating system's connect() system call to establish a full TCP connection. This completes the three-way handshake, which means the target is more likely to log the connection attempt. Connect scans are slower and generate more network traffic, but they work in environments where SYN scans are not an option. A point of clarification: some online guides state that connect scan is required for IPv6 targets. This was true in much older Nmap versions, but SYN scanning over IPv6 has been fully supported for many releases. If you have root privileges, -sS -6 works as expected. Nmap only falls back to connect scan on IPv6 when raw sockets are unavailable, just as it does on IPv4.

UDP Scan (-sU)

UDP scanning is essential but slow. Because UDP is connectionless, there is no handshake to indicate an open port. Nmap sends a UDP packet to each target port. If an ICMP port unreachable error comes back, the port is closed. If a UDP response comes back, the port is open. If nothing comes back after retransmissions, the port is classified as open|filtered -- Nmap cannot determine whether the port is open or if a firewall silently dropped the packet.

The speed problem comes from ICMP rate limiting. Many Linux systems limit ICMP destination unreachable messages to one per second by default, which means a full 65,535-port UDP scan can take more than 18 hours. In practice, you usually scan specific UDP ports rather than the full range.

# Scan common UDP services alongside a TCP SYN scan
$ sudo nmap -sS -sU -p T:22,80,443,U:53,123,161 192.168.1.1

FIN, NULL, and Xmas Scans (-sF, -sN, -sX)

These three scan types exploit a subtlety in the TCP specification. RFC 793 states that when a closed port receives a segment not containing RST, it must respond with RST. An open port, receiving a packet without SYN, RST, or ACK, should silently discard it. FIN scan sets only the FIN flag, NULL scan sets no flags at all, and Xmas scan sets FIN, PSH, and URG simultaneously (the name comes from the flags lighting up the packet header "like a Christmas tree"). A note on the RFC reference: RFC 793 was formally obsoleted by RFC 9293 in August 2022. The updated specification preserves the same port-state behavior that FIN, NULL, and Xmas scans rely on. We cite RFC 793 here because it is the original specification that Nmap was designed against, it is the document Nmap's own documentation and Fyodor's Phrack article reference, and the relevant behavior is unchanged in RFC 9293. You will find both RFC numbers cited across the security community.

"An incoming segment not containing a RST causes a RST to be sent."

-- RFC 793, "Transmission Control Protocol," IETF, September 1981 (rfc-editor.org/rfc/rfc793)

The advantage is that these scans can sometimes bypass stateless firewalls that only filter SYN packets. The disadvantage is that they rely on the target's TCP stack following the RFC exactly. Windows systems do not conform -- they send RST regardless of port state, which means all ports appear closed. This non-compliance is documented in Nmap's OS fingerprint database: the T2 test (a NULL packet to an open port) records whether the target responds, and if R=Y appears, these scans will be unreliable against that target. You can check before scanning by running nmap -O and examining the fingerprint output. This is also why Nmap's OS detection is so useful as a pre-scan step -- it tells you which scan techniques will work on a given target before you waste time running them.

TCP ACK Scan (-sA)

ACK scan does not determine whether a port is open or closed. Instead, it maps firewall rules. Nmap sends a TCP packet with only the ACK flag set. If the target responds with RST, the port is classified as unfiltered, meaning the firewall allows the packet through. If no response comes back or an ICMP unreachable error is returned, the port is filtered. This is useful for understanding whether a firewall is stateful (tracks connection state) or stateless (only examines individual packets).

Host Discovery

Before scanning ports, you often need to find out which hosts on a network are alive. Nmap's host discovery phase (sometimes called a ping sweep) identifies active systems without performing a full port scan.

# Ping sweep -- discover live hosts, skip port scanning
$ sudo nmap -sn 192.168.1.0/24

# Discover hosts using only TCP SYN probes on port 443
$ sudo nmap -sn -PS443 10.0.0.0/24

# Skip host discovery entirely -- assume all targets are up
$ sudo nmap -Pn -p 22,80,443 10.0.0.1-50

The -sn flag tells Nmap to stop after host discovery and not proceed to port scanning. When run with root privileges, Nmap uses ARP requests on the local network segment (which are extremely fast and reliable) and a combination of ICMP and TCP probes for remote hosts. The -Pn flag skips discovery entirely and treats every target as online, which is necessary when scanning hosts behind firewalls that block all ping probes.

Service and Version Detection

Knowing that port 80 is open is useful. Knowing that it is running Apache httpd 2.4.62 on Ubuntu is actionable. Nmap's version detection system (-sV) sends a series of probes to open ports and matches the responses against a database of thousands of service signatures.

$ sudo nmap -sV 192.168.1.10

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.5
80/tcp   open  http     Apache httpd 2.4.62 ((Ubuntu))
443/tcp  open  ssl/http Apache httpd 2.4.62
3306/tcp open  mysql    MySQL 8.0.40-0ubuntu0.24.04.1

Version detection works by probing the service and matching its responses against the nmap-service-probes file. You can control the intensity of version probing with --version-intensity, which accepts a value from 0 (light probing, faster) to 9 (try every possible probe, slower). The default intensity is 7. For quick internal scans where you trust the network, --version-intensity 2 cuts probing time significantly while still catching common services.

As of Nmap 7.95, the service fingerprint database contains over 12,089 signatures detecting 1,246 protocols -- from gRPC and MySQL X Protocol to more obscure services like TUYA IoT device protocol. The companion file nmap-services contains frequency data derived from scanning tens of millions of Internet-facing hosts. This is why Nmap's "top 1,000 ports" default is not simply ports 1 through 1,000 -- it is the 1,000 ports empirically observed to be open most frequently. Port 8080 (HTTP alternate) ranks significantly higher than, for example, port 900, because real-world scan data shows it open far more often. This data-driven approach is part of what makes Nmap more efficient than tools that scan ports sequentially.

"Nearly every security product on the planet uses something from Gordon somewhere."

-- HD Moore, founder of Metasploit and runZero, speaking about Nmap's ecosystem reach (runzero.com, 2022)

OS Fingerprinting

Nmap's OS detection (-O) works by sending a series of specially crafted TCP and UDP packets and analyzing how the target's networking stack responds. Different operating systems implement TCP/IP slightly differently -- variations in initial TTL values, TCP window sizes, the order of TCP options, and responses to unusual flag combinations form a fingerprint that Nmap matches against its database of known OS signatures.

$ sudo nmap -O 192.168.1.10

OS details: Linux 5.15 - 6.1 (Ubuntu)
Network Distance: 1 hop

OS detection requires at least one open and one closed port on the target for reliable results. If Nmap cannot find both, the fingerprinting accuracy drops significantly. The --osscan-guess flag tells Nmap to report its best guess even when confidence is low, and --osscan-limit restricts OS detection to targets that meet the open-and-closed-port requirement.

The Aggressive Scan (-A)

The -A flag is a shortcut that enables four features in a single option: OS detection (-O), version detection (-sV), default script scanning (-sC), and traceroute (--traceroute). It is the most comprehensive scan mode Nmap offers and provides the most complete picture of a target in one pass.

$ sudo nmap -A 192.168.1.10

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 9.6p1 Ubuntu 3ubuntu13.5
|  ssh-hostkey:
|    256 a8:3e:97:b1:5c:... (ECDSA)
|_   256 c7:12:48:f9:2a:... (ED25519)
80/tcp   open  http     Apache httpd 2.4.62 ((Ubuntu))
|_http-title: Welcome to Our Site
|_http-server-header: Apache/2.4.62 (Ubuntu)
443/tcp  open  ssl/http Apache httpd 2.4.62
| ssl-cert: Subject: commonName=example.com
| Not valid before: 2025-11-01T00:00:00
|_Not valid after:  2026-10-31T23:59:59

OS details: Linux 5.15 - 6.1
Network Distance: 1 hop

TRACEROUTE
HOP RTT     ADDRESS
1   0.42 ms 192.168.1.10

The Nmap Scripting Engine (NSE)

The Nmap Scripting Engine extends Nmap from a port scanner into a full network assessment platform. NSE scripts are written in Lua and shipped with the standard Nmap distribution -- the current library includes 612 scripts that automate tasks from banner grabbing and vulnerability detection to brute-force credential testing and service enumeration. As the official Nmap documentation states, the engine was designed with network discovery, version detection, vulnerability detection, and even vulnerability exploitation in mind (nmap.org/book/nse.html).

NSE organizes its scripts into 14 categories based on function and risk level: auth, broadcast, brute, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version, and vuln. You may encounter sources online that list 13 categories instead of 14. This discrepancy originates from a formatting quirk in certain versions of the official Nmap documentation where a period appears after "default" instead of a comma, causing some readers to count "default. discovery" as a single item. The correct count, verified in the Nmap source code and the NSE usage documentation at nmap.org/book/nse-usage.html, is 14 distinct categories. A single script can belong to multiple categories. For example, the ssl-heartbleed script belongs to vuln, safe, and discovery because it checks for a vulnerability without any risk of disrupting the target. When the Heartbleed vulnerability affected hundreds of thousands of systems in 2014, Nmap's developers shipped the ssl-heartbleed detection script within two days of disclosure (nmap.org/book/nse.html) -- a response time that underscores the engine's operational value in real incident response.

Running NSE Scripts

# Run default scripts (equivalent to -sC)
$ sudo nmap --script=default 192.168.1.10

# Run all vulnerability detection scripts
$ sudo nmap --script=vuln 192.168.1.10

# Run a specific script by name
$ sudo nmap --script=ssl-heartbleed -p 443 192.168.1.10

# Run all scripts matching a pattern
$ sudo nmap --script="http-*" -p 80,443 192.168.1.10

# Run all SMB vulnerability checks
$ sudo nmap --script="smb-vuln-*" -p 445 192.168.1.10

# Pass arguments to a script
$ sudo nmap --script=http-enum --script-args http-enum.basepath="/admin/" -p 80 192.168.1.10

Script arguments are passed with --script-args and use the format key=value. You can get help for any script, including its available arguments, by running nmap --script-help= followed by the script name.

Updating the Script Database

If you add custom scripts to the /usr/share/nmap/scripts/ directory or download third-party scripts, you need to rebuild the script database so Nmap can find them:

Recent NSE and Engine Additions (7.95 -- 7.99)

Nmap 7.95 (April 2024) added four NSE scripts from the DINA community targeting industrial control systems (ICS): hartip-info reads device information from HART protocol devices, iec61850-mms queries devices using Manufacturing Message Specification requests, multicast-profinet-discovery sends a multicast PROFINET DCP Identify All message and parses the responses, and profinet-cm-lookup queries the DCERPC endpoint mapper exposed via the PNIO-CM service. These additions reflect the growing importance of OT/ICS security in network scanning workflows. Nmap 7.96 (May 2025) introduced parallel forward DNS resolution -- the same engine that had been performing reverse-DNS lookups for nearly a decade. According to the official changelog, resolving one million website names dropped from 49 hours to just over one hour (nmap.org/changelog). That release also added three more scripts -- including mikrotik-routeros-version and targets-ipv6-eui64 -- bringing the total to 612.

Nmap 7.99 (March 2026) integrated fresh IPv4 and IPv6 OS fingerprints and fixed a reverse-DNS performance regression introduced in 7.98. It also added Windows VPN virtual adapter scanning support and upgraded core libraries including OpenSSL 3.0.19, libpcap 1.10.6, and libpcre2 10.47. For NSE users, 7.99 includes fixes to the hostmap-crtsh script (now reporting only true subdomains by default), improvements to the URL parsing library, and enhanced http-internal-ip-disclosure with IPv6 and HTTPS support.

Port Specification and Timing

Controlling which ports Nmap scans and how fast it scans them gives you precision over both speed and stealth.

# Scan a single port
$ nmap -p 22 192.168.1.10

# Scan multiple specific ports
$ nmap -p 22,80,443,3306,8080 192.168.1.10

# Scan a range
$ nmap -p 1-1024 192.168.1.10

# Scan all 65,535 ports
$ nmap -p- 192.168.1.10

# Scan the 100 most common ports (fast mode)
$ nmap -F 192.168.1.10

# Scan the top 20 most common ports
$ nmap --top-ports 20 192.168.1.10

Timing Templates

Nmap provides six timing templates, from -T0 (paranoid) to -T5 (insane), that control probe timing, parallelism, and retransmission behavior. The default is -T3 (normal).

• -T0 (paranoid) and -T1 (sneaky) -- extremely slow scans designed for IDS evasion. Probes are serialized with long pauses between them. Useful for stealth, but a full scan at -T0 can take days.
• -T2 (polite) -- slows the scan to reduce bandwidth consumption and target load. Good for scanning production systems during business hours.
• -T3 (normal) -- the default balance between speed and reliability.
• -T4 (aggressive) -- assumes a fast, reliable network. Reduces timeouts and increases parallelism. The standard choice for most internal network assessments.
• -T5 (insane) -- sacrifices accuracy for raw speed. May miss ports due to aggressive timeouts. Use only on extremely fast local networks where packet loss is near zero.

Output and Reporting

Nmap supports multiple output formats that you can combine in a single scan. Saving output is essential for documentation, comparison across scans over time, and integration with other tools.

# Normal output to file
$ nmap -oN scan_results.txt 192.168.1.0/24

# XML output (for parsing with other tools)
$ nmap -oX scan_results.xml 192.168.1.0/24

# Grepable output (one host per line, easy to parse with grep/awk)
$ nmap -oG scan_results.gnmap 192.168.1.0/24

# All three formats at once (basename approach)
$ nmap -oA scan_2026-04 192.168.1.0/24

The -oA flag is the most practical option for regular scanning. It creates three files with the extensions .nmap, .xml, and .gnmap, giving you human-readable output for quick review, structured XML for tool integration, and grepable output for command-line filtering.

Practical Scanning Scenarios

Here are complete command examples for common real-world situations, combining the options covered in earlier sections.

# Quick internal network inventory
$ sudo nmap -sn 10.0.0.0/24 -oG - | grep "Up" | awk '{print $2}'

# Full service audit of a single host
$ sudo nmap -sS -sV -O -p- -T4 -oA audit_webserver 10.0.0.50

# Check a web server for known vulnerabilities
$ sudo nmap --script=vuln -p 80,443 -sV 10.0.0.50

# Scan for common Windows SMB vulnerabilities
$ sudo nmap --script="smb-vuln-*" -p 139,445 10.0.0.0/24

# Enumerate SSL/TLS cipher suites on HTTPS servers
$ sudo nmap --script=ssl-enum-ciphers -p 443 10.0.0.50

# Fast sweep of the top 100 ports across a large subnet
$ sudo nmap -F -T4 --open 10.0.0.0/16 -oA fast_sweep

# Check DNS servers for zone transfer vulnerability
$ sudo nmap --script=dns-zone-transfer -p 53 --script-args dns-zone-transfer.domain=example.com 10.0.0.2

The --open flag in the fast sweep example filters the output to show only open ports, which is useful when scanning large ranges where you care about exposed services, not closed or filtered ports.

Target Specification and Input

Nmap accepts targets in several formats that you can mix freely on the command line. A single IP (192.168.1.10), a hostname (web01.internal), a CIDR range (10.0.0.0/24), an octet range (192.168.1.1-50), or a wildcard (192.168.1.*) all work. You can combine them: nmap 10.0.0.0/24 192.168.1.5 web01.example.com scans all three targets in a single run.

For larger engagements, the -iL flag reads targets from a file -- one per line, in any of the formats above. This is essential for repeatable scans in change management workflows:

# Read targets from a file
$ sudo nmap -sS -sV -iL targets.txt -oA weekly_scan

# Exclude specific hosts (e.g. production databases)
$ sudo nmap -sS 10.0.0.0/24 --exclude 10.0.0.5,10.0.0.6

# Exclude hosts listed in a file
$ sudo nmap -sS 10.0.0.0/24 --excludefile no-scan.txt

# Scan random targets (research/internet measurement use)
$ sudo nmap -sS -iR 100 -p 80 --open

The --exclude and --excludefile flags are critical in production environments. If your scan scope includes a /16 but certain hosts are fragile or out of scope, exclusion lists prevent accidental disruption. The -iR flag generates random Internet targets -- useful for research, but use it responsibly and only scan ports you have a legitimate reason to probe.

Interpreting Scan Results: What Filtered Really Means

New Nmap users are often confused by the difference between filtered, closed, and open|filtered. Understanding these states precisely is essential for making correct security conclusions.

Open means a service is accepting connections on that port. Closed means the port is reachable (the host responded) but nothing is listening -- this actually tells you that the host is alive and not firewalled on that port. Filtered means Nmap received no response at all, or received an ICMP unreachable error. This usually indicates a firewall is silently dropping packets. Open|filtered means Nmap cannot determine whether the port is open or filtered -- this occurs with UDP, FIN, NULL, and Xmas scans where open ports produce no response (identical to a filtered port dropping the packet).

The --reason flag is invaluable here. It tells you exactly why Nmap classified each port the way it did:

$ sudo nmap -sS --reason -p 22,80,443,8080 10.0.0.50

PORT     STATE    SERVICE  REASON
22/tcp   open     ssh      syn-ack ttl 64
80/tcp   closed   http     reset ttl 64
443/tcp  filtered https    no-response
8080/tcp filtered http-alt host-prohibited

In this output, port 22 responded with SYN/ACK (confirming an active SSH service), port 80 sent RST (reachable but not listening), port 443 produced no response at all (firewall silently dropped the probe), and port 8080 returned an ICMP host-prohibited message (the firewall explicitly rejected the probe with an ICMP administrative prohibition). The distinction between no-response and host-prohibited tells you whether the firewall is configured to silently drop or actively reject -- a detail that matters for firewall rule analysis.

Firewall and IDS Evasion Techniques

When scanning through firewalls or past intrusion detection systems, Nmap provides several techniques for modifying packet behavior. These are designed for authorized penetration testing and security assessments -- using them to verify that your own defenses are working as intended.

Packet Fragmentation (-f)

The -f flag splits TCP headers across multiple IP fragments, each eight bytes or smaller. Many stateless packet filters and older IDS sensors inspect only the first fragment (which may not contain enough of the TCP header to trigger a rule). Specifying -f twice (-f -f) uses 16-byte fragments. For precise control, --mtu lets you set an exact maximum transmission unit size (must be a multiple of 8):

# Fragment packets into 8-byte chunks
$ sudo nmap -f -sS 10.0.0.50

# Set a specific MTU (must be a multiple of 8)
$ sudo nmap --mtu 24 -sS 10.0.0.50

# Decoy scan: disguise your real IP among 5 random decoys
$ sudo nmap -D RND:5 -sS 10.0.0.50

# Idle (zombie) scan: scan without sending packets from your IP
$ sudo nmap -sI 10.0.0.99 10.0.0.50

# Spoof source port as DNS (port 53) to bypass lazy firewall rules
$ sudo nmap -g 53 -sS 10.0.0.50

# Append random data to packet payloads to avoid signature matching
$ sudo nmap --data-length 25 -sS 10.0.0.50

# Spoof MAC address (useful on local networks)
$ sudo nmap --spoof-mac Dell -sS 10.0.0.50

Decoy Scanning (-D)

Decoy scanning sends probes from multiple spoofed source addresses alongside your real IP. The target's firewall logs show connections from many hosts, making it harder to identify the real scanner. Use RND:5 to generate five random decoy addresses, or specify exact IPs. Use ME to control where your real IP appears in the decoy sequence. A critical detail: decoy hosts should ideally be alive on the network -- if only one source IP in the log is actually reachable, it is trivially identified as the real scanner.

Idle Scan (-sI)

The idle scan is the stealthiest technique Nmap offers. It uses a "zombie" host -- a machine with predictable IP ID sequence numbers -- to probe the target indirectly. Your machine never sends a single packet to the target. The technique works by monitoring how the zombie's IP ID counter increments in response to RST packets from the target. To find suitable zombie hosts, use the ipidseq NSE script: nmap --script=ipidseq -p 80 10.0.0.0/24. Look for hosts reported as having "Incremental" IP ID sequences.

Source Port Manipulation (-g)

Some firewalls are configured to allow traffic from specific source ports -- commonly port 53 (DNS) or port 80 (HTTP) -- based on the assumption that this traffic is legitimate return traffic. The -g (or --source-port) flag sends all probes from a specified source port. If a firewall allows inbound packets from port 53, -g 53 will bypass that rule. This exploits a configuration weakness in stateless firewalls that do not track connection state.

IPv6 Scanning

IPv6 scanning is increasingly important as dual-stack deployments become the norm. Nmap supports IPv6 with the -6 flag, and many organizations have weaker IPv6 firewall rules than their IPv4 equivalents -- sometimes because the IPv6 firewall was configured later or overlooked entirely. The official Nmap documentation notes a case where a target had multiple filtered ports over IPv4 but the same host showed all ports unfiltered over IPv6 (nmap.org/book/firewall-subversion.html).

# Scan an IPv6 address
$ sudo nmap -6 -sS -sV fe80::1%eth0

# Scan an IPv6 hostname
$ sudo nmap -6 -sS -sV ipv6.example.com

# Compare IPv4 and IPv6 exposure on the same host
$ sudo nmap -sS -p- -T4 example.com -oA scan_v4
$ sudo nmap -6 -sS -p- -T4 example.com -oA scan_v6

There are practical differences to be aware of. SYN scan works over IPv6, but TCP connect scan (-sT) is used as the fallback when raw sockets are unavailable -- same as IPv4. OS detection over IPv6 is supported but has a smaller fingerprint database. UDP scanning works over IPv6 but is subject to the same ICMP rate-limiting that slows IPv4 UDP scans. The most actionable takeaway: always scan both protocols during security assessments. A host that is well-firewalled on IPv4 may have services exposed on its IPv6 interface.

Comparing Scans Over Time with Ndiff

Nmap ships with ndiff, a tool that compares two XML scan results and reports what changed. This is essential for change management, baseline monitoring, and detecting unauthorized services. If a new port appears on a production server between weekly scans, ndiff will surface it immediately.

# Run a baseline scan
$ sudo nmap -sS -sV -oX baseline.xml 10.0.0.0/24

# Run the same scan a week later
$ sudo nmap -sS -sV -oX current.xml 10.0.0.0/24

# Compare the two scans
$ ndiff baseline.xml current.xml

# Output shows changes:
-Host 10.0.0.22 is up
+Host 10.0.0.22 is down

 Host 10.0.0.50:
+22/tcp  open  ssh  OpenSSH 9.6
+8443/tcp open  https-alt  nginx 1.26

The minus sign indicates something that was present in the baseline but is now gone (host 10.0.0.22 went down). The plus sign indicates something new (ports 22 and 8443 appeared on host 10.0.0.50). Automating this comparison with cron and a notification script gives you a lightweight, continuous network monitoring system without deploying a full vulnerability management platform. For best results, always use -oX (XML output) for ndiff input -- the grepable and normal formats are not supported.

Legal and Ethical Considerations

Unauthorized port scanning is illegal in many jurisdictions. In the United States, the Computer Fraud and Abuse Act (CFAA, 18 U.S.C. 1030) criminalizes unauthorized access to computer systems, and courts have considered port scanning as potential evidence of intent in broader unauthorized access cases. The UK's Computer Misuse Act 1990 has similar provisions. In the EU, the Directive on Attacks Against Information Systems (2013/40/EU) establishes criminal penalties for unauthorized access attempts across member states. A note on the ongoing debate: you will find conflicting opinions online about whether port scanning alone is illegal. Some argue that sending a SYN packet to a publicly reachable port is no different from knocking on a door, and point to the absence of U.S. case law that has convicted someone solely for port scanning with no subsequent intrusion. Others counter that certain jurisdictions treat unauthorized scanning as a precursor act that establishes intent, and that scanning networks you do not own can violate terms of service or acceptable use policies even where criminal statutes do not explicitly address it. The practical reality is that intent, scope, and jurisdiction matter enormously. This guide takes the conservative position: always get written authorization before scanning, because the legal landscape is inconsistent across jurisdictions, and proving "I only scanned" is a defense you do not want to need.

For legitimate security assessments, written authorization should specify the exact IP ranges in scope, the time window for testing, the scan types permitted, and who to contact if something goes wrong. Many organizations use a formal "rules of engagement" document that both the assessment team and the asset owner sign before any scanning begins.

Privileges and Permissions

Many of Nmap's scan types require raw socket access, which means root privileges on Linux. SYN scans, OS detection, UDP scans, and all scans that craft custom packets need sudo. TCP connect scans work without elevated privileges because they use the kernel's connect() system call.

There is a middle ground between running Nmap as root and running it unprivileged. Linux capabilities allow granting specific permissions without full root access. The CAP_NET_RAW capability is what Nmap needs for raw socket operations, and CAP_NET_ADMIN is required for certain network interface operations. You will find guides online that recommend only CAP_NET_RAW. In practice, CAP_NET_RAW alone is sufficient for SYN scanning and OS detection on many systems, but certain operations -- including some interface-level queries that Nmap performs during route calculation and the --spoof-mac feature -- require CAP_NET_ADMIN. If you set only CAP_NET_RAW and encounter errors during scanning, CAP_NET_ADMIN is likely the missing permission. We include both here because it is the more reliable approach and matches the capability set Nmap requests when run as root. You can assign these to the Nmap binary using setcap:

After setting capabilities, unprivileged users can run SYN scans and OS detection without sudo. This approach follows the principle of least privilege -- the Nmap binary gets only the specific kernel permissions it needs rather than unrestricted root access. To verify the capabilities are set, run getcap /usr/bin/nmap. To remove them later: sudo setcap -r /usr/bin/nmap. Note that this grants the capability to all users who can execute the binary, so evaluate whether that is appropriate for your environment.

"Fixing a hole is far more effective than trying to hide it."

-- Gordon "Fyodor" Lyon, Nmap Network Scanning, Nmap Project, 2009 (nmap.org/book)

# This fails without root -- SYN scan needs raw sockets
$ nmap -sS 192.168.1.10
TCP SYN Stealth Scan requires root privileges.

# Run with sudo
$ sudo nmap -sS 192.168.1.10

# Connect scan works without root but is slower
$ nmap -sT 192.168.1.10

Details Even Experienced Users Often Miss

This section collects precise technical facts that are buried in Nmap's source code, data files, and official documentation but rarely surface in guides. Each one can materially change how you plan and interpret scans.

The Port Frequency Data Is from 2008

Nmap's nmap-services file -- the data that drives --top-ports, -F, and the default 1,000-port scan -- was compiled by Fyodor during the summer of 2008 by scanning tens of millions of Internet hosts, supplemented with enterprise scan data (nmap.org/book/nmap-services.html). The frequency values have not been re-derived from a fresh Internet-wide scan since then. This means the default top-1,000 list reflects 2008-era service deployment patterns. Services that have become common since then (like port 6443 for Kubernetes API servers, or port 8443 for HTTPS-alt on cloud load balancers) may not rank as high as their current real-world prevalence warrants. You can inspect the data yourself: sort -r -k3 /usr/share/nmap/nmap-services | head -20 shows the top 20 ports by frequency. HTTP on port 80 has a prevalence of 0.484143, meaning it was found open on roughly 48% of scanned hosts.

The Exact Coverage Numbers for --top-ports

According to Nmap's official performance documentation (nmap.org/book/performance-port-selection.html), the top 10 TCP ports cover approximately 50% of all observed open TCP ports. The default top-1,000 scan covers a far higher percentage, but for UDP the picture is very different: to reach 90% coverage of open TCP ports, you need only 576 ports, but to reach 90% coverage of open UDP ports, you need 11,307 ports. This is why UDP scanning is fundamentally harder to scope correctly -- the service distribution is much flatter. Of the 8,299 TCP ports named in nmap-services, only 4,260 have non-zero prevalence values. The remaining 4,039 have never been observed open in the dataset.

Port Order Randomization and Why It Matters

By default, Nmap randomizes the order in which it scans ports. This is not mentioned in many guides but has security implications: sequential scanning (ports 1, 2, 3, 4...) is trivially detectable by IDS signatures that look for sequential probe patterns. Nmap's randomization defeats these signatures. However, certain commonly accessible ports are moved to the beginning of the queue for efficiency -- Nmap wants to find services quickly. The -r flag disables randomization and scans ports in strict numerical order, which is useful for debugging or when you need reproducible packet ordering for analysis. Many users never realize their scans are already randomized.

Custom TCP Flag Scans with --scanflags

The canned scan types (SYN, FIN, NULL, Xmas) are not the only options. The --scanflags option lets you set arbitrary TCP flags on probe packets. You can combine any of URG, ACK, PSH, RST, SYN, and FIN in any order. For example, --scanflags SYNFIN sends packets with both SYN and FIN set simultaneously -- a combination that never occurs in normal TCP communication and can produce unexpected responses from certain TCP stack implementations. You must also specify a base scan type (like -sS or -sF) to tell Nmap how to interpret responses. This is an advanced technique for firewall rule probing and TCP stack fingerprinting that goes beyond the standard scan types.

# Custom SYN+FIN scan (anomalous flag combination)
$ sudo nmap --scanflags SYNFIN -sS -p 80,443 10.0.0.50

# Scan only ports with prevalence above 0.01 (found open on 1%+ of hosts)
$ sudo nmap --port-ratio 0.01 10.0.0.50

# View exact port frequency data
$ sort -r -k3 /usr/share/nmap/nmap-services | head -20

# Bypass RST rate limiting for faster scanning of Linux targets
$ sudo nmap -sS --defeat-rst-ratelimit -T4 -p- 10.0.0.50

# Window scan: detects open vs closed on some systems via RST window size
$ sudo nmap -sW -p 80,443,8080 10.0.0.50

# SCTP INIT scan (for telephony and ICS networks using SCTP)
$ sudo nmap -sY -p 2905,3868,7626 10.0.0.50

--defeat-rst-ratelimit: Bypassing Linux's RST Throttling

When scanning Linux targets, you may notice that a full 65,535-port scan returns many ports as filtered even when they are actually closed. This happens because the Linux kernel rate-limits outgoing RST packets (controlled by net.ipv4.tcp_rst_ratelimit in sysctl, defaulting to a half-second interval in many distributions). When Nmap's probes arrive faster than the target can send RSTs, the excess probes get no response and are classified as filtered. The --defeat-rst-ratelimit flag tells Nmap to treat this specific pattern (no response during a fast scan) as closed rather than filtered. This dramatically speeds up full-port scans of Linux hosts and produces more accurate results, but should only be used when you are confident the target is a Linux system subject to RST rate-limiting rather than an actual firewall.

Window Scan (-sW) and SCTP Scanning (-sY, -sZ)

Window scan is an extension of ACK scan that examines the TCP window size field in RST response packets. On certain TCP implementations (notably older BSDs and some embedded systems), the window size in RST packets differs between open and closed ports -- open ports return a positive window size while closed ports return zero. This allows Nmap to distinguish open from closed ports in situations where ACK scan can only determine filtered vs. unfiltered. It does not work against all targets, but when it does, it provides information that no other scan type can.

SCTP (Stream Control Transmission Protocol) scanning is relevant for telephony infrastructure, VoIP systems, and industrial control networks. SCTP INIT scan (-sY) is analogous to TCP SYN scan -- it sends an INIT chunk and waits for an INIT-ACK (open) or ABORT (closed). SCTP COOKIE ECHO scan (-sZ) is the stealthier variant: open ports silently drop the COOKIE ECHO chunk while closed ports respond with ABORT. Common SCTP ports include 2905 (M3UA), 3868 (Diameter), and 7626 (SUA). If you have never scanned for SCTP, you may have services exposed that have never appeared in any of your TCP/UDP scan results.

Version Detection Internals: Probe Intensity and the Null Probe

When Nmap runs version detection (-sV), it does not simply connect and read. It follows a staged probing strategy defined in the nmap-service-probes file. The first probe is always the "NULL probe" -- Nmap connects to the port and waits up to six seconds for the service to send a banner unprompted. Many services (SSH, SMTP, FTP, MySQL) send identification banners immediately on connection, so this zero-cost probe catches a large percentage of services without sending any data at all. If the NULL probe fails, Nmap escalates to active probes at increasing intensity levels. The default intensity of 7 (on a 0-9 scale) runs probes likely to match common services while skipping rare or slow probes. Setting --version-intensity 0 runs only the NULL probe, which is the fastest possible version detection -- useful for quick banner grabs on large networks where you only care about services that self-identify.

Under the Hood: What Nmap Sends on the Wire

Understanding Nmap at the packet level separates operators who run commands from operators who understand results. Here is exactly what happens during a default privileged scan of a single host.

When you run sudo nmap 192.168.1.10, Nmap first checks whether the target is on the same Layer 2 segment. If it is, Nmap sends an ARP request to resolve the target's MAC address -- ARP discovery on local networks is near-instantaneous and completely reliable, which is why Nmap prefers it over ICMP or TCP probes for local targets. If the target is on a remote segment, Nmap sends four parallel discovery probes: an ICMP echo request (type 8), a TCP SYN to port 443, a TCP ACK to port 80, and an ICMP timestamp request (type 13). The rationale behind this combination is coverage -- ICMP probes catch hosts that allow ping, the SYN to 443 catches hosts behind stateful firewalls that allow HTTPS, and the ACK to 80 catches hosts behind stateless firewalls that do not track connection state.

Once the target is confirmed up, the SYN scan phase begins. For each of the 1,000 default ports, Nmap crafts a raw TCP packet with the SYN flag set, a randomized source port, and a specific IP identification value that Nmap uses internally to match responses. The kernel on the scanning machine does not know about these half-open connections -- Nmap operates below the kernel's TCP stack using raw sockets. When a SYN/ACK comes back, the kernel automatically sends RST (because it has no record of the SYN), which is exactly the behavior Nmap relies on to keep connections half-open. This is why SYN scanning requires root: creating raw IP packets with arbitrary flags bypasses the normal connect() system call.

You can observe this process directly using tcpdump alongside your scan:

# Terminal 1: capture Nmap's packets
$ sudo tcpdump -i eth0 -nn host 192.168.1.10 and tcp

# Terminal 2: run the scan
$ sudo nmap -sS -p 22,80,443 192.168.1.10

# tcpdump output shows the half-open handshake:
10:42:01.123 IP 192.168.1.5.54321 > 192.168.1.10.22: Flags [S], seq 12345
10:42:01.124 IP 192.168.1.10.22 > 192.168.1.5.54321: Flags [S.], seq 67890, ack 12346
10:42:01.124 IP 192.168.1.5.54321 > 192.168.1.10.22: Flags [R], seq 12346

That three-packet exchange -- SYN, SYN/ACK, RST -- is the signature of a half-open SYN scan. The term "half-open" is used throughout Nmap's documentation and the broader security community, but it is technically imprecise. In TCP, a half-open connection occurs when one side has sent SYN and received SYN/ACK but the three-way handshake has not completed with the final ACK. In a SYN scan, that final ACK never arrives -- the scanner's kernel sends RST immediately, so the connection never truly reaches the half-open state from the target's perspective. A more precise description is "incomplete handshake scan." Despite this, "half-open" is the established term in Nmap's own source code and reference guide, and it communicates the core concept effectively: the connection is started but intentionally never finished. We use it here because it matches the terminology you will encounter in Nmap's documentation and every major reference that discusses it. The connection never fully establishes, so many application-level logging systems never record it. Compare this to a connect scan (-sT), which produces SYN, SYN/ACK, ACK (full handshake), followed by the application receiving the connection and potentially logging it before Nmap closes the socket.

"These ports represent potential communication channels."

-- Gordon "Fyodor" Lyon, "The Art of Port Scanning," Phrack Magazine Issue 51, September 1, 1997 (nmap.org/p51-11.html)

Sources and References

All technical claims in this guide are verifiable against the following primary sources:

• Nmap Official Reference Guide -- nmap.org/book/man.html -- The authoritative documentation for all Nmap command-line options, scan types, and behaviors.
• Nmap Changelog -- nmap.org/changelog.html -- Complete release history including version 7.99 (March 26, 2026), 7.98 (August 21, 2025), 7.97 (May 12, 2025), 7.96 (May 1, 2025), and 7.95 (April 23, 2024) with detailed feature and fix descriptions.
• NSE Documentation Portal -- nmap.org/nsedoc -- Full documentation for all 612 NSE scripts and 139 NSE libraries, including category assignments and usage examples.
• Nmap Scripting Engine Chapter -- nmap.org/book/nse.html -- Detailed documentation of NSE architecture, script categories, and the Lua scripting interface.
• "The Art of Port Scanning" -- nmap.org/p51-11.html -- Fyodor's original September 1, 1997 Phrack Magazine article (Issue 51, Article 11) that introduced Nmap.
• Nmap Network Scanning: The Official Nmap Project Guide -- nmap.org/book -- The complete book by Gordon "Fyodor" Lyon covering installation, host discovery, port scanning, OS detection, and NSE in depth.
• RFC 793 (Transmission Control Protocol) -- rfc-editor.org/rfc/rfc793 -- The original TCP specification that defines port state behaviors exploited by FIN, NULL, and Xmas scans.
• RFC 9293 (Transmission Control Protocol) -- rfc-editor.org/rfc/rfc9293 -- The August 2022 update that formally obsoletes RFC 793 while preserving the same port-state behavior relevant to Nmap scan techniques.
• Well Known Port List: nmap-services -- nmap.org/book/nmap-services.html -- Documentation of Nmap's port frequency data, derived from Internet-wide scanning during the summer of 2008.
• Port Selection for Speed -- nmap.org/book/performance-port-selection.html -- Coverage statistics for --top-ports values across TCP and UDP, including the data behind the default 1,000-port scan.

Wrapping Up

Nmap's strength is its depth. A single tool handles everything from a quick ping sweep of a /24 to a full vulnerability assessment of a hardened server. The key concepts to internalize are the scan types and when to use each one, the difference between privileged and unprivileged scanning, how version detection and OS fingerprinting extract actionable intelligence from open ports, and how NSE transforms Nmap from a port scanner into an extensible assessment platform.

Start with simple scans and build up. A -sS -sV scan with -oA output covers the vast majority of day-to-day reconnaissance work. Add -O when you need OS details, --script=vuln when you need vulnerability data, and -p- when you need a complete port inventory. The more you understand about what each flag does at the packet level, the more precisely you can tune your scans for speed, stealth, or thoroughness depending on the situation.

What sets Nmap apart from the dozens of network scanning tools that have appeared since 1997 is the combination of packet-level control with an extensible scripting engine -- you can craft exactly the probe you need, analyze the response at whatever granularity the situation demands, and automate follow-up analysis through Lua scripts that integrate directly with the scan results. The Nmap reference guide (nmap.org/book/man.html) and the official book Nmap Network Scanning remain the authoritative references for going deeper on any topic covered here.

How to Install and Run Your First Nmap Scan on Linux

Step 1: Install Nmap from your distribution's package manager

On Debian and Ubuntu systems, run sudo apt update followed by sudo apt install nmap to install Nmap and its dependencies including the NSE script library. On RHEL, Fedora, or Rocky Linux, use sudo dnf install nmap instead. Verify the installation by running nmap --version.

Step 2: Run a basic host discovery and port scan

Execute sudo nmap followed by your target IP address or hostname to perform a default SYN scan of the 1,000 most common ports. Nmap will report which ports are open, closed, or filtered, along with the service name associated with each port number.

Step 3: Enable service version detection and OS fingerprinting

Add the -sV flag for service version detection and the -O flag for operating system fingerprinting. You can combine these with script scanning using the -A flag, which enables version detection, OS detection, default NSE scripts, and traceroute in a single pass.

Frequently Asked Questions

Does Nmap require root privileges on Linux?

Some scan types require root privileges and some do not. SYN scans, OS detection, and UDP scans all need raw socket access and must be run with sudo or as root. TCP connect scans work without elevated privileges because they use the operating system's standard connect() system call instead of crafting raw packets.

What is the difference between a SYN scan and a TCP connect scan in Nmap?

A SYN scan sends a SYN packet and waits for a SYN/ACK response but never completes the three-way handshake, which makes it faster and less likely to be logged by the target. A TCP connect scan completes the full three-way handshake using the operating system's connect() call, which takes longer and is more visible in server logs. SYN scans require root privileges while connect scans do not.

How do I update Nmap's NSE script database on Linux?

Run the command sudo nmap --script-updatedb to rebuild the script database. This is necessary after adding or removing NSE scripts from the scripts directory, or after changing the category assignments of any script. The script database file is located at scripts/script.db within the Nmap data directory.

What is the latest version of Nmap as of 2026?

The latest stable release is Nmap 7.99, released on March 26, 2026. It includes updated IPv4 and IPv6 OS fingerprints, upgraded core libraries (OpenSSL 3.0.19, libpcap 1.10.6, libpcre2 10.47), Windows VPN adapter scanning support, a reverse-DNS performance fix, and brings the total NSE script count to 612.

How many NSE scripts does Nmap include?

As of Nmap 7.99, the NSE library includes 612 scripts and 139 libraries organized into 14 categories: auth, broadcast, brute, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version, and vuln. The full list with documentation is available at nmap.org/nsedoc/.

What does filtered mean in Nmap output?

Filtered means Nmap could not determine whether the port is open because a firewall or network obstacle prevented the probe from reaching the port. Nmap received either no response at all or an ICMP unreachable error. Use the --reason flag to see exactly why each port was classified the way it was -- it will show no-response for silently dropped packets or host-prohibited for explicit ICMP rejections.

Can Nmap scan IPv6 addresses?

Yes. Add the -6 flag to any Nmap command to scan over IPv6 instead of IPv4. SYN scan, version detection, and NSE scripts all work over IPv6. OS detection is supported but has a smaller fingerprint database than IPv4. Always scan both protocols during security assessments because IPv6 firewall rules are often weaker than their IPv4 equivalents.