[21/08/2020] Las Domain Name System Security Extensions (DNSSEC) son un conjunto de especificaciones que amplían el protocolo DNS al agregar autenticación criptográfica para las respuestas recibidas de servidores DNS autorizados. Su objetivo es defenderse de las técnicas que utilizan los hackers para dirigir las computadoras a páginas web y servidores maliciosos. Si bien las DNSSEC ya se ha implementado para muchos de los dominios de nivel superior (TLD) genéricos y de nivel de país, la adopción a nivel de dominios individuales y de usuario final se ha quedado atrás.
¿Qué es la suplantación y el secuestro de DNS?
En el 2008, el investigador de seguridad Dan Kaminsky descubrió una falla fundamental en el protocolo DNS que impactó en el software de servidor DNS más utilizado. La falla permitía a los atacantes externos envenenar la memoria caché de los servidores DNS utilizados por los proveedores de telecomunicaciones y las grandes organizaciones, obligándolos a responder respuestas falsas a las consultas DNS, lo que podría enviar a los usuarios a páginas web falsificadas o servidores de correo electrónico falsos.
Esa falla fue reparada en la que, hasta ese momento, fue la respuesta coordinada más grande de la industria de TI a una vulnerabilidad de seguridad. Sin embargo, se mantuvo la amenaza de ataques de secuestro de DNS. Dado que el tráfico DNS no se autenticó ni se cifró, cualquier atacante que tome el control de un servidor DNS, en la ruta de resolución DNS de un usuario, podría responder maliciosamente y redirigirlo a un servidor malicioso -un contexto de 'hombre en el medio'.
El servidor DNS es como la guía telefónica de Internet. Permite que las computadoras conviertan nombres de dominio legibles por humanos en direcciones numéricas de Protocolo de Internet (IP, por sus siglas en inglés) que necesitan comunicar, ya que los protocolos de red principales usan direcciones IP, no nombres de host.
El Sistema de Nombres de Dominio tiene una estructura jerárquica con 13 clústeres de servidores en la parte superior, los cuales administran lo que se conoce como la zona raíz, luego servidores para cada dominio de nivel superior (TLD, por sus siglas e inglés) como '.com' o '.net' o para cada TLD de código de país como '.us' o '.ca', luego servidores para cada nombre de dominio particular, como 'google.com', luego quizás servidores separados que manejen subdominios particulares como 'cloud.google.com'.
Cada vez que un cliente -por ejemplo, una computadora o un dispositivo- realiza una consulta, esta jerarquía se recorre desde la parte superior hasta que se localiza el servidor DNS autorizado, para el nombre de host consultado, y responde con la dirección IP. Sin embargo, para mejorar el rendimiento del DNS, las respuestas se pueden almacenar en la caché durante un período de tiempo en los servidores a lo largo de la ruta. La mayoría de los dispositivos no consultarán la zona raíz por sí mismos, sino que consultarán un servidor DNS local que actúe como servidor de resolución, que a su vez podría consultar a otro DNS de resolución. Por ejemplo, los routers domésticos suelen actuar como un DNS de resolución y el primer salto en la cadena de DNS para todas las computadoras y dispositivos en la red local. Los routers también suelen enviar solicitudes a los servidores de resolución DNS operados por el ISP del cliente.
Comprender cómo funciona el DNS es importante porque cualquier servidor en esa cadena puede ser un eslabón débil y un punto desde donde los atacantes pueden servir respuestas maliciosas. Algunos programas maliciosos cambian la configuración del DNS en las computadoras para que éstas usen los servidores DNS operados por los atacantes, en cuyo caso los usuarios de las computadoras infectadas se verán afectados. Los ataques masivos han comprometido la configuración de DNS en los routers domésticos -esto se conoce como pharming de routers- afectando a todos los usuarios de las redes atendidas por esos routers. Otros ataques comprometen los solucionadores de DNS de un ISP, en cuyo caso todos los clientes del ISP que confían en esos servidores podrían verse afectados.
Ingrese a las DNSSEC
Las DNSSEC fueron diseñadas para enfrentar esos riesgos y proporcionar verificación criptográfica a través de firmas digitales. Las firmas se pueden usar para validar que los registros entregados en una respuesta DNS provienen del servidor DNS autorizado, que le sirve al nombre de dominio consultado, y para verificar que los registros no han sido alterados en el camino.
Al igual que Transport Layer Security (TLS) y otros protocolos de comunicación seguros, las DNSSEC se basan en la criptografía de clave pública. Cada servidor de nombres autorizado tiene un par de claves compuestas por una clave privada y una clave pública que están vinculadas criptográficamente entre sí. La clave privada se usa para firmar registros (en realidad, conjuntos de registros en una zona), y la firma se publica como un registro DNS. La clave pública se puede usar para validar la firma y también se almacena en un registro DNS.
¿Cómo aseguran los servidores de resolución que la firma y la clave pública provienen del verdadero servidor de nombres autorizado y no de un atacante del tipo 'hombre en el medio'? 'Suben' por la cadena jerárquica hasta la zona parental de la zona filial que desean validar. Por ejemplo, la zona '.com' es la parental para la zona 'google.com' y la zona '.(raíz)' es la parental para la zona '.com'.
Otro par de claves, privada y pública-privada, que usan los servidores DNS se conoce como clave-firma-clave (KSK, por sus siglas en inglés). La clave KSK privada se emplea con el fin de firmar la clave pública del primer par que se usó para la firma de los registros. La parte pública del KSK se entrega a la zona parental, que la publica como parte de sus propios registros para la zona filial y se utiliza esencialmente para autenticar que la información presentada en la zona secundaria es válida.
Para resumir, un DNS de resolución utiliza la clave pública de un servidor de nombres con el fin de verificar que los registros que proporciona estén firmados con su clave privada correspondiente. Luego se asegura de que la clave pública presentada por el servidor, en primer lugar, sea legítima mirando otro registro que contenga una firma de esa clave y la compare con un registro de la zona paterna -llamada registro DS- para validarla. Esto establece una cadena de confianza entre las zonas parentales y filiales.
Si va más y más alto en la cadena, ¿quién valida el par de claves más alto que se utilizó para firmar la zona raíz DNS de Internet? El par de claves raíz se genera en un módulo de seguridad de hardware que se mantiene en una ubicación segura y se rota periódicamente en una ceremonia pública y muy auditada, la cual involucra a representantes de la comunidad de confianza de todo el mundo. También existe un proceso de recuperación de claves en caso de una catástrofe importante; en él varias personas conocidas como titulares de acciones compartidas de recuperación deben reunirse en un mismo lugar y usar tokens criptográficos en su poder para reconstruir la clave.
Lo que no son las DNSSEC
Las DNSSEC se ven y suenan genial, pero no resuelven todos los problemas de la seguridad de los DNS. Primero, para alcanzar su máximo potencial, tendría que ser soportado y aplicado en todas partes, en todas las zonas DNS, en todos los dominios y en todos los DNS de resolución. Estamos lejos de ese mundo perfecto y quedan grietas donde los atacantes pueden introducirse en la cadena.
Por ejemplo, una crítica frecuente a las DNSSEC es la falta de protección para la llamada 'última milla'. Esto se debe a que la validación de las DNSSEC la realizan los servidores de resolución, lo que protege la integridad de las respuestas de DNS entre el servidor de resolución y los usuarios de este. Por ejemplo, si el servidor de resolución compatible con las DNSSEC es un router doméstico, los atacantes aún podrían comprometer el router doméstico y afectar la 'última milla', y esto sucede con bastante frecuencia.
Es posible que muchos routers domésticos, especialmente los modelos más antiguos, no soporten las DNSSEC o que no estén habilitadas. Tal vez reenvíen consultas a un DNS de resolución que tenga en cuenta las DNSSEC, como los que ejecutan los ISP. Eso es mejor que nada, pero la 'última milla' no segura ahora se ha extendido.
Las DNSSEC tampoco proporciona confidencialidad y privacidad porque el protocolo DNS, en sí, no está encriptado. Se proporcionan firmas digitales para verificar la integridad de los registros, pero los propios registros aún se encuentran en texto sin formato. Un atacante del tipo 'hombre en el medio', un ISP o un gobierno en ciertos países que practican la vigilancia de Internet puede ver a qué dominios y, por lo tanto, las páginas web a las que accede un usuario mirando sus consultas DNS.
También pueden usar DNS para bloquear ciertas páginas web. En ciertos países, los ISP se han visto obligados por orden judicial, o emitida por el gobierno, a bloquear el acceso a otras páginas web consideradas ilegales, como los rastreadores de Bittorrent, y esto se ha hecho a través de los DNS.
Las DNSSEC no han sido diseñadas para abordar estos problemas y otros protocolos --como DNS over TLS (DoT) o DNS over HTTPS (DoH)-- pueden usarse para cifrar el tráfico DNS entre los usuarios finales y los DNS de resolución en los que confían. Los DNS de resolución públicos como 1.1.1.1 de Cloudflare, 8.8.8.8 de Google, 9.9.9.9 de Quad9 y otros soportan las DNSSEC y DoT o DoH -a menudo ambos-, y son cada vez más preferidos por los usuarios en lugar de sus ISP locales, lo que por razones comerciales o legales podría interferir o recopilar datos de tráfico DNS.
Implementación y adopción de las DNSSEC
El APNIC, el registro de Internet que administra las direcciones IP para la región de Asia-Pacífico, tiene un proyecto para monitorear la validación de las DNSSEC en todo el mundo. Según las últimas estadísticas, la tasa global de validación de las DNSSEC es de alrededor del 26%, pero las tasas de validación varían significativamente según el país y la región. Estados Unidos tiene una tasa de validación de las DNSSEC del 30%, Canadá solo de 17%, Europa Occidental de 46%, Europa del Este de 26%, mientras que África y Asia de alrededor de 24%. En algunos países, sin embargo, la validación de las DNSSEC supera el 90%.
Cuando uno profundiza en los datos, descubre que, en partes de Asia, por ejemplo, los ISP dominantes optaron por reenviar las consultas DNS al DNS de resolución público de Google, en lugar de ejecutar sus propios servidores DNS locales, señala Dan York, líder del proyecto de Open Standards Everywhere de LA Internet Society. En los últimos años, en otras regiones, los grandes ISP han decidido activar la validación de las DNSSEC en sus DNS de resolución, por ejemplo, Comcast en los Estados Unidos, afirma York.
La implementación de las DNSSEC tiene muchas capas. Comenzó con la generación del primer par de claves raíz en el 2010, pero luego el par de claves se actualizó en un proceso de reinversión que tomó varios años para planificar y ejecutar, finalizándose en octubre del 2018. La parte pública del par de claves tuvo que ser compartida con proveedores de servicios de Internet, administradores de redes empresariales, operadores de resolución de DNS, desarrolladores de software de resolución de DNS, integradores de sistemas y distribuidores de hardware y software, que fue un proceso largo.
Los operadores de TLD y ccTLD también tuvieron que generar e implementar sus propias claves y procesos con el fin de habilitar las DNSSEC para sus respectivas zonas DNS. Luego está el problema de que los propietarios de dominios individuales realmente elijan firmar sus propios registros.
"La implementación está avanzando”, afirma York. "Creo que hubo una pausa entre el 2015 y el 2018, mientras esperábamos el cambio de la clave raíz, donde las personas que ejecutaban la infraestructura de DNS querían esperar y ver cómo iría la transferencia de la clave raíz. Se completó en el 2018 y todo está bien, las luces están verdes, y ahora estamos viendo en los gráficos cómo está aumentando la implementación de las DNSSE”.
Existen algunos desafíos, especialmente en el espacio empresarial, según York, cuando se trata de firmar sus dominios y rotar claves. En los casos en que el registrador de dominios es también el proveedor de DNS, y mantiene los servidores autorizados para un dominio, se puede firmar automáticamente y transmitir los registros de firma al TLD para establecer la cadena de confianza, por lo que el proceso es bastante fluido. Sin embargo, las empresas tienden a ejecutar sus propios servidores DNS o utilizar redes de entrega de contenido o proveedores DNS que no son también registradores, en cuyo caso deben manejar este proceso ellos mismos.
"Cuando firmas un dominio, tienes que dar este pequeño registro -llamado registro DS- al registro de TLD (.org, .com, .bank, etcétera). Es parte de esta cadena de confianza que verifica que su dominio está firmado”, afirma York. "El desafío con muchas empresas es que quieren ir y firmar sus propios registros..., pero luego deben asegurarse de que cuando se cambie su clave de firma, se comunique al TLD. Por lo general, solo tienen que hacerlo una vez al año, pero esta es una parte que algunas empresas encuentran un poco burda”.
Ha habido incidentes en el pasado en los que las páginas web no estaban disponibles debido a configuraciones incorrectas de las DNSSEC o registros caducados -las páginas web de la NASA y HBO Now son dos ejemplos. En comparación, la industria TLS/SSL y las Autoridades de Certificación han logrado automatizar algunos de los procesos que involucran rotaciones de certificados y claves.
"Es algo en lo que las empresas tienen que pensar un poco”, afirma York. "Hay algo de trabajo en proceso. Hay algunas normas que les permiten a las personas hacer esto. Solo tienen que entender que estas cosas existen”.
Algo que también contribuye a la implementación de las DNSSEC, según York, es la mayor adopción de la DANE (DNS-based Authentication of Named Entities). Este es un protocolo que se basa en los registros DNSSEC para vincular los certificados TLS a los nombres de dominio y, esencialmente, les dice a los clientes exactamente qué certificado TLS deben aceptar para un servidor en particular. Esto está destinado a evitar la intercepción del TLS, es decir, cuando un proxy que se encuentra entre un usuario y un servidor puede terminar la conexión TLS y devolverla al usuario con un certificado diferente. También hace posible usar y confiar en certificados que son anunciados por un dominio a través de DNS y firmados criptográficamente con DNSSEC, incluso si no han sido emitidos por una Certificate Authority (CA) de confianza pública.
"Esto no ha despegado en el espacio del navegador, en gran parte porque se realizan comprobaciones adicionales y los navegadores se centran en el rendimiento y la velocidad, pero donde ha entrado en juego es con el correo electrónico seguro”, afirma York. "Existe un número creciente de personas que usan la DANE, que luego es firmado por DNSSEC, como una forma de hacer seguro un correo electrónico cifrado desde un servidor de correo electrónico a otro. Ese es un aspecto interesante y es algo que las empresas pueden ver: ¿Al proporcionar este tipo de registros para sus servidores de correo electrónico, es esta una forma en que pueden hacer que su correo electrónico sea más seguro?
A diferencia del TLS, y especialmente del HTTPS -al que Google y otras grandes compañías tecnológicas dieron su apoyo, convirtiéndolos en predeterminados y obligatorios para diferentes servicios y aplicaciones-, York cree que no veremos una explosión en la adopción de las DNSSEC. Es más probable que su crecimiento sea más lento, ya que más ISP están comenzando a comprender el valor de usarlo para verificar cosas, agregándolo y activándolo en cada vez más herramientas, dispositivos y aplicaciones.
Lucian Constantin, CSO (EE.UU.)