Regole gestite e regole personalizzate in WAF: quando scriverne di proprie

È opinione comune che abilitare Cloudflare Managed Ruleset e OWASP Core Ruleset sia sufficiente per avere un'applicazione protetta. La premessa ignora lo scopo per cui queste regole sono state progettate e ciò che deliberatamente non fanno.

I set di regole gestiti rappresentano una protezione ad ampio spettro. Sono stati creati per funzionare su qualsiasi applicazione web, da un blog WordPress a un'API di pagamento, senza alcuna conoscenza di ciò che rende la loro applicazione diversa da qualsiasi altra. Questo è proprio ciò che li limita.

Cosa coprono le regole gestite e dove generano attriti

Il set di regole gestite da Cloudflare viene aggiornato automaticamente quando Cloudflare rileva nuovi kit di exploit, firme di attacchi su larga scala e sfruttamento attivo di CVE nei software più diffusi. Per un team senza un team di sicurezza dedicato, questo ha un valore reale: copertura continua senza manutenzione manuale.

L'OWASP Core Ruleset funziona con classi di attacco catalogate: SQL injection, XSS, inclusione di file, deserializzazione non sicura. Il modello di punteggio accumula punti poiché le regole vengono attivate sulla stessa richiesta e l'azione si verifica quando il totale supera una soglia configurabile. Questa progettazione riduce i falsi positivi derivanti da regole isolate molto sensibili, ma non li elimina.

I falsi positivi appaiono prevedibilmente in tre contesti. Gli endpoint API che accettano JSON con virgolette, apostrofi o parentesi entrano in conflitto con le regole SQLi: il motore vede il modulo, non il contesto. I pannelli amministrativi con editor di testo RTF attivano le regole XSS quando l'utente salva HTML legittimo in un POST. Gli endpoint di caricamento binari consentono regole di ispezione del corpo calibrate per testo. Nessuno di questi è un attacco; sono tutti comportamenti applicativi legittimi.

Quali regole personalizzate ti consentono di fare

Le regole personalizzate funzionano con una conoscenza che i set di regole gestiti non avranno mai: il comportamento specifico della tua applicazione, il profilo del traffico legittimo, le minacce rilevanti per il tuo caso d'uso.

Il linguaggio delle espressioni di Cloudflare supporta condizioni composte con and, or e not. Un blocco per paese di origine ip.geoip.country eq "RU" combinato con http.request.uri.path eq "/api/register" limita solo l'endpoint di registrazione, senza toccare il resto. Il campo cf.threat_score gt 10 blocca gli IP con scarsa reputazione senza richiedere blacklist manuali.

Le liste consentite per le fonti attendibili sono importanti quanto le regole di blocco. Gli IP di monitoraggio, CI/CD e gli operatori interni devono essere esclusi da tutte le ispezioni con una regola Consenti applicata prima delle altre. Senza questo, un controllo dello stato restituisce 403 e una distribuzione di staging rimane bloccata nella limitazione della velocità: ore di indagine su un problema che non dovrebbe esistere.

La limitazione della velocità sugli endpoint sensibili appartiene alle regole personalizzate. Gli accessi, il recupero della password e gli endpoint OTP hanno profili di traffico molto diversi rispetto al resto dell'applicazione. Una regola che limita /auth/login a 5 richieste al minuto per IP protegge dal credential stuffing senza influenzare nessun altro percorso.

Anche il blocco degli user agent dannosi degli scraper rientra in questo contesto: http.user_agent contains "Scrapy" o http.user_agent eq "" sono filtri che un set di regole generico non implementerà perché dipendono dalla tua decisione su quali fonti escludere.

Come risolvere i falsi positivi senza aprire scappatoie

Quando un set di regole gestito viene attivato in modo errato, la disabilitazione della regola rimuove globalmente la protezione per tutti gli altri percorsi in cui ha funzionato. La risposta corretta è una regola Ignora con ambito preciso: http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" disabilita la regola 100016 solo per quel percorso, mantenendo la copertura nell'intera applicazione. La definizione dell'ambito per cf.waf.rule_id anziché per gruppo di regole è la differenza tra un'eccezione chirurgica e un buco.

Gli identificatori delle regole vengono visualizzati nei registri delle attività quando la regola viene attivata in modalità Registro: un altro motivo per cui il periodo di osservazione è obbligatorio prima di qualsiasi blocco.

Come calibrare i piani in base a ciò che è disponibile

Il piano gratuito offre 5 regole personalizzate e nessun accesso ai set di regole gestiti. Con 5 regole, la priorità è chiara: lista consentita degli IP interni, blocco tramite cf.threat_score alto, limitazione della velocità sull'endpoint più critico. Cercare di coprire tutto con 5 regole si traduce in regole eccessivamente ampie con effetti collaterali imprevedibili.

Il piano Pro arriva fino a 20 regole e sblocca set di regole gestite. Il piano Business arriva a 100, che consente di creare diversi profili di protezione per gruppo di endpoint: API pubbliche con rate limiting più permissivi, pannelli amministrativi con ispezione più aggressiva, webhook partner con liste consentite per IP di origine. Con 20 regole fai delle scelte; con 100 fai politica.

Il processo di calibrazione che funziona nella pratica

L'ordine delle operazioni è più importante della configurazione specifica di ciascuna regola. Iniziare con il blocco attivo in un'applicazione di produzione senza una base di traffico è una ricetta per disturbare gli utenti reali.

La sequenza inizia con tutte le regole gestite in modalità Log per un periodo compreso tra sette e quattordici giorni. La dashboard delle attività WAF accumula dati reali: quali regole verranno attivate, con quali frequenze, su quali percorsi. Con questa mappatura puoi identificare i candidati falsi positivi prima che diventino incidenti, scrivere regole di salto con l'ambito corretto e configurare liste consentite personalizzate e regole di blocco.

Solo allora ha senso passare alla Managed Challenge o al Block, iniziando con le regole con il rischio di falsi positivi più basso – CVE specifici – e passando a quelle più ampie (OWASP SQLi, OWASP XSS) man mano che acquisisci sicurezza. Calibrare la soglia OWASP Core Ruleset è l'ultima decisione, perché dipende dalla visione della reale distribuzione dei punteggi nel traffico della tua applicazione.