È normale ricevere centinaia di tentativi di intrusione al giorno?

Ho appena controllato il mio server /var/log/auth.loge ho scoperto che ricevo più di 500 notifiche di tentativi di immissione / password non riuscite al giorno! Il mio sito è piccolo e il suo URL è oscuro. È normale? Dovrei prendere delle misure?

Nell'internet di oggi è abbastanza normale purtroppo. Esistono orde di botnet che tentano di accedere a ciascun server che trovano in intere reti IP. In genere, usano semplici attacchi da dizionario su account noti (come account root o determinati account delle applicazioni).

I target di attacco non vengono trovati tramite voci di Google o DNS, ma gli aggressori provano semplicemente tutti gli indirizzi IP in una determinata sottorete (ad es. Di società di hosting di server root noti). Quindi non importa che il tuo URL (quindi la voce DNS) sia piuttosto oscuro.

Ecco perché è così importante:

• non consentire il root-login in SSH ( howto )
• usa password complesse ovunque (anche nelle tue applicazioni web)
• per SSH, utilizzare l'autenticazione con chiave pubblica se possibile e disabilitare completamente password-auth ( howto )

Inoltre, è possibile installare fail2ban che eseguirà la scansione del registro automatico e se rileva un certo numero di tentativi di accesso non riusciti da un IP, procederà ad aggiungere tale IP a /etc/hosts.denyo iptables / netfilter per bloccare l'attaccante per alcuni minuti.

Oltre agli attacchi SSH, sta diventando comune anche scansionare il tuo server web per applicazioni Web vulnerabili (alcune app di blog, CMS, phpmyadmin, ecc.). Quindi assicurati di mantenerli aggiornati e configurati in modo sicuro!

Qualche 100 va bene ... Il mese scorso ho scoperto che uno dei miei server ha avuto 40.000 tentativi falliti. Ho affrontato il problema di disegnarli: Mappa

Dopo aver modificato la porta SSH e implementato il Port Knocking, il numero è sceso a 0 :-)

Io per primo uso un "tarpit" oltre a consentire solo l'autenticazione con chiave pubblica e la disabilitazione degli accessi root.

In netfilterc'è un recentmodulo, che puoi usare con ( INPUTcatena):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Ciò che fa è che ogni tentativo di connettersi alla porta 22 è elencato dal recentmodulo con IP e alcune altre cose sotto il nome "tarpit" (se sei curioso, guarda /proc/net/xt_recent/tarpit). Ovviamente puoi usare altri nomi.

Per elencare o eliminare gli IP utilizzare:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Questa velocità limita i tentativi a 5 in 300 secondi. Si noti che gli utenti con una connessione esistente non sono infastiditi da quel limite, perché hanno già una connessione stabilita e sono autorizzati a crearne di più (anche al di sopra del limite di velocità).

Regola le regole a tuo piacimento, ma assicurati che vengano aggiunte in quell'ordine (cioè quando aggiungi e poi usale in questo ordine, quando le inserisci poi nell'ordine inverso).

Questo riduce immensamente il rumore. Fornisce inoltre una sicurezza effettiva (contro la forza bruta) a differenza della sicurezza percepita del cambio di porta. Tuttavia, consiglierei comunque di cambiare la porta se è fattibile nel tuo ambiente. Ridurrà molto anche il livello di rumore ...

Puoi ancora combinarlo con fail2ban, anche se ho funzionato bene senza di esso e solo le regole sopra.

MODIFICARE:

È possibile bloccare te stesso mentre lo fai, quindi puoi aggiungere qualcosa come il seguente che ti consente di eliminare il bando bussando su una porta particolare:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

Potresti implementare fail2ban o metodi simili come bloccare SSH sul tuo IP. Purtroppo i bot tentano continuamente di accedere bruteforce quindi è abbastanza normale, devi assicurarti di avere una buona password.

Sì . È abbastanza normale al giorno d'oggi.

Se possibile, utilizzare solo l'autenticazione con chiave pubblica per scopi amministrativi. Genera una chiave privata sulla tua workstation:

$ ssh-keygen -t dsa

Copia il contenuto di ~ / .ssh / id_dsa.pub sui tuoi server ~ / .ssh / authorized_keys (e /root/.ssh/authorized_keys, se hai bisogno di accedere direttamente alla radice).

Configura i tuoi server / etc / ssh / sshd_config per accettare solo l'autenticazione con chiave pubblica:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Se hai troppi server, puoi usare Puppet per eseguire loro le chiavi pubbliche e le configurazioni.

Cerca in Denyhosts e fail2ban per bloccare ripetuti tentativi di accesso a SSH e vedi Snort se hai bisogno di IDS / IPS completi.

usa http://denyhosts.sourceforge.net/

