Centinaia di accessi ssh non riusciti


81

Ogni notte ricevo centinaia, a volte migliaia, di accessi ssh non riusciti sul mio server RedHat 4. Per motivi di firewall da siti remoti, devo eseguire sulla porta standard. C'è qualcosa che dovrei fare per bloccare questo. Ho notato che molti provengono dallo stesso indirizzo IP. Non dovrebbe fermarli dopo un po '?

Risposte:


67

È possibile utilizzare iptables per limitare la velocità delle nuove connessioni in entrata alla porta SSH. Dovrei vedere la tua intera configurazione di iptables per darti una soluzione chiavi in ​​mano, ma sostanzialmente stai parlando di aggiungere regole come:

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP 
iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT 

Queste regole presuppongono che tu accetti connessioni STABILITE in precedenza nella tabella (in modo che solo le nuove connessioni colpiranno queste regole). Le nuove connessioni SSH colpiranno queste regole e saranno contrassegnate. In 60 secondi, 5 tentativi da un singolo indirizzo IP causeranno la caduta di nuove connessioni in entrata da quell'IP.

Questo ha funzionato bene per me.

Modifica: preferisco questo metodo a "fail2ban" perché non è necessario installare alcun software aggiuntivo, e avviene totalmente in modalità kernel. Non gestisce l'analisi dei file di registro come "fail2ban", ma se il tuo problema riguarda solo SSH non utilizzerei una modalità utente che richiede l'installazione di software ed è più complessa.


1
Mi piace questa soluzione e sto programmando di metterla in atto stasera, una volta che avrò spento gli incendi di oggi.
MattMcKnight,

2
Rallenta gli attacchi e lo consiglio vivamente, ma poiché ci sono botnet di scansione non distribuite là fuori, non è una panacea. Ci saranno ancora accessi non validi da botnet che eseguono scansioni distribuite contro di te. Non c'è davvero molto che puoi fare al riguardo, a parte una sorta di schema di "port knocking" per portare in remoto la porta SSH quando vuoi entrare.
Evan Anderson,

1
+1 per il suggerimento "port knocking" di @ Evan. Alcune informazioni: linux.die.net/man/1/knockd . Ma non farlo nel modo della pagina man (cioè aggiungendo / eliminando le regole di iptables), ma usa -m conditioninvece match iptables.
pepoluan,

2
non hai bisogno di --dport 22 in queste regole in modo che vengano applicate solo per il traffico ssh?
Clime

2
@clime - Sì. Difficile credere che questo sia stato qui 2 anni e mezzo e nessuno se ne è accorto! Buona pesca.
Evan Anderson,


25

Ti consiglierei di usare una porta non standard per SSH se puoi (es. Porta 10222) ma dato che hai menzionato non puoi farlo raccomanderei di usare qualcosa come DenyHosts.

http://denyhosts.sourceforge.net/

Ottimo pacchetto, facile da installare e configurare.


6
Non so perché la gente voti questo; SSH si trova su una porta standard 22. Ciò significa che quando ci si trova su una rete straniera, non si fa affidamento sul fatto che abbiano una porta non standard aperta attraverso il firewall in uscita. La vera soluzione a questo problema è documentata sopra, o limitare il numero di connessioni ripetute tramite il firewall in entrata o disattivare gli accessi con password.
Andrew Taylor,

1
OpenSSH 6.7 elimina il supporto di tcpwrappers , che è quello che utilizza denyhosts.
Zoredache,

15

Mentre può essere bello poter accedere al tuo sistema da posizioni arbitrarie su Internet, ci sono sistemi automatici di attacco password che si bloccheranno su una porta ssh aperta e applicheranno vari account joe e attacchi al dizionario contro il tuo sistema. Questo può essere aggravante da leggere nel riepilogo del registro notturno ed è uno spreco della larghezza di banda.

Se si dispone di un server Web sullo stesso sistema, è possibile utilizzare wrapper php e tcp per limitare il traffico in entrata ssh a sistemi noti, oltre a fornire una chiave back-door per consentire l'accesso da sistemi arbitrari su Internet.

Ecco come lo fai:

negare tutte le connessioni ssh in /etc/hosts.deny:

# /etc/hosts.deny fragment
sshd:  all

Consenti sistemi noti tramite IP in /etc/hosts.allow, oltre ad aggiungere un file per l'accesso temporaneo:

# /etc/hosts.allow fragment
sshd:  10.0.10.2     # some system
sshd:  172.99.99.99  # some other system
sshd:  /etc/hosts.allow.temporary-sshd-access

Crea un file php nel tuo server web e assegnagli un nome non ovvio come my-sshd-access.php:

<?php
function get_ip()
{
    return getenv("REMOTE_ADDR"); 
}

?>

<?php
$out='/etc/hosts.allow.temporary-sshd-access';
$log='/var/log/sshd-access-addition-log';

print "Was:";
readfile($out);
print "<br>";
$ip=get_ip();
$fp=fopen($out,"w");
fputs($fp,$ip);
fclose($fp);

$lfp=fopen($log,"a");
fputs($lfp,$ip);
fputs($lfp,"n");
fclose($lfp);

print "Wrote: ";
readfile($out);
?>

Perdonate il codice php - l'ho fatto scorrere da qualche altra parte, quindi probabilmente potrebbe sopportare di essere ripulito un sacco. Tutto ciò che fa è aggiungere l'indirizzo IP del sistema accedendo al file /etc/hosts.allow.temporary-sshd-access, che viene letto da sshd (a causa della sua inclusione da /etc/hosts.allow) al momento della connessione .

