Thousands of small requests can saturate the application.
In a distributed flood every single IP remains under threshold, but the overall volume overwhelms the service.
Per-IP rate limiting does not stop distributed floods, and those who attack pretend to be Googlebot. Sentinel combines a global aggregate limit, a JavaScript challenge to separate real browsers and JA4 TLS fingerprinting to recognise clients. During an attack, legitimate users continue while hostile automation is stopped.
In a distributed flood every single IP remains under threshold, but the overall volume overwhelms the service.
Combine per-IP and global limits, a JavaScript challenge and client TLS identity.
Automated traffic is slowed down or rejected before consuming the application resources.
The problem
Limiting requests per single IP works against isolated abuse, but not against a distributed attack.
The botnets divide the load on thousands of IPs: everyone remains below the threshold per-IP, but their combined traffic overwhelms the application. aggregate, not just for clients.
A client that identifies itself as "Googlebot" in the User-Agent can be anyone. Blocking it risks excluding the real crawlers; trusting it opens the door to scrapers. verification, not the header.
Always responding with a ban is likely to hit legitimate users behind NAT or CDN. A A challenge that the real browser overcomes transparently and the flood doesn't.
Per-IP and global rate limiting
The per-IP limit uses a source token bucket: once the threshold is exceeded, the request receives 429 Too Many Requests. The global limit measures aggregate requests per second on the whole domain: it is the defense against distributed floods, where no single IP exceeds its limit but the combined traffic does.

Challenge JS · under attack
When under-attack mode is enabled, Sentinel presents a challenge JavaScript instead of a hard block. The browser runs the script and gets a cookie Sentinel_Authorization signed on HMAC and bound to the IP address: Automated clients that don't run JS stay out.

JA4 & verified bots
The JA4 fingerprint is calculated from TLS ClientHello (FoxIO specification) and identifies the client, not the IP address: the fingerprint can be added to the blocklist or allowlist (which has priority). Verified bots are confirmed with reverse-DNS PTR + forward confirmation. Verification is performed only when the global rate-limit bucket is exhausted, so normal traffic does not even trigger a DNS query.

Behavioural detection
Sentinel maintains a local baseline and looks at how the behaviour of each source changes.
Compare the number of requests with the baseline and measure how far the behaviour deviates from the norm.
Many different URLs and a sequence of 404 in a few minutes indicate an automatic search of exposed files or panels.
It recognises rapid bursts and error response concentrations before they become just log noise.
It flags suspicious changes in the client already observed, without treating the header alone as definitive proof.
How they combine
Each request passes through the controls in sequence: first the volume, then the identity, finally the content.
If aggregate requests per second exceed the threshold, excess traffic is discarded (503) to protect the app from distributed floods.
Source token bucket: an abusive IP receives 429, without touching other users.
The client TLS fingerprint: allowlist passes immediately, blocklisted clients are stopped. Fail-open if TLS is not terminated here.
Verified bots and users with clearance pass; others receive the JavaScript challenge under-attack.
Remaining traffic reaches the Web Application Firewall with OWASP Core Rule Set for content inspection.
Frequently asked questions
Transparency on the limits: Sentinel acts on the L7 application layer.
No. Sentinel acts at the level Application (L7): absorbs the flood of HTTP requests and unmasks the bots, but does not stop volumetric attacks that saturate upstream bandwidth, which must be handled first (network/upstream).
No: a real browser runs the script and gets the cookie Sentinel_Authorization (HMAC, TTL 30 min). Subsequent requests are transparent. Only those who do not run JavaScript stay out.
No. The JA4 identifies the client, not the IP: no auto-block L3 is associated with fingerprint, so entire shared networks are not blocked behind NAT.
There is no impact under normal load: reverse-DNS bot verification runs only when the global rate-limit bucket is exhausted. Under ordinary conditions no DNS queries start.
The JA4 fingerprint goes to fail-open: If the ClientHello is not available, the control does not block. Global rate limiting and challenge remain also opt-in and activate when needed.
We show you the DDoS L7 protection and live bot verification on your infrastructure, adjusted to your traffic.