Complejidades y consideraciones del protocolo DNSSEC

El DNS se divide en conjuntos de datos más pequeños llamados zonas. Una zona suele comenzar en un nombre de dominio y contiene todos los registros correspondientes a los subdominios. Un único gestor se encarga de la gestión de cada zona. Por ejemplo, cloudflare.com es una zona que contiene todos los registros DNS de cloudflare.com y sus subdominios (p. ej., www.cloudflare.com, api.cloudflare.com).

No hay un servicio de directorio para subdominios en el DNS, así que si quieres saber si api.cloudflare.com existe, tienes que preguntar a un servidor DNS que su vez acabará preguntando a cloudflare.com si api.cloudflare.com existe. Esto no ocurre con el protocolo DNSSEC. En algunos casos, la activación del protocolo DNSSEC puede exponer el contenido de la zona que de otro modo quedaría oculto. No todo el mundo se preocupa por la confidencialidad de los subdominios, y el contenido de la zona se puede adivinar fácilmente porque la mayoría de los sitios tienen un subdominio "www". Sin embargo, los subdominios se utilizan a veces como portales de acceso u otros servicios que el propietario del sitio quiere mantener en privado. Es posible que el propietario de un sitio no quiera revelar que "puertatraserasecreta.example.com" existe para proteger ese sitio de los atacantes.

La razón por la que el DNSSEC puede exponer subdominios tiene que ver con la forma en que se firman las zonas. Durante años, el DNSSEC se ha utilizado para firmar zonas estáticas. Una zona estática es un conjunto completo de registros para un determinado dominio. Los registros de firma DNSSEC se crean utilizando la clave de firma de claves (KSK) y la clave de firma de zonas (ZSK) en una ubicación central y se envían al servidor autoritativo para su publicación. Este conjunto de registros permite a un servidor autoritativo responder a cualquier pregunta que se le haga, incluidas las preguntas sobre subdominios inexistentes.

A diferencia del DNS estándar, en el que el servidor devuelve una respuesta NXDOMAIN (dominio inexistente) sin firmar cuando un subdominio no existe, DNSSEC garantiza que cada respuesta está firmada. Esto se hace con un registro especial que sirve como prueba de inexistencia, llamado registro NextSECure (NSEC). Un registro NSEC se puede utilizar para decir "no hay subdominios entre el subdominio X y el subdominio Y". NSEC, que cubre el hueco entre cada dominio de la zona, proporciona una forma de responder a cualquier consulta con un registro estático. El registro NSEC también indica qué tipos de registros de recursos existen en cada nombre.

Para las zonas firmadas estáticamente, hay, por definición, un número fijo de registros. Como cada registro NSEC apunta al siguiente, se obtiene un "anillo" limitado de registros NSEC que abarca todos los subdominios. Cualquiera puede "recorrer" una zona a la siguiente siguiendo un registro NSEC hasta conocer todos los subdominios. Este método se puede utilizar para revelar todos los nombres de esa zona, exponiendo posiblemente información interna.

Imagina que hay una zona con DNSSEC llamada example.com, con subdominios publico.example.com y secreto.example.com. Cuando se añadan los registros NSEC se revelará la existencia de todos los subdominios.

Al solicitar el registro NSEC de example.com se obtiene lo siguiente:

example.com. NSEC publico.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Al solicitar publico.example.com se obtiene el siguiente registro NSEC:

publico.example.com. NSEC secreto.example.com. A TXT AAAA RRSIG NSEC

Al solicitar secreto.example.com se obtiene el siguiente registro NSEC:

secreto.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

El primero corresponde a la zona top/apex, e indica que el nombre "example.com" existe y el siguiente nombre es "publico.example.com". El registro publico.example.com indica que el siguiente nombre es "secreto.example.com", revelando así la existencia de un subdominio privado. El registro "secreto.example.com" indica que el siguiente registro es "example.com", completando así la cadena de subdominios. Por tanto, con solo realizar unas cuantas consultas cualquiera puede conocer el conjunto completo de registros de la zona.

Técnicamente, se supone que los registros DNS no son confidenciales, pero en la práctica a veces se consideran así. Los subdominios se han utilizado para mantener recursos (como una página de inicio de sesión corporativa) en privado durante un tiempo, y la revelación repentina del contenido del archivo de zona puede que pase inadvertida al producirse de manera inesperada.

