Il mio server viene costantemente attaccato [chiuso]

32

Sono abbastanza nuovo nel mondo dell'amministrazione di sistema. Di recente ho lavorato su un'applicazione e quando controllo i registri del mio server delle applicazioni, ricevo costantemente vari indirizzi IP che provano ad accedere al mio server con la forza bruta. Ecco un esempio del mio registro del server:

Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2

È qualcosa di abbastanza normale o dovrei essere preoccupato / fare qualcosa al riguardo?

ssh security

— SivaDotRender
fonte

3

Prova a cambiare il numero di porta e vedi se persiste. Se non ti stanno prendendo di mira in modo specifico, probabilmente non lo farà.

— Riccioli d'oro,

13

La soluzione migliore è disabilitare l'autenticazione con password su SSH, poiché ciò fermerà sicuramente gli attacchi di forza bruta!

— Willem,

2

possibile duplicato di Quali sono i pro / contro dei vari metodi per bloccare gli attacchi SSH a forza bruta?

— Ripristina Monica - M. Schröder,

3

@Willem: no, disabilitare l'autenticazione con password NON fermerà gli attacchi. Li renderà solo senza successo (gli aggressori non si renderanno conto che l'autenticazione della password è stata disabilitata e continuerà a provare).

— Martin Vegter,

59

Benvenuto nel meraviglioso mondo di Internet ... Hai:

mettere il tuo server dietro un firewall hardware?
attivato il firewall del software ? (nel caso in cui il firewall HW non funzioni correttamente)
indurito il tuo server?
installato rkhunter prima di metterlo online?
attivati aggiornamenti di sicurezza giornalieri automatici ?
ha cambiato la porta predefinita di ssh?
...

Ma la vera risposta è: Sì, questo è normale : BotNet Maffia può sempre utilizzare alcuni server extra mal protetti ...

— fabby
fonte

1

Preferisco non avere SSH in Internet selvaggio e selvaggio. +1

— Rui F Ribeiro,

2

Oltre a cambiare la porta predefinita per ssh, abbiamo anche il port knocking .

— Pablo Un

15

È abbastanza normale avere prove di accesso sufficienti per creare un registro di allagamento.

Cambiare le porte SSH è più una soluzione di tipo "sicurezza per oscurità", ma aiuta con il diluvio. Sottolineo che non è molto elegante; ci sono porti di fatto per i servizi per un motivo.

Come dovrebbe essere attivo di default, ma assicurati di non poter SSH nel tuo server come root. È il nome utente che è abbastanza coerente tra i server e quindi l'obiettivo principale per i tentativi di accesso con forza bruta della password. Applicare l'impostazione con la seguente riga in sshd_config:

PermitRootLogin no

Guarda anche fail2banche controlla i registri sshd per recidivi. Ad esempio, 5 accessi non riusciti in 3 minuti da un determinato IP verrebbero bloccati per 10 minuti. Ho aumentato il tempo di divieto a 24 ore per ridurre ulteriormente lo spam del registro - con successo. :)

— unperson325680
fonte

1

apt-get install fail2ban ti coprirà sostanzialmente

— Willem,

7

"Ho aumentato il tempo di divieto a 24 ore per ridurre ulteriormente lo spam del registro" Fidati di me. A meno che tu non abbia un accesso fisico al server, un giorno te ne pentirai profondamente. ;)

— Daniel,

8

Ti suggerirei di fare alcune cose:

Cambia la porta su cui ssh è in ascolto (a qualcosa di molto superiore a 1024) e assicurati di non utilizzare la versione 1 del protocollo:

/ Etc / ssh / sshd_config

# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

Installa fail2ban: monitora i file di registro e vieta temporaneamente o in modo permanente gli indirizzi a rischio di errore aggiornando le regole del firewall esistenti ( iptables).
Assicurati di aver inserito nella lista bianca le tue sedi attendibili.

— pawel7318
fonte

7

Sì, sii preoccupato . Potresti non bruciarti mai, ma dovresti seguire le migliori pratiche IT. Meglio prevenire che curare.

Sono un amministratore di rete in un ospedale. È sempre una cattiva idea connettere una scatola direttamente a Internet. Quello che stai vedendo sono tutte le migliaia di scanner automatici che cercano vulnerabilità su Internet. Vedo queste e tutte le cose (scansioni delle porte, vari test di vulnerabilità noti) per tutti i tipi di software (ssh, telnet, ftp, ecc.) Visualizzati nella nostra casella ID La
tua macchina dovrebbe essere dietro una soluzione firewall / NAT e dovresti solo porta le porte richieste su Internet (80, 443 ecc.). È relativamente facile da fare.
Avere qualcosa che puoi usare per managemnt (SSH telnet) è una cattiva idea di dover affrontare Internet perché se - per qualsiasi motivo - c'è un bug nel software SSH / telnet su quel server, il bot automatizzato lo rileverà in un batter d'occhio e sarai fregato. I bug nel software si verificano continuamente e può volerci un po 'di tempo prima che una patch venga rilasciata o che ti ricordi di patcharla.

Se è necessario gestire in remoto, cercare di configurare qualcosa come una soluzione VPN o se si utilizza Windows, impostare il gateway di servizi terminal per il desktop remoto. So che puoi usare un box Linux o Windows separato con 2 schede NIC per configurare il routing e l'accesso remoto per VPN e NAT se sei solo un piccolo negozio. Altrimenti, fornitori come Cisco hanno firewall hardware / soluzioni NAT (Cisco ASA).

