Over the last few months we have spent a lot of time on residential proxies are the new botnet. This is what we learned.
Why per-route baselines matter
A thousand requests per second to your homepage is Tuesday. A thousand requests per second to your password-reset endpoint is an attack. Global rate limits cannot tell the difference; per-route baselines can.
We learn the normal shape of traffic per route and per hour of the week, so a surge on a sensitive endpoint raises the risk score long before it approaches a global threshold.
What actually happens during a flood
The first thing to fail during a layer 7 flood is almost never bandwidth. It is connection slots, worker processes or database connections on the origin — resources measured in hundreds or thousands, not gigabits. An attacker who can make each request expensive only needs a few thousand requests per second.
That is why we score requests before they are proxied. By the time a request reaches your origin, it has been attributed to a client, compared against that client’s history and weighed against the current load on the route it targets.
Compliance is a side effect
Regulators increasingly ask for evidence of resilience, not just promises. An incident timeline with start, peak, vectors and impact is exactly the evidence DORA and NIS2 ask for — and it falls out of good observability for free.
We export incident reports in formats auditors can file without anyone rewriting them.
What we changed
We moved the decision from a single threshold to a continuous score, added an explanation to every decision and made every rule testable against historical traffic before it goes live.
The result is fewer late-night pages for our analysts and — more importantly — fewer real users challenged by mistake.
{ "match": { "path": "/login", "risk": ">= 56" }, "action": "challenge" }
As always, questions and corrections are welcome at [email protected].
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Is the risk score exposed in the logs so we can build our own dashboards on it?
Could you share the dataset behind the percentages?
Machine-readable ranges are at /ips.json and via the API.
Great write-up. We saw almost the same pattern on our login endpoint last month.
Our auditors asked for exactly this kind of incident evidence under DORA.
Nice to read a vendor blog that admits what went wrong.