Tu puerta de enlace VPN está comprometida: qué queda realmente expuesto
Una puerta de enlace VPN pirateada ve dentro de su propio túnel, pero eso no es controlar cada sesión. Separa el tráfico, el alcance y los secretos almacenados antes de recuperar.
Una puerta de enlace VPN se sitúa al final del túnel que protege, lo que significa que termina ese cifrado en lugar de dejarlo pasar. Si un atacante controla el host, el túnel sigue pareciendo sano desde fuera mientras la máquina del medio ya no es fiable. La pregunta útil no es si todo se descifra. Es qué podía ver ese host, hasta dónde podía llegar y qué secretos estaban realmente almacenados en él. Esas tres respuestas difieren mucho, y la respuesta difiere con ellas.
La puerta de enlace termina el túnel, así que ve dentro
El cifrado en una VPN va salto a salto, y la puerta de enlace es el salto. Elimina la capa exterior, aplica la política y reenvía el paquete interior, así que cada paquete transportado existe en forma legible en la memoria de ese host en algún momento. Eso es el diseño y no un defecto. También es la razón de que comprometer la puerta de enlace sea un suceso distinto de comprometer la criptografía del túnel.
Lo primero que gana el atacante es posición: la capacidad de observar el tráfico transportado, alterar el reenvío o responder en lugar de un backend. Lo que gana después depende del host, y aquí la gente sobreestima. El acceso a la puerta de enlace por sí solo no entrega las claves de sesión TLS de un navegador, porque nunca estuvieron en la puerta de enlace.
Tres exposiciones que no son del mismo tamaño
Divide la pregunta en tráfico transportado, sistemas alcanzables y secretos almacenados, y luego responde cada una por separado.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
La fila del medio es la que se omite. Una puerta de enlace suele tener una ruta hacia redes privadas y una dirección de origen en la que los backends ya confían, así que la pregunta interesante es qué permiten esos backends desde esa dirección. Una política estrecha de acceso de clientes es un buen control, pero un atacante en el host no se limita a la interfaz que usaría un cliente normal.
La fila inferior decide cuánto dura el incidente. Una clave de servidor y una clave de CA tienen radios de impacto completamente distintos, y también una cuenta de administrador local y un token de monitorización de solo lectura.
HTTPS dentro del túnel sigue siendo HTTPS
El TLS de la aplicación termina en la aplicación, no en la puerta de enlace VPN, así que una puerta de enlace comprometida observa texto cifrado para esos flujos. Ese es un límite real a lo que obtiene el atacante, y merece decirse con claridad, porque la afirmación contraria difunde pánico y malas decisiones. Dos condiciones lo rompen. Si en el camino hay un componente de inspección con un certificado de confianza, la puerta de enlace puede ver texto plano por diseño. Si el propio punto final de la aplicación está comprometido, el túnel es irrelevante.
Por tanto, la respuesta a qué vieron es condicional, y debería escribirse como condiciones en lugar de anunciarse como un veredicto.
Qué tiene que cambiar antes de volver a confiar en ella
Reconstruir el host es necesario y rara vez suficiente. Un atacante que aún conserva una cuenta de gestión, una credencial de despliegue o una clave de firma puede devolver el host a su gusto. La recuperación debe empezar por una vía de administración que no dependa de la máquina comprometida.
Inventaría qué había en él antes de decidir qué rotar. Claves, cuentas de servicio, tokens de API, usuarios locales, tareas programadas, relaciones de confianza y la canalización de despliegue son todos candidatos, y cada uno tiene un propietario que debería confirmarlo.
ss -lntup
getent passwd
crontab -l
ip route show table allEse listado es la forma más rápida de ver qué ofrecía el host y hasta dónde podía llegar. Conserva primero las pruebas, según el proceso del propietario de la respuesta, porque una reconstrucción destruye exactamente lo que necesita una investigación. NIST SP 800-61 Revisión 3 trata la preparación, la detección, la respuesta y la recuperación como partes de un solo proceso de riesgo, no como una instrucción de reinicio.
Fronteras que abaratan la siguiente
Merece la pena construir cuatro fronteras antes de necesitarlas. Mantén una vía de recuperación independiente que no se autentique a través de la puerta de enlace. Mantén la autoridad de firma separada del host que sirve tráfico. Limita hasta dónde puede llegar la puerta de enlace, para que una puerta de enlace comprometida no sea automáticamente una red de gestión comprometida. Y registra quién posee cada credencial, para que la rotación sea una llamada en lugar de un proyecto de arqueología.
Ninguna de estas cosas impide el compromiso. Lo acotan, y marcan la diferencia entre una mala semana y un mal trimestre.