Fail2ban non mette in sicurezza SSH, e lo dice il suo stesso README

Installi fail2ban, guardi il contatore dei ban salire, ti senti più al sicuro. È questa sequenza il motivo per cui lo strumento è presente su quasi ogni server, ed è anche il motivo per cui molti di quei server sono meno protetti di quanto i loro proprietari credano.

L’affermazione più chiara del problema non si trova in una critica a fail2ban. Si trova nel README di fail2ban stesso.

Cosa fa davvero

Il meccanismo è semplice e funziona. Fail2ban analizza file di log come /var/log/auth.log e banna gli indirizzi IP che effettuano troppi tentativi di login falliti. Lo fa aggiornando le regole del firewall di sistema per rifiutare le nuove connessioni da quegli indirizzi IP, per un periodo di tempo configurabile.

Arriva già pronto a leggere molti file di log standard, compresi quelli di sshd e Apache, e può essere puntato su qualsiasi file di log tu scelga, per qualsiasi errore tu voglia. Dalla versione 0.10 riconosce anche gli indirizzi IPv6.

È un pezzo di infrastruttura genuinamente utile. Un server esposto a internet raccoglie migliaia di tentativi di login automatizzati al giorno, e fail2ban trasforma quel diluvio in un rivolo.

La frase che il progetto mette nel proprio README

Ed è qui che lo strumento è più onesto della maggior parte dei consigli che lo riguardano:

Sebbene Fail2Ban sia in grado di ridurre la frequenza dei tentativi di autenticazione errati, non può eliminare il rischio rappresentato da un’autenticazione debole.

Leggi bene cosa ammette. Fail2ban agisce sulla frequenza. Non agisce sul rischio. Sono due grandezze diverse, e confonderle è l’errore per intero.

Se il tuo server SSH accetta una password, un attaccante deve indovinarla. Fail2ban rallenta i tentativi fino a renderli lentissimi e rende impraticabile un brute force ingenuo. Ma la porta si apre comunque per chiunque abbia la password, che l’abbia indovinata, ottenuta con il phishing, comprata in un dump di credenziali o estratta da un login riutilizzato su un sito violato del tutto scollegato. Nessuno di questi percorsi comporta fallimenti ripetuti, quindi nessuno di essi fa scattare un ban.

Cosa il progetto ti dice di fare al suo posto

Il README non si ferma all’avvertimento. Indica l’alternativa:

Configura i servizi per usare solo meccanismi di autenticazione a due fattori o a chiave pubblica/privata se vuoi davvero proteggere i servizi.

Questa è la correzione vera, ed è un cambiamento di natura, non di grado. Un server che accetta solo l’autenticazione a chiave non può essere sottoposto a brute force in alcun modo, perché non c’è nulla da indovinare. La superficie di attacco non viene ristretta, viene rimossa.

Nota la parola solo. Aggiungere una chiave lasciando abilitata l’autenticazione con password non cambia nulla riguardo al rischio, perché il metodo più debole tra quelli accettati è quello che definisce la tua esposizione. L’impostazione che conta è disabilitare l’autenticazione con password, non aggiungere una chiave accanto a essa.

Quindi conviene usarlo

Sì, e per il motivo giusto.

Tienilo per il rumore. Dei log che riesci davvero a leggere valgono molto. Quando i tentativi di autenticazione falliti scendono da migliaia al giorno a una manciata, un’anomalia diventa visibile invece di restare sepolta. Questo è un beneficio operativo reale e un buon argomento a favore dello strumento.

Non contarlo come la tua sicurezza SSH. Se una revisione di sicurezza del tuo server si ferma a “fail2ban è installato”, la revisione si è fermata un passo troppo presto. La domanda che decide la tua esposizione è se l’autenticazione con password sia ancora accettata.

Osserva quanto ti costa. I ban si applicano agli indirizzi, e gli indirizzi sono condivisi. Una password digitata male su una rete aziendale o mobile può bloccare fuori tutti quelli dietro quell’indirizzo, te compreso. Fail2ban è uno dei modi più comuni con cui gli amministratori si chiudono fuori dai propri server.

Il riassunto onesto

Fail2ban fa esattamente ciò che dichiara: riduce la frequenza dei tentativi di autenticazione falliti bannando gli indirizzi rumorosi a livello di firewall, per un tempo configurabile, sulla base dei tuoi log.

La sua stessa documentazione è esplicita sul fatto che questo non può eliminare il rischio rappresentato da un’autenticazione debole, e che i servizi che vuoi davvero proteggere dovrebbero usare meccanismi a due fattori o a chiave pubblica e privata. Quelle due frasi valgono più della maggior parte delle checklist di hardening.

Usa fail2ban per mantenere i tuoi log leggibili. Disabilita l’autenticazione con password per mantenere il tuo server. Non sono sostituti l’uno dell’altro, e solo uno dei due cambia ciò che un attaccante è in grado di fare.

La descrizione del comportamento di fail2ban, il limite citato sull’autenticazione debole, la raccomandazione di usare l’autenticazione a due fattori o a chiave pubblica e privata, e il supporto IPv6 dalla versione 0.10, sono tratti dal README del progetto fail2ban stesso, verificato al momento della stesura. I dettagli di configurazione variano a seconda della distribuzione; controlla la documentazione del tuo pacchetto prima di affidarti a un percorso o a un valore predefinito specifico.