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:
È 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.
-m conditioninvece match iptables.
fail2ban può essere d'aiuto bloccando gli indirizzi IP con troppi tentativi di accesso non riusciti.
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.
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.
Potresti voler guardare anche denyhosts .
Cordiali saluti: OpenSSH 6.7 elimina il supporto per tcpwrappers , il che significa che denyhosts probabilmente non è la soluzione per le nuove installazioni.
Fatevi un favore e disabilitate il login con password. Utilizza esclusivamente chiavi di autenticazione (ad esempio google ssh-keygen - Esempio: http://www.puddingonline.com/~dave/publications/SSH-with-Keys-HOWTO/document/html/SSH-with-Keys-HOWTO-4 .html ) Il tuo server sarà più sicuro, ti collegherai ad esso più comodamente (controlla ssh-agent, ssh-add, keychain) e non sarai più vittima di attacchi di forza bruta ssh.
un'altra soluzione è semplicemente spostare ssh su un'altra porta. questi vermi sono piuttosto stupidi.
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 .
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.
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.
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.
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).
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 :)
Un'altra opzione simile a DenyHosts è sshutout http://www.techfinesse.com/sshutout/sshutout.html