How to scan UDP ports with Nmap and why UDP scans are slow

UDP has no handshake to observe

TCP scanning works because a host must answer a SYN with either SYN-ACK or RST. UDP has no handshake. Nmap sends a datagram and waits. A service may reply if the probe looks valid. A closed port usually triggers an ICMP port unreachable message. An open port that does not like the probe often says nothing at all, which looks exactly like a firewall dropping the packet.

That is why UDP results include open|filtered, and why the scan is slow. Linux, for example, rate-limits ICMP port unreachable messages to about one per second by default, so Nmap has to slow down or it will misread missing ICMP as filtering.

Protocol-specific payloads help

For well-known ports such as 53 (DNS), 123 (NTP), 161 (SNMP), and 500 (IKE), Nmap sends a payload that looks like a real request instead of an empty datagram, so a live service is more likely to answer. Adding -sV goes further and runs version probes against open|filtered ports to coax a response, turning many of them into a definite open.

The UDP services worth knowing in a defensive inventory are DNS, NTP, SNMP, TFTP, NetBIOS name service on 137, SSDP on 1900, and mDNS on 5353. Several of them leak configuration or can be abused for reflection traffic when exposed to the internet.

Lab: a UDP scan that finishes

Install a DNS resolver or an SNMP agent on a lab VM so you have something to find. Then scan the top 50 UDP ports with version detection. Compare the result to a plain -sU of the same ports. Expect the plain scan to show several open|filtered entries that -sV resolves to open with a service name.

Time both runs with the time command. Scanning all 65,535 UDP ports on one host can take many hours with default settings, so in practice you scan the top ports and any you specifically care about.

Snippet

sudo apt install snmpd   # on the lab VM
sudo nmap -sU --top-ports 50 192.168.56.101
sudo nmap -sU -sV --top-ports 50 192.168.56.101
sudo nmap -sU -p 53,123,161,1900 --reason 192.168.56.101

What a defender does with the result

An open SNMP port with the community string “public” is one of the most common findings on internal networks. It can reveal interface lists, routing tables, and running software. Either disable SNMP, restrict it to a management network, or move to SNMPv3 with authentication.

For internet-facing hosts, check that NTP, DNS, SSDP, and memcached on UDP 11211 are not answering the world. Open reflectors get used in amplification attacks against third parties, and the traffic bill lands on you.

Diagram

Three UDP outcomes and what caused them

The reply decides the state; silence is the ambiguous one.

UDP reply
A service answered the payload. State: open.
ICMP port unreachable
The host is reachable and nothing is bound. State: closed.
Silence
Either a firewall dropped it or an open service ignored a probe it did not understand. State: open|filtered.

Check yourself

1. A UDP probe gets no response at all. Which state is reported?

2. Why are full UDP scans so slow on Linux targets?

3. You find SNMP on UDP 161 answering with the community “public”. What is the fix?