Software concepito per permettere il blocco di host che tentano un attacco "brute force" sia SSH.

Però, il sofware, con le ultime versioni, si è occupato anche di altri servizi, oltre SSH.

Il funzionamento di Fail2ban è molto semplice.

Legge i file di log indicati e cerca in essi accessi falliti.
Perciò, è importante configurare bene le applicazioni, affinchè segnalino gli errori di "login" nei rispettivi file di log.

Ad ogni riscontro, Fail2ban aumenta di 1 il conto (fail) e stampa data ed ora (timestamp), relativo al ip che ha effettuato l'accesso fallito, nel proprio file di log, fail2ban.log.

Quando raggiunge una soglia di accessi falliti preimpostata, da raggiungere in una finestra temporale anch'essa preimpostata, blocca l'ip dell'host (ban) alla porta incriminata, e soltanto a quella (se non diversamente preimpostato), con una regola posta in iptables.

Il blocco è temporaneo; trascorso il periodo di inibizione (ban), l'ip viene rilasciato (unban), cioè è cancellata la regola del firewall che bloccava la connessione .

Premessa: con Debian 12 è cambiato il sistema di gestione dei file di log.
I file di log, adesso, sono centralizzati e gestiti da journald e si trovano in file binari, nella cartella /var/log/journal.
Noi, per questioni di semplicità, siamo ritornati al sistema gestito da syslog, installando Rsyslog, come descritto nell'apposita pagina.
Con la scelta di syslog, Fail2ban è facilmente gestibile ed incrementabile.
Magari, quando avremo appreso meglio il sistema di log di Journald e la sua gestione, con il suo backend systemd, potremo iniziare ad usare questo sistema di log con Fail2ban, ma, attualmente, ribadiamo di preferire la soluzione offerta con l'installazione di Rsyslog e l'abbandono del sistema di logging di journald.

Fail2ban è ritenuto, da noi, fondamentale, anzi, fonte centrale nella sicurezza del sistema, per cercare altrove le sue attuali funzionalità.


Come consueto, aggiorniamo inanzitutto il sistema: Per poi passare all'installazione vera e propria : Abilitiamo Fai2ban al boot di Debian :

I files di gestione di Fail2ban sono posti nella cartella /etc/fail2ban/ ; elenchiamoli :

fail2ban.conf è il file di configurazione di Fail2ban ;

jail.conf è il file dove sono configurate tutte le predisposizioni riguardanti le varie applicazioni su cui fare il controllo degli accessi.
È il file che a noi interessa di più; quello in cui andremo ad abilitare le varie procedure di controllo.

action.d/ , è la directory contenente le varie azioni da intraprendere al riscontro degli accessi falliti; sono queste azioni a scrivere nuove regole nelle iptables.

filter.d/ , è la cartella contenente tutti i filtri utilizzati per vagliare i vari file di log, relativi alle singole applicazioni.

jail.d/ , è la cartella in cui inserire le eventuali "jail", cioè sezioni dove si indica dove e come vagliare le varie applicazioni.
Attualmente, contiene un solo file :
L'unica app abilitata è SSH {enabled=true).
Le altre sono tutte da abilitare e, come detto precedentemente, sono previste in jail.conf

fail2ban.d/ , è una cartella dove porre eventuali file di configurazione alternativi a fail2ban.conf. Adesso, è vuota.

Rimangono i vari file path-xxx.conf predisposti dai programmatori di Fail2ban per adeguarsi alle varie distribuzioni. Leggiamo quello rivolto a Debian :
Come possiamo notare, Fail2ban è predisposto per syslog.
Volendo usare journald, come sistema di gestione dei log, avremo dovuto modificare la configurazione di Fail2ban, con risultati incerti.

Apriamo in lettura anche il file paths-common.conf, richiamato da paths-debian:
In questo file, scorrendo, troviamo indicati i vari file di log.


Abbiamo visto i file principali di Fail2ban.


Ma qual'è la procedura di azione di Fail2ban?

Il file /etc/fail2ban/jail.d/defaults-debian.conf ha abilitato il demone ssh (sshd).

Se leggiamo il file /etc/fail2ban/jail.conf All'interno di esso , leggiamo anche :


Richiamo ai files appena consultati ; proseguiamo :


Ci informa che, se preso ad autenticarsi, l'ip dell'host "colpevole" sarà "bannato", cioè gli sarà impedito l'acceso alla porta del servizio, per 10 minuti (bantime).
L'host sarà "bannato" se in 10 minuti (findtime=10m) avrà fallito 5 accessi (maxretry=5).

