Miguel Morillo Iruela DNSSEC.

Transcripción

1

2 Contenido 1. - Introducción Alcance del documento Audiencia Estructura del documento Sistema de nombres de dominio DNS Historia El propósito de DNS El Sistema de Nombres de Dominio (DNS) Como funciona el servicio de DNS Infraestructura DNS Componentes DNS y objetivos de seguridad Datos y software DNS Fichero de Zona Servidores de nombres Resolvedores Transacciones DNS Consultas y respuestas DNS Transferencias de Zona Actualizaciones dinámicas Notificaciones - DNS NOTIFY Por que el sistema de nombre de dominio es inseguro? Introducción Cambiando la petición de dirección Secuestrando un dominio: El ataque Kaminsky Parcheando el sistema frente al ataque Kaminsky Ejemplo practico: falseando la Aplicación de Automatrícula de la UCLM Como puede resolver el problema Definición Seguridad basada en cifrado Cadenas de confianza Confianzas Islas de confianza Look-aside Validation Resource Records (RR) DNSKEY RRSIG NSEC DS Implementando Linea de tiempo Estrategia para el despliegue de en una organización Recomendaciones de implementación Roles y responsabilidades Registro DS y claves KSK/ZSK Parámetros de Ejemplo de implementación...29

3 Instalación y configuración Firmando una zona principal Firmando una zona secundaria Alternativas Parcheando TSIG y SIG(0) DNScurve IPsec SSL/TLS Conclusiones proporciona confianza en las respuestas de DNS No hay alternativa a largo plazo La gestión de es diferente a la gestión de DNS Es necesario hacerlo Documentación y referencias...50 November 2010 Copyright. Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported License; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

4 Usted es libre de: copiar, distribuir y comunicar públicamente la obra hacer obras derivadas Bajo las condiciones siguientes: Reconocimiento Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra). Compartir bajo la misma licencia Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Entendiendo que: Renuncia Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor Dominio Público Cuando la obra o alguno de sus elementos se halle en el dominio público según la ley vigente aplicable, esta situación no quedará afectada por la licencia. Otros derechos Los derechos siguientes no quedan afectados por la licencia de ninguna manera: Los derechos derivados de usos legítimos u otras limitaciones reconocidas por ley no se ven afectados por lo anterior. Los derechos morales del auto; Derechos que pueden ostentar otras personas sobre la propia obra o su uso, como por ejemplo derechos de imagen o de privacidad. Aviso Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra.

5 Página dejada intencionalmente en blanco

6 1. Introducción 1.1. Alcance del documento El siguiente documento pretende ofrecer una visión global sobre la actual implementación de y las implicaciones que tendrían en una organización si es aplicado en el actual sistema de nombres de dominio, completándolo con unas primeras ideas y normas sobre la implementación de (DNS/). En primer lugar se detalla una visión del funcionamiento y por tanto entendimiento de las debilidades del servicio de nombres de dominio, a continuación se ofrece una descripción de las nuevas funcionalidades que nos ofrece para asegurar la autenticidad de las respuestas DNS. En el momento de escribir este documento la zona raíz gestionada por IANA acaba de hacer publico que desde Julio de 2010 ya tiene implementado para la zona raíz, con lo que es resto de dominios y subdominios tendrán que realizar esta actualización en sus sistemas si no quieren quedarse fuera de esta cadena de confianza que habilita las extensiones de seguridad para el protocolo DNS y que hacen a este protocolo mas seguro ya que es esencial en el desarrollo de Internet y sus servicios asociados. El NIST Computer Security Research Center acaba de hacer públicos también una serie de recomendaciones acerca de los parámetros, procedimientos, políticas y configuraciones mínimas para implementar en la zona raíz, y que desde mi punto de vista deben ser seguidas por todos los organismos y registradores de dominios que deseen implementar en sus sistemas. Además de estas recomendaciones de seguridad marcadas por el NIST existen otras lecturas recomendadas acerca de la implementación de, como por ejemplo la guía de diseño técnico de la arquitectura de publicado por el equipo que ha diseñado esta extensión de seguridad que recoge como se deben gestionar las firmas de las zonas y la gestión de las claves utilizadas, también se recomienda seguir las especificaciones con mecanismos de seguridad asociados: Internet Engineering Task Force (IETF) Domain Name System Security Extensions (), (RFC) 4033, 4034, 4035, 3833 y 1. IETF especificaciones de transacciones de Firma (TSIG), cubiertos por RFC 2845 y ISO 27001, ISO 27002:2005, (NIST) SP En reconocimiento de la urgente necesidad de una mayor seguridad para el actual sistema de nombres de dominio de Internet y el sistema de direcciones, las entidades que gestionan el sistema de nombres desean seguir adelante con la implementación de tanto en la zona raíz como en el resto de dominios. Desde el 15 de Julio de 2010 a las 2050 UTC, entró en producción la primera zona firmada con el serial SOA Para facilitar un despliegue rápido de la manera mas segura, es necesario coordinar el proceso de implementación en el proceso de gestión de la zona raíz existente y el resto de zonas secundarias, reduciendo al mínimo la introducción de nuevas medidas y cambios de responsabilidades entre las partes involucradas. En la zona raíz el ciclo de vida de seguridad sera gestionado como se describe en la norma ISO 27001, y cualquier política de seguridad para la implementación debe ser validada con los estándares existentes para los controles de seguridad de dicha norma. Para el resto de dominios y subdominios se recomienda también implementar mecanismos de seguridad y gestión según la norma ISO

