Quali sono i pro / contro dei vari metodi per bloccare gli attacchi SSH a forza bruta?

Esistono numerosi pacchetti diversi per bloccare gli IP da cui vengono lanciati attacchi SSH a forza bruta sul sistema. Per esempio:

Quali sono i pro / contro di questi o di altri?

La mia attuale soluzione è quella di prendere l'email che logwatch genera ogni giorno e scaricare gli indirizzi IP egregi in un file di testo che inserisco in uno script che poi ricostruisce iptables. È complicato, dispendioso in termini di tempo e manuale e vorrei un modo migliore.

(Nota che non ho chiesto quale fosse il modo "migliore" per risolvere il problema, perché non esiste un modo "migliore" per fare qualcosa.)

ssh security

— Andy Lester
fonte

Risposte:

Uso DenyHosts, quindi posso almeno rispondere per quello:

Professionisti

È completamente automatico
È configurabile (quanti tentativi falliti prima della blacklist, per nomi utente che non esistono, nomi utente che esistono e una voce speciale per root)
Può inviarti periodicamente un'e-mail con un elenco di host appena inseriti nella lista nera e / o eseguire un determinato programma ogni volta che un nuovo host viene inserito nella lista nera
Supporta gli host automaticamente non inclusi nella blacklist dopo un po '

Contro

Non ho alcun contro irreparabile, purché lo usi correttamente:

Nella sua configurazione predefinita non ti avviserà degli host appena inseriti nella blacklist, quindi se qualcuno sta attaccando la tua rete da centinaia di indirizzi diversi potresti non accorgertene subito come faresti se controlli i log manualmente, ma (come menzionato in la sezione professionisti) può inviarti un'e-mail o eseguire un eseguibile per avvisarti quando vengono aggiunti nuovi host
Per impostazione predefinita, inserirà nella blacklist i tuoi host come tutti gli altri, quindi probabilmente vorrai aggiungerli /etc/hosts.allow. Mi sono bloccato una volta non riuscendo a digitare la mia password e una volta qualcuno dal lavoro ha cercato di accedere al mio account di root come uno scherzo e ho inserito nella lista nera il mio IP di lavoro, e mi ci sono voluti alcuni giorni per capire perché improvvisamente non riuscivo a connettermi alla mia rete dal lavoro più

— Michael Mrozek
fonte

Un altro è fail2ban , che si basa su iptables (quindi funziona con qualsiasi servizio, non solo con ssh). Con fail2ban puoi:

Specifica il percorso per qualsiasi file di registro (apache, ssh, nginx, mail server, ...).
Specifica regex per i modelli di attacco (ad esempio, più di 10 "404 errori" dallo stesso ip sul registro di accesso nginx in 6 secondi)
Specifica regex per ignorare alcuni schemi (molto utile!)
Specifica il tempo di divieto
Invia una e-mail (o qualsiasi altro avviso ...)
Completamente personalizzabile (puoi scrivere i tuoi avvisi e filtri)

Uno "svantaggio" di DenyHosts è che richiede wrapper tcp, quindi funzionerà solo con servizi che guardano il file /etc/hosts.deny. Ma per essere onesti con DenyHosts, sshd è compilato per usare TCP Wrapper sulla maggior parte delle distribuzioni Linux. Trovo anche DenyHosts più facile da configurare out of the box di fail2ban (ma meno potente).

Riferimento a una domanda SF simile

— Barthelemy
fonte

fail2ban, per fortuna, funziona anche con pf - non solo iptables

— Good Person

Una protezione semplice e in pratica efficace contro gli attacchi basati sulla scansione non è quella di utilizzare la porta standard. 443 (la porta https) ti espone a diversi attacchi di forza bruta che non hanno intenzione di decifrare le tue password deboli e probabilmente funziona attraverso più firewall rispetto alla porta predefinita (22).

La maggior parte dei metodi per prevenire gli attacchi di forza bruta ssh sono ottimi modi per auto-fare (oops, ho rovinato la configurazione! , l'attaccante proviene da / ha sovvertito una macchina nella mia stessa sottorete (intervallo IP dinamico, rete universitaria ...) e anch'io vengo bandito!).

