Seguridad DNS

En un entorno DNS se identifican varios puntos donde posibles ataques pueden desarrollarse. Estos puntos o “vectores de ataque” se sitúan tanto localmente en el propio servidor DNS y red local, como en las comunicaciones entre servidores y clientes.

Vectores de Ataque y Amenazas en un Escenario DNS

Amenazas locales: En la prevención de las amenazas locales, la solución más sencilla es la implementación de medidas y políticas de seguridad en la red interna. Mecanismos anti-spoofing, IDS/IPS.

Amenazas Servidor-Servidor: Actualizaciones dinámicas. Presentes cuando el tamaño de la organización o el número de servidores a administrar obliga a centralizar la administración de los datos a través de DDNS (Dynamic DNS). Una opción válida para asegurar la comunicación sería dedicar un canal de comunicación restringido y/o implementar TSIG. , así como la protección de los canales de acceso a los servidores y sus archivos sentarán la línea base de protección en esta área.

Amenazas Servidor Master – Servidor Esclavo: Transferencias de zona. Cuando una organización cuenta con servidores esclavos, tiene la necesidad de ejecutar transferencias de zona maestro/esclavo. En estos casos la solución a considerar es la implementación de TSIG (Transaction SIGnature), de modo que las operaciones de transferencia de zona se firmen con una clave conocida por ambas partes. Adicionalmente la seguridad en las comunicaciones puede reforzarse usando SSL/TLS. Otras opciones pasarían por un canal de red privado para la transacción, o en caso extremo deshabilitarla y realizarla manualmente, lo cual no es una alternativa funcional.

Amenazas Servidor Master – Servidor Cliente Caché/Resolver. Las mejoras implementadas en las versiones recientes de Bind con la introducción de aleatoriedad en los puertos origen de la consulta, así como en los identificadores de mensaje, dificultan la posibilidad de envenenamiento de caché en los servidores DNS, pero aún así, el ataque sigue siendo posible. La única solución considerada efectiva es adoptar DNSSEC.

Servidor – Cliente: En el flujo de información entre un cliente/resolver y un servidor master o caché, cabe la posibilidad de ataques locales para interceptar datos y de spoofing con objeto de suplantar al servidor DNS. Nuevamente, DNSSEC es la contramedida eficaz contra esta amenaza.

VULNERABILIDADES Y PUNTOS DÉBILES EN LA ESPECIFICACIÓN DNS

Capa de transporte UDP e IP spoofing

La utilización del UDP facilita el falseo de direcciones (spoofing) y la suplantación de mensajes de consulta/respuesta, aunque el DNS contempla el uso de TCP para la transmisión de mensajes, se recomienda el UDP por rendimiento. Dada la carencia de control/confirmación la responsabilidad final de validar el mensaje recaerá directamente sobre el protocolo DNS.

Debilidad en la identificación y validación de mensajes DNS

Debilidades de diseño en el aspecto de la identificación y validación de los paquetes que favorecen la falsificación de los mismos. Como se describe en Formato genérico de mensaje DNS, en la sección HEADER de un mensaje DNS se destina el campo ID para identificar el mismo. Este identificador, representado por un número de sólo 16 bits, juega un papel importante en el mecanismo de validación de mensajes de respuesta. Como se explica a continuación, su limitada longitud unido a un débil proceso de validación sobre UDP posibilitan ataques de suplantación IP con relativa facilidad.

Validación de respuestas

Los mínimos requisitos para aceptar una respuesta son:

• El puerto destino en el datagrama de respuesta debe ser el mismo que el puerto origen de la pregunta
• El ID del mensaje de respuesta debe ser el mismo que el ID del mensaje de pregunta.
• El campo ANSWER debe referir el mismo recurso que el campo QUESTION.
• La sección AUTHORITATIVE contiene los servidores autoritativos de la sección ANSWER.

Identificador de mensaje ID

Debido a la escasa longitud destinada al campo ID del mensaje (16 bits) y a debilidades en la generación de la secuencia de los mismos, computacionalmente es relativamente sencillo construir un número suficiente de ID’s en un tiempo limitado para conseguir “acertar” con el ID original.

Estas debilidades en la transmisión y validación del mensaje convierten al protocolo DNS en un objetivo fácilmente explotable para dos grandes tipos de ataques basados en DNS IP spoofing: DNS Caché Poisoning y Denegación de servicio por amplificación DNS.

