What DORA means for your DDoS resilience (part 4)

Over the last few months we have spent a lot of time on what DORA means for your DDoS resilience. This is what we learned.

Lessons for your own runbook

Know who can change DNS at two in the morning. Know your origin IPs and who can rotate them. Know which routes are expensive, and have a rate limit ready for each of them.

Most outages during attacks are not caused by the attack itself but by rushed changes made while under pressure.

The numbers

Across the last quarter, 71% of challenged clients never attempted a solution, 24% solved one challenge and then behaved normally, and 5% solved challenges repeatedly while continuing to attack — the last group is where analysts spend their time.

Median added latency for legitimate visitors that were challenged was 280 ms on desktop and 410 ms on mid-range Android devices.

Testing in production, safely

Every rule starts in log mode. We replay the previous seven days of traffic through it and show exactly which requests it would have affected before anyone can promote it to challenge or block.

This one feature has prevented more incidents than any detection we have ever shipped.

Challenges beat blocks

Blocking lists go stale within minutes when attackers rotate through residential proxies. Proof-of-work does not care where a request comes from; it only cares whether the client is willing to pay the cost.

For a real browser that cost is a few hundred milliseconds, once per session. For a botnet sending a million requests a minute it is a million puzzles a minute — and at that point the attack stops being cheap.

{ "match": { "path": "/api/v1/checkout", "risk": ">= 61" }, "action": "challenge" }

As always, questions and corrections are welcome at [email protected].