Antes del DNSSEC, la única forma de descubrir el contenido de los nombres de una zona era consultarlo o intentar realizar una transferencia de la zona desde uno de los servidores autoritativos. Las transferencias de zona (AXFR) se bloquean con frecuencia. El registro NSEC3, la alternativa a NSEC, se usa para combatir los problemas de enumeración de zonas, pero incluso NSEC3 se puede utilizar para revelar la existencia de subdominios.

La mayoría de los dominios .ch usan NSEC3

El registro NSEC3 es como un registro NSEC, pero, en lugar de un hueco firmado de nombres de dominio para los que no hay respuestas a la pregunta, NSEC3 proporciona un hueco firmado de valores hash de nombres de dominio. Con ello, se pretendía evitar la enumeración de zonas. Así, la cadena NSEC3 de una zona que contiene "example.com" y "www.example.com" podría ser (cada registro NSEC3 está en 3 líneas para mayor claridad):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Donde

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

La primera línea del registro NSEC3 contiene el "nombre" de la zona tras haber sido cifrado con un valor de hash, el número de rondas de hash y el valor de sal utilizado en el hash son los dos últimos parámetros de la primera línea "3 ABCDEF". El "1 0" representa el algoritmo de digestión (1 significa SHA-1) y si la zona utiliza Opt-out (0 significa no). La segunda línea es el "siguiente nombre con hash en la zona", la tercera línea enumera los tipos en el nombre. Puedes ver que el "siguiente nombre" del primer registro NSEC3 coincide con el nombre del segundo registro NSEC3 y el "siguiente nombre" de este completa la cadena.

Para la enumeración NSEC, puedes crear la lista completa de dominios empezando a adivinar los posibles nombres del dominio. Si la zona tiene 100 nombres de dominio, se necesitarán unas 100 solicitudes para enumerar toda la zona. Con NSEC3, cuando solicitas un registro que no existe, se devuelve un registro NSEC3 firmado con la siguiente zona presente ordenada alfabéticamente por hash. Comprobar si el siguiente candidato a nombre de consulta encaja en uno de los huecos conocidos permite descubrir la cadena completa en unas 100 consultas. Hay muchas herramientas que pueden hacer este cálculo por ti, como un complemento de nmap.

Con los valores de hash que corresponden a todos los nombres válidos de la zona, se puede utilizar un ataque de diccionario para averiguar los nombres reales. Los nombres cortos se adivinan con mucha facilidad y con un diccionario, se puede revelar la existencia de nombres más largos sin tener que inundar los servidores de nombres autorizados con suposiciones. Herramientas como HashCat facilitan esta tarea en el software, y la popularidad de bitcoin ha bajado drásticamente el precio del hardware específico de funciones hash. La industria artesanal de dispositivos desarrollados para procesar hashes criptográficos está en auge. El descifrador de contraseñas de Tesla (abajo) es solo un ejemplo de estos dispositivos disponibles en el mercado.

El cracker de Tesla

Los algoritmos de hash son baratos, por eso la privacidad de la zona solo mejora ligeramente cuando se utiliza NSEC3 tal y como está diseñado. La cantidad de protección que obtiene un nombre es proporcional a su imposibilidad de adivinar.

En resumen, NSEC es como revelar contraseñas en texto sin formato, y NSEC3 es como revelar un archivo de contraseñas al estilo de Unix. Ninguna de las dos técnicas es muy segura. Con NSEC3, un subdominio solo es privado si es difícil de adivinar.

