Rafforzamento della VPN su Windows: correggete l’autenticazione prima del tunnel

Il vostro server VPN Windows chiede un nome utente e una password, e quella sola finestra nasconde tre compiti non correlati. Uno dimostra chi è la persona, uno impedisce che qualcuno che osserva il cavo riutilizzi quella prova, e uno decide a quali indirizzi può arrivare dopo. La maggior parte delle piccole installazioni rafforza prima il tunnel e lascia i primi due compiti ai valori predefiniti, che è l’ordine sbagliato.

Lavorate nell’ordine in cui lavora l’attaccante. Prima ciò che si può catturare dal cavo. Poi ciò che si può riprodurre più tardi con quella cattura. Infine ciò a cui può arrivare un attaccante autenticato una volta dentro.

Tre compiti, una sola finestra

L’identità è la parte a cui pensa la gente, ed è solo un terzo del problema. La prova d’identità deve sopravvivere a un osservatore che registra lo scambio e riprova più tardi. L’autorizzazione è una decisione separata che il server prende dopo che l’identità è stabilita, e Windows la conserva in un servizio diverso da quello che convalida le credenziali.

Quando tutte e tre vivono in un solo secchio mentale, il risultato abituale è un server che autentica con forza e poi permette all’utente di arrivare a tutto. Correggerlo dopo è più difficile che decidere la policy adesso, perché a quel punto il profilo del firewall, il pool di indirizzi e le route codificano tutti il vecchio presupposto.

Separe i tre nelle vostre note prima di toccare un’impostazione, poi correggeteli dalla maglia più debole verso l’alto.

Perché MS-CHAPv2 non supera una prova di riproduzione

Se il server accetta ancora PPTP con MS-CHAPv2, il tunnel non protegge la password in alcun senso rilevante. La sfida e la risposta possono essere catturate e attaccate offline, e nel 2012 un servizio pubblico di cracking dimostrò il recupero da un handshake simile in circa un giorno per una password tipica. Una password più lunga e complessa alza il costo; non elimina il materiale che l’attaccante ricava dalla rete.

La proprietà che volete è una credenziale che non si possa riprodurre. EAP-TLS con certificati client dà a ogni dispositivo la propria identità e vi permette di revocare esattamente un dispositivo.

Distribuire certificati è lavoro vero: una CA privata, un percorso di revoca che i client controllano e un piano di rinnovo che sopravvive al ricambio del personale. Trattate quel lavoro come il progetto e non come un ostacolo tra voi e un tunnel funzionante. Mettetelo a budget come mettereste a budget la sostituzione di un firewall. Una password condivisa costa meno solo fino alla prima revoca.

Una chiave precondivisa autentica la coppia, non la persona

L2TP/IPsec con una chiave precondivisa dimostra che due gateway conoscono lo stesso segreto. Non dice nulla su quale persona si connette e non può distinguere un dipendente da un altro a quel livello. Usate un valore casuale lungo, ben oltre i dieci caratteri che alcune guide suggeriscono, perché chiunque catturi l’handshake può attaccare la chiave offline.

Ogni client su quel profilo condivide il segreto, quindi togliere una persona significa ridistribuirlo a tutti gli altri che restano. Mantenete un passo separato di autenticazione utente sopra il segreto a livello macchina, e passate ai certificati man mano che la popolazione dei client cresce. Una chiave precondivisa combinata con MS-CHAPv2 sono due strati deboli, e il secondo annulla il primo.

L’autorizzazione appartiene a Network Policy Server

NPS su Windows decide chi può connettersi, e lo fa dopo che l’autenticazione è già riuscita. Quella separazione è il controllo di rafforzamento più utile del prodotto, e molte installazioni lo lasciano intatto.

Usate condizioni di policy che riflettano vincoli reali: appartenenza ai gruppi, la fascia oraria in cui il supporto è presidiato e lo stato del dispositivo da un controllo di integrità. Aggiungete un secondo fattore dove i dati giustificano l’attrito, e ricordate che la policy viene valutata per ogni tentativo di connessione, il che la rende un controllo vivo e non un documento.

La contabilità RADIUS vi dà anche un registro di chi si è connesso e quando. Quel registro è la differenza tra una revisione dell’incidente e una congettura, ed esiste sia che qualcuno lo legga sia che non lo faccia.

Limitate ciò a cui può arrivare un accesso riuscito

L’adattatore VPN dovrebbe finire in un profilo firewall che consenta i servizi necessari al suo ruolo e non l’intera sottorete. La questione del routing è distinta dal filtraggio. Un tunnel completo protegge il dispositivo client e spinge ogni byte attraverso il vostro uplink, mentre un tunnel diviso mantiene il traffico locale locale ed espone il dispositivo alla rete su cui si trova.

Nessuna delle due scelte è un valore predefinito di sicurezza. Entrambe vanno scritte accanto al profilo firewall che presuppongono.

Verificate i percorsi di errore

Provate ciò che dovrebbe rompersi: una password errata, un certificato scaduto, un dispositivo revocato, un utente fuori dal gruppo. Ognuno dovrebbe fallire in un punto diverso, e il registro dovrebbe dire quale. Eseguite la serie prima su un account di test, poi ripetetela per un utente reale. Un rifiuto che finisce nel registro eventi senza motivo vale la pena di essere corretto molto prima che vi serva quel record.

Poi confermate quali porte sono pubblicate e perché. PPTP richiede TCP 1723 e GRE come protocollo IP anziché come porta, IKEv2 richiede UDP 500 e 4500, e L2TP richiede UDP 1701 più IPsec. Esporre un’interfaccia di gestione perché un client si connetta non è una riparazione, è un secondo incidente in attesa di essere scoperto.

Infine decidete cosa registra il server e per quanto tempo. Un endpoint senza storico di autenticazione non può rispondere alla prima domanda dopo un incidente, cioè se il tentativo fosse mai stato autorizzato.