Creiamo un nuovo file chiamato /etc/fail2ban/filter.d/wordpress.conf in cui scriviamo:

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*(/wp-login.php|/xmlrpc.php).*" 200
ignoreregex =

Ora inseriamo nel file /etc/fail2ban/jail.d/defaults-debian.conf queste righe:

[wordpress]
enabled = true
port = http,https
logpath = %(apache_access_log)s
filter = wordpress
maxretry = 5
findtime = 1800
bantime = 3600

(in questo esempio controllo se ci sono almeno 5 tentativi in 1800 secondi (30 minuti), blocco quindi per 3600 secondi (1 ora) riavviamo fail2ban:

systemctl restart fail2ban.service

e dopo qualche minuto vediamo come la regola sta funzionando:

fail2ban-client status wordpress

enjoy!

Attivando la jail ssh su fail2ban (la prima che troviamo anche preattivata), fail2ban si rifiuta di partire perché non trova il file con i log degli accessi ssh. Se proviamo ad avviare fail2ban con:

systemctl start fail2ban

ci accorgiamo subito che non è partito, il file dei log non viene popolato. Se andiamo a verificare, proprio tra i log di jounald la situazione con:

journalctl -ufail2ban

possiamo vedere qualcosa tipo:

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

La stessa cosa si può vedere con:

systemctl status fail2ban

Ecco, il motivo per cui non si avvia fail2ban ora è chiaro… Apriamo il file /etc/fail2ban/jail.d/defaults-debian.conf ed inseriamo le seguenti direttive:

[DEFAULT]
backend = systemd

ora riavviamo fail2ban e partirà normalmente. Possiamo verificare che il servizio è attivo con

systemctl status fail2ban

oppure con:

fail2ban-client status
fail2ban-client status sshd

enjoy!

In questo caso possiamo limitare i danni (nel senso di bloccare le richieste per taluni IP), creando una regola nel file .htaccess posizionato nella nostra webroot che vada a bloccare le richieste se l’IP viene identificato da qualche regola di fail2ban.

Ipotizziamo che la webroot sia /var/www/web1/htdocs e che vogliamo usare la cartella blockedip per contenere i riferimenti per gli IP bloccati.

Scriviamo all’inizio del nel nostro file .htaccess le seguenti direttive (le prime due righe non servono ma le lascio perché a qualcuno possono essere utili per farci altro):

RewriteCond %{DOCUMENT_ROOT}/blockedip/%{REMOTE_ADDR} -f
RewriteRule . - F]
RewriteCond %{DOCUMENT_ROOT}/blockedip/%{HTTP:X-FORWARDED-FOR} -f
RewriteRule . - F]

Dopo aver fatto la classica configurazione di fail2ban in coppia con nftables, bisognerà aprire il file /etc/fail2ban/action.d/nftables.conf e scrivere, sotto la direttiva actionban, la riga:

touch /var/www/web1/htdocs/blockedip/<ip>

e sotto la direttiva actionunban, la riga:

rm /var/www/web1/htdocs/blockedip/<ip>

Bene, ora riavviamo fail2ban e non appena ci saranno IP bloccati, li troverete riepilogati nella cartella /var/www/web1/htdocs e la regola di rewrite nel file .htaccess provvederà a bloccare le richieste per tali IP.

enjoy!

Su Debian 11 Bullseye consiglio di utilizzare nftables, ormai direi il firewall standard per le ultime Debian.

Installiamo intanto nftables e fail2ban:

apt install fail2ban nftables

Copiamo il file con le regole di default, da personalizzare secondo le nostre esigenze:

cp /usr/share/doc/nftables/examples/workstation.nft /etc/nftables.conf

Attiviamo nftables per l’avvio automatico:

systemctl enable nftables.service

in /etc/fail2ban/jail.conf verificare che le direttive banaction e banaction_allports siano:

banaction = nftables-multiport
banaction_allports = nftables-allports

Abilitiamo poi i filtri per i vari servizi in /etc/fail2ban/jail.d/defaults-debian.conf e riavviamo:

service fail2ban restart
service nftables restart

Per verificare che la nuova chain sia stata creata:

nft list ruleset

