Come proteggere il server ubuntu dagli attacchi ssh bruteforce?

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

Verifica questo ottimo manuale per approcci diversi (autenticazione RSA inclusa): link

Sto utilizzando la terza soluzione sul mio server perché non voglio renderlo complicato per i miei utenti non professionali: utilizzando iptables per limitare il numero di connessioni al minuto che rende gli attacchi bruteforce lenti e inutili.

Ecco la soluzione che sto utilizzando:

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 detto qui : ciò consentirà tre connessioni 22 porte da qualsiasi dato indirizzo IP all'interno un periodo di 60 secondi e richiede 60 secondi di tentativi di connessione successivi prima che riprenda a consentire nuovamente le connessioni. L'opzione --rttl tiene conto anche del TTL del datagramma quando si confrontano i pacchetti, in modo da sforzarsi di mitigare gli indirizzi di origine falsificati.

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

iptables -N SSH_WHITELIST

Quindi aggiungi host fidati:

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

E dopo, fai 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

Ottengo attacchi ssh a forza bruta sui miei server con una velocità da 1 a 2 al giorno. Ho installato denyhosts (pacchetto ubuntu: denyhosts). È uno strumento molto semplice ma efficace per questo scopo: in pratica esegue periodicamente una scansione dei log per rilevare gli attacchi brute-force e mette gli IP da dove questi attacchi hanno origine nel file /etc/hosts.deny. Non sentirai più niente da loro e il tuo carico dovrebbe essere ridotto considerevolmente. È molto configurabile tramite il suo file di configurazione /etc/denyhosts.conf per risolvere problemi come quanti tentativi sbagliati costituiscono un attacco ecc.

Grazie al suo funzionamento trasparente puoi vedere facilmente cosa sta succedendo (notifica via email: "aha, un altro attacco vile ostacolato!") e annulla gli errori a causa della ripetizione errata delle password da parte degli utenti.

Ovviamente, tutto ciò che è stato detto in precedenza riguardo al passaggio ad altri metodi di autenticazione vale, ma a volte i tuoi requisiti non sono in accordo con quelli dei tuoi utenti.

Inoltre, la limitazione della velocità della nuova connessione in iptables potrebbe essere una scelta migliore, quindi negare l'accesso tramite hosts.deny. Quindi, dai un'occhiata anche a fail2ban. Ma se sai che la forza bruta di ssh è la tua preoccupazione principale (controlla manualmente attraverso /var/log/auth.log per determinarlo), vai con questo strumento molto facile e a basso impatto.

1. Cambia la porta sshd in qualcosa di non standard
2. Utilizza knockd per implementare un sistema port-knocking
3. Utilizza iptables ' recent e hashlimit corrisponde per limitare i tentativi SSH consecutivi
4. Non usare password, ma usa invece 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 risponda ai login delle password.

link

L'uso di fail2ban potrebbe anche essere un'opzione.

link

Hai intenzione di consentire il servizio SSH al mondo? O solo per i membri del team in determinati luoghi? 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 permetta il login della password per l'utente root.

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

Nei miei sistemi, ho questa impostazione

PermitRootLogin without-password

ma ho notato che nella nuova versione di Ubuntu 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 essere.

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

2. modifica /etc/hosts.deny e inserisci

   ALL: ALL

Quindi modifica /etc/hosts.allow ed elenca i numeri IP o un intervallo che vuoi consentire di usare SSH. La notazione è un po 'confusa perché se si desidera consentire tutti i sistemi con numeri IP come 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 forza bruta, una soluzione potente. Se i tuoi utenti possono essere enumerati in base all'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 delle tabelle IP individueranno i nemici prima dei programmi guidati dagli host. allow e hosts.deny. Ma questo è un fuoco sicuro, un modo semplice per risolvere molti problemi, non solo da SSH.

Nota il problema che crei per te stesso. Se vuoi aprire un server FTP, un web server, o qualcosa del genere, dovrai fare in modo che le voci siano consentite dagli host.

È possibile raggiungere lo stesso scopo di base giocando con iptables e il firewall. In un certo senso, questa è una soluzione preferita perché stai bloccando i nemici sul confine esterno. Ubuntu ha "ufw" (firewall non complicato) e "man ufw" ha un sacco di esempi. Preferirei avere una bella interfaccia grafica per guadare questo, non devo farlo tutto il tempo. Forse altri possono dirci se ce n'è uno ora.

3. Altri post qui suggeriti di utilizzare la chiave pubblica SSH solo per i tuoi utenti. Questo sicuramente ti aiuterà, al prezzo della complessità e della frustrazione per i tuoi utenti. Nel nostro laboratorio ci sono 15 computer. Gli utenti vanno tra i computer. Richiedere l'autenticazione della chiave SSH potrebbe causare grossi problemi perché le persone passano da un computer all'altro.

Un'altra fonte di frustrazione si verificherà quando alcuni utenti accumulano chiavi ssh diverse per vari server. Poiché ho le chiavi SSH per circa 12 diversi progetti, ora ssh non funziona 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 a SSH dal vasto mondo, allora dovresti usare una procedura di rifiuto per bloccare le posizioni che spesso tentano di accedere. Ci sono 2 programmi carini per questo, quelli che abbiamo usato sono denyhosts e fail2ban. Questi programmi hanno impostazioni che ti consentono di escludere i trasgressori, per una durata che ti piace.

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

In entrambi questi programmi, è un po 'noioso portare gli utenti fuori dalla prigione se dimenticano la loro password e provare qualche volta ad accedere. È un po' difficile far rientrare la gente quando commette errori di accesso. Avresti intuito che ci sarebbe stata una GUI point-and-click in cui potresti semplicemente indicare e far rientrare la gente, ma non è così. Devo farlo solo ogni pochi mesi e dimenticare come, tra una volta e l'altra, ho scritto le mie istruzioni sulla mia pagina web link

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

Un'alternativa a fail2ban è CSF: Sicurezza ConfigServer & amp; Firewall.

Viene fornito con LFD: un daemon 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 definitivamente).

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

Svantaggi:

• È necessario utilizzare CSF come firewall per consentire a LFD di svolgere il proprio lavoro. Pertanto, se si dispone di un firewall esistente, sarà necessario sostituirlo con CSF e trasferire la configurazione su
• Non è pacchettizzato 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!