Desarrollo de un Servidor Proxy de DNS para Mitigar el Problema de Enumeración de Zona en DNSSEC Edición Única

Texto completo

(1)Desarrollo de un Servidor Proxy de DNS para mitigar el problema de Enumeración de Zona en DNSSEC. por. Ing. Mario Anı́bal Cruz Hernández. Tesis Presentada al Programa de Graduados de la Escuela de Tecnologı́as de Información y Electrónica como requisito parcial para obtener el grado académico de. Maestro en Ciencias especialidad en. Tecnologı́a Informática. Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey Mayo de 2007.

(2) Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey Escuela de Tecnologı́as de Información y Electrónica Programa de Graduados. Los miembros del comité de tesis recomendamos que la presente tesis de Mario Anı́bal Cruz Hernández sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias, especialidad en: Tecnologı́a Informática. Comité de tesis:. M.C. Alejandro Parra Briones Asesor de la tesis. M.C. Gustavo Lozano Ibarra. Dr. Juan Arturo Nolazco Flores. Sinodal. Sinodal. Dr. Graciano Dieck Assad Director del Programa de Graduados. Mayo de 2007.

(3) Dedicada a la familia Cruz Hernández.

(4) Agradecimientos. Quiero agradecer sinceramente al ITESM Campus Monterrey por haberme apoyado en el financiamiento de mis estudios profesionales y de maestrı́a y por contribuir en mi formación personal, académica y profesional. A Alejandro Parra Briones, por haberme ayudado en la investigación y realización de esta tesis, y por la gran cantidad de enseñanzas que me dejó a nivel escolar, profesional y personal. A Gustavo Lozano Ibarra y al personal de NIC México por haber colaborado enormemente con su experiencia y conocimientos para la realización de este trabajo y por haberme facilitado la infraestructura necesaria para poder realizarlo. A Juan Arturo Nolazco Flores por su contribución, opiniones y recomendaciones a esta tesis. A todas las personas, familiares, amigos y a mi novia por todo el apoyo moral otorgado durante el tiempo de realización de este trabajo. Sin ellos, la realización de este trabajo no habrı́a sido posible.. Mario Anı́bal Cruz Hernández. Instituto Tecnológico y de Estudios Superiores de Monterrey Mayo 2007. v.

(5) Desarrollo de un Servidor Proxy de DNS para mitigar el problema de Enumeración de Zona en DNSSEC. Mario Anı́bal Cruz Hernández, M.C. Instituto Tecnológico y de Estudios Superiores de Monterrey, 2007. Asesor de la tesis: M.C. Alejandro Parra Briones. El servicio de DNS y su correcto funcionamiento son considerados de gran importancia para las comunicaciones que tiene lugar en Internet. La seguridad de dicho servicio no fue una prioridad durante su desarrollo, por lo que terceros explotaron las vulnerabilidades existentes. A raı́z de eso se desarrollaron extensiones de seguridad al servicio, denominadas en su conjunto DNSSEC, y que se bajan en la criptografı́a de llave pública para que la entidad que reciba la información de DNS pueda confirmar el origen de la misma y calificarla como fidedigna o falsificada. Aún ası́ la especificación actual de DNSSEC cuenta con una serie de fallas de seguridad detectadas que han impedido a las organizaciones implementarlo en sus servidores de DNS actuales. Una de estas fallas es la enumeración de zona, que permite a un individuo que tenga la posibilidad de solicitar respuestas autenticadas con DNSSEC a un servidor de DNS autoritativo, conocer todos los nombres de dominio y registros de DNS existentes dentro de la zona administrada por ese servidor a través del registro NSEC que fue incorporado al conjunto de registros de DNS cuando se finalizó el desarrollo de la especificación de DNSSEC. Con el fin de mitigar este problema la IETF creó la técnica conocida como firmado en lı́nea (online signing), que consiste en la modificación del registro NSEC y su posterior firma digital con el fin de ocultar los dominios válidos existentes en la zona y que al mismo tiempo el paquete pueda ser verificado, lo que es muy demandante en términos computacionales para el servidor de DNS que aplica dicha técnica. El presente trabajo contempla la creación de un servidor Proxy (intermedio) que aplique la técnica de firmado en lı́nea para mitigar la enumeración de zona y al mismo tiempo libere al servidor de la carga computacional que implica modificar y firmar registros al momento que son solicitados por un usuario. El prototipo desarrollado demostró en ambientes de prueba y de producción pasar las pruebas de cadena de confianza y al mismo tiempo mitigar la enumeración de zona. Además con el uso de un tarjeta de firmado digital, el Proxy pudo dirigir las operaciones de firmado a dicha tarjeta en lugar de utilizar el procesador de la máquina que lo ejecuta eliminando de este último la carga computacional relacionada a las firmas digitales..

(6) Índice general. Agradecimientos. V. Resumen. VI. Índice de cuadros. IX. Índice de figuras. X. Capı́tulo 1. Introducción. 1. Capı́tulo 2. Marco Teórico 2.1. Sistema de Nombres de Dominio . . . . . . . . . . . . . . . . 2.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. Descripción . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Tipos de Servidores de Nombres . . . . . . . . . . . . 2.1.4. Registros de Datos . . . . . . . . . . . . . . . . . . . . 2.1.5. Estructura de los Mensajes de DNS . . . . . . . . . . 2.1.6. Zonas . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.7. Problemas de Seguridad . . . . . . . . . . . . . . . . . 2.2. DNS Security (DNSSEC) . . . . . . . . . . . . . . . . . . . . 2.2.1. Conceptos Básicos de Criptografı́a de Llave Pública . 2.2.2. Descripción de DNSSEC . . . . . . . . . . . . . . . . . 2.2.3. Registro DNSKEY . . . . . . . . . . . . . . . . . . . . 2.2.4. Registro RRSIG . . . . . . . . . . . . . . . . . . . . . 2.2.5. Registro NSEC . . . . . . . . . . . . . . . . . . . . . . 2.2.6. Registro DS . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7. Bits de Encabezado . . . . . . . . . . . . . . . . . . . 2.2.8. Ordenamiento Canónico de Nombres de Dominio . . . 2.3. Enumeración de Zona . . . . . . . . . . . . . . . . . . . . . . 2.4. Soluciones Emergentes al Problema de Enumeración de Zona 2.4.1. Registro NSEC3 . . . . . . . . . . . . . . . . . . . . . 2.4.2. Firmado en Lı́nea . . . . . . . . . . . . . . . . . . . . Capı́tulo 3. Definición del Problema. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. 5 5 5 6 8 9 11 14 14 15 16 18 23 24 26 27 28 29 30 33 33 35 38. vii.

(7) Capı́tulo 4. Solución Propuesta 4.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Configuración de Servidor de DNS Autoritativo . . . . . . . . . . . 4.4. Análisis del tráfico generado y recibido por el servidor autoritativo. 4.5. Definición de Plataforma y Lenguaje de Programación . . . . . . . 4.6. Selección de Bibliotecas de DNS . . . . . . . . . . . . . . . . . . . 4.7. Desarrollo del Servidor Proxy . . . . . . . . . . . . . . . . . . . . . 4.8. Construcción de Ambiente de Pruebas . . . . . . . . . . . . . . . . 4.8.1. Ambiente de Pruebas - Proceso Iterativo . . . . . . . . . . . 4.8.2. Ambiente de Pruebas - Proceso Recursivo . . . . . . . . . . 4.8.3. Problema con Funciones Absolutas . . . . . . . . . . . . . . 4.8.4. Ambiente de Pruebas - Rendimiento . . . . . . . . . . . . . 4.9. Análisis de Resultados . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 40 40 42 46 48 50 53 54 63 63 65 68 71 77. Capı́tulo 5. Recomendaciones e Investigaciones Futuras. 81. Capı́tulo 6. Conclusiones. 83. Bibliografı́a. 84. Apéndice A. Archivo de Zona Utilizado en Servidor Autoritativo A.1. Archivo de Zona sin Firmar zone.test . . . . . . . . . . . . . . . . . . . . . A.2. Archivo de Zona Firmado zone.test.signed . . . . . . . . . . . . . . . . . .. 86 86 87. Apéndice B. Archivo de Configuración de Servidor Autoritativo. 91. Apéndice C. Paquetes de Respuesta de DNS C.1. Paquete de Respuesta sin DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . C.2. Paquete de Respuesta con DNSSEC . . . . . . . . . . . . . . . . . . . . . . .. 93 93 93. Apéndice D. Librerı́a LDNS. 95. Apéndice E. Registros NSEC Generados por el Servidor Proxy. 99. Apéndice F. Archivos de Configuración para Servidor Recursivo 101 F.1. Archivo named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 F.2. Archivo root.hint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Apéndice G. Archivos de Configuración para Servidor Raı́z 103 G.1. Archivo named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 G.2. Archivo root.zone.signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Vita. 107. viii.

