WAF + Rate Limiting + Bot Management: la tripletta della protezione dei bordi

Il presupposto più comune dei team che hanno appena abilitato Cloudflare WAF è che l'applicazione sia ora protetta. Questa conclusione è tecnicamente errata, non perché WAF non funzioni, ma perché gli attacchi che blocca sono solo un sottoinsieme di quelli che riceverai. Gli altri due sottoinsiemi hanno prodotti diversi, con logica di rilevamento completamente diversa, e raramente i tre vengono configurati insieme fin dall'inizio.

Ciò che ogni livello vede effettivamente

Il modo più chiaro per comprendere la divisione è pensare a tre dimensioni della richiesta: cosa contiene, quante ne arrivano e chi le invia.

WAF opera sul contenuto: ispeziona il payload della richiesta e controlla se corrisponde a modelli di attacco noti. Uno ' OR 1=1 -- in un parametro di query, un tag di script in un campo del form, una sequenza ../../../etc/passwd in un percorso: sono firme che il motore riconosce e blocca. Il WAF è chirurgico nella dimensione que e cieco nelle altre due.

La limitazione della velocità agisce sulla velocità. Non importa cosa contenga la richiesta: se un IP invia 50 tentativi di accesso in dieci secondi, qualcosa non va. WAF non può rilevarlo perché ogni singola richiesta è formalmente valida: la query SQL è corretta, non è presente alcun carico dannoso, la richiesta HTTP verrebbe accettata da qualsiasi server senza obiezioni. Il problema non è il formato, ma la frequenza.

Il Bot Management opera sull'identità comportamentale. Un bot sofisticato che randomizza gli intervalli tra le richieste, utilizza un pool IP a rotazione e mantiene le tariffe entro i limiti configurati in Rate Limiting passerà attraverso i primi due livelli senza attriti. Ciò che fornisce questo tipo di traffico è l'impronta digitale comportamentale: modelli di navigazione che non esistono nelle sessioni umane, assenza di eventi del mouse prima dell'invio, sequenze di richieste senza le risorse ausiliarie che un browser reale caricherebbe, uso di impronte digitali TLS associate a stack di automazione. Bot Management assegna un punteggio a ogni sessione in questa dimensione comportamentale e agisce sul punteggio, indipendentemente dal carico utile e dalla velocità.

Come il credential stuffing passa attraverso WAF e perché il Rate Limiting prende piede

L’attacco che meglio illustra la necessità dei tre livelli è il credential stuffing con una cadenza controllata. L'aggressore dispone di un elenco di credenziali trapelate da altri servizi e testa ciascuna coppia rispetto all'endpoint di accesso dell'applicazione, non a raffica, ma metodicamente, da 3 a 5 tentativi al minuto per IP. Utilizza proxy residenziali per distribuire i tentativi e garantisce che nessun IP individuale vada oltre i limiti ovvi.

Dal punto di vista del WAF, questo attacco è invisibile. La richiesta di accesso è un POST con campi email e password, strutturalmente identico a quello che invierebbe qualsiasi utente legittimo. La password errata non è un payload dannoso: è solo testo che fallirà autenticazione. Non esiste alcuna firma che WAF possa riconoscere.

Con Rate Limiting, configuri una regola sull'endpoint /login con una finestra temporale e un limite di tentativi per IP. Cinque richieste in dieci secondi attivano il blocco. Tre richieste in quindici minuti sull'endpoint di ripristino della password, idem. L'aggressore che ha calibrato il tuo bot affinché sia al di sotto di questa soglia riuscirà comunque a passare, ma hai eliminato il livello più economico di riempimento delle credenziali: gli script che semplicemente si attivano senza controllo della cadenza.

Ciò che il Rate Limiting non risolve è che l'aggressore lo distribuisce su un numero sufficiente di IP per rimanere al di sotto del limite su ciascuno di essi. È qui che entra in gioco la gestione dei bot: anche se ogni singolo IP effettua solo due tentativi, il punteggio comportamentale della sessione indicherà l'automazione.

