On Wednesday 6 October 2021 at 20:48 UTC, a GRE flood targeted a video streaming customer in Central Europe. The attack peaked at 369.9 Gbps and lasted 62 minutes. Traffic originated from 1473 autonomous systems in 71 countries, predominantly compromised cloud VMs.
| Vector | GRE flood |
| Peak | 369.9 Gbps |
| Duration | 62 min |
| Time to mitigation | 0.269 s |
| Attack traffic reaching origin | 0.029% |
| Legitimate traffic challenged | 0.72% |
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 28 points of presence.
What the customer saw
Checkout conversion was unchanged compared with the same hour of the previous week.
Recommendations
- Lower challenge thresholds on authentication endpoints during high-risk events.
- Enable authenticated origin pulls.
- Add a dedicated rate limit for the targeted route.
Any plans to support per-tenant limits keyed on a JWT claim?
Is the risk score exposed in the logs so we can build our own dashboards on it?
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
Thanks! Yes — the risk score and its components are included in every log record.
The billing model is what got our finance team on board, honestly.
This matches what we see in iGaming around big matches.
Nice to read a vendor blog that admits what went wrong.
The point about origin IPs leaking through certificate transparency logs is underrated.
Great to hear, thanks for sharing your experience.
The point about origin IPs leaking through certificate transparency logs is underrated.
Clear and practical, thanks.