Proseguiamo ancora :


Ulteriore conferma che Fail2ban è predisposto alla lettura dei file di log prodotti con syslog, altrimenti, usando journald, dovremo indicare systemd come backend.

Andiamo avanti nella lettura di jail.conf


La prima azione è mandare una mail con mittente root (root@<fq-hostname>) e destinatario sempre root (destemail = root@localhost), messaggio inviato con sendmail (mta = sendmail); valori che, al suo tempo, modificheremo.
Oltre ad interessare il protocollo Tcp, comunica anche qual'è la catena di iptables interessata (chain = <known/chain> ) .


In questa parte del file, esso ci indica qual'è azione da eseguire (banaction = iptables-multiport), cioè un rimando ad un file nella cartella delle azioni, chiamato iptables-multiport.conf .

Finalmente, arriviamo alla sezione delle Jails, la sezione dove abilitare le singole app, e vediamo quella relativa a ssh, abilitata dal file defaults-debian.conf , affrontato prima.
La porta in questione è quella ssh, cioè la 22


Per logpath, cioè dove trovare il log per ssh, indica una variabile ( %(sshd_log)s ).
A seguire, ci sono tutte le "jails" per ogni singola applicazione predisposta.

Apriamo il file del filtro, relativo al servizio SSH, posto nella cartella dei filtri : Olter al richiamo di un altro file (common.conf), leggiamo al suo interno i vari algoritmi usati per filtrare il file di log.
Se abbiamo compreso la pagina relativa alle Espressioni Regolari, potremo anche capire cosa e come viene cercato all'interno del file di log.



Rileggiamo il file che si occupa di rintracciare i file di log : E cerchiamo al suo interno: sshd_log ; questo chiama a sua volta syslog_authpriv, il quale a sua volta richiama /var/log/auth.log .


Quello è il file di log esaminato per scoprire eventuali abusi, quello dove SSH registra le sue connessioni.

Adesso possiamo andare a vedere l'azione richiamata prima dal file jail.conf (banaction = iptables-multiport).

Leggiamone il relativo file nella cartella che contiene tutte le azioni :
Ci inforrma che è diventato obsoleto e di cercare nel file dell'azione iptables.conf e come tipo: multiport. Apriamo quest'altro file :
All'interno del file sono definite tutte le azioni da intraprendere per le violazioni effettuate.


Troviamo la prima azione: ban dell'ip in iptables;


Poi, leggiamo l'azione di unban, cioè di rilascio della jail, trascorso il periodo di ban ;


Qui, indica qual'è la porta interessata ;


Il blocktype indicato nell'azione di ban, in questo caso, è il rigetto della richiesta di connessione e l'avviso che la porta 22 non è raggiungibile.

Questa è la procedura utilizzata da fail2ban.
Abilitando qualsiasi delle opzione già predisposte nel file jail.conf, la procedura sarà sempre questa, con ovviamente file diversi, relativi alle opzioni diverse attivate, le quali avranno il proprio file diverso d'azione e il proprio file diverso riguardante il filtro.

Come accennato precedentemente, per modificare alcuni aspetti di fail2ban è conveniente creare un nuovo file, jail.local, invece di modificare jail.conf e, nel nuovo file, definiamo soltanto i valori da modificare rispetto a jail.conf.
Questo perchè, in caso di aggiornamento del programma, jail.conf viene riscritto, perdendo tutte le impostazioni poste in esso.
Questa procedura, permette al processo Fail2ban di avere in memoria prima tutti i file .conf ed in seguito a memorizzare e sovrascrivere le variazioni definite nei file .local .

Generiamo un nuovo file : ed inseriamo al suo interno una sezione (va messa tra parentesi quadre) riguardante le varianti delle impostazioni di Default :
Partiamo dal primo rigo:

Salvaguardiamo il collegamento alla macchina da eventuali nostri errori, inserendo i nostri ip interessati a non essere bannati (ignoreip).
Abbiamo prima inserito l'indirizzo di loopback ed in seguito, distanziato da uno spazio, gli indirizzi interni da cui ci colleghiamo al server.
Abbiamo usato la netmask /16 (255.255.0.0 = 192.168.x.x) , invece della /24 (255.255.255.0 = 192.168.1.x) perchè, collegandoci a volte anche da remoto ed usando una VPN, abbiamo indirizzati questi a 192.168.2.x .

