Installare Fail2ban su Ubuntu 24.04 contro SSH

Cosa fa effettivamente Fail2ban

Fail2ban è un daemon che legge i log. Monitora i messaggi di autenticazione SSH e, dopo alcuni tentativi falliti da un singolo indirizzo in un breve intervallo di tempo, esegue un comando del firewall per bloccare quell'indirizzo per un periodo determinato. Questo è il principio di funzionamento. La configurazione consiste in circa trenta righe in un unico file; su Ubuntu 24.04 l'installazione richiede un singolo comando apt e garantisce protezione prima ancora di aver modificato qualsiasi parametro.

È necessario distinguere chiaramente le sue funzioni. Fail2ban non esegue l'autenticazione, non cripta alcun dato e non blocca un singolo tentativo di login mirato, ma solo tentativi ripetuti dallo stesso indirizzo sorgente. È un filtro per il rumore e un limitatore di frequenza, non una serratura. Il suo compito è impedire che la scansione continua della porta 22 consumi CPU, banda e spazio nei log, e rallentare qualsiasi attaccante che debba operare un indirizzo alla volta.

Cosa non sostituisce Fail2ban

Fail2ban è il terzo livello, non il primo. Se il server accetta ancora password SSH, una botnet distribuita su migliaia di indirizzi può continuare a tentare l'accesso. Questo accade perché ogni singolo indirizzo rimane al di sotto della soglia di ban e non la attiva mai. La difesa reale consiste nell'utilizzare l'autenticazione tramite chiavi, che rende impossibile il brute-force indipendentemente dal numero di tentativi effettuati. L'uso di Fail2ban insieme all'autenticazione tramite chiavi offre due vantaggi: riduce il rumore dei tentativi di brute-force nei log ed espelle gli scanner precocemente, impedendo loro di saturare la porta. Consideralo come una difesa in profondità. Fail2ban opera dopo l'autenticazione tramite chiavi e dopo il firewall, mai prima di essi.

Prerequisites, and the Ubuntu 24.04 reality

È necessario un VPS con Ubuntu 24.04 con privilegi root o sudo e SSH funzionante — preferibilmente tramite autenticazione a chiave. Fail2ban è leggero: richiede solo pochi decine di megabyte di RAM e non richiede la configurazione di limiti specifici.

Ecco l'errore presente in ogni guida datata. Per anni il consiglio standard è stato "installa Fail2ban, poi aggiungi backend = systemd, perché Ubuntu ha smesso di scrivere /var/log/auth.log". Questo consiglio descrive un cambiamento reale — le moderne immagini server e cloud non includono rsyslog, quindi i log SSH vengono scritti solo nel journal di systemd e il file di testo non esiste più — ma su Ubuntu 24.04 il pacchetto Fail2ban gestisce già questa modifica. Il pacchetto include /etc/fail2ban/jail.d/defaults-debian.conf, e quel file, non i default originali, è ciò che il server utilizza effettivamente:

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

[sshd]
enabled = true

Leggi attentamente, perché questo risolve due dubbi prima di procedere. backend = systemd significa che la jail SSH legge il journal, quindi l'assenza di auth.log non è un problema. banaction = nftables significa che i ban sono applicati tramite nftables, che è il firewall effettivamente utilizzato da Ubuntu 24.04 al posto del legacy iptables. [sshd] enabled = true significa che la jail è attiva dal primo avvio. Conclusione: una installazione standard di apt install fail2ban su Ubuntu 24.04 blocca i brute-force SSH immediatamente. La maggior parte del lavoro consiste nel conferare la configurazione, ottimizzare la policy e assicurarsi di non rimanere bloccati fuori dal sistema.

La vecchia trappola auth.log si presenta ancora in tre situazioni, ed è importante riconoscerle: hai installato Fail2ban con pip invece di apt, quindi manca defaults-debian.conf; ti trovi all'interno di un container non privilegiato senza journal di systemd da leggere; oppure hai seguito un vecchio tutorial e hai incollato backend = auto nel tuo jail.local, sovrascrivendo il default funzionante. La sezione failure-modes mostra esattamente come si presenta ciascuna situazione.

Step 1: Install and confirm it is already banning

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 include Fail2ban 1.0.2. Il pacchetto installa python3-systemd come dipendenza obbligatoria, quindi il backend del journal è configurato correttamente. Il servizio si abilita e si avvia automaticamente:

sudo systemctl status fail2ban

