This post is about tuning challenge thresholds for mobile traffic behind CGNAT. It started, as most of our posts do, with an incident that did not go the way we expected.
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.
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.
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.
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.
What we got wrong
Our first version challenged too eagerly on mobile networks, where thousands of real users share a handful of carrier-grade NAT addresses. Reputation that is shared is reputation that is noisy.
We now weight fingerprint consistency and session behaviour far more heavily than IP reputation for traffic from known mobile carrier ranges.
If you run into any of this in your own environment, our SOC is happy to take a look — even if you are not a customer.
Do you publish the edge IP ranges in a machine-readable format?
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
How does the proof-of-work challenge behave on older Android devices? Any numbers below Android 10?
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
This matches what we see in iGaming around big matches.
Great to hear, thanks for sharing your experience.
We had the exact false-positive issue with CGNAT carriers. The weighting change makes sense.
Verified good bots and allow-listed partners bypass challenges entirely.
Clear and practical, thanks.
Verified good bots and allow-listed partners bypass challenges entirely.
Our auditors asked for exactly this kind of incident evidence under DORA.