e sì, è necessario utilizzare l'autenticazione con chiave pubblica e disabilitare l'autenticazione password.

I tentativi sono meccanizzati, quindi i numeri sembrano OK (sì, sono alti rispetto ad alcuni siti e bassi rispetto ad altri). Dovresti prendere le misure che normalmente devi: Considera i tuoi siti come obiettivi di attacco ogni giorno, anche quando non rilevi un attacco; non rilevare un attacco, non significa che non esiste .

Direi che solo 500 sono bassi.

In un precedente datore di lavoro, uno dei ricercatori sulla sicurezza informatica ha definito il flusso costante di irruzioni "l'equivalente di Internet del rumore cosmico ". Lo descrisse come un normale flusso continuo di traffico dannoso che cercava sistemi su Internet e sfruttava automaticamente gli script per tentare di dirottare il sistema. Reti bot e altri sistemi dannosi scansionavano e scansionavano continuamente Internet alla ricerca di sistemi vulnerabili, proprio come SETI.

Sì,

questo è comune, ma ciò non significa che non dovresti combattere la buona battaglia. Ecco alcuni passaggi su come rendere il tuo server più sicuro.

Evita gli indirizzi IP associati al DNS

È possibile ridurre notevolmente questo numero in ambienti condivisi o di colocation disabilitando l'accesso SSH su tutti gli indirizzi IP associati ai nomi di dominio. Gli indirizzi IP non di dominio non elencati riceveranno meno di questo tipo di traffico, quindi acquista un IP non elencato e usa questo IP solo per l'accesso SSH.

Utilizzare una VPN per tutto l'accesso SSH

Se ti trovi in ​​un ambiente in cui puoi implementare IPsec / VPN su una rete privata all'interno del tuo ambiente server, questo è l'ideale. Disabilita tutti gli accessi a Internet SSH, assicurati di avere una soluzione di luci integrata. Configura la tua VPN e consenti l'accesso SSH solo dalla tua VPN.

Implementare le regole dell'indirizzo IP per l'accesso SSH

Se la VLAN non è un'opzione, configura il router o le regole del firewall per consentire le connessioni SSH solo da un intervallo di indirizzi IP noto.

Se segui questi passaggi, dormirai molto più facilmente nella notte sapendo che qualcuno dovrebbe compromettere la rete delle aziende di hosting per ottenere l'accesso al server tramite SSH.

Abbastanza normale vedere centinaia di connessioni SSH fallite.

Se hai l'opzione, cambio semplicemente la mia porta SSH in qualcosa di non standard. Non necessariamente rende il tuo server più sicuro, ma pulisce di sicuro i log (e ti consente di vedere chiunque stia deliberatamente tentando di entrare!)

Oltre a utilizzare un meccanismo di blocco automatico come fail2ban hai un'altra opzione: in realtà contatta l'indirizzo dell'abuso ISP dell'attaccante. Può sembrare del tutto inutile, ma nel caso dello sceneggiatore il loro ISP è più che disposto ad agire su di loro.

Per trovare l'indirizzo di abuso, inizia con arin.net e cerca l'indirizzo IP usando whois. Potresti essere reindirizzato a un altro registro regionale, ma alla fine puoi trovare l'ISP responsabile per il blocco IP che contiene l'indirizzo. Cerca l'indirizzo abuse @ o invia semplicemente il contatto tecnico.

Invia loro un messaggio educato con le voci del file di registro pertinenti (assicurarsi di rimuovere qualsiasi informazione privata) e chiedere loro di agire contro l'host incriminato.

Consiglierei di non utilizzare fail2ban ma di eseguire SSH (e altri) su una porta non standard. Non credo nella sicurezza per oscurità, ma penso che questo sia un modo eccellente per ridurre il rumore nei tuoi registri.

Gli accessi non riusciti su porte non standard saranno pochi e lontani tra loro e possono anche indicare attacchi più mirati.

Potresti anche fare un passo avanti e installare un honeypot SSH come Kippo per "far entrare" i bruteforcer e vedere cosa farebbero, data la possibilità.

Sì, è normale Cosa dico ai clienti nella tua situazione con piccoli siti Web.

Preparati sempre ad essere violato.

Avere una copia del tuo sito Web su un server di sviluppo. Questo può essere il tuo desktop di Windows usando XAMPP che puoi ottenere gratuitamente.

Apporta SEMPRE modifiche al tuo server di sviluppo, quindi caricale sul tuo sito web live. Se si tratta di un CMS come Wordpress, crea i tuoi post sul server dev quindi copiali e incollali nel server live.

Non scaricare MAI nulla dal tuo sito Web dal vivo sul tuo server di sviluppo.

Monitora regolarmente le tue pagine web per eventuali modifiche che non hai apportato. In particolare, collegamenti nascosti a farmaci o prodotti di "potenziamento". Puoi trovare molti componenti aggiuntivi del browser e programmi che lo faranno per te.

