Cómo comprobar qué cubre un interruptor de emergencia en un host comprometido

Active el interruptor de emergencia, desconecte el servidor del túnel y observe qué sigue haciendo la máquina. La prueba vale la pena porque separa lo que el cortafuegos impone de lo que usted suponía, y los resultados son más estrechos de lo que sugieren la mayoría de las páginas de producto. Un interruptor de emergencia gobierna rutas de red; no gobierna el software que ya se ejecuta en el dispositivo. Ejecuto esta secuencia en cualquier máquina cuyo cliente afirme ser fail-closed, y tarda unos diez minutos.

Empiece por el cliente, no por el servidor

El punto de aplicación es el host en el que está sentado: el cortafuegos del sistema operativo, un servicio auxiliar o el propio controlador del cliente VPN. Eso importa porque todo lo que puede hacer el interruptor está limitado por lo que ve esa capa. Si el cliente implementa el bloqueo con una regla de enrutamiento más una marca, cualquier cosa con privilegios suficientes puede añadir su propia regla; si usa una tabla de cortafuegos del núcleo, los mismos privilegios pueden editar la tabla. La fuerza del cifrado nunca entra en esta cuestión.

Así que lo primero que hay que establecer es quién posee la política en este dispositivo y qué se le permite anular. En una máquina de trabajo gestionada la respuesta suele ser el agente de punto final de la organización, y una VPN personal no elimina esas capacidades, se configure como se configure el túnel.

Paso uno: confirme el bloqueo en las rutas que cree que cubre

Baje el túnel en el extremo remoto, no en el cliente, para que el cliente siga creyendo que debería estar conectado. Luego pruebe lo que probaría una persona:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Quiere un cliente que falle rápido y limpio, no uno que se cuelgue hasta el tiempo de espera del navegador. Colgarse suele significar que una regla descarta paquetes en silencio sin rechazarlos, lo cual es aceptable, pero también puede significar que el cliente dejó una ruta por defecto obsoleta apuntando a una interfaz muerta. Lea la tabla de enrutamiento con el túnel caído: una ruta por defecto que aún apunta al dispositivo del túnel y una regla de cortafuegos que solo bloquea conexiones salientes nuevas son dos estados distintos, y solo uno es de fallo cerrado.

Repita los mismos comandos con la opción de permitir LAN del cliente activada y desactivada. Ese conmutador es donde viven la mayoría de las sorpresas, porque reabre una ruta que el resto de la política estaba escrita para cerrar.

Paso dos: compruebe DNS e IPv6 como rutas separadas

La resolución de nombres es el hueco que sobrevive a la mayoría de las implementaciones, porque la consulta puede salir por algo distinto del resolutor del sistema. Pregunte con una herramienta que ignore su configuración de resolutor y compruebe el lado v6 de paso:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Respuestas vacías para ambas consultas de nombre con el túnel caído son el resultado que quiere. Si la segunda consulta responde, una dirección de resolutor codificada es accesible y el túnel no es la única salida de la máquina. Si solo tiene éxito la petición v6, la política cubre IPv4 e ignora IPv6, que es la misma fuga en otra familia de direcciones.

Los navegadores lo hacen más difícil de leer desde fuera, porque uno configurado para DNS sobre HTTPS resuelve la consulta mediante una petición HTTPS: la consulta solo está bloqueada en la medida en que lo esté el puerto 443 hacia ese extremo. En un host donde la política permite la subred local, esa petición aún puede alcanzar un resolutor en la LAN.

Paso tres: separe la exposición de red de la exposición del punto final

Ahora la parte que ninguna regla de cortafuegos alcanza. Un interruptor de emergencia bloquea rutas fuera de la máquina; no impide que el software de la máquina lea datos antes de cifrarlos ni que ese software use el túnel de forma legítima. Un keylogger, una extensión maliciosa, una pantalla dejada desbloqueada, un cliente de sincronización con permisos amplios: todos mueven información por una conexión que el interruptor permite con gusto.

Lo mismo vale para el software de monitorización que un empleador instaló a propósito. Bloquear rutas no lo elimina, y comprar un servidor VPN nuevo no es la reparación, porque la exposición está antes del túnel.

Un gestor de portapapeles que sube a una cuenta en la nube lo muestra con claridad. El tráfico está cifrado, el destino está permitido y el interruptor informa de un estado saludable todo el tiempo.

Paso cuatro: escriba la afirmación que respalda su prueba

Tras la prueba de caída puede afirmar hechos concretos: qué aplicaciones fallaron, qué rutas se detuvieron, cómo se comportaron DNS e IPv6 y si el bloqueo aguantó cuando cayó el túnel. No puede afirmar que el sistema operativo esté limpio, ni que un servicio del extremo remoto mantendrá privado su inicio de sesión.

Mantenga los dos problemas separados y dé a cada uno su propio control:

• Interruptor de emergencia: el requisito de fallo definido, verificado con una prueba de caída que repite tras cada actualización del cliente.
• Confianza del dispositivo: actualizaciones compatibles, protección de punto final de una fuente fiable, revisión de permisos y avisos de autenticación inexplicados.
• Incidente: siga el proceso de la plataforma o de la organización cuando se sospeche un compromiso; un servidor nuevo no es un paso de limpieza.
• Divulgación: cuando pida ayuda, no pegue claves privadas ni archivos de diagnóstico completos, porque los registros y las capturas llevan los mismos secretos que la conexión.

Ejecute la secuencia de nuevo tras la próxima actualización, porque un interruptor de emergencia es configuración que se mueve con las versiones. La prueba es la única evidencia de que el comportamiento en el que confía sigue siendo el que obtiene.