El DNS asocia un nombre de dominio legible a una dirección IP utilizable por los equipos de red. Los puertos TCP, por su parte, determinan qué servicios aceptan o rechazan una conexión entrante. Estos dos mecanismos, a menudo configurados una vez y luego olvidados, son sin embargo vectores de ataque privilegiados cuando se gestionan mal.
Resolución DNS y superficie de ataque: lo que cambia el cifrado
Por defecto, las consultas DNS circulan en claro por el puerto UDP 53. Un atacante situado en la red puede interceptar estas consultas, modificarlas o redirigir el tráfico hacia un servidor malicioso. El filtrado DNS clásico se basa precisamente en esta visibilidad: el administrador inspecciona las consultas para bloquear los dominios peligrosos.
La llegada de DNS over HTTPS (DoH) altera este equilibrio. DoH encapsula las consultas DNS en tráfico HTTPS estándar, por el puerto TCP 443. El contenido de las consultas se vuelve invisible para las herramientas de supervisión de red. Un equipo configurado para utilizar un resolvedor DoH externo puede así eludir todo el filtrado DNS de la empresa sin activar ninguna alerta.
La solución no consiste en bloquear DoH a ciegas. El enfoque recomendado es definir un resolvedor DNS autorizado internamente, compatible con DoH o DoT (DNS over TLS, puerto 853), y luego forzar su uso en los equipos a través de políticas de grupo o un MDM.
Las consultas hacia resolvedores externos no aprobados se bloquean entonces a nivel del cortafuegos. Esta configuración preserva la confidencialidad de los intercambios DNS mientras mantiene la capacidad de filtrado, como detalla la guía de seguridad en Open Syd en su sección dedicada al endurecimiento de las políticas de red.
Puertos TCP abiertos: reducir la superficie expuesta de la red
Cada puerto TCP abierto en un servidor representa un punto de entrada potencial. Un servicio que escucha en un puerto no utilizado o no supervisado ofrece una oportunidad directa a un atacante para intentar una conexión, explotar una vulnerabilidad o establecer un canal de comando.
Identificar los puertos realmente necesarios
El primer paso es un inventario. Demasiados entornos mantienen puertos abiertos heredados de configuraciones antiguas: servicios de prueba, interfaces de administración temporales, protocolos obsoletos. Un escaneo regular de los puertos expuestos, desde el exterior de la red, a menudo revela servicios cuya existencia nadie sospechaba.
Los puertos a supervisar con prioridad:
- El puerto 53 (DNS) debe estar restringido a los únicos servidores DNS internos autorizados, y el tráfico DNS saliente hacia resolvedores externos no aprobados bloqueado en el cortafuegos
- El puerto 443 (HTTPS) merece una inspección particular ya que DoH transita por él, haciendo posible la exfiltración de datos o el eludir políticas de seguridad
- Los puertos de administración remota (22 para SSH, 3389 para RDP) nunca deben estar expuestos directamente a internet sin una puerta de enlace intermedia o VPN
- Los puertos asociados a servicios legacy (Telnet en el puerto 23, FTP en el puerto 21) deberían ser desactivados en favor de sus equivalentes cifrados
Aplicar el principio de menor privilegio a los flujos de red
Cada regla de cortafuegos debería especificar una fuente, un destino y un puerto preciso. Las reglas “cualquiera a cualquiera” en un puerto dado equivalen a dejar una puerta abierta a cualquiera que conozca la dirección. La segmentación de red complementa este enfoque: colocar los servidores DNS en un segmento dedicado limita la propagación lateral en caso de compromiso.
DNSSEC y protección de la cuenta DNS: dos capas complementarias
DNSSEC firma criptográficamente las respuestas DNS para garantizar que la información recibida por el cliente corresponde efectivamente a la publicada por el servidor legítimo. Sin esta validación, un atacante puede inyectar respuestas falsas (envenenamiento de caché) y redirigir el tráfico hacia servidores maliciosos sin que el usuario detecte nada.
La implementación de DNSSEC sigue siendo un tema operativo tanto como criptográfico. Errores de configuración, especialmente en la rotación de claves de firma, pueden provocar interrupciones del servicio. La activación requiere, por lo tanto, pruebas previas y un procedimiento de reversión documentado.
Un aspecto a menudo descuidado se refiere a la protección de la cuenta que administra los registros DNS. Tomar el control de esta cuenta permite modificar directamente las respuestas DNS, redirigir el tráfico o generar certificados TLS fraudulentos. La agencia estadounidense CISA recomienda proteger estos accesos mediante autenticación multifactor, auditar regularmente los registros publicados y monitorear los registros de Certificate Transparency para detectar cualquier emisión de certificado no autorizada.
Directiva NIS2 y gestión de riesgos DNS en Europa
La directiva europea NIS2 amplía el ámbito de las entidades sujetas a obligaciones de ciberseguridad. Los proveedores de servicios DNS figuran explícitamente entre las entidades afectadas. El reglamento de ejecución europeo 2024/2690 precisa los requisitos técnicos esperados, especialmente en materia de gestión de riesgos cibernéticos.
Para las organizaciones que operan su propia infraestructura DNS, esta evolución regulatoria implica formalizar varias prácticas:
- Documentar la política de gestión de zonas DNS, incluidos los transferencias de zona y los mecanismos de replicación
- Implementar un registro de modificaciones de registros y accesos a los servidores DNS
- Integrar los componentes DNS en el ámbito de las auditorías de seguridad periódicas
Estos requisitos no son nuevos desde el punto de vista técnico. NIS2 los convierte en obligatorios desde el punto de vista legal, con sanciones en caso de incumplimiento.
El dominio conjunto del DNS y de los puertos TCP forma una base de seguridad de red que ni los cortafuegos de aplicaciones ni los antivirus pueden reemplazar. Un resolvedor DNS correctamente configurado y puertos estrictamente filtrados reducen la superficie de ataque incluso antes de que una herramienta de detección entre en juego.
