Port Scanning (Nmap)

Before attacking anything you need to know what is listening on the machine. An open TCP/UDP port is a service waiting for connections, and every service is a potential attack surface. Port scanning is the first step of the whole process, and how you do it shapes what you find: a poor scan leaves services unseen and closes off paths before you even start.

The standard strategy is two phases: a fast sweep of all 65535 ports to discover which ones are open and then, over those (and only those), a slower targeted scan that identifies the service and its version. Discovery is cheap; fingerprinting is expensive, so you only fingerprint what actually exists.

# Phase 1: full sweep of all 65535 TCP ports, fast
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 10.10.10.10

# Phase 2: over the open ports, service + version + default scripts
nmap -p22,80,445 -sCV 10.10.10.10 -oN targetedScan

What each flag does (and why).

• -p- scans all 65535 ports, not just the 1000 most common ones nmap looks at by default. Many labs (and real systems) hide services on high or unusual ports; without -p- you miss them.
• -sS is a SYN or "half-open" scan: it sends the SYN, sees whether it gets SYN/ACK (open) or RST (closed) and never completes the handshake with the final ACK. It is faster and slightly stealthier than a full connect scan (-sT), but it needs root privileges to craft the packets.
• -Pn skips host discovery (the preliminary ICMP ping). Many hosts, especially Windows and anything behind a firewall, drop the ping; without -Pn, nmap would treat them as down and scan nothing. -Pn assumes the host is up and scans anyway.
• -n disables reverse DNS resolution. It adds nothing to a port scan and saves the time (and noise) of querying a DNS server for every IP.
• --min-rate 5000 sets a minimum of packets per second, forcing nmap not to crawl: this is what turns a 65535-port sweep from minutes into seconds. On fragile networks, lower it.
• --open keeps the output to open ports only, dropping the closed/filtered noise.
• -sCV combines -sV (version detection: it interrogates the service to work out the exact product and version) with -sC (the default NSE scripts, which pull HTTP titles, headers, certificates, SMB null sessions...). The result of this phase is what decides the next step: a specific version gets looked up in public exploits, a title reveals a CMS, a jive-* header gives away the real software behind a misleading banner.

The UDP scan: why and when. Services that speak UDP show up in no TCP scan, however complete, so a box can look almost empty while the vector sits there listening. To see them you need -sU:

sudo nmap -sU -n -Pn --top-ports 100 --min-rate 5000 10.10.10.10

It is far slower than TCP, and the reason is the protocol itself: TCP has a handshake, so a SYN always draws a reply (SYN/ACK open, RST closed) and one packet settles the state. UDP has none of that: if the port is open, the service usually will not answer an empty packet, and that silence is identical to a port filtered by a firewall. nmap has to wait for timeouts and retry, and it depends on an ICMP port unreachable arriving to mark something "closed" (a message that is typically rate-limited too). Hence all those open|filtered results: not a flaw in the scan, simply that with no reply there is nothing to tell apart.

That is why you do not sweep all 65535 UDP ports: you fire a --top-ports (100 or 1000) alongside the TCP scan, and look harder if TCP yields no vector. What lives there is worth it: SNMP on 161 (with the public community it leaks users, processes and sometimes credentials), DNS on 53, NTP on 123, TFTP on 69 (no authentication), mDNS on 5353, IKE/IPsec on 500, and the 111 of rpcbind giving away NFS. On a domain controller the 53/123/389 trio is practically a signature.

The practical rule: the short UDP sweep always runs, and when TCP offers no vector, UDP stops being optional.

Why it matters. The scan is the foundation of everything that follows: each open port is an attack hypothesis. Skipping -p- or -Pn is the most common cause of a pentest that stalls "with no vector": the vector was on a port that was never looked at. And the version phase (-sV) is not a formality, it is what turns "there is something on 8080" into "there is a Tomcat 9.0.30 vulnerable to X".

How to detect it. A scan leaves a clear network signature: many connection attempts to numerous or sequential ports from a single IP in a few seconds. The SYN scan (-sS) gives itself away with SYNs that never complete the ACK (half-open connections) and a burst of RSTs; the UDP sweep, with a run of ICMP port unreachable. IDS/IPS (Suricata/Snort/Zeek) ship port-scan thresholds for this, and the firewall logs the many denied ports from the same source. A high --min-rate and -p- make the pattern even more obvious.

Defense. Reduce the surface: expose only the ports you need, filter the rest at the firewall and do not rely on the obscurity of a high port. Version detection feeds on banners: minimizing (or faking) them slows the attacker down, though it does not stop them.