On Wednesday 21 July 2021 at 07:16 UTC, a HTTP GET flood targeted a gaming community customer in Western Europe. The attack peaked at 914.7 million requests per second and lasted 172 minutes. Traffic originated from 88 autonomous systems in 91 countries, predominantly mobile carrier ranges.
| Vector | HTTP GET flood |
| Peak | 914.7 million requests per second |
| Duration | 172 min |
| Time to mitigation | 0.298 s |
| Attack traffic reaching origin | 0.018% |
| Legitimate traffic challenged | 0.32% |
Timeline
The attack was preceded by a hacktivist channel announcing the target. Request rates on the targeted routes exceeded their hourly baseline by a factor of 298 within 36 seconds. The risk score of participating clients crossed the challenge threshold automatically and proof-of-work difficulty rose with origin load.
What the customer saw
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Add a dedicated rate limit for the targeted route.
- Review allow-listed partner ranges quarterly.
- Lower challenge thresholds on authentication endpoints during high-risk events.
The point about origin IPs leaking through certificate transparency logs is underrated.
Great to hear, thanks for sharing your experience.
Clear and practical, thanks.
Nice to read a vendor blog that admits what went wrong.
Interesting that most attacks are under ten minutes. Our experience is similar.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Solid runbook advice. The DNS-at-2am point hit home.
Machine-readable ranges are at /ips.json and via the API.
Do you publish the edge IP ranges in a machine-readable format?
The billing model is what got our finance team on board, honestly.