We get asked about inside a Mirai variant that learned to speak HTTP/2 more than almost anything else, so here is the long answer.
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.
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.
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.
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.
We will follow up with the numbers from the next quarter.
This matches what we see in iGaming around big matches.
Carpet bombing is nasty. Good to see a clear explanation of it.
Nice to read a vendor blog that admits what went wrong.