it-swarm.dev

Sicuro di stabilire una connessione VPN tramite la caffetteria WIFI?

Sul mio portatile di lavoro creo regolarmente una connessione VPN che utilizzo per desktop remoto sul nostro server web. È sicuro farlo in una caffetteria in cui persone casuali sono collegate alla stessa rete wifi?

25
Abe Miessler

Sì, una connessione VPN crittografa la connessione tra il computer e l'host VPN remoto. La connessione sembrerebbe semplicemente incomprensibile a chiunque fiuti il ​​traffico, sia nella caffetteria che su Internet. Vale la pena notare che lo stesso vale per qualsiasi contenuto inviato tramite HTTPS anche se non si utilizza una VPN.

Vale anche la pena notare che se si utilizza la versione corrente di Microsoft Terminal Services (ovvero desktop remoto), la connessione VPN non è nemmeno strettamente necessaria (dal punto di vista della sicurezza) poiché anche la connessione desktop remoto stessa è crittografata. Si noti che questa impostazione può essere opzionalmente ridotta dalla configurazione amministrativa sulla rete, quindi la VPN non è ancora una cattiva idea.

23
AJ Henderson

Come è già stato detto, è "sicuro" utilizzare la VPN su una rete wireless pubblica. VPN utilizza certificati per stabilire un flusso di dati crittografato tra il tuo computer e il server VPN. È possibile utilizzare uno strumento come WireShark per verificarlo. Tuttavia, penso che ci sia qualche possibilità di insicurezza almeno in teoria. Qualcuno POTREBBE creare un falso punto di accesso con lo stesso SSID del vero punto di accesso ed eseguire un attacco man-in-the-middle - per SSL VPN comunque. Dovresti ottenere un segnale più forte dall'AP falso per consentire al tuo computer di scegliere anche quello reale.

Per i dettagli, consultare il seguente collegamento: Mitigazione dei metodi di attacco SSLStrip sulla VPN SSL Secure Access

8
user5065

Per quanto riguarda la risposta di @AJ Henderson che afferma che le VPN potrebbero non essere necessarie per la "versione corrente dei servizi terminal", è necessario sapere che anche se il client è "il più recente" disponibile, un'impostazione AD all'interno di Criteri di gruppo può indebolire la sicurezza e creare scenari Wifi non sicuro. Questo viene spesso fatto come un compromesso per consentire una più ampia funzionalità.

4

Dipende molto dal tipo di VPN che stai utilizzando. Dovrebbe essere configurato correttamente su entrambi i lati (client e server, quando questa terminologia è applicabile).

  • Alcuni PPTP non forniscono alcuna crittografia per impostazione predefinita. Inoltre, dovresti assicurarti di utilizzare la forma di autenticazione appropriata (vedi questo avviso per esempio).

  • OpenVPN e IPsec (in alcuni casi) utilizzano i certificati X.509 per autenticare il server (almeno). Ciò soffrirebbe in parte degli stessi problemi PKI che interessano HTTPS.

    È necessario assicurarsi di verificare correttamente il certificato della parte remota durante la connessione (come sempre con i certificati); più specificamente, deve verificare che il certificato sia attendibile e che il suo nome corrisponda a quello che stai cercando. Le implementazioni corrette dovrebbero eseguire queste verifiche.

    Potresti anche riscontrare il problema di CA maleducato/compromesso, ma penso (spero) che sia piuttosto raro. In caso di dubbio, restringere l'elenco delle CA affidabili sul proprio computer, se possibile.

  • IPsec con un segreto condiviso. Questi possono andare bene, purché il segreto condiviso sia più segreto che condiviso. La conoscenza di questo segreto condiviso può consentire a un MITM di impersonare il server (anche i collegamenti su quella pagina dovrebbero essere di interesse).

    Più grande è l'organizzazione, più difficile sembrerebbe mantenere quel segreto condiviso sufficientemente segreto. Una rapida ricerca di istruzioni VPN per varie università sembra indicare che alcuni di questi segreti sono effettivamente resi pubblici.

    Nonostante i problemi PKI, una soluzione basata su certificato renderebbe più difficile la rappresentazione del server, poiché la chiave privata corrispondente del certificato non sarebbe condivisa con nessun utente.

