Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How to leverage UDP port scanning as a security scanning tool

UDP port scanning isn't as robust as TCP port scanning, but there are steps you can take to include the technique as a security scanning tool.

This Content Component encountered an error

Editor's note: User Datagram Protocol port scanning is the process of discovering UDP-based applications at a target...

system, and it is a key component of every network security audit. While conceptually similar to TCP port scanning, UDP port-scanning techniques are different from those of its TCP counterpart. This article explains UDP port-scanning techniques and how to implement them with security scanning tool nmap.

While most popular internet services run on top of TCP -- a reliable, connection-oriented protocol -- there are still a number of important services running on top of the User Datagram Protocol, or UDP, which is an unreliable, datagram-oriented protocol. Some of them -- notably the domain name server -- are quite crucial for the whole internet infrastructure.

Because UDP port scanning as a security scanning tool tends to be less understood and less reliable than its TCP counterpart, it is often ignored when performing security audits. This article will examine the underlying details, techniques and limitations of UDP port scanning to provide network and security administrators the opportunity to leverage these considerations when performing security audits.

Port scanning basics

The basic idea behind any port-scanning technique is that a packet, or the stimulus, is sent to a target port at a target system and, depending on the state of the corresponding port, the packet will generate a specific response. Hence, the state of the port can be easily determined.

Generally speaking, a transport port can be in any of three states: open, closed or filtered.

A port is said to be open when an application -- to provide a given service -- is accepting incoming communication requests on that port. In the case of TCP, this means there is an application accepting incoming TCP connections. In the case of UDP, this means there is an application accepting or processing incoming UDP packets.

A port is said to be closed when there is no application accepting incoming communication requests from that port. If some sort of packet-filtering device drops packets being sent to a given port, the port is said to be filtered. This means the target system will not receive any communication requests sent to that port. Depending on system configuration, the filtering device may silently drop the aforementioned packets, or signal the packet drops to the sending system via an error message within the Internet Control Message Protocol.

Filtered ports have two associated considerations. First, if no response is received to a probe packet, it is not really possible to infer whether the port is actually filtered or if the probe packet, or the corresponding response, was silently dropped -- e.g., as a result of network congestion. Second, in order to determine that a port is filtered, it is typically necessary to wait for a period of time longer than that for determining the open or closed states. That is, if there is no positive response indicating the state of a port, one has to wait enough time to make sure no response will be received from the target system.

UDP port scanning versus TCP port scanning

As noted in our previous article on TCP port-scanning techniques, the most simple TCP port-scanning techniques -- namely SYN and connect() -- can readily determine the state of a target TCP port: The probe packet (a SYN packet) will elicit a SYN/ACK (acknowledgment) packet when the port is in the open state, a reset packet when the port is closed and no response when the port is filtered.

 These responses are governed by the TCP packet-processing rules and are completely orthogonal to the type or nature of the applications running on top of such TCP ports. This has important consequences: The state of a port can be determined even without knowledge of the application running on top of the target port. Thus, a pen tester or attacker can easily determine the list of open TCP ports by sending simple SYN packets to each target port and subsequently determine, if necessary, the application employing such a port -- e.g., detect an application running on a nonstandard port by means of banner-grabbing.

In the case of UDP port scanning, the packet-processing rules are essentially as follows: When a UDP packet is received for a port on which there is no listening application, an ICMP "port unreachable" is elicited. Otherwise, it is up to the corresponding application how to respond -- if at all -- to the incoming UDP packet. Typically, applications only respond to incoming application requests they understand -- for example, incoming packets that they can parse. This means, in order to be able to elicit a response from an open UDP port, a security scanning tool must craft an UDP packet containing a valid application payload that is understood by the application running on top of the target port. As a result, explicit confirmation that a port is open is typically only received when scanning standard UDP ports of applications, for which the scanning tool can craft valid application requests.

On the other hand, probe packets, or application requests, sent to closed ports will typically elicit ICMP "port unreachable" error messages. However, ICMP error messages are widely dropped and rate-limited on the public internet. Therefore, they are highly unreliable. Finally, if an ICMP error message other than "port unreachable" -- or no response at all -- is received in response to a UDP probe packet, the corresponding port will be inferred to be filtered.

As a result of the above considerations, a port security scanning tool such as nmap implements UDP port scanning by sending application-specific requests where possible, such that a positive response is received when the corresponding port is open. However, these tools resort to simple or generic UDP packets when scanning UDP ports for which no application-specific request or payload is available -- either because the corresponding port has no associated application protocol, or because the scanning tool does not implement it. Since both the probe packets and the possibly elicited responses may be dropped, port-scanning tools typically retransmit probe packets when no response is received. However, the results of UDP-based port scans are, nevertheless, much more unreliable when compared with their TCP counterparts.

UDP port scanning in nmap

Nmap is certainly the most popular UDP port scanner. In nmap, UDP port scans are activated with the -sU option. The specific ports or port ranges to be scanned can be specified with the -p option. For example, the following command will scan the UDP port range 1-1023 at the node

# nmap -sU -p 1-1023

Rather than scanning a fixed port range, nmap can be requested to scan the "N" most common ports by means of the --top-ports option, as follows:

UDP port scanning

As noted earlier, employing application-specific payloads improves the reliability of UDP port scans as a security scanning tool. The nmap-payloads file from nmap contains application-specific payloads for more than 30 UDP ports' numbers that are employed by default when scanning such ports. The aforementioned file can be locally edited and augmented as necessary.

There are many options that can affect the tradeoff between reliability and speed when performing a port scan. For example, --min-rtt-timeout allows the user to specify the maximum amount of time -- in seconds, unless "ms" is appended to the specified value -- that nmap will wait for a response to a probe packet.  Additionally, --max-retries allows the user to specify the maximum number of retransmissions for probe packets when no response is received. Please check the nmap manual page for other options that can help tune UDP scans.

Next Steps

Comparing the top scanning tools

Scanning and AWS security

Improving IPv6 security with scanning tools

This was last published in February 2017

Dig Deeper on Network Security Monitoring and Analysis

This Content Component encountered an error
This Content Component encountered an error