Memcached amplification is usually described as the 51,000-times attack. That figure holds only for a reflector the attacker has first loaded with a large value, and the flood it produces arrives mostly as IP fragments that a simple port filter never sees, so a DDoS test exists to find out which of those conditions your edge actually handles. Underneath, it is the ordinary amplification attack recipe: a UDP request with the victim's address forged as its source, answered by a server that has no way to know the address is false.
What makes memcached amplification specific
Memcached is an in-memory key-value cache, built to sit on a private network next to a web tier. Until early 2018 it also listened on UDP port 11211 by default, and a large number of installs were bound to public interfaces with no authentication at all.
The part no other reflector shares is that the attacker writes the payload. Every other vector in the family abuses a reply the server was always going to give: a DNS record, an NTP monitor list, a directory's capabilities. With memcached the attacker first issues a set to store a value of their own choosing, up to the default 1 MB item limit, then sends a tiny spoofed get for that key. A single request can even name the same key several times. The reflector is not leaking data; it is returning a weapon it was handed a moment earlier.
That is where the headline comes from. Cloudflare measured a 15-byte request returning about 750 KB, a ratio a little over 51,000, and US-CERT quoted a range of 10,000 to 51,000 for the vector. An unprimed server still pays off: the stats command needs no preparation and returns a reply far larger than the request, just nowhere near the planted-value maximum. The amplification factor an attacker gets therefore depends on effort, not on the protocol alone.
Why it matters under attack
The vector's public history is one week long and still defines the ceiling. On 28 February 2018 GitHub took a 1.35 Tbps memcached flood, then the largest attack on record, and was back within about ten minutes after routing through its scrubbing provider. Days later NETSCOUT Arbor reported a 1.7 Tbps memcached attack on a US service provider. The same week, memcached 1.5.6 shipped with UDP disabled by default, and networks began filtering port 11211. The reflector pool shrank fast, which is the family's usual pattern in miniature.
The detail that catches defenders is the shape of the packets. A 750 KB reply cannot travel in one datagram, so the reflector's IP stack splits it into hundreds of fragments. Only the first fragment carries the UDP header with source port 11211; every fragment after it has no port information at all. An ACL that says "drop UDP from source port 11211" stops the first packet of each reply and waves the rest through. The effective rule has to cover non-initial fragments too, which is its own IP fragmentation problem for whatever device does the reassembly or the dropping.
Filtering also has to happen before the link. A flood measured in terabits fills any enterprise circuit long before a firewall behind it can decide anything, so the drop belongs at the provider or scrubbing tier.
What a DDoS test measures
On the receiving side, a test drives traffic shaped like reflected memcached output, including the fragment train, and checks three things. Does the upstream rule for source port 11211 exist at all. Does it catch the non-initial fragments, or only the headed ones. And when the fragments are dropped, does legitimate fragmented UDP, such as large DNS responses, get caught in the same rule.
On the outbound side the check is short and worth running every quarter: does any host in your address space answer on UDP 11211 from the internet. The fix is -U 0 to disable UDP and a bind to a private address, and a container image or old config can quietly undo both.
Fragment handling is one of several places where a filter that reads correctly on paper fails under real load, and DDoS Resilience Testing sets out the rest.