Refuerzo de VPN en Windows: arregle la autenticación antes del túnel

Su servidor VPN de Windows pide un nombre de usuario y una contraseña, y ese único diálogo esconde tres cometidos no relacionados. Uno demuestra quién es la persona, uno impide que alguien que observa el cable reutilice esa prueba, y uno decide a qué direcciones puede llegar después. La mayoría de los despliegues pequeños refuerzan primero el túnel y dejan los dos primeros cometidos en sus valores predeterminados, que es el orden equivocado.

Trabaje en el orden en que trabaja el atacante. Primero, lo que se puede capturar del cable. Después, lo que se puede reproducir más tarde con esa captura. Por último, aquello a lo que puede llegar un atacante autenticado una vez dentro.

Tres cometidos, un solo diálogo

La identidad es la parte en la que piensa la gente, y es solo un tercio del problema. La prueba de identidad debe sobrevivir a un observador que graba el intercambio y lo intenta de nuevo más tarde. La autorización es una decisión aparte que toma el servidor después de resolver la identidad, y Windows la guarda en un servicio distinto del que valida las credenciales.

Cuando las tres viven en un mismo cajón mental, el resultado habitual es un servidor que autentica con fuerza y luego permite al usuario llegar a todo. Arreglar eso después es más difícil que decidir la política ahora, porque para entonces el perfil de cortafuegos, el grupo de direcciones y las rutas ya codifican el supuesto antiguo.

Separe los tres en sus notas antes de tocar cualquier ajuste y luego arréglelos desde el eslabón más débil hacia arriba.

Por qué MS-CHAPv2 no supera una prueba de reproducción

Si el servidor todavía acepta PPTP con MS-CHAPv2, el túnel no protege la contraseña en ningún sentido relevante. El desafío y la respuesta se pueden capturar y atacar sin conexión, y en 2012 un servicio público de descifrado demostró la recuperación de ese intercambio en aproximadamente un día para una contraseña típica. Una contraseña más larga y compleja eleva el costo; no elimina el material que el atacante necesita de la red.

La propiedad que usted quiere es una credencial que no se pueda reproducir. EAP-TLS con certificados de cliente da a cada dispositivo su propia identidad y le permite revocar exactamente un dispositivo.

Desplegar certificados es trabajo de verdad: una CA privada, una ruta de revocación que los clientes comprueben y un plan de renovación que sobreviva a la rotación de personal. Trate ese trabajo como el proyecto y no como un obstáculo entre usted y un túnel que funciona. Presupueste para ello como presupuestaría un reemplazo de cortafuegos. Una contraseña compartida solo es más barata hasta la primera revocación.

Una clave precompartida autentica al par, no a la persona

L2TP/IPsec con una clave precompartida demuestra que dos puertas de enlace conocen el mismo secreto. No dice nada sobre qué persona se conecta y no puede distinguir a un empleado de otro en esa capa. Use un valor aleatorio largo, muy por encima de los diez caracteres que sugieren algunas guías, porque quien capture el handshake puede atacar la clave sin conexión.

Todos los clientes de ese perfil comparten el secreto, así que quitar a una persona significa redistribuirlo a todos los que quedan. Mantenga un paso aparte de autenticación de usuario por encima del secreto de nivel de máquina y pase a los certificados a medida que crezca la población de clientes. Una clave precompartida combinada con MS-CHAPv2 son dos capas débiles, y la segunda anula la primera.

La autorización pertenece a Network Policy Server

NPS en Windows decide quién puede conectarse, y lo hace después de que la autenticación ya haya tenido éxito. Esa separación es el control de refuerzo más útil del producto, y muchos despliegues lo dejan intacto.

Use condiciones de directiva que reflejen restricciones reales: pertenencia a grupos, la franja horaria en la que hay soporte y el estado del dispositivo según una comprobación de salud. Añada un segundo factor donde los datos justifiquen la fricción, y recuerde que la directiva se evalúa por cada intento de conexión, lo que la convierte en un control vivo y no en un documento.

La contabilidad RADIUS también le da un registro de quién se conectó y cuándo. Ese registro es la diferencia entre una revisión de incidente y una conjetura, y existe tanto si alguien lo lee como si no.

Limite a qué puede llegar un inicio de sesión correcto

El adaptador VPN debería caer en un perfil de cortafuegos que permita los servicios que necesita su rol y no toda la subred. La cuestión del enrutamiento es distinta del filtrado. Un túnel completo protege el dispositivo cliente y hace pasar cada byte por su enlace ascendente, mientras que un túnel dividido mantiene el tráfico local como local y expone el dispositivo a la red en la que se encuentre.

Ninguna de las dos opciones es un valor predeterminado de seguridad. Ambas deben quedar escritas junto al perfil de cortafuegos que suponen.

Verifique las rutas de fallo

Pruebe lo que debería romperse: una contraseña incorrecta, un certificado caducado, un dispositivo revocado, un usuario fuera del grupo. Cada caso debería fallar en un punto distinto, y el registro debería decir cuál fue. Ejecute el conjunto primero contra una cuenta de prueba y luego repítalo con un usuario real. Un rechazo que llega al registro de eventos sin motivo merece arreglarse mucho antes de que necesite el registro.

Luego confirme qué puertos están publicados y por qué. PPTP necesita TCP 1723 y GRE como protocolo IP en lugar de un puerto, IKEv2 necesita UDP 500 y 4500, y L2TP necesita UDP 1701 más IPsec. Exponer una interfaz de administración para que un cliente se conecte no es una reparación, es un segundo incidente esperando a ser descubierto.

Por último, decida qué registra el servidor y durante cuánto tiempo. Un extremo sin historial de autenticación no puede responder la primera pregunta tras un incidente, que es si el intento estuvo alguna vez autorizado.