Bridge WAF
Memcached DDoS: an exposed cache is two problems
A caching server reachable from the internet can be made to send large replies to an address that never asked for them, and the same exposure lets anyone read what the cache holds. The traffic problem belongs to whoever receives the replies; the disclosure problem belongs to whoever left the cache open, and it is usually the more serious.
Quick facts
- Layer
- Network (3) and transport (4)
- Vector
- Forged requests to exposed caching servers, replies sent to you
- Goal
- Saturate the link with unrequested replies
- In your logs
- Inbound traffic from a cache service you never queried
- Does a WAF stop it?
- No. The traffic never becomes a request
The reasoning is the same as for every attack in this family and is set out on attack layers.
Why this vector is different from the others
Amplification always depends on a reply being larger than a request. What distinguishes this case is that the size of the reply is not fixed by the protocol.
With a time service, the response is whatever that service produces. With a cache, the response is whatever the cache holds, and a cache holds what was put into it. An amplifier whose output size is not bounded by protocol design behaves differently from one where it is, and that difference is the entire reason this vector attracted attention.
Two design properties made exposure common. The software was built for communication inside a trusted network, so authentication was not part of the model. And it historically accepted connectionless traffic by default, which is the property amplification needs, since a request with a forged return address gets answered to that address.
Current builds ship with that default reversed, so the exposed population comes from older deployments and from configurations written when the default was different.
The problem that is worse than the traffic
If your cache is reachable from the internet, someone else's outage is not your largest concern.
A cache with no authentication returns what it stores to anyone who asks. Sessions, tokens, query results, fragments of pages assembled for particular users: whatever the application put there is readable, and reading it leaves no trace in the application's own logs, because the application was not involved.
This is why the recommendation below is not "rate limit" but "do not expose it". The amplification is a symptom. The exposure is the defect, and it has consequences that continue after the attack traffic stops.
The check worth running today
Three questions, answerable without any tooling beyond what you already have.
What interface is it listening on? A cache should be bound to a loopback or private interface. If it is bound to every interface, the question of whether a firewall happens to be in front of it becomes the only thing protecting it.
Is connectionless traffic accepted? Where the deployment predates the current defaults, this may still be enabled and unused. Turning it off removes the amplification property entirely while changing nothing about how applications use the cache.
Can anything outside your own network reach the port? Confirm from outside rather than by reading configuration. Configuration describes intent; a connection test describes reality, and the two diverge in the cases that matter.
Why exposed caches keep appearing
The population of open caches shrinks slowly, and understanding why turns the check above into a routine rather than a one-off.
Caches are added during development, on a machine that was never meant to face the internet, and the exposure arrives later when that machine moves, gets a public address, or has a firewall rebuilt without the rule that was protecting it. Nothing in the application changes, nothing fails, and nobody has a reason to look.
Container and orchestration setups add a second path to the same outcome. A service published for convenience during testing behaves identically in production, and the mapping that exposes it is a line of configuration rather than a visible decision.
The common factor is that exposure is never announced. A cache that is suddenly reachable from everywhere works as well as one that is not, which is why the only reliable detection is a deliberate check from outside.
Recognising it as the victim
Two signals, the same as for other reflection vectors.
Replies you never requested, arriving from a service port you do not use, from many distinct sources.
Sources that genuinely exist. They are real servers, misconfigured rather than compromised, and blocking them individually is an endless task with no end state.
Because the reply size is unusually large in this vector, the traffic tends to saturate a link with fewer participating sources than other reflection techniques require. From the receiving side that changes nothing about the response.
Mitigation by layer
Four measures, split by which role you are in.
As the victim: filter upstream. Replies from a protocol you never query can be discarded before your link, and this is a rule a connectivity provider can apply quickly. Nothing on your server helps.
As the victim: have capacity in front of you. Absorbing volume is infrastructure, as it is for the whole family.
As an operator: bind the cache privately and firewall the port. This single change removes both problems, the traffic one and the disclosure one.
As an operator: disable connectionless traffic and require authentication where the deployment supports it. Defence in depth for the case where a firewall rule is removed by someone who does not know why it was there.
What does not help: request inspection, rules, and challenges, for the usual reason that nothing here becomes a request.
Where the platform sits
Bridge WAF operates at the application layer and does not address traffic of this kind. What applies is termination: when visitors reach your site through the platform's edge, the address receiving reflected traffic is not your origin's, and volume is absorbed by the platform's capacity rather than your link's. What no platform can do is fix an exposed cache, which is a configuration question on your own infrastructure. See what the platform offers at Bridge CDN.
Questions
What is a memcached DDoS attack?
An attack in which requests carrying a forged return address are sent to caching servers exposed to the internet, so their much larger replies are delivered to the address on the forgery. The caches are victims of a kind too, spending their own capacity on it.
Does a WAF stop it?
No. The traffic arrives as volume and never becomes an application request, so there is nothing for inspection to act on. As with every attack in this family, the answer is upstream capacity and filtering rather than anything running behind the link.
Why are the replies so large?
Because a cache returns whatever it was asked to store, so the size of a reply is set by its contents rather than fixed by the protocol as it is for most services. That is what distinguishes this family from amplification through services with bounded answers.
Is my own cache at risk?
If it answers from the internet, yes, and the more serious problem is not the traffic. A cache of this kind expects to sit on a trusted network, so anything reachable from outside will also hand its contents to whoever asks, which is a data exposure rather than a capacity one.
How do I check?
Three things, in order: which interface the service listens on, whether it accepts connectionless traffic at all, and whether the port answers from outside your own network. The last is the only one that settles it, because a binding that looks internal can still be exposed by what sits in front.
Does authentication solve it?
It helps and it is not the answer. Requiring credentials narrows who can retrieve data, but the service still answers strangers enough to be used, and the design assumption was always a trusted network. Keeping it off the public internet is the measure that actually holds.
It does not address traffic of this kind, and no platform fixes an exposed cache. That one is yours.
off
No request is inspected. Reflected volume never becomes a request either way.
monitor
Matches are recorded on requests, which these replies never become.
block
Refusal applies at the request layer, above the one this attack fills.
The firewall layer is included with Bridge CDN. Start in monitor: nothing is refused until you decide it should be.
Get started