Seguridad DNS: Clave para Bloquear Amenazas y Detectar Tunelización

El DNS (Domain Name System) es uno de los sistemas de infraestructura fundamentales de Internet. Su función principal es sencilla y clara: traducir nombres de dominio legibles por humanos (por ejemplo, example.com) a direcciones IP, que las computadoras utilizan para el enrutamiento y el intercambio de datos.

En esencia, DNS es la “agenda telefónica” distribuida de la red: mientras un nombre no se resuelva, la conexión, en la mayoría de los casos, simplemente no se establecerá.

Sin embargo, el DNS rara vez se considera una línea de defensa, y esto constituye un error estratégico. El DNS opera en las primeras etapas de la mayoría de las interacciones de red y, por lo tanto, es ideal para el control, la detección y la contención de amenazas.

Prácticamente cualquier ataque moderno deja un rastro en el DNS. En términos de la kill chain (cadena de ataque) de un ataque, el DNS a menudo proporciona una de las primeras señales que se pueden detectar incluso antes de que aparezcan signos evidentes de compromiso en el host.

¿Por qué el DNS es uno de los vectores favoritos de los atacantes?

Imagina que el perímetro de mi red es una fortaleza. He cerrado todas las puertas y colocado guardias en las murallas. Sin embargo, hay un túnel debajo de la muralla que nadie vigila, aunque se sospecha de su existencia, y este túnel se llama DNS (tradicionalmente UDP/53). En muchas redes, el DNS sigue siendo uno de los pocos protocolos que permitirás mantener abiertos.

El DNS ha estado operativo desde 1983, y la seguridad en DNS como tal no fue incorporada en su diseño original; fue proyectado para una red interna aislada con el objetivo de garantizar velocidad y fiabilidad.

Se asumía que los servidores DNS operarían dentro de una red confiable. Sin embargo, con el surgimiento de los trabajadores remotos, a las empresas les resulta cada vez más difícil cumplir con los estándares actuales de seguridad de la información, lo que, en conjunto con la ausencia de análisis de tráfico DNS en la mayoría de los casos, conduce a graves consecuencias para el negocio.

En la práctica, una serie de artefactos de red pueden indicar directamente el compromiso de un sistema.

En primer lugar, el software malicioso a menudo realiza la resolución DNS de dominios de servidores C2 (Command & Control), a través de los cuales se gestionan los nodos infectados. La presencia de consultas DNS regulares a dichos dominios puede servir como indicador de infección.

En segundo lugar, el DNS puede utilizarse como canal de exfiltración de datos. En este caso, la información se transmite en pequeños fragmentos codificados en consultas DNS (por ejemplo, dentro de subdominios o registros TXT), pero debido a un gran número de solicitudes consecutivas, se forma un flujo continuo de transmisión de datos.

Cabe destacar aparte la infraestructura de phishing. Esta generalmente se despliega en dominios visual o semánticamente similares a recursos legítimos y, por lo general, existe por un tiempo limitado antes de que el dominio sea bloqueado. Para profundizar en cómo se usan estos dominios, te recomiendo leer sobre el ataque homógrafo Punycode.

Arquitectura de protección DNS

Antes de configurar cualquier elemento, es fundamental comprender cómo está organizado el sistema de nombres de dominio. A continuación, se presenta la jerarquía DNS, que incluye varios niveles.

Los servidores raíz no son numerosos: existen 13 identificadores de servidores raíz (A-root a M-root). Sin embargo, cada uno de ellos está replicado mediante anycast en cientos de instancias distribuidas por todo el mundo. Estos servidores contienen información sobre los dominios de nivel superior y dirigen las solicitudes a los servidores correspondientes.

Los dominios de nivel superior son responsables de zonas como .es .com, etc. Dirigen las solicitudes a los servidores autoritativos, que contienen información más detallada sobre los dominios de segundo nivel.

Los resolvedores recursivos son un componente crucial del DNS que actúan como intermediarios entre el usuario final y la red de servidores DNS. Su protección es una de las claves para la organización.

El primer paso para implementar una protección eficaz es la separación de los servidores autoritativos y los resolvedores recursivos. Junto con esto, es necesario deshabilitar la recursión en los servidores autoritativos.

Es importante comprender que la seguridad DNS no es una única herramienta, sino el uso de un conjunto de ellas.

A continuación, se presenta un esquema de protección mínima que cubrirá diversas amenazas.

La idea clave de la protección es que el bloqueo y la detección son tareas diferentes. El bloqueo debe ser rápido y confiable, mientras que la detección debe ser minuciosa y con una cantidad mínima de falsos positivos. Mezclarlos en el mismo lugar es un camino seguro para que todo sea bloqueado o nada sea detectado.

Bloqueo de dominios maliciosos: cómo no dispararte en el pie

El enfoque más simple y obvio para protegerse contra dominios maliciosos es tomar una lista de todos los dominios “malos” y responder con NXDOMAIN (es decir, nombre inexistente) a cualquier consulta dirigida a ellos. Esto suena bastante sencillo. Implementarlo tampoco será difícil. Pero recibir una llamada de un CEO enfurecido al que se le ha bloqueado una herramienta de trabajo es aún más fácil.

