Perché lasciare un SSH con password su Internet è così brutto?

Why is this so bad?

Poiché ci sono un sacco di robot che eseguono la scansione del web per le porte aperte e tentano di accedere, una volta che un bot dello scanner trova una porta SSH aperta, potrebbe essere accodata per un altro bot (o botnet) per forzare la password. Uno dei rischi qui è che alla fine potrebbero riuscire a capire la password e assumere il controllo del server.

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

Avere una password lunga è una tecnica di attenuazione, tuttavia le risorse (larghezza di banda, spazio su disco utilizzato per i registri e la CPU, ad esempio) per il consumo di un attacco a forza bruta possono essere dannose.

Mitigazione

Alcune tecniche per mitigare un attacco a forza bruta su SSH:

• Utilizza una porta diversa, non ottenere un falso senso di sicurezza con questo, ma molti robot effettuano la ricerca di 22 esclusivamente. ( domanda correlata )
• Disabilita le password SSH
• Richiedi una chiave privata per l'accesso
• Throttle connections
• Implementa un IPS ( Fail2ban e Snort vengono in mente)
• Limita il login per indirizzo IP
• Limita gli utenti che possono accedere (diversi che controllare l'indirizzo IP)

Il rischio principale è che la connessione iniziale possa essere intercettata da un Man-In-The-Middle, quindi un utente malintenzionato può recuperare la password.

La prima volta che un utente si connette a un server SSH, viene visualizzato qualcosa di simile al seguente:

$ ssh scanme.nmap.org
The authenticity of host 'scanme.nmap.org (45.33.32.156)' can't be established.
ECDSA key fingerprint is SHA256:8iz5L6iZxKJ6YONmad4oMbC+m/+vI9vx5C5f+qTTGDc.
Are you sure you want to continue connecting (yes/no)?

Ora, a meno che ogni utente verifichi quell'impronta digitale per assicurarsi che si tratti del server, sussiste il rischio che la connessione sia stata intercettata (ad esempio, il MITM sulla rete intercetta direttamente il traffico o qualche tipo di dirottamento DNS).

Questo perché SSH è "Trust on First Use". Se ti sei già collegato a quell'host e la chiave cambia improvvisamente, viene visualizzato il seguente messaggio, che avvisa l'utente.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5c:9b:16:56:a6:cd:11:10:3a:cd:1b:a2:91:cd:e5:1c.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.mydomain.com has changed and you have requested strict checking.
Host key verification failed.

L'avviso attenuerà questo attacco per gli utenti che sono già connessi da quel particolare client.

Altri, rischi meno critici di avere SSH aperto su Internet è che ci sono molti robot là fuori che trovano e tentano accessi contro tali server. Se hai una password sicura su tutti gli account, il rischio di compromissione è molto basso (per strong intendo uno che sicuramente non sarà in una lista di parole che l'attaccante può usare o creare). Si applicano regole usuali, ad esempio nessuna riutilizzazione della password, password memorizzata in modo sicuro, ecc. Lo svantaggio è che i file di registro si accumulano rapidamente con tutti i tentativi di autenticazione ricevuti.

Per quanto riguarda SSH stesso in qualsiasi modalità di autenticazione, poiché si tratta di un altro servizio, è possibile che vengano scoperte vulnerabilità che potrebbero essere sfruttate automaticamente da tali bot. Tuttavia, il rischio di questo non è maggiore di quello di un server web o di un'applicazione Web di essere sfruttato. Come ogni server con servizi pubblici, è raccomandata una buona strategia di gestione della vulnerabilità.

Vedi anche questa risposta , la parte relativa ai messaggi di avviso SSH e il rischio di continuare, anche con pubblico autenticazione con chiave.

I've heard multiple multiple times to never leave SSH with a password open over the internet. Why is this so bad?

I understand the password can be bruteforced, but what if it is a very strong password that would takes eons to crack?

Il fortissimo vantaggio della disattivazione degli accessi SSH della password è proprio nell'impedire agli account predefiniti le password deboli o gli utenti che scelgono password deboli dall'essere brute-forzate. In questo momento potresti avere solo pochi account senza password deboli, ma in futuro potrebbe essere installato qualcosa in caso contrario. Più sistemi o più complessità hai nel tempo, più alto diventa il rischio.

Caso aneddotico: un mio conoscente ha perso il suo server e ogni cosa su di esso perché ha dato ad un amico un account con la password di changeme che non è stata modificata. Nessun backup remoto è stato creato, quindi ha perso tutto.

Le chiavi SSH sono notevolmente più sicure per impostazione predefinita. A meno che la generazione della chiave non funzioni , il livello più basso di compromesso richiede il recupero della chiave dell'utente. Mentre con le password il livello è solo una supposizione quando qualcuno espone una password debole. Si tratta di assicurarsi che i futuri fallimenti umani siano protetti.

Un'altra cosa da considerare è la possibilità di vulnerabilità (benché nota per qualche tempo o zero-day) nel daemon sshd stesso, che potrebbe essere sfruttato da un utente malintenzionato. Per mitigarlo, è meglio aprire sshd solo agli utenti che lavorano da IP conosciuti di cui ti fidi, o tramite una VPN, se possibile.

Esistono diversi motivi per cui è più sicuro utilizzare l'autenticazione con chiave pubblica anziché l'autenticazione tramite password:

• La chiave segreta non lascia mai la macchina client, quindi è più difficile intercettare la chiave segreta della password. Questo è importante nel caso in cui un utente malintenzionato esegua un attacco mitm contro la prima connessione in cui la chiave host non è precedentemente nota. È inoltre importante che il server sia stato compromesso da un utente malintenzionato.
• L'utilizzo dell'autenticazione a chiave pubblica ti protegge dagli attacchi mitm completi. Se un utente malintenzionato doveva eseguire un attacco mitm contro la prima connessione, è possibile che non si verifichi la chiave host. Tuttavia, se si utilizza l'autenticazione della chiave pubblica per l'autenticazione, l'autenticazione è legata all'ID della sessione ssh, che impedisce all'utente malintenzionato di utilizzare la stessa autenticazione per passare la connessione al server legittimo. Ciò riduce l'attacco da un attacco mitm completo alla sola intercettazione della connessione, che sarà spesso più semplice da notare per l'utente. (Ad esempio, quando l'utente cerca un file noto sul server reale, ma non noto all'attaccante, l'utente noterà che qualcosa non va bene.)

Dato che mi sconsiglia l'uso dell'autenticazione tramite password, consiglierò anche di lasciarlo abilitato sul server ssh per i seguenti motivi:

• Gli attacchi tenteranno attacchi di tipo brute force. Se nel sistema è presente un utente con una password debole, è possibile che tale attacco abbia esito positivo.
• Anche se tutti gli utenti del sistema hanno password complesse, gli hacker tenteranno comunque di forzare le password. Questo consumerà risorse sul server. Occasionalmente ho visto attacchi di tipo "forza bruta" così aggressivi da rendere non validi gli accessi legittimi dovuti al sovraccarico del server.
• Se ci si abitua ai server ssh senza accettare password, è più probabile che si noti nel caso in cui un utente malintenzionato provi un giorno a eseguire un attacco mitm e ti presenti una richiesta di password.

A quanto ho capito, una chiave non è così diversa da una password; è solo molto, molto più lungo e quindi più difficile da decifrare. Inoltre hai bisogno di una password in cima.

Ma vorrei anche dire che ha senso permettere solo a determinati indirizzi IP di connettersi alla porta SSH. Riduce i file di registro ed è generalmente buona norma consentire solo l'accesso (non l'accesso) a un servizio, se necessario. Ad esempio, per un intervallo di indirizzi IP della VPN della tua azienda. Ma non affidarti mai a questo.

Qualche volta è suggerito lo spostamento della porta SSH, ma ne vedo ben pochi vantaggi.

Inoltre (off-topic): Non consentire mai il login SSH per root.