Abbiamo alzato il tempo di inibizione (bantime) alla connessione dai 10 minuti di default a 2 giorni, al fine di scoraggiare eventuali malfattori, fine d'altronde di tutte le modifiche ai valori di default che sovrascriveremo.

Innalziamo da 10 minuti a 1 giorno findtime, finestra temporale entro la quale conteggiare quante volte l'host "sbaglia" nel connettersi.

Il maxretry, cioè il numero di accessi falliti, viene portato da 5 a 2.
Se avete dubbi sulla vostro memoria e ritenete di poter sbagliare più volte i dati di accesso, alzate pure questa soglia.
Notare: queste vogliono solo essere soglie da noi suggerite, ma ognuno deve adeguarle all'ambiente in cui propone i servizi offerti al pubblico dal server.

Per banaction, intendiamo iscrizione nella catena (Chain) delle immissioni (Input) di regole al fine di rigettare (Reject) nuove richieste di connessioni da parte di quel ip (Host), scegliamo UFW, avendolo installato.
Ma, altrimenti, può essere lasciato il valore previsto in jail.conf, iptables-multiport.

Abilitiamo l'incremento del periodo di inibizione (bantime.increment) nel caso di recidiva, cioè di un IP già precedentemente bannato, ripescato tra gli errori di accesso registrati nei files di log.

Indichiamo in 2 settimane il tempo massimo di inibizione (bantime.maxtime).
Avevamo fatto un ipotesi, nell'affrontare le impostazione del firewall Ufw, ove l'host veniva bannato; in quel caso, non era previsto un tempo di "penitenza", ma, se inserito nella lista dei ban, questo ip veniva definitivamente impossibilitato a connettersi alla porta in questione.
Ma, spessissimo, chi tenta chiavi di accesso "a caso" non usa un indirizzo ip fisso, statico, dove egli sarebbe facilmente rintracciabile, ma usa indirizzi momentanei, dhcp, assegnati dal Provider "al momento".
Perciò, l'ignaro nuovo utente, che eredita quel ip bannato assegnatogli dal Provider, subirebbe tutte le conseguenze non da lui causate.
Ed è qui che entra in gioco il bantime, liberando l'indirizzo, trascorso un determinato lasso di tempo.

Indichiamo in 2 il fattore di moltiplicazione (bantime.factor) del periodo di ban (1, 2, 4, 8, 16, etc), quando recidivi.

Come azione (action) al raggiungimento dell'incremento degli errori alla soglia, indichiamo, con %(action_mwl)s, di mandare una mail, con indicati al suo interno il file di log e la porta interessata dal ban, l'ip bannato ed il "whois".

Destemail indica il destinatario della mail.

Sender indica il mittente.

Se abbiamo installato e configurato Postfix, possiamo indicare come Mail Trasfer Agent mail (mta), altrimenti, il valore di default è sendmail.

Ad ogni host bannato, dovrebbe arrivarci una mail di questo tenore:




Quando andremo ad abilitare le sezioni di specifici servizi, potremo anche sovrascrivere, a sua volta, queste direttive da noi inserite nella sezione "Default" del file jail.local .

Leggiamo le sezioni relative alle applicazioni, in jail.conf e copiamo quelle a noi utili, per il controllo accessi, in jail.local .

Ovviamente, ognuno copia e abilita le sezioni riguardanti programmi installati sul proprio server.
Noi prenderemo in considerazione le applicazioni installate durante il nostro persorso su questo sito.

Anche se già attiva, alleghiamo la sezione sshd in jail.local,


e la modifichiamo come segue :


Abiamo abilitato sshd direttamente qui; abbiamo indicato la porta interessata dal servizio e su cui fare ricadere l'eventuale inibizione; abbiamo indicato il file contenente l'algoritmo per filtrare il file di log ed abbiamo indicato il file di log da processare.
Se siete interessati agli algoritmi utilizzati nel filtro, aprite /etc/fail2ban/filter.d/sshd.conf

Copiamo e modifichiamo allo stesso modo
apache-auth : riguarda la protezione contro attacchi di forza bruta ai meccanismi di autenticazione previsti nelle pagine web;
apache-badbots : per proteggere Apache da bots maligni, al fine di evitare potenziali attacchi, spam o traffico non voluto;
e apache-noscript : contro attacchi ad Apache per accedere a files sensibili o per eseguire script;


In questi casi, abbiamo lasciati i logpath, perchè idonei tramite file paths-common.conf.
Ed abbiamo lasciato anche il maxretry, già severo nella predisposizione.
Ovviamente, abbiamo abilitato tutti e tre i servizi.

