Prevención de la suplantación de DNS y el envenenamiento de caché

Cada visita a un sitio web, cada entrega de correo y la mayoría de las llamadas a una API empiezan con una consulta DNS. Si un atacante consigue que esa consulta devuelva una dirección equivocada, el usuario acaba hablando con el servidor incorrecto mientras la barra de direcciones sigue mostrando el nombre de dominio correcto. Esa es la esencia del DNS spoofing, y su forma más dañina, el envenenamiento de caché, puede afectar a miles de usuarios a la vez. Esta guía explica cómo funcionan estos ataques a nivel conceptual, por qué un descubrimiento de 2008 cambió la forma de construir los resolutores y qué defensas deberían tener hoy los propietarios de dominios y los operadores de red. El enfoque es exclusivamente defensivo: entender la debilidad lo suficiente como para cerrarla.

Qué son realmente el DNS spoofing y el envenenamiento de caché

El DNS spoofing (suplantación de DNS) es un término amplio que abarca cualquier situación en la que un cliente recibe una respuesta DNS que no procede de la fuente legítima. Puede ocurrir en una red Wi-Fi comprometida, mediante malware que modifica el archivo hosts local o a través de un servidor DNS fraudulento que reparte un router malicioso.

El envenenamiento de caché es una variante concreta y más grave. Los resolutores recursivos, como los que gestionan los proveedores de internet, las empresas y los servicios de DNS públicos, guardan respuestas en caché para ahorrar tiempo. Si un atacante convence a un resolutor de aceptar y almacenar un registro falsificado, el resolutor servirá ese registro falso a todos los clientes que pregunten por el nombre hasta que caduque su tiempo de vida (TTL). Una sola inyección con éxito puede, por tanto, redirigir a una gran población de usuarios sin tocar ninguno de sus dispositivos.

La razón de fondo es histórica. El DNS clásico funciona sobre todo sobre UDP, un protocolo sin conexión, y el diseño original daba por hecho que la red era razonablemente fiable. Un resolutor aceptaba la primera respuesta verosímil que coincidiera con su pregunta pendiente. No existía ninguna forma integrada de demostrar de dónde venía una respuesta.

Cómo decide un resolutor si confía en una respuesta

Cuando un resolutor envía una consulta a un servidor autoritativo, más tarde recibe una respuesta y tiene que decidir si pertenece a la pregunta que hizo. Tradicionalmente comprueba unos pocos campos:

• La sección de pregunta debe coincidir con el nombre y el tipo consultados.
• El ID de transacción, un número de 16 bits, debe coincidir con el usado en la consulta.
• La respuesta debe llegar desde la dirección IP y el puerto a los que se envió la consulta, y de vuelta al puerto de origen que usó el resolutor.

Si todo coincide, la respuesta se acepta. Un atacante fuera de la ruta, que no puede ver el tráfico real, tiene que adivinar estos valores. Antes de 2008, muchos resolutores usaban un puerto de origen fijo o predecible, con lo que solo quedaba el ID de transacción de 16 bits: apenas 65.536 posibilidades. Es un espacio de búsqueda pequeño para un atacante decidido que pueda enviar muchos paquetes rápidamente.

El ataque Kaminsky de 2008 y por qué fue tan importante

Las debilidades de los ID de transacción se conocían mucho antes de 2008, pero los defensores se consolaban con la propia caché: una vez que un resolutor tenía guardada una respuesta válida, el atacante debía esperar a que caducara el TTL para volver a intentarlo. En 2008, el investigador de seguridad Dan Kaminsky demostró que ese consuelo era infundado.

Su idea, descrita aquí solo a grandes rasgos, era que el atacante no necesitaba competir con el resolutor por el nombre exacto que quería secuestrar. Provocando consultas de muchos subdominios distintos e inexistentes, podía generar una carrera nueva cada vez, y una respuesta falsificada podía incluir registros adicionales que apuntaran todo el dominio a servidores de nombres controlados por el atacante. La protección del TTL largo desaparecía, y un resolutor predecible podía envenenarse en poco tiempo.