(8) Índice de cuadros. 2.1. Estructura de un RR . . . . . . . . . . 2.2. Ejemplos de RR de tipos A, MX y NS 2.3. Estructura de un Paquete de DNS . . 2.4. Encabezado de un Paquete de DNS . . 2.5. Ejemplo de RR de tipo DNSKEY . . . 2.6. Ejemplo de RR de tipo RRSIG . . . . 2.7. Ejemplo de RR de tipo NSEC . . . . . 2.8. Ejemplo de RR de tipo DS . . . . . . 2.9. Enumeración de Zona . . . . . . . . . 2.10. RDATA de registro NSEC3 . . . . . . 2.11. RDATA de registro NSEC3PARAM .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 10 11 12 12 24 26 27 28 31 35 35. Envı́o de Diferente Número de Registros NSEC . . . . Información de BIND 9 provista por dnsperf . . . . . Velocidades en Operaciones RSA de 1024 Bits . . . . . Tiempos de Espera para Respuestas con DNSSEC . . Velocidad en Peticiones x Segundo del Servidor Proxy Utilización del Procesador en Pruebas con dnsperf . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 58 72 75 78 79 79. E.1. Registros NSEC generados por el servidor Proxy . . . . . . . . . . . . . . . . E.2. Registros NSEC generados por el servidor Proxy . . . . . . . . . . . . . . . .. 99 100. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6.. ix. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . ..

(9) Índice de figuras. 1.1. Uso de un servidor Proxy para filtrado de información . . . . . . . . . . . . . 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9.. Estructura Jerárquica DNS . . . . . . . . . . . . . . . . . Procesos Recursivo e Iterativo de Petición de Nombres . . Ataque de Hombre en Medio . . . . . . . . . . . . . . . . Ejemplo de Criptografı́a de Llave Pública . . . . . . . . . Firmado de Mensajes con Llave Privada . . . . . . . . . . Verificación de Mensajes Firmados . . . . . . . . . . . . . Tipos de almacenamiento de llaves privadas recomendados Inclusión de firmas en paquetes de DNSSEC . . . . . . . . Respuesta de DNS con bit de AD . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 7 9 15 16 18 19 21 22 30. 4.1. Paquete de Respuesta de DNSProxy . . . . . . . . . . . . . . . 4.2. Lectura de Paquete de Respuesta de DNS con Ethereal . . . . . 4.3. Paquete de Respuesta con DNSSEC en Ethereal . . . . . . . . 4.4. Arquitectura de Proceso Iterativo . . . . . . . . . . . . . . . . . 4.5. Paquete de Respuesta del Servidor Proxy . . . . . . . . . . . . 4.6. Arquitectura de Proceso Recursivo . . . . . . . . . . . . . . . . 4.7. Paquete de Respuesta del Servidor Recursivo . . . . . . . . . . 4.8. Arquitectura para Delegación de Zona . . . . . . . . . . . . . . 4.9. Paquete de Respuesta en Ambiente de Producción . . . . . . . 4.10. Tarjeta de Firmado Digital Niagara 2100B . . . . . . . . . . . . 4.11. Utilización del CPU en Pruebas con dnsperf . . . . . . . . . . 4.12. Utilización del CPU en Pruebas con dnsperf y Tarjeta Niagara 4.13. Comparativo de Rendimientos en el Servidor Proxy . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 43 50 51 64 65 67 68 69 71 73 76 77 79. x. . . . . . . . . .. . . . . . . . . .. 4.

(10) Capı́tulo 1. Introducción. El incremento continúo de usuarios de Internet a partir de la década de los 90, acompañado del crecimiento de la capacidad de transmisión de las redes de comunicaciones, ha significado un aumento en la dependencia que se tiene hacia el sistema de nombres de dominio (DNS) para la correcta operación por parte de los usuarios de los servicios que se ofrecen en Internet. La posibilidad de relacionar nombres con direcciones IP (de 32 bits en su versión 4, 128 para la versión 6), ha facilitado por mucho la experiencia de los usuarios de Internet con diversos servicios como Web, correo electrónico, mensajerı́a instantánea, etc., puesto que es más sencillo recordar nombres que secuencias de números [1]. Dichos nombres pueden ser de empresas, personas, gobiernos de paı́ses, etc., que las personas pueden reconocer más fácilmente que una secuencia de números. Además de permitir a los usuarios acceder de manera sencilla a la información contenida en Internet, el servicio de DNS permite que dicha información esté disponible para todos los usuarios de la red en el mundo [1]. Al publicar un recurso (documento, foto, sonido, video) en la Internet, se puede acceder a éste con sólo conocer el nombre asociado a la dirección IP de la computadora que lo contiene, y en caso de el servidor de DNS no cuente con dicha información puede obtenerla buscando en otros servidores de DNS hasta dar con la asociación del nombre solicitado con la correspondiente dirección IP. Creada en 1984 por Paul Mockapetris, la especificación del servicio de DNS (RFC’s 882 y 883) describe al servicio como una base de datos distribuida que almacenarı́a los nombres de hosts (computadoras) y su correspondiente dirección IP, sustituyendo de esta manera a los archivos de nombres de hosts (hosts.txt) locales a cada computadora y que contenı́an la información de dicho mapeo [8]. A pesar de todos los beneficios que proporciona el sistema de nombres de dominio, el dar seguridad y certeza a los usuarios y proveedores sobre la información proporcionada mediante dicho servicio no fue parte primordial de la especificación original de DNS. En los 90’s cuando el uso del archivo hosts.txt se volvió inviable y el uso de servidores de DNS aumentó considerablemente, se detectaron las siguientes fallas de seguridad en dicho servicio [8]: La naturaleza del servicio de DNS lo hace propenso a ataques de negación de servicio 1.

(11) (DoS), ya que el tamaño de las peticiones es mucho menor comparado con el tamaño de las respuestas que envı́a el servidor de DNS. No existe forma de verificar que las entradas (relación nombre con dirección IP) son legı́timas ya que no existe un sistema de autenticación para las mismas. La comunicación entre clientes y servidores de DNS no está protegida, permitiendo a un intruso interceptarlas y crear peticiones y respuestas propias mientras éstas están en marcha. No existe autenticación para servidores de DNS, por lo que un tercero podrı́a hacerse pasar por un servidor de DNS válido y redirigir las peticiones de los clientes a computadoras de su propiedad. A raı́z de estos descubrimientos, los intentos de ataque contra este servicio se incrementaron y muchos lograron fructificar como el ataque ocurrido en 1997 realizado por Eugene Kashpureff. En dicho ataque Kashpureff redirigı́a a los usuarios del sitio Web de Network Solutions a un sitio Web de su autorı́a [7]. En 1993, en una reunión de la IETF (Internet Engineering Task Force) celebrada en Houston, se inició el trabajo en una especificación del servicio de DNS que involucrarı́a a la seguridad como una caracterı́stica principal del mismo [8]. Ataques como el de Kashpureff lograron acelerar el proceso de creación de la especificación para que incluso ahora esté disponible para servidores de DNS de naturaleza abierta como BIND. Los requerimientos principales para la nueva especificación de DNS, denominada DNSSEC (DNS Security), abarcan la integridad de los datos y la autenticación del origen de los mismos. Dicha especificación no incluye la encriptación de los datos que por naturaleza son públicos y la autenticación entre clientes y servidores previo al intercambio de mensajes, esto último para hacerlo compatible con los servidores que implementan el servicio de DNS con la especificación original [8]. La especificación de DNSSEC implica el uso de mecanismos criptográficos de llave pública para el firmado de la información contenida en cada servidor de DNS. El firmado consiste en utilizar una función de hash sobre la información contenida en los archivos del servidor para obtener un valor que deberá ser idéntico al pasar la información a otro servidor o de lo contrario se considerará que la información ha sido alterada y por lo tanto no es fidedigna [6]. De esta manera un cliente de DNS (resolver ) puede comprobar que la información que recibe de una consulta proviene en efecto de un servidor legitimo de DNS. A pesar de las ventajas provistas en materia de seguridad por DNSSEC, se han detectado diversas fallas en la especificación original que han impedido la implementación de DNSSEC a gran escala [10]: 1. La especificación actual permite conocer todos los registros (nombres de dominio) dentro de una zona (conjunto de nombres) al proporcionar los registros anterior y posterior al nombre solicitado cuando dicho nombre no existe en el servidor de DNS. Un individuo 2.