A continuación, presento algunas reglas de supervivencia para el bloqueo DNS:

• Nunca utilices una única fuente de indicadores de compromiso (IoC). Es necesario emplear un mínimo de tres con diferentes metodologías.
• Implementa la lista de bloqueo de forma gradual: primero utiliza el modo de auditoría (registra, pero no bloquea), luego el modo de advertencia y, finalmente, el bloqueo.
• Para los recursos empresariales críticos, siempre es necesario introducir listas blancas. Es imprescindible actualizarlas periódicamente con una implementación automática desde la CMDB, por ejemplo.
• Debo configurar alertas (notificaciones) para cualquier intento de acceso a dominios bloqueados; esto, por sí mismo, es una señal muy valiosa.

Si se siguen estas reglas, el riesgo de bloqueo de recursos críticos será mínimo. Y mi teléfono no será bombardeado por empleados enfadados que no tienen acceso a datos importantes.

Response Policy Zones (RPZ): la navaja suiza del filtrado DNS

RPZ es un mecanismo estándar para DNS Firewall, soportado por BIND, PowerDNS y diversas soluciones comerciales. Permite implementar políticas personalizadas sobre el DNS estándar.

El principio de funcionamiento es bastante sencillo: yo creo una zona especial donde se enumeran los dominios “malos” y se especifica qué respuesta se debe dar ante una consulta hacia ellos.

Importante: La política NXDOMAIN es más agresiva que la redirección a una página de bloqueo. La primera indica “el dominio no existe”, la segunda muestra claramente que el acceso ha sido bloqueado por política de seguridad del DNS. En entornos corporativos, una página de bloqueo informativa suele reducir las llamadas al servicio de asistencia.

Hoy el panorama DNS incluye también variantes cifradas como DNS over HTTPS (DoH) y DNS over TLS (DoT). Muchos navegadores y sistemas operativos pueden utilizarlas por defecto, lo que reduce la visibilidad del tráfico DNS tradicional basado en UDP/53.

En entornos corporativos esto introduce un problema operativo claro: los usuarios pueden resolver dominios directamente contra resolvers públicos cifrados y saltarse controles DNS locales. Por eso muchas organizaciones fuerzan el uso del resolvedor corporativo mediante políticas de red, bloquean resolvers externos conocidos o utilizan gateways que aplican filtrado DNS centralizado.

Filtrado por categorías: trabajando con “zonas grises”

La presencia de indicadores de compromiso (IoC) basados en reputación es beneficiosa, pero estos solo abordan las amenazas conocidas. Surge la pregunta: ¿qué hacer con los dominios registrados recientemente? Aquellos que, por ejemplo, fueron registrados hace tres días y no han sido incluidos en ninguna fuente de IoC.

La respuesta a esta pregunta es bastante sencilla: el filtrado por características del dominio, es decir, por categorías. Aquí tienes algunas prácticas efectivas:

• Antigüedad del dominio inferior a 7-14 días: bloquéalo o exige su presencia explícita en una lista blanca (con excepciones controladas). La mayoría de infraestructuras de phishing y C2 aparecen en dominios recién registrados, mientras que los recursos corporativos legítimos rara vez surgen de forma repentina.
• Entropía del nombre de dominio superior a 3.5: Los dominios generados por algoritmos (DGA) poseen una entropía elevada (ejemplo: abc123xqz.com — sospechoso; google.com — no).
• Longitud del subdominio superior a 50 caracteres: un indicio típico de tunelización DNS o DGA.
• Múltiples subdominios únicos de un mismo dominio: si, por ejemplo, en una hora se realizaron 500 solicitudes a diferentes subdominios de un mismo dominio, esto no es una CDN, es un túnel.

DNSSEC como herramienta para proteger la integridad

Al abordar la seguridad DNS, es obligatorio mencionar DNSSEC: la extensión que permite construir una cadena de confianza criptográfica entre las zonas DNS. Su objetivo principal es evitar la manipulación de respuestas DNS, por ejemplo en ataques de envenenamiento de caché o compromisos de resolvedores.

DNSSEC añade firmas criptográficas a los registros DNS y permite que los resolvedores validadores verifiquen si una respuesta ha sido alterada. Si la firma no coincide, la respuesta simplemente se descarta. Para una comprensión más profunda de su funcionamiento, recomiendo revisar la introducción oficial al estándar DNSSEC del IETF.

Cada zona DNS posee un par de claves pública y privada. El propietario de la zona firma los registros con la clave privada, mientras que la clave pública se publica mediante registros DNSKEY. La cadena de confianza se establece mediante registros DS en la zona padre, lo que permite a los resolvedores validar progresivamente la autenticidad de los datos. Para detalles técnicos sobre los registros, puedes consultar el documento que describe los registros DNSSEC.