enjoy!

Vedere lo stato generale di fail2ban:

fail2ban-client status

Aggiungere il blocco per un IP alla chain sshd:

fail2ban-client set sshd banip 30.30.30.3

Verificare lo stato della chain sshd:

fail2ban-client status sshd

Eliminare un IP alla chain sshd:

fail2ban-client set sshd unbanip 30.30.30.3

Aggiungere un IP in whitelist:

fail2ban-client set sshd addignoreip 30.30.30.3

Rimuovere un IP dalla whitelist:

fail2ban-client set sshd delignoreip 30.30.30.3

Vedere gli IP in whitelist:

fail2ban-client get sshd ignoreip

Varie:

Per testare il funzionamento di un filtro, ad esempio il filtro fail2ban creato prima, basta digitare:

fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Se si vuole testare sia la regexp che l’ignore filter, va ripetuto due volte il nome del file con il filtro, es:

fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf /etc/fail2ban/filter.d/fail2ban.conf

Per vedere i dettagli delle righe rilevate, bisogna aggiungere il parametro -v, es:

fail2ban-regex -v /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Per vedere invece l’elenco delle righe trovate si usa –print-all-matched:

fail2ban-regex --print-all-matched /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Per verificare i filtri attivi:

fail2ban-client status

Per controllare gli IP bloccati da un determintato filtro:

fail2ban-client status fail2ban

Per vedere tutti gli IP bloccati da tutti i filtri non esiste un comando specifico, si può fare in questo modo:

fail2ban-client status | grep "Jail list:" | sed "s/ //g" | awk '{split($2,a,",");for(i in a) system("fail2ban-client status " a[i])}' | grep "Status\|IP list"

Oppure si può controllare il contenuto del database sqlite in /var/lib/fail2ban/fail2ban.sqlite3 ad esempio:

sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "select distinct ip,jail from bips"

oppure, per avere tutte le informazioni sul blocco):

sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "select * from bips"

