Fail2ban WordPress: bloccare brute force automaticamente

Perché Fail2ban è superiore ai plugin WordPress

Quando gestisci decine o centinaia di siti WordPress per clienti, i plugin di sicurezza diventano un collo di bottiglia. Ogni tentativo di login fallito deve essere processato da PHP, caricato da MySQL, e validato dall’applicazione. Con attacchi distribuiti che generano migliaia di richieste al minuto, questo approccio consuma risorse server preziose.

Fail2ban opera a livello di sistema operativo, analizzando i log e bloccando IP malevoli direttamente con iptables o firewalld prima che le richieste raggiungano PHP. Il vantaggio è duplice: protezione più efficace e zero overhead applicativo.

Secondo dati Wordfence del 2025, il 94% degli attacchi WordPress sono brute force automatizzati. Un singolo sito può ricevere 50.000+ tentativi di login al giorno. Fail2ban gestisce questo volume senza impattare le performance del sito.

Installazione e configurazione base

Fail2ban è disponibile nei repository ufficiali delle principali distribuzioni Linux. L’installazione richiede accesso root al server.

Installazione su Ubuntu/Debian

apt update
apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

Installazione su CentOS/RHEL

yum install epel-release -y
yum install fail2ban fail2ban-systemd -y
systemctl enable fail2ban
systemctl start fail2ban

Dopo l’installazione, la struttura di configurazione si trova in /etc/fail2ban/. Non modificare mai i file .conf direttamente: crea sempre file .local che sovrascrivono le impostazioni di default.

Configurare il filtro WordPress

Fail2ban usa espressioni regolari per analizzare i log e identificare pattern di attacco. Per WordPress, dobbiamo creare un filtro personalizzato che riconosca tentativi di login falliti.

Creare il file filtro

Crea il file /etc/fail2ban/filter.d/wordpress-auth.conf:

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php
            ^<HOST> .* "POST /xmlrpc\.php
            ^<HOST> .* "POST .*/wp-cron\.php
ignoreregex =

Questa configurazione intercetta tre vettori di attacco principali:

• wp-login.php: il form di login standard
• xmlrpc.php: spesso abusato per attacchi amplificati
• wp-cron.php: talvolta targetizzato per DDoS applicativi

Filtro avanzato con log WordPress

Se usi un plugin di logging come WP Activity Log o Simple History, puoi creare filtri più granulari basati sui loro log specifici. Esempio con log personalizzati in /var/log/wordpress/auth.log:

[Definition]
failregex = Authentication failure for .* from <HOST>
            Failed login attempt .* \[<HOST>\]
ignoreregex =

Questo approccio è più preciso ma richiede configurazione aggiuntiva per centralizzare i log WordPress.

Configurare la jail WordPress

Le “jail” sono contenitori di regole che definiscono come e quando bannare IP. Crea /etc/fail2ban/jail.d/wordpress.local:

[wordpress-auth]
enabled = true
port = http,https
filter = wordpress-auth
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300
bantime = 3600
action = iptables-multiport[name=wordpress, port="http,https", protocol=tcp]

Parametri critici spiegati

• maxretry: numero di tentativi falliti prima del ban (5 è un buon compromesso)
• findtime: finestra temporale in secondi per contare i tentativi (300 = 5 minuti)
• bantime: durata del ban in secondi (3600 = 1 ora, usa -1 per ban permanente)
• logpath: percorso del log da monitorare (adatta a nginx o Apache)

Per Apache, il logpath tipico è /var/log/apache2/access.log o /var/log/httpd/access_log.

Configurazione multi-sito

Se gestisci più siti su server diversi, puoi usare log separati per ogni dominio:

[wordpress-client1]
enabled = true
filter = wordpress-auth
logpath = /var/log/nginx/client1.com-access.log
maxretry = 5

[wordpress-client2]
enabled = true
filter = wordpress-auth
logpath = /var/log/nginx/client2.com-access.log
maxretry = 3

Questo permette policy di sicurezza differenziate per cliente.

Testing e verifica

Prima di andare in produzione, testa sempre la configurazione per evitare di bloccarti fuori o creare falsi positivi.

Validare la sintassi

fail2ban-client -t
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-auth.conf

Il secondo comando testa il filtro contro log reali e mostra quante righe matchano.

Applicare le modifiche

systemctl restart fail2ban
fail2ban-client status
fail2ban-client status wordpress-auth

L’output mostra IP attualmente bannati e statistiche della jail.

Simulare un attacco

Da un altro IP, esegui 6 tentativi di login falliti consecutivi. Verifica il ban con:

