I. Presentation
In the rest of the tutorials on port scanning, today we will study the interest, operation, but also the limits of port scanning via the UDP transport protocol, also called “connectionless protocol”.
II. UDP, known as the “connection-less” protocol
Unlike TCP (Transmission Control Protocol) , UDP (User Datagram Protocol) is a so – called “connectionless” or “connectionless” protocol and this poses an additional difficulty in port detection and scanning. The fact that a transport protocol is connectionless implies that the packets are not sure to arrive at their destination and that we are not notified of their arrival. This can then skew the scan. For more information, the UDP protocol is described in RFC 768, “User Datagram Protocol”
In addition, we saw in our previous posts on TCP port scans that the responses to our packets greatly helped to determine the state of the scanned ports, or in UDP, no feedback is made.
III. How a UDP Port Scan Works
Due to the simplicity of the exchanges between the machines using the UDP transport protocol, scanning UDP ports is not complex to implement. Indeed, it is only possible to determine two states of a port. Either it is filtered or open, or it is closed . If the port is open, no return will be made to our scan machine by the targeted server. Indeed, it is the normal behavior of machines communicating via UDP not to send back a good reception packet (ACK or “acknowledgment”). Conversely, if no application is ready to receive our packet on the targeted UDP port, then an ICMP packet is sent back to us with the corresponding error code, namely the message “. By having a difference between the reaction of an open port and that of a closed port, we can perform a scan of all UDP ports:
Diagram of the behavior for an open and closed port during a udp port scan
It is important to know that a UDP scan is not able to detect the presence of a firewall or of a filtering system between the scanning machine and the scanned target, which can distort the results obtained. Indeed, a firewall between the two machines will have the effect that no packet is sent back to the machine sending the scan, whether the port is open or not. This is annoying because when the targeted UDP port is opened, no packets are returned to us either. So when a port appears open, it may actually be filtered, and vice versa.
On the nmap tool , the “-sU” ( s can U DP) option must be used to perform a UDP port scan:
nmap -sU 192.168.1.17
To make the article more meaningful and clear, I performed a UDP scan on two ports of a target machine, one of the ports was open, the other closed. I also listened to the network during these two scans to observe the behavioral differences studied above. Here is for example the view on n map when scanning an open or filtered port :
Nmap view during a UDP scan for an open or filtered port.
So we see that nmap informs us that the target port “991” can be either open, or filtered. We can then try to investigate more in depth on the port in question. On the network, here is what we can observe:
Network analysis during a UDP scan for an open or filtered port.
It can therefore be seen that the two UDP packets sent on the given port “991” are unanswered from the remote host. Nmap chooses to send two packets because of the risk UDP poses. Indeed, if a packet is lost, we could not get a response and believe that the port is open even though it has never reached the target, which is why two packets are sent.
Conversely, during the nmap scan of a closed port, here is what we can get as a return:
Nmap view during a UDP scan for a closed port.
So we see that the port is clearly marked as closed ( “closed”) . On the network, here is what we can see when listening to the network:
Network analysis during a UDP scan on a closed port
We therefore clearly see after our UDP packet sent on port ” 990″ that a response from the scanned host is made to us. It is therefore the ICMP packet comprising the message “Port unreachable”. We can see that the port is closed here.
UDP scanning software and tools all use this functionality. By receiving all ICMP packets, they make a list of closed packets and therefore know that all other packets that have been sent UDP packets are either being filtered by a firewall or open. You are then free to investigate each of them in more depth to find out what is behind these ports.
IV. The limits of UDP port scanning
The scan via the UDP transport protocol is as important as the TCP scan in terms of the information it can provide to an attacker, it will often betray the presence of a service that can be used and exploited. However, it has a few limitations that are important to be aware of:
- The fact that the protocol does not have a good reception validation system between the hosts creates the risk that the lost packets will distort the results of the scan . Indeed, the non-response of a host to the stimulation of a port could make us think that it is about a potentially open port whereas the UDP packet has simply not arrived at its destination, that’s why some tools like nmap send two UDP packets.
- UDP scan is generally slower than TCP scans. Indeed, it is a protocol which generally uses less network resources than the TCP protocol and which is also less used in terms of packet volume. The size of the buffers (buffers that store network packets awaiting processing by the system) is smaller than those for TCP packets. This therefore leads to additional slowness during the scan.
- During a UDP scan, you will notice that the packets are formatted according to the targeted port . For example, here is the case of a UDP scan done on port 53 which corresponds to the DNS port generally used by clients during their requests:
Network analysis during a UDP scan for an open or filtered port.
It can therefore be seen that the UDP packet sent to probe port 53 automatically includes a DNS query on the status of the server. Thus, a standard server put on a port other than the usual one (or vice versa) could falsify the result of the scan.
Finally, there is an effective workaround against UDP scans that we will study in the next point and which constitutes a strong limit to UDP scans made in certain contexts.
V. Protection against UDP port scanning
After having explained the way in which attackers could detect active services via UDP on systems, it is now necessary to propose avenues of protection and prevention against these scans which, even if they appear harmless, can lead to the detection of vulnerable and sensitive services. There are indeed a few tips for detecting port scans and for blocking them:
- The implementation of intrusion detection or intrusion prevention services , more commonly called IDS or IPS, makes it possible to detect UDP scans. By receiving network traffic in real time, it can be easy to detect that hundreds of UDP packets are being sent over a single IP in a short period of time and raise an alert about it. This can nevertheless be circumvented when the attacker takes several days to perform his scan by spacing out the UDP packet sending to pass under the IPS / IDS radars . An attacker can also target only a few strategically chosen ports known to be often open and sensitive ports (DNS & SNMP for example).
- Another protection often put forward against UDP scans is the implementation of a filtering of the network traffic prohibiting the ICMP packets of type “ICMP_Port_Unreachable_Error” from leaving. This will prevent the attacker from receiving packets indicating that a port is closed, thus distorting the results of his scan which will display all ports as either open or filtered. This implies of course that the scanned machine has an integrated filtering system such as iptables or a router-type filtering system, but for this the scan must be carried out through this router and not inside even from the local network of the targeted machine.