Copiamo e modifichiamo anche
apache-nohome : per scovare attaccanti che provano ad entrare in Apache indicando un ip , invece della home del sito;
apache-botsearch : contro le richieste di pagine web inesistenti, spesso ricercate da ro-bots, al fine di trovare un varco, oppure una nota vulnerabilità di dette pagine;
e apache-modsecurity : attacchi rivolti ai moduli di sicurezza di Apache


Anche stavolta abbiamo abilitato i tre servizi, ma abbiamo modificato il maxretry ad 1, perchè , spesso, questi servizi vengono "interrogati" da bots, cioè app programmate per tentare di trovare varchi.

Copiamo e modifichiamo anche le sezioni :
postfix : per trovare rifiuti di Postfix ad utenti che tentano di accedervi ;
dovecot : per scovare le fallite autenticazioni a Dovecot ed anche a pop3 ed imap;
e postfix-sasl : per bloccare le autenticazioni a SASL fallite;


Li abbiamo abilitati ed abbiamo modificato solo lo stretto necessario.

Copiamo e modifichiamo anche :
pam-generic : riguarda le connessioni da terminale, con errori di login;


Abilitato anche questo servizio.

Chiudiamo con i soliti tasti Ctrl + X, seguiti da Y , ed Invio.

Riavviamo Fail2ban per controllare che tutto vada a buon fine e poi vediamone lo stato


Va da se, che , se installiamo, in un secondo momento, una applicazione compresa nelle sezioni di jail.conf, possiamo abilitarla copiando, incollando e scrivendo le dovute modifiche nella relativa [sezione] di jail.local .


Inoltre, possiamo anche creare nuove sezioni, con eventuali filtri nuovi, se quelli presenti non raggiungono l'obiettivo da noi voluto e possiamo anche scrivere nuove azioni.

Ne abbiamo create alcune, adatte alle nostre esigenze: essere disturbati il meno possibile, tentare di eliminare tutte le richieste casuali di connessioni a file inesistenti.

La prima l'abbiamo chiamata apache-php-error, perchè creata per eliminare le infinite richieste di connessione a file .php inesistenti.
Abbiamo il sospetto che qualche CMS abbia qualche problemino, visto che molte ricerche sono effettuate su file generalmente appartenenti a questa categoria di prodotti.
Ogni giorno, riceviamo varie richieste di collegamento a file xmlrpc.php, inf.php, test.php, info1.php, env.php e mille altri, per nominarne solo alcuni, files php peraltro mai esistiti sulle nostre pagine, essendo queste prodotte esclusivamente ed integralmente da noi e nominate sempre da noi. Queste richieste sono puntualmente registrate sul file di log apache2/error.log

Apriamo nuovamente il file jail.local : Ed alla fine del file, aggiungiamo la nuova sezione:
Non trovando un filtro soddisfacente, ne abbiamo creato uno e lo richiamiamo qui.
Chiudiamo il file e salviamolo .

Adesso, generiamo il filtro apache-php-error.local : Diamo come titolo "Definition", come tutti gli altri filtri, e poniamo in esso un failregex ed un ignoregex.
Nel failregex (espressione regolare nel caso di fallimento}, inseriamo, dopo attenta lettura dei file di log, un semplice algoritmo da cui ricavare il numero IP del presunto molestatore .
In ignoreregex vanno inserite eventuali eccezioni per ignorare le espressioni regolari risultate positive.
Semplice, ma efficace.
Anche questo file va chiuso e salvato.

Fail2ban ha una funzionalità per provare il filtro appena impostato, fail2ban-regex.
Chiediamo a questa utilità di provare il filtro creato con l'analisi del file di log prescelto.
Fail2ban-regex ha trovato 7 occorrenze (righe del file) positive e 25 negative.
Ha anche confermato di aver trovato il timestamp, cioè l'ora e la data indicati per poter applicare il conteggio temporale.

Creiamo un'altra "gabbia", stavolta per un tipo di attacco contro postfix, postfix-lost-conn.
Spesso, analizzando i file di log, riceviamo richieste di connessione a Postfix da un/alcuni utenti sconosciuti. Il sistema di autenticazione sicuramente non lascia passare questi, ma queste continue richieste di accesso possono consumare risorse ed anche impedire a legittimi utenti di connettersi.
Perciò abbiamo deciso di tentare di porvi fine : Dopo l'ultima gabbia aggiunta, apache-php-error, aggiungiamo quest'altra :
Abbiamo aggiunto anche le porte web, se eventualmente abbiamo una pagina web da cui consultare il nostro mail server.
Come sempre, salviamo il file prima di chiuderlo.