È necessario active (running). Verificare quindi la jail che è già operativa:

sudo fail2ban-client status sshd

Su un VPS pubblico raggiungibile da pochi minuti, si vedranno spesso tentativi falliti e indirizzi bannati: gli scanner internet scansionano continuamente la porta 22. Questo conferma che la configurazione predefinita funziona. Da questo punto in poi si procederà alla personalizzazione, non alla creazione da zero.

Step 2: Modifica jail.local, mai jail.conf

Fail2ban conserva i valori predefiniti in /etc/fail2ban/jail.conf. Non modificare quel file. Ogni apt upgrade del pacchetto può sovrascriverlo e le modifiche andranno perse senza preavviso. Fail2ban legge i file in un ordine fisso — prima jail.conf, poi tutto il contenuto in jail.d/, infine jail.local — e l'ultimo valore applicato è quello definitivo. Il file .local è il tuo e gli aggiornamenti del pacchetto non lo modificano mai. La stessa regola si applica ai filtri, dove un file *.local sovrascrive il file filter.d/*.conf incluso nel pacchetto.

Crea quindi un piccolo jail.local che sovrascriva solo le poche impostazioni necessarie, lasciando jail.conf e il pacchetto jail.d/defaults-debian.conf invariati come riferimento.

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

sudo nano /etc/fail2ban/jail.local

Inserire il seguente contenuto, sostituendo l'indirizzo sulla 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 specifica:

• bantime, findtime, maxretry definiscono la policy. Il valore predefinito bantime è di soli dieci minuti; un'ora è un limite minimo più sicuro. Cinque tentativi falliti da un singolo indirizzo in dieci minuti attivano il ban. Gli utenti reali sbagliano la password una o due volte; cinque tentativi in dieci minuti indicano uno script.
• ignoreip è la misura di sicurezza. Inserire qui l'indirizzo pubblico da cui ci si connette per evitare che Fail2ban blocchi l'accesso al proprio server. Se la connessione domestica ha un IP dinamico, si consiglia l'approccio VPN descritto alla fine, ma non è un motivo per saltare questa riga.
• bantime.increment = true aumenta la durata di ogni ban successivo rispetto al precedente — un'ora, poi due, poi quattro — fino a bantime.maxtime. Gli indirizzi ricorrenti subiscono blocchi progressivamente più lunghi.

Trovare l'indirizzo da inserire nella whitelist dalla macchina da cui si effettua l'SSH, non dal server:

curl -s ifconfig.me

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

Step 4: Restart and verify it is reading the journal

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

Il comando -t esegue prima un test di configurazione. Un errore di sintassi in jail.local causerà un errore immediato invece di lasciare il servizio inattivo. Uno stato della jail corretto è il 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 valore che conferma che Fail2ban sta leggendo correttamente i login è Total failed. Se il valore è superiore a zero, o aumenta quando si simula un login errato da un altro host, il journal viene letto correttamente e l'operazione è conclusa. Se il valore rimane a 0 nonostante i tentativi falliti — e si è certi di non testare dall'indirizzo indicato in ignoreip — consultare le modalità di errore riportate di seguito.

Si noti che la riga Journal matches indica ancora sshd.service. Su Ubuntu l'unità SSH è in realtà ssh.service, ma il filtro incluso include anche _COMM=sshd. Inoltre, OpenSSH su 24.04 registra i fallimenti tramite un processo denominato sshd, garantendo la corrispondenza. Questo dettaglio è rilevante solo se si utilizza una versione recente di OpenSSH (9.8 o successiva, dove il worker per connessione è sshd-session); le modalità di errore coprono questo scenario.

Step 5: Monitor un ban reale o forzarne uno per il test

I ban reali avvengono automaticamente entro pochi minuti su qualsiasi VPS pubblico. Per monitorarne uno, esegui il tail del log:

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

Un ban appare in questo modo:

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 testare il sistema end-to-end senza attendere, banna manualmente un indirizzo di documentazione — non usare mai il proprio:

sudo fail2ban-client set sshd banip 10.0.0.66

Il comando stampa 1 e l'indirizzo appare sotto Banned IP list in fail2ban-client status sshd. Ora conferma che il blocco è attivo nel firewall. Su Ubuntu 24.04 il componente è nftables, non iptables:

sudo nft list table inet f2b-table

