La resolución DNS y la gestión de los puertos TCP constituyen dos capas de seguridad que a menudo se tratan por separado en las políticas de red de las empresas. Sin embargo, el aislamiento de estos dos temas crea puntos ciegos explotables: un cortafuegos puede filtrar correctamente el puerto 53 mientras deja pasar solicitudes DNS encapsuladas en tráfico HTTPS por el puerto 443. Comprender cómo interactúan estos mecanismos permite endurecer la configuración de la red sin multiplicar las herramientas.
DNS cifrado en el puerto 443: la vulnerabilidad que el filtrado clásico no ve
El filtrado DNS tradicional se basa en la inspección del tráfico que transita por el puerto UDP/53 o TCP/53. Este enfoque funcionaba mientras las solicitudes DNS circulaban en claro por un canal dedicado.
El DNS-over-HTTPS (DoH), transportado por el puerto TCP 443, cambia las reglas del juego. Las solicitudes DNS están encapsuladas en tráfico HTTPS estándar, lo que las hace indistinguibles del resto de la navegación web para un cortafuegos configurado únicamente en función de los números de puerto. El DNS-over-TLS (DoT), que generalmente utiliza el puerto TCP 853, plantea un problema similar pero sigue siendo más fácil de identificar y bloquear.
Según recomendaciones transmitidas por la CISA y Axio Networks, una política de filtrado DNS efectiva debe ahora imponer los resolutores autorizados en cada terminal, incluidos los navegadores que activan el DoH por defecto. Ya no es suficiente con monitorear el puerto 53: las salidas hacia los puertos 443 y 853 también deben ser controladas para detectar resoluciones DNS no autorizadas.
Encontrará información técnica en Open Syd que detalla los mecanismos de endurecimiento aplicables a estas configuraciones.
Puerto TCP 53 y cortafuegos: por qué bloquear TCP provoca fallos DNS
Un error frecuente en la configuración de los cortafuegos consiste en permitir solo el tráfico UDP en el puerto 53, bloqueando TCP/53. La lógica parece razonable: la gran mayoría de las solicitudes DNS comunes utilizan UDP.
En la práctica, TCP/53 sigue siendo necesario para las respuestas DNS voluminosas. Los registros DNSSEC, que añaden firmas criptográficas a las respuestas, superan regularmente el límite de tamaño de los paquetes UDP. Las transferencias de zona entre servidores DNS autoritativos también utilizan exclusivamente TCP. Bloquear este protocolo en el puerto 53 provoca fallos intermitentes difíciles de diagnosticar, porque solo se manifiestan para ciertos tipos de solicitudes o ciertos dominios.
La documentación de Cisco sobre los requisitos DNS para Cisco Secure Access distingue tres roles de red, cada uno de los cuales requiere diferentes reglas de cortafuegos en el puerto 53:
- El puesto cliente, que envía solicitudes al resolutor recursivo interno, puede limitarse a UDP/53 en la mayoría de los casos
- El resolutor recursivo debe poder emitir y recibir en TCP/53 y UDP/53 hacia los servidores autoritativos, de lo contrario no podrá resolver los registros firmados DNSSEC
- El servidor autoritativo requiere TCP/53 abierto para las transferencias de zona y las respuestas voluminosas
Aplicar una regla uniforme a estos tres roles equivale a debilitar la resolución de nombres o a abrir canales innecesarios.
Política de seguridad de red: superar el filtrado por número de puerto
El puerto 443 ya no es un indicador fiable de un uso web clásico. El DoH transita por él, pero también túneles VPN, flujos de aplicaciones propietarias y algunas soluciones de seguridad DNS mismas. Una estrategia basada únicamente en los números de puerto deja pasar tráfico no identificado.
Un enfoque más robusto combina varios parámetros de control:
- La identificación de los resolutores DNS autorizados por su dirección IP, bloqueando cualquier otro resolutor en los puertos 53, 443 y 853
- La inspección de los certificados TLS para distinguir el DoH legítimo del tráfico web estándar en el puerto 443
- La supervisión de aplicaciones que identifica el protocolo real independientemente del puerto utilizado, permitiendo detectar un túnel DNS encapsulado en HTTPS
- El control de los parámetros de configuración de los navegadores para evitar la activación automática del DoH hacia resolutores externos
Esta lógica de defensa en profundidad exige tratar el DNS no como un servicio aislado, sino como un componente transversal del sistema de información. Las reglas de enrutamiento, la gestión de las aplicaciones instaladas en los puestos y la configuración de los sistemas operativos participan todas en la postura DNS de la empresa.
Supervisión DNS y detección de flujos anormales en la red
El refuerzo de las reglas de cortafuegos solo cubre una parte del problema. Un resolutor DNS interno comprometido, o un software malicioso que utiliza el DNS como canal de exfiltración de datos, puede generar tráfico que cumpla con las reglas de filtrado mientras es malicioso.
La supervisión del volumen y la frecuencia de las solicitudes DNS constituye un complemento necesario. Un puesto que emite varios miles de solicitudes hacia un mismo dominio en unos minutos presenta un comportamiento atípico que merece investigación. Del mismo modo, solicitudes hacia nombres de dominio de alta entropía (cadenas de caracteres aleatorios) a menudo señalan un túnel DNS o una comunicación con un servidor de comando y control.
Los retornos de campo divergen sobre el umbral a partir del cual estas alertas se vuelven explotables sin generar demasiados falsos positivos. El tamaño de la red, el número de puestos y la diversidad de las aplicaciones empresariales influyen directamente en la calibración. Un sistema de supervisión DNS mal calibrado genera ruido que termina siendo ignorado por los equipos de seguridad.
La correlación entre los registros DNS y los registros de cortafuegos (puertos TCP abiertos, conexiones salientes inusuales) permite reducir este ruido. Un pico de solicitudes DNS hacia un dominio desconocido, combinado con una conexión TCP saliente en un puerto no estándar desde el mismo puesto, produce una alerta mucho más fiable que un indicador aislado.
El endurecimiento DNS y el control de los puertos TCP no son dos proyectos distintos. Los datos disponibles muestran que los ataques recientes explotan precisamente la intersección entre estas dos capas, donde el DNS cifrado atraviesa puertos considerados seguros. Tratar estos temas juntos, en una política de seguridad de red unificada, sigue siendo el único enfoque que tiene en cuenta la realidad del tráfico actual.
