Nmap: The Complete Guide to Network Scanning

Nmap (Network Mapper) is the tool every network engineer eventually reaches for when the question stops being "is the link up?" and becomes "what is actually listening on that box, and should it be?" It is free, open source, and it does one thing extraordinarily well: it sends carefully crafted packets at a target and infers, from the replies, which hosts are alive, which ports are open, what services and versions are running, and often what operating system sits underneath. That makes it as useful for inventorying your own network and verifying firewall rules as it is for the reconnaissance phase of a security assessment.

This is the complete guide to Nmap on PingLabz. It covers the whole workflow, from finding live hosts to fingerprinting services, reading the firewall's behavior, scripting with the NSE engine, tuning scan speed, and saving results you can parse later. Every example on this page and across the cluster is real output captured live in a Cisco Modeling Labs topology (Cisco routers, a switch, an nginx server, Linux hosts, and an ASA firewall fronting a DMZ) and against a real Linux host and the public scanme.nmap.org target. Nothing here is faked. The Nmap version throughout is 7.95.

What Nmap actually solves

On a network you own, Nmap answers questions you cannot answer from a routing table or a switch's MAC table. Which of these 254 addresses are live right now? Did that server really stop listening on telnet after the hardening change, or is it still up? Is the new firewall rule dropping what you think it is dropping? Which build of nginx is on the DMZ box, and is it old enough to have a known CVE? Is there a service sitting on a high port that nobody documented? Those are inventory, verification, and audit tasks, and Nmap is the fastest way to get ground truth.

The same capabilities, pointed at a network you do not own, are reconnaissance. That is why Nmap has a reputation as a "hacking tool." The mechanics are identical; only authorization changes. Scan your own lab, your employer's network with permission, and public targets that explicitly invite it (like scanme.nmap.org). Scanning networks you have no authority over is, in many jurisdictions, illegal, and it is always bad manners.

How a scan works, from the top down

A default Nmap run is a pipeline. First it does host discovery (also called a ping scan) to decide which targets are worth scanning. Then it does port scanning against the live hosts to find open ports. Optionally it layers on version detection to name the service behind each port, OS detection to guess the operating system, and the Nmap Scripting Engine (NSE) to run deeper probes. Finally it prints or saves the results in the format you asked for. Each stage is a deep topic in this cluster, and you can turn any stage on or off.

Here is the smallest useful command, the one you will type more than any other:

$ nmap -sV 10.10.10.21
PORT   STATE SERVICE VERSION
80/tcp open  http    nginx 1.29.8

That single line found the host, scanned its top 1000 ports, and identified the exact web server build. From there the rest of the toolkit is about doing each of those steps more deliberately.

The scan stages at a glance

Host discovery: who is even there

Step one of a scan is not ports, it is figuring out which addresses are live. On a local subnet Nmap does this with an ARP sweep, which is fast and cannot be blocked by a host firewall (ARP is layer 2). Here is a real ping scan of a lab subnet:

$ nmap -sn 10.10.10.0/24
Nmap scan report for 10.10.10.1
Host is up (0.0031s latency).
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap scan report for 10.10.10.21
Host is up (0.012s latency).
MAC Address: 52:54:00:A2:2F:84 (QEMU virtual NIC)
...
Nmap done: 256 IP addresses (6 hosts up) scanned in 1.98 seconds

Six live hosts in under two seconds, and the MAC OUI already profiles them (AA:BB:CC is the burnt-in Cisco IOL range, 52:54:00 is a QEMU/KVM Linux VM) before a single TCP packet is sent. The catch is that plenty of hardened hosts drop the ping probes Nmap uses remotely, so Nmap decides they are down and never scans them. The fix is -Pn, which skips discovery and scans anyway. This whole stage, including the probe types (-PS, -PA, -PU, -PE) and when to reach for -Pn, is covered in the deep dive on Nmap host discovery and ping sweeps.

