UDP Flood Attack
A UDP flood is a volumetric denial-of-service attack that exploits the connectionless, stateless nature of the User Datagram Protocol to overwhelm a target with massive volumes of UDP packets. Since UDP requires no handshake or session establishment, attackers can send packets from spoofed IP addresses at line rate, saturating the target's network bandwidth and forcing the server to consume CPU cycles generating ICMP 'Destination Unreachable' responses for every packet hitting a closed port.
How UDP Flood Attack Works
UDP is inherently vulnerable to flooding because it provides no connection state, authentication, or flow control. A sender can transmit UDP datagrams to any IP:port combination without prior negotiation, and the receiving host must process each packet to determine whether a service is listening. When a UDP packet arrives at a closed port, the OS kernel generates an ICMP Port Unreachable message β consuming CPU and outbound bandwidth. When it arrives at an open port (DNS on 53, NTP on 123, SNMP on 161), the listening application must parse and reject the malformed data, consuming application-layer resources. At high packet rates (millions of packets per second), the target's network interface card, kernel network stack, and firewall connection tracking tables all become bottlenecks. Unlike TCP floods that exploit protocol state, UDP floods are pure bandwidth exhaustion attacks β the only defense is having more capacity than the attacker or filtering upstream.
Generate high-volume UDP traffic from spoofed sources
The attacker uses a botnet or compromised servers with high-bandwidth connections to generate UDP packets at maximum rate. Each packet carries a randomized or spoofed source IP address, since UDP has no handshake that would require a valid return path. Modern botnets with 10,000-100,000 nodes, each capable of sending 1-10 Mbps of UDP traffic, can collectively generate 10-100+ Gbps of attack traffic. The packets are typically 512-1400 bytes (just under MTU to avoid fragmentation overhead) with random payload data.
Target random ports to maximize ICMP generation
The attacker sends packets to random destination ports on the victim's IP address. For each packet arriving at a port where no application is listening, the victim's kernel generates an ICMP Port Unreachable response β a 70-byte packet sent back to the (spoofed) source. This doubles the victim's traffic impact: inbound flood plus outbound ICMP responses. At 500,000 incoming UDP packets per second to closed ports, the victim generates 500,000 ICMP responses, consuming approximately 280 Mbps of outbound bandwidth on top of the inbound flood. Some attackers deliberately alternate between open and closed ports to strain both network and application resources.
Saturate the network link before packets reach the server
Once the UDP flood volume exceeds the target's network link capacity, all traffic β legitimate and malicious β is dropped indiscriminately at the network edge. A server with a 1 Gbps uplink receiving a 10 Gbps UDP flood loses 90% of all packets before they even reach the firewall or operating system. This is the fundamental challenge of volumetric DDoS: the bottleneck is the pipe, not the server. Even a perfectly hardened server with unlimited CPU is useless if its network link is saturated. Collateral damage extends to all services sharing the same network segment or upstream ISP link.
Exhaust stateful device resources along the path
Firewalls, IDS/IPS systems, and load balancers that maintain connection tracking tables must create a state entry for each unique UDP flow. A UDP flood with randomized source IPs and destination ports generates millions of unique flows, rapidly filling conntrack tables (typically sized 128K-2M entries). Once the conntrack table is full, these devices drop all new connections β including TCP β causing broader service failure beyond the UDP flood itself. This makes stateful devices a common bottleneck even when the network link has sufficient bandwidth.
Target UDP-based services for application-layer impact
When the attacker knows which UDP services are running, they send well-formed or semi-formed packets to those specific ports: DNS queries to port 53, NTP requests to port 123, SIP INVITE messages to port 5060, or game protocol packets to the game server port. The application must parse and process each packet before determining it's malicious, consuming CPU, memory, and application threads. DNS servers are particularly vulnerable because they perform recursive resolution for each query, amplifying the computational cost far beyond simple packet processing.
Real-World Examples
Estonian cyberattacks β UDP floods against national infrastructure
In April-May 2007, Estonia suffered a coordinated 22-day cyberattack campaign following a political dispute with Russia. The attacks included massive UDP floods targeting Estonian government websites, banking systems (Hansabank, SEB), media outlets, and DNS infrastructure. Online banking was disrupted for over a week, government email systems were knocked offline, and the country's DNS servers were overwhelmed with floods peaking at 4 Gbps β enormous for the time. The incident was the first cyberattack against an entire nation-state's digital infrastructure and led to the establishment of NATO's Cooperative Cyber Defence Centre of Excellence in Tallinn.
Online gaming industry UDP flood epidemic
Throughout 2021, the online gaming industry faced an epidemic of UDP flood attacks, with game servers being primary targets due to their dependence on UDP for real-time communication. Attacks against major game publishers and competitive gaming platforms peaked at 253 Gbps, causing widespread session disconnections, lag spikes, and tournament disruptions. Game server hosting providers reported 10x increases in UDP flood incidents year-over-year, with some attacks sustaining 100+ Gbps for over 12 hours. The gaming sector accounted for nearly 40% of all DDoS attacks in 2021 according to industry reports.
OVHcloud record multi-vector attacks including UDP floods
In the second half of 2024, European hosting provider OVHcloud faced a sustained two-week campaign of multi-vector DDoS attacks reaching a record 4.2 Tbps, with UDP floods constituting a significant portion of the traffic alongside TCP-based vectors. The attacks originated from approximately 150,000 source IPs, including compromised MikroTik routers and IoT devices. The campaign targeted multiple OVHcloud customers and infrastructure simultaneously, requiring continuous adaptation of filtering rules as the attackers rotated between UDP flood, SYN flood, and DNS amplification vectors.
Impact & Risk Assessment
UDP floods are the simplest and most common volumetric DDoS technique, accounting for approximately 55-62% of all DDoS attacks by volume. Their effectiveness comes from the combination of UDP's stateless nature (no handshake means unlimited spoofing), the availability of massive botnets, and the fundamental physics of bandwidth saturation β no amount of server hardening helps when the network pipe is full. Impact extends beyond the target: shared hosting environments see all customers affected when one is attacked; upstream ISP links may saturate, causing collateral damage to unrelated networks; and stateful security devices (firewalls, IDS) along the path may fail under the load of tracking millions of UDP flows. UDP-dependent services are disproportionately affected: VoIP calls drop with as little as 1% packet loss, online gaming becomes unplayable at 50ms additional latency, and DNS resolution fails when UDP port 53 is overwhelmed. Financial impact scales with downtime duration β gaming companies report losses of $25,000-$40,000 per hour during DDoS attacks, while enterprises with SLA obligations face contractual penalties alongside direct revenue loss.
How to Detect UDP Flood Attack
Monitor inbound UDP packet rates and compare against established baselines β a typical web server receives minimal UDP traffic (primarily DNS responses and NTP), so a sudden spike from hundreds to hundreds of thousands of packets per second is a clear indicator. Track the ratio of UDP to TCP traffic; legitimate web traffic is overwhelmingly TCP, so a shift where UDP exceeds 30-40% of total traffic indicates a likely flood. Analyze source IP entropy: legitimate UDP traffic comes from a relatively stable set of DNS resolvers and NTP servers, while UDP floods show thousands of unique source IPs with high address space entropy. Monitor ICMP Port Unreachable generation rate β a sharp increase indicates UDP packets hitting closed ports at high rates. Check conntrack table utilization on firewalls and stateful devices: rapid filling of the connection tracking table with UDP entries signals a flood. Deploy NetFlow/sFlow analysis at the network perimeter to detect volume anomalies before they impact services β flow data captures traffic patterns with minimal overhead even during high-volume events.
How to Prevent UDP Flood Attack
Deploy upstream DDoS mitigation (cloud-based scrubbing or ISP-level filtering) as the primary defense β on-premises hardware cannot mitigate a flood that exceeds your network link capacity. Configure firewalls to drop UDP packets to ports where no service is listening, eliminating ICMP Port Unreachable generation and reducing CPU load. Disable ICMP Port Unreachable responses in the kernel (net.ipv4.icmp_ratemask on Linux) to prevent outbound ICMP traffic amplifying the flood's bandwidth impact. Implement conntrack table tuning: increase nf_conntrack_max, reduce UDP timeout values (net.netfilter.nf_conntrack_udp_timeout=10 instead of default 30), and consider using NOTRACK rules for high-volume UDP services to bypass connection tracking entirely. For UDP services that must remain accessible (DNS, game servers), implement application-level rate limiting, packet validation (check packet structure before processing), and geographic filtering (drop traffic from regions with no legitimate users). Implement BCP 38 source address validation at your network edge and advocate for its adoption by your upstream providers β widespread BCP 38 deployment would eliminate spoofed UDP floods entirely. Consider dedicated DDoS mitigation appliances positioned inline for organizations with high-bandwidth connections.
Code Examples
# === Kernel tuning for UDP flood resilience ===
# Disable ICMP Port Unreachable responses to prevent outbound amplification
# Bit 3 in icmp_ratemask controls Port Unreachable (Type 3)
iptables -A OUTPUT -p icmp --icmp-type port-unreachable -j DROP
# Increase conntrack table size (default 65536 is too small under flood)
sysctl -w net.netfilter.nf_conntrack_max=2000000
sysctl -w net.netfilter.nf_conntrack_buckets=500000
# Reduce UDP conntrack timeout (default 30s β 10s)
# Entries expire faster, freeing conntrack slots during floods
sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=30
# Increase network receive buffer sizes
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.rmem_default=8388608
sysctl -w net.core.netdev_max_backlog=50000
# === iptables rules to filter UDP flood traffic ===
# Drop UDP packets to ports where no service listens
# List your legitimate UDP services explicitly
iptables -A INPUT -p udp --dport 53 -j ACCEPT # DNS (if you run a DNS server)
iptables -A INPUT -p udp --dport 123 -j ACCEPT # NTP (if you run NTP)
iptables -A INPUT -p udp --dport 1194 -j ACCEPT # OpenVPN (if applicable)
# Drop all other inbound UDP
iptables -A INPUT -p udp -j DROP
# If you must accept UDP on certain ports, rate-limit per source IP
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-above 50/sec \
--hashlimit-burst 100 \
--hashlimit-mode srcip \
--hashlimit-name udp_dns_limit \
-j DROP
# Bypass conntrack for high-volume UDP services (reduces state table pressure)
iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 53 -j NOTRACK
# Anti-spoofing: enable reverse path filtering
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1
# Persist all sysctl settings
sysctl -p
import subprocess
import time
import logging
from collections import defaultdict
logger = logging.getLogger('udp_flood_monitor')
def get_udp_stats():
"""Read UDP statistics from /proc/net/snmp and conntrack"""
stats = {}
# Parse /proc/net/snmp for UDP counters
with open('/proc/net/snmp', 'r') as f:
lines = f.readlines()
for i, line in enumerate(lines):
if line.startswith('Udp:') and i + 1 < len(lines):
headers = line.split()
values = lines[i + 1].split()
if headers[0] == 'Udp:' and values[0] == 'Udp:':
for h, v in zip(headers[1:], values[1:]):
stats[f'udp_{h}'] = int(v)
break
# Get conntrack stats
try:
result = subprocess.run(
['cat', '/proc/sys/net/netfilter/nf_conntrack_count'],
capture_output=True, text=True
)
stats['conntrack_count'] = int(result.stdout.strip())
result = subprocess.run(
['cat', '/proc/sys/net/netfilter/nf_conntrack_max'],
capture_output=True, text=True
)
stats['conntrack_max'] = int(result.stdout.strip())
except (ValueError, FileNotFoundError):
pass
return stats
def get_interface_counters(interface='eth0'):
"""Read packet and byte counters from /sys/class/net"""
base = f'/sys/class/net/{interface}/statistics'
counters = {}
for stat in ['rx_packets', 'rx_bytes', 'tx_packets', 'tx_bytes']:
try:
with open(f'{base}/{stat}', 'r') as f:
counters[stat] = int(f.read().strip())
except FileNotFoundError:
counters[stat] = 0
return counters
def monitor_udp_flood(
interface='eth0',
pps_threshold=100000,
bps_threshold=1_000_000_000, # 1 Gbps
conntrack_pct_threshold=80,
check_interval=5
):
"""Continuous UDP flood monitoring with multi-indicator alerting"""
prev_counters = get_interface_counters(interface)
prev_stats = get_udp_stats()
prev_time = time.time()
while True:
time.sleep(check_interval)
curr_counters = get_interface_counters(interface)
curr_stats = get_udp_stats()
curr_time = time.time()
elapsed = curr_time - prev_time
# Calculate rates
rx_pps = (curr_counters['rx_packets'] - prev_counters['rx_packets']) / elapsed
rx_bps = (curr_counters['rx_bytes'] - prev_counters['rx_bytes']) * 8 / elapsed
tx_pps = (curr_counters['tx_packets'] - prev_counters['tx_packets']) / elapsed
# UDP-specific: NoPorts = ICMP Dest Unreachable generated (closed port hits)
noports_rate = 0
if 'udp_NoPorts' in curr_stats and 'udp_NoPorts' in prev_stats:
noports_rate = (curr_stats['udp_NoPorts'] - prev_stats['udp_NoPorts']) / elapsed
# Conntrack utilization
conntrack_pct = 0
if 'conntrack_count' in curr_stats and 'conntrack_max' in curr_stats:
conntrack_pct = (curr_stats['conntrack_count'] / curr_stats['conntrack_max']) * 100
# Alert conditions
if rx_pps > pps_threshold:
logger.critical(
f'HIGH PACKET RATE: {rx_pps:,.0f} pps inbound '
f'({rx_bps / 1e9:.2f} Gbps), threshold: {pps_threshold:,}'
)
if noports_rate > 1000:
logger.warning(
f'UDP closed-port hits: {noports_rate:,.0f}/sec '
f'(generating ICMP Port Unreachable responses)'
)
if conntrack_pct > conntrack_pct_threshold:
logger.critical(
f'CONNTRACK TABLE {conntrack_pct:.1f}% full '
f'({curr_stats["conntrack_count"]:,}/{curr_stats["conntrack_max"]:,}) β '
f'risk of dropping all new connections'
)
prev_counters = curr_counters
prev_stats = curr_stats
prev_time = curr_time
if __name__ == '__main__':
logging.basicConfig(level=logging.INFO)
monitor_udp_flood()
# Nginx reverse proxy architecture for UDP flood resilience.
# Nginx only processes TCP/HTTP β UDP floods hit the OS, not the application.
# Combined with kernel hardening, this isolates web services from UDP attacks.
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 65535;
multi_accept on;
use epoll;
}
http {
# Aggressive timeouts to reclaim resources during attacks
keepalive_timeout 10s;
client_header_timeout 5s;
client_body_timeout 5s;
send_timeout 5s;
reset_timedout_connection on;
# Connection and rate limiting per IP
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=30r/s;
# Health check endpoint for load balancer monitoring
server {
listen 80;
server_name _;
# Quick health check β responds even under heavy load
location /health {
access_log off;
return 200 'OK';
add_header Content-Type text/plain;
}
}
server {
listen 443 ssl http2 backlog=65535;
limit_conn conn_per_ip 30;
limit_req zone=req_per_ip burst=50 nodelay;
location / {
proxy_pass http://backend;
proxy_connect_timeout 3s;
proxy_read_timeout 15s;
proxy_send_timeout 5s;
}
}
}
PowerWAF automatically blocks UDP Flood Attack at the edge.
Deploy in minutes. No code changes required. Free plan available.
Free plan spots are limited