Quanto è sicuro consentire l'accesso SSH basato su chiave all'interno della LAN?

2

Quindi questa è la mia configurazione:

  • Abbiamo alcune macchine in una LAN, utilizzate per il calcolo, che io e i miei colleghi accediamo dall'esterno con SSH.
  • Tutti i nostri account sulle macchine LAN sono gestiti e condivisi tramite LDAP (risiede nella LAN, ma è accessibile solo con SSL).
  • L'accesso dall'esterno è limitato attraverso una delle macchine (SSH su una porta diversa da 22 ed esegue Fail2Ban). L'autenticazione della password è disabilitata e tutti gli utenti utilizzano chiavi crittografate con password passphrase quando effettuano l'accesso dall'esterno della LAN. Anche il login root è disabilitato in tutta la rete.

Tuttavia, poiché è normale passare da una macchina all'altra, molti utenti usano login paswordless all'interno della LAN. Ciò significa che se un utente malintenzionato accede a tale host esterno, ha lo stesso livello di accesso in tutta la LAN dell'utente compromesso.

Come posso mitigare questo rischio? Quali sono alcune buone pratiche da seguire? Ci sono altri problemi evidenti con il mio setup?

    
posta nikitautiu 21.11.2018 - 17:20
fonte

2 risposte

2

Puoi utilizzare host SSH Jump ( ssh -J ) per connetterti alla macchina interna tramite la macchina esterna. Questa configurazione significa che i materiali chiave risiedono nella workstation anziché sul gateway. Quando si utilizza la configurazione dell'host jump, la workstation locale negozia direttamente la connessione SSH con le macchine interne, quindi un utente malintenzionato che ha bloccato l'host di salto non può intercettare la connessione al computer interno.

Se si desidera avviare la connessione dopo aver effettuato la connessione al gateway, è possibile utilizzare invece inoltro agente ( ssh -A ). Si noti che questo è meno sicuro rispetto all'installazione dell'host di salto, poiché un utente malintenzionato che ha pwnato il gateway può utilizzare il socket dell'agente inoltrato per creare nuove connessioni al computer interno. Per proteggerlo, è possibile configurare l'agente ssh locale per visualizzare la finestra di dialogo di conferma prima che l'agente debba firmare una nuova connessione. Si noti inoltre che, in questa configurazione, il gateway può intercettare le comunicazioni poiché la sessione verrà decodificata dal gateway prima di inoltrarla alla macchina interna. In generale, l'host di salto è preferito, ma ci sono situazioni in cui l'inoltro dell'agente ha senso, ad esempio, se è necessario trasferire i file direttamente tra l'host di salto e la macchina interna, invece di dover passare attraverso la stazione di lavoro locale.

    
risposta data 22.11.2018 - 13:04
fonte
0

La risposta di Lie copre già la maggior parte degli aspetti.

Ecco alcuni aspetti aggiuntivi relativi alla sicurezza delle coppie di chiavi del cliente:

  • Devi stabilire una gestione delle chiavi autorizzata che rimuova automaticamente le chiavi pubbliche degli utenti inattivi / eliminati
  • Si consiglia vivamente di applicare una norma per la rotazione delle chiavi del client.
  • Non è possibile applicare efficacemente una protezione avanzata della chiave privata a meno che non si registrino token hardware crittografici per gli utenti, ma questi sono lenti.

Pertanto consiglierei di utilizzare i certificati temporanei client OpenSSH che emetti dopo l'autenticazione multi-fattore e che sono validi solo per un paio d'ore.

    
risposta data 22.11.2018 - 16:46
fonte

Leggi altre domande sui tag