Open, closed, and filtered: the most important table in Nmap

Every port Nmap reports lands in one of a few states, and confusing them is the single most common beginner mistake. The cleanest way to see all three at once is to scan a host through a firewall. This is a real scan through a Cisco ASA whose policy permits only TCP 22 and TCP 80 to the target:

$ nmap -sS -p 22,23,80,443 10.10.20.32
PORT    STATE    SERVICE
22/tcp  open     ssh
23/tcp  filtered telnet
80/tcp  closed   http
443/tcp filtered https

The difference between closed and filtered is the difference between "the host is reachable and rejected me" and "a device in the path ate my packet." Learning to read that distinction is what separates guessing from knowing. The full treatment, including the SYN scan versus the TCP connect scan and how to choose your port set, is in Nmap port scanning: SYN vs connect and port states.

Scan technique reference

Nmap ships with a whole family of scan techniques beyond the default SYN scan. Each crafts a different probe to answer a different question.

Which one to reach for, and why the stealth scans behave so differently on a Cisco IOS device than on a Linux host, is the subject of Nmap scan types explained. If you need the connectionless side, the ambiguity of open|filtered and how to make it bearable is covered in Nmap UDP scanning.

Fingerprinting: naming services and operating systems

An open port is a start; a named, versioned service is a target. Version detection sends probes and matches the replies against Nmap's service database. On the lab it turns bare ports into exact builds:

$ nmap -sV 10.10.10.1
PORT   STATE SERVICE VERSION
22/tcp open  ssh     Cisco SSH 1.25 (protocol 2.0)
23/tcp open  telnet  Cisco IOS telnetd
Service Info: OS: IOS; Device: switch; CPE: cpe:/o:cisco:ios

That is no longer "a device with SSH and telnet." It is a Cisco IOS device, and the CPE string feeds straight into a CVE lookup. The full workflow, including probe intensity and banner grabbing, is in Nmap version detection and banner grabbing. The companion technique, guessing the OS from TCP/IP stack behavior (and why it nails a Linux host but shrugs at virtual Cisco gear), is in Nmap OS detection.

The Nmap Scripting Engine

NSE is what turns Nmap from a port scanner into a lightweight vulnerability and enumeration framework. It runs Lua scripts (roughly 600 ship with Nmap) grouped into categories like default, safe, discovery, and vuln. A single -sC runs the default set; --script targets specific ones. Real example against the lab's nginx box:

$ nmap -p80 --script http-title,http-headers,http-methods 10.10.10.21
80/tcp open  http
|_http-title: Welcome to nginx!
| http-methods:
|_  Supported Methods: GET HEAD
| http-headers:
|   Server: nginx/1.29.8

The categories, how to combine scripts with version detection, and the authorization line you should not cross with intrusive scripts are all in the guide to Nmap NSE scripts.

Reading and testing firewalls

Because Nmap can tell filtered from closed, it is a genuinely useful tool for validating that your firewall and IDS do what you think. The ACK scan maps which ports a stateful firewall is filtering; fragmentation, decoys, timing, and source-port tricks let you test whether your controls actually catch evasive traffic. This is a defensive exercise as much as an offensive one: if a decoy scan or a fragmented probe sails through, your IDS has a gap. The techniques, with real packet traces and honest results (one fragmentation scan got dropped in transit, exactly the outcome you want to see from a good filter), are in Nmap firewall and IDS evasion. For the firewall side of that conversation, see the Cisco ASA guide.

Speed and output

Two operational concerns round out the toolkit. Timing controls how fast or how quietly you scan: the same top-100 scan can run in 1.37 seconds at -T4 or take 40 seconds at -T2 to stay under an IDS rate threshold. That tradeoff, plus the finer rate controls, is in Nmap timing and performance. Output controls what you keep: normal, XML, and grepable formats each suit a different consumer, and -oA saves all three at once so you can grep the results into an asset list. That is covered in Nmap output formats and parsing.

