WAF Cloudflare: cosa blocca realmente la protezione gestita e cosa supera

La maggior parte dei team attiva Cloudflare WAF come se installasse un antivirus: una volta configurato, il problema è risolto. Questa premessa è sbagliata, e il costo di non comprenderla è un falso senso di sicurezza che può essere più pericoloso di nessuna protezione.

WAF è un livello efficace contro una classe specifica di minacce. Contro un’altra classe, fornisce attrito, non barriera. Conoscere la differenza determina come calibrare il sistema e cosa deve essere creato a livello di applicazione.

Cosa fanno effettivamente le regole gestite

Le regole gestite coprono le classi di attacco più comuni: SQL injection, cross-site scripting, directory traversal, caricamento di web shell, sfruttamento di CVE noti nei framework più diffusi. Funzionano tramite la corrispondenza delle firme: il motore ispeziona la richiesta e controlla se eventuali modelli corrispondono a quelli registrati nelle regole.

Questo modello ha un limite intrinseco: opera sulla forma della richiesta, non sul suo significato per la domanda. Una regola che rileva ' OR 1=1 -- in un parametro di query attiverà sia un attacco SQLi sia un utente legittimo che cerca tutorial SQL. La regola non ha modo di sapere cosa rappresenta quel parametro nel contesto della tua applicazione: vede solo byte.

Ciò genera falsi positivi prevedibili. Nelle applicazioni con editor di testo RTF, gli endpoint che accettano HTML come input legittimo si bloccano sulle regole XSS. Le API che ricevono JSON con caratteri speciali entrano in conflitto con le regole SQLi. La protezione è reale, ma non è chirurgica.

Cosa può fare un paziente aggressore

I set di regole gestiti sono eccellenti contro gli attacchi alle merci: scanner automatizzati, strumenti come sqlmap in modalità standard, script kiddie che attivano payload generici. Chiunque utilizzi questi vettori senza personalizzazione premerà WAF e si fermerà qui.

Lo scenario diverso è che l'aggressore sappia quale WAF sta proteggendo il bersaglio, spesso informazioni pubbliche tramite intestazioni, cookie o comportamento di risposta. Con questa conoscenza, testa sistematicamente le tecniche di bypass: codifica insolita (codifica URL a più livelli, normalizzazione Unicode, lettere maiuscole miste in parole chiave SQL), carichi utili frammentati in corpi di grandi dimensioni, combinazioni che sfruttano il limite di elaborazione del motore.

Contro un utente malintenzionato determinato che personalizza i payload per un obiettivo specifico, WAF aggiunge lavoro, non impossibilità. Ciò ha ancora valore: aumentare il costo di un attacco riduce il numero di aggressori disposti a pagare per questo. Ma non è una barriera assoluta e trattarla come tale è pericoloso.

Esiste una categoria di vulnerabilità in cui WAF semplicemente non si adatta: la logica aziendale. Se la tua applicazione consente a un utente di visualizzare i dati di un altro manipolando gli ID nell'URL (IDOR), WAF non lo rileverà. La richiesta è formalmente valida, senza payload dannoso. Il problema è nella logica dell'applicazione e l'unica protezione efficace è nel codice.

Livelli e cosa copre effettivamente ciascun piano

La protezione DDoS Layer 3 e 4 è disponibile su tutti i piani, sempre attiva e senza configurazione: mitigazione volumetrica all'edge, prima che il traffico raggiunga la tua infrastruttura.

Il WAF di livello 7, con regole gestite, inizia con il piano Pro a $ 20 al mese. Questo livello sblocca il set di regole gestite da Cloudflare e il set di regole core OWASP. Il piano gratuito consente solo 5 regole personalizzate, senza accesso ad alcun set di regole gestite. Per la maggior parte delle applicazioni con reali requisiti di sicurezza, Pro è il pavimento minimo accettabile.

Le azioni disponibili per regola sono: Blocca (restituisce immediatamente 403), Sfida (visualizza una sfida JavaScript che i bot non possono risolvere), Sfida gestita (Cloudflare decide automaticamente il livello della sfida), Registra (registra senza intraprendere alcuna azione), Salta (salta regole specifiche o interi gruppi) e Consenti (passa senza ispezione). La composizione di queste azioni è il luogo in cui avviene gran parte della calibrazione.

Un dettaglio che invalida il tutto

Esiste un prerequisito che non è ovvio nella documentazione iniziale: WAF funziona solo per i record DNS con il proxy Cloudflare attivo, ciò che l'interfaccia chiama "nuvola arancione". I record configurati come solo DNS (icona grigia) puntano direttamente all'IP di origine. Il traffico non passa attraverso Cloudflare, quindi non si applicano regole WAF, mitigazioni DDoS edge o sfide JavaScript.

Ciò riguarda i sottodomini lasciati solo DNS per comodità: ambienti di staging, API interne accessibili dall'esterno, servizi ausiliari. Se l’aggressore scopre questi sottodomini – e gli strumenti di enumerazione DNS rendono questo banale – ha un percorso diretto verso l’origine senza passare attraverso il WAF. La mappatura dei record DNS e lo stato di ciascuno deve far parte del controllo di sicurezza.

Cosa deve decidere la tua squadra prima dell'attivazione

Abilitare i set di regole gestiti senza un periodo di osservazione è una ricetta per bloccare il traffico legittimo in produzione. Il percorso sicuro dal punto di vista operativo inizia con tutte le regole in modalità Log: vedi cosa verrebbe bloccato senza bloccare nulla, analizzi lo schema di attivazione e identifichi i falsi positivi prima di passare a Blocca o Sfida.

La decisione più critica è come gestire le regole che vengono attivate in modo errato. La disabilitazione della regola a livello globale crea una scappatoia per l'attacco effettivo da cui è protetta. La risposta giusta è una regola Ignora con ambito preciso: questa regola gestita specifica, su questo percorso specifico, per questa condizione specifica. L'ambito chiuso preserva la copertura per tutto il resto dell'applicazione.

Vale anche la pena decidere in anticipo la soglia di sensibilità per l'OWASP Core Ruleset. Funziona in base al punteggio accumulato: ogni regola che si attiva aggiunge punti e l'azione avviene quando il totale supera un limite configurabile. Un limite troppo basso blocca il traffico legittimo; troppo alto, manca attacchi sofisticati. Il punto di pareggio dipende dalla natura della tua applicazione e dal profilo di traffico osservato.