Why is UDP port scanning slower than TCP port scanning?

Question

I can't seem to find an answer for this.

Any suggestions?

Answer 1

The difference is in the very nature of the two protocols.

TCP is a connection-oriented protocol. This means that systems must establish and confirm a stable connection - for TCP, the process is commonly known as the "three-way handshake" - before data is actually transferred. As the process must happen quickly for a good connection, it can be reasonably expected that an open TCP port will respond in short order when it is probed. This means that the timeout before assuming a port is closed may also be very short.

UDP, on the other hand, is a connectionless protocol. For UDP, communications are sent without any expectation of a timely confirmation of receipt from the remote end. Thus, one has to allow for a longer timeout before it can be assumed that a remote port is closed - even after the timeout, such assumption is not 100% assured to be valid.

---

In a certain way, it's kind-of like this:

• TCP will call your phone and wait for you to actually pick up in order to warn you of a fire in your workplace. If you pick up and they talk to you, they know you've gotten the message. If your voicemail picks up, or the phone rings >4 times without a re-direct, they can be pretty sure you're not getting the message soon enough.

• UDP will send an emergency alert announcement to your phone to tell you of the fire. They won't know if you got the message unless they see you exiting the building, 5 flights of stair-climbing and a 100-meter dash or two later. And that's assuming you were even in the building to begin with.

Now, let's say you had to notify 1,000 or so people about a fire. But you could only tell them one at a time, and had to wait for confirmation of receipt (or a reasonable time to be sure of probable non-receipt) from each one before trying the next.

Port scanning (with Nmap or any other tool) is kinda like that. TCP is gonna go relatively quick, and will probably be pretty accurate. With UDP the building will probably burn down before you get through the list just once, and you still won't be really sure whether the people you sent the message to were even around to care about it.

Answer 2

From the nmap page

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.

Answer 3

They are different protocols. At UDP you have to wait for the answer for a specified timeout, at TCP you instantly see that a port is open after getting the three-way handshake. If it's closed, you are most likely to get a packet with the RST flag set, so also you can instantly move on to the next port.

It is possible to achieve some extra speed for UDP scans, with nmap you could use --min-rate, --max-rtt-timeout and --max-retries to fine tune some settings.