Getting Nmap onto your machine

Nmap runs everywhere you are likely to work from. On Debian or Ubuntu it is sudo apt install nmap; on RHEL, Rocky, or Fedora it is sudo dnf install nmap; on macOS use Homebrew with brew install nmap; and on Windows the official self-installer bundles the Npcap driver you need for raw-packet scans. Verify the build with nmap --version and keep it current, because the service and OS fingerprint databases and the NSE scripts all improve with each release. For scripting work you can refresh the script database at any time with nmap --script-updatedb. If you want a target to practice against without any legal grey area, the Nmap project runs scanme.nmap.org specifically so people can point scans at it (a few scans, not a hammering), and every fingerprinting example in this cluster that is not from the lab was captured against exactly that host.

Minimum viable scan on your own network

If you take one command away from this page, make it a version scan of your own subnet with output saved for later:

$ nmap -sV -oA baseline-$(date +%F) 10.10.10.0/24

That gives you a dated inventory of every live host, its open ports, and the service versions behind them, in all three output formats. Run it again next month and diff the two with ndiff to catch a new listener before an attacker does. Everything else in this cluster is a refinement of that idea.

The full Nmap cluster, in reading order

Fundamentals

Start with host discovery to find live hosts, then port scanning for the SYN scan, port selection, and the open/closed/filtered states. Round out the mechanics with the full set of scan types (ACK, FIN, Null, Xmas, Window, Maimon).

Fingerprinting

Use version detection to name services and grab banners, OS detection to guess the operating system, and UDP scanning for the services TCP scans miss.

Depth and operations

Go deeper with NSE scripts, test your controls with firewall and IDS evasion, tune speed with timing and performance, and keep your results with output formats and parsing.

Frequently asked questions

Is it legal to use Nmap?

Nmap itself is legal software, and scanning networks you own or are explicitly authorized to test is fine. Scanning systems without permission may violate computer misuse laws depending on your jurisdiction, even if you cause no harm. Practice on your own lab, on networks where you have written authorization, and on public targets like scanme.nmap.org that invite scanning.

Why does Nmap need root or administrator privileges?

The default SYN scan (-sS), OS detection, and many advanced techniques craft raw packets, which requires elevated privileges. Without them, Nmap falls back to the TCP connect scan (-sT), which uses the operating system's normal connection calls and needs no special rights but is slower and more likely to be logged.

What is the difference between closed and filtered ports?

A closed port means the host is reachable and actively refused the connection with a RST, so nothing is listening there. A filtered port means a firewall or filter silently dropped the probe and you got no reply, so you cannot tell whether a service is behind it. Closed is the host talking to you; filtered is a device in the path staying silent.

How do I make Nmap scan faster?

The biggest lever is the number of ports: scan -F (top 100) or a specific -p list instead of all 65535. After that, the -T4 timing template speeds things up on reliable networks, and --min-rate forces a packets-per-second floor. Be aware that faster scans are noisier and more likely to trip an IDS.

Can a target detect an Nmap scan?

Yes. A TCP connect scan completes full handshakes that land in application logs, and any IDS worth its license flags the burst of connection attempts a scan produces. Techniques like slower timing, fragmentation, and decoys exist to reduce that footprint, but no scan is truly invisible against a well-monitored network.

Key takeaways

Nmap is a packet-crafting inference engine: it sends probes and reads the replies to tell you what is alive, what is listening, what version it is, and what the firewall in between is doing. Learn the pipeline (discovery, port scan, version, OS, scripts, output) and you can turn any one stage up or down for the job in front of you. The single most valuable skill is reading port states correctly, because the gap between closed and filtered is the gap between a reachable host and a firewall drop. Ground everything in real output on a network you are allowed to scan, save your results so you can diff them over time, and treat the evasion techniques as a way to audit your own defenses. Work through the cluster above in order and you will have a complete, practical command of the tool. Every article links back here to the complete Nmap guide as your hub.