In breve, metti la tua macchina dietro NAT. Porta solo le porte richieste per eseguire lo scopo del servizio. Non eseguire il port forwarding dei servizi utilizzati per la gestione su Internet, ma cerca VPN per la gestione remota.

PS La modifica delle porte SSH può aiutare con il volume del registro, ma in realtà non impedisce l'accesso a SSH. Una qualsiasi delle migliaia di cercatori automatici di vulnerabilità può e farà scansioni delle porte per vedere quali porte sono in ascolto per quali servizi. Puoi farlo da solo con uno strumento chiamato nmap .

— persona
fonte

7

In realtà, una soluzione VPN non è più o meno sicura di un server SSH. Entrambi si basano sulla corretta implementazione dei protocolli crittografici e sulla corretta configurazione dei servizi. Con mezzi diversi direi che forniscono esattamente lo stesso livello di sicurezza. Quindi, se ti capisco bene, metti un SSH dietro una VPN, quindi sì, è un livello più sicuro.

— Lgeorget,

Sì, hai ragione, è quello che volevo dire, usa vpn per far passare il firewall / nat poi ssh nel server

— persona

1

In seguito, la maggior parte delle configurazioni VPN passa attraverso diversi livelli di autenticazione client e fornisce un unico punto in cui il traffico esterno può raggiungere la rete interna. Contro avere molti nodi. I concentratori di VPN non sono di solito obiettivi interessanti in sé e per sé, rispetto al server che probabilmente ospita l' sshdistanza. Un jumpbox ssh può essere sicuro come la maggior parte delle configurazioni VPN, ma in generale non è così che funziona.

— Bratchley,

5

È possibile configurare il firewall interno del kernel da iptables . In modo che solo alcune macchine possano inviare ssh al tuo server e lasciare cadere altri pacchetti IP. Vedi man iptablesper maggiori informazioni.

Ad esempio, se 192.168.1.67 è l'host da cui ssh, quindi sul tipo di server:

sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save

— CFF
fonte

2

Tieni presente che verrai gravemente fregato se la gestione remota è l'unica opzione. La maggior parte degli IP sono solo semi-permanenti. Cambia l'hardware e verrai masterizzato.

— Albero

3

Hai davvero bisogno del tuo server su Internet? Se vuoi davvero averlo su Internet, assicurati che sia sicuro prima di metterlo lì.

Cambiare la porta è solo sicurezza attraverso l'oscurità. Se l'attaccante è più sofisticato della semplice esecuzione di script, non sarà di aiuto.

Alcune cose già menzionate che raccomando anche:

Sono d'accordo con Fail2Ban e una corretta configurazione terrà a bada gli script e gli hacker più sofisticati.
L'impostazione di PermitRootLogin su no è un must.
Configura un firewall. Di solito modifico semplicemente le regole di iptables, ma funzionerà anche qualcosa come UFW o firehol.

Sono appena entrato in questa community perché ci sono due cose che non credo siano state affrontate in modo adeguato.

Nel firewall config block / disabilita assolutamente tutto ciò che non è completamente necessario. Prima di aprire le porte, chiediti "Ho davvero bisogno di questo servizio da Internet?" Ogni porta / servizio che apri diventa un altro potenziale vettore che qualcuno potrebbe essere in grado di sfruttare. Se in quel servizio è presente un bug che consente loro di ottenere l'accesso root al server, potrebbero essere in grado di accedere a tutto ciò che contiene. La tua sicurezza è forte solo come l'anello più debole.
Ora per l'ultima cosa e probabilmente il più importante. Gli script che hai visto tentando di accedere a ssh potrebbero essere in grado di indovinare la tua password nel tempo. Fail2Ban li rallenterà molto, ma potrebbero ancora indovinarlo. In tal caso, si desidera un'autenticazione a 2 fattori sui servizi accessibili. Per questo consiglio un account gratuito con Duo Security. https://www.duosecurity.com/docs/duounix

— moriab
fonte

1

La modifica della porta ha il vantaggio di ripulire i file di registro: poiché gli script kiddie per lo più non attaccano le porte non predefinite, sai che qualsiasi voce di registro rappresenta una grave minaccia.

— Segna il

Anche cambiare la porta non è del tutto zero contro una vera minaccia. Un dosso non è molto simile a un muro, ma è comunque un dosso, e ci sono modi per farlo diventare un dosso più grande. Inoltre, mentre l'autenticazione a 2 fattori è sicuramente una buona idea da usare ogni volta che è possibile e dovrebbe essere quasi sempre possibile, ci sono casi limite. Se c'è un periodo di tempo minimo specifico, puoi essere abbastanza sicuro che Fail2Ban li ritarderà, quindi semplicemente cambiando la tua password più spesso di così, li costringerai a ricominciare ripetutamente e non finire mai.

— Matthew Najmon,

2

Un altro esempio di risposta a @cff, se si intende vietare qualsiasi "tentativo" successivo sul server SSH:

sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save

Questa connessione "tag" tenta e se si verificano più di 4 in 600s (10mn), l'origine viene "vietata". Usa questa invece della soluzione @cff perché è più sicura (se ti blocchi, attendi 10 minuti e riprova).

— xryl669
fonte