Cloudflare WAF: regole essenziali per proteggere il sito
Il Web Application Firewall (WAF) di Cloudflare ispeziona ogni richiesta HTTP/HTTPS in ingresso alla ricerca di pattern malevoli noti, bloccando attacchi prima che raggiungano il server di origine. Dalla fine del 2021 il WAF è disponibile anche sul piano Free con un set limitato di regole gestite, mentre Pro e Business sbloccano funzionalità avanzate. In questa guida vediamo come configurare le regole essenziali per coprire gli attacchi più diffusi.
Architettura del WAF
Il WAF di Cloudflare opera su tre livelli sovrapposti: Managed Rules mantenute da Cloudflare e aggiornate giornalmente, Custom Rules definite dall'utente con linguaggio espressivo, e Rate Limiting Rules per limitare la frequenza di richieste. Le richieste passano attraverso tutti i livelli e una sola azione finale viene applicata: Block, Challenge, JS Challenge, Managed Challenge, Log o Skip.
Procedura passo-passo
- Accedi al dashboard e seleziona il dominio.
- Vai su Security → WAF.
- Nella scheda Managed Rules attiva il set Cloudflare Managed Ruleset.
- Imposta la sensitivity su Low per iniziare, poi aumenta gradualmente.
- Aggiungi il ruleset OWASP Core Ruleset con paranoia level 1.
- Vai su Custom Rules e crea regole specifiche per il tuo stack.
- Attiva Browser Integrity Check e Hotlink Protection.
- Imposta il Security Level globale su Medium o High.
- Monitora gli eventi dalla scheda Events per identificare falsi positivi.
- Aggiungi exception per IP, ASN o path interni quando necessario.
Regole essenziali da attivare subito
Per qualsiasi sito conviene attivare immediatamente questi blocchi. Blocco metodi non standard: regola custom che blocca metodi diversi da GET, POST, HEAD, OPTIONS sul perimetro pubblico. Blocco User-Agent vuoto: 99% sono bot malevoli. Blocco country specifiche: se vendi solo in Italia, blocca paesi noti per traffico fraudolento (Cina, Russia, Nigeria) sulle pagine checkout. Challenge su /wp-login.php: WordPress è target privilegiato di brute force.
Esempi di Custom Rules
Esempio 1, blocco SQL injection nei query string: (http.request.uri.query contains "union+select") or (http.request.uri.query contains "or+1=1") action Block. Esempio 2, challenge su admin per IP non italiani: (http.request.uri.path contains "/admin") and (ip.geoip.country ne "IT") action Managed Challenge. Esempio 3, blocco vulnerability scanner: (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "acunetix") action Block.
Errori comuni e come risolverli
- Falso positivo blocca utenti legittimi: identifica la regola dall'Events log e aggiungi exception per path o cookie.
- Editor WYSIWYG bloccato: il WAF interpreta tag HTML inseriti come XSS. Disabilita la regola XSS sul path admin.
- Upload file bloccato: dimensione richiesta supera limite. Verifica la regola "large body" e l'header Content-Length.
- Geoblocking non funziona: il visitatore usa VPN. Considera regole basate su ASN per identificare hosting provider.
- Bot legittimi (Googlebot, Bing) bloccati: attiva Verified Bots allow nella sezione Bots.
Sensitivity e paranoia level
Le Managed Rules hanno un livello di sensitivity (Low, Medium, High) e l'OWASP Core ha paranoia level da 1 a 4. Aumentare questi parametri rende il WAF più restrittivo ma aumenta i falsi positivi. La strategia consigliata: parti con livelli bassi, attiva la modalità Log only per 1-2 settimane analizzando gli eventi, poi alza gradualmente passando ad azione Block o Challenge.
Domande frequenti
D: Il WAF rallenta il sito?
R: No, l'ispezione avviene in pochi microsecondi sull'edge. L'overhead è trascurabile.
D: Quante regole posso creare nel piano Free?
R: Free ha 5 Custom Rules, Pro 20, Business 100, Enterprise illimitate.
D: Le Managed Rules sono visibili?
R: Sì la lista è visibile, ma il dettaglio dei pattern è proprietà Cloudflare.
D: Posso testare una regola prima di attivarla?
R: Sì, ogni regola può essere creata con azione Log che osserva senza bloccare.
Considerazioni operative finali
Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.
Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.
Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.
Hai bisogno di aiuto?
Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.