(12) podrı́a enumerar todos los registros contenidos en el servidor de DNS (zone walking o enumeración de zona) y realizar ataques a ese servidor si es que contiene un registro del nombre de dominio que quiera atacar. 2. Actualmente el intercambio de llaves (key rollover ) para comprobar la autenticidad de los datos que un servidor de DNS ostenta se realiza en forma manual, requiriendo la intervención de los administradores de los servidores cada vez que las llaves se modifiquen. 3. Es actualmente objeto de controversia la decisión de qué entidad (organización) se encargará del firmado en los servidores de DNS de mayor jerarquı́a, los servidores raı́z. 4. No existe consenso en la manera que deben de proceder las aplicaciones que solicitan información a servidores de DNS con DNSSEC implementado al recibir una respuesta no válida.. Este trabajo de investigación presenta una alternativa de solución al primer problema de DNSSEC descrito con anterioridad (enumeración de zona), mediante la construcción de un servidor Proxy que sirva de intermediario entre clientes de DNS y un servidor autoritativo de DNS con DNSSEC implementado. El Proxy cumplirá la función de filtrar la información que no se desea que sea pública para los clientes y que debido a la especificación de DNSSEC, el servidor autoritativo divulgarı́a. Para lograr este fin, el servidor Proxy implementará una técnica conocida como firmado en lı́nea, que fue propuesta como solución al problema de enumeración de zona, que implica modificar la información contenida en los registros que son devueltos al cliente, además de firmar digitalmente dichos registros antes de devolverlos. La implementación del firmado en lı́nea en el servidor autoritativo de DNS, implica que dicho servidor tendrá que efectuar trabajo adicional para firmar las peticiones y ocultar la información que pueda permitir a los clientes enumerar los registros de la zona. La presente tesis analiza como con el uso de un servidor Proxy que implemente el procedimiento de firmado en lı́nea, apoyado de una tarjeta electrónica equipada con su propio procesador y que se utilice exclusivamente para firmar digitalmente la información modificada por el Proxy, se puede impedir la enumeración de zona, eliminando al mismo tiempo del servidor autoritativo la carga computacional que implica realizar el firmado en lı́nea, ya que el Proxy le provee de ese servicio. Además se analiza el impacto en cuanto a peticiones resueltas por segundo provocado por tener un servidor Proxy filtrando (y firmando) información que va dirigida los clientes. Esto puede observarse en la figura 1.1, donde se explica el funcionamiento general del servidor Proxy. En un primer punto el cliente envı́a su petición al servidor Proxy, la cual es redirigida al servidor autoritativo para que la responda como cualquier petición normal de DNS. El servidor autoritativo devuelve la respuesta al Proxy y es en este momento cuando el Proxy actúa, modificando el paquete original si dicho paquete contiene registros que permitan enumerar la zona. La computadora donde el Proxy se ejecuta, también contiene la tarjeta electrónica que permite al CPU de la computadora delegar 3.

(13) las operaciones de firmado digital al procesador de dicha tarjeta. Finalmente el paquete ya firmado y modificado es devuelto al cliente, que asume la respuesta como proveniente de un servidor autoritativo. Cabe aclarar que la comunicación entre el cliente, el Proxy y los servidores autoritativos será a través del intercambio de datagramas (UDP), tal y como ocurre con la mayorı́a de las implementaciones de DNS que existen en la actualidad.. Figura 1.1: Uso de un servidor Proxy para filtrado de información En las siguientes secciones se incluye el marco teórico necesario para la investigación y posteriormente se define el problema a tratar en la investigación, para después abordar la solución propuesta al mismo, incluyendo los resultados obtenidos al aplicar dicha solución. Finalmente se incluyen recomendaciones para futuros trabajos en esta área y se enumeran las conclusiones a las que se llegaron durante la realización de este trabajo.. 4.

(14) Capı́tulo 2. Marco Teórico. En esta sección se describe el sistema de nombres de dominio DNS para posteriormente presentar la especificación DNSSEC y los problemas asociados a la misma, haciendo énfasis en el problema de enumeración de zona, finalmente se describen las soluciones existentes y en desarrollo a dicho problema.. 2.1.. Sistema de Nombres de Dominio. El Sistema de Nombres de Dominio es en sı́ una base de datos distribuida, donde se almacenan y asocian muchos tipos de información, pero que predominan los datos donde se asocian direcciones IP a nombres de dominio de Internet como por ejemplo, la dirección 192.168.2.170 se asocia con el nombre de dominio ejemplo.com., ası́ los usuarios que introduzcan en sus programas de aplicación (navegadores de Internet, clientes de correo electrónico, etc.,) dicho nombre, serán redirigidos con la ayuda de un servidor de DNS a la máquina que tenga asignada dicha dirección IP [1].. 2.1.1.. Historia. En los años 70, la red que fue antesala de la Internet, ARPAnet gozó de un crecimiento moderado que le permitió satisfacer las necesidades de los usuarios sin requerir grandes inversiones de esfuerzo para asegurar su escalabilidad. En ese entonces ya se contaba con un sistema de nombres de dominio, dicho sistema era local a cada computadora y consistı́a en un archivo de texto (hosts.txt) que contenı́a relaciones de dirección numérica y nombre de dominio para cada computadora conectada a la ARPAnet. Dicho archivo era actualizado por el Stanford Research Institute (SRI) mediante su Network Information Center (NIC). El uso de un archivo local a cada máquina para mapear nombres de dominio con direcciones IP era justificado ya que en ese entonces el número de computadoras conectadas a la ARPAnet era reducido. Pero conforme el número de computadoras conectadas que demandaban contar con un nombre de dominio para ser identificados con mayor facilidad aumentó, el tamaño del archivo se incrementó y las constantes modificaciones realizadas a dicho archivo obligaron a los usuarios a actualizar con frecuencia su propia 5.

(15) versión del archivo hosts.txt para esta al dı́a [1]. Una solución escalable era demandada para los problemas que representaba el estar moviendo constantemente un archivo que crecı́a exponencialmente a medida de que ARPAnet fue adoptando el modelo TCP/IP como esquema de direccionamiento. Problemas de consistencia del archivo (diferencias entre versiones) y de colisión de nombres (nombres de dominio repetidos para diferentes direcciones IP) provocaron que las entidades de gobierno de ARPAnet empezaran a trabajar por una solución que permitiera una administración local de la información referente al mapeo de nombres con direcciones pero que al mismo tiempo las actualizaciones fueran disponibles globalmente. En dichos trabajos iniciados por las autoridades, se describieron las cualidades que deberı́a de tener el nuevo sistema, principalmente la de estar basado en una estructura jerárquica para asegurar que los nombres de dominio utilizados sean únicos [1]. En 1984, Paul Mockapetris del Information Sciences Institute de la USC diseñó la arquitectura del DNS como lo conocemos actualmente. En los documentos RFC 882 y 883, el describe la estructura jerárquica del sistema de nombres, parte central del mismo. Posteriormente se hicieron revisiones a la especificación de DNS original y se incluyeron dichas modificaciones en los documentos RFC 1034 y 1035, que con el transcurso del tiempo también han sido modificados para incluir aspectos que no se tomaron en cuenta en las primeras especificaciones como los mecanismos de actualización, seguridad, etc., por ejemplo el RFC 3425 que actualiza sólamente del RFC 1035 la sección 6.4 que se refiere a las peticiones inversas de DNS (preguntas para obtener el nombre de dominio de la máquina para la que ya se conoce la dirección IP correspondiente) [1][14].. 2.1.2.. Descripción. Como se mencionó anteriormente, el sistema de nombres de dominio DNS es una base de datos distribuida donde se almacena la información de los equipos conectados a la red que cuentan con un nombre de dominio propio para que puedan ser identificados con facilidad. Se ha utilizado a lo largo de este escrito la palabra servicio para referirse al DNS, debido a que este sistema funciona a través de un esquema cliente - servidor, donde la computadora que tenga asignado el rol de servidor, ejecutará un programa denominado servidor de nombres que será el encargado de proporcionar a la computadora que tiene el rol de cliente, la relación dirección IP - nombre de dominio cuando la computadora cliente le envı́e una petición a través de programas denominados resolvers. Los resolvers también se encargan de recibir las respuestas del servidor y hacerlas disponibles para las aplicaciones locales de los clientes como navegadores de Web o programas que reciban y envı́en correo electrónico [1]. Además de los resolvers y los servidores de nombres, la información intercambiada entre servidores y clientes en forma de peticiones y respuestas constituye una de las tres partes fundamentales del sistema de nombres. Dicha información es conocida como registro y en 6.