Vedrai un set denominato addr-set-sshd contenente 10.0.0.66 e una chain f2b-chain che rifiuta ogni sorgente presente in quel set. Se fail2ban-client indica che un indirizzo è bannato ma non appare nulla in nft list, l'azione di ban non corrisponde al firewall — consulta la nota su nftables/iptables nella sezione dei possibili errori.

Step 6: Unban yourself, and recover if you are locked out

If you banned an address you should not have — your own — remove it:

sudo fail2ban-client set sshd unbanip 10.0.0.66

It returns 1 on success. To clear every ban across every jail:

sudo fail2ban-client unban --all

Do not count on an already-open SSH session to save you: the nftables ban rejects every packet from the banned address to port 22 — established connections included — so an existing session freezes the moment the ban lands. If you ban yourself and have no ignoreip entry, you are locked out until the ban expires — recover through your provider's web console (VNC or serial), which does not go through SSH, and either wait out bantime or run the unban command there.

Step 7: Rendere i ban persistenti e scalabili

Fail2ban memorizza i ban attivi in un database SQLite in /var/lib/fail2ban/fail2ban.sqlite3. I ban sopravvivono al riavvio del servizio o del sistema; non vengono persi. Le righe bantime.increment aggiunte trasformano ogni trasgressore ricorrente in un problema crescente: il tempo di ban raddoppia progressivamente da una ora fino a una settimana.

Per applicare una politica "tre strike" a livello di sistema, Fail2ban include una jail recidive che monitora la propria /var/log/fail2ban.log. Questa jail applica ban prolungati a qualsiasi indirizzo bannato ripetutamente in tutte le jail. Poiché [DEFAULT] utilizza il backend systemd, è necessario vincolare questa jail al file di log originale:

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

L'uso di backend = auto con il parametro logpath esplicito costringe recidive a leggere il file fail2ban.log. È in questo file che appaiono le righe Ban da contare. L'impostazione predefinita di systemd configurata globalmente indirizzerebbe la jail verso il journal, dove tali righe non sono presenti.

Step 8: Accoppiarlo con SSH basato solo su chiavi, o meglio ancora una VPN

Fail2ban è efficace solo se utilizzato insieme all'autenticazione tramite chiavi. In un file di configurazione sotto /etc/ssh/sshd_config.d/ — ad esempio /etc/ssh/sshd_config.d/00-hardening.conf — impostare:

PasswordAuthentication no
KbdInteractiveAuthentication no

Successivamente sudo systemctl restart ssh. Disabilitando le password, gli attacchi brute force non possono avere successo. In questo scenario, Fail2ban serve a ridurre il rumore nei log ed eliminare gli scanner precocemente. Una soluzione ancora più sicura consiste nel rimuovere SSH da internet: configurare SSH tramite una VPN WireGuard self-hosted e bloccare la porta 22 sul firewall, in modo che risponda solo tramite il tunnel. Nessuno può tentare un brute force su una porta irraggiungibile; Fail2ban diventa così una misura di sicurezza secondaria invece che una linea di difesa primaria.

Fail2ban non è limitato a SSH. Qualsiasi servizio che registri tentativi di login falliti può avere una jail — un server mail, un sito nginx o un password manager Vaultwarden self-hosted il cui login web non si desidera esporre a attacchi di credential stuffing. Una volta che un'app web è protetta da un sito nginx con certificato Let's Encrypt, punta un filtro Fail2ban al suo log di accesso, nello stesso modo in cui la jail SSH punta al journal.

Modalità di errore, con le stringhe esatte che visualizzerai

"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 default del pacchetto — un'installazione pip senza defaults-debian.conf, un container senza journal, o un backend = auto errato incollato in jail.local. Su un backend basato su file senza /var/log/auth.log, la jail sshd non trova il log e l'intero daemon 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 si avvia mai, e fail2ban-client status riporta quindi il sintomo a valle:

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

Quella riga "socket path" non significa che Fail2ban sia rotto — significa che non è mai partito perché una jail non riusciva a trovare il proprio log. Impostare backend = systemd in [DEFAULT], operazione che il pacchetto Ubuntu esegue già per te, risolve entrambi i messaggi contemporaneamente.

La jail è attiva ma Total failed non si muove mai. Il daemon è in esecuzione e il journal viene letto, eppure i fallimenti reali si accumulano in journalctl -u ssh mentre il contatore rimane a 0. Per prima cosa escludi l'ovvio: stai effettuando i test da un indirizzo elencato in ignoreip, quindi i tuoi fallimenti sono esclusi per design. Se non è questo il problema, stai usando una build di OpenSSH in cui il worker per connessione è sshd-session (9.8 e successivi), il cui journal _COMM è sshd-session, non sshd, quindi il match incluso nel pacchetto non lo rileva. Amplia il match nel blocco [sshd]:

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

