Come possiamo limitare l'impatto delle sonde ssh?

13

Il mio server web è costantemente attaccato da vari indirizzi IP. Provano cinque password e poi cambiano l'indirizzo IP.

Ho eseguito vari blocchi come l'uso di ssh-key e non consentire le password e non consentire l'accesso remoto alla radice.

C'è qualcosa che posso fare per sbarazzarmi di questi tentativi di attacco? In caso contrario, ci sono difese specifiche che dovrei mettere in piedi?

ssh security

— JW01
fonte

1

Segnalazione per una migrazione a security.se dove è un po 'più in tema

— Rory Alsop,

1

@Rory C'è una differenza tra "un po 'più sull'argomento qualcun altro" e "fuori argomento qui" - sembra abbastanza chiaramente sull'argomento qui

— Michael Mrozek

Nessun problema @Michael. Ho avuto un rumore metallico da Gilles per venire a vederlo perché probabilmente era offtopico qui.

— Rory Alsop,

@Rory Ok, glielo chiederò; di solito è abbastanza bravo a convincermi di qualcosa che penso sia {off, on} l'argomento è in realtà {on, off} argomento

— Michael Mrozek

1

La mia domanda sembra essere stata cambiata oltre il riconoscimento. Nella mia domanda originale stavo davvero cercando di scoprire se era comune per ogni sito sperimentare attacchi di forza bruta - cioè è un fatto della vita. A questo ha risposto Matteo con "È davvero un dato di fatto". La seconda parte della domanda era chiedermi cosa avrei potuto fare per fermare attivamente questi attacchi a parte difendere . Questa sarebbe stata una questione secondaria rilevante se solo alcuni siti avessero subito attacchi di forza bruta. Bruce rispose con la sua idea di tarpit. Non ho davvero chiesto consigli difensivi.

— JW01,

14

È davvero un dato di fatto. Puoi installare strumenti per filtrare gli host che ti attaccano dopo un paio di tentativi falliti.

DenyHosts analizza i file di registro e aggiunge automaticamente gli aggressori al /etc/hosts.denyfile.

Controlla la documentazione su come configurarlo per le tue esigenze.

Aggiornamento : alcuni punti importanti suggeriti nei commenti

assicurati di configurare correttamente gli strumenti come DenyHosts poiché potresti bloccarti (ad esempio, puoi configurare una macchina o una rete che non viene mai filtrata)
DenyHosts non aumenta la sicurezza del sistema: filtra solo gli attacchi a livello IP (potrebbe ridurre il carico su macchine di piccole dimensioni e ridurre le dimensioni dei file di registro, ma niente di più)

— Matteo
fonte

1

Aaah. Stavo iniziando a pensare di essere speciale. Grazie per avermi chiarito.

— JW01,

Estendendo su Matteo, la tua domanda ha quasi una risposta esattamente refs Q1.3 denyhosts.sourceforge.net/faq.html#1_0

— whoami,

@whoami Grazie per il link, un bel riassunto. Sebbene una cosa che mi viene sempre in mente quando vedo l' uso di un diverso suggerimento di porta è " come fai a sapere che la porta alternativa che scegli non è già utilizzata da qualcos'altro? '

— JW01,

1

Fai attenzione con DenyHosts e strumenti simili, poiché introducono ulteriore complessità, cioè possono creare problemi di sicurezza da soli, cfr. il secondo commento su unix.stackexchange.com/questions/2942/…

— maxschlepzig

1

Fai anche attenzione con DenyHosts perché potresti bloccarti fuori dalla tua macchina. Un semplice apt-get install denyhostsmi ha bloccato fuori dalla mia macchina.

— Naftuli Kay,

15

Ho seguito queste istruzioni per aggiungere un ritardo di 7 secondi a ogni tentativo di accesso SSH con password errata. Ho trasformato la mia sshd in un "tarpit" per gli scanner a forza bruta.

Dovrei anche aggiungere che ho modificato il mio registro tarsh sshd le password non riuscite. Questo potrebbe non essere del tutto etico, in quanto dà all'utente root uno sguardo a quali utenti normali digitano erroneamente le loro password, ma dato che sono l'unico "vero" utente, immagino che vada bene.