La revelación dio lugar, en julio de 2008, a una publicación de parches coordinada entre fabricantes de una forma poco habitual. La corrección que se desplegó en todas partes no fue un rediseño del DNS, sino una manera de dificultar muchísimo las conjeturas: la aleatorización del puerto de origen. Kaminsky y otros dejaron claro que se trataba de una mitigación y que la respuesta a largo plazo era la validación criptográfica mediante DNSSEC.

Mitigaciones por capas dentro del resolutor

Los resolutores modernos combinan varias técnicas que añaden imprevisibilidad a cada consulta, de modo que un atacante fuera de la ruta tiene mucho más que adivinar.

Aleatorización del puerto de origen

En lugar de enviar todas las consultas desde el mismo puerto UDP, el resolutor elige un puerto de origen aleatorio para cada consulta dentro de un rango amplio. Combinado con el ID de transacción aleatorio de 16 bits, esto multiplica por decenas de miles el número de valores que el atacante debe adivinar. Convirtió un ataque práctico en otro mucho más costoso, y por eso se convirtió en la respuesta estándar en 2008. Tenga en cuenta que algunos dispositivos NAT y cortafuegos reescriben los puertos de origen de forma predecible, lo que puede anular esta protección sin que nadie lo note; conviene comprobar el comportamiento del perímetro de la red.

Codificación 0x20 (aleatorización de mayúsculas)

Los nombres DNS no distinguen entre mayúsculas y minúsculas, pero la mayoría de los servidores autoritativos copian la pregunta en su respuesta exactamente como la recibieron. La técnica conocida como codificación 0x20, llamada así por el bit que diferencia las letras ASCII mayúsculas de las minúsculas, aleatoriza las mayúsculas del nombre consultado, por ejemplo wWw.ExAmPlE.cOm. El resolutor comprueba después que la respuesta conserve el mismo patrón. Cada letra aporta aproximadamente un bit de entropía. Es menos eficaz con nombres cortos y debe tolerar servidores que no conservan las mayúsculas, así que los resolutores suelen aplicarla con mecanismos de respaldo.

Otras comprobaciones del resolutor

• Comprobación de bailiwick: descartar los registros de una respuesta que queden fuera de la zona para la que el servidor es autoritativo.
• Tratamiento reforzado de los registros glue: impedir que los registros de la sección adicional sobrescriban datos de confianza ya almacenados.
• Limitación de tasa y umbrales de respuestas no deseadas: detectar avalanchas de respuestas que no coinciden y reaccionar, por ejemplo reintentando por TCP.
• Minimización de QNAME (RFC 7816 y después RFC 9156): enviar a cada servidor solo la parte necesaria del nombre, lo que reduce la filtración de datos.

La tabla siguiente resume qué protege cada control y dónde están sus límites.

DNSSEC: demostrar que una respuesta es auténtica

Todas las mitigaciones anteriores dificultan la falsificación, pero ninguna permite al resolutor demostrar que un registro es auténtico. DNSSEC sí. El propietario de la zona firma sus registros con claves privadas, publica las claves públicas correspondientes como registros DNSKEY, y la zona padre publica un registro DS que avala la clave de la zona hija. Un resolutor validador sigue esta cadena de confianza desde la raíz hasta el registro recibido. Si la firma no se verifica, el resolutor devuelve un fallo (SERVFAIL) en lugar de una respuesta posiblemente falsificada.

Para los propietarios de dominios, esto significa que la medida más eficaz que pueden tomar personalmente contra el envenenamiento de caché de sus propios nombres es firmar su zona y asegurarse de que el registro DS esté publicado en el registro del TLD a través de su registrador. Tratamos la configuración y sus trampas en detalle en por qué DNSSEC es esencial para la seguridad de un dominio. Dos advertencias prácticas: las rotaciones de claves deben planificarse, y si cambia de proveedor DNS debe actualizar o eliminar el registro DS; de lo contrario, los resolutores validadores tratarán su dominio como roto.

DNS cifrado: DoT y DoH

DNSSEC autentica los datos, pero no los oculta, y el salto entre un portátil o un móvil y su resolutor suele ser la parte más expuesta del recorrido, sobre todo en redes Wi-Fi públicas. Dos estándares cifran ese salto:

