WAF e firewall applicativo WordPress: perché la protezione a livello server ferma gli attacchi prima di WordPress

C'è una differenza fondamentale tra un plugin di sicurezza e un firewall applicativo, e non è sottile. Un plugin di sicurezza vive dentro WordPress: scansiona i file, monitora le modifiche, blocca i login dopo N tentativi. Ma per fare tutto questo, la richiesta malevola deve prima arrivare a WordPress, essere processata da PHP, e solo allora il plugin può intervenire. Un WAF — Web Application Firewall — sta un livello prima: ispeziona ogni richiesta HTTP e decide se farla passare o bloccarla prima che raggiunga WordPress del tutto.

La differenza pratica è tra scoprire che qualcuno sta attaccando e impedire che l'attacco arrivi. Un plugin di sicurezza ti dice che ha bloccato 500 tentativi di login stanotte. Un WAF fa sì che quei 500 tentativi non consumino mai risorse del tuo server, perché li ferma al perimetro. Per i siti sotto attacco costante, che sono quasi tutti i siti WordPress pubblici, questa differenza si traduce in prestazioni e stabilità.

Cosa fa un WAF che un plugin non può fare

Un WAF ispeziona il traffico HTTP in tempo reale e applica regole che riconoscono pattern di attacco noti: SQL injection, cross-site scripting, file inclusion, esecuzione di codice remoto. Le regole sono aggiornate costantemente contro le vulnerabilità nuove. Un plugin di sicurezza può fare qualcosa di simile, ma con due limiti: lavora dentro PHP, quindi ogni richiesta bloccata ha comunque consumato risorse per arrivare fin lì; e le sue regole sono limitate a quello che può vedere dal livello di WordPress.

Il WAF vede l'intera richiesta HTTP — header, body, parametri — prima di WordPress, e può bloccare su pattern che WordPress non vedrebbe mai, come attacchi a livello di protocollo o exploit che colpiscono il server web stesso.

Le tre famiglie di WAF per WordPress

La prima è il WAF basato su CDN, come Cloudflare o Sucuri. Sta sulla rete del provider, filtra il traffico prima che arrivi al tuo server, e ha il vantaggio di assorbire gli attacchi DDoS distribuiti che altrimenti saturerebbero la tua connessione. La seconda è il WAF a livello di server web, come mod_security per Apache o Nginx con regole OWASP. Sta sul tuo server, ispeziona ogni richiesta, e non dipende da un servizio esterno. La terza è il WAF plugin, che vive dentro WordPress — è il meno efficace dei tre ma il più semplice da attivare.

Abilitare mod_security con regole OWASP

Se il tuo hosting supporta mod_security, le regole OWASP Core Rule Set sono il punto di partenza. Bloccano i pattern di attacco più comuni. Su Apache si abilita nel virtual host:

# Abilita mod_security con regole OWASP CRS
<IfModule mod_security2.c>
    SecRuleEngine On
    # Carica le regole OWASP Core Rule Set
    IncludeOptional /etc/modsecurity/owasp-crs/*.conf

    # Escludi falsi positivi comuni per WordPress
    SecRuleRemoveById 920300 949110 980130

    # Non bloccare l'admin di WordPress (regola troppo aggressiva)
    <LocationMatch /wp-admin/admin-ajax.php>
        SecRuleRemoveById 942100
    </LocationMatch>
</IfModule>

Cloudflare come WAF: le regole personalizzate

Con Cloudflare il WAF è gestito e aggiornato dal provider. Oltre alle regole gestite, puoi aggiungere regole personalizzate per bloccare pattern specifici. Per esempio, bloccare l'accesso a xmlrpc.php e limitare wp-login.php:

# Regola Cloudflare: blocca xmlrpc.php
(http.request.uri.path eq "/xmlrpc.php")
Action: Block

# Regola Cloudflare: rate limit su wp-login.php (10 richieste/minuto per IP)
(http.request.uri.path eq "/wp-login.php")
Action: Rate limit, 10 requests per 60 seconds

Perché il WAF non sostituisce tutto il resto

Un WAF ferma gli attacchi noti al perimetro, ma non sostituisce gli aggiornamenti, le password forti, il backup verificato, o l'hardening del login. Un WAF non ferma un attaccante che ha già le credenziali valide, perché la richiesta legittima passa. La sicurezza a strati è il principio: il WAF è lo strato più esterno, gli aggiornamenti e l'hardening sono gli strati interni, il backup è l'ultima risorsa.

Il nostro approccio: WAF attivo al perimetro (Cloudflare o mod_security), aggiornamenti controllati in staging, hardening del login con 2FA, backup verificato, e scansione periodica dei file. Nessuno strato da solo basta; insieme riducono drasticamente la superficie d'attacco. Un audit di sicurezza valuta quali strati sono presenti e quali mancano sul tuo sito.