Enduriment del VPN a Windows: arregleu l’autenticació abans del túnel

El vostre servidor VPN de Windows demana un nom d’usuari i una contrasenya, i aquest únic diàleg amaga tres deures no relacionats. Un demostra qui és la persona, un evita que algú que observa la xarxa reutilitzi aquesta prova, i un decideix a quines adreces pot accedir després. La majoria de desplegaments petits endureixen primer el túnel i deixen els dos primers deures amb els valors per defecte, que és l’ordre equivocat.

Treballen en l’ordre en què treballa l’atacant. Primer, què es pot capturar de la xarxa. Després, què es pot reproduir més tard amb aquesta captura. Finalment, a què pot arribar un atacant autenticat un cop a dins.

Tres deures, un sol diàleg

La identitat és la part en què la gent pensa, i només és un terç del problema. La prova d’identitat ha de sobreviure a un observador que enregistra l’intercanvi i ho torna a provar més tard. L’autorització és una decisió separada que el servidor pren després que la identitat estigui resolta, i Windows la guarda en un servei diferent del que valida les credencials.

Quan les tres viuen en una sola ment, el resultat habitual és un servidor que autentica amb força i després permet a l’usuari arribar a tot. Arreglar-ho més tard és més difícil que decidir la política ara, perquè llavors el perfil del tallafoc, el conjunt d’adreces i les rutes ja codifiquen la suposició antiga.

Separeu les tres coses a les notes abans de tocar cap paràmetre, i després arregleu-les des de l’enllaç més feble cap amunt.

Per què MS-CHAPv2 no supera una prova de reproducció

Si el servidor encara accepta PPTP amb MS-CHAPv2, el túnel no protegeix la contrasenya en cap sentit rellevant. El repte i la resposta es poden capturar i atacar fora de línia, i el 2012 un servei públic de trencament va demostrar la recuperació d’aquest intercanvi en aproximadament un dia per a una contrasenya típica. Una contrasenya més llarga i complexa encareix l’atac; no elimina el material que l’atacant necessita de la xarxa.

La propietat que voleu és una credencial que no es pugui reproduir. EAP-TLS amb certificats de client dóna a cada dispositiu la seva pròpia identitat i us permet revocar exactament un dispositiu.

Desplegar certificats és feina de veritat: una CA privada, un camí de revocació que els clients comprovin i un pla de renovació que sobrevisqui la rotació de personal. Tracteu aquesta feina com el projecte i no com un obstacle entre vosaltres i un túnel funcionant. Pressuposteu-la com pressupostaríeu una substitució de tallafoc. Una contrasenya compartida només és més barata fins a la primera revocació.

Una clau prèviament compartida autentica la parella, no la persona

L2TP/IPsec amb una clau prèviament compartida demostra que dues passarel·les coneixen el mateix secret. No diu res sobre quina persona es connecta i no pot distingir un empleat d’un altre en aquesta capa. Feu servir un valor aleatori llarg, molt per sobre dels deu caràcters que suggereixen algunes guies, perquè qui capturi l’intercanvi pot atacar la clau fora de línia.

Cada client d’aquest perfil comparteix el secret, així que treure una persona significa redistribuir-lo a tots els qui queden. Mantingueu un pas separat d’autenticació d’usuari per sobre del secret de nivell de màquina i passeu als certificats a mesura que creixi la població de clients. Una clau prèviament compartida combinada amb MS-CHAPv2 són dues capes febles, i la segona anul·la la primera.

L’autorització pertany a Network Policy Server

NPS a Windows decideix qui es pot connectar, i ho fa després que l’autenticació ja hagi tingut èxit. Aquesta separació és el control d’enduriment més útil del producte, i molts desplegaments el deixen intacte.

Feu servir condicions de política que reflecteixin restriccions reals: pertinença a grups, la franja horària en què hi ha suport i l’estat del dispositiu provinent d’una comprovació de salut. Afegiu un segon factor on les dades justifiquin la fricció, i recordeu que la política s’avalua per cada intent de connexió, cosa que la converteix en un control viu i no en un document.

La comptabilitat RADIUS també us dóna un registre de qui es va connectar i quan. Aquest registre és la diferència entre una revisió d’incident i una conjectura, i existeix tant si algú el llegeix com si no.

Limiteu a què pot arribar un inici de sessió correcte

L’adaptador VPN hauria de caure en un perfil de tallafoc que permeti els serveis que necessita el seu rol i no tota la subxarxa. La qüestió de l’encaminament és separada del filtratge. Un túnel complet protegeix el dispositiu client i fa passar cada byte pel vostre enllaç, mentre que un túnel dividit manté el trànsit local local i exposa el dispositiu a qualsevol xarxa on es trobi.

Cap de les dues opcions no és un valor per defecte de seguretat. Totes dues s’han d’escriure al costat del perfil de tallafoc que pressuposen.

Verifiqueu els camins de fallada

Proveu què hauria de fallar: una contrasenya incorrecta, un certificat caducat, un dispositiu revocat, un usuari fora del grup. Cada cas hauria de fallar en un punt diferent, i el registre hauria de dir quin era. Executeu el conjunt primer amb un compte de prova i després repetiu-ho amb un usuari real. Un rebuig que arriba al registre d’esdeveniments sense cap motiu val la pena arreglar-lo molt abans que necessiteu el registre.

Després confirmeu quins ports estan publicats i per què. PPTP necessita TCP 1723 i GRE com a protocol IP en lloc d’un port, IKEv2 necessita UDP 500 i 4500, i L2TP necessita UDP 1701 més IPsec. Exposar una interfície de gestió perquè un client es connecti no és una reparació, és un segon incident esperant a ser descobert.

Finalment, decidiu què registra el servidor i durant quant de temps. Un extrem sense historial d’autenticació no pot respondre la primera pregunta després d’un incident, que és si l’intent havia estat mai autoritzat.