Riavvia, simula un login errato intenzionalmente da un indirizzo non presente in ignoreip e conferma che Total failed finalmente aumenti.

Ti sei bannato da solo: Connection refused. Hai escluso il tuo indirizzo da ignoreip, hai testato alcuni login errati e ora:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Il rifiuto, invece di un timeout silenzioso, è il verdetto predefinito reject dell'azione nftables che svolge il suo compito — su di te. Risolvi come descritto nello Step 6: esegui l'unban da una sessione su un indirizzo diverso e non bannato, o dalla console del provider — una sessione già aperta dall'indirizzo bannato si bloccherà anch'essa. Poi aggiungi il tuo indirizzo a ignoreip affinché non accada più.

Fail2ban indica che un indirizzo è bannato, ma riesce ancora a connettersi. Il contatore in status sshd aumenta, eppure l'indirizzo raggiunge ancora la porta 22. Questo è un disallineamento tra ban-action e firewall; su Ubuntu 24.04 significa quasi sempre che hai sovrascritto il funzionante banaction = nftables con banaction = iptables-multiport copiato da una guida datata, su un sistema senza lo strato iptables. fail2ban.log mostra:

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

Elimina quella sovrascrittura e mantieni l'azione nftables inclusa nel pacchetto, oppure, se gestisci il firewall interamente tramite ufw e vuoi che i ban appaiano lì, imposta banaction = ufw in [DEFAULT]. Riavvia e conferma che la regola appaia con sudo nft list ruleset | grep f2b.

Fail2ban non si avvia dopo aver modificato jail.local. Un errore di battitura — un'intestazione errata o un valore temporale non valido — impedisce l'avvio del servizio. Chiedi a Fail2ban di controllare la configurazione prima dell'esecuzione:

sudo fail2ban-client -t

Indica il file e la jail con il problema, ad esempio Errors in jail 'sshd'. Skipping..., così puoi correggere la sorgente invece di tirare a indovinare.

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 la jail sshd, imposta backend = systemd per leggere il journal di systemd invece del mancante /var/log/auth.log, e imposta banaction = nftables affinché i ban siano applicati tramite il firewall nativo di Ubuntu. Una configurazione apt install fail2ban protegge SSH fin dal primo avvio. Verificalo con sudo fail2ban-client status sshd controllando che Total failed sia diverso da zero.

Perché Fail2ban non blocca nulla sul mio server?

Verifica queste tre cause comuni in ordine. Potresti eseguire i test da un indirizzo in ignoreip, che è escluso per design. Potresti aver sovrascritto il default funzionante incollando backend = auto in jail.local da una vecchia guida, il che impedisce la lettura del journal su un'immagine senza auth.log. Oppure potresti essere all'interno di un container senza un journal di systemd da leggere. Controlla Total failed in fail2ban-client status sshd: se il valore non aumenta mentre journalctl -u ssh mostra fallimenti reali, la jail sta leggendo il file errato.

Come posso sbloccare il 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 hai accesso via SSH, usa la console web o VNC del tuo provider per eseguire lo stesso comando — il ban rifiuta ogni pacchetto dal tuo indirizzo verso la porta 22, quindi anche una sessione già aperta smetterà di funzionare. Successivamente, aggiungi il tuo indirizzo a ignoreip per evitare che il problema si ripresenti.

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

jail.conf contiene i default ufficiali di Fail2ban e viene sovrascritto ad ogni aggiornamento del pacchetto; ogni modifica effettuata lì andrà 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 la priorità su entrambi, e che non viene mai toccato dagli aggiornamenti. Lascia jail.conf come riferimento in sola lettura.

Fail2ban sostituisce l'autenticazione SSH tramite chiavi?

No. Fail2ban limita la frequenza dei tentativi falliti da un singolo indirizzo; non protegge da attacchi distribuiti lenti dove ogni indirizzo rimane sotto la soglia impostata. L'autenticazione tramite chiavi (PasswordAuthentication no) rende impossibile il brute-force delle password; Fail2ban serve poi a ridurre il rumore nei log ed eliminare gli scanner precocemente. Utilizza entrambi e, idealmente, mantieni SSH non esposto su internet.