Come proteggere il server Ubuntu da attacchi ssh bruteforce?

Ho le mie password sicure, ma ho sentito persone lamentarsi della perfomance di un server che crollava drasticamente quando si sta verificando un attacco bruteforce. Come posso proteggere il mio server Ubuntu 10.10 da tali attacchi? Esiste un profilo apparmor per questo? O qualche altro modo per affrontarlo?

Esistono diverse soluzioni. Il migliore è utilizzare l'autenticazione RSA che utilizza chiavi pubbliche / private per autenticare gli utenti.

Controlla questo ottimo manuale per approcci diversi (inclusa l'autenticazione RSA): http://www.la-samhna.de/library/brutessh.html

Sto usando la terza soluzione sul mio server perché non voglio complicarla per i miei utenti non tecnici: usare iptablesper limitare il numero di connessioni al minuto che rende gli attacchi bruteforce inefficaci e inefficaci.

Ecco la soluzione che sto usando:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Come menzionato qui : questo consentirà connessioni a tre porte 22 da qualsiasi indirizzo IP entro un periodo di 60 secondi e richiederà 60 secondi di nessun tentativo di connessione successivo prima che riprenda a consentire nuovamente le connessioni. L'opzione --rttl tiene anche conto del TTL del datagramma quando si abbinano i pacchetti, in modo da cercare di mitigare gli indirizzi sorgente falsificati.

Come indicato nella guida menzionata, è meglio utilizzare una lista bianca per separare gli utenti fidati da queste regole:

iptables -N SSH_WHITELIST

quindi aggiungere host attendibili:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

e successivamente stabilisci le regole:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Ricevo attacchi ssh a forza bruta sui miei server con una frequenza da 1 a 2 al giorno. Ho installato denyhosts (pacchetto ubuntu: denyhosts). È uno strumento molto semplice ma efficace a tale scopo: essenzialmente scansiona periodicamente i tuoi registri per rilevare attacchi di forza bruta e mette gli IP da cui questi attacchi hanno origine nel tuo file /etc/hosts.deny. Non sentirai più da loro e il tuo carico dovrebbe essere ridotto considerevolmente. È molto configurabile tramite il suo file di configurazione /etc/denyhosts.conf per modificare problemi come quanti tentativi sbagliati comportano un attacco ecc.

Grazie al suo funzionamento trasparente puoi facilmente vedere cosa sta succedendo (notifica e-mail: "aha, un altro attacco sgarbato contrastato!") E annullare gli errori dovuti al fatto che i tuoi utenti digitano ripetutamente le loro password.

Ovviamente, tutto quanto detto in precedenza sul passaggio ad altri metodi di autenticazione è valido, ma a volte i tuoi requisiti non sono d'accordo con quelli dei tuoi utenti.

Inoltre, la limitazione della nuova connessione in iptables potrebbe essere una scelta migliore rispetto alla negazione dell'accesso tramite hosts.deny. Quindi, dai un'occhiata anche a fail2ban. Ma se sai che ssh brute-force è la tua principale preoccupazione (guarda manualmente attraverso /var/log/auth.log per determinarlo), vai con questo strumento molto semplice ea basso impatto.

1. Cambia la porta sshd in qualcosa di non standard
2. Utilizzare knockdper implementare un sistema di port knocking
3. Usa iptables ' recente hashlimitcorrispondenze per limitare i tentativi SSH consecutivi
4. Non utilizzare le password, ma utilizzare invece le chiavi SSH

Prima di tutto dovresti considerare di non usare password e usare invece le chiavi. Non è necessario utilizzare una password. Se questo funziona per te, puoi configurare il server OpenSSH in modo che non reagisca agli accessi con password.

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

Utilizzando fail2ban, potrebbe anche essere un'opzione.

https://help.ubuntu.com/community/Fail2ban

Quanto è esposto il server sulla rete? Forse puoi parlare con l'amministratore di rete e verificare se è possibile monitorare e limitare l'accesso di rete al server. Anche se gli accessi all'account sono sicuri, sembra che il server potrebbe soffrire di un semplice attacco DoS / DDoS.

Un'alternativa a fail2ban è CSF: ConfigServer Security & Firewall .

Viene fornito con LFD: un demone di errore di accesso in grado di rilevare più tentativi di accesso non riusciti su vari servizi e bloccherà l'indirizzo IP offensivo (temporaneamente o permanentemente).

Ha alcune altre opzioni che possono aiutare contro gli attacchi di inondazioni e possibilmente rilevare intrusioni.

svantaggi:

• È necessario utilizzare CSF come firewall per consentire a LFD di svolgere il proprio lavoro. Quindi, se hai un firewall esistente, dovrai sostituirlo con CSF e trasferire la tua configurazione.
• Non è impacchettato per Ubuntu. Dovrai fidarti degli aggiornamenti automatici da configserver.com o disabilitare gli aggiornamenti automatici.
• Ho sentito che è abbastanza popolare, quindi gli intrusi intelligenti probabilmente sapranno come disabilitare il rilevamento delle intrusioni prima che vengano rilevati!

Intendi consentire il servizio SSH al mondo? O solo ai membri del team in luoghi particolari? La mia risposta dipende un po 'dalla gravità della tua sfida.

In entrambi i casi, una cosa che dovresti fare è assicurarti che il server SSH non consenta l'accesso con password per l'utente root.

1. In / etc / ssh / sshd_config assicurati di non consentire mai un login root se non con una chiave SSH.

Nei miei sistemi, ho questa impostazione

PermitRootLogin without-password

ma noto in Ubuntu più recente che hanno

PermitRootLogin prohibit-password

Se leggi "man sshd_config" penso che significhi che questa nuova "password proibita" significa la stessa cosa ed è certamente più ovvia nel significato. Questo NON è predefinito su alcuni sistemi Linux, ma probabilmente dovrebbe esserlo.

Ora, riguardo al tuo problema. Il tuo server di sistema utilizza solo alcuni utenti in determinati luoghi? Fai questo!

2. modifica /etc/hosts.deny e inserisci

   TUTTO TUTTO

Quindi modifica /etc/hosts.allow ed elenca i numeri IP o un intervallo che desideri consentire l'utilizzo di SSH. La notazione è un po 'confusa perché se si desidera consentire tutti i sistemi con numeri IP come da 111.222.65.101 a 111.222.65.255, si inserisce una voce come questa in hosts.allow

ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.

Questa è una soluzione potente e bruta. Se i tuoi utenti possono essere elencati per intervallo IP, fallo!

Questa soluzione esisteva prima della creazione delle tabelle IP, è (penso) molto più facile da amministrare, ma non è buona come una soluzione di tabelle IP perché le routine di tabelle IP individueranno i nemici prima dei programmi gestiti da hosts.allow e hosts .negare. Ma questo è un incendio sicuro, un modo semplice per chiudere molti problemi, non solo da SSH.

Nota il problema che crei per te stesso. Se si desidera aprire un server FTP, un server Web o quant'altro, è necessario inserire le voci negli host.

Puoi raggiungere lo stesso scopo di base armeggiando con iptables e il firewall. In un certo senso, questa è una soluzione preferita perché stai bloccando i nemici al limite esterno. Ubuntu ha "ufw" (firewall semplice) e "man ufw" ha molti esempi. Preferirei avere una bella interfaccia grafica per superare questo, non devo farlo tutto il tempo. Forse altri possono dirci se ce n'è uno ora.

3. Altri post qui suggeriti di usare la chiave pubblica SSH solo per i tuoi utenti. Ciò sarà sicuramente di aiuto, a prezzo di complessità e frustrazione per i tuoi utenti. Nel nostro laboratorio ci sono 15 computer. Gli utenti vanno tra i computer. Richiedere l'autenticazione con chiave SSH causerebbe una grande seccatura perché le persone passano da un computer all'altro.

Un'altra fonte di frustrazione accadrà quando alcuni utenti accumuleranno chiavi ssh diverse per vari server. Poiché ho chiavi SSH per circa 12 progetti diversi, ora ssh non riesce perché ho troppe chiavi pubbliche (richiede "ssh -o PubkeyAuthentication = false" o la creazione di una voce nel file .ssh / config. È una PITA)

4. Se devi lasciare il server aperto su SSH dal grande mondo, allora sicuramente dovresti usare una routine di rifiuto per bloccare le posizioni che spesso tentano di accedere. Ci sono 2 bei programmi per questo, quelli che abbiamo usato sono denyhosts e fail2ban . Questi programmi hanno impostazioni che ti consentono di vietare i trasgressori, per la durata che desideri.

Nei nostri sistemi Centos Linux, ho notato che hanno abbandonato il pacchetto denyhosts e offrono solo fail2ban. Mi è piaciuto denyhosts perché ha creato un elenco di utenti problematici / gamme ip e quindi in hosts.deny, quell'elenco è stato notato. Abbiamo invece installato fail2ban ed è OK. La mia comprensione è che preferiresti bloccare questi cattivi utenti sul bordo esterno del server, quindi i blocchi basati su tabelle ip, come fail2ban, sono effettivamente migliori. Denyhosts funziona al livello secondario, dopo che i nemici hanno superato iptables vengono respinti dal demone sshd.

In entrambi questi programmi, è un po 'noioso far uscire gli utenti dal carcere se dimenticano la password e provano alcune volte ad accedere. È un po' difficile riavviare le persone quando commettono errori di accesso. Avresti indovinato che ci sarebbe una GUI punta e clicca in cui potresti semplicemente puntare e far rientrare le persone, ma non è così. Devo farlo solo ogni pochi mesi e dimenticare come tra le volte, quindi ho scritto istruzioni per me stesso sulla mia pagina web http://pj.freefaculty.org/blog/?p=301