UDP flood mitigation:
techniques that actually work

Back to Blog

Understanding UDP Floods

A UDP flood attack sends a massive volume of UDP packets to random or specific ports on a target server. Because UDP is connectionless, there is no handshake requirement - the attacker simply blasts packets as fast as their bandwidth allows. The target's network stack must process each packet to determine whether an application is listening on the destination port. When no application is listening, the server generates an ICMP "Destination Unreachable" response for each packet, consuming CPU and bandwidth in both directions.

UDP floods are effective because they are simple to execute and difficult to filter without also affecting legitimate UDP traffic. Unlike TCP-based attacks where SYN cookies and connection tracking provide built-in defenses, UDP has no equivalent mechanism. The server must inspect every packet individually.

Types of UDP Floods

• Random port flood: Packets are sent to random destination ports, forcing the server to check each port and generate ICMP unreachable responses. This is the most basic UDP flood.
• Amplification flood: The attacker uses reflectors (open DNS, NTP, memcached, SSDP servers) to amplify their traffic. See our guides on DNS amplification and memcached amplification.
• Application-specific flood: Packets target a specific UDP service (like a game server on a known port) with valid-looking but malicious payloads designed to consume application resources.
• Fragmentation flood: Oversized UDP packets that force IP fragmentation, consuming reassembly buffer memory on the target.

Host-Level Mitigation with iptables

Drop Traffic to Unused UDP Ports

The simplest and most effective first step: if your server does not run any UDP services, drop all inbound UDP except DNS responses. Most web servers only need TCP on ports 80 and 443.

# Allow DNS responses (we initiated the queries)
iptables -A INPUT -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Allow specific UDP services you actually use (e.g., WireGuard VPN)
iptables -A INPUT -p udp --dport 51820 -j ACCEPT

# Drop everything else UDP
iptables -A INPUT -p udp -j DROP

Rate-Limit UDP Per Source IP

For servers that need UDP services exposed (game servers, VoIP, DNS), rate limiting per source IP prevents any single attacker from overwhelming the service:

# Limit each source IP to 100 UDP packets/second
iptables -A INPUT -p udp -m hashlimit \
  --hashlimit-above 100/sec \
  --hashlimit-burst 150 \
  --hashlimit-mode srcip \
  --hashlimit-name udp_limit \
  -j DROP

Limit ICMP Unreachable Responses

When UDP packets hit closed ports, the kernel generates ICMP unreachable messages. During a flood, this wastes outbound bandwidth. Rate-limit these responses:

# Limit ICMP unreachable to 10/second
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

Modern Mitigation with nftables

nftables is the successor to iptables and offers better performance and cleaner syntax. Here is an equivalent UDP flood mitigation ruleset:

table inet filter {
  set udp_meter {
    type ipv4_addr
    flags dynamic,timeout
    timeout 30s
  }

  chain input {
    type filter hook input priority 0; policy drop;

    # Allow established connections
    ct state established,related accept

    # Allow loopback
    iif lo accept

    # Allow SSH, HTTP, HTTPS
    tcp dport { 22, 80, 443 } accept

    # Rate-limit UDP per source IP (100/sec)
    udp dport != 53 update @udp_meter { ip saddr limit rate 100/second } accept
    udp dport != 53 drop

    # Allow DNS responses for our queries
    udp sport 53 ct state established accept
  }
}

Kernel-Level Tuning

Linux kernel parameters can improve resilience against UDP floods by adjusting buffer sizes and connection tracking behavior:

# Increase receive buffer size to handle burst traffic
net.core.rmem_max = 67108864
net.core.rmem_default = 33554432

# Increase connection tracking table
net.netfilter.nf_conntrack_max = 1048576

# Reduce conntrack timeout for UDP (default 30s is too long during floods)
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 30

# Increase the backlog for incoming packets
net.core.netdev_max_backlog = 50000

Kernel tuning buys you headroom but cannot save you from a flood that exceeds your link capacity. These settings help your server process legitimate traffic under load but they are not a substitute for upstream mitigation.

Upstream Mitigation

ISP-Level Filtering

For floods that exceed your server's processing capacity or link bandwidth, mitigation must happen upstream. Contact your ISP or hosting provider and request UDP filtering at their edge. Most providers can apply ACLs that drop specific UDP traffic patterns before they reach your port.

Scrubbing Services

DDoS scrubbing services (Cloudflare Spectrum, AWS Shield, Akamai Prolexic) route your traffic through their global networks, filter out attack traffic, and forward clean traffic to your origin. For UDP-heavy services like game servers, choose a scrubbing provider that supports UDP passthrough with filtering.

BGP Blackhole Routing

As a last resort for attacks that threaten to affect other customers on shared infrastructure, request a BGP blackhole for the attacked IP prefix. This drops all traffic (legitimate and attack) to the targeted IP at the network edge, protecting the rest of your infrastructure.

Detection Is the Foundation

Every mitigation strategy depends on detecting the attack first. Flowtriq detects UDP floods within one second by monitoring PPS rates, protocol distribution, and packet size patterns. The classification engine distinguishes between random UDP floods, amplification attacks, and application-specific floods so you know exactly which mitigation rules to apply.

Start your free 7-day trial and see UDP flood detection in action.

Back to Blog

Related Articles