7 1.2. Audiencia Este documento ha sido creado para poder ofrecer una visión global de la tecnología empleada en la securización del sistema de nombre de dominio por lo que esta enfocado tanto al ámbito académico, como profesional, especialmente a administradores y responsables de sistemas encargados de administrar y gestionar el servicio de DNS Estructura del documento Sección 1: Introducción. Sección 2: DNS, Historia, propósito, arquitectura y funcionamiento de DNS. Sección 3: Los problemas de DNS, cuestiones sobre la falta de seguridad en la implementación actual del sistema DNS. Sección 4:, definición, arquitectura y definición de nuevas funcionalidades añadidas a DNS. Sección 5: Implementación de, indicaciones y ejemplos de una posible implementación de. Sección 6: Alternativas, posibles alternativas, procedimientos o tecnologías compartidas con para aumentar la seguridad de las transacciones DNS. Sección 7: Conclusiones. Sección 8: Referencias.

8 2. Sistema de nombres de dominio DNS 2.1. Historia Cuando Internet fue creado cada nodo de la red necesitaba tener su propia dirección, por ese motivo se definió la dirección IP. Quienes comenzaron a trabajar en Internet pronto se encontraron con el problema de una falta de estructura lógica entre los sistemas informáticos con las direcciones IP y se opto por una solución simple: crear un archivo que asigne una dirección IP a un nombre lógico. Este archivo se llama 'hosts' archivo que contenía una lista de hosts conectados a la red. Un ejemplo de un archivo hosts se muestra en siguiente tabla: webmail.alu.uclm.es campusvirtual.uclm.es El fichero de hosts era mantenido y administrado por los administradores de sistemas de los equipos que en ese momento estaban conectados entre si en una incipiente Internet, pero cuando Internet comenzó a crecer, esta solución no era escalable ni adecuada para conectar miles de nuevos usuarios a través de la red. Como solución se opto por estandarizar un servicio de nombres de dominio en lo que hoy conocemos como DNS (Domain Name System) El propósito de DNS Internet es la red más grande del mundo, desde la perspectiva de un usuario, cada nodo o recurso en la red se identifica por un nombre único: el nombre de dominio. Para alcanzar un ordenador o cualquier otro recurso de una red, es necesaria alguna forma de indicar el destino, esto se consigue asignando direcciones de red. La dirección de red debe de ser única para poder encaminar correctamente los paquetes de un host o router a otro. Esta dirección esta formada por un identificador numérico el cual los routers o cualquier dispositivo de red pueda entender y procesar. Desde la perspectiva de los dispositivos de red (por ejemplo, routers) que solo encaminan paquetes a través de Internet, son solo transacciones de paquetes. Pero desde la perspectiva del usuario para acceder a los recursos de Internet se utilizan los nombres de dominio, los usuarios necesitan un sistema que traduzca los nombres de dominio a direcciones IP y viceversa. Esta traducción es la tarea principal del Domain Name System (DNS). La dirección numérica se denomina IP (IPv4), la cual se pueden expresar como números de notación decimal: se dividen los 32 bits de la dirección en cuatro octetos. El valor decimal de cada octeto puede ser entre 0 y 255 [el número binario de 8 bits más alto es y esos bits, de derecha a izquierda, tienen valores decimales de 1, 2, 4, 8, 16, 32, 64 y 128, lo que suma 256 en total, 255 más la 0 ( )]. En la expresión de direcciones IPv4 en decimal se separa cada octeto por un carácter único ".". Cada uno de estos octetos puede estar comprendido entre 0 y 255, salvo algunas excepciones. Los ceros iniciales, si los hubiera, se pueden obviar ( sería ). Esta dirección es difícil de recordar y además no tiene una estructura organizativa lógica, con lo que

