Fail2ban su Ubuntu 24.04: configurazione minima per bloccare SSH e wp-login.php

Chi gestisce anche un solo VPS con WordPress sopra lo sa: i log di auth.log e access.log si riempiono di tentativi automatici entro poche ore dalla messa online. Fail2ban resta lo strumento più diretto per tagliarli alla radice, senza installare plugin PHP che consumano risorse. Questa è la configurazione minima testata su Ubuntu 24.04 LTS (noble), aggiornata al 22 ottobre 2026.

Installazione

Il pacchetto è nei repository ufficiali, componente universe:

sudo apt update
sudo apt install fail2ban

Su Ubuntu 24.04 la versione presente in archivio è fail2ban 1.0.2-3 (noble) e 1.0.2-3ubuntu0.1 in noble-updates.

Il bug da sistemare subito

Su un'installazione pulita di 24.04 il servizio può non partire. Il bug è tracciato su Launchpad come "fail2ban is broken in 24.04 Noble": il pacchetto fail2ban non ha 'python3-setuptools' elencato tra le dipendenze, anche se serve per distutils, richiesto dalla jail sshd di default e quindi perché fail2ban possa funzionare. La causa tecnica è la rimozione del modulo asynchat da Python 3.12, diventato di default con Ubuntu 24.04. La correzione è un comando:

sudo apt install python3-setuptools
sudo systemctl restart fail2ban

Una volta fatto, fail2ban dovrebbe avviarsi correttamente. Verificare con systemctl status fail2ban prima di proseguire: se lo stato non è active (running), il resto della configurazione non serve a niente.

Il file jail.local

Non si tocca mai /etc/fail2ban/jail.conf: viene sovrascritto a ogni aggiornamento del pacchetto. Le regole vanno in un file separato che fail2ban legge come override:

sudo nano /etc/fail2ban/jail.local

Configurazione minima per SSH:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h

Su Ubuntu 24.04 il backend del firewall di default per fail2ban è nftables, mentre il log di sshd viene letto tramite systemd invece che da file: in caso di jail sshd che non intercetta nulla, vale la pena controllare che backend sia impostato su systemd nel blocco [sshd], non su auto con un logpath inesistente.

Bloccare i tentativi su wp-login.php

Fail2ban non include un filtro per WordPress di serie: va creato un filtro e una jail dedicati.

File del filtro, /etc/fail2ban/filter.d/wordpress-login.conf:

[Definition]
failregex = ^<HOST> .* "POST /wp-login.php HTTP.* 200
ignoreregex =

Il dettaglio che conta: il codice di risposta 200 identifica un login fallito (la pagina si ricarica), mentre un accesso riuscito restituisce un redirect 302, che il regex non intercetta. Senza questa distinzione il filtro bannerebbe anche gli utenti legittimi.

Jail corrispondente in /etc/fail2ban/jail.local:

[wordpress-login]
enabled = true
port = http,https
filter = wordpress-login
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 10m
bantime = 1h

Con Apache il logpath da usare è /var/log/apache2/access.log. Prima di fidarsi della jail, conviene testare il filtro sul log reale:

sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-login.conf

Se il numero di righe trovate è zero, il formato del log non corrisponde al regex (capita spesso con reverse proxy o CDN davanti al sito, che riscrivono l'IP in un campo diverso da quello che fail2ban si aspetta).

Applicare e verificare

Dopo aver salvato jail.local:

sudo systemctl restart fail2ban

Per controllare lo stato generale delle jail attive:

sudo fail2ban-client status

Per vedere nel dettaglio una singola jail, con il numero di IP attualmente bannati e lo storico dei fallimenti:

sudo fail2ban-client status sshd
sudo fail2ban-client status wordpress-login

L'output elenca gli indirizzi correntemente in ban. Per rimuoverne uno manualmente, ad esempio per sbloccare un IP finito in jail per errore:

sudo fail2ban-client set sshd unbanip 203.0.113.10

Questa configurazione minima copre il caso base: brute force su SSH e su wp-login.php. Non sostituisce una policy di accesso più ampia (chiavi SSH al posto delle password, 2FA su WordPress), ma riduce da subito il rumore nei log e il carico sul server generato da tentativi automatici.