Perché usare SSH e VPN in combinazione?

Il mio datore di lavoro mi richiede di accedere prima a una VPN e solo allora posso accedere a SSH nei server. Ma, data la sicurezza di SSH, una VPN è eccessiva?

Qual è l'uso di una VPN in termini di sicurezza se sto già utilizzando SSH ?

Il ragionamento alla base della configurazione corrente è probabilmente una combinazione dei seguenti tre motivi.

La VPN è una soluzione di sicurezza esterna alla rete della tua azienda (vedi n. 1 di seguito) . SSH, tuttavia, potrebbe essere un secondo livello di sicurezza al di fuori della rete della tua azienda ... ma il suo scopo principale è proteggere il traffico all'interno della rete della tua azienda (vedi n. 2 di seguito) . La VPN è inoltre necessaria se il dispositivo su cui stai tentando di accedere a SSH utilizza un indirizzo privato sulla rete della tua azienda (vedi n. 3 di seguito) .

1. VPN crea il tunnel verso la tua rete aziendale attraverso la quale trasferisci i dati. Pertanto, nessuno vede il traffico tra te e la rete della tua azienda può effettivamente vedere ciò che stai inviando. Tutto ciò che vedono è il tunnel. Ciò impedisce alle persone esterne alla rete aziendale di intercettare il traffico in modo utile.

