UDP flood detection
and mitigation

Back to Blog

What UDP Floods Are

A UDP flood is a volumetric DDoS attack that sends a high volume of User Datagram Protocol packets to a target, aiming to saturate network bandwidth, overwhelm server resources, or both. Unlike TCP, UDP is connectionless: there is no handshake, no state tracking, and no built-in mechanism to verify that the sender is who they claim to be. This makes UDP the ideal protocol for attackers because every packet is processed independently, source IPs can be trivially spoofed, and the target must expend resources handling each packet even if it is completely illegitimate.

UDP floods come in two primary forms. Direct floods send massive volumes of random UDP packets to the target, often to random destination ports. The target's kernel receives each packet, checks whether any application is listening on that port, and when nothing is listening, generates an ICMP "Destination Unreachable" reply. This creates a double cost: processing the incoming flood and generating outbound ICMP responses. Amplification floods are more efficient for the attacker. Instead of sending traffic directly, the attacker sends small requests to third-party servers (DNS resolvers, NTP servers, memcached instances) with the target's IP as the spoofed source. These servers send their responses, which are much larger than the request, to the target.

Common Amplification Vectors

DNS amplification exploits open DNS resolvers. The attacker sends a small query (typically 40 to 60 bytes) requesting a large DNS record (DNSSEC-signed ANY queries work well) with the target's IP as the source. The resolver sends the response (up to 4,096 bytes with EDNS0) to the target. The amplification factor is roughly 28x to 54x. DNS amplification remains one of the most common attack vectors because millions of open resolvers still exist on the internet.

NTP amplification exploits the monlist command on NTP servers running older versions of ntpd. A 234-byte monlist request generates up to 100 response packets containing the last 600 clients that contacted the server. The amplification factor can reach 556x, making NTP one of the most powerful amplification vectors. While most NTP servers have been patched to disable monlist, enough vulnerable servers remain to generate attacks exceeding 100 Gbps.

Memcached amplification is the most extreme amplification vector ever discovered in practice. A 15-byte UDP request to an exposed memcached server can generate a response of up to 10 MB, yielding an amplification factor of roughly 51,000x. The 2018 GitHub attack that reached 1.35 Tbps used this vector. Most memcached servers have since been configured to disable UDP or been firewalled, but the vector still surfaces in attacks using newly exposed instances.

SSDP amplification exploits the Simple Service Discovery Protocol used by UPnP devices. An M-SEARCH request of approximately 40 bytes can generate responses of 1 to 30 KB from home routers, media servers, and IoT devices. The amplification factor ranges from 20x to 75x. SSDP reflectors are abundant because consumer routers often expose UPnP to the internet by default.

Detecting UDP Floods

UDP flood detection relies on multiple signals that together distinguish attack traffic from legitimate UDP usage. The most fundamental signal is the UDP-to-TCP ratio. Most servers have a traffic profile dominated by TCP (HTTP/HTTPS, database connections, SSH). A sudden shift where UDP becomes the dominant protocol, or where UDP PPS spikes dramatically while TCP remains stable, is a strong attack indicator.

Packet size analysis is highly effective for identifying amplification attacks. DNS amplification produces UDP packets clustered around 512 to 4,096 bytes from source port 53. NTP amplification produces 468-byte packets from source port 123. Memcached amplification produces very large packets from source port 11211. A sudden influx of same-size UDP packets from a single source port is nearly always amplification traffic.

# Monitor UDP packet rates from /proc/net/snmp
# InDatagrams = total UDP packets received
# NoPorts = UDP packets to ports with no listener (flood indicator)
watch -n 1 "awk '/^Udp:/{getline;print}' /proc/net/snmp"

# Check for ICMP Destination Unreachable responses (generated by UDP flood to closed ports)
awk '/^Icmp:/{split($0,h);getline;split($0,v);for(i in h)if(h[i]~/OutDestUnreachs/)printf "%s=%s\n",h[i],v[i]}' /proc/net/snmp

# Quick per-second UDP PPS rate
S1=$(awk '/^Udp:/{getline;print $2}' /proc/net/snmp); sleep 1; S2=$(awk '/^Udp:/{getline;print $2}' /proc/net/snmp); echo "UDP PPS: $((S2-S1))"

Source diversity analysis reveals whether the flood is spoofed or from a real botnet. Amplification attacks appear to come from legitimate servers (DNS resolvers, NTP servers), so the source IPs are real but the traffic is unsolicited. Direct spoofed floods show thousands of random source IPs with uniform packet characteristics. Botnet-driven floods show a moderate number of source IPs (hundreds to thousands), each sending sustained traffic. Each pattern requires a different mitigation approach.

Mitigation Strategies

Rate limiting at the host level using iptables or nftables can reduce the impact of UDP floods when the attack volume does not exceed your link capacity. Limiting inbound UDP to a rate your server can handle buys time while you engage upstream mitigation. However, rate limiting is a blunt instrument: it drops both attack and legitimate UDP traffic indiscriminately if the attack exceeds the limit.

# Rate-limit inbound UDP to 10,000 packets per second
iptables -A INPUT -p udp -m limit --limit 10000/s --limit-burst 15000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

# Block specific amplification source ports
iptables -A INPUT -p udp --sport 19 -j DROP   # chargen
iptables -A INPUT -p udp --sport 53 -m length --length 512:65535 -j DROP  # large DNS responses
iptables -A INPUT -p udp --sport 123 -j DROP   # NTP
iptables -A INPUT -p udp --sport 11211 -j DROP # memcached
iptables -A INPUT -p udp --sport 1900 -j DROP  # SSDP

Null routing (RTBH) sacrifices the target IP to save the rest of your network. By injecting a BGP route that sends traffic for the attacked IP to a null interface, you stop the flood from consuming transit bandwidth. The downside is that the target IP becomes unreachable from the internet, which means the attack has effectively succeeded in taking that IP offline. RTBH is a last-resort measure when the flood threatens your entire network.

Cloud scrubbing diverts traffic through a scrubbing center that filters out attack traffic and forwards only legitimate packets. This is the most effective mitigation for large volumetric attacks that exceed your link capacity. Cloud scrubbing services (Cloudflare Magic Transit, Akamai Prolexic, Path.net, Voxility) have the bandwidth capacity to absorb multi-terabit floods and the filtering intelligence to separate attack traffic from legitimate UDP.

How Flowtriq Detects and Classifies UDP Floods

Flowtriq's node agent tracks UDP-specific kernel counters every second: Udp InDatagrams, Udp NoPorts, Udp InErrors, and the ICMP OutDestUnreachs counter that spikes when UDP packets hit closed ports. It compares these per-second rates against the node's rolling UDP baseline and triggers detection when the deviation exceeds the configured threshold.

When a UDP anomaly is detected, Flowtriq classifies the specific attack vector. If the traffic is predominantly from port 53 with large packet sizes, it is classified as DNS amplification. Port 123 traffic is classified as NTP amplification. Port 11211 is memcached. Random source ports with random destination ports are classified as a generic UDP flood. This classification appears in the incident record and the alert notification, so the responder immediately knows which mitigation approach to use. Flowtriq also captures a PCAP sample during the first seconds of the attack, providing packet-level evidence for forensic analysis and upstream provider communication.

Back to Blog

Related Articles