Skip to main content
HighProtected by PowerWAF

UDP Flood Attack

CategoryDDoSFirst seen2000Read time9 minVerified2026-03-11
DEFINITION

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.

1

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.

2

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.

3

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.

4

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.

5

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

2007

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.

2021

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.

2024

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

Mitigation: Linux kernel and iptables hardening against UDP floods
# === 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
Detection: Real-time UDP flood monitoring with alerting
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()
Mitigation: Nginx as TCP/HTTP absorber unaffected by UDP floods
# 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

Frequently Asked Questions

UDP is connectionless β€” the sender transmits packets without establishing a session, negotiating parameters, or waiting for acknowledgments. This means: (1) no three-way handshake consumes the attacker's resources, (2) source IP spoofing is trivial because no return traffic needs to reach the attacker, (3) the attacker can send at line rate without back-pressure from the protocol, and (4) generating attack traffic requires minimal code β€” a raw socket sending UDP datagrams in a loop. In contrast, TCP attacks like SYN floods require crafting valid TCP headers with proper sequence numbers, and application-layer attacks (HTTP floods) require completing TCP handshakes. The simplicity of UDP floods makes them the default choice for booter/stresser services and amateur attackers.
RFC 1122 requires that when a UDP packet arrives at a port where no application is listening, the host SHOULD respond with an ICMP Destination Unreachable (Type 3, Code 3 β€” Port Unreachable) message. This is designed to inform legitimate senders that their packets aren't reaching any application. During a UDP flood, this behavior becomes harmful: the victim generates one ICMP response for every UDP packet hitting a closed port, consuming CPU for ICMP generation and consuming outbound bandwidth to send those responses. A 10 Gbps inbound UDP flood to random ports could generate 2-3 Gbps of outbound ICMP traffic. Disabling or rate-limiting ICMP Port Unreachable responses (Linux: sysctl net.ipv4.icmp_ratemask or iptables rules) is an essential flood mitigation step.
Yes, in two ways. First, bandwidth saturation is protocol-agnostic β€” a 10 Gbps UDP flood saturating a 10 Gbps link blocks all traffic including TCP (HTTP, HTTPS, SSH, email). The UDP packets crowd out legitimate TCP packets in the network pipe. Second, stateful devices along the path (firewalls, IDS/IPS) create conntrack entries for each unique UDP flow. When the conntrack table fills, these devices drop all new connections including TCP, causing web servers, APIs, and other TCP services to become unreachable even though they're not directly targeted. This is why UDP floods are often called 'pipe flooding' attacks β€” they attack the infrastructure, not the application.
Gaming servers face a unique challenge: they must accept UDP traffic from unknown sources (new players connecting) while filtering attacks. Common defenses include: challenge-response authentication where the server sends a small UDP challenge packet and only processes further traffic from IPs that respond correctly (proving they can receive traffic, which spoofed IPs cannot); protocol validation that drops packets not matching the expected game protocol format; geographic filtering that restricts connections to regions where the game operates; per-IP rate limiting at the network layer; and dedicated DDoS mitigation proxies that absorb volumetric attacks and forward only validated game traffic. Some game publishers run their own anycast networks to absorb floods across geographically distributed points of presence.
Traditional WAFs operate at the HTTP/application layer (Layer 7) and inspect web requests β€” they don't process raw UDP packets. However, comprehensive DDoS protection platforms like PowerWAF include network-layer mitigation that detects UDP flood patterns (sudden volume spikes, high source entropy, random destination ports) and filters malicious UDP traffic at the network edge before it reaches protected infrastructure. This combined approach provides defense at both the network layer (against volumetric UDP/TCP floods) and the application layer (against HTTP floods, bot attacks, and injection).