Por qué bloquear los puertos de VPN no detiene los túneles no autorizados

Una regla de cortafuegos deniega el tráfico con el que coincide. No deniega todos los usos de una conexión que permite, y esa laguna es donde fallan la mayoría de las políticas contra túneles no autorizados. Bloquear los puertos del cliente que fuera popular hace cinco años deja intacto todo lo que viaja por 443, y no dice nada sobre un dispositivo que puede reescribir sus propias rutas. Construya el control en torno a la autoridad y los destinos, y luego lea los flujos que realmente permite.

Por qué una lista de puertos no es una política

Los puertos son un concepto de la capa de transporte, y varias tecnologías de túnel no usan ninguno. Otras comparten deliberadamente un puerto con el tráfico web ordinario porque ese puerto es el que tiene garantizado el paso. Una regla basada en un puerto histórico enumera, por tanto, un puñado de implementaciones en lugar de la clase de comportamiento. También envejece mal: en el momento en que un proveedor cambia sus valores predeterminados, la lista describe el pasado.

Peor aún, un bloqueo exitoso en un puerto puede leerse como prueba de que todo el problema está resuelto, lo que retrasa los controles que sí habrían importado.

Los números de protocolo y los puertos son espacios de nombres distintos

A GRE se le asigna el número de protocolo IP 47. No es el puerto TCP 47 ni el puerto UDP 47, y un filtro escrito para un puerto no lo toca. ESP y AH ocupan los números de protocolo 50 y 51 con la misma propiedad. El tráfico encapsulado también puede esconderse dentro de una conexión permitida, por lo que una categoría o firma puede ayudar, pero nunca certifica el propósito por sí sola. La confianza y la cobertura pertenecen a un producto y una versión concretos, no al concepto.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

El primer comando muestra lo que realmente escribió; el segundo muestra la tabla de protocolos que conoce la pila; el tercero muestra cuántas sesiones están usando el puerto web en este momento. Ninguno de ellos dice para qué sirven esas sesiones. La interceptación de TLS es una decisión aparte con sus propios costes de confianza, privacidad y compatibilidad con los clientes. No es un requisito previo para denegar un destino con nombre, y tampoco es una garantía de reconocimiento de túneles.

Controle la autoridad que tiene el dispositivo

Un dispositivo que puede cambiar su propia tabla de rutas y su filtrado tiene capacidades que una aplicación ordinaria no tiene. La gestión de admisión y de configuración es lo que elimina esa capacidad, y actúa con independencia del puerto que fuera a usar el túnel.

Eso significa que los adjuntos aprobados reciben su rol declarado en lugar de permiso sin restricciones para reenviar por otros dispositivos, y significa que los derechos de instalación y de administración de red forman parte de la política en lugar de ser un añadido.

Observe los flujos que quedan. Correlacione la identidad del dispositivo, el rol asignado y los metadatos del flujo, y trate la clasificación como evidencia con límites en lugar de como veredicto.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

Una sesión cifrada de larga duración o un gran recuento de bytes no son prueba de uso indebido: las copias de seguridad, las herramientas de soporte y los enlaces entre sedes se ven igual. Mantenga la recopilación limitada a la investigación y conserve lo que encuentre bajo el proceso que lo posee.

Haga explícitas las excepciones

Todo entorno tiene destinos que deben seguir siendo accesibles para actualizaciones, autenticación y recuperación. Anótelos con un propósito y un responsable, y revíselos en lugar de descubrirlos una caída tras otra.

Cuando el negocio permite de verdad un servicio externo amplio, evalúe la autoridad que ese servicio proporciona en lugar de suponer que la etiqueta del destino hace aceptable cualquier uso.

Una excepción no revisada es un agujero con un número de ticket. Una excepción con un nombre, un motivo y una fecha de revisión es una decisión.

Acepte con un plan escrito, no con un eslogan

La aceptación tiene dos mitades: el trabajo aprobado sigue teniendo éxito y los casos prohibidos concretos fallan en una prueba autorizada. Ambas deben escribirse antes del cambio y repetirse después.

Incluya los cambios de punto final y de política en esa revisión, porque una ruta añadida en un portátil puede deshacer un filtro que funcionaba perfectamente en el borde.

El entregable es un límite de salida con propietario y una lista conocida de riesgo restante. Afirmar que unos cuantos puertos cerrados acabaron con el uso no autorizado de VPN no es eso.