Vale la pena di bloccare i tentativi di accesso falliti

Vale la pena eseguire fail2ban , sshdfilter o strumenti simili, quali indirizzi IP nella blacklist che tentano e non riescono ad accedere?

Ho visto che ha sostenuto che si tratta di un teatro della sicurezza su un server "adeguatamente protetto". Tuttavia, ritengo che probabilmente i kiddie degli script passano al server successivo nella loro lista.

Diciamo che il mio server è "adeguatamente protetto" e non sono preoccupato che un attacco di forza bruta abbia effettivamente successo: questi strumenti mantengono semplicemente puliti i miei file di registro o sto ottenendo qualche utile vantaggio nel bloccare i tentativi di attacco di forza bruta?

Aggiornamento : molti commenti sull'ipotesi della forza bruta delle password - ho detto che non ero preoccupato per questo. Forse avrei dovuto essere più specifico e chiedere se fail2ban avesse dei vantaggi per un server che consente solo accessi SSH basati su chiavi.

I tentativi di accesso con limitazione della velocità sono un modo semplice per prevenire alcuni degli attacchi di ipotesi di password ad alta velocità. Tuttavia, è difficile limitare gli attacchi distribuiti e molti corrono a un ritmo basso per settimane o mesi. Personalmente preferisco evitare di utilizzare strumenti di risposta automatizzati come fail2ban. E questo per due motivi:

1. Gli utenti legittimi a volte dimenticano le loro password. Non voglio vietare al mio server utenti legittimi, costringendomi a riabilitare manualmente i loro account (o peggio, prova a capire quale degli indirizzi IP vietati 100/1000 è il loro).
2. Un indirizzo IP non è un buon identificatore per un utente. Se hai più utenti dietro un singolo IP (ad esempio, una scuola che gestisce NAT su 500 macchine studente), un singolo utente che fa alcune ipotesi sbagliate può farti entrare in un mondo di dolore. Allo stesso tempo, la maggior parte dei tentativi di indovinare la password che vedo sono distribuiti.

Pertanto non considero fail2ban (e strumenti di risposta automatizzati simili) un ottimo approccio per proteggere un server da attacchi di forza bruta. Una semplice regola di IPTables impostata per ridurre il log spam (che ho sulla maggior parte dei miei server Linux) è qualcosa del genere:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Impedisce più di 4 tentativi di connessione da un singolo IP a SSH in un periodo di 60 secondi. Il resto può essere gestito garantendo che le password siano ragionevolmente forti. Su server ad alta sicurezza costringere gli utenti a utilizzare l'autenticazione con chiave pubblica è un altro modo per smettere di indovinare.

Strumenti come fail2ban aiutano a ridurre il traffico di rete non necessario e a mantenere i file di registro un po 'più piccoli e più puliti. Non è un grosso problema di sicurezza, ma rende la vita del sistema un po 'più semplice; ecco perché raccomando di usare fail2ban su sistemi dove te lo puoi permettere.

Non si tratta solo di ridurre il rumore: la maggior parte degli attacchi ssh cerca di indovinare le password con forza bruta. Quindi, mentre vedrai molti tentativi ssh falliti, forse quando arriva il 2034 ° tentativo potrebbero ottenere un nome utente / password validi.

La cosa bella di fail2ban rispetto ad altri approcci è che ha un effetto minimo sui tentativi di connessione validi.

Bene, salva un po 'la tua rete dagli attacchi di negazione e risparmia sui costi di elaborazione degli errori.

Non essere il server più debole in un elenco di kiddies di script è sempre una buona cosa.

Siamo spiacenti, ma direi che il tuo server è adeguatamente protetto se il tuo SSH rifiuta i tentativi di autenticazione con password.

PasswordAuthentication no