"Upon hitting a closed port on the target machine, the UDP probe should elicit an ICMP port
unreachable packet in return. This signifies to Nmap that the machine is up and available. Many
other types of ICMP errors, such as host/network unreachables or TTL exceeded are indicative of a
down or unreachable host. A lack of response is also interpreted this way. If an open port is
reached, most services simply ignore the empty packet and fail to return any response. This is why
the default probe port is 31338, which is highly unlikely to be in use. A few services, such as
chargen, will respond to an empty UDP packet, and thus disclose to Nmap that the machine is
" -sU (UDP scans)
While most popular services on the Internet run over the TCP protocol, UDP3 services are widely
deployed. DNS, SNMP, and DHCP (registered ports 53, 161/162, and 67/68) are three of the most
common. Because UDP scanning is generally slower and more difficult than TCP, some security
auditors ignore these ports. This is a mistake, as exploitable UDP services are quite common and
attackers certainly donÂ´t ignore the whole protocol. Fortunately, Nmap can help inventory UDP
UDP scan is activated with the -sU option. It can be combined with a TCP scan type such as SYN
scan (-sS) to check both protocols during the same run.
UDP scan works by sending an empty (no data) UDP header to every targeted port. If an ICMP port
unreachable error (type 3, code 3) is returned, the port is closed. Other ICMP unreachable errors
(type 3, codes 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a service will respond
with a UDP packet, proving that it is open. If no response is received after retransmissions, the
port is classified as open|filtered. This means that the port could be open, or perhaps packet
filters are blocking the communication. Versions scan (-sV) can be used to help differentiate the
truly open ports from the filtered ones.
A big challenge with UDP scanning is doing it quickly. Open and filtered ports rarely send any
response, leaving Nmap to time out and then conduct retransmissions just in case the probe or
response were lost. Closed ports are often an even bigger problem. They usually send back an ICMP
port unreachable error. But unlike the RST packets sent by closed TCP ports in response to a SYN
or connect scan, many hosts rate limit ICMP port unreachable messages by default. Linux and
Solaris are particularly strict about this. For example, the Linux 2.4.20 kernel limits
destination unreachable messages to one per second (in net/ipv4/icmp.c).
Nmap detects rate limiting and slows down accordingly to avoid flooding the network with useless
packets that the target machine will drop. Unfortunately, a Linux-style limit of one packet per
second makes a 65,536-port scan take more than 18 hours. Ideas for speeding your UDP scans up
include scanning more hosts in parallel, doing a quick scan of just the popular ports first,
scanning from behind the firewall, and using --host-timeout to skip slow hosts.
I'm aware of nmap, thanks. The problem is that my code above shows _no_difference_ between a closed and an open UDP port. I understand that I might have to try timing out, and that I might have to lump all "connection failed" responses together, and I'm completely fine with that.
Edit: Holy cow. I just realised that gman and I joined PM about 2 weeks apart. Almost 10 years ago!
Hmmm. Maybe; I hadn't really thought of that... However, I'm not sure that a netstat would show all services that are started by inetd (the reason I switched to rpcbind here is because more people are likely to have rpcbind available, hence the failure's easier to prove). I'm also trying to get as close to evidential proof as possible -- e.g. "You want port 1234 closed?": "Let's prove it's closed by trying to connect to it"
The netstat command shows network information and is not concerned with what services/processes are running. Also, inetd isn't magical and can't establish a connection without a listener. In order for the server to accept connections on a port then there has to be a listener for that port. The netstat command can be used to show what listeners are out there.
As far as proving it by attempting to connect to it, I would have no way of testing presently.
Sorry, I realised the stupidity of what I'd said (the implied magic) fairly quickly! Yeah, grokking the "netstat -af inet" output would almost certainly work for me for both TCP and UDP listeners, but there's still something somehow... cleaner about the attempted connection method, at least in my head.