Non l'ho eseguito su una porta non standard, in quanto l'aspetto "tarpit" non perderebbe tempo a nessuno.

— Bruce Ediger
fonte

Inoltre, utilizzare una porta non standard e utilizzare le chiavi anziché le password. Quindi non hanno quasi alcuna speranza (a condizione che non riescano a trovare le chiavi, che dovrebbero comunque essere tutte dotate di password).

— Callum Rogers,

Questa è una bella risposta perché ha un approccio un po '"offensivo" piuttosto che essere puramente "difensivo", che secondo me aggiunge morale.

— JW01,

9

Se solo un piccolo numero di persone ha bisogno di SSH sul sistema, considera di spostare SSH su una porta non standard (ad es. 6422, 8080, ecc.) Che da solo ridurrà notevolmente il numero di tentativi di accesso (e possibilmente ti proteggerà da alcuni senza patch Worm basato su exploit SSH, ad esempio).

— Cuneo
fonte

3

+1 Piuttosto utile in quanto limita il fastidio, ma non confonderlo con una misura di sicurezza - questo è un equivalente più vicino di una porta dello schermo contro le zanzare che di un blocco di sicurezza.

— Piskvor lasciò l'edificio il

1

+1 Questo è anche un risparmio sulle risorse del server.

— Xeoncross,

6

Concordo con la risposta di @Matteo; quello che stai vedendo sono essenzialmente migliaia di sistemi zombi che eseguono un attacco di forza bruta distribuito sul tuo server perché c'è un sito Web in esecuzione su di esso, il che significa che potrebbero esserci utenti che potrebbero avere un account di accesso che potrebbe essere indovinato sforzo minimo da parte del kiddie dello script - ha un programma che ordina alle migliaia di zombi di fare i tentativi di forza bruta su alcune centinaia di host di siti Web alla volta e solo di compilare un elenco dei ritorni riusciti.

Allo stesso modo, a volte potresti vedere molte permuizioni di "http://your.web.host/phpmyadmin/" nei tuoi /var/log/apache2/access.logfile; si tratta di scansioni automatizzate per i modi più comuni di impostazione di PHPMyAdmin e tenteranno una serie di exploit noti se ne viene trovato uno (questo, per inciso, è il motivo per cui ho iniziato a dire ai clienti di utilizzare il sito PMA che ho impostato personalmente e tieniti aggiornato anziché installare la propria versione e dimenticando di tenerlo aggiornato, ma ora siamo fuori su una tangente).

A parte l'invio del comando originale, non gli costa nemmeno tempo o larghezza di banda; è fuoco e dimentica.

Un altro bit molto utile di software per situazioni come questa è fail2ban , che utilizza iptables per bloccare i tentativi di connessione dopo più accessi chiaramente falsi o altri tentativi di exploit.

— Shadur
fonte

4

Prova a configurare Fail2ban . Fornisce un modo molto flessibile per cercare tentativi falliti e ha modelli per SSH, HTTP e servizi comuni.

Fail2ban aggiornerà iptables in base alle tue azioni .. Lo adoro.

— tacca
fonte

3

Puoi usare IPTABLES per fermare il traffico senza eseguire un demone come Fail2Ban o DenyHosts.

#  Allows SSH connections (only 4 attempts by an IP every 3 minutes, drop the rest to prevent SSH attacks)
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

— Xeoncross
fonte

2

Se riesci a gestirlo, trovo che il modo migliore per gestire cose come questa sia usare una VPN. In questo modo, l'unica cosa che possono scegliere come target è la VPN. Non dovrebbero esserci servizi aperti al mondo in generale, ad eccezione di quelli necessari per l'accesso di "tutti", come il tuo server web. Tutto il resto dovrebbe essere bloccato dal firewall. Ora l'unica cosa che devi davvero preoccuparti di proteggere è la tua VPN. Se puoi, ottieni un IP statico per i computer da cui gestisci i tuoi server e blocca la tua VPN fino a quell'indirizzo IP specifico. Questo è davvero l'unico modo per impedire alle persone di provare a forzare le password.

— Kibbee
fonte

0

Sshguard funziona alla grande. Lo sto usando insieme a iptables.

— Alessandro
fonte