Se accedi solo da alcuni punti, puoi solo inserire nella whitelist gli indirizzi IP di origine. Ovviamente non va bene se vuoi ssh dal tuo laptop o cellulare in movimento.

Avere un demone ssh che ascolta solo connessioni IPv6 dovrebbe proteggerti dalle scansioni già da qualche anno. Ma molti firewall non ti consentono di trasportare IPv6 in modo ragionevole.

Un altro metodo che non menzionate è il port knocking . Non soffre di problemi di auto-DoS (oltre alla configurazione errata), ma non attraversa bene i firewall e può aggiungere una latenza di alcuni secondi allo stabilimento di connessione.

Se hai buone password o puoi vivere senza autenticazione password, disabilita l'autenticazione password. (Le chiavi e le password monouso sono sufficienti per la maggior parte dei casi d'uso: se non ti fidi della macchina client abbastanza per memorizzare una chiave ssh, non ti fidi nemmeno di non avere un keylogger). Quindi gli attacchi di forza bruta ti costeranno un po 'di CPU e larghezza di banda ma non ti esporranno a un'intrusione (a patto che tu abbia verificato che nessuna delle tue chiavi provenga da un OpenSSL Debian a bassa entropia ).

Tutto sommato, notare che cambiare la porta non riduce significativamente l'esposizione. Otterrai meno scansioni , ma tutto ciò che puoi tagliare è il frutto basso che cerca di sfruttare vecchie vulnerabilità e password deboli. Finché si mantiene aggiornato il demone e si applicano password ragionevoli o limiti di velocità di tentativo ragionevoli, cambiare porta è più una responsabilità che una misura di sicurezza.

— Gilles 'SO- smetti di essere malvagio'
fonte

Sono d'accordo che ci vuole un po 'di pratica per non vietarti ;-) Cambiare le porte predefinite e non fare affidamento su una password ma su una chiave protetta da password è anche un buon consiglio. Ma davvero non so perché dovrei permettere alle reti di bot di riempire i miei file di registro di accesso mentre il mio server SSH e il mio web devono rifiutare migliaia di richieste all'ora. Con fail2ban, il mio registro di accesso è pulito e le mie applicazioni server non vedono affatto questo traffico (tranne le prime X richieste errate :-)).

— Barthelemy,

L'uso di una porta non standard non aggiunge alcuna protezione. La scansione per SSH su una porta non standard richiede solo pochi minuti in più rispetto alla scansione per SSH sulla porta 22 (Supponendo che il cracker esegua una scansione e la scansione non sia stata bloccata da un IDS. Ma se si dispone di un IDS, l'offuscamento della porta probabilmente non è necessario ). Se fossi un cracker e trovassi SSH su una porta non standard, sarei ancora PIÙ interessato perché so che l'amministratore ha pensato che questo servizio fosse abbastanza prezioso da nascondere e si affida alla sicurezza per oscurità.

— Stefan Lasiewski,

@Stefan: la maggior parte degli attacchi non è contro un determinato host ma contro un determinato servizio. Per questo è molto più efficace scansionare una singola porta su molti indirizzi rispetto a molte porte su ciascun indirizzo. E se in realtà hai un attaccante che ti prende di mira, è meglio che tu sappia, quindi vorrai registrare password sicure o proibite e gli attacchi.

— Gilles 'SO- smetti di essere malvagio'

@Stefan Vedo le porte non standard come una soluzione efficace a un fastidio (scansioni a forza bruta) e non come una misura di sicurezza (cioè impedire a qualcuno di assumere il controllo del mio server).

— Barthelemy,

@sudowned Specificare una porta diversa non è certo una seccatura. È solo una riga dentro .ssh/config. Il blocco è un problema se il firewall non ti lascia passare, e la soluzione più semplice è quella di aderire alla porta 22 e anche di ascoltare su 443. Sono d'accordo sul fatto che cambiare porta non migliora davvero la sicurezza, forse dovrei renderlo più chiaro . Non so perché consideri impossibile per un demone SSH non supportare l'autenticazione con password: si tratta solo di aggiungere una linea a sshd_configOpenSSH, l'implementazione più comune.

— Gilles 'SO- smetti di essere malvagio' il