fail2ban-client status wordpress-auth

Dovresti vedere l’IP nella lista “Currently banned”.

Ottimizzazioni per ambienti ad alto traffico

In contesti con migliaia di siti WordPress, alcune ottimizzazioni sono cruciali per performance e affidabilità.

Whitelist IP fidati

Aggiungi al file /etc/fail2ban/jail.local:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 IP_UFFICIO IP_VPN

Include sempre IP del tuo team e sistemi di monitoring per evitare autoblocking.

Ridurre carico I/O su log

Per server con 50+ siti, il parsing continuo dei log può diventare un problema. Considera:

• Usare backend = systemd invece di polling file quando possibile
• Implementare log rotation aggressivo con compressione immediata
• Montare /var/log su filesystem dedicato o SSD

Integrazione con firewall cloud

Per architetture dietro Cloudflare o AWS WAF, configura Fail2ban per aggiornare regole firewall cloud tramite API:

[wordpress-auth]
action = iptables-multiport[name=wordpress, port="http,https"]
         cloudflare-apiv4[cftoken=TOKEN, cfuser=EMAIL]

Questo propaga i ban a livello edge, riducendo traffico verso l’origin server.

Monitoring e alerting

Fail2ban offre hook per integrare notifiche. Aggiungi alla jail:

action = iptables-multiport[name=wordpress, port="http,https"]
         sendmail-whois[name=WordPress, dest=security@agency.com]

Per integrazione con Slack o sistemi di ticketing, usa action personalizzate in /etc/fail2ban/action.d/.

Metriche da monitorare

• Numero di ban per ora/giorno
• IP più frequentemente bannati (possibili botnet)
• Siti più targetizzati
• Tempo medio prima del ban

Questi dati aiutano a identificare pattern e ottimizzare le soglie di ban. Integrali con stack di monitoring esistenti via log shipping o script custom.

Limitazioni e considerazioni

Fail2ban non è una soluzione completa. Alcune limitazioni importanti:

• Attacchi distribuiti: botnet con migliaia di IP diversi bypassano facilmente soglie basate su singolo IP
• IP condivisi: ban di NAT aziendali o VPN pubbliche possono bloccare utenti legittimi
• Rate limiting applicativo: Fail2ban non previene attacchi che rispettano le soglie (10 tentativi/ora da 1000 IP)

Per protezione completa, combina Fail2ban con:

• Rate limiting a livello web server (nginx limit_req_zone)
• 2FA obbligatorio per utenti amministratori
• Web Application Firewall (ModSecurity, Cloudflare WAF)
• Monitoring comportamentale con machine learning

Se gestisci l’infrastruttura tramite piattaforme dedicate per agenzie, verifica se offrono integrazione nativa con Fail2ban o alternative managed.

FAQ

Fail2ban può bloccare Google o bot legittimi?

Sì, se configurato male. I bot rispettabili non tentano mai il login, quindi un filtro corretto su wp-login.php POST non li tocca. Usa sempre ignoreip per IP di monitoring e aggiungi User-Agent whitelist se necessario. Per sicurezza, monitora i ban nei primi giorni e affina le regex.

Quante risorse consuma Fail2ban su server condivisi?

Minimal: 20-50MB RAM e <1% CPU in idle. Durante attacchi intensi, il parsing log può raggiungere 5-10% CPU, ma è comunque drasticamente inferiore al carico che PHP/MySQL avrebbero gestendo le richieste. Su VPS da 2GB gestisce tranquillamente 100+ siti WordPress.

Come gestire IP dinamici di utenti legittimi?

Tre approcci: 1) Aumenta maxretry a 8-10 per dare margine a typo, 2) Riduci bantime a 30-60 minuti invece di ore, 3) Implementa sistema di unban self-service via email con token temporaneo. La terza opzione richiede script custom ma migliora UX per clienti enterprise.

Fail2ban funziona con setup Docker o Kubernetes?

Con Docker, Fail2ban va installato sull’host, non nei container. Deve accedere a log dei container (monta volumi o usa log driver) e manipolare iptables dell’host. Su Kubernetes è più complesso: meglio usare network policy native o service mesh come Istio per rate limiting. Fail2ban è ottimale per VPS tradizionali o bare metal.

È meglio ban permanente o temporaneo?

Dipende. Ban permanenti (bantime = -1) accumuleranno migliaia di IP nel tempo, appesantendo iptables. Ban di 24-48 ore sono efficaci contro botnet che ciclano target. Per IP che attaccano ripetutamente, considera integrazioni con threat intelligence feed per identificare e bannare permanentemente solo IP noti come malevoli.