Come proteggere SSH con Fail2Ban su Rocky Linux 8

Introduzione

SSH è il metodo predefinito per connettersi a un server cloud. È resistente e estensibile: man mano che vengono sviluppati 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 è totalmente sicuro, e il fatto che SSH sia così ampiamente diffuso su Internet significa che rappresenta una superficie di attacco molto prevedibile o un vettore di attacco attraverso il 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, è possibile vedere 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 tali attacchi riescano, come disabilitare l’autenticazione tramite password a favore delle chiavi SSH, possono comunque rappresentare una minore responsabilità continua.

Le implementazioni di produzione su larga scala per le quali questa responsabilità è completamente inaccettabile di solito implementano una VPN come WireGuard davanti al loro servizio SSH, in modo che sia impossibile connettersi direttamente alla porta SSH predefinita 22 dall’esterno senza software di astrazione aggiuntivo o gateway. Queste soluzioni VPN sono ampiamente affidabili, ma aggiungeranno complessità e potrebbero rompere alcune automazioni o altri piccoli collegamenti software.

Prima di impegnarti o in aggiunta alla configurazione completa di una VPN, puoi implementare uno strumento chiamato Fail2ban. Fail2ban può mitigare significativamente gli attacchi di forza bruta creando regole che modificano automaticamente la configurazione del tuo firewall per bandire IP specifici dopo un certo numero di tentativi di accesso non riusciti. Questo 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 Rocky Linux 8.

Prerequisiti

Per completare questa guida, avrai bisogno di:

• Un server Rocky Linux 8 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 Rocky Linux 8. Dovresti anche avere firewalld in esecuzione sul server, il che è coperto nella nostra guida alla configurazione iniziale del server.

• Opzionalmente, un secondo server al quale puoi connetterti dal tuo primo server, che utilizzerai per testare l’essere bloccato deliberatamente.

Passaggio 1 — Installazione di Fail2ban

Fail2ban non è disponibile nei repository software predefiniti di Rocky. Tuttavia, è disponibile nel repository EPEL, o Enhanced Packages for Enterprise Linux, che è comunemente usato per pacchetti di terze parti su Red Hat e Rocky Linux. Se non hai ancora aggiunto EPEL alle tue fonti dei pacchetti di sistema, puoi aggiungere il repository utilizzando dnf, come faresti con l’installazione di qualsiasi altro pacchetto:

sudo dnf install epel-release -y

Il gestore di pacchetti dnf controllerà ora anche EPEL oltre alle tue fonti di pacchetti predefinite durante l’installazione di nuovi software. Procedi con l’installazione di Fail2ban:

sudo dnf install fail2ban -y

Fail2ban installerà automaticamente un servizio in background dopo essere stato installato. Tuttavia, è disabilitato per impostazione predefinita, poiché alcune delle sue impostazioni predefinite potrebbero causare effetti indesiderati. Puoi verificarlo utilizzando il comando systemctl:

systemctl status fail2ban.service

Output
○ fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled
     Active: inactive (dead)
       Docs: man:fail2ban(1)

Puoi abilitare Fail2ban immediatamente, ma prima esaminerai alcune delle sue funzionalità.

Passaggio 2 – Configurazione di Fail2ban

Il servizio fail2ban mantiene i suoi file di configurazione nella directory /etc/fail2ban. C’è un file con impostazioni predefinite chiamato jail.conf. Vai in quella directory e stampa le prime 20 righe di quel file usando head -20:

cd /etc/fail2ban
head -20 jail.conf

Output
#
# AVVISO: pesantemente ristrutturato nella versione 0.9.0. Si prega di rivedere e
# personalizzare le impostazioni per la propria configurazione.
#
# Modifiche: nella maggior parte dei casi non si dovrebbe modificare questo
# file, ma fornire personalizzazioni nel file jail.local,
# o in file .conf separati nella directory jail.d/, ad esempio:
#
# COME ATTIVARE LE CARCERI:
#
# NON SI DOVREBBE MODIFICARE QUESTO FILE.
#
# Probabilmente sarà sovrascritto o migliorato in un aggiornamento della distribuzione.
#
# Fornire personalizzazioni in un file jail.local o in un jail.d/customisation.local.
# Ad esempio, per modificare il tempo di ban predefinito per tutte le carceri e per abilitare il
# jail ssh-iptables, nel file .local comparirebbe quanto segue (non commentato).
# Consultare il manuale 5 jail.conf per i dettagli.
#
# [DEFAULT]

Come vedrai, le prime righe di questo file sono commentate – iniziano con i 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 sarà periodicamente aggiornato mentre Fail2ban stesso viene aggiornato e sarà utilizzato come fonte di impostazioni predefinite per le quali non hai creato alcuna sovrascrittura.

In questo tutorial, creerai jail.local. Puoi farlo copiando jail.conf:

sudo cp jail.conf jail.local

Ora puoi iniziare a apportare modifiche alla configurazione. Apri il file in vi o nel tuo editor di testo preferito:

sudo vi jail.local

Mentre scorri il file, questo tutorial esaminerà alcune opzioni che potresti voler aggiornare. Le impostazioni situate sotto la sezione [DEFAULT] vicino all’inizio del file saranno 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 i valori predefiniti.

