On Wednesday 22 May 2024 at 12:42 UTC, a SYN flood targeted a news publisher customer in Iberia. The attack peaked at 340.1 Gbps and lasted 161 minutes. Traffic originated from 3522 autonomous systems in 106 countries, predominantly a headless-browser farm.
| Vector | SYN flood |
| Peak | 340.1 Gbps |
| Duration | 161 min |
| Time to mitigation | 0.111 s |
| Attack traffic reaching origin | 0.079% |
| Legitimate traffic challenged | 0.43% |
Timeline
The attack was preceded by a breaking political story. Edge packet filters identified the flood by source port and payload signature and dropped it at line rate across 34 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
- Add a dedicated rate limit for the targeted route.
- Keep origin IPs out of public DNS history.
- Lower challenge thresholds on authentication endpoints during high-risk events.
Could you share the dataset behind the percentages?
Any plans to support per-tenant limits keyed on a JWT claim?
The billing model is what got our finance team on board, honestly.
This matches what we see in iGaming around big matches.
How do you avoid challenging uptime monitors and partners?
Our auditors asked for exactly this kind of incident evidence under DORA.
Carpet bombing is nasty. Good to see a clear explanation of it.
Machine-readable ranges are at /ips.json and via the API.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Machine-readable ranges are at /ips.json and via the API.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Good question. We will cover that in a follow-up post.