Port Scanning with Nmap

A single IP address can run dozens of services at once — a web server, a mail server, a database, a remote-login daemon. To keep them separate, the transport layer gives every host 65,535 numbered ports for TCP and another 65,535 for UDP. Picture them as numbered doors on the front of the machine: a web server listens at door 80 or 443, SSH at door 22, DNS at door 53. A port scan is simply you walking down the hallway, knocking on each door, and writing down which ones answer.

TCP is the connection-oriented protocol — it sets up a session with a handshake before any data flows, which gives a scanner a clear, reliable signal to read. UDP is connectionless: it fires packets with no handshake and often no reply at all, which is exactly what makes UDP scanning slow and ambiguous. Most of what follows is about TCP, with UDP called out where it differs.

When Nmap finishes probing a port, it does not just say "open" or "closed." It reports one of six states, and each one is a different piece of intelligence:

• open — an application is actively listening and accepting connections. This is the state you are hunting: every open port is a potential way in.
• closed — the port is reachable and the host replied, but nothing is listening there right now. Useful negative information: the host is up and not firewalled on that port.
• filtered — Nmap got no answer, or got an error that hides the truth. A firewall or filter is almost certainly dropping the probe before it reaches the port, so Nmap cannot tell whether anything is listening. Filtered usually means "something is blocking you."
• unfiltered — the port is reachable, but this particular scan cannot decide whether it is open or closed (you see this with the ACK scan, which is built to map filtering rather than find services).
• open|filtered — Nmap cannot tell open from filtered because no response is the expected behavior for both. Common with UDP and the stealth scans, where silence is ambiguous.
• closed|filtered — Nmap cannot tell closed from filtered. Rare, and tied to specific scan types like the IP ID idle scan.

Nmap can probe a port in several different ways, and the technique you pick changes the speed, the stealth, and even the meaning of the result. Each one sends a different combination of TCP flags and interprets the reply differently. The table below covers the techniques you will reach for most often.

Two of these stand apart. Connect and SYN are your everyday workhorses for finding open TCP ports; which one runs depends mostly on whether you have root. The FIN/Xmas/Null and ACK scans are situational — you reach for them when you are fighting a firewall or trying to stay quiet, not for routine discovery.

Because the SYN scan is the default and the one you will run most, it is worth walking through exactly what happens on the wire. A normal TCP connection opens with a three-way handshake: the client sends a SYN, the server answers with SYN/ACK, and the client confirms with an ACK. Only after that third packet is the connection fully established and ready to carry data. The SYN scan deliberately stops short of finishing it.

Here is each possible outcome when Nmap fires a single SYN at a port:

• SYN → SYN/ACK — the port is open. Something is listening and just offered to complete the handshake. Nmap has its answer, so instead of replying with ACK it sends an RST to kill the half-built connection immediately.
• SYN → RST — the port is closed. The host is reachable and up on the network, but no application is listening on that port, so the stack refuses with a reset.
• SYN → (no response) — the port is filtered. The probe vanished. A firewall is most likely dropping the packet silently, so Nmap cannot see past it. After a retransmission or two with no answer, it records the port as filtered.

The trick is that the connection never completes. Many older applications only logged a connection once the handshake finished — and since the SYN scan resets before that point, it left no entry in those logs. That is where the name "half-open" comes from, and why it was historically called a stealth scan. In practice modern firewalls and intrusion-detection systems watch for exactly this pattern, so it is far less invisible than it once was, but it remains faster and lighter than a full Connect scan, which is why it stays the default.

By default, Nmap does not scan all 65,535 ports — it scans the 1,000 most common ones, a curated list of the ports services actually tend to use. That default is a deliberate trade-off: it finds the overwhelming majority of services quickly, but it is not exhaustive. A service deliberately moved to an unusual high port will sit there unseen. Knowing how to widen or narrow the range is part of scanning well:

• -p- — scan all 65,535 ports. The thorough choice, and much slower, but the only way to be sure you have not missed a service hiding on a high port.
• -p 22,80,443 — scan a specific list of ports. Fast and targeted when you already know what you are looking for. Ranges work too, for example -p 1-1024.
• --top-ports 100 — scan the N most common ports. A tunable middle ground between the default 1,000 and a full sweep.
• -F — fast scan, checking only the top 100 ports. The quickest first look at a host.

The tension is always speed versus coverage. Scanning the default top-1000 is quick and catches almost everything; scanning every port with -p- is slow but complete. The mistake to avoid is assuming the fast scan is the whole picture — skipping -p- can hide a service deliberately tucked away on a high port, which is exactly where an attacker would put something they did not want found. A common rhythm is a fast scan first to get your bearings, then a full -p- sweep in the background to be certain.

Every scan you run is a balance of three pulls that fight each other: speed, stealth, and accuracy. Push for speed — faster timing, fewer ports, fewer retries — and you risk missing services or misreading filtered ports as closed. Push for stealth — slow timing, fragmented packets, exotic scan types — and a thorough scan can take hours. Push for accuracy — full port range, multiple retransmissions, careful timing — and you trade away both speed and quiet. There is no universal "best" scan; there is only the right scan for what you are trying to learn and how much noise you can afford to make.

Whatever the balance, remember what a port scan actually gives you: an open port is only half the story. Knowing that port 8080 is open does not tell you whether it runs a web server, a proxy, or some custom application — let alone which version, and whether that version has a known vulnerability. An open door is an invitation to look closer, not a conclusion.

That is exactly where the next lesson goes: service and version enumeration — getting Nmap to fingerprint the software behind each open port so you know precisely what you are dealing with. Before you move on, put this lesson into practice. Run real scans against safe targets in the Port Scanning Lab, and assemble your own commands flag by flag in the Nmap Scan Builder.