Ora, quando ti trovi in ​​un sistema arbitrario sul web e vuoi usare ssh su questo sistema, usa prima un browser web e premi questo file (o usa wget o equivalenti):

$ wget http://your.system.name/my-sshd-access.php

Ora dovresti essere in grado di accedere al tuo sistema. Se questo è un posto in cui verrai spesso inviato, sarebbe banale leggere il contenuto del file /etc/hosts.allow.temporary-sshd-access e aggiungere in modo permanente l'indirizzo IP a / etc / hosts. permettere.


Per renderlo più sicuro, esegui questa pagina su https.
Robert Munteanu,

Se si modifica lo script in modo che non generi il contenuto del file "Indirizzo IP temporaneo consentito", non ci sarà nulla per un aspirante sniffer. Quindi puoi eseguirlo su http anziché su https.
Barry Brown,

L '"indirizzo IP temporaneo consentito" è sempre quello del richiedente (ovvero il tuo). Non penso sia importante in un modo o nell'altro. Https significa che l'URL richiesto è crittografato, il che significa che non è banale annusarlo via cavo.
David Mackintosh,

Questo non funzionerà se ci si trova su una rete che esegue il proxy delle connessioni HTTP ma il percorso diretto a Internet avviene tramite un altro ingresso.
Andrew Taylor,

OpenSSH 6.7 elimina il supporto di tcpwrappers , che è ciò che viene utilizzato nella risposta.
Zoredache,



2

un'altra soluzione è semplicemente spostare ssh su un'altra porta. questi vermi sono piuttosto stupidi.


3
Il poster originale diceva che doveva funzionare sulla porta standard.
kbyrd,

1
scusate, devo leggere le domande più attentamente :)
disserman

1
Devo essere d'accordo ... Ho il mio SSH in esecuzione su porte "alternative" e fa un MONDO di differenza nei registri. I worm sono intelligenti come un mattone, quindi funzionano bene contro gli script di automazione muti; non così bene contro gli aggressori umani. Tuttavia, i tronchi hanno il suono benedetto del silenzio in loro ...
Avery Payne,

..non è che i robot siano "stupidi", è che sono progettati per cercare frutta a bassa quota. Quindi spostare la porta SSH è nello stile di ... mantenere i tuoi frutti da terra.
elrobis,

2

Un'altra opzione potrebbe essere quella di richiedere che tutte le connessioni SSH siano verificate da un certificato e che le password vengano eliminate del tutto.

Uso Denyhosts, ma ho scoperto che mi collegavo regolarmente in remoto da una manciata di posti, quindi ho bloccato tutte le connessioni della porta 22 tranne da qualsiasi altra parte e uso il port knocking in modo da poter connettermi da qualsiasi luogo con il mio laptop se devo .


1

Qualsiasi soluzione che implichi il blocco automatico degli IP dopo più guasti presenta il rischio di attacchi Denial of Service. Finché esiste una buona politica di password per ridurre l'efficacia della forza bruta o degli attacchi del dizionario, non mi preoccuperei troppo di loro.

Se limiti gli utenti / i gruppi solo a quelli a cui dovrebbe essere permesso di accedere in primo luogo e disabilitare l'accesso come root, dovresti essere più che abbastanza sicuro. E, se ciò non è sufficiente, esiste sempre un'autenticazione basata su chiave.


1

Onestamente, se devi eseguire SSH (e sulla porta 22), non puoi evitarli. Se devi accettare le password, sei ancora peggio.

La soluzione migliore è configurare il software di analisi dei log per escludere i log SSH. Quindi eseguire un'istanza separata per esaminare solo i registri SSH e utilizzare procmail per filtrare i tentativi falliti. È anche possibile scrivere script per controllare gli accessi riusciti da indirizzi IP con più tentativi falliti.

Non c'è modo di impedire alle persone di sondare il tuo server SSH. Denyhosts, fail2ban e l'esempio iptables funzioneranno fino a un certo punto, ma con l'ulteriore pericolo di bloccare accidentalmente utenti legittimi. Il metodo migliore è risucchiarlo e provare ad automatizzare il processo di analisi dei registri per ridurre il tempo necessario a pensarci.


0

Quando dici che stai fallendo shh accedi ai tentativi sul tuo server Red Hat, che tipo di firewall si trova dietro e quante persone hanno bisogno di inserirci. Suggerisco che, se è possibile, si desidera limitare i tentativi di firewall prima che si avvicinino ovunque al proprio server.

Se è possibile limitare l'intervallo di indirizzi IP che hanno legittimamente bisogno di accesso, si dovrebbe essere in grado di impostare un elenco di accesso sul firewall. Se riesci a limitare il traffico sul firewall, ti suggerirei di esaminare i sistemi di intrusione di rete, in quanto sembra che il tuo server sia preso di mira da qualcosa.


0

La maggior parte dei webhost utilizza APF + BFD per bloccare gli accessi SSH non riusciti. Al giorno d'oggi c'è CSF (Configserver firewall) che include uno strumento chiamato LFD che fa la stessa cosa, e altro ancora, inclusi gli IP di blocco da alcuni paesi a cui non vuoi accedere al tuo server (ad esempio Corea, Cina, ecc., Dove il 99% delle mie sonde SSH sembra provenire da).



0

Se devi risolvere questo problema su più di un host, ti consigliamo di dare un'occhiata a OSSEC: http://www.ossec.net/main/ossec-architecture

Ciò consentirà di configurare più agenti da una posizione centralizzata per rispondere automaticamente agli attacchi di forza bruta (insieme a qualsiasi altro modello che è possibile estrarre dai registri).

Software molto bello :)


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.