Endurecemento do VPN en Windows: corrixa a autenticación antes do túnel

O seu servidor VPN de Windows pide un nome de usuario e un contrasinal, e ese único diálogo agocha tres cometidos non relacionados. Un demostra quen é a persoa, un impide que alguén que observa o cable reutilice esa proba, e un decide a que enderezos pode chegar despois. A maioría dos despregamentos pequenos endurecen primeiro o túnel e deixan os dous primeiros cometidos nos seus valores predeterminados, que é a orde equivocada.

Traballen na orde en que traballa o atacante. Primeiro, o que se pode capturar do cable. Despois, o que se pode reproducir máis tarde con esa captura. Por último, aquilo a que pode chegar un atacante autenticado unha vez dentro.

Tres cometidos, un só diálogo

A identidade é a parte na que pensa a xente, e só é un terzo do problema. A proba de identidade debe sobrevivir a un observador que grava o intercambio e o tenta de novo máis tarde. A autorización é unha decisión aparte que toma o servidor despois de resolver a identidade, e Windows gárdaa nun servizo distinto do que valida as credenciais.

Cando as tres viven nun mesmo caixón mental, o resultado habitual é un servidor que autentica con forza e logo permite ao usuario chegar a todo. Arranxar iso despois é máis difícil que decidir a política agora, porque para entón o perfil de cortalumes, o conxunto de enderezos e as rutas xa codifican o suposto antigo.

Separe os tres nas súas notas antes de tocar calquera axuste e logo arránxeos desde o elo máis feble cara arriba.

Por que MS-CHAPv2 non supera unha proba de reprodución

Se o servidor aínda acepta PPTP con MS-CHAPv2, o túnel non protexe o contrasinal en ningún sentido relevante. O desafío e a resposta pódense capturar e atacar sen conexión, e en 2012 un servizo público de descifrado demostrou a recuperación dese intercambio en aproximadamente un día para un contrasinal típico. Un contrasinal máis longo e complexo eleva o custo; non elimina o material que o atacante necesita da rede.

A propiedade que vostede quere é unha credencial que non se poida reproducir. EAP-TLS con certificados de cliente dá a cada dispositivo a súa propia identidade e permítelle revogar exactamente un dispositivo.

Despregar certificados é traballo de verdade: unha CA privada, unha ruta de revogación que os clientes comproben e un plan de renovación que sobreviva á rotación de persoal. Trate ese traballo como o proxecto e non como un obstáculo entre vostede e un túnel que funciona. Orzamente para el como orzaría unha substitución de cortalumes. Un contrasinal compartido só é máis barato ata a primeira revogación.

Unha chave precompartida autentica a parella, non a persoa

L2TP/IPsec cunha chave precompartida demostra que dúas pasarelas coñecen o mesmo segredo. Non di nada sobre que persoa se conecta e non pode distinguir un empregado doutro nesa capa. Use un valor aleatorio longo, moi por riba dos dez caracteres que suxiren algunhas guías, porque quen capture o handshake pode atacar a chave sen conexión.

Todos os clientes dese perfil comparten o segredo, así que quitar a unha persoa significa redistribuílo a todos os que quedan. Manteña un paso aparte de autenticación de usuario por riba do segredo de nivel de máquina e pase aos certificados a medida que medre a poboación de clientes. Unha chave precompartida combinada con MS-CHAPv2 son dúas capas febles, e a segunda anula a primeira.

A autorización pertence a Network Policy Server

NPS en Windows decide quen pode conectarse, e faino despois de que a autenticación xa tivese éxito. Esa separación é o control de endurecemento máis útil do produto, e moitos despregamentos déixano intacto.

Use condicións de directiva que reflictan restricións reais: pertenza a grupos, a franxa horaria na que hai soporte e o estado do dispositivo segundo unha comprobación de saúde. Engada un segundo factor onde os datos xustifiquen a fricción, e lembre que a directiva se avalía por cada intento de conexión, o que a converte nun control vivo e non nun documento.

A contabilidade RADIUS tamén lle dá un rexistro de quen se conectou e cando. Ese rexistro é a diferenza entre unha revisión de incidente e unha conxectura, e existe tanto se alguén o le como se non.

Limite a que pode chegar un inicio de sesión correcto

O adaptador VPN debería caer nun perfil de cortalumes que permita os servizos que precisa o seu rol e non toda a subrede. A cuestión do encamiñamento é distinta da filtragem. Un túnel completo protexe o dispositivo cliente e fai pasar cada byte polo seu enlace ascendente, mentres que un túnel dividido mantén o tráfico local local e expón o dispositivo á rede na que se atope.

Ningunha das dúas opcións é un valor predeterminado de seguridade. Ambas deben quedar escritas xunto ao perfil de cortalumes que supoñen.

Verifique as rutas de fallo

Probe o que debería romper: un contrasinal incorrecto, un certificado caducado, un dispositivo revogado, un usuario fóra do grupo. Cada caso debería fallar nun punto distinto, e o rexistro debería dicir cal foi. Execute o conxunto primeiro contra unha conta de proba e logo repítao cun usuario real. Un rexeitamento que chega ao rexistro de eventos sen motivo merece arranxarse moito antes de que necesite o rexistro.

Logo confirme que portos están publicados e por que. PPTP necesita TCP 1723 e GRE como protocolo IP en lugar dun porto, IKEv2 necesita UDP 500 e 4500, e L2TP necesita UDP 1701 máis IPsec. Expor unha interface de administración para que un cliente se conecte non é unha reparación, é un segundo incidente agardando a ser descuberto.

Por último, decida que rexistra o servidor e durante canto tempo. Un extremo sen historial de autenticación non pode responder a primeira pregunta tras un incidente, que é se o intento estivo algunha vez autorizado.