Checking if UDP ports are up and basics of port scanning

Nmap and UDP scanning

nmap is one hell of a tool. It is a very powerful swiss army knife for anything related to network exploration and security / port scanning.

It's relatively easy to test TCP-based services (try "telnet www.blogger.com 80", and press Ctrl-D to quit). But what about UDP?

UDP is connectionless, we can't rely on something like TCP's 3-way handshake. All that is happening here, is that somehow our machine (the client) wants to see if it can receive a datagram from a server.
Usually, the server will answer a corresponding request from the client, in the form of another UDP datagram.

Now we can either be smart about it by sending datagrams without content and risking the server not answering back, or do it by the book and send a datagram the server would be expecting for a given port. In other words if we know the protocol in advance, we better comply with that protocol.

And this is what nmap is going to do for us, i.e. sending the appropriate UDP datagrams for well-known ports and empty datagrams otherwise (except if the appropriate command-line option is used).

f

Testing one UDP port

I just read an article about Switzerland transitioning from "winter time" to "summer time", or more specifically from CET to CEST (Central European Summer Time) tonight. They were some words about the NTP (Network Time Prococol) server at ntp.metas.ch.
You can't test if that service really exists with HTTP by typing this address in your browser (even though I was expecting them to have at least some webpage there, but anyway...)
We are going to send a UDP datagram on port 123, the default for NTP.

sudo nmap -p 123 -sU -P0 ntp.metas.ch

Starting Nmap 6.40 ( http://nmap.org ) at 2016-03-26 11:24 CET
Nmap scan report for ntp.metas.ch (162.23.41.10)
Host is up (0.033s latency).
rDNS record for 162.23.41.10: metasntp13.admin.ch
PORT    STATE SERVICE
123/udp open  ntp

Nmap done: 1 IP address (1 host up) scanned in 1.10 seconds

First, let's look at the command.
sudo is required because nmap will be sending raw packets. Even when it is not strictly required, it is recommended to use nmap with a privileged user as the scans will be able to use more techniques and avoid relying on workarounds.
-p 123 limits the scan to port 123. Unfortunately UDP scanning is slow and, according to the manual, it will take 18 hours to scan all 65,536 ports, so you need to be precise.
-sU stands for "UDP scan"
-P0 activates IP protocol ping. You might want to try the command without that option. It basically asks the host operating system if there is a service running on that port (because the OS needs to know which program is listening on that port and where to forward UDP datagrams).

f

How does that work? (when the port is open)

Let's ask Wireshark what the previous command really did:

11 The client (my computer) first needs to know the IP address of ntp.metas.ch, by sending a DNS Address request to my local DNS caching server.
12 The DNS server replies back, saying: "Hey, ntp.metas.ch is actually an alias for metasntp13.admin.ch whose address is 162.23.41.10". This might be due to load-balancing.
13 Nmap got the address 162.23.41.10 for ntp.metas.ch by the operating system. Nmap doesn't know the hostname it asked the address of is actually an alias, and because Nmap is curious, it performs a reverse DNS lookup (rDNS), that is it looks for the hostname belonging to an IP address. That is what frame #13 is about. This step is completely  useless, it's only for our information.
14 is the answer from the reverse DNS lookup
15 Now that Nmap knows the IP address, it can start its work. It knows that UDP port 123 is used for NTP, so it sends the appropriate payload, which Wireshark shows like this:

It doesn't really matter what is in there, but you can see it is a valid NTP message.

16 is the response from the NTP server:

f

How does that work? (when the port is closed, 1st variant)

Let's try again with port 12345, on which the server is not listening. 

sudo nmap -p 12345 -sU -P0 ntp.metas.ch

Starting Nmap 6.40 ( http://nmap.org ) at 2016-03-26 12:18 CET

Nmap scan report for ntp.metas.ch (162.23.41.10)

Host is up.

rDNS record for 162.23.41.10: metasntp13.admin.ch

PORT      STATE         SERVICE

12345/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.09 seconds

Notice how Nmap reports the port as being open or filtered. This means it could not definitely say the port was closed, so it is saying it might be open but the server did not respond to our request, possibly because it was badly formed, which means the request was filtered.

This is the complete exchange (nothing more happened after that):

1 to 4 are the same as before. In many cases, you will not see these frames as clients usually have a local DNS cache so they don't need to perform DNS lookup every time

5 looks like that:

You can see the client tried to contact the server on port 12345 (which is known to Wireshark to usually be used for some application / protocol named italk). The length is 8 bytes, which is the size of the UDP header ; the source port has a size of 2 bytes (because the max value  is 65,536), same for the destination port, the length field itself is 2 bytes, and there are 2 more bytes for the checksum. So if the header size is equal to the size of the UDP datagram, then there is no payload.

6 is exactly the same as #, except for the source port.

There is no other response from the server. What does that tell us?

The server did not send an "ICMP unreachable error" packet, which prevents us from definitely determining that the port is closed or filtered (the distinction depends on the ICMP error code, but it doesn't matter now). That is why Nmap is saying the port might be open.

It is not just saying "open" either, but "open or filtered" because there was no response.

f

How does that work? (when the port is closed, 2nd variant)

You might be more lucky and get a definitive answer telling you the port is closed with certainty.

Let's try another request:

sudo nmap -p 86 -sU -P0 172.16.123.34

Starting Nmap 6.40 ( http://nmap.org ) at 2016-03-26 12:40 CET

Nmap scan report for 172.16.123.34

Host is up (0.0033s latency).

PORT   STATE  SERVICE

86/udp closed mfcobol

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

If you followed the previous explanation, you should figure out what happened if Nmap was able to conclude that the port was closed instead of "open", or "open|filtered", or just "filtered".

You don't? Let's look at it then:

It looks pretty standard, starting with the DNS request (which this time was unsucessful), and a UDP datagram from the client. But the response (frame #6) from the server is different:

Look at that, it's an ICMP message! It says the port is unreachable. It could not be more clear. As a result, Nmap shows the port as closed.

f

Why don't we get "port closed" all the time?

The network stack on the server on my local network is probably not much different than the one from the example before that. Probably the server behind ntp.metas.ch also sent a similar packet, but the firewall in front of that server blocks ICMP packets. For instance it is not even possible to ping that server ("ping" works by sending an ICMP message and getting one in return).

Or the folks operating the firewall might just block these two types of ICMP messages (ping and port unreachable) to avoid network discovery and port scanning. This, along with blocking TCP Reset might be advisable to prevent this kind of attacks.
This is why many Internet servers don't send back diagnostic messages telling if a host or service is up. The client is usually going to assume that after sending one or more requests that don't get an answer in a reasonable amount of time ("timeout").

Unfortunately in the case of UDP, no answer doesn't necessarily means that there is no service at a particular host and port, as the server might simply be ignoring the request.