Memcached amplification: detection,
evidence & what to tell your upstream

Back to Blog

The 50,000x Amplification Factor: How It Actually Works

Amplification attacks exploit the asymmetry between the size of a request and the size of the response. The attacker sends a small request packet with the source IP spoofed to the victim's address. The server receiving the request sends a much larger response to the spoofed IP — the victim. The victim's network receives massive response traffic without ever sending a single request.

Memcached (the distributed memory caching daemon, widely deployed as a backend cache layer) is particularly severe because of how it handles the stats command. A memcached UDP request for statistics is 15 bytes. The response containing all statistics can be up to 750 kilobytes. That is a bandwidth amplification factor of 50,000x. An attacker with a 1 Gbps upstream connection can direct 50 Tbps of traffic at a target if they have access to enough exposed memcached servers.

The February 2018 attack against GitHub peaked at 1.35 Tbps and used exactly this mechanism. It was generated by approximately 30,000 exposed memcached servers. Shodan routinely finds 80,000+ internet-exposed memcached instances with UDP enabled.

What the Traffic Looks Like at the Packet Level

Memcached amplification traffic has a distinctive packet signature that makes it one of the easier attack types to positively identify:

• Protocol: UDP exclusively (memcached over UDP, not TCP)
• Source port: 11211 (the memcached default port, always)
• Destination port: variable, typically random high-numbered port on the victim
• Packet size: 1,400–1,500 bytes (maximum-size UDP datagrams; responses are fragmented at the IP layer)
• Source IPs: globally distributed, belonging to legitimate hosting providers and enterprises with exposed memcached instances
• TTL distribution: wide spread (different reflectors are at different network distances from the victim)

# Confirm memcached amplification in tcpdump
tcpdump -nn -i eth0 'udp src port 11211' -c 100

# Expected output during attack:
# 09:14:22.001122 IP 52.8.211.74.11211 > 203.0.113.5.54123: UDP, length 1400
# 09:14:22.001344 IP 104.21.14.55.11211 > 203.0.113.5.54123: UDP, length 1400
# 09:14:22.001891 IP 185.146.232.12.11211 > 203.0.113.5.12847: UDP, length 1400

# Check for IP fragmentation (common with large memcached responses)
tcpdump -nn -i eth0 'ip[6:2] & 0x2000 != 0 or ip[6:2] & 0x1fff != 0' -c 50

The immediate tell is the source port. Legitimate memcached UDP traffic from a server to a client would have a destination port of 11211, not a source port of 11211. Seeing UDP traffic with source port 11211 arriving at your server, which is almost certainly not running a memcached client, means you are receiving amplified responses directed at you by an attacker.

Distinguishing Amplification from Legitimate Memcached Traffic

If your server legitimately connects to a remote memcached instance, you will see traffic with destination port 11211 (outbound from your server). Amplification attack traffic has source port 11211 and destination port something-else. The directionality is completely opposite:

# Legitimate memcached client traffic (your server talking to cache)
# src=YOUR_IP:random_ephemeral  dst=CACHE_SERVER:11211

# Amplification attack traffic (responses directed at you)
# src=REFLECTOR_IP:11211  dst=YOUR_IP:random_port

# Quick one-liner to confirm attack direction
tcpdump -nn -i eth0 -c 200 'udp port 11211' 2>/dev/null | \
  awk '{
    if ($3 ~ /\.11211/) print "LEGIT (outbound to cache):", $3, "->", $5
    if ($5 ~ /\.11211/) print "ATTACK (inbound amplification):", $3, "->", $5
  }' | sort | uniq -c | sort -rn | head -10

Immediate iptables Mitigation

The good news about memcached amplification from a local mitigation standpoint is that it is trivially easy to drop with iptables. Since all attack traffic arrives with source port 11211 over UDP, and your server almost certainly does not run a memcached client pointed at internet-facing servers, a single rule drops all of it:

# Drop all incoming UDP from source port 11211 (memcached reflectors)
iptables -I INPUT -p udp --sport 11211 -j DROP

# Verify the rule is counting hits
iptables -nvL INPUT | grep "sport 11211"
# Example: 1843792  2621M DROP  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp spt:11211

This rule will not stop the attack at the source — the traffic is still arriving at your network edge and saturating your uplink. But it will stop your server's CPU and kernel network stack from processing the packets, which preserves server availability while you work on upstream mitigation. The counter on the rule (1843792 packets in the example above) is also useful evidence for your ISP.

If memcached amplification is saturating your uplink, local iptables rules cannot help — the traffic fills the pipe before it reaches your server. In that scenario, you need upstream mitigation immediately. The local rule is still useful to pre-stage so it is ready when scrubbing begins and some attack traffic still gets through.

Capturing PCAP Evidence for Your Upstream

When you contact your upstream provider for null-routing or scrubbing, they will ask for a packet capture. The capture needs to demonstrate the attack signature clearly. For memcached amplification, a 200-packet sample is sufficient because the signature is so consistent:

# Capture 200 attack packets to a file
tcpdump -nn -i eth0 'udp src port 11211' -c 200 -w /tmp/memcached_attack_$(date +%s).pcap

# If link is saturated and tcpdump cannot run, use Flowtriq's PCAP download
# from the incident page in the dashboard — it has a pre-attack buffer included

Flowtriq maintains a rolling 500-packet capture buffer. When the PPS anomaly threshold fires, the PCAP file already contains packets from before the attack crossed the detection threshold, giving you baseline traffic as context alongside the attack traffic. The file is immediately available for download from the incident page.

What to Tell Your Upstream NOC

Upstream NOC and abuse teams deal with dozens of mitigation requests a day. The faster you give them everything they need in the first message, the faster they act. Here is the exact template to use for a memcached amplification attack:

The key details are the attack type, target IP, attack start time (in UTC, not local time), and the specific filter rule they can apply. An upstream engineer can configure "drop UDP source port 11211 destined to X.X.X.X" on an edge router in under two minutes if you hand them that sentence directly.

Flowtriq's alert emails include a pre-formatted incident summary with all of this information populated automatically. The alert body includes the attack type as classified by Flowtriq's detection engine, the PPS and estimated bandwidth, and a direct download link to the PCAP file. Many customers forward the Flowtriq alert directly to their ISP NOC with the PCAP attached and get mitigation activated within 5–10 minutes.

Long-Term: Eliminating Your Exposure as a Reflector

If you run memcached yourself, the most important thing you can do for the internet (and your own liability) is to disable UDP on your memcached instances. The text-based stats protocol that enables amplification only works over UDP. Disabling UDP does not affect normal application usage because memcached client libraries use TCP by default:

# Disable UDP in memcached (add to /etc/memcached.conf)
# -U 0 disables the UDP port entirely
-U 0

# Or pass at runtime
memcached -U 0 -p 11211 -m 512 -d

# Confirm UDP is not listening
ss -ulnp | grep 11211
# Should return nothing if UDP is disabled

Also ensure memcached is bound only to localhost or internal network interfaces, never to 0.0.0.0 on an internet-facing host. A memcached instance exposed to the internet with UDP enabled is an amplification weapon waiting to be used.

Back to Blog

Related Articles