Introduzione
SSH è il metodo di fatto per connettersi a un server cloud. È resistente e estensibile: nuovi standard di crittografia possono essere utilizzati per generare nuove chiavi SSH, garantendo che il protocollo principale rimanga sicuro. Tuttavia, nessun protocollo o stack software è completamente sicuro, e il fatto che SSH sia così ampiamente utilizzato su Internet significa che rappresenta una superficie di attacco molto prevedibile attraverso la quale le persone possono cercare di ottenere accesso.
Ogni servizio esposto alla rete è un potenziale bersaglio in questo modo. Se si esaminano i registri del servizio SSH in esecuzione su un server molto frequentato, si vedranno spesso tentativi di accesso ripetuti e sistematici che rappresentano attacchi brute force da parte degli utenti e dei bot. Anche se è possibile apportare alcune ottimizzazioni al servizio SSH per ridurre al minimo la possibilità che questi attacchi abbiano successo, come disabilitare l’autenticazione tramite password a favore delle chiavi SSH, possono comunque rappresentare un rischio minore e continuo.
Le distribuzioni di produzione su larga scala per le quali questa responsabilità è completamente inaccettabile di solito implementano una VPN come WireGuard davanti al proprio servizio SSH, in modo che sia impossibile connettersi direttamente alla porta SSH predefinita 22 dall’esterno senza software di astrazione o gateway aggiuntivi. Queste soluzioni VPN sono ampiamente affidabili, ma aggiungono complessità e possono interrompere alcune automazioni o altri piccoli collegamenti software.
Prima di impegnarti o in aggiunta a un setup VPN completo, puoi implementare uno strumento chiamato Fail2ban. Fail2ban può mitigare significativamente gli attacchi di forza bruta creando regole che modificano automaticamente la configurazione del firewall per bandire specifici indirizzi IP dopo un certo numero di tentativi di accesso non riusciti. Ciò consentirà al tuo server di rinforzarsi contro questi tentativi di accesso senza intervento da parte tua.
In questa guida, vedrai come installare e utilizzare Fail2ban su un server Debian 11.
Prerequisiti
Per completare questa guida, avrai bisogno di:
-
Un server Debian 11 e un utente non root con privilegi sudo. Puoi saperne di più su come configurare un utente con questi privilegi nella nostra guida Configurazione Iniziale del Server con Debian 11.
-
Facoltativamente, un secondo server a cui puoi connetterti dal tuo primo server, che userai per testare l’essere deliberatamente bannato.
Passaggio 1 — Installazione di Fail2ban
Fail2ban è disponibile nei repository software di Debian. Inizia eseguendo i seguenti comandi come utente non root per aggiornare le tue liste dei pacchetti e installare Fail2ban:
Fail2ban imposterà automaticamente un servizio in background dopo essere stato installato. Puoi verificare il suo stato utilizzando il comando systemctl:
Output● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled
Active: active (running) since Tue 2022-06-28 16:23:14 UTC; 17s ago
Docs: man:fail2ban(1)
Process: 1942 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS
Main PID: 1943 (fail2ban-server)
Tasks: 5 (limit: 1132)
Memory: 15.8M
CPU: 280ms
CGroup: /system.slice/fail2ban.service
└─1943 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
Puoi continuare ad utilizzare Fail2ban con le sue impostazioni predefinite, ma prima, esaminerai alcune delle sue funzionalità.
Passaggio 2 – Configurazione di Fail2ban
Il servizio fail2ban conserva i suoi file di configurazione nella directory /etc/fail2ban. C’è un file con le impostazioni predefinite chiamato jail.conf. Vai in quella directory e stampa le prime 20 righe di quel file usando il comando head -20:
Output#
# AVVISO: pesantemente refattorizzato nella versione 0.9.0. Si prega di esaminare e
# personalizzare le impostazioni per la propria configurazione.
#
# Cambiamenti: nella maggior parte dei casi non è necessario modificare questo
# file, ma fornire personalizzazioni nel file jail.local,
# o file .conf separati nella directory jail.d/, ad esempio:
#
# COME ATTIVARE LE PRIGIONI:
#
# NON SI DEVE MODIFICARE QUESTO FILE.
#
# Probabilmente verrà sovrascritto o migliorato in un aggiornamento della distribuzione.
#
# Fornire personalizzazioni in un file jail.local o in un jail.d/customisation.local.
# Per esempio, per modificare il bantime predefinito per tutte le prigioni e per abilitare il
# prigione ssh-iptables, quanto segue (senza commenti) dovrebbe apparire nel file .local.
# Consultare man 5 jail.conf per i dettagli.
#
# [DEFAULT]
Come vedrai, le prime righe di questo file sono commentate – iniziano con caratteri # indicando che devono essere interpretate come documentazione piuttosto che come impostazioni. Come vedrai anche, questi commenti ti indicano di non modificare direttamente questo file. Invece, hai due opzioni: creare profili individuali per Fail2ban in file multipli all’interno della directory jail.d/, oppure creare e raccogliere tutte le tue impostazioni locali in un file jail.local. Il file jail.conf verrà periodicamente aggiornato quando Fail2ban stesso verrà aggiornato e verrà utilizzato come fonte di impostazioni predefinite per le quali non hai creato alcuna modifica.
In questo tutorial, creerai jail.local. Puoi farlo copiando jail.conf:
Ora puoi iniziare a fare modifiche di configurazione. Apri il file in nano o nel tuo editor di testo preferito:
Mentre stai scorrendo il file, questo tutorial esaminerà alcune opzioni che potresti voler aggiornare. Le impostazioni situate sotto la sezione [DEFAULT] vicino all’inizio del file verranno applicate a tutti i servizi supportati da Fail2ban. Altrove nel file, ci sono intestazioni per [sshd] e per altri servizi, che contengono impostazioni specifiche del servizio che si applicheranno sopra ai valori predefiniti.
[DEFAULT]
. . .
bantime = 10m
. . .
Il parametro bantime imposta la durata del tempo in cui un client sarà bandito quando non ha avuto successo nell’autenticazione corretta. Questo è misurato in secondi. Per impostazione predefinita, è impostato su 10 minuti.
[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .
I prossimi due parametri sono findtime e maxretry. Questi lavorano insieme per stabilire le condizioni in base alle quali un client viene considerato un utente illegittimo che dovrebbe essere bandito.
La variabile maxretry imposta il numero di tentativi che un client ha per autenticarsi entro una finestra temporale definita da findtime, prima di essere bandito. Con le impostazioni predefinite, il servizio fail2ban bandirà un client che tenta senza successo di effettuare il login 5 volte entro una finestra di 10 minuti.
[DEFAULT]
. . .
destemail = root@localhost
sender = root@<fq-hostname>
mta = sendmail
. . .
Se hai bisogno di ricevere avvisi via email quando Fail2ban interviene, dovresti valutare le impostazioni destemail, sendername e mta. Il parametro destemail imposta l’indirizzo email che dovrebbe ricevere i messaggi di divieto. Il parametro sendername imposta il valore del campo “Da” nell’email. Il parametro mta configura il servizio di posta che verrà utilizzato per inviare la posta. Per impostazione predefinita, questo è sendmail, ma potresti voler usare Postfix o un’altra soluzione di posta.
[DEFAULT]
. . .
action = $(action_)s
. . .
Questo parametro configura l’azione che Fail2ban intraprende quando vuole istituire un divieto. Il valore action_ è definito nel file poco prima di questo parametro. L’azione predefinita è aggiornare la configurazione del firewall per rifiutare il traffico dall’host incriminato fino a quando il tempo di divieto non scade.
Sono forniti altri script action_ predefiniti che è possibile sostituire con $(action_) sopra:
…
# divieto e invia un'email con il report whois al destemail.
action_mw = %(action_)s
%(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
# divieto e invia un'email con il report whois e le righe di registro rilevanti
# al destemail.
action_mwl = %(action_)s
%(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
# Vedi la nota IMPORTANTE in action.d/xarf-login-attack per sapere quando utilizzare questa azione
#
# divieto e invia un'email xarf al contatto di abuso dell'indirizzo IP e include le righe di registro rilevanti
# al destemail.
action_xarf = %(action_)s
xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
# divieto IP su CloudFlare e invia un'email con il report whois e le righe di registro rilevanti
# al destemail.
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
%(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
…
Per esempio, action_mw prende azioni ed invia un’email, action_mwl prende azioni, invia un’email e include il logging, e action_cf_mwl fa tutto ciò che è stato detto precedentemente oltre ad inviare un aggiornamento all’API Cloudflare associata al tuo account per bandire anche l’offensore lì.
Impostazioni di Prigione Individuali
Segue la porzione del file di configurazione che tratta dei servizi individuali. Questi sono specificati da intestazioni di sezione, come [sshd].
Ognuna di queste sezioni deve essere abilitata singolarmente aggiungendo una linea enabled = true sotto l’intestazione, insieme alle altre impostazioni.
[jail_to_enable]
. . .
enabled = true
. . .
Per impostazione predefinita, il servizio SSH è abilitato e tutti gli altri sono disabilitati.
.
Alcune altre impostazioni impostate qui sono il filter che verrà utilizzato per decidere se una riga in un log indica un’autenticazione fallita e il logpath che indica a fail2ban dove si trovano i log per quel particolare servizio.
Il valore del filter è in realtà un riferimento a un file situato nella directory /etc/fail2ban/filter.d, con l’estensione .conf rimossa. Questi file contengono espressioni regolari (un comune abbreviazione per l’analisi del testo) che determinano se una riga nel registro è un tentativo di autenticazione fallito. Non tratteremo questi file in modo approfondito in questa guida, perché sono piuttosto complessi e le impostazioni predefinite corrispondono bene alle righe appropriate.
Tuttavia, puoi vedere quali filtri sono disponibili guardando in quella directory:
Se vedi un file che sembra correlato a un servizio che stai utilizzando, dovresti aprirlo con un editor di testo. La maggior parte dei file è abbastanza ben commentata e dovresti essere in grado almeno di capire contro quale tipo di condizione lo script è stato progettato per proteggere. La maggior parte di questi filtri ha sezioni appropriate (disabilitate) nel file jail.conf che possiamo abilitare nel file jail.local se desiderato.
Ad esempio, immagina di servire un sito web utilizzando Nginx e ti rendi conto che una parte del tuo sito protetta da password sta ricevendo un gran numero di tentativi di accesso. Puoi dire a fail2ban di utilizzare il file nginx-http-auth.conf per controllare questa condizione all’interno del file /var/log/nginx/error.log.
Questo è già configurato in una sezione chiamata [nginx-http-auth] nel tuo file /etc/fail2ban/jail.conf. Dovresti solo aggiungere il parametro enabled:
. . .
[nginx-http-auth]
enabled = true
. . .
Quando hai finito di modificare, salva e chiudi il file. Se hai apportato delle modifiche, puoi riavviare il servizio Fail2ban usando systemctl:
Nel prossimo passaggio, dimostrerai il funzionamento di Fail2ban.
Passaggio 3 — Test delle Politiche di Blocco (Opzionale)
Da un altro server, uno che non avrà bisogno di accedere al tuo server Fail2ban in futuro, puoi testare le regole facendo bannare quel secondo server. Dopo esserti connesso al tuo secondo server, prova ad accedere tramite SSH al server Fail2ban. Puoi provare a connetterti usando un nome inesistente:
Inserisci caratteri casuali nel prompt della password. Ripeti questo alcune volte. Ad un certo punto, l’errore che ricevi dovrebbe cambiare da Permission denied a Connection refused. Questo segnala che il tuo secondo server è stato bannato dal server Fail2ban.
Sul tuo server Fail2ban, puoi vedere la nuova regola controllando l’output del comando iptables. iptables è un comando per interagire con le regole di porta e firewall a livello basso sul tuo server. Se hai seguito la guida di DigitalOcean per la configurazione iniziale del server, userai ufw per gestire le regole del firewall a un livello più alto. Eseguire iptables -S ti mostrerà tutte le regole del firewall che ufw ha già creato:
Output-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N f2b-sshd
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
…
Se si instrada l’output di iptables -S a grep per cercare all’interno di quelle regole la stringa f2b, è possibile vedere le regole che sono state aggiunte da fail2ban:
Output-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 134.209.165.184/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
La riga contenente REJECT --reject-with icmp-port-unreachable sarà stata aggiunta da Fail2ban e dovrebbe riflettere l’indirizzo IP del tuo secondo server.
Conclusione
Dovresti ora essere in grado di configurare alcune politiche di bannaggio per i tuoi servizi. Fail2ban è un modo utile per proteggere qualsiasi tipo di servizio che utilizza l’autenticazione. Se desideri saperne di più su come funziona fail2ban, puoi consultare il nostro tutorial su come funzionano le regole e i file di fail2ban.
Per informazioni su come utilizzare fail2ban per proteggere altri servizi, puoi leggere su Come Proteggere un Server Nginx con Fail2Ban e Come Proteggere un Server Apache con Fail2Ban.
Source:
https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11