Absorb application floods and expose disguised bots.

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.

Per-IP and global rate limitingChallenge JSJA4
The problem

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.

What Sentinel does

Measure total traffic and distinguish browsers from bots.

Combine per-IP and global limits, a JavaScript challenge and client TLS identity.

The result

The app remains available to real users.

Automated traffic is slowed down or rejected before consuming the application resources.

The problem

Why conventional rate limiting is not enough.

Limiting requests per single IP works against isolated abuse, but not against a distributed attack.

Distributed flood

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.

Impersonated bots

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.

A hard block can create false positives

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

Two limits, two different threats.

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.

  • Per-IP · token bucket: above the threshold → 429, with gradual recovery of tokens.
  • Global · aggregate req/s: above the threshold → 503 (shedding) or challenge.
  • Targeted bypasses: allowlisted IP addresses, verified bots and users with clearance are not limited.
Sentinel dashboard real screen

Challenge JS · under attack

Real browsers pass; clients that do not run JavaScript do not.

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.

  • HMAC clearance cookies bound to the IP address, with TTL 30 minutes: activated only when needed.
  • Response 503 with header Retry-After and noindex: No SEO impact during the attack.
  • Opt-in: the challenge and the global limit are activated when they are needed, not permanently.
Sentinel dashboard real screen

JA4 & verified bots

Recognise the client and verify the crawler.

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.

  • JA4 from ClientHello: blocklist/allowlist, allowlist priority, fail-open if TLS is not terminated by Sentinel.
  • No automatic L3 block on the JA4: identify the client, not the IP → no ban of entire networks behind NAT.
  • Verified bots: Googlebot, Bingbot, YandexBot, DuckDuckBot, Baiduspider, Applebot (cache 1h).
Sentinel dashboard real screen

Behavioural detection

You don't need a signature to recognise abnormal behaviour.

Sentinel maintains a local baseline and looks at how the behaviour of each source changes.

Traffic spikes

Compare the number of requests with the baseline and measure how far the behaviour deviates from the norm.

Path scanning

Many different URLs and a sequence of 404 in a few minutes indicate an automatic search of exposed files or panels.

Bursts and error floods

It recognises rapid bursts and error response concentrations before they become just log noise.

Change of User-Agent

It flags suspicious changes in the client already observed, without treating the header alone as definitive proof.

How they combine

Five levels, in order.

Each request passes through the controls in sequence: first the volume, then the identity, finally the content.

01

Global load shedding

If aggregate requests per second exceed the threshold, excess traffic is discarded (503) to protect the app from distributed floods.

02

Rate-limit per-IP

Source token bucket: an abusive IP receives 429, without touching other users.

03

JA4 & Lists

The client TLS fingerprint: allowlist passes immediately, blocklisted clients are stopped. Fail-open if TLS is not terminated here.

04

Soft gate → challenge

Verified bots and users with clearance pass; others receive the JavaScript challenge under-attack.

05

WAF CRS

Remaining traffic reaches the Web Application Firewall with OWASP Core Rule Set for content inspection.

Frequently asked questions

What Sentinel does—and does not do.

Transparency on the limits: Sentinel acts on the L7 application layer.

Does Sentinel mitigate volumetric DDoS attacks?

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).

Does the challenge block legitimate users?

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.

Does an IP behind NAT risk being blocked because of the JA4?

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.

Reverse-DNS verification slows down traffic?

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.

What happens if TLS is not terminated by Sentinel?

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.

Do you want to see it in action?

We show you the DDoS L7 protection and live bot verification on your infrastructure, adjusted to your traffic.