Installare Fail2ban su Ubuntu 24.04 per bloccare i bot SSH

Che cosa fa realmente Fail2ban

Fail2ban è un demone che legge i log. Monitora i messaggi di autenticazione SSH e, dopo alcuni tentativi non riusciti dallo stesso indirizzo entro un breve intervallo, esegue un comando del firewall che blocca temporaneamente quell’indirizzo. Questa è l’idea generale. La configurazione richiede circa trenta righe in un unico file e, su Ubuntu 24.04, l’installazione consiste in un solo comando apt che attiva la protezione prima ancora di modificare qualsiasi impostazione.

È importante chiarire che cosa sia e che cosa non sia. Fail2ban non autentica gli utenti, non cifra i dati e non impedisce un singolo tentativo di accesso mirato: blocca soltanto i tentativi ripetuti dalla stessa origine. È un filtro del rumore e un limitatore della frequenza, non una serratura. Il suo compito è impedire che le scansioni continue della porta 22 consumino CPU, banda e spazio nei log e rallentare un eventuale attaccante che deve operare un indirizzo alla volta.

Cosa non sostituisce Fail2ban

Fail2ban è il terzo livello di difesa, non il primo. Se il server accetta ancora password per SSH, una botnet distribuita su migliaia di indirizzi può continuare a tentare l'autenticazione, perché ogni indirizzo resta sotto la soglia di ban e non la supera mai. La difesa efficace è l'autenticazione con sole chiavi, che rende impossibili i tentativi basati su password indipendentemente dal numero di tentativi. Fail2ban, aggiunto all'autenticazione con sole chiavi, svolge due funzioni utili: riduce nei log il rumore generato dai tentativi di forza bruta ed espelle rapidamente gli scanner, impedendo loro di continuare a colpire la porta. Consideralo una misura di difesa in profondità. Viene dopo l'autenticazione con chiavi e dopo il firewall, mai prima.

Prerequisiti e realtà di Ubuntu 24.04

È necessario un VPS con Ubuntu 24.04, accesso root o sudo e SSH già funzionante, idealmente con autenticazione tramite chiave. Fail2ban richiede poche risorse: alcune decine di megabyte di RAM e nessuna modifica ai limiti predefiniti.

Ora viene il punto che le guide più datate indicano spesso in modo errato. Per anni il consiglio standard è stato: «installa Fail2ban, quindi aggiungi backend = systemd, perché Ubuntu ha smesso di scrivere /var/log/auth.log». Questo consiglio descrive una modifica reale: le immagini moderne per server e cloud vengono distribuite senza rsyslog, quindi SSH scrive i log soltanto nel journal di systemd e quel file di testo non esiste più. Tuttavia, in Ubuntu 24.04 il pacchetto Fail2ban tiene già conto di questa situazione. Il pacchetto installa /etc/fail2ban/jail.d/defaults-debian.conf e questo file, non le impostazioni predefinite upstream, determina la configurazione effettivamente usata dal server:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Leggi con attenzione questa configurazione, perché chiarisce due aspetti prima di modificare qualsiasi cosa. backend = systemd indica che il jail SSH legge il journal, quindi l'assenza di auth.log non è un problema. banaction = nftables indica che i ban vengono applicati tramite nftables, il firewall effettivamente usato da Ubuntu 24.04, anziché tramite il vecchio iptables. Inoltre, [sshd] enabled = true indica che il jail è attivo già dal primo avvio. In pratica, un'installazione standard di apt install fail2ban su Ubuntu 24.04 blocca automaticamente i tentativi di brute force contro SSH. Nella maggior parte dei casi è sufficiente verificare questo comportamento, configurare la policy e assicurarsi di non bloccarsi fuori dal server.

Il problema del vecchio auth.log si presenta ancora in tre situazioni, che è utile riconoscere: hai installato Fail2ban con pip invece di apt, quindi defaults-debian.conf non esiste; ti trovi in un container senza privilegi e senza un journal di systemd da leggere; oppure hai seguito un tutorial datato e hai incollato backend = auto nel tuo jail.local, sovrascrivendo la configurazione predefinita funzionante. La sezione dedicata alle modalità di errore mostra esattamente come si manifesta ciascuna situazione.