DNSSEC protege contra ataques como el envenenamiento de caché DNS (DNS cache poisoning), la manipulación de respuestas DNS y ciertas formas de secuestro de tráfico basadas en falsificación de respuestas. Si deseas una explicación más clara y simplificada, Cloudflare ofrece una guía útil.

Detección de tunelización DNS: atrapando al topo

La tunelización DNS es, en esencia, el proceso de abuso del protocolo DNS para transmitir datos arbitrarios. El atacante codifica la carga útil (payload) en el nombre de dominio (por ejemplo, base32 o base64), y el servidor DNS que participa en el ataque la decodifica en el otro extremo. Herramientas como dnscat2 y DNSExfiltrator lo hacen con unos pocos clics.

¿Por qué es esto realmente peligroso? Porque el tráfico DNS está permitido casi en todas partes. Incluso en la red más restrictiva, UDP/53 suele estar abierto. Por lo tanto, a través de él se puede tanto comandar un bot como robar datos silenciosamente, lo que lo convierte en un método de exfiltración de datos por DNS muy efectivo. Para entender mejor este concepto, puedes revisar mi artículo sobre robo de datos.

Caso real: En 2020, el grupo OilRig (también conocido como APT34) de Irán utilizó la tunelización DNS para comunicaciones C2 en un ataque a una empresa de telecomunicaciones en Oriente Medio. El tráfico se presentaba como solicitudes DNS ordinarias a dominios de apariencia legítima, lo que hacía su detección prácticamente imposible con medios estándar. Los atacantes emplearon la herramienta DNSExfiltrator, que era nueva en ese momento. Para un análisis técnico detallado de este tipo de campañas, recomiendo la lectura de este análisis de Palo Alto Networks.

Indicadores estadísticos de tunelización

En todo esto hay una buena noticia: la tunelización misma deja rastros. Sin embargo, inmediatamente surge la mala: solo son visibles mediante el análisis de tráfico DNS de patrones, no de solicitudes individuales.

Es decir, existen dos métodos para detectar el abuso de DNS:

• Análisis de la “carga útil”, es decir, la búsqueda de anomalías en los datos transmitidos en ambas direcciones mediante métodos estadísticos.
• Análisis del número de solicitudes DNS por subdominio en comparación con un nivel promedio normal.

Por lo tanto, se pueden identificar algunas anomalías que se deben buscar para una eficaz detección de anomalías DNS:

• Longitud promedio de la consulta: En una red corporativa típica, la longitud del nombre de dominio completo (FQDN) suele mantenerse relativamente corta y repetitiva. Un aumento significativo de la longitud promedio de las consultas o la aparición frecuente de subdominios muy largos puede indicar actividad DGA o un intento de transmisión de datos a través de DNS. Es crucial evaluar la desviación respecto al perfil estadístico propio de la red.
• Número de subdominios únicos de un mismo dominio por unidad de tiempo: Para la mayoría de los servicios legítimos, el número de subdominios diferentes a los que un cliente accede en una hora es limitado. Un aumento brusco en el número de subdominios únicos (decenas y cientos por hora para un mismo dominio base) es una característica distintiva de la tunelización DNS o de nombres generados algorítmicamente.
• Frecuencia y regularidad de las solicitudes a un mismo dominio: En el tráfico de usuario normal, las solicitudes se distribuyen de manera irregular y dependen de la actividad del usuario y de las aplicaciones. La aparición de solicitudes DNS estrictamente regulares y periódicas con un intervalo fijo (beaconing) puede indicar comunicación C2.

Existen varias utilidades que resultarán útiles para la detección de tunelización DNS:

• reassemble_dns: una utilidad de Python que abre archivos .pcap y analiza las solicitudes DNS.
• dnsHunter: un módulo de Python que lee archivos .pcap, extrae solicitudes DNS y realiza la geolocalización, lo que ayudará posteriormente en el análisis.

Conclusión: por dónde empezar ahora mismo

Si has leído hasta este punto y deseas comenzar a proteger eficazmente tu servidor DNS, aquí tienes una hoja de ruta práctica para implementar la seguridad DNS:

• Paso 1: Es necesario habilitar el registro completo de DNS en los resolvedores utilizados.
• Paso 2: Conecta 2-3 fuentes de Threat Intelligence (inteligencia de amenazas) y ejecútalas en modo de auditoría durante una semana.
• Paso 3: Configura un monitoreo básico de anomalías: consultas largas, estructura regular, tipos de registros poco comunes.
• Paso 4: Identifica los sistemas críticos y añádelos a una lista blanca para evitar bloqueos.
• Paso 5: Habilita el bloqueo de forma gradual, comenzando por el departamento de TI. Es necesario medir la Tasa de Falsos Positivos (FPR), es decir, la proporción de ejemplos negativos incorrectamente percibidos como positivos.

El DNS no es solo infraestructura, es inteligencia. Entender qué es el DNS es el primer paso.

Cada consulta es una señal de intenciones. Un atacante no puede ocultar el hecho de la comunicación, solo puede intentar disfrazarla. La seguridad DNS es la capacidad de leer entre líneas estas señales. Y cuanto antes comiences a leer, menos sorpresas tendrás el próximo año.