(16) cada registro se localiza la dirección IP con su correspondiente nombre de dominio [9]. Los registros de DNS se encuentran organizados de manera jerárquica, de manera similar a la estructura de datos conocida como árbol binario de búsqueda, pero los nodos existentes en dicho árbol pueden contar con más de 2 ramificaciones. Cada nodo cuenta con una etiqueta de texto que identifica el nodo con respecto a su nodo padre, mientras que el nodo raı́z (root) tiene el caracter ’.’ (punto) como etiqueta de texto. Cada nodo representa una partición del conjunto de dominios y puede ser dividido en subdominios especı́ficos para ese dominio [1]. En la figura 2.1 [1][9], se observa la estructura de datos jerárquica utilizada por el servicio de DNS, teniendo en el nodo raı́z al caracter punto y si uno desciende el árbol hasta llegar a un nodo hoja, se puede formar un nombre de dominio completo. Por ejemplo, si se desciende por el árbol por el nodo hijo del nodo raı́z y marcado con la palabra com, posteriormente se desciende por el nodo hijo example y finalmente se llega al nodo hoja www, formando ası́ el nombre de dominio www.example.com., nótese el punto al final del nombre de dominio para denotar el nodo raı́z.. Figura 2.1: Estructura Jerárquica DNS En la actualidad, organizaciones privadas y públicas poseen y mantienen conjuntos de subdominios de nombres que pueden ser utilizados por las mismas organizaciones para facilitar el acceso a los productos y servicios que ofrecen o también las organizaciones pueden rentar o vender dichos nombres a particulares. Cabe recalcar que la administración del nodo raı́z y de sus hijos directos (edu, gov, com, mil, etc.) recae en los Network Information Centers, ninguna otra organización puede administrar dichos nodos del árbol. Se habló anteriormente de manera general de los servidores de nombres y clientes (re7.

(17) solvers) como componentes principales del servicio de DNS, ahora se profundizará en los tipos de servidores nombres, tipos de registros de nombres de dominio, estructura de las peticiones de información (preguntas y respuestas) y las agrupaciones de la información para facilitar la administración de la misma (zonas). También se presenta información sobre los problemas de seguridad que aquejan al servicio en su especificación original.. 2.1.3.. Tipos de Servidores de Nombres. Los servidores de nombres pueden que no posean la información que los clientes les solicitan sobre ciertos dominios, por lo que pueden contar con la funcionalidad de preguntar por dicha información a servidores de nombres ubicados en un nivel superior del árbol de dominio antes presentado, éstos a su vez podrı́an preguntar a servidores que sı́ cuentan con la información o dar ellos mismos una respuesta al cliente sobre la existencia (o no existencia) de dicho dominio en sus registros. Estas funciones clasifican a los servidores de nombres en recursivos y autoritativos respectivamente: Servidores Recursivos: Se les denomina ası́ a este tipo de servidores porque utilizan la resolución recursiva, proceso que consiste en enviar peticiones recursivas a servidores de nombres para encontrar información sobre un dominio que el servidor recursivo no posee [1]. Las peticiones del servidor recursivo son realizadas al servidor de dominio raı́z y posteriormente van descendiendo el árbol de dominios hasta topar con el servidor de dominio que si tiene la respuesta a la petición del cliente (ver figura 2.2). Servidores Autoritativos: Estos servidores realizan el proceso iterativo, en el cual el servidor devuelve la respuesta más completa sobre los dominios que dichos servidores poseen (administran). Solo existe una respuesta para cada petición y no se realizan preguntas adicionales a otros servidores si el servidor no cuenta con la información solicitada [1]. En este último caso, el servidor devolverá al cliente información que le podrı́a servir para localizar al servidor que sı́ tiene la respuesta a su petición. Estos servidores se encargan de administrar conjuntos de nombres de dominio ubicados en niveles inferiores del árbol de nombres de dominio (ver figura 2.1), por lo que son de vital importancia para el funcionamiento correcto de la Internet y por consiguiente también son frecuente blanco de ataques. En la figura 2.2 [1], se observa un ejemplo de una petición realizada por un cliente que desea conocer la dirección IP del dominio girigiri.gbrmpa.gov.au (etapa 1). Dicha petición es recibida por el servidor recursivo que al no contar con la información pregunta al servidor de DNS raı́z (etapa 2) por la dirección IP del dominio solicitado por el cliente. El servidor raı́z le responde (etapa 3) con la dirección IP del servidor que ubicado en el segundo nivel de la jerarquı́a que tiene autoridad sobre el dominio au. Al recibir esa respuesta, el servidor recursivo repite el proceso de preguntar a un servidor autoritativo, en este caso au por la dirección IP del dominio solicitado (etapa 4). El servidor autoritativo da la mejor respuesta al proporcionar la dirección IP del servidor que administra el dominio gov ubicado en el 8.

(18) tercer nivel de la jerarquı́a (etapa 5). En las etapas posteriores se sigue el mismo esquema de peticiones y respuestas utilizado con los servidores autoritativos, hasta que se llega con el servidor que administra el dominio gbrmpa y que tiene autoridad para dar información de los dominios ubicados en el nivel inmediato inferior, en este caso el dominio girigiri. Finalmente la información es devuelta al servidor recursivo quién a su vez devuelve el resultado obtenido al cliente. Como se observa, en una petición a un servidor recursivo, se combinan los procesos recursivo e iterativo.. Figura 2.2: Procesos Recursivo e Iterativo de Petición de Nombres. 2.1.4.. Registros de Datos. Como se explicó con anterioridad el DNS puede verse como una base de datos, donde los registros de datos denominados Resource Records (RR) para el servicio de DNS contienen la información (direcciones IP) que requieren los clientes para poder acceder a los servicios de Internet [9]. En una base de datos conformada por renglones y columnas, los registros de datos son los renglones, mientras que las columnas serán los elementos que conforman cada uno de los registros.. 9.

(19) 0. 1. 2. 3. 4. 5. 6. 7. 8 9 10 NAME TYPE CLASS TTL RDLENGTH RDATA. 11. 12. 13. 14. 15. Cuadro 2.1: Estructura de un RR. En el cuadro 2.1 [15], se pueden apreciar los campos que componen la estructura de un RR. Las longitudes de dichos campos se miden en bits, que es la unidad de datos utilizada para expresar el tamaño de los campos de los RR que van incluı́dos en los paquetes de datos que se envı́an y se reciben para el servicio de DNS. Dicha estructura se describe a continuación [9][15]: NAME: También conocido como Owner Name, este es el nombre del dominio al que pertenece el RR. TYPE: Campo de 16 bits que denota el tipo de RR. Los tipos de registros se refieren los recursos y servicios asociados a un nombre de dominio. Los tipos de registro que existen desde la primera especificación de DNS son los siguientes y son solicitados con mayor frecuencia por los clientes son los siguientes: • A: Tipo de registro que indica que se incluye la dirección IP versión 4 del nombre de dominio correspondiente. • AAAA: Igual que el tipo A, pero la dirección IP que se envı́a está formateada en su versión 6. • NS: Tipo de registro que indica que el nombre de dominio corresponde a un servidor de nombres autoritativo. • CNAME: Identifica al nombre de dominio como un nombre canónico para un alias. Los nombres canónicos representan nombres calificados para funcionar como nombres de dominios ya que respetan reglas de tamaño máximo para los nombres de dominio (255 caracteres, 63 caracteres entre cada caracter ’.’ para las etiquetas) y además respetan las reglas de uso del caracter ’.’ como la de incluirlo siempre al final de cada nombre de dominio. • SOA: Identifica al nombre de dominio como el inicio de una zona de autoridad. • MX: Tipo de registro que indica que el nombre de dominio corresponde a un servidor de correo electrónico. CLASS: Valor de 16 bits que indica la familia de protocolos a la que corresponde el RR. Para esta investigación la familia de protocolos utilizada es la familia IN, que corresponde a los protocolos existentes en la Internet. 10.

(20) NAME itesm.mx. google.com. yahoo.com.. TTL 3600 10800 172800. CLASS IN IN IN. TYPE A MX NS. RDATA 200.34.200.229 10 smtp1.google.com. ns1.yahoo.com.. Cuadro 2.2: Ejemplos de RR de tipos A, MX y NS. TTL: Entero de 32 bits con signo que especifica el intervalo de tiempo que el RR será almacenado en el caché del servidor antes de que la información tenga que ser consultada de nuevo. La utilidad de este campo radica en que los servidores de nombres pueden almacenar en el caché información de los nombres de dominio más solicitados y ası́ atender de una manera más rápida a los clientes ya que no se ejecutarı́a ningún proceso iterativo y recursivo porque la información está disponible. RDLENGTH: Entero de 16 bits que indica la longitud del campo RDATA que contiene la información relativa al nombre de dominio. Por lo general los resolvers no despliegan este campo al presentar la información obtenida del servidor sino que se salta de inmediato a presentar el campo RDATA. RDATA: Campo que contiene una cadena de caracteres de longitud variable que describe al recurso. Los datos de este campo se formatean de diferente manera de acuerdo al tipo y clase del RR. Para registros A y AAAA, aquı́ se incluirı́a la dirección IP correspondiente al nombre de dominio ubicado en el campo de Owner Name. El cuadro 2.2 presenta ejemplos de RR de tipos MX, NS y A de dominios conocidos. Obsérvese que en el caso de los RR de tipo NS y MX, no se devuelve una dirección IP como el tipo A, sino que se devuelve el nombre de dominio al que se refiere el tipo de RR solicitado. Estos registros se consultaron utilizando la herramienta dig que viene instalada por default en el sistema operativo Linux en sus versiones recientes. Tecleando el comando mas el nombre del dominio y el tipo de registro a buscar (dig dominio RRTYPE), se obtuvieron los RR del cuadro 2.2.. 2.1.5.. Estructura de los Mensajes de DNS. El servicio de DNS se encuentra ubicado en la capa de aplicación de los modelos OSI y TCP/IP, al igual que el servicio de Web (HTTP), de correo electrónico (SMTP) y transferencia de archivos (FTP). La información y las peticiones para este servicio se envı́an por el puerto 53 del protocolo UDP, por lo tanto este servicio no está orientado a la conexión, por lo que si el mensaje de respuesta a una petición llega a perderse en el trayecto por la red de comunicaciones, el cliente debe enviar de nuevo la pregunta al servidor para esperar la respuesta de nuevo.. 11.

