Protezione del server SSH contro il bruteforcing

Ho un piccolo server SVN, vecchio dell optiplex con debian. Non ho richieste così elevate sul mio server, perché è solo un piccolo server SVN ... ma voglio che sia sicuro.

Ho appena rinnovato il mio server in un optiplex più nuovo e migliore e ho iniziato a cercare un po 'nel vecchio server. L'ho rimosso dopo aver riscontrato problemi. Quando controllo i registri, è pieno di tentativi di forza bruta e in qualche modo qualcuno è riuscito a entrare nella mia macchina. Questa persona ha creato un volume extra chiamato "knarkgosse" con due dirs "root" e "swap1" o qualcosa del genere. Non so davvero perché e cosa fanno, ma sicuramente voglio impedire che ciò accada di nuovo. Lo trovo un po 'strano però perché cambio la mia password ogni pochi mesi circa, e le password sono sempre lettere e numeri casuali messi insieme ... non è facile da forzare.

So di poter impedire al root di accedere, usare i sudo ... e cambiare la porta SSH, ma cosa posso fare di più?

Quindi ho alcune domande:

1. Come posso impedire l'accesso per 5 minuti dopo X quantità di tentativi errati. O tentativi lenti dopo ogni tentativo errato?

2. Esiste una specie di lista nera centrale a cui un server può connettersi? Una lista nera che tiene traccia degli indirizzi IP "non sicuri" e ai quali non dovrebbe mai essere concesso l'accesso?

3. Cosa posso fare di più per applicare la sicurezza al mio server?

Come ho detto prima, sto eseguendo Debian 5 con Apache (problema utente www-data?), Svn, mysql, php, phpmyadmin, hudson. È su una rete domestica con port forwarding su 80, 443, 8080, 8180, 23 e 22.

Fail2ban e Port Knocking dovrebbero soddisfare la maggior parte delle tue esigenze.

Si consiglia inoltre di modificare la porta SSH e di consentire solo l'autenticazione basata su chiave.

Si può obiettare che si possono raggiungere rendimenti decrescenti con l'aggiunta di ulteriori misure di sicurezza, ma, di nuovo, spetta a te decidere quando sei "abbastanza sicuro".

È anche una buona idea non consentire l'accesso root.

Non vi è alcun sostituto per password sicure E autenticazione con chiave. Detto questo, Fail2Ban è un ottimo strumento per vietare gli IP degli utenti che tentano di autenticarsi troppe volte. È anche disponibile come pacchetto predefinito per la maggior parte delle distribuzioni. Attenzione, puoi essere accidentalmente escluso, quindi assicurati di avere anche un IP di ripristino nella lista bianca o un facile accesso alla console ...

Fail2Ban ha diversi buoni esempi di come configurare tutto ciò che hai chiesto ... ma non ha un repository universale di indirizzi errati. Non penso che ci sia un simile repository ovunque a causa della facilità di ottenere un altro IP (dhcp rinnova / attacchi bot-net / ecc ...). Disabiliterei anche l'accesso tramite ssh usando nomi utente di tipo 'amministratore' comuni (root / admin / administrator / sysop / ecc.) In quanto questi sono i più comunemente bannati.

Ho fermato gli attacchi di forza bruta con:

• fail2ban
• sshd.config:
  • PasswordAuthentication No
  • PermitRootLogin No
