Perché è così brutto?

Poiché ci sono tonnellate di bot che scansionano il Web alla ricerca di porte aperte e cercano di accedere, una volta che uno scanner trova un SSH aperto porta può essere messa in coda per un altro bot (o botnet) per provare a forzare la password. Uno dei rischi qui è che alla fine potrebbero riuscire a capire la password e prendere il controllo del server.

Capisco che la password possa essere forzata, ma cosa succede se è molto forte password che impiegherebbe eoni a craccare?

Avere una password lunga è una tecnica di mitigazione, tuttavia le risorse (larghezza di banda, spazio su disco utilizzato per i log e CPU per esempio) consumano una forza bruta l'attacco può anche essere dannoso.

Mitigazione

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

• Usa una porta diversa, don ' Non ho un falso senso di sicurezza con questo, ma molti bot cercano esclusivamente 22. ( Domanda correlata)
• Disattiva le password SSH
• Richiedi una chiave privata per l'accesso
• Limita le connessioni
• Implementa un IPS ( Fail2ban e Snort vieni in mente)
• Limita l'accesso per indirizzo IP
• Limita gli utenti che possono accedere (diverso dal controllo dell'indirizzo IP )

Il rischio principale è che la connessione iniziale possa essere intercettata da un Man-In-The-Middle, in modo che un utente malintenzionato possa 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 L'autenticità dell'host 'scanme.nmap.org (45.33.32.156)' non può essere stabilita. L'impronta digitale della chiave ECDSA è SHA256: 8iz5L6iZxKJ6YONmad4oMbC + m / + vI9vx5C5f + qTTGDc. Sei sicuro di voler continuare a connetterti (sì / no)?  

Ora, a meno che ogni utente non abbia intenzione di verificare l'impronta digitale per assicurarsi che è il tuo server, quindi c'è il rischio che la loro connessione sia stata intercettata (es. MITM sulla loro rete intercetta direttamente il traffico, o qualche tipo di dirottamento DNS).

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

  @@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@ AVVISO: L'IDENTIFICAZIONE DELL'HOST REMOTO È CAMBIATA! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ È POSSIBILE CHE QUALCUNO STA FACENDO QUALCOSA DI CATTIVO! Qualcuno potrebbe origliare su di te in questo momento (attacco man-in-the-middle)! È anche possibile che la chiave host RSA sia stata appena cambiata. L'impronta digitale per la chiave RSA inviata dall'host remoto è 5c: 9b: 16: 56: a6: cd: 11: 10: 3a: cd: 1b: a2: 91: cd: e5: 1c Contatta l'amministratore di sistema Aggiungi la chiave host corretta in /home/user/.ssh/known_hosts per eliminare questo messaggio. key in /home/user/.ssh/known_hosts:1RSA host key per ras.mydomain.com è cambiata e hai richiesto un controllo rigoroso. Verifica della chiave host non riuscita.  

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

Un altro rischio meno critico di avere SSH aperto su Internet è che ci sono molti bot là fuori che trovano e tentano di accedere a tali server. Se si dispone di una password complessa su tutti gli account, il rischio di compromissione è molto basso (per forte intendo una che sicuramente non sarà in un elenco di parole che l'attaccante potrebbe utilizzare o creare). Si applicano le regole usuali, ad esempio nessun riutilizzo della password, password memorizzata in modo sicuro, ecc. Lo svantaggio è che i file di registro si accumuleranno rapidamente con tutti i tentativi di autenticazione ricevuti.

Per quanto riguarda SSH stesso in qualsiasi modalità di autenticazione, poiché un altro servizio esiste la possibilità che vengano scoperte vulnerabilità che potrebbero essere sfruttate automaticamente da tali bot. Tuttavia, il rischio di ciò non è maggiore di quello di un server Web o di un'applicazione Web di essere sfruttati. Come ogni server con servizi pubblici, si consiglia una buona strategia di gestione delle vulnerabilità.

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

Ho sentito più volte di non lasciare mai SSH con una password aperta su Internet. Perché è così grave?

Capisco che la password possa essere forzata, ma cosa succederebbe se fosse una password molto complessa che impiegherebbe eoni a decifrarla?

La stessa Il grande vantaggio della disabilitazione degli accessi SSH tramite password consiste nel impedire che gli account predefiniti con password deboli o gli utenti che scelgono password deboli siano forzati. Al momento potresti avere solo pochi account senza password deboli, ma in futuro potrebbe essere installato qualcosa in cui non è così. Più sistemi o più complessità hai nel tempo, più alto diventa il rischio.

Caso aneddotico: un mio conoscente ha perso il suo server e tutto ciò che contiene perché ha dato ad un amico un account con la password di changeme che non è stato modificato. Non sono stati creati nemmeno backup remoti, quindi ha perso tutto.

Le chiavi SSH sono notevolmente più sicure per impostazione predefinita. A meno che la generazione della chiave non venga interrotta, il livello di compromissione più basso richiede l'acquisizione della chiave dell'utente. Considerando che con le password il livello è solo indovinare 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à (anche se note da tempo o zero-day) nel demone sshd stesso, che potrebbero essere sfruttate da un attaccante. Per mitigare questo problema, è meglio aprire sshd solo agli utenti che lavorano da IP noti di cui ti fidi, o tramite una VPN, se possibile.

Ci sono diversi motivi per cui è più sicuro usare l'autenticazione con chiave pubblica anziché l'autenticazione con password:

• La chiave segreta non lascia mai la macchina client, quindi è più difficile intercettare il segreto chiave rispetto alla password. Questo è importante nel caso in cui un utente malintenzionato esegua un attacco mitm contro la tua prima connessione in cui la chiave host non è precedentemente nota. È anche importante nel caso in cui il server sia stato compromesso da un utente malintenzionato.
• L'uso dell'autenticazione con chiave pubblica ti protegge dagli attacchi mitm completi. Se un utente malintenzionato dovesse eseguire un attacco mitm contro la tua prima connessione, potresti non verificare la chiave host. Tuttavia, se si utilizza l'autenticazione con chiave pubblica per l'autenticazione, l'autenticazione è legata all'ID di sessione ssh, che impedisce all'autore dell'attacco 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 spesso sarà più facile da notare per l'utente. (Ad esempio, quando l'utente cerca un file noto per essere sul server reale, ma non noto all'attaccante, l'utente noterà che qualcosa non va.)

Dato che io sconsiglio di utilizzare l'autenticazione con password, consiglierò anche di non lasciarla abilitata sul tuo server ssh per i seguenti motivi:

• Gli aggressori tenteranno attacchi di forza bruta con password. Se hai un utente sul sistema con una password debole, esiste la possibilità che un tale attacco abbia successo.
• Anche se tutti gli utenti del sistema hanno password complesse, gli aggressori proveranno comunque a forzare le password . Ciò consumerà risorse sul server. Di tanto in tanto ho visto tali attacchi di forza bruta essere così aggressivi che gli accessi legittimi non riuscivano a causa del sovraccarico del server.
• Se ti abitui al fatto che i server ssh non accettano mai password, è più probabile che te ne accorga nel caso in cui un utente malintenzionato un giorno tenti di sferrarti 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.

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

A volte viene suggerito di spostare la porta SSH, ma ne vedo pochi vantaggi.

Inoltre (fuori tema): non consentire mai l'accesso SSH per root .