WAF in modalità log: come abilitare gradualmente la protezione senza bloccare il traffico legittimo

Esiste un presupposto comune secondo cui abilitare WAF è una decisione binaria: è bloccante o non lo è. I team che iniziano da questo punto attivano le regole gestite in modalità Blocco direttamente in produzione, presuppongono che le regole siano sufficientemente prudenti e poi scoprono che il modulo di caricamento del contratto ha smesso di funzionare, che l'integrazione con payment gateway restituisce 403 e che il team di supporto riceve reclami da clienti che non riescono ad accedere. Il WAF non aveva torto, ma non conosceva nemmeno l'applicazione.

Cosa fa la modalità Log e perché esiste

Cloudflare WAF ha tre possibili azioni per ciascuna regola: Blocca, che restituisce 403 e termina la richiesta; Challenge, che presenta una sfida al cliente; e Log, che registra l'evento senza interferire con il flusso. La modalità Log è l'unica che permette di osservare il comportamento delle regole rispetto al traffico reale senza conseguenze per gli utenti.

Quando un set di regole è configurato con un'azione Log, tutte le regole si attivano normalmente (valutano intestazioni, URI, corpo, stringa di query) ma invece di bloccarsi, registrano semplicemente l'evento. Gli eventi firewall nel dashboard di Cloudflare acquisiscono ogni trigger: l'IP di origine, l'URI completo, l'ID della regola specifica e il contenuto esatto che ha causato la corrispondenza. La richiesta raggiunge intatta il server di origine. L'utente non si accorge di nulla.

La sequenza di distribuzione che previene gli incidenti

Il processo inizia abilitando tutti i set di regole gestiti con l'azione impostata su Registra. Il livello di paranoia OWASP dovrebbe essere impostato su 1 fin dall'inizio: questo livello cattura i modelli di attacco più evidenti con il volume più basso di falsi positivi. Salire al livello 2 o 3 alla prima attivazione garantisce quasi un rumore eccessivo che rende difficile distinguere gli attacchi reali dal traffico legittimo e malformattato.

Con le regole nel Log, la dashboard degli eventi del firewall deve essere rivista quotidianamente. L'obiettivo è identificare le regole che si attivano in modo coerente su richieste legittime: lo stesso URI, lo stesso modello di richiesta, la stessa regola. Uno scatto isolato può essere rumore; lo stesso trigger su migliaia di richieste da parte di utenti reali è un falso positivo che bloccherà il traffico quando l'azione passa a Blocca.

Quando viene identificato un falso positivo, la risposta è creare una regola Ignora: una regola firewall che indica al WAF di ignorare set di regole o regole specifiche quando criteri come URI e metodo HTTP corrispondono. Un endpoint /api/upload che attiva la regola 100035 perché accetta file con estensione .php nel suo nome riceve una regola Ignora che esclude quel percorso dall'ispezione da parte di quella regola. L'esclusione è chirurgica: tutto il resto del traffico continua ad essere valutato.

Dopo una o due settimane con le regole nel registro, i falsi positivi gestiti con le regole Ignora e nessun nuovo trigger sul traffico legittimo, l'azione cambia in Blocca. Il criterio è la stabilità, non il tempo trascorso.

Lettura accurata degli eventi del firewall

La dashboard Eventi Firewall mostra ogni evento con dettagli sufficienti per prendere una decisione. Oltre all'IP e all'URI, l'evento mostra l'ID della regola che è stata attivata (un identificatore come 949110 o 100035 consultabile nella documentazione di Cloudflare) e i dati abbinati, la parte specifica della richiesta che ha causato la corrispondenza.

Questo campo di dati abbinati trasforma l'indagine da un falso positivo di speculazione in una diagnosi concreta. Se la regola 100035 è stata attivata il POST /api/upload e i dati corrispondenti mostrano filename=relatorio.php, è chiaro che la regola reagisce al nome del file, non al contenuto dannoso nel corpo. La regola Salta risultante è precisa: ignora la regola 100035 solo per quel percorso. Qualsiasi altro endpoint che riceve un .php veramente sospetto continua a essere valutato.

Gli avvisi di notifica per i nuovi eventi WAF chiudono il ciclo del rilevamento continuo. Quando Cloudflare aggiunge una nuova firma a un CVE circolante, l'avviso avvisa il team e Firewall Events mostra se la nuova regola sta toccando il traffico legittimo prima che sia troppo tardi.

Analisi WAF e integrazione SIEM

Per i team con operazioni di sicurezza consolidate, i dati degli eventi firewall possono essere esportati tramite Logpush. Logpush invia eventi WAF a R2, S3, Datadog o Splunk con la serie completa di campi: timestamp, IP, paese, URI, metodo, ID regola, azione intrapresa e dati corrispondenti. Per un team con un SOC attivo, questi dati alimentano correlazioni che la dashboard di Cloudflare non fornisce: pattern di attacco distribuito da più IP contro lo stesso endpoint nel corso di ore, variazioni del payload che testano quale regola può essere aggirata.

WAF Analytics aggrega questi eventi in una serie temporale all'interno di Cloudflare. Quando l'azione passa da Registra a Blocca, un aumento inatteso delle risposte 403 nel traffico normale indica un falso positivo sfuggito alla fase di osservazione e l'ID regola nell'evento ti dice esattamente cosa gestire.

Costruire abitudini operative

WAF non è una configurazione una tantum. Le applicazioni cambiano: vengono aggiunti nuovi endpoint, le integrazioni di terze parti introducono modelli di richiesta che WAF non ha mai visto e Cloudflare aggiorna regolarmente le regole gestite.

Ciò che funziona è assegnare una responsabilità esplicita: qualcuno sulla piattaforma o nel team di sicurezza esamina settimanalmente gli eventi del firewall. La revisione cerca nuovi modelli: l’attivazione di regole ad alto volume che non apparivano prima, un picco di blocchi nelle ore di punta. Quando un nuovo endpoint entra in produzione, la sequenza di osservazione ricomincia per quel percorso: Registra prima, Ignora regole per falsi positivi, Blocca dopo.