2. SSH è un modo crittografato per connettersi ai dispositivi della rete (al contrario di Telnet, che è un testo in chiaro). Le aziende spesso richiedono connessioni SSH anche su una rete aziendale per motivi di sicurezza. Se ho installato malware su un dispositivo di rete e tu telnet in quel dispositivo (anche se stai attraversando un tunnel VPN - poiché il tunnel VPN di solito termina al perimetro della rete di un'azienda), posso vedere il tuo nome utente e password. Se stai usando SSH, non posso.

3. Se la tua azienda utilizza l'indirizzamento privato per la rete interna, il dispositivo a cui ti stai connettendo potrebbe non essere in grado di eseguire il routing su Internet. La connessione tramite un tunnel VPN sarebbe come se tu fossi collegato direttamente in ufficio, pertanto utilizzeresti il ​​routing interno della rete aziendale che non sarebbe raggiungibile al di fuori della rete aziendale.

SSH è un obiettivo estremamente popolare per i tentativi di forzare il bruto. Se hai un server SSH direttamente su Internet, in pochi minuti, vedrai tentativi di accesso con tutti i tipi di nomi utente (e password), spesso migliaia al giorno anche su piccoli server insignificanti.

Ora è possibile rafforzare i server SSH (i tre principali meccanismi richiedono una chiave SSH, negando l'accesso root a SSH e, se possibile, limitando gli indirizzi IP a cui è persino consentito connettersi). Tuttavia, il modo migliore per rafforzare un server SSH è di non averlo affatto disponibile su Internet.

Perchè importa? Dopo tutto, SSH è fondamentalmente sicuro, giusto? Bene, sì, ma è sicuro tanto quanto gli utenti lo fanno - e il tuo datore di lavoro potrebbe essere preoccupato per le password deboli e il furto delle chiavi SSH.

L'aggiunta di una VPN aggiunge un ulteriore livello di difesa che è controllato a livello aziendale, anziché a livello di singolo server come lo è SSH.

Nel complesso, raccomanderei al vostro datore di lavoro di implementare alcune buone pratiche di sicurezza qui. A scapito della convenienza, ovviamente (la sicurezza di solito viene a scapito della convenienza).

La VPN ti consente di connetterti alla rete privata del tuo datore di lavoro e acquisire un indirizzo IP di quella rete privata. Una volta che sei connesso alla VPN, è come se stessi utilizzando uno dei computer all'interno dell'azienda, anche se ti trovi fisicamente dall'altra parte del mondo.

Molto probabilmente, il tuo datore di lavoro ti richiede di connetterti prima tramite VPN perché i server non sono accessibili da Internet (cioè non hanno un indirizzo IP pubblico), che è una buona idea. La VPN aggiunge un altro livello di sicurezza, come se i server fossero accessibili pubblicamente tramite SSH sarebbero vulnerabili a una serie di attacchi.

SSH è un protocollo di crittografia utilizzato per diverse cose. La crittografia del traffico in un tunnel VPN è una di queste. Il tuo traffico viene crittografato tramite SSH, ma deve essere racchiuso in pacchetti IP (tunnel) validi per attraversare una rete come Internet. Questo tunnel è la VPN.

Fondamentalmente, il tuo datore di lavoro blocca il traffico di rete esterno, per sicurezza, a meno che quel traffico non provenga da una VPN controllata dal datore di lavoro. Una VPN può o meno crittografare il contenuto del tunnel. L'uso di SSH crittograferà il traffico trasportato nel tunnel VPN.

È necessaria la VPN per accedere alla rete locale.

Non è quindi necessario proteggere la connessione ai singoli server, poiché sarà già crittografata dal collegamento VPN.

Tuttavia, in quale altro modo ti connetteresti a loro? SSH è il protocollo di accesso alla console di fatto per i server remoti; l'installazione e la configurazione di uno non sicuro costituirebbe un ulteriore sovraccarico di gestione e ridurrebbe la sicurezza all'interno della rete locale (che potrebbe essere o meno un problema).

Non dimenticare che non tutti, anche all'interno dell'azienda, avranno accesso totale a tutti i server e la possibilità di utilizzare la crittografia basata su chiave anche all'interno della rete locale consente al tuo amministratore di rete di garantire in modo facile e sicuro che solo le persone che sanno apparentemente cosa stanno facendo, anche all'interno dell'azienda, sono autorizzati a toccare il server.

Puoi guidare ulteriori livelli di sicurezza anche attraverso la VPN. Come controlli dei criteri del dispositivo, autenticazione a 2 fattori, ecc.

Il ragionamento tipico è che si desidera ridurre il più possibile l'esposizione e i possibili vettori di attacco.

Se si parte dal presupposto che sono richiesti sia SSH che VPN (per i propri scopi), allora avere entrambi i lati esterni significa che gli aggressori hanno due potenziali percorsi nel proprio ambiente. Se si esegue SSH solo in locale, si aggiunge un ulteriore livello alla sicurezza del server. Considera i seguenti scenari:

1. SSH + VPN esternamente. L'attaccante deve solo compromettere SSH per compromettere il server.

2. SSH esterno. Funzionalmente uguale allo scenario precedente.

3. VPN esterno (SSH interno). Raddoppia la sicurezza. L'attaccante deve superare entrambi prima di poter fare qualsiasi cosa al server.

Considera che oltre al fatto che la VPN sarebbe essenziale per altre funzioni e potrebbe essere meglio configurata per l'accesso esterno ed è un gioco da ragazzi.

Avrei il rischio che la risposta sia semplicemente che il NAT è coinvolto e (come molti altri hanno affermato) esporre il server di destinazione finale al mondo invita un altro punto di attacco. A meno che non si eseguano pesanti trasferimenti di dati di grandi dimensioni con chiavi di grandi dimensioni, SSH generalmente non si mette in mezzo. Il collo di bottiglia sarà quasi sempre la rete. (Quasi! = Sempre).

Se sei abbastanza "fortunato" da avere IPv6, questo non è probabilmente un grosso problema, ma con IPv4 e lo spazio di indirizzi limitato disponibile NAT è (IMO) in definitiva ciò che penso sia dietro questa "politica" più di ogni altra sicurezza "accidentale" o "intenzionale".

Secondo la mia attuale comprensione, SSH - perché utilizza semplicemente uno scambio di chiavi TCPC per verificare che un utente client disponga delle credenziali corrette per accedere all'ID utente nel server, sia suscettibile all'uomo nel mezzo di attacchi in cui un ISP o un router compromesso potrebbero intercettare la richiesta di handshake e fungere da autenticazione di invio, in effetti dirottando la connessione. Ciò consente ai comandi di essere iniettati nel flusso e quindi di filtrare l'output prima che raggiunga il client autentico iniziale, nascondendo così l'uomo nel mezzo dell'iniezione di comandi arbitrari nella shell ssh del server.

Tuttavia da un tunnel VPN consente qualcosa che ssh non lo fa. Una chiave di crittografia simmetrica pre-concordata aggiuntiva. Ciò significa che il traffico tra le due macchine non è suscettibile a un uomo nel mezzo dell'attacco perché il traffico, se intercettato e inoltrato per conto del client autentico al fine di controllare il livello di crittografia SSL non sarebbe in grado di passare la chiave di crittografia VPN requisiti poiché la terza parte non avrebbe la possibilità di falsificare le chiavi VPN allo stesso modo in cui sarebbe in grado di controllare un inoltro intermedio della connessione ssh tcp ssl.

Quindi, ssh non è abbastanza buono per fermare man in the middle da un ISP o un router compromesso che un client deve attraversare per connettersi al server.