Esta vulnerabilidad se puede mitigar mediante una técnica adoptada en los RFC 4470 y 4471 (https://tools.ietf.org/html/rfc4470 y https://tools.ietf.org/html/rfc4471) llamada "mentiras blancas DNSSEC". Fue implementada por Dan Kaminsky con fines de demostración. Cuando llega una solicitud para un dominio que no está presente, en lugar de proporcionar un registro NSEC3 del siguiente dominio real, se presenta un registro NSEC3 del siguiente hash alfabético. Esto no afecta a la garantía del NSEC3 según la cual no hay dominios cuyo hash encaje lexicográficamente entre la respuesta del NSEC3 y la pregunta.

Solo puedes implementar las "mentiras blancas" de NSEC3 o NSEC si las firmas se pueden calcular en tiempo real en respuesta a las preguntas. Tradicionalmente, los registros de zona estáticos para la resolución del DNS se crean sin conexión, y todos los registros con firmas se almacenan en un archivo de zona. Este archivo es leído por un servidor DNS en directo, lo que le permite responder a las preguntas sobre la zona.

La implementación de DNSSEC de Cloudflare aprovecha la eficiente generación de firmas de ECDSA para firmar registros DNSSEC sobre la marcha.

El DNSSEC se diseñó para funcionar en varios modos, cada uno de los cuales ofrece diferentes desventajas de seguridad, rendimiento y facilidad. La firma en directo resuelve el problema de la exposición del contenido de la zona a cambio de una gestión de claves menos segura.

El modo más común de DNSSEC es la firma sin conexión de zonas estáticas. Esto permite que el sistema de firma esté muy protegido de las amenazas externas al mantener las claves privadas en un equipo que no está conectado a la red. Este modelo operativo funciona bien cuando la información del DNS no cambia con frecuencia.

Otro modo de funcionamiento habitual es la firma en línea centralizada. La firma de datos en sistemas de firma DNS de acceso restringido permite que los datos DNS cambien y se publiquen rápidamente. Algunos operadores ejecutan la firma DNS en sus servidores DNS principales. Al igual que la firma fuera de línea de zonas estáticas, este modo sigue el modelo de firma central, es decir, un único firmante central (o replicado) realiza toda la firma y los datos se propagan desde este a los servidores DNS autoritativos reales.

Un modo más radical es permitir que los propios servidores DNS autoritativos firmen los datos sobre la marcha cuando sea necesario, lo que permite una serie de nuevas funciones, como la información dependiente de la geografía que se firma en el lugar donde se genera la respuesta. El inconveniente es que ahora el material para claves está en muchos equipos diferentes que tienen acceso directo a Internet. El proceso de firma en directo en el perímetro plantea nuevos problemas, como la distribución de la clave, y supone requisitos informáticos adicionales para los nodos.

Recientemente, se encontró un error conocido como Heartbleed que abrió una importante vulnerabilidad de seguridad en las aplicaciones de los servidores. Su origen fue error de codificación en OpenSSL que creó una vulnerabilidad de divulgación de memoria remota. Este fallo permitía a los atacantes remotos extraer claves criptográficas de los servidores accesibles desde Internet. Los fallos de exposición a la memoria remota son solo una de las muchas amenazas a la seguridad de la clave privada cuando esta se utiliza en un proceso activo como la firma en directo de DNSSEC. Cuanto más expuesto esté un equipo a Internet, más vectores de ataque habrá. Las máquinas de firma fuera de línea tienen una ventana de exposición mucho menor a tales amenazas.

Una forma de mantener las claves seguras es utilizar una solución basada en hardware, como un módulo de seguridad de hardware (HSM). El mayor inconveniente es el coste. Los HSM son muy caros (y lentos). Este es uno de los puntos más conflictivos para la gestión de los servidores DNS que están repartidos geográficamente para estar cerca de sus clientes. Instalar un HSM en cada ubicación del servidor no solo puede ser caro, sino que también puede haber complicaciones desde el punto de vista legal.

Otra solución para proteger las claves del riesgo de revelación remota es descargar las operaciones criptográficas en un componente de confianza del sistema. Aquí es donde resulta útil tener un servidor DNS personalizado que pueda descargar la criptografía.

La gestión de claves para DNSSEC es similar a la gestión de claves para el protocolo TLS y tiene retos similares. A principios de este año, presentamos SSL sin clave para ayudar a mejorar la seguridad de las claves para el protocolo TLS. Estamos estudiando la posibilidad de ampliar SSL sin clave para que ofrezca las ventajas de los servidores de claves remotos para la firma en directo de DNSSEC.

A los operadores que gestionan un servidor DNS autoritativo les suele inquietar que su servidor se utilice como vía para ataques maliciosos de denegación de servicio distribuido (DDoS). Esto se debe a que el DNS utiliza UDP, un protocolo sin estado.

En el protocolo TCP, cada conexión comienza con un protocolo de enlace de tres vías. Esto garantiza que la dirección IP de ambas partes es conocida y correcta antes de iniciar una conexión. En un protocolo UDP, no existe ese protocolo de enlace. Los mensajes se envían directamente a una dirección IP con una dirección IP "de" no verificada. Si un ciberdelincuente puede crear un paquete UDP que diga "hola, desde la IP X" a un servidor, este suele responder enviando un paquete UDP a X. Elegir X como dirección IP de la víctima en lugar de la del remitente se denomina "suplantación" de UDP. Al suplantar a una víctima, un ciberdelincuente puede hacer que un servidor que responda a solicitudes UDP inunde a la víctima con tráfico "reflejado". Esto se aplica tanto a los servidores autoritativos como a los solucionadores recursivos abiertos.

DNSSEC también funciona a través del protocolo UDP, y las respuestas a las consultas DNS pueden ser muy largas, e incluir varios registros DNSKEY y RRSIG. Es un objetivo atractivo para los ciberdelincuentes, ya que les permite "amplificar" sus ataques de reflexión. Si se envía un pequeño volumen de solicitudes DNSSEC UDP falsas a los servidores de nombres, la víctima recibirá un gran volumen de tráfico reflejado. A veces esto es suficiente para sobrecargar el servidor de la víctima y provocar una denegación de servicio.

Preguntar por un protocolo TLD que no existe a un servidor raíz devuelve una respuesta de unos 100 bytes, la respuesta firmada para la misma pregunta es de unos 650 bytes o un factor de amplificación de 6,5. La raíz está firmada con una clave RSA de 1 024 bits y utiliza NSEC para las respuestas negativas. Solicitar un dominio que no existe en un protocolo TLD utilizando NSEC3 firmado con una clave de 1 024 bits dará un factor de amplificación de alrededor de 10. Hay otras consultas que pueden generar factores de amplificación aún mayores, siendo la más eficaz la consulta de tipo "ANY".

Como muchos servicios, el DNS también puede funcionar a través de TCP. Hay una marca de "truncamiento" que se puede enviar a un solucionador para indicar que se necesita el protocolo TCP. Esto solucionaría el problema de la reflexión del DNS a costa de que las solicitudes de DNS sean más lentas. Esta solución no es práctica por el momento, ya que el 16 % de los solucionadores no respetan la marca de truncamiento TCP, y el 4 % no intentan un segundo servidor.

Otra opción para reducir el tamaño de las respuestas es utilizar claves de algoritmo de firma digital de curva elíptica (ECDSA) en lugar de las tradicionales RSA. Las claves ECDSA son mucho más cortas que las claves RSA de seguridad equivalente, y producen firmas más reducidas haciendo que las respuestas DNSSEC sean mucho más breves, reduciendo así el factor de amplificación. El DNS público de Google añadió la compatibilidad para ECDSA a finales de 2014, y otros han seguido su ejemplo desde entonces.

La compatibilidad con TCP y ECDSA sigue estando por detrás de la compatibilidad general con DNSSEC, por lo que se pueden utilizar en su lugar los métodos tradicionales contra el abuso. Esto incluye limitación de velocidad de respuesta (RRL) y otras heurísticas.

Para ofrecer protección contra los ataques de reflexión, Cloudflare está trabajando en un enfoque multidimensional. En primer lugar, utilizando la heurística de identificación de ataques y las técnicas contra abuso que actualmente utilizamos en nuestro servidor DNS, y en segundo lugar, reduciendo el factor de amplificación de las respuestas DNSSEC. Entre las formas de reducir el factor de amplificación máximo se incluyen la respuesta solo a las solicitudes del tipo "ANY" a través del protocolo TCP, el uso de claves ECDSA más cortas cuando sea posible y la reducción de la frecuencia de las renovaciones de claves.

Cloudflare es consciente de la complejidad que plantea el DNSSEC con respecto a la privacidad de la zona, la gestión de claves y el riesgo de ataques de reflexión/amplificación. Con decisiones inteligentes de ingeniería y controles operativos, se pueden prevenir los peligros del protocolo DNSSEC.