(21) En la especificación original de DNS realizada por Paul Mockapetris, se definió también la estructura de los mensajes (paquetes de información) que serı́an intercambiados entre clientes y servidores. Se especificaron los campos que contendrı́an los paquetes de información y el tamaño de los mismos se fijó a un máximo de 512 bytes, que es el tamaño máximo permitido para un datagrama (denominación del paquete de información del protocolo UDP) [15].. HEADER QUESTION ANSWER AUTHORITY ADDITIONAL Cuadro 2.3: Estructura de un Paquete de DNS. En el cuadro 2.3 [15], se observa la estructura de un paquete de DNS, dicha estructura es la misma para los paquetes de preguntas y de respuestas, pero en los paquetes de preguntas, solo se incluyen las secciones del encabezado y la sección de pregunta que contiene el nombre del dominio por el que se está solicitando información al servidor de DNS. Un paquete de respuesta incluye además de las dos secciones que se incluyen con el paquete de pregunta, al menos una de las secciones posteriores, ya sea la de respuesta (si es que la búsqueda fue exitosa) o las secciones autoritativa y adicional en el caso de que la búsqueda no haya traı́do resultados. Una cabecera de un paquete de DNS ya sea de petición o de respuesta, incluye campos que contienen información importante para poder identificar un paquete de petición con su correspondiente respuesta, también la información de los campos es utilizada por los servidores para realizar un proceso de búsqueda de la información de acuerdo a la solicitud hecha por el cliente si les es posible. En el cuadro 2.4 [15], se incluyen los elementos que conforman la cabecera de un paquete de DNS [15].. 0 QD. 1. 2. 3. 4. OPCODE. 5. 6. AA. TC. 7. 8. ID RD RA QDCOUNT ANCOUNT NSCOUNT ARCOUNT. 9. 10. 11. 12. Z. Cuadro 2.4: Encabezado de un Paquete de DNS. 12. 13. 14. RCODE. 15.

(22) Los campos de la cabecera se definen a continuación [15]: ID: Un identificador de 16 bits asignado por el programa que creo la petición. El servidor que genere la respuesta a esa petición añadirá el mismo valor de ID al entregar el RR al cliente, con el fin de que el cliente pueda identificar la respuesta correspondiente a cada pregunta que hizo al servidor. QR: Este campo cuenta con un bit que especifica si el paquete corresponde a una pregunta (valor del bit es 0) o de una respuesta (valor del bit es 1). OPCODE: Este es un campo de 4 bits que especifica el tipo de petición de un mensaje de DNS. El valor es colocado por el creador de la petición y es copiado en el mensaje de respuesta. Para esta investigación, sólo se manejarán peticiones estándares, por lo que el valor de OPCODE utilizado será de 0. AA: Campo de un bit que indica si el servidor que responde tiene autoridad sobre el dominio por el que se preguntó (valor del bit es 1 para servidores autoritativos). TC: Campo de un bit que indica si el mensaje fue truncado debido a que sobrepasa el tamaño permitido en unidades de datos para ser transmitido en la red (valor del bit es 1). RD: Campo de un bit, que encendido indica que se desea que el servidor que recibe la petición realice un proceso recursivo de búsqueda a otros servidores para obtener la información solicitada por el cliente. El cliente se encarga de colocar el valor de este bit en el paquete de pregunta y dicho valor es copiado en el paquete de respuesta. RA: Campo de un bit que es encendido o apagado en el paquete de respuesta por el servidor de nombres. Denota en caso de que el valor del bit sea 1 que la respuesta provino de un proceso recursivo y que dicho proceso está disponible para futuras búsquedas. Z: Campo reservado para uso futuro. Tiene el valor de 0 para los dos tipos de paquetes. RCODE: Campo de 4 bits similar al campo OPCODE, pero éste se utiliza para denotar el tipo de respuesta recibida. Para esta investigación el valor del campo será de 0 para denotar que no hubo error en la respuesta y la búsqueda fue exitosa, o de 3 para denotar que no hubo error en la respuesta pero no se obtuvieron resultados en la búsqueda. QDCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el número de entradas (RR’s) en la sección de preguntas. ANCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el número de entradas (RR’s) en la sección de respuestas. NSCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el número de entradas (RR’s) en la sección autoritativa.. 13.

(23) ARCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el número de entradas (RR’s) en la sección adicional.. La secciones de pregunta, respuesta, autoritativa y adicional, están formadas de RR’s que tienen el formato mencionado con anterioridad. Los servidores deben incluir al menos una de las tres últimas secciones y opcionalmente pueden incluir las demás para proporcionar al cliente una mayor información sobre el nombre de dominio por el que preguntó. Por ejemplo, un registro SOA irá incluido en la sección autoritativa cuando un servidor autoritativo responda a una petición para la cual no encontró respuesta, para asegurar al cliente que dicho servidor tiene autoridad sobre la zona y desconoce el nombre de dominio preguntado.. 2.1.6.. Zonas. En la terminologı́a de DNS, existen las Zonas, que representan un conjunto de nombres de dominio administrados por un servidor de DNS que tiene autoridad sobre ellos. La ventaja de agrupar grupos de dominios en zonas radica en que el conjunto de dominios puede ser manejado como una sola unidad que puede ser delegada a una organización para su mejor administración, por ejemplo, todos los nombres de dominio que estén ubicados debajo del nodo itesm.mx. serán administrados por el Instituto Tecnológico de Monterrey. Dichos dominios pueden ser mty.itesm.mx., chs.itesm.mx., etc. Para este caso, la zona será denominada como itesm.mx. [1]. La zona contiene los nombres de los dominios contenidos dentro del dominio utilizado para nombrar a la zona. Inclusive si los nombres de dominio no han sido asignados a un RR, estos nombres son agregados a la zona para tenerlos reservados para uso futuro [1]. La zona dentro del servidor de DNS se presenta en un archivo de texto que contiene todos los RR que la zona contiene.. 2.1.7.. Problemas de Seguridad. Como se mencionó con anterioridad, el principal problema de seguridad de la especificación original de DNS es la falta de protección que existe en la comunicación entre clientes y servidores. Al ser un servicio basado en datagramas, un intruso podrı́a capturar los paquetes dirigidos al servidor de nombres (complemente legibles para él por la naturaleza pública del DNS), y proporcionar a los clientes respuestas forjadas por él mismo. Este ataque a la seguridad es una forma de ataque de hombre en medio, ya que la comunicación entre dos entidades es interceptada y posiblemente alterada por un tercero. En la figura 2.3, puede observarse como funciona un ataque de hombre en medio para el caso del servicio de DNS (otros servicios también pueden ser afectados si no existe autenticación entre clientes y servidores). El atacante se hace pasar por el servidor de DNS y el 14.

(24) Figura 2.3: Ataque de Hombre en Medio cliente dirige erróneamente sus paquetes de pregunta a la computadora de éste en lugar de dirigirlos al servidor de DNS legı́timo. El atacante puede leer dichos paquetes y reenviarlos al servidor de DNS como si fueran peticiones suyas, por lo que el servidor de DNS le contestará al atacante y no al cliente original. El atacante puede entonces leer o modificar la respuesta antes de enviarla al cliente original para que éste siga creyendo que está interactuando realmente con el servidor de DNS y las respuestas son legı́timas. En la especificación original de DNS no era posible constatar la veracidad de la información intercambiada, por lo que la IETF planteó extensiones de seguridad al servicio original que sirvieran para asegurar la veracidad de la información que se recibe de los servidores y clientes de DNS.. 2.2.. DNS Security (DNSSEC). Los problemas de seguridad anteriormente mencionados en el servicio de DNS, hicieron inminente un replanteo de los procesos de envı́o de respuestas a los clientes para garantizar a éstos que la información devuelta realmente proviene de servidores de DNS auténticos y no de servidores apócrifos o de paquetes de información forjados por un atacante. La criptografı́a de llave pública fue incorporada al servicio de DNS para firmar los registros con la ’estampa’ del servidor de DNS, de manera que un cliente puede comprobar que al recibir un RR realmente proviene de un servidor de DNS legı́timo verificando la firma que acompaña al RR. La especificación de DNSSEC incorpora los conceptos de criptografı́a de llave pública para el firmado de los RR. Dichos conceptos serán expuestos a continuación para facilitar el entendimiento de los procesos de firmado sobre los registros. 15.

