Over the last few months we have spent a lot of time on scraper bots are getting better at pretending to be Chrome. This is what we learned.
Measuring success
We track three numbers for every incident: time to mitigation, the share of attack traffic that reached the origin, and the share of legitimate traffic that was challenged. The first should be under a second, the second under 0.1% and the third under 1%.
Those numbers go into every incident report, and they are the same numbers we are measured against in our SLA.
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.
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.
Observability first
Every mitigation decision is logged with its reasons, and every log line can be traced to the rule and score components that produced it. When a customer asks why a request was challenged, the answer is a link, not a guess.
Logs stream to the customer’s SIEM within seconds, which also means their security team sees attacks in the same tools they use for everything else.
{ "match": { "path": "/account/reset", "risk": ">= 49" }, "action": "challenge" }
The full incident data behind this post is available to customers in the dashboard under Reports.
The point about origin IPs leaking through certificate transparency logs is underrated.
Thanks! Yes — the risk score and its components are included in every log record.
Any plans to support per-tenant limits keyed on a JWT claim?
The billing model is what got our finance team on board, honestly.
Solid runbook advice. The DNS-at-2am point hit home.
Could you share the dataset behind the percentages?
Could you share the dataset behind the percentages?
Is the risk score exposed in the logs so we can build our own dashboards on it?
Great write-up. We saw almost the same pattern on our login endpoint last month.
Nice to read a vendor blog that admits what went wrong.