• DNS over TLS (DoT), definido en la RFC 7858, envuelve el DNS en TLS sobre un puerto dedicado, el 853. A los operadores de red les resulta fácil identificarlo y gestionarlo.
• DNS over HTTPS (DoH), definido en la RFC 8484, transporta los mensajes DNS dentro de HTTPS por el puerto 443, de modo que se confunde con el tráfico web normal y lo admiten ampliamente navegadores y sistemas operativos.

Ambos impiden que un atacante situado en la ruta lea o altere en silencio las respuestas entre el cliente y el resolutor, siempre que el cliente autentique el certificado del resolutor. Ninguno sustituye a DNSSEC: si el propio resolutor ha sido envenenado, un canal cifrado entregará fielmente la respuesta envenenada. La postura más sólida combina un transporte cifrado con un resolutor que valide.

Cómo endurecer sus propios resolutores

Si gestiona resolutores recursivos para una oficina, un centro de datos o clientes, unas pocas decisiones de configuración marcan una diferencia notable:

1. No opere un resolutor abierto. Restrinja la recursión a sus propias redes. Los resolutores abiertos se usan para ataques de amplificación y ofrecen a los atacantes un objetivo fácil.
2. Separe las funciones autoritativa y recursiva. Un servidor que responde por sus zonas no debería hacer también recursión para todo internet.
3. Active la validación DNSSEC y mantenga actualizado automáticamente el ancla de confianza de la raíz.
4. Mantenga el software al día. Los proyectos de resolutores publican con regularidad correcciones para debilidades relacionadas con la caché.
5. Limite los TTL de caché a máximos razonables y active las protecciones contra respuestas no deseadas.

Un ejemplo mínimo para el resolutor Unbound podría ser este:

server:
    interface: 10.0.0.53
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes
    use-caps-for-id: yes
    qname-minimisation: yes
    unwanted-reply-threshold: 10000000
    cache-max-ttl: 86400

El equivalente en BIND restringiría la recursión con una lista de control de acceso y activaría la validación:

acl internal { 10.0.0.0/8; 127.0.0.1; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
    dnssec-validation auto;
};

Pruebe siempre los cambios en un entorno de preproducción, ya que las opciones de endurecimiento estrictas pueden poner al descubierto zonas de terceros mal configuradas.

Monitorización y comprobaciones para propietarios de dominios

La mayoría de las organizaciones no gestionan resolutores para el público, pero sí poseen dominios cuyas respuestas pueden ser objetivo de ataques. Una rutina práctica incluye:

• Comprobar que sus servidores de nombres y los datos del registrador no han cambiado de forma inesperada. Una consulta rápida con la herramienta WHOIS y RDAP de TLDix muestra los servidores de nombres actuales, los códigos de estado y el indicador DNSSEC de un dominio.
• Verificar las firmas con dig +dnssec example.com A y confirmar que un resolutor validador devuelve el indicador ad.
• Activar el bloqueo del registrador y la autenticación en dos pasos, porque secuestrar una cuenta de registrador consigue el mismo resultado que un envenenamiento con mucho menos esfuerzo.
• Evitar que caduquen los dominios, los certificados SSL y el alojamiento DNS. Un dominio caducado puede volver a registrarlo otra persona, lo que equivale a una suplantación permanente. Controlar las fechas de renovación en su panel de dominios de TLDix elimina ese riesgo.

En resumen

El envenenamiento de caché aprovecha que el DNS clásico confiaba en la primera respuesta verosímil. Los puertos aleatorios, los ID de transacción y la codificación 0x20 encarecen las conjeturas; el endurecimiento del resolutor elimina atajos fáciles; los transportes cifrados protegen el enlace del cliente; y DNSSEC permite por fin a los resolutores verificar que los datos son auténticos. Ningún control basta por sí solo, pero juntos hacen el DNS muchísimo más seguro. Para los propietarios de dominios, la lista corta está clara: firme sus zonas, proteja su cuenta del registrador, vigile sus registros y no deje nunca que caduquen los nombres críticos.