UDP DDoS amplification attacks exploit the stateless and connectionless nature of UDP to magnify attack traffic.
Here’s how it works and how to defend against it.
The Attack Chain
- Attacker: Sends a small UDP packet to a vulnerable UDP service (like DNS, NTP, CLDAP) on a spoofed source IP address (the victim’s IP).
- Vulnerable Server: Receives the small UDP packet. Because the source IP is spoofed, it thinks the request came from the victim.
- Vulnerable Server: Responds to the spoofed source IP (the victim) with a much larger UDP response.
- Victim: Is flooded with a massive volume of UDP traffic, overwhelming its network capacity.
The amplification factor can be anywhere from 20x to over 200x, meaning a small initial attack can generate a huge flood.
Common Vulnerable Services
- DNS (Domain Name System): Open DNS resolvers responding to ANY queries.
- NTP (Network Time Protocol): Monlist queries.
- CLDAP (Connectionless Lightweight Directory Access Protocol): Often found on Microsoft Active Directory servers.
- SSDP (Simple Service Discovery Protocol): Used by UPnP devices.
- Memcached: UDP port 11211.
Prevention and Mitigation Strategies
The core of prevention is to stop your network from being used as a launching pad for these attacks and to protect your own infrastructure from being the target.
1. Block Unnecessary UDP Services (External Facing)
Diagnosis: Scan your external-facing IP addresses for open UDP ports that are not essential for your business operations.
nmap -sU -p- --open <your_external_ip> -oG - | grep open
Fix: Configure your edge firewall to drop all inbound UDP traffic to non-essential ports. For example, to block UDP port 1900 (SSDP):
# Cisco ASA example
access-list OUTSIDE_IN extended deny udp any object <your_external_ip> range 1900 1900
access-group OUTSIDE_IN in interface outside
Why it works: This prevents attackers from using your servers as the origin of amplified UDP packets by ensuring no vulnerable services are exposed to the internet.
2. Rate Limit UDP Traffic (Internal and External)
Diagnosis: Monitor your network ingress for unusually high UDP traffic volumes, especially from unexpected sources or to non-standard UDP ports.
# Example using NetFlow/sFlow data analysis tools
# Look for spikes in UDP traffic volume, byte counts, and packet counts
# Filter by source IP, destination IP, and destination port
Fix: Implement rate limiting on your edge routers or firewalls for UDP traffic. For example, limit inbound UDP traffic to 1000 packets per second per source IP to non-essential services.
# Juniper SRX example (applying to an interface)
policy-options {
prefix-list UDP_NON_ESSENTIAL {
<non_essential_udp_port_1>;
<non_essential_udp_port_2>;
}
firewall-filter UDF_RATE_LIMIT {
term LIMIT_UDP {
from {
protocol udp;
destination-port [ 53 123 1900 11211 ]; # Example ports
}
then {
rate-limit {
bandwidth 10mbit; # Limit bandwidth
burst 5m;
police;
}
log;
count UDP_LIMITED;
}
}
term ALLOW_REST {
then accept;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
filter {
input UDF_RATE_LIMIT;
}
}
}
}
}
Why it works: This throttles the volume of UDP packets, making it harder for an attacker to overwhelm your network or for your servers to send out an overwhelming response.
3. IP Source Address Verification (BCP 38)
Diagnosis: Check if your network is correctly filtering outbound traffic to ensure that the source IP addresses in your packets actually belong to your network.
# This is more of a configuration audit.
# On Cisco routers:
show ip interface <interface_name> | include reverse-path
# Look for 'rp-filter' or 'unicast-reverse-path' settings.
# On Juniper routers:
show configuration firewall family inet filter <filter_name> | match policer
# Or check firewall filters for source-address-validation.
Fix: Enable Unicast Reverse Path Forwarding (uRPF) on your edge routers. For example, on Cisco IOS:
interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
ip verify unicast source
! Or for stricter mode:
! ip verify unicast source strict
Why it works: uRPF checks if the incoming packet arrived on an interface that would be used to send a reply back to the purported source IP address. If not, the packet is dropped, preventing IP spoofing originating from your network.
4. Patch and Harden UDP Services
Diagnosis: Regularly audit your servers for outdated software versions of DNS, NTP, Memcached, or other UDP-based services.
# For DNS (BIND):
named -v
# For NTP:
ntpq -p
# For Memcached:
memcached -V
Fix: Update vulnerable UDP services to their latest stable versions. For example, update BIND to the latest version and disable specific query types that are commonly exploited.
// In named.conf for BIND
options {
// ... other options
allow-query { trusted_clients; }; // Restrict who can query your DNS server
recursion no; // If not an open resolver
// For specific protection against ANY queries:
// You might need to use response rate limiting (RRL) which is more advanced.
};
Why it works: Newer versions often include security patches that disable or restrict the behavior that amplification attacks exploit, like responding to broad queries.
5. Use Network Security Appliances / DDoS Mitigation Services
Diagnosis: If you’re experiencing persistent attacks, your on-premises defenses might be insufficient.
Fix: Deploy a dedicated DDoS mitigation appliance or subscribe to a cloud-based DDoS scrubbing service. These services have massive capacity and sophisticated detection algorithms to filter malicious traffic before it reaches your network.
Why it works: These specialized solutions are designed to handle volumetric attacks by absorbing and filtering traffic at scale, far beyond what most enterprise networks can manage.
6. Block Known Malicious IP Addresses and Botnets
Diagnosis: Utilize threat intelligence feeds to identify and block IPs associated with known UDP amplification botnets.
Fix: Import IP blacklists into your firewall or IPS.
# Example concept:
# In a firewall's IP reputation list:
# Add entries from a threat feed.
# e.g., block 1.2.3.4, 5.6.7.8, ...
Why it works: Proactively blocking known malicious actors reduces the attack surface and the likelihood of becoming a target.
The Next Problem
After implementing these measures, you’ll likely start seeing an increase in log messages related to legitimate traffic being dropped by your rate-limiting rules, prompting a need to fine-tune those policies.