(25) 2.2.1.. Conceptos Básicos de Criptografı́a de Llave Pública. A la criptografı́a de llave pública se le conoce como criptografı́a asimétrica, donde los individuos que deseen cifrar información cuentan con dos llaves, una privada y la otra pública, a diferencia del cifrado simétrico, donde se utiliza la misma llave para cifrar y descifrar. Con el cifrado asimétrico, el individuo conserva su llave privada como secreta mientras que la llave pública la pone a disposición de los individuos que quieran enviarle mensajes cifrados a él. La llave pública es entonces utilizada para cifrar mensajes que solo el poseedor de la llave privada correspondiente podrá descifrar. Esto puede observarse en la figura 2.4 [5], donde suponiendo que Jane quiere enviarle un mensaje cifrado a John, hará uso de la llave pública de John para cifrar el mensaje antes de transmitirlo, dicho mensaje sólo podrá ser descifrado por la llave privada de John en cuanto éste lo reciba [5].. Figura 2.4: Ejemplo de Criptografı́a de Llave Pública La ventaja de utilizar 2 llaves para el proceso de cifrado y el proceso inverso, radica en la administración de las mismas. Los individuos que deseen cifrar mensajes a un tercero solamente necesitan la llave pública de éste, que está disponible para todos los que deseen utilizarla. La llave privada no requiere ser transmitida a otros individuos como ocurrı́a con el esquema simétrico, esquema que comprometı́a la llave de cifrado si ésta era interceptada mientras se transmitı́a. Adicionalmente, no es posible derivar la llave privada de la llave pública aunque estén relacionadas matemáticamente. Para la generación de llaves tanto privadas como públicas existen diversos algoritmos matemáticos que demandan mayor capacidad de procesamiento que los algortimos que gene16.

(26) ran llaves simétricas por el simple hecho de generar dos llaves en lugar de una sola. Al final, las llaves son valores numéricos generadas por los algoritmos, donde dependiendo de su longitud, pueden ser más fáciles o más difı́ciles de adivinar por parte de un individuo ajeno a éstas. Por lo general los algoritmos manejan tamaños de 1024 bits para las llaves que generan y si se cuenta con la capacidad de procesamiento adecuada, este tamaño deberı́a de incrementarse para dificultar los ataques contra las llaves. Dentro de los principales algoritmos para la generación de llaves privadas y llaves públicas se destacan los siguientes: 1. Diffie-Hellman 2. ElGamal 3. DSA (Digital Signature Algorithm) 4. RSA (Iniciales de los apellidos de los creadores de este algoritmo: Ron Rivest, Adi Shamir y Leonard Adleman) En este trabajo de investigación el algoritmo a utilizar para la generación de llaves será el algoritmo RSA de 1024 bits de tamaño para las llaves para asegurar la compatibilidad con el formato de las llaves utilizadas en el servidor Proxy y en el servidor de DNS autoritativo. En dicho algoritmo, la llave pública consta de 2 componentes numéricos, un entero no negativo n que es el módulo y e, un exponente público que es un entero no negativo también. Ambos valores numéricos son utilizados en conjunto en formulas matemáticas de cuya resultado se obtienen las llaves privadas y públicas, ofreciendo la seguridad suficiente de que es prácticamente imposible derivar la llave privada si se cuenta sólo con la llave pública [11]. Las llaves privadas y las llaves públicas también pueden utilizarse para firmar información digitalmente, es decir, pueden usarse para agregar a los mensajes una firma que consiste en generar con la llave privada y una función de hash (función que genera un resumen de una cadena de bits que reciben como entrada) una secuencia de texto que se añade al mensaje y que con la llave pública correspondiente otra persona pueda comprobar la procedencia del mensaje. Para firmar el mensaje y comprobar la identidad del que firma se deben de seguir los siguientes pasos (ver figuras 2.5 y 2.6) [5]: 1. Hacer pasar el texto del mensaje por la función de hash para producir una cadena de mı́nimo 128 bits que sirva como resumen de la información contenida en el mensaje. La función de hash genera una cadena de bits que resumen la información contenida. Los algoritmos a utilizar para generar dicho resumen pueden ser MD2, MD4, MD5, que son de 128 bits o el algoritmo SHA-1 que es de 160 bits. No es posible recuperar el texto original a partir del resumen. 2. Utilizar la llave privada de manera inversa al proceso de encriptación descrito anteriormente, es decir ahora la llave privada se utiliza para encriptar la cadena de bits 17.

(27) de resumen. La cadena resultante es anexada al mensaje. Dicha cadena es la firma del autor del mensaje. 3. Finalmente el mensaje se envı́a al destinatario. El destinatario al recibirlo, ejecuta una función de hash sobre el cuerpo del mensaje que se envió como texto plano (sin encriptar). A su vez, el destinatario aplica la llave pública del remitente a la firma para desencriptarla para obtener el valor de hash que el autor agregó a su mensaje (antes de encriptarlo). 4. Si la cadena de la función de hash que se obtuvo del texto del mensaje coincide en su totalidad con la cadena del hash que se obtuvo de la firma, se confirma la identidad del remitente. Si dichas cadenas no son iguales el mensaje puede considerarse como alterado y a su vez como apócrifo.. Figura 2.5: Firmado de Mensajes con Llave Privada Este esquema de firmado de mensajes, es utilizado para firmar los registros de DNS. Dicha firma es devuelta en un RR de tipo RRSIG. La firma va incluı́da en la sección de RDATA. Los demás elementos como el Owner Name, TTL, y RDATA adicionales se incluyen en ese registro también para identificar cual es el texto que se está firmando.. 2.2.2.. Descripción de DNSSEC. Las extensiones de seguridad al servicio de DNS (DNSSEC) añaden elementos importantes de la seguridad como lo son la autenticación de las fuentes de la información y la integridad de los datos provistos por dichas fuentes. Dichas extensiones de seguridad ya habı́an sido descritas en el RFC 2035 pero por la dificultad de escalar esas extensiones al servicio de 18.

(28) Figura 2.6: Verificación de Mensajes Firmados DNS existente en Internet, tuvieron que hacerse modificaciones al documento original para que dicha escalabilidad pudiera lograrse, dichas modificaciones, se describen a detalle en los documentos RFC 4033, RFC 4034 y RFC 4035 [2]. DNSSEC incorpora nuevos conceptos a la especificación original de DNS. La mayorı́a de dichos conceptos involucran el uso de llaves privadas para firmar registros [2]: Cadena de Autenticación: Conjunto de RR’s (RRsets), es decir, RR’s del mismo tipo que aparecen consecutivamente en un mensaje de DNS, en este caso de tipo DNSKEY y DS, estos RRsets contienen tanto llaves como información firmada respectivamente. En esta cadena de autenticación, las llaves públicas contenidas en los RR de tipo DNSKEY se utilizan para validar los registros DS (Delegation Signer ) que contienen resultados de funciones hash aplicadas sobre otros RR de tipo DNSKEY. La verificación con llaves públicas pertenecientes a unos nombres de dominio de los registros que contienen resúmenes de llaves públicas de nombres de dominio en niveles inferiores va creando la cadena de autenticación con lo que se obtiene certeza de que todos los nombres de dominio contienen las llaves correctas para ser firmados con éstas. Llave de Autenticación: Se refiere a la llave pública que se le proporciona al resolver para que realice la autenticación de los datos. El resolver realiza el mismo proceso que se realiza con la cadena de autenticación. Utiliza la llave pública para verificar que la llave incluida en el RR de tipo DNSKEY corresponde al resumen de dicha llave incluido en RR de tipo DS. Llave para Firmado de Llaves - KSK: Llave privada utilizada para firmar las llaves de autenticación para una zona dada. Esta llave es utilizada para firmar las llaves de 19.