• Limitare le tariffe SSH Connect con iptables ( http://www.debian-administration.org/articles/187 )

Ci sono una serie di buoni suggerimenti offerti qui. Suggerisco rispettosamente che tre cose dovrebbero renderlo relativamente sicuro:

1. Esegui sshd su una porta alta casuale. I robot in genere vanno solo dopo la porta 22 e le variazioni sulla porta 22 come 2222.
2. Disabilita l'autenticazione basata su password nella configurazione sshd:

UsePAM no

3. Autenticare solo con questo sito tramite coppie di chiavi SSH pre-condivise. Man on ssh-keygen per iniziare con l'autenticazione basata su PKI.

Spero che sia di aiuto.

Sono sempre stato un grande fan di CSF / LFD che può bloccare gli indirizzi IP di persone che cercano di potenziare la forza, portcancan e alcune altre opzioni. È fondamentalmente un enorme perl-wrapper per le tabelle IP, ma il file di configurazione non è difficile da leggere e la documentazione non è male.

Potresti anche guardare in sshguard. Non l'ho usato ma ho sentito cose positive.

Fonti:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard monitora i server dalla loro attività di registrazione. Quando i registri indicano che qualcuno sta facendo una Cosa Cattiva, sshguard reagisce bloccandolo per un po '. Sshguard ha una personalità permalosa: quando un tyke cattivo insiste a disturbare il tuo host, reagisce sempre più sodo ".

Ho un server SSH collegato a Internet sulla porta predefinita e non ho mai avuto problemi.

• tcp_wrappers (es. hosts.allow hosts.deny) per SSH .. Non penso che ci sia un SSH là fuori che non ha supporto compilato in esso
• iptables questo insieme a tcp_wrappers ha eliminato circa il 99% dei miei scansioni di porte casuali / tentativi di bruteforce .. l'unico problema è che devi sapere da dove ti collegherai per consentire quegli intervalli IP / IP ... Ho semplicemente fatto una ricerca su provider popolari nella mia zona per vedere i loro range IP e consentire a questi .. la maggior parte delle scansioni sembrano provenire da terre lontane :)
• PermitRootLogin senza password (cioè solo coppie di chiavi RSA / DSA che sono crittografate con una passphrase) funziona meravigliosamente per le attività automatizzate .. quando accedo per interagire ovviamente uso il mio account (normale) che è configurato con accesso sudo
• sudoers
• aggiornamenti costanti .. aggiorno frequentemente questa casella con tutti gli aggiornamenti di sicurezza / critici
• modifiche password / passphrase
• esegui chkrootkit ogni tanto per vedere se ho qualche problema .. (ce ne sono diversi là fuori che svolgono questa funzione)

spero che sia d'aiuto!

C'è un modo migliore per farlo, usando fail2ban significa che devi aggiungere un'applicazione e funziona a livello di applicazione.

Se usi iptables è più efficiente in quanto opera a livello di rete e non devi installare un'applicazione aggiuntiva.

Utilizzare il modulo recente di iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Un'opzione (da utilizzare in aggiunta ad altre misure di sicurezza) è quella di ascoltare sshd su una porta diversa da 22. Non l'ho provato da solo, ma ho sentito che riduce il numero di attacchi di pura forza bruta da parte dei robot.

Devo sottolineare che questa non è una vera sicurezza, riduce solo il numero di attacchi automatizzati di forza bruta. Troppo lavoro per controllare ogni porta immagino.

Qualcosa che non è menzionato qui e dovrebbe davvero limitare l'accesso tramite firewall. Questo non si adatta a tutte le situazioni, ma se ci si connette all'host da una posizione coerente con un IP statico, è possibile bloccare completamente SSH tranne che per quell'IP. Ciò garantirà che gli intrusi non possano entrare. Come ho già detto, ciò non sempre soddisfa ogni situazione, specialmente se il tuo IP è dinamico e cambia spesso.

DenyHosts, http://denyhosts.sourceforge.net/ , è un buon progetto con cui ho avuto fortuna. Se imposti denyhosts per la sincronizzazione, verranno scaricati nuovi IP da aggiungere a un elenco di ban che hanno dovuto forzare altri sistemi usando denyhosts. Scade anche gli IP che non hanno provato a forzare la forza per un po '.

L'uso dell'autenticazione con chiave pubblica e la disabilitazione della registrazione delle password è probabilmente la cosa migliore che potresti fare. Sconfigge qualsiasi attacco di forza bruta.

Cosa è stato efficace per me:

1. Come altri hanno già detto, nessun login root, PasswordAuthentication impostato su no (solo login con chiavi) in sshd_config

2. Solo uno o due utenti sono autorizzati ad accedere tramite ssh e hanno nomi quasi oscuri che non si trovano su elenchi di nomi utente comuni dello strumento di forza bruta (cioè, non "admin" o "apache" o "web" o " Johnny")

3. Regole restrittive del firewall (in pratica, tutto è bloccato tranne la mia porta di servizio e SSH). Ho anche limitato il ping, per evitare scansioni più grossolane (con grande dispiacere del mio partner).

4. Sul mio host web, limito l'accesso a pochi indirizzi IP specifici, ma sembra che non sia un'opzione per te. Certamente non posso farlo da solo su tutti i nostri host. Potresti anche voler esaminare il "port knocking".

5. E il mio preferito: il modulo di risposta attiva OSSEC per bloccare una serie di condizioni di forza bruta e avvisi anche su altri errori. Rileva x accessi non validi in y tempo, quindi li blocca (tramite un comando iptables firewall-drop) per un certo periodo di tempo. Mi sto bloccando da circa 12 ore per divertimento. :)

Una cosa che faccio qui per assicurarmi di non bloccare troppo della cosa sbagliata, è che in /etc/ossec.conf, ho impostato la risposta attiva su un livello elevato (che non esiste nella configurazione predefinita) e quindi passare attraverso sshd_rules.xml e impostare le regole che voglio bloccare a quel livello e modificare le soglie per blocco vs. avviso, se necessario.

Se stai usando Apache, puoi bloccare anche cose che violano le regole di Apache. Non mi blocco su questi solo a causa del problema NAT, voglio pensare a bloccare un'intera università o qualcosa del genere. :) Inoltre, puoi scrivere regole personalizzate per bloccare determinate condizioni nei file di registro, il che può essere davvero utile.