On Sunday 25 February 2024 at 02:53 UTC, a memcached amplification targeted a airline booking customer in the Middle East. The attack peaked at 20.7 Gbps and lasted 185 minutes. Traffic originated from 571 autonomous systems in 50 countries, predominantly mobile carrier ranges.
| Vector | memcached amplification |
| Peak | 20.7 Gbps |
| Duration | 185 min |
| Time to mitigation | 0.339 s |
| Attack traffic reaching origin | 0.017% |
| Legitimate traffic challenged | 0.56% |
Timeline
The attack was preceded by a competitor’s product launch. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 25 points of presence.
What the customer saw
The customer’s status page stayed green throughout; they learned about the attack from our notification.
Recommendations
- Enable authenticated origin pulls.
- Review allow-listed partner ranges quarterly.
- Keep origin IPs out of public DNS history.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Nice to read a vendor blog that admits what went wrong.
Machine-readable ranges are at /ips.json and via the API.
Our auditors asked for exactly this kind of incident evidence under DORA.
Great to hear, thanks for sharing your experience.
Solid runbook advice. The DNS-at-2am point hit home.
Great to hear, thanks for sharing your experience.
Do you publish the edge IP ranges in a machine-readable format?
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Great to hear, thanks for sharing your experience.