L'architettura del prodotto e ciò che ogni piano sblocca

Il Rate Limiting è un prodotto separato dal WAF: non sono regole all'interno dello stesso sistema, sono sistemi con logica e configurazioni indipendenti. Questa distinzione è importante durante la configurazione, perché i team abituati a lavorare solo con le regole WAF spesso cercano il Rate Limiting nel posto sbagliato nell'interfaccia.

Le dimensioni di controllo disponibili in Rate Limiting includono IP, combinazione di IP e percorso, cookie specifico e agente utente. Le azioni sono Blocca, Sfida e Log, dove Log è l'equivalente della modalità orologio di WAF, utile per calibrare le soglie prima di attivare il blocco in produzione.

Il piano gratuito di Cloudflare consente un'unica regola di limitazione della velocità. Pro ($ 20 al mese) arriva fino a cinque regole. Gli affari si fermano a cento. Enterprise rimuove il limite delle regole e sblocca la gestione completa dei bot, incluso l'accesso a cf.bot_management.score come variabile nelle espressioni delle regole, un numero compreso tra 0 e 99 dove valori più bassi indicano traffico più automatizzato.

Su Pro, l'equivalente di Gestione bot è la modalità Super Bot Fight: un'impostazione semplificata che blocca definitivamente i bot automatizzati, sfida quelli probabilmente automatizzati e lascia passare il traffico verificato. Non si accede al punteggio numerico né si scrivono regole basate su di esso, ma è attiva la copertura contro le categorie di bot più comuni.

Cosa copre in pratica la combinazione del piano Pro

Per 20 dollari al mese, un'applicazione web con un'attenzione minima alla configurazione può coprire la maggior parte della superficie di attacco automatizzata. WAF con set di regole gestiti da Cloudflare in modalità Blocco per OWASP livello 1 intercetta SQLi, XSS, percorso trasversale e sfruttamento di CVE noti. Le cinque regole di limitazione della velocità coprono endpoint critici: accesso con un limite di cinque richieste in dieci secondi per IP, recupero della password con tre richieste in quindici minuti, registrazione dell'account con dieci richieste in un'ora, endpoint di pagamento con dieci richieste in un'ora e root API con cento richieste al minuto. La modalità lotta attiva Super Bot blocca il volume di bot che non sono abbastanza sofisticati per mascherare il comportamento.

Ciò che questa combinazione non copre sono i bot con un comportamento genuinamente umano: sessioni che navigano a velocità plausibile, con pattern di mouse e tastiera sintetici ma convincenti, utilizzando IP domestici con cronologie pulite. Questo livello di sofisticazione è costoso per l'aggressore ed è raro negli attacchi che prendono di mira applicazioni che non sono obiettivi di alto valore. Per la maggior parte delle applicazioni web, il divario lasciato in Pro è accettabile.

Dove ha senso scalare il business o l'impresa?

La decisione di aggiornare è un’equazione tra rischio e costo, non ambizione tecnologica. Il business giustifica il salto soprattutto se sono necessarie più di cinque regole di limitazione della velocità: un'applicazione con dozzine di endpoint sensibili esaurirà rapidamente il limite Pro. Cento regole nel mondo degli affari risolvono questo problema senza raggiungere l'investimento aziendale.

L’impresa ha senso quando il profilo della minaccia include avversari con capacità di aggirare il rilevamento semplificato: frodi finanziarie sofisticate, concorrenti che riducono sistematicamente i prezzi con bot che imitano il comportamento umano o credential stuffing altamente distribuito contro un servizio di alto valore. L'accesso al punteggio numerico di Gestione Bot ti consente di creare regole con una granularità che la modalità Super Bot Fight non offre: blocca sopra 30, sfida tra 30 e 60, consenti sopra 60, con logica aggiuntiva tramite percorso o metodo HTTP. Questa espressività ha un costo, e il costo è giustificato solo quando il rischio mitigato è proporzionale.