9 recordar de manera global estas direcciones para comunicarnos con otros hosts o elementos de red es complicado. Por esta razón es necesario crear una relación entre nombres de domino y direcciones IP, para poder crear esta relación se hizo necesario crear un sistema de traducción llamado DNS (Domain Name System). DNS traduce los nombres lógico como a dirección IP Los usuarios acceden a un recurso de Internet (por ejemplo, un servidor Web) a través del cliente correspondiente, o programa de usuario (por ejemplo, un navegador web), y escribe el nombre de dominio. Para contactar con el servidor Web y visualizar la página Web, el navegador necesita la dirección IP correspondiente. Entonces se llama al DNS para proporcionar esta información, esta función de asignación de nombres de dominio a direcciones IP se denomina resolución de nombres. En primer lugar, el DNS debe tener un repositorio de datos para almacenar los nombres de dominio y sus correspondientes direcciones IP. Dado que el número de nombres de dominio es grande, para conseguir un mayor rendimiento, su almacenamiento debe ser distribuido. Los nombres de dominio pueden incluso ser replicados para ofrecer tolerancia a fallos. En segundo lugar, debe haber un software que gestione este repositorio y proporcione la función de resolución de nombres. Estas dos funciones (la gestión de los nombres de dominio de un repositorio y la prestación del servicio de resolución de nombres) son proporcionados por el el servidor de nombres. Para acceder a los servicios prestados por un servidor de nombres DNS por los programas de usuario, hay otro componente de DNS llamado resolución. Hay dos categorías principales de resolvedores (resolverdor caché/recursivo de nombres y resolvedor sin almacenamiento en caché). El protocolo de comunicación, los distintos componentes de DNS, las políticas que rigen la configuración de estos componentes y procedimientos para la creación, almacenamiento y uso de nombres de dominio constituyen la infraestructura DNS El Sistema de Nombres de Dominio (DNS) En respuesta a la rápida expansión de Internet, incrementando cada día el numero de direcciones IP del espectro normalizado, se introdujo el servicio de nombres de dominio DNS en 1983 para poder gestionar de manera eficiente el direccionamiento. El sistema de nombres de dominio es un sistema jerarquizado, es decir, existe un dominio raíz (representado por un solo punto "."), un conjunto de dominios de primer nivel, como.com o.es, y cualquier número de niveles debajo de estos dominios. La siguiente imagen muestra un ejemplo de la jerarquía de nombres de dominio.

10 La zona de la parte superior de la jerarquía (el dominio ".") se llama la zona root o zona raiz. Las entradas de esta zona son los dominios de nivel superior (Top Level Domains, TLDs). Existen dominios de primer nivel como.com para empresas,.edu para instituciones educativas y dominios genéricos de nivel superior formado por el código de país. El Domain Name System (DNS) es una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio. DNS convierte nombres de máquina a las direcciones IP que tienen todas las máquinas de la red y traduce o relaciona nombres con direcciones y direcciones con nombres Como funciona el servicio de DNS Cuando una aplicación (cliente) necesita resolver un FQDN (Fully Qualified Domain Name) envía una petición al servidor de nombres configurado en el sistema. A partir de entonces se desencadena el proceso de resolución del nombre: 1. El servidor de nombres inicial si no lo reconoce en su propia biblioteca de nombres de dominios, consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente). 2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona. 3. El servidor inicial interroga al nuevo servidor. 4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada. 5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo consulta. 6. El servidor resuelve el nombre correspondiente, si este existe. 7. El servidor inicial informa al cliente el nombre resuelto. Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre 1. El sistema tiene configurado el servidor de nombres Y envía la consulta del dominio 2. El servidor de envía la consulta root server le informa que el servidor con autoridad sobre es. 4..es responde que la autoridad sobre uclm.es la tiene envía ahora la consulta a informa que la dirección IP de es Finalmente, devuelve este resultado a la aplicación que originó la consulta. Mecanismos de caché Cada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de validez de la misma (TTL o tiempo de vida ). Esto posibilita que el receptor, antes la necesidad de volver a resolver la misma consulta, pueda utilizar la información previamente obtenida en vez de realizar un nuevo requerimiento.