DNS CACHE POISONING Y DNS SPOOFING

Un atacante puede enviar multitud de respuestas (flooding) con distintos ID hasta lograr acertar con el ID generado en la consulta. Si es así, y se consigue hacer llegar la respuesta falsa antes de que llegue la legítima, el servidor que ha iniciado la consulta la aceptará y la almacenará en su caché.

Descripción del ataque

El atacante, con un servidor DNS bajo su control, solicita un nombre que pertenezca al dominio al cual quiere suplantar (1). Se asegura que este nombre no esté cacheado. El servidor víctima que no encuentra en su cache el recurso pedido, inicia la secuencia de peticiones iterativas empezando por los servidores raíz (2) y recorriendo los TLD que se le indican en los referrals (3) hasta que sepa a qué servidor, autoritativo del recurso, dirigir la pregunta (4). En ese instante, el servidor malicioso inicia un bombardeo de respuestas (6) con distintos ID con el objetivo de acertar en una de ellas con el ID coincidente con la query original del servidor víctima. En esas respuestas se indica que el servidor autoritativo (AUTHORITY) para el dominio a suplantar se encuentra en la IP del servidor malicioso. Si se consigue hacer llegar la respuesta falseada (6) antes de que llegue la original (5), el servidor víctima almacenará en caché el registro falseado con la IP del servidor malicioso como servidor autoritativo suplantando al servidor legítimo. La respuesta legítima que llegará después será descartada.

En este momento, el envenenamiento de caché o caché poisoning del servidor víctima se ha completado con éxito, y todas las solicitudes de resolvers que le lleguen de subdominios pertenecientes al dominio suplantado se dirigirán al servidor malicioso que se encargará de ofrecer las IP bajo su control según le convenga.

Medidas contra el ataque de caché poisoning

“Un resolver, con objeto de validar una respuesta DNS, debe realizar las siguientes comprobaciones:

• La sección question del paquete de respuesta es equivalente a la consulta realizada en la query.
• El campo ID del paquete de respuesta coincide con el ID de la consulta.
• La respuesta procede de la misma dirección de red a la cual la pregunta fue enviada.
• La respuesta llega a la misma dirección y puerto desde la cual se emitió la pregunta.
• Es la primera respuesta recibida en cumplir las cuatro condiciones anteriores.”

Partiendo de las premisas reseñadas, el software DNS debe implementar las medidas descritas a continuación.

• Aleatoriedad del ID de transacción y puerto origen: añade aleatoriedad en la generación en las consultas y así hacerlo menos predecible.
• 0x20 bit encoding: consiste en realizar las consultas DNS alternando aleatroiamente mayúsculas y minúsculas. Puesto que el protocolo DNS no distingue entre ambas, se resolverá de igual forma el dominio WwW.EjEmPlo.Com que www.ejemplo.com, sin embargo la implementación del software solo validará aquella respuesta que coincida en la capitalización de los caracteres con la consulta.
• Validación de respuestas y detección de spoofing. Retransmisión sobre TCP: comprobaciones adicionales sobre la respuesta en sí, abandonando la petición sobre UDP y reintentando a través de TCP.
• Limitar recursión: reducir la superficie de exposición a atacantes.
• Solución al poisoning: DNSSEC: implementar un DNSSEC.

Vocabulario y Abreviaturas

TSIG: es un mecanismo de secreto compartido para identificar a dos servidores de DNS entre sí. Permite controlar quien puede acceder al servidor para preguntas de DNS.

DNSSEC: Domain Name System Security Extensions (Extensiones de seguridad para el Sistema de Nombres de Dominio) es un conjunto de especificaciones de la Internet Engineering Task Force (IETF) para asegurar cierto tipo de información proporcionada por el sistema de nombre de dominio (DNS) que se usa en el protocolo de Internet (IP). Se trata de un conjunto de extensiones al DNS que proporcionan a los clientes DNS (o resolvers) la autenticación del origen de datos DNS, la negación autenticada de la existencia e integridad de datos, pero no disponibilidad o confidencialidad.

UDP es un protocolo de transporte de red en el que prima la velocidad de la transmisión y sobre el cual se envía y recibe la información sin que se haya establecido previamente una conexión y sin confirmación ni control de entrega/recepción de la misma.

Fuentes:

• Wikipedia
• Inteco