NMAP 5.21 - Is UDP Protocol Specific Scanning Important? Why Should I Care?
Before we address the question, let's discuss how UDP port scanning is typically done.
When a host receives a UDP packet, what is supposed to happen is that if the host isn't listening on that port, it should reply with a ICMP Port Unreachable (ICMP Type 3, Code 3). If it is listening on that port, the packet contents are fed to the listening application and processed. If the application does not understand the packet contents, it might reply with an error, but most likely will drop the packet and not reply at all.
If there is any kind of a firewall involved, either on the host itself or in the network path, then quite often no reply at all will be received for the sent packet.
So an open port and a port protected by a firewall will often look the same to a scanner. This can be a real problem when scanning UDP ports, as ports listening with a running service will look exactly like firewalled ports, which of course do not have a service available to the scanning station.
What UDP Protocol Awareness brings is a better payload. With protocol awareness, a scan of the UDP DNS port for instance (udp/53), might be a an actual dns request. A scan of an NTP (network time protocol) port could be an NTP timestamp or time request. The application receives a valid packet, and if there is a listening port, a valid response is sent back to the scanner, and the scanner can now know for certain that this port is open!
To illustrate - first, let's scan an NTP (Network Time Protocol) server's NTP port with an older version of Nmap (5.0). This behaviour is typical of most port sc
C:> nmap -sU -p123 192.168.122.254
Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-28 13:17 Eastern Standard Time
Interesting ports on 192.168.122.254:
PORT STATE SERVICE
123/udp open|filtered ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)
Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds
As you can see, the port shows as open/filtered. From the packet trace below, you can see that an emtpy packet is sent to udp/123, no valid NTP data is contained, and the NTP server simply drops the packet. There really is an NTP server running, but there's no way to tell for sure using this method of scanning.
Now let's run the same scan with Nmap 5.2, which has UDP protocol awareness.
C:>nmap -sU -p 123 192.168.122.254
Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-21 22:15 Eastern Standard Time
Nmap scan report for 192.168.122.254
Host is up (0.0019s latency).
PORT STATE SERVICE
123/udp open ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)
Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds
The difference is immediately apparent, the port now has a state of open, instead of open/filtered. Let's take a look at the packet and see exactly why ..
As you can see, Nmap is sending an actual NTP client timestamp of the NTP server, and it gets an NTP server response back. This identifies both the fact that the host is actually listening on that port, as well as the fact that it's an actual NTP service that's listening.
Currently NMAP 5.21 supports protocol specific payloads for:
udp/7 echo
udp/53 domain
udp/111 rpcbind
udp/123 ntp
udp/137 netbios-ns
udp/161 SNMP
udp/177 xdmcp
udp/500 ISAKMP
udp/520 route
udp/1645 and udp/1812 RADIUS
udp/2049 NFS
udp/5353 zeroconf
udp/10080 amanda
This is an exciting development, allowing us to scan these particular ports with a LOT more accuracy than previously possible. Again, Fyodor and the NMAP crew have replaced a number of other tools simply by adding some new features to NMAP - great job!
=============== Rob VandenBrink, Metafore =================
Comments
By RST do you mean ICMP Port Unreachable?
Anonymous
Feb 1st 2010
1 decade ago
Fixed.
Rob
Feb 1st 2010
1 decade ago
Kura
Feb 1st 2010
1 decade ago
drak
Feb 1st 2010
1 decade ago
Should that be "open/filtered"?
Patrik
Feb 1st 2010
1 decade ago
Dom De Vitto
Feb 1st 2010
1 decade ago
Thanks for heads up on Fyodor's expansion. Nice work!
Bill
Feb 1st 2010
1 decade ago