Se sei compromesso. Avvisa il tuo host, elimina tutto, cambia tutte le password e carica il tuo server dev pulito sul server web ora vuoto. Collabora con il tuo host per prevenire una ricorrenza.

Non è necessario un team di sicurezza per un sito di piccole dimensioni. Questo è ciò che il tuo host dovrebbe fornire. In caso contrario, ottenere un altro host che è molto più facile da fare quando si dispone di un server dev piuttosto che provare a spostare il server live.

Spero che sia di aiuto.

Un altro modo per fermarlo (dato che personalmente non mi piace spostare la porta SSH): decidi se sei in grado di elencare tutte le reti da cui vorrai accedere, quindi consenti solo a queste di accedere alla tua porta SSH.

Le voci WHOIS degli ISP locali mi hanno aiutato a ridurre gli attacchi a 1-2 tentativi di accesso al mese (allora era circa 1k / giorno). Ho rilevato quelli usando ancora denyhosts .

Oltre agli altri eccellenti suggerimenti che hai già ricevuto, mi piace anche utilizzare la direttiva AllowUsers se appropriato per il server specificato. Ciò consente solo agli utenti specificati di accedere tramite SSH, il che riduce notevolmente la possibilità di ottenere l'accesso tramite un account guest / servizio / sistema configurato in modo non sicuro.

Esempio:

AllowUsers admin jsmith jdoe

L'opzione AllowUsers specifica e controlla quali utenti possono accedere ai servizi ssh. È possibile specificare più utenti, separati da spazi.

Sì, è normale Puoi :

• Riduci l'opportunità di attaccare usando fwknop

Fwknop è una delle migliori implementazioni port knock perché non è spoofable e in realtà autentica piuttosto che autorizzare una connessione.

• Puoi cambiare la porta utilizzata da Openssh ma non stai migliorando la sicurezza.

• Fortifica l'autenticazione ssh utilizzando Google-Authenticator o Wiki

Ciò proteggerà gli attacchi basati su password e la possibilità di un determinato aggressore / attacco mirato che comprometta la macchina di amministrazione e ruba la combinazione di chiavi ssh e password.

Basta guardare l'ultima comp pwn2own per vedere quanto è facile per un attaccante esperto compromettere la tua casella di amministrazione completamente patchata.

Purtroppo questo è abbastanza normale. Dovresti considerare di aggiungere qualcosa come fail2ban al tuo sistema per rilevare automaticamente e vietare gli aggressori. Se non lo fai già, dovresti anche considerare di usare solo ssh con le chiavi pubbliche e non consentire l'accesso root su ssh. Se usi ftp per trasferire file sul sistema, considera invece l'uso di scp / sftp.

Ho implementato il port knocking e ho alcune sonde al giorno. Non hanno una connessione, quindi vanno via. Registro e riporto tutti gli accessi alle porte interessate.

Ho anche eseguito fail2ban con Shorewall come firewall per inserire temporaneamente nella lista nera gli aggressori persistenti.

Se non è necessario l'accesso a Internet su SSH, disabilitarlo. Se si dispone di alcuni indirizzi noti che richiedono l'accesso remoto, limitare l'accesso a tali indirizzi.

Può anche essere utile limitare l'accesso alle chiavi autorizzate.

Uso pam_abltemporaneamente nella lista nera i bruti forzati, e funziona benissimo. Penso che sia meglio avere l'autorizzazione in PAM usando il proprio database piuttosto che dipendere da hosts.denyo iptables.

Un altro vantaggio è che pam_ablnon dipende dalla scansione dei file di registro.

È completamente normale in questi giorni.
È possibile impostare il limite di "burst" sul firewall per le nuove connessioni in entrata sulla porta SSH,
oppure installare uno dei numerosi parser di log a'la fail2ban o modificare la porta SSH;).

L'ultimo è il più semplice. Su macchine con carichi pesanti tali tentativi di intrusione possono influire negativamente sull'intero sistema.

-
Saluti,
Robert

Sì è normale

Ho appena cambiato la porta ssh rispetto allo standard 22. Il mio server, le mie regole :) basta modificare / etc / ssh / sshd_config, cambiare la porta e riavviare il servizio. L'unico lato negativo è che devi ricordare di aggiungere quella porta alla configurazione per ogni client ssh che usi.

• Disabilita il login root (in ogni sistema Linux esiste un utente root in modo che i robot possano facilmente indovinare il nome utente). Dopo aver effettuato l'accesso come utente normale, puoi passare al root tramite su o sudo.

• cambia la porta predefinita da 22

• Consentire l'accesso ssh solo da ip noti

• Utilizzare una password alfanumerica numerica per l'utente con accesso ssh