(dato che lo schema del DB è stato modificato tra le varie versioni, la tabella potrebbe chiamarsi in altro modo, si può verificare con:

sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 '.schema'

enjoy!

Richiamando infatti:
nft list ruleset
non vengono visualizzate le regole relative alle chain create.

Bisogna modificare il file /etc/fail2ban/jail.conf ed in particolare sostituire:
chain = INPUT
con
chain = input

Per verificare che i blocchi di fail2ban siano stati attivati, eseguire:
nft list ruleset

enjoy!

Ad esempio si potrebbe voler configurare fail2ban per bloccare attacchi DoS e quindi bisogna conoscere quante sono le connesioni che generalmente vengono fatte da ogni IP. Per fare questo si deve monitorare il file di log per un po’ di tempo al fine di evitare falsi positivi.

Vi segnalo una semplice concatenazione di comandi che può tornare utile:

tail -f /var/log/apache2/access.log | awk {'print $1; fflush();'} | logtop

enjoy!

Dopo aver riavviato lo script, ho controllato i log (/var/log/fail2ban.log) per vedere che tutto fosse corretto e mi sono accorto della riga:

fail2ban.comm: WARNING Invalid command: ['set', 'ssh', 'addlogpath', '/var/log/auth.log']

Per capire meglio cosa genera l’errore, ho eseguito il comando fail2ban-client con i parametri indicati nell’errore:

fail2ban-client set ssh addlogpath /var/log/auth.log

ed il messaggio è stato molto chiaro:

[Errno 13] Permission denied: '/var/log/auth.log'

Bene, per ovviare al problema basta far in modo che l’utente che esegue fail2ban possa accedere al suddetto file di log.

enjoy!

Di default, fail2ban, blocca temporaneamente l’IP sorgente ed il tempo può essere modificato con la direttiva bantime nel file /etc/fail2ban/jail.conf.

Facendo qualche controllo in questi giorni, mi sono accorto che ci sono IP che effettuano continui tentativi di accesso e che riprendono a fare tentativi, dopo averli sbloccati (ovvero dopo che il bantime è trascorso).

Ho pensato che sarebbe utile un sistema che provvede a bloccare in modo definitivo un IP che persevera nei tentativi di accesso abusivo. Fail2ban può fare questo per noi, se lo configuriamo opportunamente. L’idea di base è quella di creare un controllo del file di log di fail2ban /var/log/fail2ban.log e se viene riscontrato il blocco per più di una volta da un qualsiasi filtro attivo, allora viene avviato una nuova azione di blocco definitivo. Vediamo come fare.

Nel file di configurazione /etc/fail2ban/jail.conf aggiungiamo:

[fail2ban]
enabled = true
filter = fail2ban
action = iptables[name=fail2ban]
logpath = /var/log/fail2ban.log
maxretry = 3
# findtime: 1 day
findtime = 86400
# bantime: es 31536000 for 1 year or negative number for permanent block
bantime = -1

poi creiamo il filtro in /etc/fail2ban/filter.d/fail2ban.conf :

# Fail2Ban configuration file for persistent block
#
# Author: Antonello Alonzi
#
# $Revision: 
#

[Definition]

# Count all bans in the logfile
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>

# Ignore our own bans, to keep our counts exact.
# In your config, name your jail 'fail2ban', or change this line!
ignoreregex = fail2ban.actions: WARNING \[fail2ban\] Ban <HOST>

Bene, ora riavviamo fail2ban e dopo 3 blocchi di un IP, verrà attivato il blocco permanente.

Quanto fatto, potrebbe andar bene, ma se dovessimo riavviare fail2ban, gli IP bloccati anche in modo permanente, verrebbero sbloccati. Poco male, perché non credo fail2ban venga riavviato ogni giorno e comunque appena vengono identificati nuovamente blocchi ripetuti, si riattiva il meccanismo di blocco permanente. Per quanto mi riguarda, utilizzando apf-firewall, ho pensato di gestire il blocco permanente con un’azione specifica, in modo che l’IP venga memorizzato da apf e quindi gestito autonomamente da quest’ultimo.

Se volete usare questa soluzione, basterà creare un nuova azione di fail2ban, partendo da quella di shorewall:

cp /etc/fail2ban/action.d/shorewall.conf /etc/fail2ban/action.d/apf.conf

e poi modificando le righe di actionban ed actionunban in /etc/fail2ban/action.d/apf.conf come segue:

actionban = apf --deny

actionunban = apf --remove

Infine andrà modificata l’action della regola fail2ban in /etc/fail2ban/jail.conf da:

action = iptables[name=fail2ban]

a

action = apf[name=fail2ban]

Varie:

Per testare il funzionamento di un filtro, ad esempio il filtro fail2ban creato prima, basta digitare:

fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Se si vuole testare sia la regexp che l’ignore filter, va ripetuto due volte il nome del file con il filtro, es:

fail2ban-regex /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf /etc/fail2ban/filter.d/fail2ban.conf

Per vedere i dettagli delle righe rilevate, bisogna aggiungere il parametro -v, es:

fail2ban-regex -v /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Per vedere invece l’elenco delle righe trovate si usa –print-all-matched:

fail2ban-regex --print-all-matched /var/log/fail2ban.log /etc/fail2ban/filter.d/fail2ban.conf

Per verificare i filtri attivi:

fail2ban-client status

Per controllare gli IP bloccati da un determintato filtro:

fail2ban-client status fail2ban

enjoy!

#SecAuditLogRelevantStatus "^(?:5|4(?!04))"

Creiamo un nuovo filtro per fail2ban, scrivendo nel file /etc/fail2ban/filter.d/mod_sec.conf:

# Fail2Ban configuration file for mod_security

[Definition]
failregex = \[.*?\]\s[\w-]*\s\s
ignoreregex =

Attiviamo il filtro in /etc/fail2ban/jail.conf:

[mod_sec]
enabled  = true
filter   = mod_sec
action   = iptables-multiport[name=ModSec, port="http,https"]
#           sendmail-buffered[name=ModSec, lines=5, dest=you@mail.com]
simple-log[name=modsec]
logpath  = /var/log/apache2/modsec_audit.log
#bantime  = 172800
maxretry = 3

Bene, ora possiamo riavviare apache e fail2ban ed i tentativi di richieste anomale al server web verranno bloccati.

enjoy!