UDP scanning is fundamentally a lie.
Let’s watch Nmap find a UDP service that’s actually there. We’ll scan for the chargen service on UDP port 19. chargen is a simple protocol that just spews out characters, and it’s often used for testing.
sudo nmap -sU -p 19 --reason --open 192.168.1.100
Here’s what Nmap might tell you:
Starting Nmap 7.92 ( https://nmap.org ) at 2023-10-27 10:00 EDT
Nmap scan report for 192.168.1.100
Host is up (0.0020s latency).
PORT STATE SERVICE REASON
19/udp open chargen user
That open state feels pretty definitive, right? Nmap told you it’s open. But here’s the kicker: Nmap doesn’t know if UDP port 19 is open. What it knows is that it didn’t get a "port unreachable" ICMP error back. That’s it.
The UDP protocol is connectionless. When Nmap sends a UDP packet to a port, it’s like dropping a letter in a mailbox with no return address. If the service is listening, it might send a response back. If it’s not, there’s no guarantee anything will happen. Nmap’s UDP scan is essentially probing for the absence of a negative response.
The "REASON" column is your real clue here. user means Nmap sent a UDP packet, and the operating system didn’t respond with an ICMP "Destination Unreachable" message (specifically type 3, code 3). This usually implies the port is open, or at least that there’s no firewall actively blocking it with an ICMP error.
Think about what that means. If Nmap sends a UDP packet to a port and no one replies, it marks it as open. This is because a firewall might be silently dropping packets, or the service might simply not be running. If Nmap does get an ICMP "port unreachable" message back, it marks it as closed. If it gets a UDP response from the service, it also marks it as open.
The problem Nmap solves with UDP scanning is discovering services that might be listening on UDP ports, which are common for things like DNS (port 53), SNMP (port 161), or VoIP protocols. TCP scans are more reliable because TCP’s handshake provides a clear "open" or "closed" signal. UDP lacks this inherent confirmation.
Nmap’s UDP scan has a few key levers you can pull:
-sU: This is the fundamental flag to tell Nmap to perform a UDP scan.--reason: Crucial for UDP scans. It shows why Nmap decided a port is open, closed, or filtered. For UDP, the "reason" will often beno-response(implying open or filtered) orport-unreachables(implying closed).-p <portlist>: Specify the UDP ports you want to scan. You can scan all ports (-p-) but be aware UDP scans are slower than TCP.-sV: Service version detection. This is particularly useful for UDP because the state itself is ambiguous.sVtries to elicit a protocol-specific response to identify the service.
Here’s a more complex example, scanning for DNS (port 53) and SNMP (port 161) on a target, and attempting to identify the services:
sudo nmap -sU -sV -p 53,161 --reason 192.168.1.100
A potential output might look like this:
Starting Nmap 7.92 ( https://nmap.org ) at 2023-10-27 10:05 EDT
Nmap scan report for 192.168.1.100
Host is up (0.0020s latency).
PORT STATE SERVICE VERSION
53/udp open domain ISC BIND 9.16.1 (Linux)
161/udp open snmp SNMPv2-MIB::enterprises.2021.10.1.100.1 (Cisco IOS)
This is where it gets interesting. Nmap sent a DNS query to port 53. Because it received a valid DNS response, it declared the port open and then used sV to identify the specific DNS server software. For port 161, it sent a UDP packet that mimicked an SNMP request. If it received any kind of SNMP response, it marked it open and tried to fingerprint the SNMP agent.
The ambiguity of UDP scanning means you often have to combine -sU with -sV and analyze the REASON column very carefully. A port listed as open with no-response as the reason is less certain than a port open with a specific service response.
When Nmap sends a UDP packet to a port that has no listener, the target host’s operating system should send back an ICMP "Destination Unreachable" message (type 3, code 3). Nmap interprets the absence of this specific ICMP message as a sign that the port is likely open or that a firewall is silently dropping the packet. This is why UDP scanning is often slower and less reliable than TCP scanning; it’s a probabilistic assessment based on what didn’t happen.
The next hurdle you’ll likely face is dealing with UDP scans that appear to show many open|filtered ports, making it difficult to distinguish between a genuinely open port and one that’s just being silently blocked.