Ricerca nel sito web

Come proteggere SSH con Fail2Ban su Rocky Linux 9


introduzione

SSH è il metodo de facto per connettersi a un server cloud. È durevole ed 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 infallibile e il fatto che SSH sia così diffuso su Internet significa che rappresenta una superficie di attacco o vettore di attacco molto prevedibile attraverso la quale le persone possono cercare di ottenere l'accesso.

Qualsiasi servizio esposto alla rete è un potenziale obiettivo in questo modo. Se esamini i log per il tuo servizio SSH in esecuzione su qualsiasi server ampiamente trafficato, vedrai spesso tentativi di accesso ripetuti e sistematici che rappresentano attacchi di forza bruta da parte di utenti e bot. Sebbene tu possa apportare alcune ottimizzazioni al tuo servizio SSH per ridurre quasi a zero la possibilità che questi attacchi abbiano successo, come disabilitare l'autenticazione della password a favore delle chiavi SSH, possono comunque rappresentare una responsabilità minore e continua.

Le distribuzioni di produzione su larga scala per le quali questa responsabilità è del tutto 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 da Internet esterno senza ulteriore astrazione del software o gateway. Queste soluzioni VPN sono ampiamente affidabili, ma aggiungeranno complessità e possono interrompere alcune automazioni o altri piccoli hook software.

Prima o in aggiunta all'impegno per una configurazione VPN completa, puoi implementare uno strumento chiamato Fail2ban. Fail2ban può mitigare in modo significativo gli attacchi di forza bruta creando regole che modificano automaticamente la configurazione del firewall per vietare IP specifici dopo un certo numero di tentativi di accesso non riusciti. Ciò consentirà al tuo server di rafforzarsi contro questi tentativi di accesso senza alcun intervento da parte tua.

In questa guida vedrai come installare e utilizzare Fail2ban su un server Rocky Linux 9.

Prerequisiti

Per completare questa guida avrai bisogno di:

  • Un server Rocky Linux 9 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 9. Dovresti anche avere firewalld in esecuzione sul server, come descritto nella nostra guida iniziale alla configurazione del server.
  • Facoltativamente, un secondo server da cui puoi connetterti al tuo primo server, che utilizzerai per verificare di essere stato deliberatamente bannato.

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, comunemente utilizzato per i pacchetti di terze parti su Red Hat e Rocky Linux. Se non hai già aggiunto EPEL ai sorgenti dei pacchetti di sistema, puoi aggiungere il repository utilizzando dnf, come faresti con qualsiasi altro pacchetto:

  1. sudo dnf install epel-release -y

Il gestore di pacchetti dnf ora controllerà EPEL oltre alle origini dei pacchetti predefinite durante l'installazione di nuovo software. Procedi con l'installazione di Fail2ban:

  1. sudo dnf install fail2ban -y

Fail2ban imposterà automaticamente un servizio in background dopo l'installazione. Tuttavia, è disabilitato per impostazione predefinita, poiché alcune delle sue impostazioni predefinite potrebbero causare effetti indesiderati. Puoi verificarlo usando il comando systemctl:

  1. 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)

Potresti abilitare subito Fail2ban, 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:

  1. cd /etc/fail2ban
  2. head -20 jail.conf
Output
# # WARNING: heavily refactored in 0.9.0 release. Please review and # customize settings for your setup. # # Changes: in most of the cases you should not modify this # file, but provide customizations in jail.local file, # or separate .conf files under jail.d/ directory, e.g.: # # HOW TO ACTIVATE JAILS: # # YOU SHOULD NOT MODIFY THIS FILE. # # It will probably be overwritten or improved in a distribution update. # # Provide customizations in a jail.local file or a jail.d/customisation.local. # For example to change the default bantime for all jails and to enable the # ssh-iptables jail the following (uncommented) would appear in the .local file. # See man 5 jail.conf for details. # # [DEFAULT]

Come vedrai, le prime righe di questo file sono commentate: iniziano con caratteri # che indicano che devono essere lette come documentazione piuttosto che come impostazioni. Come vedrai anche, questi commenti ti stanno indirizzando a non modificare questo file direttamente. Invece, hai due opzioni: creare profili individuali per Fail2ban in più file all'interno della directory jail.d/, oppure creare e raccogliere tutte le tue impostazioni locali in un jail.local codice> file. Il file jail.conf verrà periodicamente aggiornato man mano che Fail2ban stesso viene aggiornato e verrà utilizzato come fonte di impostazioni predefinite per le quali non hai creato alcuna sostituzione.

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

  1. sudo cp jail.conf jail.local

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

  1. sudo vi jail.local

Mentre scorri il file, questo tutorial esaminerà alcune opzioni che potresti voler aggiornare. Le impostazioni che si trovano nella sezione [DEFAULT] nella parte superiore 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 verranno applicate oltre a quelle predefinite.

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

Il parametro bantime imposta il periodo di tempo durante il quale un client verrà bannato quando non è riuscito ad autenticarsi correttamente. Questo è 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 risulta essere un utente illegittimo che dovrebbe essere bannato.