[DEFAULT]
. . .
bantime = 10m
. . .

Il parametro bantime imposta la durata del tempo per cui un client sarà bandito quando non riesce ad autenticarsi correttamente. Questo viene misurato in secondi. Per impostazione predefinita, questo è impostato su 10 minuti.

[DEFAULT]
. . .
findtime = 10m
maxretry = 5
. . .

I due parametri successivi 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 invano di accedere 5 volte entro una finestra temporale 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 blocco. 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 blocco. 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 offensivo fino a quando il tempo di blocco non scade.

Esistono altri script action_ forniti per impostazione predefinita che puoi sostituire con $(action_) sopra:

…
# blocco e invio di un'email con rapporto whois al destemail.
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

# blocco e invio di un'email con rapporto whois e linee di log 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 quando usare questa azione
#
# blocco e invio di un'email xarf al contatto di abuso dell'indirizzo IP e inclusione di linee di log rilevanti
# al destemail.
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]

# blocco IP su CloudFlare e invio di un'email con rapporto whois e linee di log 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"]
…

Ad esempio, action_mw prende azione ed invia un’email, action_mwl prende azione, invia un’email e include il logging, e action_cf_mwl fa tutto quanto sopra oltre ad inviare un aggiornamento all’API Cloudflare associata al tuo account per bannare anche l’offensore lì.

Impostazioni Individuali del Carcere

Successivamente è la parte del file di configurazione che tratta i 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, con le loro altre impostazioni.

[jail_to_enable]
. . .
enabled = true
. . .

Per questo tutorial, abiliterai il carcere SSH. Dovrebbe essere in cima alle impostazioni del carcere individuale. I parametri predefiniti funzioneranno altrimenti, ma dovrai aggiungere una linea di configurazione che dica enabled = true sotto l’intestazione [sshd].

#
# JAILS
#

#
# Server SSH
#

[sshd]

# Per utilizzare modalità sshd più aggressive impostare il parametro del filtro "mode" in jail.local:
# normale (predefinito), ddos, extra o aggressivo (combina tutto).
# Vedi "tests/files/logs/sshd" o "filter.d/sshd.conf" per un esempio di utilizzo e dettagli.
#mode   = normale
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Altre impostazioni che vengono configurate 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 sono situati 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 (una forma comune per l’analisi del testo) che determinano se una riga nel log è un tentativo di autenticazione fallito. Non tratteremo questi file in dettaglio in questa guida, perché sono piuttosto complessi e le impostazioni predefinite corrispondono bene alle righe appropriate.

Tuttavia, puoi vedere quali tipi di filtri sono disponibili guardando in quella directory:

ls /etc/fail2ban/filter.d

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 sono abbastanza ben commentati e dovresti almeno capire che 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 viene bombardata con tentativi di accesso. Puoi dire a fail2ban di utilizzare il file nginx-http-auth.conf per verificare questa condizione all’interno del file /var/log/nginx/error.log.

Questo è già configurato nella 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 stai usando vi, utilizza :x per salvare e uscire. A questo punto, puoi abilitare il servizio Fail2ban in modo che si avvii automaticamente da ora in poi. Per prima cosa, esegui systemctl enable:

sudo systemctl enable fail2ban

Quindi, avvialo manualmente per la prima volta con systemctl start:

sudo systemctl start fail2ban

Puoi verificare che stia funzionando con systemctl status:

sudo systemctl status fail2ban

Output
● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled
     Active: active (running) since Mon 2022-06-27 19:25:15 UTC; 3s ago
       Docs: man:fail2ban(1)
   Main PID: 39396 (fail2ban-server)
      Tasks: 5 (limit: 1119)
     Memory: 12.9M
        CPU: 278ms
     CGroup: /system.slice/fail2ban.service
             └─39396 /usr/bin/python3.6 -s /usr/bin/fail2ban-server -xf start

Jun 27 19:25:15 fail2ban22 systemd[1]: Started Fail2Ban Service.
Jun 27 19:25:15 fail2ban22 fail2ban-server[39396]: Server ready

Nel prossimo passaggio, dimostrerai il funzionamento di Fail2ban.

Passaggio 3 — Test delle Politiche di Banning (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 effettuare l’accesso SSH al server Fail2ban. Puoi provare a connetterti usando un nome inesistente:

ssh blah@your_server

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 indica che il tuo secondo server è stato bannato dal server Fail2ban.

Sul tuo server Fail2ban, puoi vedere la nuova regola controllando l’output di fail2ban-client. fail2ban-client è un comando aggiuntivo fornito da Fail2ban per verificare la sua configurazione in esecuzione.

sudo fail2ban-client status

Output
Status
|- Number of jail:      1
`- Jail list:   sshd

Se esegui fail2ban-client status sshd, puoi vedere l’elenco degli IP che sono stati banditi da SSH:

sudo fail2ban-client status sshd

Output
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     7
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   134.209.165.184

I contenuti della lista IP banditi dovrebbero riflettere l’indirizzo IP del tuo secondo server.

Conclusione

Dovresti ora essere in grado di configurare alcune politiche di bandiera per i tuoi servizi. Fail2ban è un modo utile per proteggere qualsiasi tipo di servizio che utilizza l’autenticazione. Se vuoi 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.