(29) firmado de zonas (ZSK). Tanto la KSK como ZSK pueden tener el mismo valor ya que DNSSEC no distingue entre tipos de llave de autenticación, sin embargo, el periodo de validez de la KSK puede diferir del de la ZSK, siendo el de la KSK por lo regular más amplio. Zona Firmada: Una zona cuyos RRsets están firmados y contienen registros de tipo DNSKEY, RRSIG, NSEC y DS correctamente construidos. Llave para Firmado de Zonas - ZSK: Llave de autenticación que corresponde a la llave privada usada para firmar una zona. Esta llave será parte de las llaves de autenticación donde también se encuentra la KSK correspondiente, pero su uso y su ciclo de vida (tiempo de validez) serán diferentes. La ZSK es modificada con mayor regularidad que la KSK.. Integrando los conceptos de llaves mencionados anteriormente, la especificación de DNSSEC proporciona además de los mecanismos de autenticación y de integridad de datos, mecanismos que autentican la negación de la existencia de registros de DNS, es decir que si cierto registro por el que se preguntó no existe dentro de los registros de zona del servidor, se le proporcionará al resolver una prueba fidedigna de que dichos registros no se encuentran en dicho servidor. Los mecanismos que proporcionan este servicio son los siguientes [2]: Inclusión de 4 nuevos tipos de registros, que son el registro RRSIG (Resource Record Signature), DNSKEY (DNS Public Key), DS (Delegation Signer ) y NSEC (Next Secure Domain). Agrega 2 nuevos bits al encabezado original de DNS, CD (Checking Disabled ) y AD (Authenticated Data). Debido a que se incrementa el tamaño de los datos a ser devueltos al cliente, el tamaño del paquete de respuesta de DNS se amplió de los 512 bytes originales a los 4096 bytes para poder acompañar los registros de sus correspondientes firmas.. Con la ayuda de los mecanismos provistos por DNSSEC, se pueden asociar firmas digitales a los RRsets para que los resolvers puedan validar la identidad del servidor que los devuelve como respuesta a una petición. Las firmas digitales son almacenadas en el registro RRSIG que acompañan a cada RRset que se firma. Puede enviarse más de un RRSIG para cada RRset, en estos casos los RRSIG contienen firmas resultantes de la aplicación de diferentes algoritmos matemáticos. Cabe resaltar que la llave ZSK utilizada para firmar la zona, está asociada a esa zona únicamente, no a los servidores autoritativos que administran la zona, debido a que estos servidores pueden tener más zonas que administrar. Las llaves KSK y ZSK deben permanecer en su condición de llaves privadas en lugares seguros y de preferencia estos lugares no deben de poderse acceder desde la red [2].. 20.

(30) La figura 2.7, se muestran los dos tipos de almacenamiento de llaves privadas recomendados por el RFC 4461. El tipo de almacenamiento óptimo es que el se realiza en servidores que no tienen acceso a Internet, por consiguiente el riesgo de que la KSK y la ZSK sean robadas a través de dicha red desaparece. Dicho modo de almacenamiento tiene como desventaja que todas las actualizaciones a las llaves privadas y por consiguiente a los archivos de zona, deben de ser realizadas directamente sobre la computadora que los contenga. En el caso de que se desee contar con actualización dinámica de las llaves, el RFC 4461 recomienda habilitar el acceso a Internet para el servidor que contiene las llaves, permitiéndose la conexión desde el servidor a la red pero no viceversa. Con esta configuración (ver figura 2.7), se logran actualizar los archivos de zona que estén dispersos en la red y se protege a los archivos de llaves privadas del acceso de terceros a la carpeta donde se almacenan, ya que su actualización en el servidor principal sigue siendo manual. Para que el segundo método sea exitoso se debe de contar con mecanismos de seguridad que encripten el contenido de las llaves para que un tercero no pueda apoderarse de ellas mientras son transmitidas [12].. Figura 2.7: Tipos de almacenamiento de llaves privadas recomendados. 21.

(31) El registro DNSKEY es hasta la fecha, el único medio válido para distribuir llaves públicas a los clientes que deseen verificar la autenticidad de la información del servidor. Estos clientes pueden asegurar que las llaves que usan son las correctas al crear cadenas de autenticación con las llaves que les fueron proporcionadas y el resumen que se envı́a en el registro DS [2]. Para proveer al cliente de una negación de existencia de registros que pueda ser validada por éste, se utiliza el registro NSEC, que igualmente va firmado (acompañado de un RRSIG) y que devuelve como respuesta información referente al espacio que deberı́a de ocupar en la zona el dominio preguntado, es decir, proporciona información del sucesor y del predecesor de dicho dominio para asegurar al cliente que el dominio por el que se preguntó no existe. Dicho registro requiere que los nombres de dominio estén ordenados de acuerdo a forma canónica [2]. Cabe aclarar que a pesar de estas modificaciones, la estructura general del paquete de DNSSEC, se mantiene igual a la que se muestra en el cuadro 2.3 que corresponde a la estructura original de paquetes de DNS. Los paquetes de DNSSEC siguen incluyen un campo de encabezado, el campo de pregunta, el campo de respuesta, el campo autoritativo y el campo adicional. Los cambios más radicales se dan en la estructura de los registros, especı́ficamente en la sección de RDATA (ver cuadro 2.1) de los mismos, cuyo tamaño debió de ser incrementado para poder acomodar la información que se le proporciona al cliente para su validación.. Figura 2.8: Inclusión de firmas en paquetes de DNSSEC En la figura 2.8 puede observarse como se envı́an los registros de datos en DNSSEC. A pesar de que el formato se mantiene igual al original de DNS, si el usuario lo solicita, un registro RRSIG que contiene la firma digital de toda la información contenida en el registro de datos (Owner Name, tipo, clase, TTL y RDATA) es colocado por el servidor inmediatamente 22.

(32) después del registro de datos antes mencionado. La inclusión de esta firma es la principal diferencia entre los paquetes de DNS y los de DNSSEC. DNSSEC mantiene como pública la naturaleza de los datos, es decir, no se incluye en la especificación algún método de encriptación de la información contenida en los RR, para continuar siendo conforme a la especificación original de DNS donde toda la información de los RR está disponible para quién la solicite. Tampoco dicha especificación provee mecanismos de defensa contra ataques de negación de servicio, algo a lo que se es vulnerable desde la especificación original, por lo que medidas externas no especificadas deben ser implementadas para contrarrestar estos ataques a la disponibilidad del servicio. El otro problema de DNSSEC radica en que permite enumerar todos los registros contenidos en la zona realizando múltiples peticiones por registros NSEC. Se incluye más información referente a este problema en la sección dedicada al problema de enumeración de zona [2].. 2.2.3.. Registro DNSKEY. El registro DNSKEY almacena las llaves públicas que se utilizan para el proceso de autenticación de la información de los RR. Los registros firmados en la zona son propiamente los registros autoritativos que proporcionan información relevante de la misma, como el registro SOA. Con la ayuda de las llaves insertadas en el RR de tipo DNSKEY, un resolver puede usarlas para validar la información que viene firmada y autenticar el origen. El registro DNSKEY sólo debe de utilizar llaves públicas que correspondan a llaves privadas utilizadas para firmar la zona. Las llaves que no cumplan con dicho requisito no deberán ser incluidas [4]. Como peculiaridad, este registro es independiente del campo de clase y no tiene requerimientos especiales para valores de TTL. El registro está formado de un campo de banderas de longitud de 2 octetos (2 bytes), 1 octeto para el campo de protocolo, 1 octeto para el campo donde se indica el algoritmo matemático utilizado para generar la llave y finalmente el campo donde va incluida la llave pública en sı́ [4]. La descripción de los campos que componen a este registro se incluye a continuación [4]: En el campo de banderas, el bit que ocupa la séptima posición corresponde a la bandera de la llave de la zona. Si dicho bit está encendido, indica que el RR de tipo DNSKEY posee una llave de zona y el Owner Name de esa llave de zona corresponde al nombre de la zona. Si dicho bit está apagado entonces la llave incluida no puede ser utilizada para validar registros del tipo RRSIG que acompañan a los RRsets. El bit 15 de este campo de banderas representa si está encendido que el registro DNSKEY cuenta con una llave que se utiliza como punto de acceso seguro. Los demás bits de este campo no se utilizan aún por lo que mantiene su calidad de reservados y su valor en todos los casos debe ser de 0. El campo de protocolo debe de tener el valor de 3 siempre, si no todo el RR será con23.

(33) siderado como inválido. El campo del algoritmo identifica al algoritmo matemático de criptografı́a de llave pública utilizado para generar la llave. Dicho algoritmo puede ser de tipo DSA/SHA-1, Curva Elı́ptica, RSA/SHA-1, etc. El campo de llave pública almacena el valor de la llave. El formato de esta llave está definido por el algoritmo utilizado para obtenerla.. En el cuadro 2.5 se observa un ejemplo de registro de tipo DNSKEY, siguiendo el formato general de los RR, pero respetando los campos definidos para este nuevo tipo de registro. Se incluyen primeramente el Owner Name, el TTL, la clase y el tipo de registro (DNSKEY), para posteriormente incluir el valor del campo de banderas (256) con el valor del bit 7 encendido. El valor de 3 corresponde al campo de protocolo y el valor 5 que le sigue indica que el algoritmo utilizado para generar la llave es el algoritmo RSA/SHA-1. Finalmente se incluye la llave pública codificada en base 64.. test.. 86400. IN. DNSKEY. 256. 3. 5. AQPbMtIGS6XTiAEky8eltx1Hk7cJxl +EMBcwX4q9Ho/PmRJIb+RFpBfEYNq0 WXrqSGndC980/YVZcd0zjJdeOWWzWC NpAbqaky0bbeMxdbMHXlG/puthKAnH 3qDM3z8P3KrmrhjqYfN5rSdMyEgE1B iwDLo4P7zK4qbiyeCe bPGbQQ==. Cuadro 2.5: Ejemplo de RR de tipo DNSKEY. 2.2.4.. Registro RRSIG. El registro RRSIG es utilizado por los resolvers para validar la información contenida en los RRsets que los preceden en los mensajes devueltos por los servidores. Las firmas digitales son almacenadas dentro de los registros RRSIG. Dicho registro incluye también información legible sobre el nombre, clase y tipo de registro que se está firmando. También se incluye información similar a la que acompaña al registro DNSKEY como lo es información sobre el algoritmo, el tiempo de validez de la firma, el nombre de dominio del servidor que firma y un identificador de llave que permite relacionar esa firma con su correspondiente DNSKEY [4]. Es obligatorio firmar todos los nombres autoritativos de una zona, que generalmente están escritos en su forma canónica. El valor del campo de clase para este registro es el tipo de registro que se está firmando. Igualmente, el valor del campo de TTL debe ser igual al valor de TTL original del registro firmado [4].. 24.

