Un servidor DNS que responde a todas las solicitudes sin distinción, puertos abiertos por defecto que nadie ha revisado desde su puesta en marcha: encontramos este esquema en la mayoría de las redes empresariales. La seguridad de la red a menudo se juega en estos dos ejes descuidados, la gestión de los DNS y el control de los puertos TCP, mucho antes de la compra de un cortafuegos de nueva generación.
Control de los resolutores DNS: el primer candado que colocar en la red
En el terreno, el problema comienza casi siempre en el mismo lugar. Los puestos de trabajo y los objetos conectados envían sus solicitudes DNS a cualquier resolutor, incluidos los resolutores públicos que el administrador no supervisa. Mientras no se restrinjan los resolutores autorizados, se deja un canal de salida invisible.
La primera acción consiste en forzar todo el tráfico DNS hacia un resolutor interno controlado. Se bloquean las solicitudes salientes en el puerto UDP y TCP 53 hacia cualquier destino que no sea este resolutor. Esto permite registrar cada solicitud, detectar dominios sospechosos y cortar las comunicaciones hacia servidores de comando y control (C2).
El cifrado DNS complica este enfoque. DNS over HTTPS (DoH) utiliza el puerto TCP 443, el mismo que el tráfico web clásico, lo que lo hace difícil de filtrar con reglas de red tradicionales. DNS over TLS (DoT) pasa por el puerto TCP 853, más fácilmente identificable.
Para mantener el control, se puede aprender el funcionamiento de Open Syd y elegir una estrategia adecuada: permitir DoT en el puerto 853 hacia el resolutor interno mientras se bloquea DoH en los puestos para evitar que los navegadores eludan la política DNS de la organización.
Puertos TCP abiertos: auditar antes de filtrar
Regularmente se ven servidores con decenas de puertos en escucha, algunos de los cuales corresponden a servicios instalados por defecto y nunca utilizados. Cada puerto abierto es una superficie de ataque potencial. El reflejo consiste en escanear su propio perímetro antes de que un atacante lo haga.
Una auditoría de los puertos TCP y UDP activos, realizada desde el exterior de la red, a menudo revela servicios olvidados: una interfaz de administración en un puerto no estándar, un servicio de base de datos expuesto, un antiguo servidor de correo aún accesible. Cerrar un puerto innecesario reduce el riesgo más eficazmente que una regla de detección.
Priorizar el cierre por nivel de riesgo
No todos los puertos abiertos presentan el mismo peligro. Aquí hay un enfoque de clasificación pragmático:
- Los puertos relacionados con la administración remota (SSH en 22, RDP en 3389, interfaces web en 8080 o 8443) deben ser restringidos a rangos IP internos o accesibles únicamente a través de VPN. Dejarles expuestos en Internet sigue siendo la primera causa de compromiso por fuerza bruta.
- Los puertos de servicios de mensajería (25, 465, 587, 993) merecen un filtrado geográfico estricto si la actividad es local, y una verificación de que los protocolos de cifrado TLS están activados para proteger los datos en tránsito.
- Los puertos utilizados por protocolos no cifrados (Telnet en 23, FTP en 21, HTTP en 80) deberían ser desactivados en favor de sus equivalentes seguros. Si un servicio legado impone su mantenimiento, se aísla este servicio en un segmento de red dedicado.
Registro DNS y correlación con los flujos TCP
Bloquear y filtrar no es suficiente si nunca se observa lo que sucede. El registro de las solicitudes DNS, cruzado con los logs de conexión en los puertos TCP, constituye una herramienta de detección formidable y poco explotada.
Un puesto que resuelve un nombre de dominio inusual, y luego abre una conexión TCP saliente hacia una dirección IP desconocida en un puerto elevado, produce una señal débil. Tomado de forma aislada, cada evento parece inofensivo. Es la correlación entre la solicitud DNS y el flujo TCP la que revela la exfiltración.
La guía NIST SP 800-81 Revisión 3, publicada el 19 de marzo de 2026, insiste en esta noción de visibilidad operativa. Agrupa DoH, DoT y DoQ bajo la categoría “DNS cifrado” y recomienda tratar el DNS no solo como una simple infraestructura de fondo, sino como un punto de control de seguridad en sí mismo.
Lo que el registro debe capturar
Para ser utilizable, un registro DNS debe registrar como mínimo el nombre de dominio solicitado, la dirección IP de origen, la marca de tiempo y la respuesta devuelta. En cuanto a los puertos TCP, se conservan las conexiones establecidas, rechazadas y los intentos de conexión fallidos. Los retornos varían sobre la duración de retención ideal, pero el reglamento de ejecución europeo 2024/2690, aplicable desde el 7 de noviembre de 2024, impone a ciertos proveedores de servicios DNS e infraestructura un registro continuo con prueba de efectividad de los controles.
DNSSEC y cifrado: proteger la integridad de las respuestas DNS
Un resolutor que responde correctamente no garantiza que la respuesta no haya sido alterada en el camino. La intoxicación de caché DNS redirige a los usuarios hacia servidores fraudulentos sin que se dispare ninguna alerta en el lado de la red. DNSSEC añade una firma criptográfica a los registros de zona para validar su autenticidad.
DNSSEC valida el origen de las respuestas, el cifrado DNS protege su confidencialidad en tránsito: los dos mecanismos se complementan, ninguno reemplaza al otro.
En la práctica, desplegar DNSSEC en sus zonas internas implica gestionar la renovación de las claves criptográficas. Una clave expirada sin rotación programada provoca una falla de resolución tan brusca como un ataque. Se automatiza la rotación o no se despliega.
Política de seguridad de red: unir DNS y puertos en un enfoque unificado
Tratar los DNS por un lado y los puertos por otro crea ángulos muertos. Un servicio autorizado por el cortafuegos pero que resuelve dominios maliciosos pasará desapercibido. A la inversa, un bloqueo DNS sin control de puertos deja la puerta abierta a conexiones directas por dirección IP.
El enfoque coherente une las tres capas:
- El resolutor DNS interno filtra los dominios y registra las solicitudes.
- El cortafuegos restringe los puertos TCP y UDP solo a los servicios declarados y mantenidos.
- Una herramienta de correlación (SIEM o simple script de análisis de logs) cruza los eventos DNS y las conexiones de red para identificar comportamientos anormales.
Esta articulación no exige un presupuesto considerable. Un resolutor filtrante, reglas de cortafuegos revisadas trimestralmente y un conjunto de logs consultado cada semana cubren la mayoría de las vulnerabilidades relacionadas con los DNS y los puertos. El eslabón más débil no es la herramienta, es la regularidad de la revisión.