La variabile maxretry imposta il numero di tentativi che un client deve autenticare entro una finestra di tempo definita da findtime, prima di essere bannato. Con le impostazioni predefinite, il servizio fail2ban bannerà un client che tenta senza successo di accedere 5 volte in 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 sendername imposta il valore del campo \Da nell'e-mail. Il parametro mta configura quale servizio di posta 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 intrapresa da Fail2ban quando vuole istituire un ban. Il valore action_ è definito nel file poco prima di questo parametro. L'azione predefinita consiste nell'aggiornare la configurazione del firewall per rifiutare il traffico dall'host incriminato fino allo scadere del tempo di divieto.

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

…
# ban & send an e-mail with whois report to the destemail.
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]

# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(action_)s
             %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]

# See the IMPORTANT note in action.d/xarf-login-attack for when to use this action
#
# ban & send a xarf e-mail to abuse contact of IP address and include relevant log lines
# to the destemail.
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]

# ban IP on CloudFlare & send an e-mail with whois report and relevant log lines
# to the 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 interviene e invia un'email, action_mwl interviene, invia un'email e include la registrazione e action_cf_mwl esegue tutte le sopra oltre a inviare un aggiornamento all'API Cloudflare associata al tuo account per bannare anche lì l'autore del reato.

Impostazioni della prigione individuale

La prossima è la parte del file di configurazione che si occupa dei singoli servizi. Questi sono specificati dalle intestazioni di sezione, come [sshd].

Ognuna di queste sezioni deve essere abilitata individualmente aggiungendo una riga enabled=true sotto l'intestazione, con le loro altre impostazioni.

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

Per questo tutorial, abiliterai la prigione SSH. Dovrebbe essere in cima alle singole impostazioni della prigione. I parametri predefiniti funzioneranno diversamente, ma dovrai aggiungere una riga di configurazione che dica enabled=true sotto l'intestazione [sshd].

#
# JAILS
#

#
# SSH servers
#

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Alcune altre impostazioni impostate qui sono il filtro che verrà utilizzato per decidere se una riga in un registro indica un'autenticazione non riuscita e il logpath che indica a fail2ban dove si trovano i registri per quel particolare servizio si trova.

Il valore filter è in realtà un riferimento a un file che si trova nella directory /etc/fail2ban/filter.d, con la sua estensione .conf rimossa . Questi file contengono espressioni regolari (un'abbreviazione comune per l'analisi del testo) che determinano se una riga nel registro è un tentativo di autenticazione non riuscito. 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 che tipo di filtri sono disponibili esaminando quella directory:

  1. 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 è commentata abbastanza bene e dovresti essere in grado di dire almeno da quale tipo di condizione lo script è stato progettato per proteggersi. La maggior parte di questi filtri ha sezioni appropriate (disabilitate) nel file jail.conf che possiamo abilitare nel file jail.local se lo desideriamo.

Ad esempio, immagina di servire un sito Web utilizzando Nginx e renditi conto che una parte del tuo sito protetta da password viene bloccata dai 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 in realtà è già impostato 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 stai usando vi, usa :x per salvare e uscire. A questo punto, puoi abilitare il tuo servizio Fail2ban in modo che d'ora in poi venga eseguito automaticamente. Innanzitutto, esegui systemctl enable:

  1. sudo systemctl enable fail2ban

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

  1. sudo systemctl start fail2ban

Puoi verificare che sia in esecuzione con systemctl status:

  1. sudo systemctl status fail2ban
Output
● fail2ban.service - Fail2Ban Service Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled Active: active (running) since Wed 2022-09-14 20:48:40 UTC; 2s 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 Sep 14 20:48:40 rocky9-tester systemd[1]: Starting Fail2Ban Service... Sep 14 20:48:40 rocky9-tester systemd[1]: Started Fail2Ban Service. Sep 14 20:48:41 rocky9-tester fail2ban-server[39396]: Server ready

Nel passaggio successivo, dimostrerai Fail2ban in azione.

Passaggio 3: test delle politiche di divieto (facoltativo)

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 aver effettuato l'accesso al tuo secondo server, prova a connetterti tramite SSH al server Fail2ban. Puoi provare a connetterti utilizzando un nome inesistente:

  1. ssh blah@your_server

Immettere caratteri casuali nella richiesta della password. Ripeti questo un paio di volte. Ad un certo punto, l'errore che ricevi dovrebbe cambiare da Autorizzazione negata a Connessione rifiutata. Questo segnala 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 controllare la sua configurazione in esecuzione.

  1. 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 bannati da SSH:

  1. 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 dell'lista di IP bloccati dovrebbero riflettere l'indirizzo IP del tuo secondo server.

Conclusione

Ora dovresti essere in grado di configurare alcune politiche di divieto 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 dare un'occhiata al nostro tutorial su come funzionano le regole e i file di fail2ban.

Per informazioni su come utilizzare fail2ban per proteggere altri servizi, puoi leggere Come proteggere un server Nginx con Fail2Ban.