On Wednesday 15 December 2021 at 19:26 UTC, a CLDAP reflection targeted a online casino customer in the UK. The attack peaked at 141.3 Gbps and lasted 137 minutes. Traffic originated from 578 autonomous systems in 114 countries, predominantly residential proxy networks.
| Vector | CLDAP reflection |
| Peak | 141.3 Gbps |
| Duration | 137 min |
| Time to mitigation | 0.657 s |
| Attack traffic reaching origin | 0.017% |
| Legitimate traffic challenged | 0.14% |
Timeline
The attack was preceded by a publicly announced sales event. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 13 points of presence.
What the customer saw
No customer-visible impact. The on-call engineer was notified and acknowledged the incident from the dashboard.
Recommendations
- Review allow-listed partner ranges quarterly.
- Enable log streaming to your SIEM for faster correlation.
- Enable authenticated origin pulls.
Do you publish the edge IP ranges in a machine-readable format?
The point about origin IPs leaking through certificate transparency logs is underrated.
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Could you share the dataset behind the percentages?
This matches what we see in iGaming around big matches.
Verified good bots and allow-listed partners bypass challenges entirely.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Good question. We will cover that in a follow-up post.
Great write-up. We saw almost the same pattern on our login endpoint last month.
How do you avoid challenging uptime monitors and partners?
Carpet bombing is nasty. Good to see a clear explanation of it.