UDP flood attacks are often misunderstood as simply "sending too much UDP traffic." The real issue is that they exploit the stateless nature of UDP and the way applications process incoming datagrams to consume finite resources on the target server, leading to denial of service.
Let’s see a UDP flood in action. Imagine a simple UDP server listening on port 12345.
import socket
UDP_IP = "127.0.0.1"
UDP_PORT = 12345
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
print(f"UDP server listening on {UDP_IP}:{UDP_PORT}")
while True:
data, addr = sock.recvfrom(1024) # buffer size is 1024 bytes
print(f"Received message: {data} from {addr}")
# In a real attack, the server might do some processing here,
# like looking up a database entry based on 'data'.
# This processing consumes CPU and memory.
Now, let’s simulate a flood of UDP packets to this server using scapy. This isn’t a real-world attack, but it demonstrates the principle.
from scapy.all import IP, UDP, send
import time
target_ip = "127.0.0.1"
target_port = 12345
num_packets = 100000
for i in range(num_packets):
packet = IP(dst=target_ip)/UDP(dport=target_port)
send(packet, verbose=0)
if i % 10000 == 0:
print(f"Sent {i} packets...")
# A slight delay might be used in real attacks to evade detection,
# but for overwhelming resources, high rate is key.
# time.sleep(0.0001)
print(f"Finished sending {num_packets} UDP packets.")
When the scapy script runs, the Python UDP server will start printing "Received message…" for every packet it gets. If the server application also had to perform a lookup or some computation for each packet, the CPU usage would spike, and the network receive buffers could fill up. Eventually, the server would become unresponsive to legitimate traffic because it’s too busy processing the flood or its network stack is saturated.
The core problem UDP floods exploit is that UDP is connectionless. Unlike TCP, there’s no handshake to establish a connection. A UDP packet arrives, and the server’s operating system or application has to deal with it. This "dealing with it" often involves:
- Network Stack Processing: The OS kernel receives the UDP datagram, checks its checksum, and determines which application port it’s destined for. This consumes CPU cycles.
- Application Layer Processing: The application bound to that port reads the datagram from the socket buffer. If the application performs any work based on the datagram’s content (e.g., database lookups, computations, generating a response), this consumes CPU and memory.
- Resource Exhaustion: The sheer volume of packets can exhaust several resources:
- CPU: Processing each packet, even if minimal, adds up.
- Memory: Network buffers (both OS and application level) can fill up. In some cases, applications might allocate memory per request, leading to memory exhaustion.
- Bandwidth: While the attack aims at the server’s processing, it also consumes inbound bandwidth.
The attacker’s goal is to make the server too busy to respond to legitimate requests. This can be achieved by sending a high volume of UDP packets to random ports or specific ports used by applications. If a port isn’t listening, the server might still generate an ICMP "Destination Unreachable" response, which also consumes resources.
The key levers an attacker can pull are the volume (packets per second) and the size of the UDP packets. Larger packets consume more bandwidth and can take longer to process. Attackers often use spoofed source IP addresses, making it difficult to trace the attack or block specific sources.
One subtle aspect of UDP flood attacks is their effectiveness against specific application protocols that rely on UDP. For instance, protocols like DNS (port 53), NTP (port 123), or VoIP traffic can be targeted. An attacker might send UDP packets to a DNS server with forged queries, forcing the server to perform recursive lookups for domains that don’t exist or are computationally expensive to resolve. This can tie up the DNS server’s resources and prevent it from serving legitimate DNS requests. The same principle applies to other UDP-based services; the attacker essentially forces the target application to perform a lot of work for "free" by simply sending it a constant stream of UDP datagrams.
The immediate aftermath of a successful UDP flood, assuming the attack is stopped, is often the server recovering its resources. However, if the attack was sustained and caused significant load, you might then encounter issues with other services that depend on the overloaded server, or perhaps network devices that were also saturated by the traffic.