(34) El registro RRSIG está conformado por 8 campos. El primer campo consta de dos octetos que indican el tipo de registro que se está firmando, le sigue un campo de 1 octeto que indica el algoritmo matemático utilizado para generar la firma, a este campo le sigue uno de 1 octeto donde se indica el número de etiquetas (nodos del árbol de dominios) que tiene el Owner Name del registro RRSIG. El siguiente campo abarca 4 octetos, ahı́ se incluye el valor de TTL que debe de coincidir con el del registro que se está firmando. Los dos campos siguientes incluyen la fecha de expiración y de incepción, de 4 octetos cada una, con dichas fechas los resolvers pueden determinar la validez de las llaves [4]. Finalmente los últimos 3 campos lo conforman el identificador de la llave, el nombre del que firma y la firma en sı́. Los campos se describen a continuación [4]: El campo del tipo de registro cubierto identifica el RRTYPE del registro que se está firmando. El campo del algoritmo contiene un valor numérico con el que se identifica al algoritmo matemático utilizado para crear la firma. Dicho algoritmo puede ser de tipo DSA/SHA1, Curva Elı́ptica, RSA/SHA-1, etc. El campo de las etiquetas especifica el número de etiquetas utilizadas en el Owner Name del RR firmado, que es el mismo que aparece en el campo del Owner Name del RRSIG. Si una etiqueta cuenta sólo con el caracter ’*’ que denota un wildcard, dicha etiqueta no es contada en la cifra de este campo. Se incluye el campo del TTL original del RR firmado con el fin de que el RR firmado pueda autenticarse aunque el servidor decremente el valor de TTL del registro original. Los campos de fecha de expiración y de incepción se utilizan para calcular el periodo de validez de la llave. La llave no debe de ser utilizada para verificar firmas si dicha operación se realiza antes de la fecha de incepción o después de la fecha de expiración. El campo del identificador de llave tiene un valor numérico que relaciona al RRSIG con su DNSKEY correspondiente. En casos que existan muchas firmas y muchas llaves, el uso de este campo es vital para poder utilizar la llave adecuada con cada firma. El campo del nombre del que firma debe de coincidir con el Owner Name del registro DNSKEY. Debe de contener el nombre de la zona que cubre el conjunto de registros firmados. El campo de la firma contiene el valor obtenido con un algoritmo matemático, siguiendo el esquema de firmado de la figura 2.5. Los datos que se firman incluyen el Owner Name, la clase, el tipo de registro cubierto y demás elementos del RDATA del registro RRSIG.. En el cuadro 2.6 se muestra un ejemplo de registro de tipo RRSIG. Se observa el valor de Owner Name que debe de coincidir con el valor del registro NSEC que se firma. En la 25.

(35) parte de RDATA como primer elemento está el tipo de registro firmado, un NSEC, el número 5 que le sigue indica que el algoritmo matemático utilizado es RSA/SHA1. Posteriormente se indica que el número de etiquetas a firmar es de 1. El TTL que se incluye es igual al TTL original del registro que se firma. En los siguientes 2 campos se encuentran las fechas de expiración e incepción respectivamente en formato YYYY:MM:DD:HH:mm:SS (año, mes, dı́a, hora, minuto y segundo). Posteriormente a este campo va el campo donde se identifica al que está firmando el RR, en este caso, se incluye el Owner Name de la zona. Finalmente se incluye la firma, en formato de base 64.. test. 1200 IN RRSIG NSEC 5 1 1200 20070209163058 20070110163058 32402 test. CO0ueslsSuKJtTKWqFzgRef1b5c9KFK5f8AOG ZlI+ud1uhHlgzLRGkrlETQGgnEacilOqx3oGoiBDsOlcZTJLTCW+Xu8zKOq5eF9 4wMr3gRzn20xalVNwtWTFMRAF1/neofQfglqwfqxNOrGoVdFLRVlYRVYRKdW 4CwfXNw0j60= Cuadro 2.6: Ejemplo de RR de tipo RRSIG. 2.2.5.. Registro NSEC. El registro NSEC se utiliza para proporcionar al cliente una negación firmad del registro solicitado cuando éste no está contenido en los archivos de zona. En dicho registro se incluye el Owner Name autoritativo existente en la zona que va colocado después del nombre de dominio solicitado por el usuario (el siguiente dominio válido). En un archivo de zona, el conjunto de registros NSEC permite formar una cadena de los Owner Names autoritativos que existen en la zona [4]. Al igual que el registro DNSKEY, el registro NSEC es independiente del valor que tenga el campo de clase. El valor del campo TTL debe de coincidir con el valor de TTL mı́nimo declarado para el registro SOA. La estructura del RDATA de este registro consta de sólo 2 campos, el campo del siguiente Owner Name válido y el campo donde se indica de que tipo o tipos de registros cubre el nombre de dominio contenido en el campo que le precede [4]. El campo del siguiente dominio contiene el siguiente Owner Name válido en su forma canónica. El último NSEC tendrá en este campo el Owner Name de la zona, idéntico a como aparece en el SOA, para indicar que se ha llegado al final de la enumeración de los nombres de la zona. En el campo de tipos de registros se incluyen todos los RRTYPE que estén relacionados directamente con el nombre de dominio del campo del siguiente dominio. En este campo se incluyen los RRTYPE en forma de bloques que contienen los 8 bits menos significativos de los 16 bits que componen un espacio de RRTYPE, tal como se representan los demás RR. Los RRTYPE se ordenan de forma ascendente de acuerdo al valor numérico del octeto que representa a cada RRTYPE [4]. 26.

(36) En el cuadro 2.7 se observa un registro NSEC donde se puede notar que el campo del siguiente dominio válido es el nombre de dominio c.test. y que corresponde a registros de tipo A, RRSIG y el propio NSEC. Se observa que como el Owner Name incluye el nombre de dominio a.test., que es el predecesor directo al nombre de dominio solicitado por el usuario y que se le devuelve para comprobarle que no existe ningún registro entre a.test. y c.test.. Es decir, si un usuario preguntara por el dominio b.test., este RR será devuelto. a.test.. 3600. IN. NSEC. c.test.. A. RRSIG. NSEC. Cuadro 2.7: Ejemplo de RR de tipo NSEC. 2.2.6.. Registro DS. El registro DS esta relacionado directamente con un registro DNSKEY al participar en conjunto con este tipo de registro en el proceso de autenticación. Dentro del registro DS se almacena un identificador de llave, el número de algoritmo matemático utilizado y un resumen de la llave contenida en el registro DNSKEY al que se hace referencia. Al autenticar un registro DS, el resolver puede autenticar también el registro DNSKEY al que el registro DS se refiere [4]. El registro DS y su correspondiente registro DNSKEY comparten información referente al Owner Name, pero su colocación en la zonas del servidor varia. Este registro también es independiente del valor de clase que se le asigne y no tiene requisitos especiales para un valor especı́fico de TTL [4]. La sección de RDATA para el registro DS contiene el campo del identificador de la llave (2 octetos), el campo donde va colocado un identificador numérico del algoritmo matemático (1 octeto), el campo que identifica el tipo de resumen que se incluye (1 octeto) y el campo de resumen de longitud variable [4]. Los campos se describen a continuación [4]: El campo de identificador de llave (Key Tag) contiene el identificador de la llave del registro DNSKEY referido por el registro DS. Dicho valor de identificador está en el mismo formato que el campo del identificador de llave contenido en el registro RRSIG. Al igual que en los RR anteriormente presentados, el campo del algoritmo contiene un número que identifica al algoritmo matemático utilizado para generar el registro DNSKEY. El campo de tipo de resumen, se indica el número del algoritmo matemático utilizado para obtener el resumen de la llave que se incluye en el campo siguiente. 27.