Here is a question we could not answer well a year ago: what really happens with how we test WAF rules against seven days of real traffic? We can answer it now.
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.
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.
Protecting the origin
None of this matters if the attacker can reach your origin directly. Historical DNS records, certificate transparency logs and misconfigured subdomains leak origin addresses all the time.
Allow-list the edge ranges, enable authenticated origin pulls and treat any origin IP that ever appeared in public DNS as burned.
The economics behind it
A booter service rents out a 100 Gbps attack for less than the price of a pizza. Defending against it with bandwidth alone is a race you lose. Defending against it by making each malicious request cost more than it earns is a race you win.
This is the entire idea behind never metering attack traffic: our costs scale with filtering, not with your invoice.
Latency budget
Our budget for the whole filtering pipeline is one millisecond at the 99th percentile. Anything that cannot be decided within that budget runs asynchronously and influences the next request from the same client, not the current one.
That constraint shapes everything: data structures, where state lives and which signals we are willing to compute inline.
{ "match": { "path": "/account/reset", "risk": ">= 68" }, "action": "challenge" }
As always, questions and corrections are welcome at [email protected].
Do you publish the edge IP ranges in a machine-readable format?
Solid runbook advice. The DNS-at-2am point hit home.
How do you avoid challenging uptime monitors and partners?
The point about origin IPs leaking through certificate transparency logs is underrated.
Great to hear, thanks for sharing your experience.
Nice to read a vendor blog that admits what went wrong.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Machine-readable ranges are at /ips.json and via the API.