Passaggio 1: installare Fail2ban e verificare che stia già applicando i ban

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 distribuisce Fail2ban 1.0.2 e il pacchetto installa python3-systemd come dipendenza obbligatoria, quindi il backend del journal dispone di tutto il necessario. Il servizio viene abilitato e avviato automaticamente:

sudo systemctl status fail2ban

Devi ottenere active (running). Poi controlla il jail che sta già svolgendo il suo compito:

sudo fail2ban-client status sshd

Su un VPS pubblico raggiungibile anche solo da pochi minuti, spesso vedrai già dei tentativi falliti conteggiati e alcuni indirizzi sottoposti a ban: Internet esegue scansioni continue sulla porta 22. Questa è la prova che la configurazione predefinita funziona. Da qui in poi la perfezioni, invece di crearla da zero.

Passaggio 2: modifica jail.local, mai jail.conf

Fail2ban conserva le impostazioni predefinite upstream in /etc/fail2ban/jail.conf. Non modificare questo file. Ogni apt upgrade del pacchetto può sostituirlo e le modifiche andrebbero perse senza alcun avviso. Fail2ban legge i file in un ordine fisso: prima jail.conf, poi tutti i file in jail.d/, quindi jail.local; prevale l’ultimo valore definito. Il file .local è riservato alle tue configurazioni e gli aggiornamenti del pacchetto non lo modificano mai. La stessa regola vale per i filtri: un file *.local sostituisce il file filter.d/*.conf fornito dal pacchetto.

Devi quindi creare un piccolo jail.local che sovrascriva soltanto le poche impostazioni necessarie, lasciando intatti sia jail.conf sia il file jail.d/defaults-debian.conf fornito dal pacchetto come riferimento.

Passaggio 3: Scrivere /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Inserire questo contenuto e sostituire l'indirizzo nella riga ignoreip con il proprio IP pubblico:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Ogni riga ha una funzione precisa:

• bantime, findtime e maxretry definiscono la policy. Il valore predefinito fornito, bantime, è di soli dieci minuti; un'ora è un valore minimo più adeguato. Cinque tentativi falliti dallo stesso indirizzo nell'arco di dieci minuti attivano il ban. Un utente può inserire una password errata una o due volte; cinque tentativi falliti in dieci minuti indicano uno script.
• ignoreip è una misura di sicurezza. Inserire qui l'indirizzo pubblico da cui ci si connette, in modo che Fail2ban non possa mai bloccare l'accesso al proprio server. Una connessione domestica con IP dinamico è un motivo per preferire l'approccio tramite VPN descritto alla fine, non per omettere questa riga.
• bantime.increment = true aumenta la durata di ogni ban successivo: un'ora, poi due, quindi quattro, fino a bantime.maxtime. Gli indirizzi che continuano a ripresentarsi vengono bloccati progressivamente più a lungo.

Individuare l'indirizzo da inserire nella whitelist dalla macchina da cui si esegue la connessione SSH, non dal server:

curl -s ifconfig.me

Qui è possibile generare un jail.local configurato per le proprie porte e policy di ban, quindi incollarlo nel file:

Passaggio 4: riavviare e verificare che legga il journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Il comando -t esegue prima un test della configurazione, quindi un errore di battitura in jail.local viene segnalato immediatamente invece di lasciare il servizio non avviato. Lo stato di un jail funzionante è simile al seguente:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Il numero che dimostra che Fail2ban sta leggendo effettivamente i log degli accessi è Total failed. Se è maggiore di zero, oppure aumenta quando si forza intenzionalmente un accesso non riuscito da un'altra macchina, il journal viene letto e la configurazione è completa. Se rimane 0 indipendentemente dal numero di tentativi non riusciti e si è certi di non eseguire il test dall'indirizzo indicato in ignoreip, consultare le modalità di errore riportate di seguito.

Si noti che la riga Journal matches continua a indicare sshd.service. In Ubuntu l'unità SSH è in realtà ssh.service, ma il filtro fornito include corrispondenze anche per _COMM=sshd. Inoltre, in OpenSSH 24.04 i tentativi non riusciti vengono registrati da un processo denominato sshd, quindi la corrispondenza funziona. Questo dettaglio è rilevante solo con versioni più recenti di OpenSSH (9.8 o successive), nelle quali il processo worker per ogni connessione è sshd-session; le modalità di errore includono anche questo caso.

Passaggio 5: osservare un ban reale o forzarne uno per i test

Su qualsiasi VPS pubblico, i ban reali arrivano autonomamente entro pochi minuti. Per osservarne uno, segui il log:

sudo tail -f /var/log/fail2ban.log

Un ban ha questo aspetto:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Per verificare il funzionamento end-to-end senza attendere, applica manualmente il ban a un indirizzo usato per la documentazione, mai al tuo:

sudo fail2ban-client set sshd banip 10.0.0.66

Il comando stampa 1 e l'indirizzo compare sotto Banned IP list in fail2ban-client status sshd. Ora verifica che il blocco esista effettivamente nel firewall. In Ubuntu 24.04 il firewall è nftables, non iptables:

sudo nft list table inet f2b-table

Vedrai un set denominato addr-set-sshd che contiene 10.0.0.66 e una chain f2b-chain che rifiuta qualsiasi origine presente in quel set. Se fail2ban-client indica che un indirizzo è bannato, ma non compare nulla in nft list, l'azione di ban non corrisponde alla configurazione del firewall. Consulta la nota su nftables/iptables nella sezione relativa ai problemi.

Passaggio 6: rimuovere il proprio ban e recuperare l'accesso dopo un blocco

Se hai applicato un ban a un indirizzo che non avresti dovuto bloccare, incluso il tuo, rimuovilo:

sudo fail2ban-client set sshd unbanip 10.0.0.66

In caso di successo, restituisce 1. Per rimuovere tutti i ban da tutte le jail:

sudo fail2ban-client unban --all

Non fare affidamento su una sessione SSH già aperta: il ban di nftables rifiuta ogni pacchetto proveniente dall'indirizzo bloccato diretto alla porta 22, incluse le connessioni già stabilite, quindi una sessione esistente si blocca non appena il ban diventa attivo. Se applichi un ban al tuo indirizzo e non disponi di una voce ignoreip, perdi l'accesso fino alla scadenza del ban. Recupera l'accesso tramite la console Web del provider, VNC o seriale, che non usa SSH, quindi attendi la scadenza di bantime oppure esegui lì il comando per rimuovere il ban.

Passaggio 7: rendere persistenti i ban e aumentarne la durata

Fail2ban conserva i ban attivi in un piccolo database SQLite in /var/lib/fail2ban/fail2ban.sqlite3, quindi restano disponibili dopo il riavvio del servizio o del server. Non vengono persi. Le righe bantime.increment aggiunte in precedenza trasformano ogni recidivo in un problema progressivamente più lungo per il suo stesso indirizzo, con una durata che raddoppia approssimativamente da un'ora fino a circa una settimana.

Per applicare anche una policy di sistema basata su «tre tentativi», Fail2ban include il jail recidive. Questo jail monitora il proprio /var/log/fail2ban.log e applica ban più lunghi a ogni indirizzo che è stato bannato ripetutamente in jail diversi. Poiché il tuo [DEFAULT] usa ora il backend systemd, imposta nuovamente questo jail sul file di log che deve leggere:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto con l'esplicito logpath mantiene recidive collegato al file di testo fail2ban.log. È in quel file che compaiono effettivamente le righe Ban conteggiate. Il valore predefinito systemd impostato globalmente lo collegherebbe invece al journal, dove queste righe non compaiono.

Passo 8: abbinalo all’autenticazione SSH con sole chiavi, o meglio ancora a una VPN

Fail2ban è utile solo insieme all’autenticazione tramite chiavi. In un file di override nella directory /etc/ssh/sshd_config.d/, ad esempio /etc/ssh/sshd_config.d/00-hardening.conf, imposta:

PasswordAuthentication no
KbdInteractiveAuthentication no

Quindi esegui sudo systemctl restart ssh. Con le password disabilitate, un attacco brute force non può avere successo; Fail2ban serve quindi a ridurre il rumore nei log e a bloccare rapidamente gli scanner. Una soluzione ancora più sicura consiste nel non esporre affatto SSH a Internet: instrada SSH attraverso una VPN WireGuard self-hosted e configura il firewall in modo che la porta 22 risponda solo tramite il tunnel. Nessuno può eseguire un attacco brute force su una porta che non può raggiungere, e Fail2ban diventa una misura di contenimento, non la prima linea di difesa.

Fail2ban non serve soltanto per SSH. Qualsiasi servizio che registri nei log i tentativi di accesso falliti può avere un jail: un server di posta, un sito nginx o un gestore di password Vaultwarden self-hosted il cui accesso web non vuoi lasciare esposto al credential stuffing. Dopo aver pubblicato un’applicazione web dietro un sito nginx con un certificato Let's Encrypt, configura un filtro Fail2ban sul relativo access log, nello stesso modo in cui il jail SSH analizza il journal.

Modalità di errore, con le stringhe esatte visualizzate

"Have not found any log file for sshd jail", e Fail2ban non si avvia. Questo è il vecchio problema auth.log e, su Ubuntu 24.04, si verifica solo se qualcosa ha sovrascritto il valore predefinito del pacchetto, se è stata eseguita un'installazione pip senza defaults-debian.conf, se si utilizza un container senza journal oppure se è presente un backend = auto estraneo incollato in jail.local. Su un backend basato su file senza /var/log/auth.log, la jail sshd non riesce a trovare il log e l'intero demone si interrompe. fail2ban.log mostra:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Poiché questo errore è fatale, il servizio non viene mai avviato e fail2ban-client status riporta quindi il sintomo conseguente:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

La riga relativa al "percorso del socket" non indica che Fail2ban sia danneggiato. Indica che non è stato avviato perché una jail non riusciva a trovare il proprio log. Impostare backend = systemd in [DEFAULT], come fa già il pacchetto Ubuntu, risolve entrambi i messaggi.

La jail è attiva, ma Total failed non cambia mai. Il demone è in esecuzione e il journal viene letto, ma gli errori reali si accumulano in journalctl -u ssh mentre il contatore resta a 0. Per prima cosa escludi la causa più ovvia: stai eseguendo i test da un indirizzo elencato in ignoreip, quindi i tuoi errori sono esclusi intenzionalmente. Se non è questo il problema, utilizzi una build di OpenSSH in cui il worker per connessione è sshd-session (9.8 e versioni successive). Il relativo journal _COMM è sshd-session, non sshd, quindi il filtro fornito dal pacchetto non trova la corrispondenza. Estendi la corrispondenza nel blocco [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Riavvia il servizio, esegui intenzionalmente un tentativo di accesso non riuscito da un indirizzo non incluso in ignoreip e verifica che Total failed inizi finalmente ad aumentare.

Ti sei bloccato da solo: Connection refused. Hai omesso il tuo indirizzo da ignoreip, hai eseguito alcuni tentativi di accesso non riusciti e ora:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Il rifiuto, invece di un timeout silenzioso, è il comportamento predefinito reject dell'azione nftables, che sta funzionando anche nei tuoi confronti. Correggi il problema come descritto nel passaggio 6: rimuovi il ban da una sessione su un indirizzo diverso e non bannato oppure dalla console del provider. Anche una sessione già aperta dall'indirizzo bannato si blocca. Aggiungi quindi il tuo indirizzo a ignoreip per evitare che il problema si ripeta.

Fail2ban indica che un indirizzo è bannato, ma l'indirizzo riesce comunque a connettersi. Il contatore in status sshd aumenta, ma l'indirizzo continua a raggiungere la porta 22. Si tratta di una mancata corrispondenza tra l'azione di ban e il firewall. Su Ubuntu 24.04, quasi sempre significa che hai sovrascritto il valore funzionante banaction = nftables con banaction = iptables-multiport, copiato da una guida precedente, su un sistema senza livello iptables. fail2ban.log mostra:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Elimina questa sovrascrittura e lascia attiva l'azione nftables fornita dal pacchetto. In alternativa, se gestisci il firewall interamente tramite ufw e vuoi che i ban siano visibili anche lì, imposta banaction = ufw in [DEFAULT]. Riavvia il servizio e verifica che la regola compaia con sudo nft list ruleset | grep f2b.

Fail2ban non si avvia dopo la modifica di jail.local. Un refuso, un'intestazione estranea o un valore temporale non valido possono impedire l'avvio del servizio. Chiedi a Fail2ban di controllare la configurazione prima di avviarlo:

sudo fail2ban-client -t

Il comando indica il file e la jail con il problema, ad esempio Errors in jail 'sshd'. Skipping.... In questo modo puoi correggere l'origine dell'errore senza procedere per tentativi.

FAQ

L'installazione standard di Fail2ban su Ubuntu 24.04 blocca effettivamente gli attacchi SSH?

Sì. Il pacchetto include /etc/fail2ban/jail.d/defaults-debian.conf, che abilita il jail sshd, imposta backend = systemd per leggere il journal di systemd invece del file /var/log/auth.log mancante e imposta banaction = nftables per applicare i ban tramite il firewall effettivamente utilizzato da Ubuntu. Un semplice apt install fail2ban protegge SSH fin dal primo avvio. Verificalo con sudo fail2ban-client status sshd e cerca un valore diverso da zero per Total failed.

Perché Fail2ban non blocca nulla sul mio server?

Escludi in ordine le tre cause più comuni. Potresti eseguire i test da un indirizzo incluso in ignoreip, che per progettazione è esente. Potresti avere sovrascritto la configurazione predefinita funzionante incollando backend = auto in jail.local seguendo una guida obsoleta; su un'immagine priva di auth.log questo impedisce la lettura del journal. Oppure potresti trovarti all'interno di un container senza alcun journal di systemd da leggere. Controlla Total failed in fail2ban-client status sshd: se non aumenta mai mentre journalctl -u ssh mostra errori reali, il jail sta leggendo la posizione sbagliata.

Come rimuovo il ban dal mio indirizzo IP?

Esegui sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, che restituisce 1 in caso di successo, oppure sudo fail2ban-client unban --all per rimuovere tutti i ban. Se non puoi più accedere a SSH, usa la console web o VNC del provider per eseguire lo stesso comando. Il ban rifiuta ogni pacchetto dal tuo indirizzo verso la porta 22, quindi smette di funzionare anche una sessione già aperta. Aggiungi quindi il tuo indirizzo a ignoreip per impedire che il problema si ripresenti.

Qual è la differenza tra jail.conf e jail.local?

jail.conf contiene i valori predefiniti upstream di Fail2ban e viene sovrascritto a ogni aggiornamento del pacchetto; qualsiasi modifica viene quindi persa. Il pacchetto Debian/Ubuntu applica le proprie impostazioni tramite jail.d/defaults-debian.conf. Le tue modifiche devono essere inserite in jail.local, che viene letto per ultimo e ha precedenza su entrambi i file e che non viene modificato dagli aggiornamenti. Lascia jail.conf come riferimento in sola lettura.

Fail2ban sostituisce l'autenticazione SSH basata su chiavi?

No. Fail2ban limita la frequenza dei tentativi ripetuti provenienti da un singolo indirizzo; non può contrastare un tentativo lento e distribuito in cui ogni indirizzo resta sotto la soglia. L'autenticazione con sole chiavi (PasswordAuthentication no) rende impossibili i tentativi di indovinare la password e Fail2ban riduce quindi il rumore nei log e rimuove rapidamente gli scanner. Usa entrambe le misure e, idealmente, non esporre affatto SSH a Internet.