Creiamo anche il filtro postfix-lost-conn.local : ed inseriamo al suo interno una sezione (va messa tra parentesi quadre) riguardante le varianti delle impostazioni di Default :
Abbiamo semplicemente estratto l'host dal rigo del file di log, dove appare la scritta lost connection after Auth .
Solita sequenza di tasti per salvare.

Anche in questo caso, proviamo il filtro :
Stavolta, la prova è stata molto fruttuosa: 113 riscontri su 88947 righe di log .

Creiamo l'ultima gabbia ("jail"), che chiameremo postfix-unknown, visto che nei file di log spuntano autenticazione da parte di sconosciuti, anche queste certamente respinte da Postfix, con le sue restrizioni e loggate, ma che comunque occupano risorse inutilmente , se non al fine di disturbare : E dopo gli ultimi due aggiunti, continuiamo con :
Salviamo e chiudiamo .

Generiamo il filtro in questione, postfix-unknown : e definiamo in esso failregex, molto semplicemente associando l'host alla stringa "connect from unknown" :
Ctrl + X, Y , Invio .

Con failregex, testiamo il filtro :
In questo test, i riscontri sono 412 su 88947 linee.

Possiamo finalmente riavviare Fail2ban, per controllarne poi il giusto funzionamento, con la verifica del suo stato :

Per avere un riscontro delle "gabbie attivate" possiamo consultare il client di Fail2ban :

Per conoscere la situazione di una singola gabbia, digitiamo :

Per inibire l'accesso manualmente ad una specifica porta ad un ip, digitiamo :
Il numero 1 è un valore boleano che indica Vero (TRUE), operazione riuscita.
Il suo opposto sarebbe stato zero oppure NULL.

All'inverso, per togliere un ban manualmente ad un ip, magari perchè inserito per errore, oppure perchè abbiamo avuto conferma trattasi di ip legittimo :

Possiamo conoscere quali sono gli IP bannati dal nostro sistema, utilizzando sempre il client di Fail2ban:
Sembra incredibile, ma appena attivato, già ci sono occorrenze .
Teniamo a precisare che questi IP non sono obbligatoriamente attaccanti, ma anche semplici bots che scandagliano la rete in cerca di files da indicizzare.

Se ci è di aiuto, potremmo farci inviare un report giornaliero, un riassunto delle attività inibitorie svolte dal server Fail2ban.

Per mandarci la mail, useremo mail, un app di mailutils.
Installiamo mailutils :

Creiamo un file bash :
ed inseriamo tutte le indicazioni a noi necessarie :
Salviamo e chiudiamo

Rendiamo il file eseguibile con :
Inoltre, visto che usiamo sudo fail2ban-client per conoscere gli ip bannati, dobbiamo mettere una eccezione, nel file sudoers, con visudo, al nostro utente, al fine di non chiedere la password utente quando appunto deve eseguire il file eseguibile : e scriviamo quasi alla fine del file :
Salviamo il tutto.

Non ci rimane che configurare cron per eseguire giornalmente il file bash eseguibile :
Inseriamo al suo interno un rigo nuovo con la destinazione della mail e le istruzioni per eseguire il file eseguibile ad un determinato orario :
Salviamo con Ctrl + X, Y, Invio ed il crontab diventa immediatamente operativo.


Tutte le mattine alle 02.00 riceveremo un mail col report degli ip bannati sul nostro sistema, di questo tenore :




Alcuni comandi, non di Fail2ban, ma che direttamente lo riguardano:
Ci permette di vedere le ultime -n 10 pagine del file di log .


Estrae tutte le occorrenze, ad esempio di "unknown", ricercate in un file di log, in questo caso mail.log, permettendoci l'analisi di eventuali minacce e la comprensione del log per attuare un algoritmo di estrazione utile alla difesa con Fail2ban .

Abbiamo concluso la configurazione di Fail2ban.
In caso di bisogno, adesso sappiamo come metterci le mani.

Questa è stata una lunga esposizione su Fail2ban, ma ci ha permesso di apprezzarne tutta la modularità nel contrastare non soltanto minacce di compromissione rivolte al nostro Server, ma anche comprendere la sua flessibilità, il suo essere una applicazione personabilizzabile e di relativa facilità di configurazione, rendendo Fail2ban uno degli strumenti maggiormente utili a rafforzare la sicurezza del Server.