Skip to content

nmap

Every tool in this module so far has answered a question about a machine you already know something about — its own configuration, a name it resolves to, a route to reach it. nmap answers a different kind of question: given a host or a whole range of addresses, what's actually listening, what's running there, and what does that surface look like from the outside? It's the closest thing in this module to what an attacker's first move against a network actually looks like — which is exactly why using it comes with a real legal and ethical line to respect.

Scan only what you're authorized to scan

Port scanning a network you don't own or don't have explicit written permission to test can violate your ISP's acceptable use policy, and in some jurisdictions can violate computer-abuse law even without any resulting damage — nmap's own documentation is direct about this, and recommends getting permission in writing before scanning anything beyond your own infrastructure. The project maintains scanme.nmap.org specifically as a legal target for learning and testing, with a documented, informal limit of a reasonable number of scans a day — every example in this article uses it or a private lab network for exactly that reason.

Installing and a first scan

sudo apt install nmap

nmap scanme.nmap.org

Starting Nmap 7.94 ( https://nmap.org ) at 2026-07-27 09:52 UTC
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.087s latency).
Not shown: 996 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
9929/tcp open  nping-echo
31337/tcp open  Elite

nmap's default scan checks the 1,000 most commonly used TCP ports and reports each one's state. open means something is actively accepting connections there; the Not shown: 996 closed line means the other 996 of the default 1,000 responded but had nothing listening — nmap collapses a long run of the same state into that one summary line rather than printing a thousand rows, most of which would say nothing interesting.

Port states: more than just open or closed

nmap distinguishes six states, though the first three cover almost everything you'll see in practice:

  • open — a service is actively listening and accepted the probe.
  • closed — the port responded (with a TCP RST, or an ICMP message for UDP), but nothing is listening there.
  • filtered — no response came back at all, and nmap can't tell whether that's because nothing's listening or because a firewall silently dropped the probe — the same fundamental ambiguity a silent hop in traceroute leaves unresolved.
  • unfiltered — the port is reachable, but its open/closed state couldn't be determined by the specific scan type used (mainly comes up with the ACK scan, -sA, described below).
  • open|filtered, closed|filtered — nmap narrowed the possibilities but couldn't fully resolve which of two states applies, most often on UDP scans where a lack of response is inherently ambiguous.

The distinction between closed and filtered matters a lot in practice: closed tells you definitively nothing is running there; filtered tells you a firewall is probably in the way and you genuinely don't know what's behind it — the same "timeout versus explicit rejection" signature the firewall article already covered from the defender's side of that same wall.

SYN scan versus connect scan

sudo nmap -sS scanme.nmap.org

The default scan type when running as root is -sS, the SYN scan. It sends a TCP SYN, and if a SYN-ACK comes back, immediately sends an RST instead of completing the handshake with the final ACK — the connection never actually opens at the application level. This needs a raw socket to craft that unusual SYN-then-RST sequence directly, which is why it requires root privileges (or the CAP_NET_RAW capability specifically).

Without root, nmap falls back automatically to -sT, the connect scan, which uses the operating system's ordinary connect() call and completes the full three-way handshake from the TCP deep dive module — a real connection is briefly established and then closed, rather than abandoned mid-handshake. Functionally the two scans report the same open/closed information; the practical difference is that a connect scan's completed connections are far more likely to show up in the target's own application logs, since a real connection actually happened, while a SYN scan's half-open attempts often leave no trace beyond a firewall or IDS specifically watching for that pattern.

Beyond a bare port list: -sV, -O, and -A

nmap -sV -p 22,80 scanme.nmap.org

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu
80/tcp open  http    Apache httpd 2.4.52

-sV goes beyond "something is listening on 80" to actually identify what — it sends a series of protocol-specific probes and matches the responses against a large signature database, which is how it named the exact web server and SSH implementation above rather than just the port number. -p restricts the scan to specific ports, considerably faster than scanning the default thousand when you already know which ones matter.

-O adds OS fingerprinting, inferring the likely operating system from subtle variations in how a target's TCP/IP stack responds to a series of crafted probes — no single feature identifies an OS conclusively, but the combination narrows it down with reasonable confidence. -A bundles version detection, OS detection, script scanning, and a traceroute into one run — convenient for a first broad look at an authorized target, at the cost of being considerably louder and slower than a targeted -sV -p scan.

Verifying a firewall change actually took effect

A team just applied a new firewall rule intended to close public access to a database port that was mistakenly left open. Before trusting the change, they scan from outside the network rather than just re-reading the rule:

nmap -p 5432 -Pn db01.example.internal

PORT     STATE    SERVICE
5432/tcp filtered postgresql

-Pn skips nmap's usual initial host-discovery ping (some hosts are configured to drop ICMP entirely, and without -Pn nmap might otherwise conclude the host is down and refuse to scan it at all — the same "ICMP blocked doesn't mean down" lesson from the ICMP module, applied here to a scanner instead of a person running ping by hand). filtered on 5432 confirms the rule is actually blocking external probes — a materially stronger confirmation than reading the rule file, since it verifies the effect from where an actual external client would sit, catching any mismatch between what the rule was intended to do and what it's actually enforcing on the wire.

Practice exercises

  1. Run nmap scanme.nmap.org and identify which ports are open versus which the summary line collapses as closed.
  2. Explain, in your own words, why a SYN scan is less likely to appear in a target's application logs than a connect scan, even though both report the same open ports.
  3. A scan against an internal host you're authorized to test reports port 443 as filtered rather than closed. What does that specifically tell you about a firewall in the path, that a closed result would not?

Knowing what's open from the outside is one layer. Seeing exactly what's said over an open connection — the actual bytes of a request and a response — is the next, and the tool for it is one you've almost certainly already used without the flag that makes that visible.

Sources