Quindi, sì, una VPN può proteggerti su una rete non attendibile (almeno nella misura della rete VPN remota), ma come tutto, deve essere configurato in modo appropriato.

3
Bruno

La VPN soddisfa le tue esigenze purché siano soddisfatti i seguenti requisiti:

  • Il nodo di accesso VPN è autenticato da te, ad esempio con un certificato aggiornato
  • Il certificato è sicuro (ci sono problemi con i certificati, in particolare il segno MD5 dei certificati si è dimostrato debole)
  • Il meccanismo di autenticazione della VPN è sicuro (sono stati segnalati alcuni problemi con alcuni meccanismi di autenticazione, vale a dire MS-CHAP v2)
  • Il meccanismo di crittografia del canale è sicuro (non sono a conoscenza di difetti noti)
1
user823959

Dipende da come è impostata la tua VPN. Se il client verifica l'identità del server, ad esempio utilizzando i certificati, quindi sì. In caso contrario, puoi comunque essere MITM-ed.

0
Vitaly Osipov

1o rischio: OS

Il primo punto dipende dalla sicurezza della soluzione proposta è la sicurezza del sistema operativo che è il punto di partenza della VPN.

Troppi amministratori tendono a dimenticare che l'utilizzo di una VPN per raggiungere la propria rete aziendale da un sistema operativo debole è soprattutto un rischio per la sicurezza, e soprattutto perché una connessione VPN in entrata è generalmente classificata come attendibile (presso il firewall aziendale, a la società IPS, ovunque).

Ecco uno scenario di realtà comune: il tuo computer è ospitato da un keylogger. (Ritorno dell'esperienza reale: la cifra abituale è superiore a 1. Controllo dell'utente finale con una soluzione VPN: la cifra abituale è inferiore a 1).

2o rischio: traffico accanto al tunnel

Una VPN correttamente configurata dovrebbe bloccare la visibilità di Internet attraverso un traffico non crittografato (cioè un IP normale). Tutto dovrebbe passare attraverso esp (50) ah (51 ora per lo più non più utilizzato) o 443/tcp/IP aka https.

Scenario di realtà: la tua configurazione VPN è attiva ma il traffico sulla connessione wireless lato letto il tunnel è aperto e nulla sul sistema lo controlla e l'amministratore non è abbastanza consapevole della rete da vederlo all'inizio.

Immagino che non digiti tcpdump -i en1 ogni volta che avvii una VPN su un'interfaccia denominata en1 per verificare che 53/udp/IP, 67/udp/IP… Stanno ancora allagando accanto all'ingresso del tunnel :) e non solo 500/udp/IP.

Immagino che non verifichi con arp -a se un vicino è già collegato al PC nell'ambiente Wi-Fi.

3o rischio: certificati magicamente accettati

Sulla maggior parte dei sistemi operativi, gli utenti, anche gli amministratori e persino gli amministratori sensibili alla sicurezza, tendono a fidarsi della funzione automagica di accettare un certificato remoto. Questa funzione è nascosta nei browser e talvolta nel sistema operativo stesso. Una fiducia che non si verifica è magica. È un rischio.

Quando questa magia implica che devi prima lanciare Internet Explorer per costruire la tua VPN, questo vale una vita piena di investigazioni e horror.

Quando ti connetti con la tua azienda su una VPN costruita sopra una connessione https, la tua azienda dovrebbe costringerti a controllare il certificato della tua azienda per essere sicuro di non utilizzarne uno presentato da un web server falso all'interno del tuo Wi -Fi quartiere. Dovresti avere l'impronta digitale del certificato della tua azienda su un documento indipendente che puoi controllare in qualsiasi situazione. Questa connessione non dovrebbe essere costruita su magia trust.

0
dan