On Tuesday 26 July 2022 at 06:27 UTC, a GRE flood targeted a B2B SaaS customer in Iberia. The attack peaked at 340.7 Gbps and lasted 76 minutes. Traffic originated from 3877 autonomous systems in 87 countries, predominantly residential proxy networks.
| Vector | GRE flood |
| Peak | 340.7 Gbps |
| Duration | 76 min |
| Time to mitigation | 0.420 s |
| Attack traffic reaching origin | 0.072% |
| Legitimate traffic challenged | 0.46% |
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 32 points of presence.
What the customer saw
A brief increase in p99 latency of 174 ms during the first minute, then normal service.
Recommendations
- Keep origin IPs out of public DNS history.
- Enable log streaming to your SIEM for faster correlation.
- Add a dedicated rate limit for the targeted route.
Would love a follow-up on how you handle HTTP/3 fingerprinting.
This matches what we see in iGaming around big matches.
Thanks! Yes — the risk score and its components are included in every log record.
Solid runbook advice. The DNS-at-2am point hit home.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Would love a follow-up on how you handle HTTP/3 fingerprinting.
Interesting that most attacks are under ten minutes. Our experience is similar.
Good question. We will cover that in a follow-up post.
This matches what we see in iGaming around big matches.
Solid runbook advice. The DNS-at-2am point hit home.