Migliaia di richieste piccole possono saturare l'applicazione.
In un flood distribuito ogni singolo IP resta sotto soglia, ma il volume complessivo manda il servizio in affanno.
Assorbi i flood, smaschera i bot travestiti.
Il rate-limit per singolo IP non ferma i flood distribuiti, e chi attacca finge di essere Googlebot. Sentinel combina un limite globale aggregato, una challenge JavaScript per separare i browser reali e il fingerprint TLS JA4 per riconoscere i client — così, sotto attacco, gli utenti veri passano e il rumore no.
Rate-limit per-IP e globaleChallenge JSJA4
Misura il traffico totale e distingue browser e bot.
Combina limiti per IP e globali, challenge JavaScript e identità TLS del client.
L'app resta disponibile agli utenti reali.
Il traffico automatico viene rallentato o respinto prima di consumare le risorse dell'applicazione.
Il problema
Perché il rate-limit classico non basta.
Limitare le richieste per singolo IP funziona contro un abuso puntuale. Contro un attacco vero, no.
Flood distribuiti
Le botnet dividono il carico su migliaia di IP: ognuno resta sotto la soglia per-IP, ma la somma travolge l'applicazione. Serve una misura del traffico aggregato, non solo per client.
Bot che mentono
Un client che si dichiara "Googlebot" nell'User-Agent può essere chiunque. Bloccarlo rischia di tagliare fuori i crawler veri; fidarsi apre la porta agli scraper. Serve una verifica, non l'header.
Blocco netto = falsi positivi
Rispondere sempre con un ban rischia di colpire utenti legittimi dietro NAT o CDN. Meglio una challenge che il browser reale supera in modo trasparente e il flood no.
Rate-limit per-IP e globale
Due limiti, due minacce diverse.
Il limite per-IP usa un token bucket per sorgente: superata la soglia, la richiesta riceve 429 Too Many Requests. Il limite globale misura le richieste al secondo aggregate su tutto il dominio: è la difesa contro i flood distribuiti, dove nessun singolo IP sfora ma la somma sì.
- Per-IP · token bucket: oltre soglia → 429, con recupero graduale dei token.
- Globale · req/s aggregate: oltre soglia → 503 (shedding) oppure challenge.
- Bypass mirati: whitelist IP, bot verificati e utenti con clearance non vengono limitati.
Challenge JS · under attack
Il browser reale passa. Chi non esegue JS, no.
Quando scatta la modalità sotto attacco, Sentinel serve una challenge JavaScript al posto del blocco netto. Il browser esegue lo script e ottiene un cookie sentinel_clearance firmato in HMAC e legato all'IP: i client automatici che non eseguono JS restano fuori.
- Cookie di clearance HMAC legato all'IP, con TTL 30 minuti: superata una volta, si naviga senza attriti.
- Risposta 503 con header Retry-After e noindex: nessun impatto SEO durante l'attacco.
- Opt-in: la challenge e il limite globale si attivano quando servono, non a regime.
JA4 & bot verificati
Riconosci il client, verifica il crawler.
Il fingerprint JA4 è calcolato dal ClientHello TLS (spec FoxIO) e identifica il client, non l'IP: puoi metterlo in blocklist o in allowlist (che ha priorità). I bot buoni vengono confermati con reverse-DNS PTR + forward-confirm — la verifica scatta solo quando il bucket globale è esaurito, così a carico normale non parte nemmeno una query DNS.
- JA4 dal ClientHello: blocklist/allowlist, allowlist prioritaria, fail-open se il TLS non è terminato da Sentinel.
- Nessun auto-block L3 sul JA4: identifica il client, non l'IP → niente ban di intere reti dietro NAT.
- Bot buoni verificati: Googlebot, Bingbot, YandexBot, DuckDuckBot, Baiduspider, Applebot (cache 1h).
Rilevamento comportamentale
Non serve una firma per riconoscere un comportamento anomalo.
Sentinel mantiene una baseline locale e osserva come cambia il comportamento di ogni sorgente.
Picchi di volume
Confronta il numero di richieste con la baseline e misura quanto il comportamento si discosta dalla norma.
Path scanning
Molti URL diversi e una sequenza di 404 in pochi minuti indicano una ricerca automatica di file o pannelli esposti.
Raffiche ed error flood
Riconosce burst rapidi e concentrazioni di risposte d'errore prima che diventino soltanto rumore nei log.
Cambio di User-Agent
Segnala variazioni sospette del client già osservato, senza trattare il solo header come prova definitiva.
Come si combinano
Cinque livelli, in ordine.
Ogni richiesta attraversa i controlli in sequenza: prima il volume, poi l'identità, infine il contenuto.
01
Shedding globale
Se le richieste al secondo aggregate superano la soglia, il traffico in eccesso viene scartato (503) per proteggere l'app dai flood distribuiti.
02
Rate-limit per-IP
Token bucket per sorgente: chi abusa da un singolo IP riceve 429, senza toccare gli altri utenti.
03
JA4 & liste
Fingerprint TLS del client: allowlist passa subito, blocklist viene fermata. Fail-open se il TLS non è terminato qui.
04
Gate soft → challenge
Bot buoni verificati e utenti con clearance passano; gli altri ricevono la challenge JavaScript under-attack.
05
WAF CRS
Ciò che resta arriva al Web Application Firewall con OWASP Core Rule Set per l'ispezione del contenuto.
Domande frequenti
Cosa fa (e cosa non fa).
Trasparenza sui limiti: Sentinel agisce a livello applicativo L7.
Sentinel mitiga il DDoS volumetrico di banda?
No. Sentinel agisce a livello applicativo (L7): assorbe i flood di richieste HTTP e smaschera i bot, ma non ferma il volumetrico che satura la banda a monte, che va gestito prima (rete/upstream).
La challenge blocca gli utenti legittimi?
No: un browser reale esegue lo script e ottiene il cookie sentinel_clearance (HMAC, TTL 30 min). La navigazione successiva è trasparente. Solo chi non esegue JavaScript resta fuori.
Un IP dietro NAT rischia il ban per colpa del JA4?
No. Il JA4 identifica il client, non l'IP: nessun auto-block L3 è associato al fingerprint, quindi non si bannano intere reti condivise dietro NAT.
La verifica reverse-DNS rallenta il traffico?
No a carico normale: la verifica dei bot via reverse-DNS scatta solo quando il bucket globale è esaurito. In condizioni ordinarie non parte nessuna query DNS.
Cosa succede se il TLS non è terminato da Sentinel?
Il fingerprint JA4 va in fail-open: se il ClientHello non è disponibile, il controllo non blocca. Rate-limit globale e challenge restano inoltre opt-in e si attivano quando servono.
Vuoi vederla in azione?
Ti mostriamo la protezione DDoS L7 e la verifica bot dal vivo sulla tua infrastruttura, tarate sul tuo traffico.