11 Esta es la razón por la cual los cambios realizados en el DNS no se propagan instantáneamente a través del sistema. Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la propagación puede tardar desde algunos minutos hasta varios días Infraestructura DNS La infraestructura de DNS está formada por entidades de procesamiento y comunicación que se encuentran distribuidas. Para entender esta infraestructura de DNS, es necesario primero examinar la estructura de la organización. El espacio de nombres de dominio (el universo de todos los nombres de dominio) es organizada de forma jerarquía. El nivel más alto en la jerarquía es el dominio raíz, que se representa como un punto (".") y el siguiente nivel en la jerarquía se llama dominio de nivel superior (TLD). Sólo hay un dominio de raíz, pero hay muchos TLDs y cada TLD se llama dominio secundario del dominio raíz. En este contexto, el dominio raíz es el dominio principal, ya que está un nivel por encima de un TLD y cada TLD, a su vez, pueden tener muchos dominios hijos. Los hijos de los dominios de nivel superior se llaman de segundo nivel. En una representación de nombres de dominio, el símbolo del dominio de raíz por lo general se omite. Por ejemplo, considere el nombre de dominio La etiqueta más a la derecha en este nombre de dominio (".es") es un TLD. La siguiente etiqueta a la izquierda ("uclm ) es el segundo nivel o de dominio de nivel empresarial. La etiqueta de la izquierda ("www") es el dominio de tercer nivel. También es posible tener un dominio de cuarto nivel, dominio de quinto nivel, y así sucesivamente. Debido a que cada una de las etiquetas en se llama un dominio (TLD, de dominio de segundo nivel, de dominio de tercer nivel, etc), la concatenación de todos estos TLD s es un dominio de nombre completo (FQDN). Sólo hay una raíz de dominio, pero hay más de 250 dominios de nivel superior, clasificados en los siguientes tres tipos: TLD de código de país (cctld): dominios asociados con países y territorios. Hay más de 240 cctld. Ej: es, uk, en, y jp. Dominios de nivel superior genéricos de organismos (gtld): dominios especializados que representan una comunidad de intereses, detrás existe una organización u organismo publico. Ej: edu, gov, int, mil, aero, museum. Dominios de nivel superior genéricos (gtld): dominios sin una organización detrás. La lista de gtld incluye. com, net, org, biz, info. Cada servidor de nombres contiene información acerca de una porción del espacio de nombres de dominio. Hay 13 servidores de nombres asociados con el nivel de la raíz, dos de los servidores raíz son actualmente dirigidos por los EE.UU. (VeriSign), el resto son operados por organizaciones de todo el mundo como un servicio a la comunidad de Internet. Las organizaciones que ejecutan los servidores de nombres asociados con un TLD se llaman registros. En general, los cctld están a cargo de registros designados en los respectivos países, y gtld están a cargo de los registros mundiales. La gestión de la infraestructura DNS se realiza a través de la colaboración de diversas entidades (organizaciones que gestionan los servidores raíz, los registros de dominios de nivel superior, etc) mediante una corporación sin animo de lucro, Internet Corporation for Assigned Names and Numbers (ICANN). Por ejemplo, ICANN formula las políticas para la gestión de los servidores raíz. ICANN fue creada en 1998 por el Departamento de Comercio de EE.UU.. Para facilitar la agrupación, DNS define el concepto de zona, una zona puede ser todo un dominio o un dominio con uno o más subdominios. Una zona es una entidad configurable dentro de un servidor de nombres con el que se describe la información sobre todos los recursos relacionados con un dominio y un conjunto seleccionado de subdominios. Por tanto, las zonas son bloques administrativos del espacio de nombres DNS, en otras palabras, la zona es el recurso configurable

12 dentro de una instalación de servidor de nombres desplegado que contiene la información del nombre de dominio. Con este conocimiento global de la infraestructura de DNS, nombres de dominio, zonas, servidores de nombres de varios niveles (es decir, los servidores raíz y servidores TLD), y los resolvedores, la función de resolución de nombres se puede definir con más detalle. Ej: Cuando un usuario escribe la URL en un navegador web, el host se comunica con un servidor de nombres local (llamado servidor de nombres recursivo o resolución de servidor de nombres). El servidor de nombres resolvente comprobará su caché para determinar si tiene información válida para proporcionar la dirección IP. Si no, el servidor de nombres utiliza la resolución de caché para determinar si tiene la información sobre el servidor de nombres para la zona y si la dirección IP del servidor de nombres de no está disponible en la caché, la resolución determina si tiene la información del servidor de nombres para una zona que es un nivel más alto que (es decir, uclm.es). Si la información del servidor de nombres para uclm.es no está disponible, la siguiente búsqueda será para el servidor de nombres de la zona.es. Todo este proceso se realiza primero en la cache de los diferentes servidores de DNS. Si la búsqueda completa en la caché no da la información requerida, el servidor de nombres no tiene más remedio que iniciar su búsqueda y consultar al servidor de nombres de la zona superior en la jerarquía del espacio de nombres DNS (es decir, el servidor raíz) Componentes DNS y objetivos de seguridad A la hora de planificar la securización del servicio de DNS debemos tener en cuenta la securización de todos los componentes que lo componen, DNS incluye las siguientes entidades que deben de ser securizadas:

13 Plataforma (hardware y sistema operativo) en el que el servidor de nombres y resolvedores residen. El nombre del servidor y el software de resolución. Transacciones DNS. Archivos de zona. Los archivos de configuración en el servidor de nombres y resolución. Confidencialidad, integridad, disponibilidad, y autenticación son los objetivos de seguridad que son comunes a cualquier sistema electrónico. Sin embargo, de DNS se espera que proporcione la información de resolución de nombres para cualquier recurso de Internet a disposición del público. A excepción de los datos DNS correspondientes a los recursos internos (por ejemplo, los servidores dentro de un servidor de seguridad) que es proporcionada por los servidores internos de nombre DNS a través de canales seguros, los datos DNS proporcionados por los servidores públicos de nombres DNS no se considera confidencial. Por lo tanto, la confidencialidad no es uno de los objetivos de seguridad de DNS. Velar por la autenticidad de la información y el mantenimiento de la integridad de la información en tránsito es fundamental para el funcionamiento eficiente de la red. En consecuencia, la integridad y la autenticación de la fuente son los principales objetivos de seguridad de DNS, aunque mediante la aplicación de tecnologías que aseguren tanto los datos como las transacciones de los servidores DNS los objetivo de garantizar confidencialidad, integridad, disponibilidad, y autenticación pueden ser logrados. Debido a la diversidad de plataformas de servidores de nombres y redes en las que los componentes de DNS residen (como el software de nombre de servidor y software de resolución), no es factible evitar todo tipo de ataques de denegación de servicio. Algunas pautas de referencia deben ser observadas para evitar ataques de denegación de servicio que exploten las vulnerabilidades de la plataforma, el contenido del archivo de zona de datos y la configuración del control de acceso para determinadas transacciones DNS. Como hemos indicado anteriormente se deberían planificar protocolos y procedimientos que desarrollen políticas de seguridad, listas de comprobación para los siguientes componentes de DNS y operaciones asociadas a: Entorno de hosting DNS. Plataforma (SO, sistema de ficheros, pila de comunicaciones, etc...) Software DNS (servidor de nombres, etc...) Datos DNS (fichero de zona, fichero de configuración) Transacciones DNS Consultas/respuestas DNS Transferencias de zona Actualizaciones dinámicas Notificaciones DNS Administración de la seguridad Elección de algoritmos y tamaños de claves(tsig y )

14 Gestión de las claves (generación, almacenamiento y uso) Publicación de la clave publica Backups de las claves (periódico y de emergencia). Datos y software DNS 2.7. Los dos componentes principales del software de DNS son el servidor de nombres y el servidor de resolución. Las principales funciones del servidor de nombres son albergar la base de datos (archivo de zona), que contiene la información de dominio y dar respuesta a las consultas de resolución de nombre. La función principal del software de resolución es la formulación de una consulta de resolución de nombres o una serie de consultas. Los datos primarios de DNS es el archivo de zona Fichero de Zona El archivo de zona contiene información acerca de los diversos recursos en esa zona. La información sobre cada recurso está representada en una entrada que llama a un registro de recursos (RR) y debido a que una zona puede contener varios dominios y varios tipos de recursos dentro de cada dominio, el formato de cada RR contiene campos para realizar esta identificación. En concreto, el RR se compone de los siguientes campos principales: Nombre propio: el nombre de dominio o nombre del recurso. TTL: time to live en segundos. Class: En este momento solo es usada una clase,. RRType: Tipo de recurso. RData: Información sobre el recurso. Algunos de los tipos RRTypes son: A = Address (Dirección) Este registro se usa para traducir nombres de hosts a direcciones IP. Proporciona la IP para un nombre de host (FQDN). CNAME = Canonical Name (Nombre Canónico) Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio. Es usado cuando se están corriendo múltiples servicios (como ftp y web server) en un servidor con una sola dirección IP. Cada servicio tiene su propia entrada de DNS (como ftp.uclm.net y NS = Name Server (Servidor de Nombres) Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres. MX (registro) = Mail Exchange (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. PTR = Pointer (Indicador) También conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. SOA = Start of authority (Autoridad de la zona) Proporciona información sobre la zona. HFO = Host FOrmation (Información del sistema informático) Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un

15 dominio. TXT = TeXT - ( Información textual) Permite a los dominios identificarse de modos arbitrarios. LOC = LOCalización - Permite indicar las coordenadas del dominio. WKS - Generalización del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV. SRV = SeRVicios - Permite indicar los servicios que ofrece el dominio. RFC 2782 SPF = Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts están autorizados a enviar correo desde el dominio dado. El servidor que recibe consulta el SPF para comparar la IP desde la cual le llega, con los datos de este registro. IETF RFC 1035 proporciona el formato completo de los tipos RRTypes Servidores de nombres Hay dos principales tipos de servidores de nombres: los servidores de nombre de autoridad y los servidores de almacenamiento en caché. El término autoridad es con respecto a una zona. Si un servidor de nombres es una fuente autorizada de los RR para una determinada zona (o zonas), se llama un servidor de nombres con autoridad para esa zona (o zonas) y ofrece respuestas a las consultas de nombres utilizando el RR en su archivo de zona propia. Un servidor de nombres caché (también llamado resolvedor/servidor de nombres recursivo), por el contrario, proporciona respuestas a través de una serie de consultas a los servidores de nombres con autoridad en la jerarquía de dominios que se encuentran en la consulta de resolución de nombres o de una caché construida de las respuestas a consultas anteriores Servidores de Nombres autorizados Hay dos tipos de servidores de nombres autorizados: maestro (o principal) del servidor de nombres y el esclavo (o secundario). Para mejorar la tolerancia a fallos, puede haber varios servidores de nombres esclavos. Un servidor de nombres principal contiene los archivos de zona que se crean y editan manualmente por el administrador de la zona. A veces un servidor de nombres maestro permite que se actualice dinámicamente por los clientes DNS autorizados el archivo de zona. Un servidor de nombres maestro que está configurado con esta función por lo general se llama servidor maestro de nombres primario. Un esclavo (secundario) del servidor de nombres también contiene información fidedigna para una zona, pero su archivo de zona es una réplica de la del servidor maestro asociado. La replicación está habilitada a través de una transacción de transferencia de zona que transfiere todos los RR del archivo de zona de un servidor de nombres maestro hacia el servidor de nombres esclavo, una transferencia de zona en realidad se trata como una categoría de consulta de resolución de nombres con AXFR. Cada vez que el contenido de un archivo de zona se cambia en los servidores maestros, los servidores de nombres esclavos son notificados del cambio a través de una operación llamada notificación DNS (DNS NOTIFY). Cuando un servidor de nombres esclavo recibe esta solicitud, se inicia una solicitud de transferencia de zona para el servidor de nombres maestro Servidor de Nombres de cache Un servidor de nombres de caché en general, es el servidor de nombre local que realiza la función de resolución de nombres. Un servidor de nombres caché también se le llama resolvedor / servidor de nombres recursivo. La función de la resolución de nombres se realiza mediante un servidor de nombres de caché en respuesta a las consultas recibidas. El proceso de búsqueda en la resolución

16 de nombres puede implicar la búsqueda en su propia caché, de forma recursiva consulta varios servidores de nombres autorizados a través de una serie de consultas iterativas, o una combinación de estos. Un servidor de nombres específicos puede ser configurado para ser a la vez una autoridad y un servidor de nombres recursivo. En esta configuración, el servidor de nombres mismo proporciona información autorizada para las consultas relativas a las zonas de autoridad, mientras que realiza las funciones de resolvedor de las consultas relativas a otras zonas. Para llevar a cabo la función de resolvedor, se tiene que apoyar en consultas recursivas. Cualquier servidor que soporte consultas recursivas es más vulnerable al ataque que un servidor que no admite este tipo de consultas. Como resultado, la información autorizada pueda verse comprometida. Por lo tanto, no es una buena práctica de seguridad configurar un servidor de nombres único para ambas funciones, autoridad y recursiva Resolvedores Software, como navegadores web y clientes de correo electrónico que requieren acceso a recursos de Internet hacen uso de clientes DNS, los cuales realizan llamadas para resolver un dominio especifico. La resolución formula una consulta de nombres para el recurso solicitado por el software y la envía a un almacenamiento en caché (resolución) del servidor de nombres. El resolvedor generalmente se configura con una lista de dos o más servidores de resolución de nombres para proporcionar alguna tolerancia a fallos en su funcionamiento y el almacenamiento en caché (resolución) del servidor de nombres que recibe una consulta de una resolución también formula consultas para enviarlos a servidores de nombres autorizados (si no es capaz de responder a la consulta de su caché). Transacciones DNS Consultas y respuestas DNS Esta es la operación más común en el DNS. Una consulta DNS se origina en una resolución, el destino es un servidor de nombres con autoridad o el almacenamiento en caché. La consulta más común es la búsqueda de un RR en base al nombre del propietario o RRType. La respuesta puede consistir en un solo RR, un RRSet, o un mensaje de error apropiado. Hay dos tipos de consultas: iterativos y recursivos. Resolvedores DNS que envían consultas iterativas tienden a ser más robustos en lo que respecta a los tipos de respuestas que ofrecen, ya que pueden tener que seguir referencias múltiples para obtener la respuesta final a una consulta determinada. Las consultas DNS se envían en un solo paquete UDP, la respuesta generalmente es un solo paquete UDP también, pero el tamaño de los datos puede dar lugar a truncamiento, en cuyo caso el procedimiento normal es volver a emitir la consulta a través de TCP. UDP es preferido debido a que requiere menos recursos. Las consultas DNS se envían en claro, se supone que la respuesta recibida es correcta y recibida de una fuente auténtica, por lo que es posible que un atacante pueda interceptar (y modificar) o falsificar las respuestas a una consulta de un cliente Transferencias de Zona Una transferencia de zona se refiere a la forma en que un servidor esclavo (secundario) actualiza todo el contenido de su archivo de zona desde los servidores maestros (primarios). Este proceso permite a un servidor de nombres secundario mantener su archivo de zona en sintonía con su servidor de nombres primario. Una transacción de transferencia de zona se inicia como una consulta de un servidor de nombres secundario a un servidor de nombres primario. Una consulta de transferencia de zona en contraste con una solicitud de consulta DNS es que se consultan todos los

17 registros de una zona en lugar de solicitar un RR de un nombre dado o RRType. Una consulta de transferencia de zona se origina en un servidor de nombres secundario, ya sea en respuesta a un mensaje de notificación DNS o sobre la base del valor del elemento de datos de actualización en el campo RDATA de las zonas de autoridad (SOA) RR. Un proceso de transferencia de zona tiene diferentes implicaciones de seguridad, ya que revela mucha mas información que una consulta DNS normal Actualizaciones dinámicas Normalmente los administradores de DNS realizan cambios de forma manual, cuando estos cambios se hacen grandes en volumen y más frecuentes se introduce el concepto de actualizaciones dinámicas. Aparte del volumen y la frecuencia, hay algunas aplicaciones que requieren información inmediata, por lo tanto son necesarias las actualizaciones automáticas del archivo de zona DNS a través de programas de aplicación. Ejemplos de estas aplicaciones: Entidad emisora de certificados (CA), servidores DHCP, etc... RFC 2136 recoge la hoja de ruta para el mecanismo de actualización dinámica, que posteriormente fue implementada en la versión 8 de BD y ha continuado en todas las versiones posteriores desde entonces. La instalación de actualización dinámica proporciona operaciones de inserción y eliminación de RR en el archivo de zona Notificaciones - DNS NOTIFY Siempre que se producen cambios en el archivo de zona del primario (maestro) del servidor DNS, en el secundario (esclavo) se supone que se tienen los mismos datos que en el servidor DNS principal, para ello se deben notificar los cambios. Esta notificación se lleva a cabo a través del mensaje de notificación DNS, lo que le indica a un servidor DNS secundario iniciar una transferencia de zona. El mensaje de notificación DNS es una forma mucho más eficaz y más rápida de mantener servidores secundarios en sincronía con el servidor principal. Una vez que un servidor secundario recibe un mensaje de notificación DNS, provoca un intento de transferencia de zona. Como en cualquier actualización de zona, si el número de serie de la zona en el RR SOA no ha aumentado, la transferencia de zona no se produce. Este procedimiento permite que los cambios realizados en la zona se propaguen a todos los servidores de nombres con mayor rapidez y eficacia. El envío de mensajes de notificación DNS falsos provocaran una transferencia de zona DNS falsa, lo que podría dar lugar a transferencias de zona innecesarias y por lo tanto una posible denegación de servicio.

18 3. Por que el sistema de nombre de dominio es inseguro? 3.1. Introducción El DNS fue diseñado durante los primeros años de Internet y durante esta época todos los usuarios pertenecían el sector académico, organizaciones militares y entusiastas de la informática, en los cuales, en general, se podía confiar. Todo aquello implicó que la seguridad no fuese uno de los principales objetivos de diseño del sistema de nombres de dominio. Como consecuencia, existen vulnerabilidades en el sistema (algunas de los cuales son incluso errores de diseño). La más importante vulnerabilidad se debe a que los servidores de nombres realizan consultas entre sí, sin un método seguro de verificación de los resultados obtenidos. Esto permite un tipo de ataque llamado envenenamiento de caché Cambiando la petición de dirección Como ya se describió anteriormente, es una práctica común para los clientes a hacer uso de un servidor de almacenamiento en caché de nombres de dominio, que hace todo el trabajo de resolver ya que mantiene las respuestas en un sistema de cache para que puedan ser reutilizados por otros clientes. Este servidor DNS está en contacto con los clientes que están realizando consultas de manera frecuente, por lo que su caché es una herramienta ideal para reducir los accesos y peticiones a los servidores DNS principales, con lo que los clientes obtienen sus resultados más rápidamente, y los servidores DNS tienen menos carga de trabajo. Pero imagina que fuese posible engañar al servidor de almacenamiento falsificando esa caché de nombres de dominio haciéndole al servidor aceptar una respuesta incorrecta, esta respuesta incorrecta, podría terminar en su caché y la serviría a todos los clientes que soliciten la misma dirección hasta que el tiempo de vida (TTL) de la respuesta incorrecta se agote. Como resultado, los usuarios podrían ser enviados a una dirección equivocada, a un sitio web con malware, sus s pueden ser enviados a la dirección equivocada y hasta sus llamadas telefónicas pueden ser interceptadas, y si se hace correctamente, lo peor es que los usuarios no pueden percibir la diferencia entre la dirección correcta o incorrecta. Esta posible infección de la cache es posible en los actuales sistemas de nombres de dominio, cuando una resolución de un nombre de dominio envía una solicitud, es posible que un atacante envíe una respuesta errónea a dicha resolución. Si el atacante ofrece una respuesta aceptable con la suficiente rapidez, la resolución va a aceptar la respuesta. Ahora bien, este ataque sólo es posible si el atacante intercepta la solicitud original o genera la solicitud él mismo y solo tendrá éxito en ofrecer la respuesta falsa en la resolución si la envía antes de que lo realice el servidor autorizado.

19 3.3. Secuestrando un dominio: El ataque Kaminsky El secuestro o falsificación de un dominio se conoce como el ataque Kaminsky. La vulnerabilidad descubierta por Dan Kaminsky da una vuelta de tuerca más al procedimiento anterior creando una respuesta fraudulenta que nos permite secuestrar el Authoritative nameserver y por tanto todo el dominio, no solo una entrada en la cache del servidor. El primer paso consiste en configurar un servidor de DNS de realice las funciones de Authoritative nameserver del dominio a secuestrar, obviamente en este DNS fraudulento tendremos configurados todos los registros (RR) de forma que se resuelvan a direcciones IP incorrectas deseadas que contienen webs o servicios que queremos secuestrar. En los puntos anteriores se explicó el proceso de resolución de nombres de dominio. En este proceso, los servidores de nombres pueden responder a un cliente que no saben la respuesta con lo que envían al cliente a realizar la consulta a otro servidor. La información que es proporcionada por el servidor de nombres es la información llamada "autoridad". El servidor de nombres indica "No estoy autorizado para el dominio que estás buscando, pero este es otro servidor que si esta autorizado", a continuación, indica el nombre y la dirección de este servidor de nombres autorizado como parte de la respuesta a la consulta. La respuesta a cada consulta consta de tres partes: La respuesta a la consulta (puede estar en blanco si la consulta no puede ser respondida). Autoridad de la información (que está autorizada para el dominio que se consulta). Información adicional (la información de la dirección de los servidores autorizados). Es fácil ver cómo esto puede ser objeto de abuso: el atacante puede intentar responder antes de que el servidor pueda responder a los clientes que enviaron la solicitud. Si el atacante tiene éxito, se pueden suministrar servidores falsos, a todas las solicitudes que recibe (es decir, sustituye la "información adicional" de la respuesta con información falsa sobre su servidor). Acerca de este ataque indicamos tres características importantes: El atacante puede llevar a cabo este ataque en cualquier momento. El atacante se limita a realizar consultas, al servidor de almacenamiento de caché del servidor de nombres que quiere falsear con nombres de host (inexistentes) en la memoria caché. El servidor de nombres atacado al no tener estos nombres en memoria cache enviará esta solicitud de

20 resolución, dando al atacante la oportunidad de insertar sus propias respuestas incorrectas que luego serán almacenadas automáticamente en la memoria caché. Este ataque secuestra o falsea todo un dominio en vez de un nombre de host solamente. Además el atacante normalmente establecerá en la respuesta falsa un tiempo de vida largo, para asegurarse de que permanece en la memoria caché durante mucho tiempo. Una vez que todo el dominio ha sido secuestrado todo el tráfico puede ser redireccionado, paginas web, servicios, correo electrónico, etc... Este ataque no puede ser mitigado mediante la protección de su sitio web usando SSL (https) con lo que es trivial para un atacante redirigir a los usuarios a un sitio seguro SSL que puede parecer completamente válido desde el punto de vista del usuario Parcheando el sistema frente al ataque Kaminsky El ataque Kaminsky se dio a conocer sólo después de que un parche estuviese disponible para todas las implementaciones comunes o habituales de servidores de nombres y un gran número de servidores de nombres de caché hubieran ya parcheado. Esta es la primera medida a tomar para hacer frente a este ataque, sin embargo, no una solución que funcione a largo plazo, ya que se seguirán sufriendo nuevos ataques que pongan en peligro el diseño y funcionalidad de los servidores de nombres. Por qué la aplicación de parches no es la solución definitiva, se ilustra mejor con algunos números: Existen demostraciones en que los servidores sin parchear se pueden envenenar en 3 segundos. Además la investigación realizada por CZ.NIC, el registro de dominios de nivel superior para el dominio de la República Checa CZ. Ha demostrado que es posible envenenar a un servidor con todos los parches aplicados en un intervalo de entre una a once horas. Así que, aunque la aplicación de parches ayuda a retrasar un ataque, dando a los administradores una tiempo de advertencia en la que poder detectar el ataque. Y dado que el atacante tiene "todo el tiempo en el mundo" hay muchas maneras en las que un atacante puede ocultar el ataque, por ejemplo realizando pequeñas ráfagas desde diferentes hosts Ejemplo practico: falseando la Aplicación de Automatrícula de la UCLM El siguiente ejemplo describe como se podría realizar el ataque Kaminsky a una aplicación web con certificados SSL demostrando así que no es segura. La UCLM pone al servicio de los alumnos una aplicación web para la automatriculación, este servicio se ofrece a través de una web: que nos redirige a una web segura para autenticarnos: Suponemos que un atacante quiere falsear esta dirección donde los usuarios se autentican, para asi recoger datos de los alumnos como números de cuenta, números de teléfonos, etc... Usando el ataque Kaminsky seguiríamos los siguientes pasos: 1. El atacante en primer lugar realiza una copia lo mas próxima posible a la realidad de la web que quiere atacar, para no hacer sospechar a los usuarios. 2. A continuación registra un dominio parecido al atacado: sso.secure-uclm.es 3. Haciendo uso de las técnicas vistas en los puntos anteriores del ataque Kaminsky realiza un ataque para envenenar la cache del mayor proveedor de Internet, dirigiendo las consultas de sso.uclm.es al dominio registrado por el atacante.