Quando ho analizzato i log di un ente sanitario pubblico con 2.000 endpoint, ho contato oltre 15.000 tentativi di accesso SSH falliti in una singola notte. I bot scansionano interi subnet IP, provano dizionari di password, e martellano la porta 22 fino a trovare una credenziale debole. Se non hai un sistema automatizzato che blocca questi attacchi brute force, stai solo sperando che nessuno indovini la password giusta. Speranza che non ha mai protetto nessun server. Fail2ban è il tool che trasforma i tuoi log di autenticazione in un firewall reattivo. Legge i tentativi falliti, identifica gli IP malevoli, e aggiorna le regole di iptables o nftables per droppare il traffico in tempo reale. In questa guida configureremo Fail2ban su Linux per proteggere SSH e i servizi web, partendo dai prerequisiti fino ai test di funzionamento.
Prerequisiti / Ambiente di test
Prima di iniziare, assicurati di avere l’accesso root o un utente con privilegi sudo. Questa guida è testata su Ubuntu 22.04/24.04 e CentOS Stream 9, ma la logica è identica su qualsiasi distribuzione Linux moderna. Devi avere un firewall attivo, come UFW o firewalld, e un server SSH esposto. Non applicare configurazioni restrittive su un server di produzione senza prima testarle in un ambiente isolato. Un ban accidentale del tuo IP ti bloccherebbe fuori dal sistema.
Cos’è Fail2ban e perché ogni server Linux lo deve avere
Fail2ban è un daemon scritto in Python che monitora i file di log alla ricerca di pattern specifici. Quando rileva un numero anomalo di errori di autenticazione provenienti dallo stesso IP, interviene modificando le regole del firewall per bloccare quel nodo. Non è un sostituto dell’autenticazione a chiave pubblica o di un VPN, ma è il primo strato di difesa contro il rumore di fondo di internet. Riduce il carico sul server, abbassa il rumore nei log, e impedisce ai bot di consumare risorse. Per rispettare standard come NIS2 e ISO 27001:2022, proteggere l’accesso remoto è obbligatorio. Fail2ban ti permette di configurare una risposta automatica e proporzionale agli attacchi.
Installazione su Ubuntu/Debian e CentOS/RHEL
L’installazione richiede un solo comando. Su Ubuntu e Debian, il pacchetto è nei repository ufficiali.
sudo apt install fail2banSu CentOS Stream, RHEL e derivate, si trova in EPEL.
sudo dnf install epel-release
sudo dnf install fail2banUna volta installato, abilita il servizio al boot e avvialo.
sudo systemctl enable fail2ban
sudo systemctl start fail2banVerifica lo stato. Il daemon deve essere attivo e senza errori.
sudo systemctl status fail2banConfigurazione jail.local — i parametri che contano
Il pacchetto fornisce un file di configurazione predefinito, jail.conf. Non devi mai modificarlo. Gli aggiornamenti del sistema lo sovrascriveranno. La pratica corretta è copiarlo in jail.local. Fail2ban legge prima .local, e i tuoi parametri avranno la precedenza.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localApri jail.local con il tuo editor. I parametri globali che devi calibrare si trovano nella sezione [DEFAULT].
bantime: la durata del ban. Il default è 10 minuti, troppo basso. Imposta 3600 secondi (1 ora) o più per gli attacchi sostenuti.findtime: la finestra temporale in cui Fail2ban conta i tentativi. 600 secondi (10 minuti) è un buon compromesso.maxretry: il numero di fallimenti prima del ban. Imposta 3 per l’SSH, 5 per i servizi web.
Questi valori definiscono l’aggressività della tua difesa. Un bantime troppo corto permette ai bot di riprovare, un maxretry troppo alto dà loro troppi tentativi.
Proteggere SSH: impostazioni consigliate per produzione
Ora attiviamo la jail specifica per l’SSH. Cerca la sezione [sshd] nel file jail.local e configurala in questo modo:
[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 3600
findtime = 600Con questa configurazione, dopo 3 tentativi di login falliti in 10 minuti, l’IP del mittente viene bannato per un’ora. Se la tua porta SSH non è la 22 standard, cambia il parametro port con il numero corretto. Dopo aver salvato il file, riavvia il servizio per applicare le regole.
sudo systemctl restart fail2ban[Leggi anche: Hardening SSH su Linux: 10 Impostazioni Essenziali]
Proteggere Nginx e Apache con Fail2ban
Fail2ban non protegge solo l’SSH. I server web sono bersagli costanti per attacchi di tipo brute force sulle aree di login o scan di vulnerabilità. Devi creare jail personalizzate per i log di Nginx o Apache. Per Nginx, abilita la jail [nginx-http-auth] per proteggere l’autenticazione Basic Auth. Per Apache, usa [apache-auth]. Entrbe leggono i log degli errori di autenticazione e applicano lo stesso principio: troppi errori uguali portano al ban dell’IP. Aggiungi i filtri in jail.local specificando il percorso del log corretto nel parametro logpath.
Monitorare i ban in tempo reale
Per capire se Fail2ban sta lavorando, controlla lo stato delle jail attive. Il comando mostra gli IP bannati e il conteggio dei tentativi.
sudo fail2ban-client status sshdL’output ti restituisce il numero di IP bannati e la lista degli indirizzi. Se vedi la lista popolarsi, significa che il daemon sta intercettando il traffico malevolo. Controlla i log di sistema per i dettagli su ogni azione intrapresa.
sudo tail -f /var/log/fail2ban.logSbloccare un IP bannato per errore
Prima o poi banni un utente legittimo. Un collega che dimentica la password, un automatismo aziendale con credenziali scadute. Non serve a riavviare il servizio. Usa il client per rimuovere il ban in tempo reale.
sudo fail2ban-client set sshd unbanip 1.2.3.4Sostituisci 1.2.3.4 con l’indirizzo IP reale. L’azione è immediata. Se non ricordi l’IP, usa sudo fail2ban-client status sshd per leggere la lista dei ban attivi.
Testare che Fail2ban stia funzionando
Non affidarti alla speranza. Testa la configurazione. Da una macchina esterna, prova a fare login SSH con una password sbagliata per 3 volte consecutive. Al quarto tentativo, la connessione dovrebbe rifiutarsi (Connection refused o Timeout). Controlla sul server.
sudo fail2ban-client status sshdL’IP di test deve apparire nella lista dei bannati. Se non appare, controlla che il parametro logpath nella jail punti al file di log corretto del tuo sistema (es. /var/log/auth.log su Ubuntu, /var/log/secure su RHEL). Un percorso errato è la causa più frequente di malfunzionamento.
Errori comuni e troubleshooting
Il problema più ricorrente è il file di log sbagliato. Se Fail2ban non rileva gli attacchi, verifica il percorso in logpath. Un altro errore frequente è la mancanza del backend di firewall. Fail2ban si appoggia a iptables, nftables o firewalld. Se usi UFW su Ubuntu, assicurati che la jail abbia banaction = ufw. Senza questa direttiva, Fail2ban scrive regole in iptables che UFW ignora, creando conflitti. Infine, le espressioni regolari nei filtri predefiniti potrebbero non allinearsi con il formato di log della tua versione specifica di un servizio. Controlla i filtri in /etc/fail2ban/filter.d/ e adatta il regex se necessario.
Conclusioni con takeaway operativi
Fail2ban trasforma i log passivi in una difesa attiva. L’ho installato come primo step in una PA con 2.000 endpoint per fermare il rumore di fondo dei bot, e l’impatto sui log è stato immediato. Ricorda tre regole: copia sempre jail.conf in jail.local, abbassa il maxretry e alza il bantime per l’SSH, e allinea sempre il banaction al tuo firewall di sistema. Per approfondire le direttive e i filtri, consulta la documentazione ufficiale su fail2ban.readthedocs.io. Non lasciare i tuoi server esposti alla forza bruta.
