How Reflection and Amplification Works
UDP amplification is the most efficient class of volumetric DDoS attacks. An attacker with 1 Gbps of bandwidth can generate anywhere from 30 Gbps to 50 Tbps of attack traffic depending on the protocol abused. The technique combines two properties: reflection (bouncing traffic off third-party servers) and amplification (the response is many times larger than the request).
The attack flow works like this: the attacker crafts a small UDP request packet and sets the source IP address to the victim's IP. This is called IP spoofing. The packet is sent to a third-party server (the reflector) that runs a UDP service. The reflector processes the request and sends its response to the spoofed source IP, which is the victim. Because the response is much larger than the request, the victim receives a flood of traffic that far exceeds what the attacker actually sent.
Attacker (small request, spoofed src IP)
|
v
Reflector (legitimate server running UDP service)
|
v
Victim (receives amplified response, never sent the request)
The amplification factor is the ratio of response size to request size. A factor of 50x means a 100-byte request produces a 5,000-byte response. Multiply that across thousands of reflectors, and a botnet with modest bandwidth can saturate multi-gigabit links.
Why UDP Enables This
TCP-based protocols are not vulnerable to reflection attacks because TCP requires a three-way handshake (SYN, SYN-ACK, ACK) before any data is exchanged. A server will not send a large response until the handshake completes, and the handshake cannot complete with a spoofed IP because the SYN-ACK goes to the wrong host.
UDP has none of these protections. It is a connectionless, stateless protocol. A UDP server receives a datagram, processes it, and sends a response to whatever source IP is in the packet header. There is no verification that the source IP actually sent the request. This fundamental design choice makes every UDP service a potential amplification vector.
The attacker only needs two things: a list of reflectors running the target UDP service, and the ability to send packets with spoofed source IPs. Networks that do not implement BCP38 (ingress filtering) allow spoofed packets to leave their network, enabling the attack.
DNS Amplification (UDP Port 53)
How DNS Normally Works
The Domain Name System translates human-readable domain names into IP addresses. A client sends a query (typically 40-70 bytes) to a DNS resolver, and the resolver responds with the requested records. Most A/AAAA record lookups produce responses under 512 bytes. However, certain query types and configurations produce much larger responses.
What Gets Abused
Attackers target open recursive resolvers with ANY queries. The ANY query type requests all record types for a domain, which can include A, AAAA, MX, NS, TXT, SOA, DNSKEY, RRSIG, and more. A single ANY query for a well-configured domain with DNSSEC signatures can return 3,000 to 4,000 bytes. With EDNS0 (Extended DNS) enabled, responses can reach 4,096 bytes.
# Attacker's query (spoofed source IP) dig ANY isc.org @open-resolver-ip # Typical request size: ~64 bytes # Typical response size: ~3,400 bytes # Amplification factor: ~54x
Amplification Factor
DNS amplification typically achieves 28x to 54x depending on the domain queried and whether DNSSEC is enabled. DNSSEC-signed zones produce larger responses because cryptographic signatures (RRSIG records) and DNSKEY records add substantial data. There are an estimated 2.5 million open DNS resolvers on the internet, giving attackers a massive reflector pool.
Detection Signatures
DNS amplification traffic arrives as UDP packets from source port 53 with the DNS response flag set. The victim never sent the corresponding queries. Key indicators:
- Flood of inbound UDP from source port 53
- DNS response flag (QR=1) without matching outbound queries
- Average response size exceeding 2,000 bytes
- Responses from many different source IPs (the reflectors), all from port 53
# tcpdump filter for DNS amplification $ tcpdump -nn 'udp src port 53 and udp[10] & 0x80 != 0' -c 10 15:42:18.331 IP 8.8.4.4.53 > 198.51.100.10.39211: 65412*- 18/0/1 (3847) 15:42:18.332 IP 208.67.222.222.53 > 198.51.100.10.48102: 65412*- 18/0/1 (3512) 15:42:18.332 IP 9.9.9.9.53 > 198.51.100.10.51887: 65412*- 18/0/1 (3847) # Wireshark display filter dns.flags.response == 1 && udp.length > 2000
NTP Amplification (UDP Port 123)
How NTP Normally Works
The Network Time Protocol synchronizes clocks across computer networks. NTP clients send small time-request packets to NTP servers, which respond with the current time. Standard NTP traffic is lightweight, with request and response packets both around 48-90 bytes. However, NTP includes monitoring commands that produce much larger responses.
What Gets Abused
The monlist command (also called MON_GETLIST_1) is the primary attack vector. This monitoring command was designed for NTP server administrators to see a list of the last 600 clients that contacted the server. A single 234-byte monlist request can return up to 100 response packets, each containing 6 client records with IP addresses, ports, and timestamps. The total response can exceed 48 KB.
# Attacker's monlist request (spoofed source IP) ntpdc -n -c monlist ntp-server-ip # Request size: ~234 bytes # Response size: ~48,000+ bytes (up to 100 packets) # Amplification: ~556x
Amplification Factor
NTP monlist amplification reaches approximately 556x, making it one of the highest amplification factors among common protocols. The factor depends on how many clients the NTP server has recently served. A busy NTP server that has communicated with 600 unique clients will produce the maximum response. Even servers with fewer clients still achieve factors above 100x.
Detection Signatures
NTP amplification traffic arrives as a burst of UDP packets from source port 123. The response packets contain NTP mode 7 (private) data, which is distinct from standard NTP mode 3 (client) or mode 4 (server) time synchronization packets.
- Flood of inbound UDP from source port 123
- NTP mode 7 (private/monlist) response packets
- Packet sizes of 440-480 bytes each, arriving in rapid bursts
- Multiple response packets from the same source IP per "query"
# tcpdump filter for NTP amplification $ tcpdump -nn 'udp src port 123 and udp[8:1] & 0x7 == 7' -c 10 09:14:22.718 IP 192.0.2.50.123 > 198.51.100.10.41233: NTPv2, Reserved, length 440 09:14:22.718 IP 192.0.2.50.123 > 198.51.100.10.41233: NTPv2, Reserved, length 440 09:14:22.719 IP 203.0.113.25.123 > 198.51.100.10.41233: NTPv2, Reserved, length 440 # Wireshark display filter ntp.priv.reqcode == 42 && udp.srcport == 123
Memcached Amplification (UDP Port 11211)
How Memcached Normally Works
Memcached is an in-memory caching system used to speed up database-driven web applications. It stores key-value pairs in RAM for fast retrieval. Memcached was designed for use on trusted internal networks and was never intended to be exposed to the internet. However, many installations accidentally expose UDP port 11211 to the public internet, especially in cloud environments with permissive default security groups.
What Gets Abused
Attackers use the stats command or get commands against keys they have previously seeded. In the most devastating variant, the attacker first connects to an exposed memcached server and stores a large value (up to 1 MB per key) under a known key. They then send spoofed UDP get requests for that key. The memcached server responds with the full stored value, directed at the victim.
# Step 1: Attacker seeds a large value (from their real IP)
echo -e "set amplify 0 60 750000\r\n$(python3 -c 'print("A"*750000)')\r\n" | nc -u target 11211
# Step 2: Attacker sends spoofed get request
# Request: "get amplify\r\n" = 15 bytes
# Response: 750,000 bytes
# Amplification: ~50,000x
Amplification Factor
Memcached holds the record for the highest amplification factor of any known protocol: approximately 50,000x. This extraordinary factor was demonstrated in the February 2018 attack on GitHub, which peaked at 1.35 Tbps, and in a subsequent attack that reached 1.7 Tbps. The factor is so high because memcached can store values up to 1 MB, while the get request is only 15 bytes. Even without pre-seeding, the stats command produces responses of 10-50 KB from a single request, yielding factors of 10,000x to 50,000x.
Detection Signatures
Memcached amplification traffic is distinctive because it arrives from UDP source port 11211, a port that has almost no legitimate reason to appear in inbound traffic for most organizations.
- Flood of inbound UDP from source port 11211
- Packets containing ASCII memcached protocol responses ("VALUE", "STAT", "END")
- Individual packets up to 1,400 bytes (MTU-limited fragments of larger responses)
- IP fragmentation common due to large response sizes
# tcpdump filter for memcached amplification $ tcpdump -nn 'udp src port 11211' -c 10 11:05:33.201 IP 203.0.113.44.11211 > 198.51.100.10.32901: UDP, length 1400 11:05:33.201 IP 203.0.113.44.11211 > 198.51.100.10.32901: UDP, length 1400 11:05:33.202 IP 192.0.2.88.11211 > 198.51.100.10.32901: UDP, length 1400 # Wireshark display filter udp.srcport == 11211 # Check for fragmented packets (common with memcached) ip.flags.mf == 1 && udp.srcport == 11211
The GitHub memcached attack in 2018 was mitigated within 10 minutes because GitHub used Akamai Prolexic for DDoS protection. Without upstream scrubbing, a 1.35 Tbps memcached flood would overwhelm virtually any single-homed network.
CLDAP Amplification (UDP Port 389)
How CLDAP Normally Works
Connection-less Lightweight Directory Access Protocol (CLDAP) is a UDP variant of LDAP used primarily by Microsoft Active Directory for domain controller discovery. When a Windows client joins a network, it broadcasts CLDAP queries on UDP port 389 to locate domain controllers. The protocol is intended for internal network use only, but thousands of Active Directory servers expose UDP port 389 to the internet.
What Gets Abused
Attackers send a small CLDAP search request (typically a rootDSE query) with a spoofed source IP. The domain controller responds with detailed information about the Active Directory environment, including the domain name, site name, server name, supported LDAP versions, and supported SASL mechanisms. This response is 56 to 70 times larger than the request.
# CLDAP rootDSE query (using ldapsearch syntax) # The actual attack uses raw UDP packets with spoofed source ldapsearch -H cldap://target:389 -x -s base "" defaultNamingContext # Request size: ~56 bytes # Response size: ~3,100-3,900 bytes # Amplification: ~56-70x
Amplification Factor
CLDAP amplification achieves 56x to 70x, placing it among the higher-factor protocols. CLDAP gained significant attention in February 2020 when AWS reported mitigating a 2.3 Tbps DDoS attack that used CLDAP reflection as its primary vector. This remains one of the largest publicly disclosed DDoS attacks in history. Shodan scans consistently find between 200,000 and 300,000 CLDAP reflectors exposed to the internet, most of them Windows Server machines running Active Directory.
Detection Signatures
CLDAP amplification arrives as UDP traffic from source port 389. The payload contains ASN.1/BER-encoded LDAP response data. For most organizations, inbound UDP from port 389 is entirely unexpected.
- Flood of inbound UDP from source port 389
- BER-encoded LDAP search response data in the payload
- Response packets typically 3,000-4,000 bytes
- Source IPs predominantly from enterprise Windows Server environments
# tcpdump filter for CLDAP amplification $ tcpdump -nn 'udp src port 389' -c 10 14:28:55.901 IP 10.20.30.40.389 > 198.51.100.10.52810: UDP, length 3124 14:28:55.902 IP 172.16.0.55.389 > 198.51.100.10.52810: UDP, length 3891 14:28:55.902 IP 10.50.60.70.389 > 198.51.100.10.52810: UDP, length 3340 # Wireshark display filter udp.srcport == 389 && ldap
SSDP Amplification (UDP Port 1900)
How SSDP Normally Works
The Simple Service Discovery Protocol (SSDP) is part of the Universal Plug and Play (UPnP) protocol suite. It allows devices on a local network to discover each other automatically. When a new device joins the network, it sends an M-SEARCH multicast request on UDP port 1900, and all UPnP-enabled devices respond with their service descriptions. SSDP is used by routers, smart TVs, printers, gaming consoles, IP cameras, and many IoT devices.
What Gets Abused
Attackers send a unicast M-SEARCH request with ssdp:all or ssdp:rootdevice as the search target. Devices that accept this request from the internet respond with their full service description, which includes device type, manufacturer, model, UUID, and a list of all available services with their URLs. Some devices respond with multiple packets because they advertise many services.
# M-SEARCH request (spoofed source IP) M-SEARCH * HTTP/1.1 Host: target:1900 Man: "ssdp:discover" MX: 3 ST: ssdp:all # Request size: ~100 bytes # Response size: ~3,000 bytes (often multiple responses per device) # Amplification: ~30x
Amplification Factor
SSDP amplification achieves approximately 30x per device. However, some devices respond with multiple NOTIFY packets for each service they advertise, which can push the effective factor higher. The real danger of SSDP is the reflector count: there are millions of UPnP-enabled consumer devices exposed to the internet. Many of these are home routers, cable modems, and IoT devices that their owners do not know are accessible. Conservative estimates place the number of exploitable SSDP reflectors at over 5 million.
Detection Signatures
SSDP amplification traffic consists of HTTP-like text responses from UDP source port 1900. The responses contain UPnP device descriptions with headers like SERVER:, USN:, and LOCATION:.
- Flood of inbound UDP from source port 1900
- HTTP-formatted responses with UPnP headers in the payload
- Source IPs from consumer ISP address space (home routers, IoT devices)
- Packet sizes typically 300-500 bytes each, but many packets per reflector
# tcpdump filter for SSDP amplification $ tcpdump -nn 'udp src port 1900' -c 10 20:17:44.102 IP 24.56.78.90.1900 > 198.51.100.10.39402: UDP, length 347 20:17:44.102 IP 71.12.34.56.1900 > 198.51.100.10.39402: UDP, length 412 20:17:44.103 IP 98.76.54.32.1900 > 198.51.100.10.39402: UDP, length 389 # Wireshark display filter udp.srcport == 1900 && ssdp
Protocol Comparison Table
Here is a side-by-side comparison of the five major UDP amplification protocols:
| Protocol | Port | Amplification | Response Size | Est. Reflectors |
|---|---|---|---|---|
| DNS | 53 | 28-54x | 2,000-4,096 bytes | ~2.5 million |
| NTP | 123 | ~556x | ~48,000 bytes | ~30,000 |
| Memcached | 11211 | ~50,000x | up to 1 MB | ~50,000 |
| CLDAP | 389 | 56-70x | 3,000-4,000 bytes | ~250,000 |
| SSDP | 1900 | ~30x | 300-500 bytes each | ~5 million |
The amplification factor alone does not determine the severity of an attack. Memcached has the highest factor, but the number of available reflectors is relatively low (around 50,000) because most operators have patched or firewalled their installations since the 2018 attacks. DNS and SSDP have lower factors but vastly more reflectors, making them consistently high-volume vectors.
Is Your Server an Open Reflector?
If you operate servers on the internet, you should verify that they are not being used as amplification reflectors. Here are commands to test each service from an external host:
DNS (Port 53)
# Test if your server accepts recursive queries from external IPs dig @your-server-ip ANY isc.org +norecurse # If you get a full response with multiple records, your server is an open resolver # Check with nmap nmap -sU -p 53 --script dns-recursion your-server-ip
NTP (Port 123)
# Test if monlist is enabled ntpdc -n -c monlist your-server-ip # If you get a list of recent clients, monlist is enabled and exploitable # Alternative using ntpq ntpq -c rv your-server-ip
Memcached (Port 11211)
# Test if UDP memcached is accessible echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -u -w 2 your-server-ip 11211 # If you get stats output, your memcached UDP port is open # Quick port check nmap -sU -p 11211 your-server-ip
CLDAP (Port 389)
# Test if CLDAP responds to external queries ldapsearch -H ldap://your-server-ip:389 -x -s base "" defaultNamingContext 2>/dev/null # If you get AD information back, your CLDAP is exposed # UDP port check nmap -sU -p 389 your-server-ip
SSDP (Port 1900)
# Test for SSDP response echo -e "M-SEARCH * HTTP/1.1\r\nHost:your-server-ip:1900\r\nMan:\"ssdp:discover\"\r\nST:ssdp:all\r\nMX:3\r\n\r\n" | nc -u -w 5 your-server-ip 1900 # If you get UPnP device descriptions, SSDP is exposed
Only test servers you own or have explicit authorization to test. Sending probes to servers you do not control may violate computer fraud laws in your jurisdiction.
Defense Strategies
BCP38 and BCP84: Source Address Validation
The root cause of all UDP amplification attacks is source IP spoofing. BCP38 (RFC 2827) and BCP84 (RFC 3704) define network ingress filtering that prevents packets with spoofed source addresses from leaving a network. If every ISP and hosting provider implemented BCP38, reflection attacks would be impossible. In practice, adoption is incomplete, but implementing it on your own network prevents your infrastructure from being used as an attack source.
# Example: BCP38 on a Linux router (eth0 = upstream, eth1 = internal 10.0.0.0/24) iptables -A FORWARD -i eth1 -s ! 10.0.0.0/24 -j DROP # Enable reverse path filtering (kernel-level BCP38) sysctl -w net.ipv4.conf.all.rp_filter=1 sysctl -w net.ipv4.conf.default.rp_filter=1
Block Unnecessary UDP Services
If your server does not need to run DNS, NTP, memcached, LDAP, or UPnP services, firewall off the corresponding ports. Even if the software is not installed, blocking the ports prevents future accidental exposure.
# Block common amplification source ports (inbound) iptables -A INPUT -p udp --sport 19 -j DROP # chargen iptables -A INPUT -p udp --sport 53 -j DROP # DNS (if not needed) iptables -A INPUT -p udp --sport 123 -j DROP # NTP monlist iptables -A INPUT -p udp --sport 389 -j DROP # CLDAP iptables -A INPUT -p udp --sport 1900 -j DROP # SSDP iptables -A INPUT -p udp --sport 11211 -j DROP # memcached
If you do run these services, restrict them to trusted networks or specific interfaces. For memcached, disable UDP entirely (it defaults to TCP-only in versions 1.5.6+). For NTP, disable the monlist command by adding disable monitor to your ntp.conf. For DNS, disable open recursion by restricting allow-recursion to your own IP ranges.
Rate Limiting at the Network Edge
Rate limiting inbound UDP traffic from known amplification ports provides a useful defense layer, especially when combined with connection tracking:
# Rate limit DNS responses to 100/sec (allow established connections) iptables -A INPUT -p udp --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT iptables -A INPUT -p udp --sport 53 -m limit --limit 100/sec --limit-burst 200 -j ACCEPT iptables -A INPUT -p udp --sport 53 -j DROP
Flowtriq Detection
Flowtriq detects all five amplification protocols automatically with no configuration required. The agent monitors per-second PPS and bandwidth metrics, protocol distribution ratios, and source port entropy. When an amplification attack begins, Flowtriq identifies the attack type within 1-2 seconds and sends an alert through your configured notification channels. The classification engine labels the specific amplification protocol (DNS, NTP, memcached, CLDAP, or SSDP) so your response team knows exactly what they are dealing with.
For attacks that exceed your link capacity, Flowtriq provides PCAP evidence that you can share with your upstream provider to expedite BGP blackhole or scrubbing activation. The incident timeline shows exactly when the attack started, which amplification vector was used, and how the traffic volume evolved over time.
Detect amplification attacks in real time. Flowtriq classifies DNS, NTP, memcached, CLDAP, and SSDP amplification automatically. Start your free 7-day trial at $9.99/mo per node and see attack classification in action within minutes of deployment.