Detección de tráfico anómalo en servidores autoritativos del DNS mediante sistemas de reglas y clasificadores bayesianos por Ing. Gustavo Lozano Ibarra Tesis Presentada al Programa de Graduados en Tecnologı́as de Información y Electrónica como requisito parcial para obtener el grado académico de Maestro en Ciencias especialidad en Sistemas Inteligentes Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey Diciembre de 2006 Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey División de Tecnologı́as de Información y Electrónica Programa de Graduados Los miembros del comité de tesis recomendamos que la presente tesis de Gustavo Lozano Ibarra sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias, especialidad en: Sistemas Inteligentes Comité de Tesis: Dr. Arturo Galván Rodrı́guez Asesor de la tesis Dr. Jorge Carlos Mex Perera Dr. José Raúl Pérez Cázares Sinodal Sinodal Dr. Graciano Dieck Assad Director del Programa de Graduados Diciembre de 2006 Detección de tráfico anómalo en servidores autoritativos del DNS mediante sistemas de reglas y clasificadores bayesianos Gustavo Lozano Ibarra, M.C. Instituto Tecnológico y de Estudios Superiores de Monterrey, 2006 Asesor de la tesis: Dr. Arturo Galván Rodrı́guez El sistema de nombres de dominio o DNS por sus siglas, es una tecnologı́a fundamental para el correcto funcionamiento de Internet. Gracias, a su diseño distribuido, el sistema de nombres de dominio ha logrado escalar a millones de nombres de dominio con un desempeño adecuado. Al ser una pieza fundamental en el funcionamiento de Internet, los servidores que proporcionan el servicio de DNS son blanco constante de ataques y abusos. Expertos en seguridad escudriñan entre miles de paquetes del DNS buscando nuevas vulnerabilidades, trabajo que podrı́a ser más eficiente con un clasificador computacional que permitiera al experto en seguridad enfocarse a los paquetes más sospechosos. Los clasificadores bayesianos han demostrado su efectividad en la lucha contra el correo electrónico no deseado y en la siguiente tesis se analiza la utilización de los mismos en la clasificación de paquetes del DNS. El prototipo del sistema de clasificación creado para comprobar si un clasificador bayesiano se puede utilizar en el problema de clasificar paquetes del DNS demostró tener grandes posibilidades de convertirse en una herramienta útil en la defensa de servidores del DNS. Índice general Resumen IV Capı́tulo 1. Introducción 1 Capı́tulo 2. Marco Teórico 4 2.1. Detección de intrusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Sistema de nombres de dominio . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.2. Descripción del DNS . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5. Redes Bayesianas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.5.1. Utilización de clasificadores bayesianos para catalogar correo no solicitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capı́tulo 3. Definición del Problema 32 35 Capı́tulo 4. Solución propuesta mediante clasificacı́ón bayesiana de paquetes de DNS 38 4.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2. Metodologı́a utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Variables utilizadas en la clasificación . . . . . . . . . . . . . . . . . . . 41 v 4.3.1. Dirección de IP de origen . . . . . . . . . . . . . . . . . . . . . 41 4.3.2. Cantidad de consultas desde la misma IP de origen . . . . . . . 42 4.3.3. Sección consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.4. RR type poco usados . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.5. Clases poco usadas . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.6. Tamaño del dominio . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.7. Tamaño total de la consulta . . . . . . . . . . . . . . . . . . . . 45 4.3.8. Cantidad de consultas repetidas desde la misma IP . . . . . . . 45 4.3.9. Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.10. Cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.11. Intento de realizar actualizaciones dinámicas . . . . . . . . . . . 47 4.3.12. Intento de realizar transferencias de zonas . . . . . . . . . . . . 48 4.3.13. Consultas sobre TLDs que no son .mx . . . . . . . . . . . . . . 48 4.3.14. Tamaño de consulta igual a cero . . . . . . . . . . . . . . . . . . 48 4.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Capı́tulo 5. Cosas aprendidas y recomendaciones para trabajos posteriores 52 5.0.1. Comportamiento por Active Directory . . . . . . . . . . . . . . 52 5.0.2. Servidores de NIC México como servidores recursivos . . . . . . 53 5.1. Recomendaciones para trabajos posteriores . . . . . . . . . . . . . . . . 53 Capı́tulo 6. Conclusión 58 Bibliografı́a 60 Apéndice A. Bloques reservados por IANA 64 Apéndice B. Librerı́a libpcap 68 vi Apéndice C. IDMEF 75 Apéndice D. Software utilizado en la solución propuesta 79 D.1. Clasificador Bayesiano . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 D.2. Procesamiento de archivos binarios libpcap . . . . . . . . . . . . . . . . 79 D.3. Herramienta de captura de tráfico . . . . . . . . . . . . . . . . . . . . . 80 Vita 81 vii Capı́tulo 1 Introducción La utilización de sistemas de cómputo en todos los aspectos de la vida diaria del hombre crece dı́a con dı́a creando una dependencia en los mismos. De igual forma, los ataques a estos sistemas han crecido en los últimos años según lo demuestran las estadı́sticas de incidentes de seguridad (ver figura 1.1) reportados al Centro de respuesta a incidentes de cómputo (CERT[5], por sus siglas en inglés) y en la actualidad las pérdidas ocasionadas por estos ataques ascienden a millardos de dólares; sin embargo, un ataque a un sistema de cómputo no solamente puede ocasionar pérdidas económicas, basta con imaginar el costo humano al atacar los sistemas de control de vuelo aéreo, por ejemplo. Aunado al crecimiento de incidentes de seguridad, existe un crecimiento de vulnerabilidades crı́ticas reportadas por el CERT[5] en sistemas operativos, aplicaciones y dispositivos usados en Internet. Existe una gama de herramientas y dispositivos creados para asegurar los sistemas informáticos. Dentro de estas herramientas encontramos los sistemas de detección de intrusos. El proceso de detección de intrusos se basa en monitorear los eventos que ocurren en una computadora o red y analizarlos en búsqueda de ataques que pueden en un momento dado comprometer la confidencialidad, integridad o accesibilidad de la información; el origen de estos ataques proviene del exterior de la red corporativa (Internet) y de la misma red corporativa (usuarios internos). Por su parte, un sistema de detección de intrusos (IDS, por sus siglas en inglés) automatiza este proceso ayudando 1 Figura 1.1: Crecimiento anual de incidentes reportados al CERT. al personal encargado de la seguridad informática a monitorear un mayor rango de dispositivos. El estudio de crimen y seguridad computacional [20] del FBI de los Estados Unidos de América revela que los IDS son la tercera tecnologı́a más utilizada por los especialistas de seguridad. El campo de investigación sobre IDS es muy joven, y la mayorı́a de la investigación se llevó a cabo entre 1980 y 1990. La mayorı́a de los IDS comerciales basan su funcionamiento en la búsqueda de ataques conocidos en bases de datos de firmas, las cuales tienen que ser actualizadas cuando se descubren nuevos ataques. El tiempo transcurrido desde la aparición de nuevos ataques hasta su identificación e incorporación a las bases de datos de firmas es crucial y en ocasiones puede demorar dı́as. Aunado a la demora por parte de las casas de software para actualizar sus bases de datos de firmas encontramos el problema de que estas actualizaciones no son incorporadas a los productos debido a: problemas de conexión de red, administradores inexpertos o la 2 falta de una polı́tica de seguridad adecuada. Investigadores alrededor del globo buscan alternativas para lograr IDS cada vez más poderosos, con la capacidad de identificar ataques no conocidos en tiempo real. La incorporación de técnicas de inteligencia artificial a los sistemas de detección de intrusos promete la detección temprana de ataques no conocidos con la posibilidad de crear sistemas que trabajen con autonomı́a bloqueando accesos para controlar ataques en el momento que estos ocurren. La presente tesis analiza la utilización de redes bayesianas en la búsqueda de tráfico anómalo que pueda indicar ataques no conocidos en servidores autoritativos del sistema de nombre de dominios. Se describen en detalle los beneficios esperados al incorporar redes bayesianas ası́ como el proceso de investigación necesario para la creación del sistema. Recordemos que por la naturaleza del problema es fundamental que exista aprendizaje computacional conforme el sistema es utilizado. 3 Capı́tulo 2 Marco Teórico El presente capitulo describe la arquitectura y diseño detrás del DNS, los tipos de sistemas de detección de intrusos, la utilización de redes bayesianas para generar clasificadores y los modelos de interconexión abierta de sistemas (OSI, por sus siglas en inglés) y del protocolo de control de transmisión y protocolo de Internet (TCP/IP, por sus siglas en inglés). La información de este capitulo presenta la teorı́a necesaria para el desarrollo de la implementación que valida la hipótesis de la presente tesis. 2.1. Detección de intrusos La búsqueda de intrusos en informática es un campo en constante evolución y desarrollo; la utilización cada vez mayor del Internet ha traı́do como consecuencia que los ataques a redes corporativas se vuelvan algo cotidiano y un virus como el código rojo logre afectar las comunicaciones a una escala global. Estos incidentes cuestan a las compañı́as millardos de dólares en pérdidas por incapacidad para realizar funciones, pérdida de información, negación de servicio e inclusive demandas por usuarios o clientes que son afectados indirectamente. Un simple virus como el código rojo costó a las empresas norteamericanas 2.6 millardos de dólares en dos meses [9]. Los IDS tienen como finalidad detectar ataques que se presentan en un sistema 4 computacional, los mismos son parte de la lı́nea defensiva que las empresas utilizan para proteger sus activos informáticos. Los firewalls y otros sistemas basados en listas de control evitan el acceso a partes de una red, sin embargo, generalmente es necesario dejar expuesta alguna sección de la red porque la empresa ofrece algún servicio en lı́nea mediante Internet, o porque existe una relación empresarial y se necesita compartir datos o simplemente porque los usuarios de la compañı́a necesitan conectarse remotamente. Un sistema de detección de intrusos trata de llenar el vació que dejan los firewalls al exponer las secciones de la red que deben estar accesibles desde el exterior. Un IDS como su nombre lo indica trata de detectar intrusos que buscan hacer uso indebido de un recurso computacional. La mayorı́a de los IDS comerciales utilizan una base de datos sobre ataques que tiene que ser actualizada conforme se descubren nuevos hoyos de seguridad en los sistemas. Este modelo ha mostrado su principal punto de falla en la rapidez con la que las empresas que desarrollan el producto generan las nuevas definiciones y la posterior incoproración de éstas a las bases de datos de IDS instalados. El objetivo de esta tesis es explorar si un clasificador bayesiano es capaz de clasificar tráfico malicioso en servidores autoritativos del DNS, creando con esto la base para un IDS inteligente que pudiera detectar ataques no conocidos en servidores autoritativos del DNS. Al diseñar un IDS, se debe elegir entre dos formas de obtención de datos para análisis. Una forma es obtener los datos directamente de la infraestructura de red y el otro paradigma es obtener los datos de los servidores o host. Un IDS que opera en el servidor es llamado host IDS y busca eventos poco usuales ası́ como comportamiento anómalo en el sistema operativo que pueda indicar que existe una intrusión. Un host IDS es frecuentemente utilizado en servidores compartidos por usuarios como aquellos utilizados por instituciones financieras. 5 La detección de intrusos en red, llamada network IDS (NIDS, por sus siglas en inglés), resulta más apropiada en el caso de un servidor autoritativo del DNS. Un NIDS se coloca en la sección de red donde se encuentran los servidores que se desean proteger; la ventaja principal es que se realiza una captura pasiva de tráfico y por lo tanto no es necesario afectar el funcionamiento del servidor en cuestión. Un host IDS puede verse afectado si el atacante logra capturar el servidor, además de que el sistema operativo puede por su complejidad inherente ocultar actividades maliciosas al host IDS. Una vez obtenidos los datos es necesario realizar la detección de intrusos propiamente. Existen diferentes modelos de análisis y detección, los principales están descritos en [26]. Modelos principales de análisis y detección de intrusos. 1. Modelo de detección de uso no correcto: el IDS detecta intrusos al buscar actividad sospechosa que corresponde a firmas de ataques bien identificados con anterioridad. 2. Modelo de detección de anomalı́as: el IDS detecta intrusos mediante la búsqueda de comportamiento anómalo. La detección de uso no correcto. 1. Sistemas expertos: contienen un conjunto de reglas que describen los ataques. 2. Verificación de firmas: donde los escenarios de ataques son traducidos a secuencias de eventos que pueden ser auditados. 3. Redes de Petri: los ataques son representados mediante redes de Petri. 4. Diagramas de estado de transición: los ataques son representados como un conjunto de metas y transiciones. 6 La implementación común de un IDS de uso no correcto es la detección mediante firmas, donde un sistema detecta ataques previamente identificados al buscar la firma invariable dejada por estos ataques. Estas firmas son encontradas al auditar archivos, el servidor o mediante sistemas de captura y análisis de paquetes ubicados en la parte externa e interna de una red. Limitantes de la detección de uso no correcto. 1. Frecuente detección de ataques inexistentes causando falsas alarmas. 2. La necesidad de especificar la firma del ataque, y tener que actualizar estas firmas de ataques en cada IDS. La firma de un nuevo ataque es comúnmente difı́cil de descubrir. La detección anómala. 1. Detección de actividad anormal: donde el IDS busca encontrar intrusos al buscar comportamientos anormales del CPU, sistema de archivos o saturación de la red. 2. Medición estadı́stica de valores históricos. 3. Medición mediante reglas utilizando sistemas expertos. 4. Algoritmos no lineales como redes neuronales y algoritmos genéticos. La implementación común de detección de anomalı́as utiliza el análisis estadı́stico donde el comportamiento del usuario o sistema son medidos mediante variables en el tiempo. Estas variables pueden ser la fecha y hora de entrada ası́ como la fecha y hora de salida de cada sesión y la cantidad de recursos utilizados durante la sesión. La mayor limitación para esta implementación es encontrar los valores de las variables que describen la utilización correcta del sistema minimizando las falsas alarmas. 7 Un servidor DNS, a diferencia de un servidor compartido por usuarios, generalmente solo ejecuta un proceso, que es el servicio de resolución de nombres y no existen usuarios compartiendo el servidor además de que generalmente son ubicados en secciones desmilitarizadas de un firewall por lo cual estos servidores están expuestos al exterior. La solución propuesta en esta tesis se basa en el paradigma de obtención de datos en red (NIDS), ya que resulta más apropiado por la naturaleza del problema. La detección de intrusos es realizada mediante el modelo de detección anómala utilizando un clasificador bayesiano para detectar el tráfico anómalo y posteriormente los posibles ataques. 2.2. Modelo OSI A principio de los años 80, la Organización Internacional de Estándares (ISO, por sus siglas en inglés) reconoció la necesidad de crear un modelo estándar de red; un estándar que permitiera crear sistemas de red interoperables [32]. De esta necesidad surge en 1984, el modelo OSI. El modelo OSI (ver figura 2.1) describe cómo la información fluye de una aplicación a otra a través de un medio fı́sico como una red computacional. El modelo OSI divide un problema complejo en siete problemas pequeños. Cada uno de estos siete problemas es resuelto de forma independiente por una de las capas de las que se compone el modelo OSI. Las siete capas que componen al modelo OSI son: 1. Fı́sica. 2. Enlace. 3. Red. 8 Figura 2.1: Modelo de referencia OSI. 4. Transporte. 5. Sesión. 6. Presentación. 7. Aplicación. Las dos capas inferiores del modelo son implementadas en hardware y software. Las cinco capas superiores generalmente son implementadas solo en software. Ventajas de la solución por capas: Reducción de la complejidad. Facilidad en su aprendizaje. Ingenierı́a modular. Evolución acelerada. Tecnologı́a interoperable. Interfaces estándares. 9 Capa de aplicación La capa de aplicación es la capa superior del modelo OSI, su función principal es proveer servicios a los programas de aplicación fuera del alcance del modelo OSI. Sus funciones son: Identificar e iniciar la comunicación con el destino. Sincronizar a la aplicación emisora y receptora. Establecer los procedimientos para manejo de errores y control de integridad de datos. Determina si existen los recursos suficientes para que la comunicación exista. Capa de presentación La función principal de la capa de presentación es asegurar que la información enviada de una capa de aplicación de un sistema se legible por la capa de aplicación de otro sistema. Esta capa provee un formato común para la transmisión de datos a través de varios sistemas, de tal forma que pueda ser entendida, sin importar los diferentes tipos de maquinas involucradas. La capa de presentación, además de validar el formato y representación de los datos de los usuarios, se encarga de la estructura de datos usados por los programas. La capa de presentación negocia la sintaxis de transferencia de datos para la capa de aplicación. Capa de sesión La capa de sesión controla las sesiones o conexiones lógicas entre los dispositivos de red. Una sesión consiste de un diálogo, o conversación de datos entre dos entidades de presentación. Los diálogos pueden ser: simples. 10 unidireccionales. bidireccionales. Las conversaciones simples o simplex son raras en una red. Las conversaciones unidireccionales o half duplex requieren un complejo control en la capa de sesión, porque el inicio y fin de cada transmisión necesita ser delimitado y monitoreado. La mayorı́a de las redes son capaces de transmisiones bidireccionales o full duplex, sin embargo, la mayorı́a de las conversaciones son unidireccionales. Capa de transporte La capa de transporte se puede visualizar como la frontera entre los protocolos superiores e inferiores, esta capa provee el transporte de datos permitiendo que las capas superiores no necesiten implementar sistemas para verificar la confiabilidad de la conexión. La capa de transporte provee mecanismos para: Multiplexado de las capas superiores. Establecimiento, mantenimiento y transmisión adecuada de los circuitos virtuales de comunicación. Control de flujo de información. Detección y recuperación de problemas de transporte. Capa de red La capa de red envı́a los paquetes de la red origen a la red destino. Provee servicios consistentes de envió y recepción de paquetes punto a punto para el usuario. En una red de área amplia como el Internet, dos redes pueden ser comunicadas a través de distintos puntos intermedios. Estos puntos intermedios son llamados ruteadores. 11 La capa de red es el dominio de los ruteadores. Los protocolos de ruteo seleccionan las rutas óptimas a través de una serie de redes interconectadas. La función principal de la capa de red por consiguiente es la determinación de rutas. Capa de enlace La capa de enlace provee tránsito de datos a través del medio fı́sico. En la capa de enlace los bits que llegan de la capa fı́sica son convertidos en segmentos de datos. Los segmentos están divididos en campos de bits que en conjunto tienen un significado y representación. La capa de enlace tiene las siguientes responsabilidades: Direccionamiento fı́sico. Topologı́a de red. Disciplina de la lı́nea. Notificación de errores. Envı́o en orden de los segmentos. Control de flujo. La capa de enlace está divida en dos subcapas: Subcapa de control de enlace lógico (LLC, por sus siglas en inglés). Subcapa de control de acceso al medio (MAC, por sus siglas en inglés). La supcapa LLC provee soporte para: Conexiones entre aplicaciones corriendo en una red de área local. Control de flujo hacia las capas superiores a través de códigos de permiso para transmisión y recepción. 12 Control de secuencia. La subcapa MAC provee acceso ordenado al medio permitiendo que varios dispositivos usen un medio compartido mediante el control de colisiones. Capa fı́sica La primera capa del modelo OSI es la capa fı́sica. La capa fı́sica es la interfaz al medio de transmisión. La tarea principal de la capa fı́sica es la transmisión de datos al medio como una secuencia de bits. Variables que utiliza la capa fı́sica para su funcionamiento: Nivel de voltaje. Distancias máximas de transmisión. Conectores fı́sicos. El tiempo de cambio en el voltaje. 2.3. Modelo TCP/IP En la actualidad el modelo OSI es utilizado como marco teórico para explicar las diferentes capas ası́ como las interfaces entre las mismas que al trabajar en conjunto permiten la comunicación a través de redes computacionales. El modelo OSI es difı́cilmente mapeado a los protocolos utilizados en la actualidad, debido a esta dificultad nace el modelo de referencia TCP/IP. El modelo de cuatro capas de TCP/IP (ver figura 2.2) también conocido como el modelo de Internet nació a partir de la creación del protocolo TCP/IP actualmente utilizado como el protocolo dominamente para la comunicación en Internet. El modelo TCP/IP es el modelo utilizado para la creación de protocolos de Internet y por lo mismo tiene mayor aplicación práctica que el modelo OSI. El modelo es 13 Figura 2.2: Modelo de referencia TCP/IP. estudiado en tratados sobre TCP/IP como [30], sin embargo, en esta tesis utilizamos como referencia el modelo TCP/IP descrito por la compañı́a CISCO Systems en [31] debido a su enfoque practico. Las redes basadas en transmisión paquetes han permitido la creación de redes tan importantes como el Internet. El protocolo TCP/IP es el protocolo dominante en la actualidad y el modelo de capas surgido a partir de este protocolo es, por su simplicidad, utilizado para entender las interfaces que existen entre los protocolos hoy en dı́a. Es importante conocer el modelo TCP/IP, debido a que la solución desarrollada para comprobar la hipótesis de la presente tesis obtiene información de las capas de interconexión de redes y aplicación. Las cuatro capas del modelo TCP/IP, descrito a detalle en [31], se muestran en la figura 2.2: Capa de aplicación La capa superior del modelo de TCP/IP es la capa de aplicación. Esta capa interactúa directamente con las aplicaciones utilizadas por el usuario y los protocolos en esta capa están diseñados para una función en particular. La mayor 14 cantidad de la información utilizada para probar la hipótesis de esta tesis proviene de esta capa y del protocolo del DNS en particular. La capa de aplicación es especificada por el protocolo en cuestión, existen cientos de protocolos en la actualidad, sin embargo, el protocolo del DNS es uno de los protocolos más utilizados y es la base para uno de los servicios de infraestructura que existen en una red IP. El protocolo del DNS es descrito en la sección 2.4.2 de esta tesis; en esta sección se detalla la información obtenida a partir del protocolo y que es utilizada en la solución propuesta de la presente tesis. Capa de transporte de dispositivo a dispositivo Esta capa es la responsable de guardar la integridad de datos de un punto a otro de la red. Los protocolos en esta capa intercambian información de inicio, estado aceptable y fin de comunicación que permiten conocer el correcto estado de la conexión. Esta capa implementa el servicio de conexión o circuito virtual. Los protocolos más importantes de esta capa son el protocolo de control de transmisión (TCP, por sus siglas en inglés) y el protocolo de datagramas del usuario (UDP, por sus siglas en inglés): El protocolo TCP provee un servicio de conexión confiable, asegurando que la información es retransmitida en caso de existir errores. De igual forma el protocolo TCP permite mantener múltiples conexiones simultáneas. El protocolo UDP provee un servicio de conexión no confiable que permite obtener un mayor nivel de desempeño porque no es necesario el intercambio de mensajes de control. La mayorı́a de las consultas en el DNS utilizan el protocolo UDP. Capa de interconexión de redes Esta capa es responsable de enrutar los paquetes a través de las redes que conforman el Internet o cualquier otra red basada en el protocolo TCP/IP. En esta capa encontramos los dispositivos llamados ruteadores, cuya función es pasar paquetes de datos o datagramas entre redes interconectadas. 15 Prefijo Desde Hasta 10/8 10.0.0.0 10.255.255.255 172.16/12 172.16.0.0 172.31.255.255 192.168/16 192.168.0.0 192.168.255.255 Cuadro 2.1: Lista de direcciones IP privadas. Dentro de la información que podemos obtener de esta capa se encuentra la dirección origen y destino de los datagramas. El protocolo mas conocido de interconexión de redes es el protocolo de Internet (IP, por sus siglas en inglés), el cual provee el servicio básico de envı́o de paquetes. El protocolo IP define un sistema de direccionamiento basado en identificadores de 32 bits en la versión 4 y 128 bits en la versión 6 del protocolo. Todo paquete que viaja por una red IP esta encapsulado en un paquete IP. La información principal que se obtiene de un paquete de IP es la dirección IP origen y destino del paquete. Actualmente existen dos versiones del protocolo IP, la versión 4 (IPv4) y 6 (IPv6). La mayor parte de la comunicación en la actualidad utiliza la versión 4 del protocolo y es la versión analizada en este documento. Las direcciones IP usadas en Internet son asignadas en bloques. Los bloques de direcciones de IPv4 son asignados a usuarios finales mediante una estructura administrativa jerárquica cuya raı́z es Internet Assigned Numbers Authority[13] (IANA, por sus siglas en inglés). IANA asigna bloques del tipo A o /8 a los registros regionales (ARIN que abarca Norteamérica, LACNIC que abarca Latinoamérica y el Caribe, RIPE que abarca Europa, APNIC que abarca Asia y Australia y AfriNIC que abarca Africa). Los registros regionales a su vez asignan bloques más pequeños a usuarios finales. Existen bloques /8 que no han sido asignados y a los mismos se les conoce como el pool libre de direcciones. La lista de bloques /8 no asignados por IANA hasta el 31 de Septiembre/2006 se muestra en la tabla A. Existen direcciones de IPv4 reservadas para utilizar dentro de intranets o redes internas. Estas direcciones son descritas en el RFC 1918[27] (ver tabla 2.3). 16 A continuación se detallan los bloques de direcciones de IPv4 de uso especial: 0.0.0.0/8 tiene un número de propiedades únicas, las cuales han sido implementadas en los stacks de TCP/IP usados en Internet. 0.0.0.0/32 o una dirección IP con únicamente ceros ha sido usada y es reconocida históricamente como la dirección de broadcast. Este uso es obsoleto y el código moderno configura la dirección de broadcast como aquella en la que existen solamente unos para la mascara de red. Es una práctica común usar 0.0.0.0 para codificar la idea de la red por omisión. 127.0.0.0/8 se le conoce como la red de loopback. La mayorı́a de las implementaciones de stack de TCP/IP solo utiliza la dirección 127.0.0.1/32 como dirección de loopback. 192.0.2.0/24 es la llamada red de pruebas. Este prefijo esta reservado para documentación y código de ejemplo. 169.254.0.0/16 es utilizada como el segmento de red para una tarjeta de red que no ha sido autoconfigurada vı́a DHCP. La clase D y E. La clase D es utilizada para multicast y por lo tanto no encontraremos consultas con la dirección IP de origen de la clase D. El uso de la clase E todavı́a se encuentra como desconocido. Capa de acceso a la red La capa de acceso a la red es la capa inferior del modelo TCP/IP. Esta capa contiene los protocolos que el dispositivo utiliza para enviar los paquetes de datos a través de la infraestructura de red. La capa de acceso a red permite que cuando nuevas tecnologı́as de transmisión de datos son desarrolladas no exista la necesidad de reescribir los protocolos de capas superiores. Otra función realizada por esta capa incluye la traducción entre el esquema de direccionamiento IP y el esquema de 17 direccionamiento del protocolo de acceso a red en cuestión. Un ejemplo de los protocolos que podemos encontrar en esta capa es el caso de Ethernet, utilizado en gran parte de las redes locales de la actualidad. El direccionamiento en las redes Ethernet se basa en un identificador único representado por 48 bits asignado a cada interfaz conectada al segmento de red. 2.4. 2.4.1. Sistema de nombres de dominio Historia A finales de los 60s, la Agencia de Proyectos Avanzados de Investigación Avanzada del Departamento de Defensa de Estados Unidos (DARPA, por sus siglas en inglés) patrocinó la creación de ARPAnet, una red de área amplia experimental que conectaba a organizaciones de investigación en los Estados Unidos explica [1]. La finalidad original de ARPAnet fue permitir a contratistas del gobierno compartir recursos computacionales sumamente escasos en ese tiempo. Desde el principio los usuarios utilizaron ARPAnet para colaborar creando lo que en un futuro se conocerı́a como Internet. El protocolo TCP/IP fue desarrollado a principios de los 1980 y rápidamente se convirtió en el protocolo estándar para intercomunicación en la ARPAnet. La red creció de un número pequeño de nodos a miles y miles de conexiones a nivel mundial. La red ARPAnet se convirtió en el backbone de una confederación de redes locales y regionales basadas en TCP/IP, llamada Internet. En 1988, DARPA decidió que el experimento debı́a del culminar y la red original ARPAnet fue reemplaza por NFSNET, una nueva red patrocinada por la Fundación Nacional de Ciencias de Estados Unidos (NSF, por sus siglas en inglés). En los años 70, ARPAnet era una red pequeña y amigable de algunos cientos de nodos. Un archivo llamado HOSTS.TXT contenı́a toda la información necesaria para 18 conocer todos los nodos existentes. El archivo contenı́a un mapeo de nombre de host a direcciones IP. El archivo HOSTS.TXT era mantenido por el Centro de Información de la Red de la Universidad de Stanford (SRI-NIC, por sus siglas en inglés) y distribuido a través de un servidor central. Los administradores de ARPAnet mandaban un mail con los cambios necesarios y el centro de información de red actualizaba el archivo que después era transferido por los usuarios de ARPAnet. El archivo HOSTS.TXT creció conforme crecı́a la red y el ancho de banda requerido para su transmisión creció de igual forma. El problema principal del archivo HOSTS.TXT es que no fue una solución escalable a través del tiempo aunado a los siguientes problemas: Tráfico y carga. El ancho de banda requerido para transmitir el archivo HOSTS.TXT ası́ como el trabajo requerido para su actualización creció de manera exponencial creando un problema para los administradores del SRI-NIC. Colisiones de nombres. Existı́an diversas colisiones de nombres para los equipos, y debido a que el SRI-NIC no tenı́a autoridad para la asignación de nombres, se tornaban en conflictos que requerı́an tiempo y esfuerzo para su solución. Consistencia. Mantener la consistencia de un archivo en expansión se volvı́a más difı́cil con el transcurrir del tiempo. En 1984 la Internet Engineering Task Force (IETF, por sus siglas en inglés), entidad responsable de definir los estándares usados en Internet, asignó a Paul Mockapetris la definición de un sistema de nombres para sustituir el archivo HOSTS.TXT a partir de las discusiones que habı́a tenido la IETF en sus reuniones de principios de los años 80. En 1984, Mockapetris escribió el RFC 882[21] y el 883[22] que describen el DNS. Un RFC es un documento estandarizado por la IETF y que describe un protocolo en 19 particular permitiendo a los desarrolladores crear sistemas que se pueden comunicar entre si. Estos RFC fueron después actualizados por los RFC 1034[23] y 1035[24], que conforman la especificación básica del DNS. Las metas de diseño del DNS son: Un espacio de nombres consistente que pueda ser utilizado para encontrar recursos. Para evitar problemas por codificaciones propias del sistema de comunicación utilizado, los nombres de dominio no deben de contener identificadores de red, rutas o información similar como parte del nombre. La base de datos debe mantenerse en una forma distribuida para obtener mayor redundancia y desempeño. De igual forma las herramientas y tecnologı́as para mantener actualizada la base de datos deben de seguir la filosofı́a de distribución de recursos. El dueño de la información o administrador de la porción de la base de datos debe de ser capaz de definir el balance entre el costo de obtener la información, la velocidad de las actualizaciones, y la exactitud de la información en los caches. La base de datos debe ser lo suficientemente flexible como para poder representar todo tipo de información, como direcciones IP, información sobre servidores de correo, etc. El espacio de nombres debe de mantenerse uniforme, y utilizar clases de datos para representar la información que cada familia de protocolos necesita. Las transacciones del DNS deben ser independientes del sistema de comunicación que se use como transporte. Actualmente las consultas realizadas vı́a Internet son las mayormente utilizadas. 20 2.4.2. Descripción del DNS El DNS es una base de datos distribuida[25]. Esto permite delegar el control de secciones de la base de datos a otras entidades, mientras que la información es accesible a todos los segmentos mediante un esquema cliente servidor. La replicación y almacenamiento temporal de información (caching) proveen robustez y rendimiento adecuados a la base de datos. En el sistema interactúan dos elementos principales: los clientes o resolvers que hacen peticiones y los servidores de nombres que tienen parte de la base de datos y atienden dichas peticiones. Los tres principales componentes del DNS son: El espacio de nombres de dominio y los registros de recursos intercambiados en las transacciones del DNS. Los servidores de nombres, que son programas que tienen la información sobre una porción de la base de datos. Los servidores de nombres deben ser capaces de contactar a otros servidores de nombres y obtener información que no se encuentre en su base de datos local. Se dice que un servidor es autoritativo para la información que se encuentra en su base de datos local. Los resolvers, que son programas utilizados para extraer información de los servidores de nombres. Los resolvers generalmente son funciones del sistema operativo que son invocadas cuando se requiere hacer uso del DNS. Estos tres componentes corresponden a las tres capas o vistas del DNS: Desde el punto de vista del usuario, el sistema de dominios es accedido a través de una simple función del sistema operativo. El espacio de nombre de dominios corresponde a un árbol sencillo y el usuario puede obtener información de cualquier sección del árbol. 21 Figura 2.3: Visualización en forma de árbol de una porción del DNS. Desde el punto de vista de un resolver, el DNS está compuesto de un número desconocido de servidores de nombres. Cada servidor de nombres tiene una o más piezas de la información del árbol del DNS. Desde el punto de vista del servidor de nombres, el DNS consiste en un conjunto de información local llamada zonas. Los servidores de nombres tienen copias de estas zonas. La base de datos del DNS se puede imaginar como un árbol (ver figura 2.3) en el cual las hojas son los nombres de hosts y cada nodo que no es hoja constituye un segmento de la base de datos. Los nodos que no son hojas son la raı́z de lo que se encuentra dentro de su segmento y a la vez existe una raı́z para todo el árbol representada con un “.”. Los servidores de nombres que tienen la información segmentada de la base de datos de nombres de dominios se dividen en dos tipos: 22 Figura 2.4: Ejemplo de resolución de nombres de dominio efectuado por un servidor recursivo. Servidores recursivos. Servidores autoritativos. Servidores Recursivos Los servidores recursivos tienen la tarea de recorrer el árbol para obtener alguna información en especı́fico. La figura 2.4 ilustra el funcionamiento de un servidor recursivo: A continuación (ver figura 2.5) podemos observar el recorrido que realiza el resolver o servidor recursivo para obtener la respuesta de la consulta por www.google.com.mx. El recorrido parte desde los servidores raı́z o root servers. Los registros NS en este ejemplo son utilizados para guiar al resolver en su recorrido en el árbol del DNS: Los registros NS que podemos observar en este ejemplo son registros de referencia o referrals y permiten a un servidor recursivo recorrer el árbol del DNS. Este tipo de 23 Figura 2.5: Ejemplo de registros NS usados por un servidor recursivo para recorrer el árbol del DNS. respuestas componen la mayorı́a de las respuestas que envı́a un operador de registro o registry (ej. NIC México) de Internet. Servidores Autoritativos Un servidor autoritativo es de vital importancia en el DNS y es el servidor que tiene la información completa de un segmento de la base de datos. Estos servidores pueden tener información sobre las direcciones IP de un host (hoja del árbol) o bien pueden tener la información de qué servidores tienen la información de ramas inferiores en el árbol. Por ejemplo, los servidores raı́z tienen la información de cuáles son los servidores que tienen la información sobre los nombres de dominio terminados en .com y a su vez estos servidores tienen la información de 24 los servidores con autoridad o que tienen la información sobre el dominio o sección del árbol microsoft.com, por ejemplo. Los servidores autoritativos son blanco común de atacantes pues al interrumpir el servicio que ofrecen se pierden grandes secciones de la base de datos. Es de vital importancia proteger la infraestructura de los servidores autoritativos para evitar perder secciones de la base de datos del DNS y mantener este servicio de infraestructura funcionando adecuadamente. Registros de datos Si vemos al DNS como una base de datos, los registros serı́an los llamados Resource Records (RR, por sus siglas en inglés), y los campos serı́an los elementos que conforman un RR. De estos elementos el nombre del dominio es el campo llave usado para la realización de las búsquedas. Si vemos al DNS como un árbol entonces un nombre de dominio identifica a un nodo y cada nodo tiene un conjunto de recursos asociados y posiblemente subárboles. Un RR esta formado por el siguiente conjunto de elementos: owner : el nombre de dominio. type: valor numérico de 16 bits que especifica el tipo de recurso. Los tipos refieren a recursos abstractos. class: valor numérico de 16 bits que identifica a una familia de protocolos. TTL: valor numérico de 32 bits que indica en segundos cuanto tiempo dura el RR en el área de cache de los servidores recursivos. RDATA: los datos transmitidos mediante el RR. El formato del RDATA depende del tipo de RR. 25 Consultas estándares Las consultas o queries son enviadas a un servidor para provocar una respuesta. Las consultas pueden viajar por UDP o TCP en el caso de Internet, sin embargo, el transporte de UDP es generalmente utilizado debido a que es menos costoso de procesar ya que es un protocolo no orientado a conexión. Al recibir una consulta o query el servidor de nombres primero verifica sı́ la información está en sus zonas locales, en caso de no existir en sus zonas locales enviará la respuesta obtenida de su cache y en caso de no encontrar la información en su cache el servidor realizará una búsqueda en el sistema de DNS. Generalmente el usuario no genera consultas directamente, en su lugar realiza peticiones a un resolver local el cual envı́a una o mas peticiones a los servidores de nombres necesarios. Una consulta estándar especifica un nombre de dominio a buscar (QNAME), un tipo de consulta (QTYPE), y un tipo de clase o class (QCLASS). En Internet la clase IN es la más utilizada. Además de enviar los registros que son encontrados para esta terna de campos, el servidor puede enviar otros RR que permitan al servidor encontrar la información deseada en algún otro servidor de nombres. Mensajes del DNS Todas las comunicaciones que se realizan dentro del protocolo del DNS se realizan mediante mensajes. Los mensajes tienen un formato definido, y a continuación se presentan las capas que los conforman: Cabecera o Header siempre está presente. La cabecera incluye campos que permiten conocer cuales de las secciones restantes están presentes, y también especifica si el mensaje es una consulta o una respuesta. consulta o Question, es donde viaja la consulta que se esta realizando. Esta sección puede contener solamente un nombre de dominio, una clase y un tipo de registro. 26 Respuesta o Answer, es donde viaja la respuesta a la consulta y existe una gran cantidad de tipos de registros. Esta tesis no aborda el obtener variables a partir de la sección de respuesta. Autoridad o Authority, es donde viaja información sobre otros servidores de nombres que pueden tener la información sobre el dominio. Esta sección es utilizada para guiar a los servidores recursivos hacia otros servidores autoritativos en Internet. Adicional o Additional, es donde viaja información sobre glue records para la sección de authority. Cabecera La cabecera o Header es la sección que siempre esta presente en un mensaje del DNS. La información definida por la cabecera indica si el mensaje es una consulta o respuesta. En caso de ser una respuesta la cabecera indica si la consulta fue realizada con éxito o no. A continuación se muestra el formato de la cabecera: La tabla 2.2 muestra el formato de la cabecera, donde: ID, Un identificador de 16 bits asignado por el programa que genera la consulta. Este identificador es después copiado en la respuesta y puede ser usado por el programa que envı́a la respuesta para hacer match de los queries que ha enviado. QR, Un campo de un bit que especifica si el mensaje es una consulta (0), o una respuesta (1). OPCODE, Un campo de cuatro bits que especifica el significado de la consulta de ese mensaje en especifico. Los valores permitidos son: • 0, una consulta standard (QUERY). 27 • 1, una consulta inversa (IQUERY). • 2, una petición para conocer el tipo de servidor (STATUS). • 3-15, reservado para uso futuro. AA, Respuesta autoritativa o Authoritative Answer, este bit especifica que el servidor de nombres es autoritativo para el nombre de dominio en la sección de consulta. TC, Truncado o Truncation, especifica que el mensaje fue truncado debido a que el tamaño es más grande que el permitido por el canal de transmisión. RD, Recursividad deseada o Recursion Desired, este bit indica que se desea que la consulta sea resuelta mediante recursión. RA, Recursividad permitida o Recursion Available, este bit es activado por el servidor que envı́a la respuesta, y especifica que el servidor puede realizar recursión. Z, Reservado para uso futuro. Debe ser 0 en todos las consultas y respuestas. RCODE, Código de respuesta o Response Code, este campo de 4 bits especifica el tipo de respuesta: • 0, Condición de no error. • 1, El servidor de nombres no fue capaz de interpretar la consulta. • 2, El servidor de nombre no fue capaz de procesar esta consulta debido a un problema con el servidor de nombres. • 3, Error de nombre, este tipo de respuestas solo tienen significado cuando un servidor de nombres es autoritativo para el nombre de dominios, este código significa que el dominio no existe. 28 0 1 2 3 4 QR OPCODE 5 AA 6 7 8 ID TC RD RA QDCOUNT ANCOUNT NSCOUNT ARCOUNT 9 10 11 12 13 14 15 Z RCODE Cuadro 2.2: Cabecera de un mensaje DNS. • 4, El servidor no implementa soporte para este tipo de consulta. • 5, El servidor de nombres se rehúsa a realizar la operación especificada por razones polı́ticas. • 6-15, Reservado para uso futuro. QDCOUNT, un campo de 16 bits que especifica el número de registros en la sección de consulta. ANCOUNT, un campo de 16 bits que especifica el número de registros en la sección de respuesta. NSCOUNT, un campo de 16 bits que especifica el número de servidores de nombres que se encuentran en la sección de autoridad. ARCOUNT, un campo de 16 bits que especifica el número de registros que se encuentran en la sección adicional. 2.5. Redes Bayesianas Un clasificador es una función que asigna a una instancia de un conjunto de atributos una clase. Los clasificadores bayesianos utilizan el teorema de Thomas Bayes que afirma que la probabilidad de que ocurra el evento A dado que el B ocurrió es: 29 Figura 2.6: Red Bayesiana para un clasificador simple o naive. P (A|B) = P (B|A)P (A) P (B) Uno de los clasificadores más efectivos es el clasificador bayesiano simple o naive, descrito en [11], [18] y [19]. Este clasificador aprende analizando datos de entrenamiento la probabilidad de cada atributo Ai dado la clasificación C. La clasificación es realizada mediante la aplicación de la regla de Bayes para computar la probabilidad de C dado una instancia particular de A1 . . . An , y después predecir la clase. Este cómputo es posible al asumir que existe una fuerte independencia: todos los atributos Ai son condicionalmente independientes dado un valor de la clase C. La independencia es probabilı́stica, y en la vida real muy pocas veces existente. A pesar de asumir la independencia probabilista entre los atributos, el clasificador simple tiene una buena exactitud, la estructura de red bayesiana de un clasificador simple se muestra en la figura 2.6. Las variables obtenidas a partir de un paquete del DNS no son independientes entre si. Un clasificador simple ofrece la posibilidad de realizar una clasificación adecuada para el propósito de validar la hipótesis de esta tesis, sin embargo, resulta pertinente 30 analizar los avances [12] en clasificación bayesiana que se han dado en los últimos años e incorporar los mismos a esta tesis. Las redes bayesianas se representan como un grafo acı́clico que permite una representación eficiente y efectiva de la distribución de probabilidades entre un conjunto de variables aleatorias. Cada vértice en el grafo representa una variable aleatoria, y cada conexión entre vértices representa una correlación directa entre las variables. La red sigue un teorema básico: cada variable es independiente de sus no descendientes en el grafo dado el estado de sus padres. El generar redes bayesianas a partir de conjuntos de instancias para un conjunto de variables para después utilizarlas como clasificadores bayesianos es un campo estudiado en la actualidad, y algunas de las mejores soluciones para hacer minerı́a de datos son resultado de estas investigaciones. Este es un tipo de aprendizaje no supervisado, en el sentido de que el modulo de aprendizaje no distingue la variable que define la clase de las variables atributos de los datos. El objetivo es inducir una red (o conjunto de redes) que describen de la forma mas adecuada la probabilidad de la distribución sobre los datos de entrenamiento. Este proceso de optimización es implementado en la práctica mediante el uso de técnicas heurı́sticas para encontrar el mejor candidato sobre un espacio de posibles redes de solución. El proceso de búsqueda depende en una función que da como resultado la eficiencia de cada red candidato. Considere un conjunto finito U = {X1 , . . . , Xn } de variables discretas aleatorias donde cada variable Xi debe tomar valores de un conjunto finito, denotado por V al(Xi ). Finalmente, P es la distribución de probabilidad sobre las variables en U , cuando X, Y, Z son un subconjunto de U . Se dice que X y Y son condicionalmente independientes dado Z, si para toda x ∈ V al(X), y ∈ V al(Y ), z ∈ V al(Z), P (x|z, y) = P (x|z) ∀ P (y, z) > 0. Formalmente, una red bayesiana para U es un par B = {G, θ}. El primer componente, G, es un grafo dirigido acı́clico donde los vértices corresponden a variables aleatorias X1 . . . , Xn , y donde las aristas representan dependencias directas entre las 31 variables. En el grafo G, cada variable Xi es independiente de sus no descendientes. El segundo componente del par que define a la red bayesiana, θ, representa el conjunto de parámetros que cuantifican la red. El problema de aprendizaje en una red bayesiana se puede describir informalmente como: dado un conjunto de aprendizaje D = {u1 , . . . , uN } de instancias de U , encuentre una red B que mejor se aproxima a D. La estrategia común para este problema es introducir una función de evaluación que evalúa cada red con respecto al conjunto de entrenamiento y después realiza una búsqueda por la mejor red de acuerdo a esta función. En general, este problema de optimización es intratable. Sin embargo, para ciertas clases de redes hay algoritmos eficientes que requieren tiempo polinomial dependiendo el número de variables en la red. 2.5.1. Utilización de clasificadores bayesianos para catalogar correo no solicitado La utilización de redes bayesianas y otros algoritmos de inteligencia artificial están siendo utilizados como clasificadores para lograr atacar la subjetividad que puede existir en los ataques de seres humanos a las redes computaciones. A continuación se analiza la utilización de redes bayesianas para la detección de correo no solicitado, también conocido como SPAM. El funcionamiento y filosofı́a detrás de los sistemas de detección de SPAM es similar al funcionamiento y filosofı́a del sistema creado en la presente tesis para comprobar la hipótesis de la efectividad de las redes bayesianas para detectar ataques no conocidos en servidores autoritativos del DNS. Las redes bayesianas se han convertido en un concepto de uso general y en el estándar para detectar SPAM gracias a su exactitud. En un principio se crearon bases de datos de direcciones de IPs donde se hospedaban servidores de correo que enviaban SPAM ası́ como bases de datos con las firmas de 32 mensajes de SPAM previamente identificados, sin embargo, todas estas soluciones eran efectivas ya que el SPAM habı́a sido reportado y anexado a estas bases de datos, la utilización de clasificadores bayesianos ha permitido que los sistemas de correo detecten SPAM no conocido con anterioridad. Spamassassin es un buen ejemplo de un sistema anti SPAM que utiliza clasificadores bayesianos para catalogar el correo electrónico y de igual forma puede ser entrenado para reconocer nuevo SPAM o para adaptarse a las caracterı́sticas propias de cada usuario (idioma, tipo de correos recibidos, etc.). Spamassassin a diferencia de otras soluciones que utilizan redes bayesianas para catalogar SPAM toma en cuenta una cantidad amplia de variables que va mas allá de simplemente obtener todas las palabras del cuerpo del mensaje y utilizar el clasificador, en Spamassassin existen variables cuyo valor es obtenido de un análisis profundo de los encabezados del correo. Se ha propuesto utilizar variables obtenidas a partir del dominio propio del protocolo de envı́o de correo electrónico SMTP[16], en su artı́culo [29] los investigadores explican los buenos resultados obtenidos con esta técnica. Por ejemplo: si la dirección IP de la persona que envı́a el mensaje está en alguna de las listas negras de autores de SPAM en Internet, entonces existe una mayor probabilidad que el correo sea SPAM. El sistema de análisis y obtención de datos de Spamassassin es sumamente flexible y ha permitido que se incorporen nuevas variables de forma sencilla. Por ejemplo la creación del estándar Sender Policy Framework (SPF, por sus siglas en inglés) está permitiendo evitar la utilización de direcciones de inocentes para el envı́o de SPAM, Spamassassin fácilmente logro incorporar la validez de los registros SPF en su conjunto de variables para identificar SPAM. Las variables identificadas en el correo electrónico son alimentadas al sistema de reglas que ya tiene predefinido una probabilidad para cada regla que resulta ser verdadera. Spamassassin viene con un conjunto de reglas y probabilidades predefinidas, 33 sin embargo, se puede entrenar la red bayesiana para reconocer nuevos correos que son SPAM. El usuario simplemente almacena los correos que ha identificado como SPAM y con la ejecución de una utilerı́a de Spamassassin llamada “sa-lerning” se entrena la red para el reconocimiento de nuevos correos. 34 Capı́tulo 3 Definición del Problema Durante años los investigadores han buscado crear IDS que puedan detectar actividades maliciosas sin conocimiento previo; diversas técnicas de inteligencia artificial han sido propuestas en la creación de IDS que simulen el razonamiento de un experto en seguridad, sin embargo no se han obtenido los resultados deseados. La acción de detectar intrusos en una red de cómputo sin conocimiento previo es un problema sumamente complejo y en la actualidad la falta de esta caracterı́stica es reconocida como una de las limitantes de los IDS[2]. Detectar ataques sin conocimiento previo es sumamente complejo, ya que existen una cantidad de variables enormes y sin relaciones claramente definidas entre las mismas que puedan ayudar a implementar una solución exitosa. Aunado a la complejidad intrı́nseca del problema, el mismo puede ser analizado en cada una de las capas del modelo OSI. Los mejores sistemas de detección de intrusos de la actualidad analizan todas las capas del modelo OSI lo que ha creado otro problema, al llegar a las capas superiores existen diferentes protocolos (HTTP, FTP, etc.) y cada uno de estos protocolos tiene un propósito y forma diferente de trabajar, por lo cual se deben crear módulos de detección especı́ficos para cada protocolo. En un principio se planteó como objetivo de tesis: Desarrollar un NIDS inteligente que busque ataques analizando tráfico de enlaces crı́ticos (backbones, distribución a switches de segundo nivel, etc.) en una red mediante la utilización de redes neuronales debido a los prometedores resultados obtenidos en [4], [28], [15] y [8] por investigadores 35 alrededor del mundo. El objetivo resultó estar muy por encima del alcance y posibilidades de una tesis de postgrado de maestrı́a, por lo cual, se decidió acotar el problema y solución. El objetivo original planteaba la creación de un sistema capaz de sustituir al experto de seguridad, con la suficiente capacidad para detectar ataques no conocidos utilizando las variables contenidas en la capa cuatro del modelo OSI y su relación con las capas superiores. Después de acotar el problema y solución se planteó como objetivo: Desarrollar un NIDS inteligente capaz de detectar actividades maliciosas sobre servidores autoritativos del DNS con cierto grado de certeza (probabilidad) utilizando variables de importancia en la capa 4 (transporte) del modelo OSI y analizando de forma exhaustiva variables en la capa 7 (aplicación). Gracias a este nuevo objetivo el problema fue acotado y se pudo utilizar la experiencia del autor en el DNS. El nuevo objetivo busca crear un sistema que permita al experto en seguridad filtrar una gran cantidad de paquetes de DNS y obtener cuales paquetes son sospechosos. La capacidad de análisis, búsqueda de relaciones, sı́ntesis y experiencia obtenida a través del tiempo de un experto en seguridad son caracterı́sticas clave que difı́cilmente podrán ser sustituidas por un sistema computacional autónomo, sin embargo, catalogar el tráfico en base a una probabilidad de actividad maliciosa permitirá al experto en seguridad centrar su atención en el tráfico de mayor importancia. Se eligió proteger servidores autoritativos del DNS, por el papel crı́tico que desempeñan estos servidores en el correcto funcionamiento de Internet, además de que el autor de esta tesis tiene experiencia en el funcionamiento de este protocolo. La solución propuesta analiza la capa de interconexión de redes y exhaustivamente la capa de aplicación del modelo de referencia TCP/IP obteniendo variables a partir de los datagramas de comunicación que posteriormente son utilizadas para clasificar el tráfico como sospechoso o no. La solución propuesta busca proteger servidores autoritativos por lo que se consideran las caracterı́sticas propias de este tipo de servidores. 36 La técnica de inteligencia artificial utilizada es la de clasificadores bayesianos. Los clasificadores bayesianos han resultado sumamente efectivos al implementar clasificadores inteligentes, y actualmente encontramos sistemas que explotan sus caracterı́sticas para buscar desde problemas en redes eléctricas hasta el bloqueo de SPAM o correo no solicitado. La utilización de clasificadores bayesianos para detectar ataques no conocidos es un campo que está empezando a ser estudiado con resultados prometedores [3]. 37 Capı́tulo 4 Solución propuesta mediante clasificacı́ón bayesiana de paquetes de DNS El objetivo principal de la investigación realizada es clasificar consultas del DNS cuyas caracterı́sticas permitan etiquetarlas como tráfico de red sospechoso. Las consultas clasificadas como sospechosas pueden significar un ataque o compromiso en la seguridad y deben ser analizadas con prontitud por los responsables de seguridad de las empresas e instituciones que administran servidores autoritativos. 4.1. Antecedentes Los registros de Internet tienen como función principal administrar un nivel superior del árbol de DNS, y, generalmente proporcionan el servicio de DNS al público en general. La terminación asignada a nuestro paı́s es .mx y NIC México es la empresa que administra los servidores autoritativos para la zona .mx que son clave en la correcta operación de los dominios terminados en .mx y en gran medida de la correcta operación de la mayorı́a de los sitios mexicanos en Internet. Los servidores autoritativos de NIC México reciben aproximadamente 30,000 consultas por minuto y cada consulta puede ser un ataque que puede tener consecuencias tan simples como generar gasto de ciclos de CPU hasta consecuencias graves como 38 lograr comprometer el servidor en cuestión. No existen bases de datos de entrenamiento con información procedente de paquetes de DNS, ası́ que uno de los principales retos para llegar a identificar tráfico anómalo en consultas del DNS es crear las bases de datos de entrenamiento que permitan evaluar si los clasificadores bayesianos u otros métodos de clasificación son adecuados para esta tarea. 4.2. Metodologı́a utilizada Debido a la complejidad de analizar manualmente y de forma individual cada consulta recibida se decidió realizar una preclasificación para generar bases de datos de entrenamiento y de evaluación del clasificador bayesiano. El tráfico analizado para comprobar la hipótesis de esta tesis proviene de muestras capturadas en tiempos aleatorios en uno de los servidores autoritativos de NIC México. Las muestras de tráfico fueron obtenidas mediante la utilización de la herramienta TCPDUMP[14]. La herramienta TCPDUMP permite la captura de tráfico en la interfaz de red del servidor donde se ejecute. El sistema de preclasificación procesa archivos de tráfico capturado mediante la utilerı́a TCPDUMP en los servidores de NIC México y mediante un sistema de reglas cataloga el tráfico como sospechoso o no. El tráfico es catalogado como sospechoso si el valor de alguna de las variables de clasificación esta fuera de los rangos considerados normales por los responsables de seguridad. La figura 4.1 muestra el funcionamiento del sistema de preclasificación de consultas, mismo que permite generar las bases de dato de entrenamiento inicial. Una vez que el sistema de preclasificación ha procesado todas las consultas, etiquetando como sospechosas aquellas que mostraban alguna variable de clasificación fuera de rango normal, se solicita al responsable de seguridad que analice el trabajo realizado 39 Figura 4.1: Diagrama del sistema de preclasificación de consultas del DNS. por el sistema de preclasificación quitando o agregando la etiqueta de sospechoso según sea el caso. Terminando esta tarea, el sistema de preclasificación genera una base de datos de entrenamiento inicial. La base de datos de entrenamiento inicial es utilizada para entrenar el clasificador bayesiano. En las siguientes iteraciones del proceso, la tarea de decidir si una consulta debe ser clasificada como sospechosa es realizada por el clasificador bayesiano propuesto como solución para responder la hipótesis planteada en esta tesis. Este clasificador bayesiano permitirá que el responsable de seguridad de la empresa se enfoque en estudiar las consultas sospechosas con detenimiento y no en la clasificación de consultas como sospechosas. El sistema de clasificación bayesiano es entrenado utilizando la base de datos de entrenamiento inicial generada por el sistema de preclasificación. Una vez entrenado el sistema se le presentan nuevas capturas de tráfico al clasificador bayesiano y se realiza nuevamente la clasificación. El responsable de seguridad retroalimenta el sistema de 40 clasificación bayesiano en cada ejecución del mismo. Las variables de clasificación que utiliza el clasificador bayesiano son las mismas que utiliza el sistema de preclasificación para generar las bases de entrenamiento iniciales. 4.3. Variables utilizadas en la clasificación A continuación se detallan las variables de clasificación utilizadas por el sistema, para cada variable de clasificación se explica porque se eligió como variable de clasificación y los rangos considerados normales: 4.3.1. Dirección IP de origen Preclasificación: en caso de que la consulta provenga de una dirección privada o de un bloque /8 no asignado por IANA o de un bloque de uso especial (ver sección 2.3) se preclasificará la consulta como un paquete sospechoso. La dirección IP de origen de la consulta no deberá estar dentro del rango de direcciones privadas descritas en el RFC 1918[27]. El envı́o de paquetes desde direcciones privadas es algo común en Internet debido a problemas de configuración generalmente con equipos de Network Address Translation (NAT, por sus siglas en inglés). Sin embargo, los atacantes utilizan de igual forma este rango de direcciones porque no se puede rastrear su origen. La dirección IP de origen no deberá estar dentro de los bloques /8 que no han sido asignados por la IANA [13] para su utilización en Internet. Los atacantes utilizan bloques que no han sido asignados por IANA, porque, al igual que las direcciones privadas, no existe prueba de asignación de los mismos. 41 4.3.2. Cantidad de consultas desde la misma dirección IP de origen Preclasificación: Todas las consultas de la muestra provenientes de un cliente que envı́e más de 1,000 peticiones en un minuto serán catalogadas como sospechosas. Actualmente los responsables de seguridad de NIC México clasifican una cantidad substancial de consultas provenientes de una misma dirección IP como un posible ataque o configuración errónea. Las mediciones en este caso son realizadas por minuto, y mediante ajustes manuales se ha situado este valor en 15,000 peticiones. La elecciòn de este número busca evitar falsas alarmas y obedece a las dimensiones de los servidores, sin embargo, es un número muy alto y existe la posiblidad de que tráfico anómalo pueda perderse, por lo que, en caso de que un cliente envı́e más de 1,000 peticiones en un minuto, todas las consultas provenientes de esa dirección IP son catalogadas como sospechosas. 4.3.3. Sección consulta Preclasificación: una consulta que contenga un QNAME no válido será considerada como sospechosa. La sección de consulta es usada para transportar la consulta que se quiere realizar al servidor. Tres son las secciones que componen la sección consulta: QNAME, que es el dominio del cual se trata de conocer la información y deberá cumplir con la sintaxis válida para un nombre dominio. Un nombre de dominio válido esta formado por letras (a-z), números (0-9) y el “-”. Adicionalmente se permite el uso del “ ” cuando el tipo de RR es “SRV”. QTYPE, que es el tipo de RR y es tratado posteriormente en esta tesis. 42 QCLASS, que es el tipo de clase y es tratado posteriormente en esta tesis. 4.3.4. RR type poco usados Preclasificación: cualquier consulta con un QTYPE diferente a los comúnmente utilizados será catalogada como sospechosa. Actualmente existen màs de 70 tipos (QTYPE) de RR definidos. Cada vez que se agrega un tipo de registro las diferentes implementaciones de resolvers, servidores de nombres, stub resolvers, proxies, balanceadores, etc. deben de implementar el procesamiento necesario para entender y poder hacer uso del nuevo tipo de registro. En cada implementación de un nuevo tipo de registro pueden estar presentes vulnerabilidades que pueden generar incidentes de seguridad. A pesar de la constante introducción de nuevos tipos de registros, los tipos de registros creados con la primera especificación del protocolo son los más utilizado con casi el 95 % del total de las consultas segun las muestras analizadas. Debido a que esta tesis no analiza la sección respuesta es imposible detectar si existió un error en el procesamiento de un tipo de registro, sin embargo, la utilizaciòn de tipos de registro pocos comunes puede indicar un intento de explotar una nueva vulnerabilidad. A continuación se detallan los tipos de registros comúnmente utilizados: 4.3.5. Clases poco usadas Preclasificación: cualquier consulta que no sea sobre la clase (QCLASS) IN (Internet) será catalogada como sospechosa. La clase por omisión de las implementaciones del DNS es la clase IN. Existen otras clases como la CHAOS y HESOID, sin embargo, su uso es casi nulo. La clase CHAOS es utilizada porque la implementación BIND utiliza la clase CHAOS para responder la versión de BIND que se está utilizando. Generalmente este tipo de consultas son 43 Nombre de tipo de RR A NS CNAME SOA PTR MX TXT AAAA Código de tipo de RR Descripción 1 una dirección IPv4 de un host 2 un servidor autoritativo 5 el nombre canónico para un alias 6 inicio de autoridad de zona o start of a zone of authority 12 un apuntador a un dominio, utilizado para resolución inversa 15 servidor de mail encargado de recibir el correo para el dominio 16 cadenas de texto 28 dirección IPv6 de un host Cuadro 4.1: Tipos de registros comúnmente utilizados. un indicativo de que alguien quiere conocer que versión de BIND esta siendo utilizada para tratar de explotar alguna vulnerabilidad. 4.3.6. Tamaño del dominio Preclasificación: Una consulta que sobrepase 30 octetos en alguna de las etiquetas (labels) se considerará como sospechosa. La cantidad de octetos normalmente encontrados en una etiqueta (label ) inmediatamente posterior a .mx o alguno de los SLDs (com.mx, gob.mx, net.mx, edu.mx, org.mx) es de 1 a 30 octetos según un muestreo realizado de nombres de dominio. La mayorı́a de los nombres de dominio bajo el árbol .mx se encuentran en el rango de 4 a 13 octetos. A continuación (ver figura 4.2) se presentan gráficas con la cantidad de octetos en los nombres de dominio según un muestro de dominios .mx: Un nombre de dominio de tamaño excesivo en una consulta puede significar el intento de explotar una vulnerabilidad de buffer overflow. Las vulnerabilidades de buffer overflow son comunes y han sido la causa de una gran cantidad de compromisos y ataques de negación de servicio. Una vulnerabilidad de buffer overflow es una condición anómala donde el proceso intenta escribir más datos que el permitido por el tamaño del 44 Figura 4.2: Cantidad de octetos en los nombres de dominio .mx. buffer en memoria causando que los datos extras se escriban en la memoria contigua, que puede ser usada para buffers o código de otros procesos. 4.3.7. Tamaño total de la consulta Preclasificación: una consulta de más de 80 octetos en la sección de dominio será considerada sospechosa. La especificación del protocolo del DNS restringe el tamaño total de la consulta a 255 octetos, sin embargo, el rango normal para el tamaño de un nombre de dominio es de 4 a 13 octetos y se considera sospechoso después de 30 octetos. Considerando que la mayorı́a de las consultas son sobre dominios con cuatro etiquetas (labels) y que las dos últimas etiquetas son com.mx se considera 80 octetos como el lı́mite superior de normalidad. 45 4.3.8. Cantidad de consultas repetidas desde la misma dirección IP Preclasificación: La recepción de más de 12 consultas por la misma información (QNAME, QCLASS y QTYPE) y provenientes de la misma dirección IP en un periodo de un minuto generará que todas las consultas provenientes de esa dirección IP sean consideradas como sospechosas. El DNS implementa el llamado mecanismo de cache, mediante el cual, un servidor de nombres recursivo guarda en memoria durante cierto tiempo la respuesta a una consulta. Gracias, al mecanismo de cache, la cantidad de consultas que llegan a los servidores de nombres es manejable. El DNS provee un servicio llamado negative caching que permite a un servidor de nombres distribuir a los servidores recursivos que un dominio no existirá durante cierto tiempo. El campo MINIMUM en el registro SOA controla por cuanto tiempo el servidor de cache deberá almacenar que el dominio no existe. Debido al comportamiento estándar que debe seguir un servidor de nombres, el envı́o de peticiones desde el mismo cliente preguntando por el mismo nombre, clase y tipo son consideradas como un ataque o un error en la implementación del servidor de nombres. Por omisión, los servidores de nombres realizan generalmente hasta tres intentos para obtener una respuesta y un timeout de cinco segundos para cada una, por lo tanto, en un minuto en el peor de los casos estarı́amos recibiendo 12 consultas por la misma información. 4.3.9. Comandos Preclasificación: una consulta que incluya alguno de los comandos indicativos de un posible ataque será clasificada como sospechosa. 46 Existen comandos que son ejecutados normalmente para tratar de comprometer servidores, por ejemplo, normalmente los atacantes utilizan el comando “wget” para bajar el código malicioso que será utilizado para controlar el equipo u obtener la información deseada. Si encontramos en una consulta el intento de ejecución del comando “wget”, estamos viendo el inicio del compromiso de un sistema mediante la transferencia de código malicioso. Los comandos incluidos como indicativos de un posible ataque son: wget, fget, fetch, rm, sh, bash, perl, mv, lynx. 4.3.10. Cabecera Preclasificación: el OPCODE y QDCOUNT de la cabecera de un mensaje del DNS deberá ser 0 y 1 respectivamente. El valor de los campos ANCOUNT, NSCOUNT y ARCOUNT de la cabecera deberá ser 0. Cualquier consulta que no cumpla con los dos enunciados anteriores será considerada como sospechosa. La cabecera siempre esta presente en una consulta o respuesta del DNS. La cabecera incluye campos que permiten conocer cuales de las secciones restantes de un paquete están presentes. Los campos de la cabecera también permiten conocer si el paquete es una consulta o respuesta, y en el caso de una respuesta permite conocer si la respuesta fue exitosa o no. Un OPCODE de 0 nos indica que es una pregunta estándar y un QDCOUNT de 1 nos indica que existe un RR en la sección consulta. En las secciones de ANSWER, AUTHORITY y ADDITIONAL no deberán existir RR ya que se trata de una consulta y por consiguiente los valores de los campos ANCOUNT, NSCOUNT y ARCOUNT deberá ser de 0. 47 4.3.11. Intento de realizar actualizaciones dinámicas Preclasificación: una dirección IP que intente realizar dynamic updates generará que todos los paquetes provenientes de esa dirección IP sean catalogados como sospechosos. La facilidad de actualizaciones dinámicas o dynamic updates en el protocolo del DNS permite actualizar en tiempo real los registros del DNS. La recepción de dynamic updates en un servidor autoritativo desde direcciones IP que no tienen permiso para realizar la actualización es un intento de modificación de registros o mala configuración por parte del cliente. 4.3.12. Intento de realizar transferencias de zonas Preclasificación: los paquetes provenientes de una dirección IP que intente realizar transferencias de zonas serán clasificados como sospechosos. La facilidad de transferencia de zonas es utilizada por los servidores esclavos para transferir una zona desde un servidor maestro. La recepción de solicitudes de transferencias de zonas desde direcciones de IP que no tienen permiso para realizar la transferencia de zona es un intento por obtener información privilegiada sobre la zona. 4.3.13. Consultas sobre TLDs que no son .mx Preclasificación: una consulta por un dominio con TLD diferente a .mx se marcará como sospechosa. NIC México administra el Country Code Top Level Domain .mx (ccTLD, por sus siglas en inglés) y es de esperarse que las consultas que reciban los servidores de NIC México sean por dominios terminados en .mx y no por dominios de otros Top Level Domain (TLD, por sus siglas en inglés). 48 4.3.14. Tamaño de consulta igual a cero Preclasificación: Una consulta nula será considerada como sospechosa. Durante el análisis de tráfico se encontró que se recibieron consultas con dominios nulos, existe la posibilidad de que estas consultas simplemente no hayan llegado completas al servidor, sin embargo, la cabecera del paquete indicaba que existı́a una consulta dentro del paquete. Estos paquetes nulos resultaron por demás extraños y se decidió incorporar una variable mas para la clasificación. 4.4. Resultados Las capturas realizadas en uno de los servidores de NIC México arrojaron un total de 227,856 paquetes capturados. De esta captura se seleccionaron 61,381 paquetes de forma aleatoria. Se aplicó la preclasificación utilizando las variables descritas anteriormente. Un total de 34,345 de las consultas fueron catalogadas como sospechosas, en parte debido a la cantidad de peticiones repetidas y el número de peticiones recibidas desde la mismas IPs. Al encontrar un número tan alto de consultas preclasificadas como sospechosas se decidió buscar información sobre la cantidad de peticiones legı́timas que reciben otros TLD. En un estudio[7] reciente de cientı́ficos del centro de super cómputo de la Universidad San Diego, California se analizó el tráfico de uno de los 13 root servers y se encontró que solamente el 2 por ciento de las consultas que llegan al root server son necesarias y el 98 restante son totalmente innecesarias. Cerca del 70 por ciento de las peticiones son idénticas o simplemente son consultas repetidas del mismo dominio. Esta información apunta a que es normal encontrar una gran cantidad de tráfico anómalo e innecesario en los servidores de nivel superior. Las 34,345 consultas fueron posteriormente analizadas de forma manual dejando catalogadas como tráfico sospechoso aquellas consultas que deben de ser analizadas a 49 detalle para encontrar porqué se esta dando ese comportamiento o detectar si se trata de un posible un ataque o inicio del mismo. Esta clasificación manual arrojo un total de 18,586 consultas sospechosas, las cuales fueron etiquetadas con el valor numérico 1 (paquete sospechoso). La variable de clasificación puede contener un 0 que indica que el paquete no es sospechoso, 1 que indica que el paquete es sospechoso y 2 que indica que existen altas posibilidades de tratarse de un ataque. Las bases de datos de 18,586 consultas tipo 1 y 42,795 consultas del tipo 0 fueron conjuntadas en una sola base de datos. Posteriormente se seleccionaron 70 por ciento de las consultas aleatoriamente para generar la base de datos de entrenamiento del clasificador bayesiano y 30 por ciento para generar la base de datos de evaluación de aprendizaje del clasificador bayesiano. Debido a que no se encontraron paquetes del tipo 2, se decidió agregar manualmente paquetes de DNS con consultas tipo “CHAOS TXT version.bind´´ que son asociadas con el intento de descubrir la versión del software BIND que se ejecuta y utilizadas generalmente por los atacantes para reconocimiento de la infraestructura. Se agregó un paquete del tipo de 2 a la base de datos de entrenamiento y otro paquete similar del tipo 2 a la base de datos de evaluación. Cabe mencionar que el responsable de seguridad es el encargado de realizar un análisis a detalle de los resultados del sistema de clasificación bayesiano y de etiquetar paquetes como tipo 2. Etiquetar un paquete como tipo 2 requiere la intervención del responsable de seguridad porque esta clasificación requiere el empleo de experiencia y conocimiento. Después de ejecutar el clasificador bayesiano se encontró que 372 consultas no fueron catalogadas como sospechosas cuando manualmente fueron catalogadas de esta forma. De las consultas no sospechosas 297 fueron catalogadas como sospechosas. Catalogar consultas no sospechosas como sospechosas es un problema menor de50 bido a que simplemente la revisión manual de un ser humano descartará estas consultas. Es un problema mayor catalogar consultas sospechosas como no sospechosas, la efectividad en este rubro es de aproximadamente del 90 por ciento. Conforme se entrene el clasificador bayesiano esta eficiencia aumentará, y es ilógico pensar en un sistema de clasificación 100 por ciento efectivo. La consulta tipo 2 fue detectada como tipo 2 en la base de datos de evaluación, conforme se presenten una mayor cantidad de consultas tipo 2 el clasificador bayesiano podrá tener mayores patrones para su clasificación. El sistema desarrollado en esta tesis permite filtrar rápidamente el tráfico y permitir a los encargados de seguridad analizar los paquetes con caracterı́sticas que apuntan a un posible ataque. Esta solución reduce significativamente la cantidad de paquetes que deben analizarse. La sección D describe el software utilizado para la solución desarrollada. 51 Capı́tulo 5 Cosas aprendidas y recomendaciones para trabajos posteriores Durante el análisis de paquetes sospechosos y después de analizar los resultados del clasificador bayesiano se encontraron algunos paquetes que indican un comportamiento o configuración errónea. A continuación se presentan posibles hipótesis del porqué se presentan estas singulares consultas. Un análisis detallado de los mismos permitirá conocer más al respecto. 5.0.1. Comportamiento por Active Directory Alrededor del uno por ciento de las consultas recibidas son consultas por registros del tipo SRV y nombres del tipo ldap. tcp.dc. msdcs.dominio.com.mx. Este tipo de dominios apareció catalogado como sospechoso por el clasificador bayesiano debido al intento de realización de dynamic updates por parte del cliente. Después de una investigación se encontró que Microsoft implementa la búsqueda de los servidores de kerberos mediante DNS utilizando el tipo de consultas SRV. De igual forma el cliente de DNS de Windows implementa mediante dynamic updates la creación de registros automáticos en el DNS cuando se asigna una dirección dinámica. Al parecer si el dominio com.mx no esta bien configurado o presente en el servicio de Microsoft, el cliente termina enviando el paquete de dynamic update al siguiente nivel 52 que serı́a en este caso com.mx. 5.0.2. Servidores de NIC México como servidores recursivos Cuenta la historia de Internet en México que cuando el Internet llegó a nuestro paı́s y solo pocas universidades tenı́an acceso a la red, el servidor autoritativo para los dominios .mx funcionaba como servidor recursivo para el Internet de México. En esos tiempos el único servidor de nombres recursivo que existı́a en nuestro paı́s tenı́a la dirección IP 200.23.1.1. Actualmente NIC México tiene cuatro servidores autoritativos y las consultas pueden llegar a cualquiera de los cuatro con una distribución relativamente uniforme. Al parecer algunas personas siguen colocando a los servidores autoritativos de NIC Mexico como sus servidores recursivos debido a la gran cantidad de consultas que llegan a los servidores por dominios .com con la bandera de recursividad encendidada y sin relación aparente entre alguna consulta realizada con anterioridad que pudiera indicar algún error de procesamiento en el resolver, de igual forma estas consultas son realizadas en su mayorı́a sobre la dirección IP 200.23.1.1. 5.1. Recomendaciones para trabajos posteriores El DNS no solamente es utilizado para la conversión de nombres de dominio a direcciones IP, en la actualidad, existen extensiones que permiten por ejemplo la convergencia de las redes telefónicas y el Internet mediante la utilización de un tipo de registro llamado NAPTR. El sistema de Active Directory de Microsoft funciona gracias a la incorporación del tipo de registro SRV al DNS, y permite el descubrimiento de servicios en una red. Al momento de escribir esta tesis una de las extensiones particularmente interesantes es DNSSEC o la utilización de firmas digı́tales para asegurar y validar las consultas. 53 Esta tesis no abordó estas nuevas extensiones y se enfocó a crear la base para una solución posterior más completa. El siguiente paso es incorporar las nuevas extensiones, ası́ como la evaluación de servidores recursivos. El servicio de transferencia deberá ser analizado en trabajos posteriores porque ya fue explotado en alguna ocasión para lograr comprometer servidores utilizando la implementación dominante BIND. Generalmente las empresas con servidores mantienen listas de acceso para el servicio de transferencias de zonas limitando la factibilidad de un ataque de transferencia de zonas, pero no está por demás su análisis en un trabajo posterior. Los servidores autoritativos tienen una importancia fundamental en Internet, sin embargo, los servidores recursivos son de igual forma fundamentales para que los usuarios de una empresa o proveedor de servicios de Internet puedan utilizar la red de redes. Los servidores recursivos son de igual forma explotados y utilizados en la actualidad para actividades como phishing. Existen más variables que se pueden utilizar en la clasificación de paquetes de un servidor recursivo ya que la interacción con otros servidores es mucho mayor. Existe otra gran fuente de información en la creación de sistemas de clasificación inteligentes para tráfico de DNS: las respuestas a las consultas. Ligando una respuesta del servidor con la consulta previa se pueden obtener una mayor cantidad de variables que podrán ser utilizadas en la clasificación. El enfoque de esta tesis es la investigación de la efectividad de los clasificadores bayesianos en la detección de paquetes sospechosos en servidores autoritativos del DNS. Un sistema completo de detección de ataques en servidores se presenta en la figura 5.1. Un servidor recibe una gran cantidad de peticiones por segundo. El proceso de captura de paquetes es un proceso que afecta directamente la capacidad de procesamiento de un servidor, de igual forma, el proceso de obtención de variables a partir de un paquete del DNS y la posterior clasificación bayesiana requieren ciclos del procesador. Serı́a un error de diseño ejecutar los procesos de captura de paquetes, obtención de 54 Figura 5.1: Sistema de detección de ataques en servidores. 55 variables y clasificación bayesiana sobre el mismo servidor que ejecuta el servicio de DNS. Un diseño más apropiado consiste en utilizar un servidor de monitoreo diferente al servidor donde corre el servicio de DNS que realice la captura de paquetes, obtención de variables a partir de los paquetes del DNS y la clasificación de paquetes sospechosos. La captura de paquetes es realizada mediante la utilización de un dispositivo llamado TAP que tiene como función replicar el tráfico destinado al servidor. Una vez realizada la captura de paquetes, el servidor de monitoreo obtiene las variables de clasificación a partir de los paquetes capturados del DNS, y posteriormente realiza la clasificación bayesiana. Los paquetes catalogados como sospechosos son enviados a un servidor central de clasificación. El servidor central de clasificación recibe los paquetes marcados como sospechosos de todos los servidores de monitoreo y posteriormente realiza una reclasificación de los mismos. El usuario retroalimenta el sistema y el clasificador bayesiano aprende mediante la retroalimentación. El servidor central de clasificación envı́a la nueva red bayesiana generada a partir de la retroalimentación del usuario a los servidores de monitoreo con la finalidad de mejorar la clasificación realizada por cada servidor de monitoreo. El Internet basa su funcionamiento en la cooperación entre diferentes entidades, los proveedores de servicio comparten tráfico mediante un protocolo definido, los navegadores utilizan un mismo estándar, y ası́ sucesivamente. La cooperación entre entidades administradoras de servidores es fundamental para responder efectivamente a las nuevas amenazas que aparecen dı́a con dı́a. Un trabajo posterior deberá incorporar algún mecanismo para comunicar los nuevos ataques encontrados a otras entidades administradoras de servidores ası́ como desarrolladores de implementaciones de servidores y actuar rápidamente en conjunto. Existe un estándar en desarrollo en la IETF llamado Intrusion Detection Message Exchange Format[10] cuya función es interconectar mediante un protocolo en común a los sistemas de detección de intrusos para compartir la 56 información sobre nuevas amenazas encontradas. El apéndice C describe este protocolo en la versión 7 del draft de especificación. Una vez que este protocolo sea estandarizado en la IETF, el mismo deberá ser incorporado al sistema de clasificación bayesiano para comunicar los resultados a otras entidades. Las propuestas de mejora descritas con anterioridad permitirán la creación de un mejor sistema de detección de intrusos en servidores DNS. La incorporación de estas mejoras plantea nuevos retos que para los investigadores del área. 57 Capı́tulo 6 Conclusión La solución de clasificación bayesiana desarrollada para comprobar la hipótesis de esta tesis demostró que es posible capturar y utilizar la inteligencia del ser humano en la clasificación de consultas del DNS. Un servidor autoritativo es sencillo en su funcionamiento, básicamente es una base de datos con un protocolo especial para poderla consultar. La cantidad de variables que se pueden obtener a partir de una consulta en un servidor autoritativo es reducida, sin embargo, suficiente para lograr una clasificación adecuada. El DNS es fundamental para el correcto funcionamiento de Internet. Existen dos servicios básicos de infraestructura en Internet, uno es el ruteo que permite que un paquete de datos pueda llegar de un lugar a otro y el otro es el DNS que permite nombrar a los recursos en Internet. La creación de sistemas computacionales libres de errores y sin problemas de seguridad es difı́cil y casi imposible de lograr con la tecnologı́a actual. La complejidad de los sistemas computacionales aunada a la interacción de componentes creados por diferentes equipos de programación crea un ambiente propicio para la aparición de vulnerabilidades computacionales. La solución propuesta en esta tesis comprobó la eficacia de utilizar clasificadores bayesianos en la clasificación de tráfico a partir de la estructura misma del protocolo. La incorporación de técnicas de inteligencia artificial en IDS es un campo que promete la detección temprana de vulnerabilidades disminuyendo el 58 impacto de las mismas. Esta tesis es la base para crear sistemas de detección de intrusos de redes para el servicio de DNS mucho más efectivos. El objetivo de esta tesis se cumplió a plenitud y NIC México, la empresa encargada de la administración de los servidores autoritativos para los dominios terminados en .mx, tiene una nueva y efectiva herramienta en su arsenal para enfrentar los desafı́os que la seguridad computacional plantea. 59 Bibliografı́a [1] Paul Albitz. DNS and BIND. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2001. [2] Rebecca Bace and Peter Mell. Nist special publication on intrusion detection system. Technical report, NIST (National Institute of Standards and Technology), August 2001. Special Publication 800-31. [3] Daniel Barbara and Sushil Jajodia. Detecting novel network intrusions using bayes estimators. In the 1st SIAM International Conference on Data Mining, April 2001. [4] James Cannady and James Mahaffey. The application of artificial neural networks to misuse detection: initial results. In the 1st International Workshop on Recent Advances in Intrusion Detection (RAID 1998), 1998. [5] CERT Center. Cert/cc statistics 1988-2005. Electronic document available at http://www.cert.org/stats/. [6] J Cheng. Bn powerpredictor. Electronic document available at http://www.cs. ualberta.ca/~jcheng/bnsoft.htm. [7] K.C. Claffy. Sd supercomputer center researchers find unnecessary traffic saturating a key internet rook server. Electronic document available at http: //ucsdnews.ucsd.edu/newsrel/science/sdscRoot.htm. 60 [8] Susan C.Lee and David V.Heinbuch. Training a neural network-based intrusion detector to recognize novel attacks. IEEE Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans, 31(4):294–299, July 2001. [9] Symantec Corporation. Enterprise security news. Electronic document available at http://enterprisesecurity.symantec.com/content.cfm?articleid=852. [10] H. Debar, D. Curry, and B. Feinstein. The Intrusion Detection Message Exchange Format. draft-ietf-idwg-idmef-xml (WORK IN PROGRESS), February 2006. [11] R. O. Duda and P. E. Hart. Pattern Classification and Scene Analysis. John Wiley and Sons, New York, 1973. [12] Nir Friedman, Dan Geiger, and Moises Goldszmidt. Bayesian network classifiers. Mach. Learn., 29(2-3):131–163, 1997. [13] IANA. Internet protocol v4 address space. Electronic document available at http: //www.iana.org/assignments/ipv4-address-space. [14] Van Jacobson, Craig Leres, and Steven McCanne. Tcpdump/libpcap. Electronic document available at http://www.tcpdump.org/pcap3_man.html, 2002. [15] Anup K.Ghosh and Aaron Schwartzbard. A study in using neural networks for anomaly and misuse detection. In Proceedings of the 8th USENIX Security Symposium, 1999. [16] J. Klensin. Simple Mail Transfer Protocol. RFC 2821 (Proposed Standard), April 2001. [17] NLnet Labs. Dns analyzer. Electronic document available at http://www. nlnetlabs.nl/dns-analyzer/index.html, 2003. 61 [18] Pat Langley, Wayne Iba, and Kevin Thompson. An analysis of bayesian classifiers. In National Conference on Artificial Intelligence, pages 223–228, 1992. [19] Pat Langley and Stephanie Sage. Induction of selective bayesian classifiers. In Proceedings of the 10th Conference on Uncertainty in Artificial Intelligence, pages 399–406, 1994. [20] William Lucyshyn Lawrence A. Gordon, Martin P. Leob and Robert Richardson. Computer crime and security survey. Electronic document available at http: //i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2005.pdf. [21] P. V. Mockapetris. RFC 882: Domain names: Concepts and facilities, November 1983. [22] P. V. Mockapetris. RFC 883: Domain names: Implementation specification, November 1983. [23] P. V. Mockapetris. RFC 1034: Domain names — concepts and facilities, November 1987. [24] P. V. Mockapetris. RFC 1035: Domain names — implementation and specification, November 1987. [25] Paul V. Mockapetris. The domain name system. In Proc. of the IFIP WG 6.5 working conference on Computer-based message services, pages 61–72, New York, NY, USA, 1984. Elsevier North-Holland, Inc. [26] JeanPhilippe Planquart. Application of neural networks to intrusion detection. Electronic document available at http://rr.sans.org/intrusion/neural.php, 2004. 62 [27] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear. Address Allocation for Private Internets. RFC 1918 (Best Current Practice), February 1996. [28] Jake Ryan and Risto Miikkulainen. Advances in Neural Information Processing Systems, chapter Intrusion detection with neural networks. The MIT Press, 1999. [29] Mehran Sahami, Susan Dumais, David Heckerman, and Eric Horvitz. A bayesian approach to filtering junk E-mail. In Learning for Text Categorization: Papers from the 1998 Workshop, Madison, Wisconsin, 1998. AAAI Technical Report WS-98-05. [30] W. Richard Stevens. TCP/IP Illustrated Vol. 1 - The Protocols. Addison-Wesley, 1994. [31] Cisco Systems. Understanding tcp/ip. Electronic document available at http://www.cisco.com/univercd/cc/td/doc/product/iaabu/centri4/user/ scf4ap1.pdf. [32] Andrew Tanenbaum. Computer Networks. Prentice Hall Professional Technical Reference, 2002. 63 Apéndice A Bloques reservados por IANA Bloque Fecha Status 001/8 Sep 81 IANA - Reserved 002/8 Sep 81 IANA - Reserved 005/8 Jul 95 IANA - Reserved 007/8 Apr 95 IANA - Reserved 023/8 Jul 95 IANA - Reserved 027/8 Apr 95 IANA - Reserved 031/8 Apr 99 IANA - Reserved 036/8 Jul 00 IANA - Reserved 037/8 Apr 95 IANA - Reserved 039/8 Apr 95 IANA - Reserved 042/8 Jul 95 IANA - Reserved 092/8 Sep 81 IANA - Reserved 093/8 Sep 81 IANA - Reserved 094/8 Sep 81 IANA - Reserved 095/8 Sep 81 IANA - Reserved 096/8 Sep 81 IANA - Reserved Bloques /8 no asignados por IANA. 64 Bloque Fecha Status 097/8 Sep 81 IANA - Reserved 098/8 Sep 81 IANA - Reserved 099/8 Sep 81 IANA - Reserved 100/8 Sep 81 IANA - Reserved 101/8 Sep 81 IANA - Reserved 102/8 Sep 81 IANA - Reserved 103/8 Sep 81 IANA - Reserved 104/8 Sep 81 IANA - Reserved 105/8 Sep 81 IANA - Reserved 106/8 Sep 81 IANA - Reserved 107/8 Sep 81 IANA - Reserved 108/8 Sep 81 IANA - Reserved 109/8 Sep 81 IANA - Reserved 110/8 Sep 81 IANA - Reserved 111/8 Sep 81 IANA - Reserved 112/8 Sep 81 IANA - Reserved 113/8 Sep 81 IANA - Reserved 114/8 Sep 81 IANA - Reserved 115/8 Sep 81 IANA - Reserved 116/8 Sep 81 IANA - Reserved 117/8 Sep 81 IANA - Reserved 118/8 Sep 81 IANA - Reserved 119/8 Sep 81 IANA - Reserved 120/8 Sep 81 IANA - Reserved Bloques /8 no asignados por IANA. 65 Bloque Fecha Status 173/8 Apr 03 IANA - Reserved 174/8 Apr 03 IANA - Reserved 175/8 Apr 03 IANA - Reserved 176/8 Apr 03 IANA - Reserved 177/8 Apr 03 IANA - Reserved 178/8 Apr 03 IANA - Reserved 179/8 Apr 03 IANA - Reserved 180/8 Apr 03 IANA - Reserved 181/8 Apr 03 IANA - Reserved 182/8 Apr 03 IANA - Reserved 183/8 Apr 03 IANA - Reserved 184/8 Apr 03 IANA - Reserved 185/8 Apr 03 IANA - Reserved 186/8 Apr 03 IANA - Reserved 187/8 Apr 03 IANA - Reserved 197/8 May 93 IANA - Reserved 223/8 Apr 03 IANA - Reserved 240/8 Sep 81 IANA - Reserved 241/8 Sep 81 IANA - Reserved 242/8 Sep 81 IANA - Reserved 243/8 Sep 81 IANA - Reserved 244/8 Sep 81 IANA - Reserved 245/8 Sep 81 IANA - Reserved 246/8 Sep 81 IANA - Reserved Bloques /8 no asignados por IANA. 66 Bloque Fecha Status 247/8 Sep 81 IANA - Reserved 248/8 Sep 81 IANA - Reserved 249/8 Sep 81 IANA - Reserved 250/8 Sep 81 IANA - Reserved 251/8 Sep 81 IANA - Reserved 252/8 Sep 81 IANA - Reserved 253/8 Sep 81 IANA - Reserved 254/8 Sep 81 IANA - Reserved 255/8 Sep 81 IANA - Reserved Bloques /8 no asignados por IANA. 67 Apéndice B Librerı́a libpcap Libpcap[14] es la librerı́a de código abierto de captura de paquetes de red por excelencia. Las funciones que componen esta librerı́a conforman un API portable que permite la creación de sistemas para monitoreo de red de bajo nivel. La librerı́a está desarrollada en C y conforma el core del sistema de captura de paquetes tcpdump utilizado en UNIX para depuración. Esta librerı́a fue utilizada en la compresión y modificación del paquete DNS Analyzer[17]. A continuación se muestran las funciones que conforman esta librerı́a y después una descripción del propósito de cada función. pcap t *pcap open live(char *device, int snaplen, int promisc, int to ms, char *errbuf); pcap t *pcap open dead(int linktype, int snaplen); pcap t *pcap open offline(char *fname, char *errbuf); pcap dumper t *pcap dump open(pcap t *p, char *fname); int pcap setnonblock(pcap t *p, int nonblock, char *errbuf); int pcap getnonblock(pcap t *p, char *errbuf); int pcap findalldevs(pcap if t **alldevsp, char *errbuf); void pcap freealldevs(pcap if t *); 68 char *pcap lookupdev(char *errbuf); int pcap lookupnet(char *device, bpf u int32 *netp, bpf u int32 *maskp, char *errbuf); int pcap dispatch(pcap t *p, int cnt, pcap handler callback, u char *user); int pcap loop(pcap t *p, int cnt, pcap handler callback, u char *user); void pcap dump(u char *user, struct pcap pkthdr *h, u char *sp); int pcap compile(pcap t *p, struct bpf program *fp, char *str, int optimize, bpf u int32 netmask); int pcap setfilter(pcap t *p, struct bpf program *fp); void pcap freecode(struct bpf program *); u char *pcap next(pcap t *p, struct pcap pkthdr *h); int pcap datalink(pcap t *p); int pcap snapshot(pcap t *p); int pcap is swapped(pcap t *p); int pcap major version(pcap t *p); int pcap minor version(pcap t *p); int pcap stats(pcap t *p, struct pcap stat *ps); FILE *pcap file(pcap t *p); int pcap fileno(pcap t *p); void pcap perror(pcap t *p, char *prefix); 69 char *pcap geterr(pcap t *p); char *pcap strerror(int error); void pcap close(pcap t *p); void pcap dump close(pcap dumper t *p); pcap open live pcap open live() es utilizada para obtener un apuntador de captura para posteriormente obtener paquetes de la red. device es un string que especifica el nombre de la interfaz de red que será abierta. snaplet especifica el número máximo de bytes a capturar. promisc especifica si la interfaz será configurada en modo promiscuo. to ms especifica el número de milesegundos a esperar para una lectura. pcap open dead pcap open dead() es usada para crear una estructura pcap t utilizada al llamar otras funciones de libpcap. pcap open offline pcap open offline es llamada para abrir un archivo previamente guardado para lectura. fname especifica el nombre del archivo. El archivo utiliza el mismo formato que tcpdump y tcpslice. El nombre “-” es un sinónimo de stdin. errbuf es usado para regresar el texto de error y solamente contiene valor cuando pcap open offline() falla y regresa NULL. pcap dump open pcap dump open() es llamada para abrir un archivo en modo escritura. El nombre “-” es un sinónimo de stdout. Si NULL es regresado por la función entonces pcap geterr() podrá ser utilizado para obtener el texto del error. pcap setnonblock pcap setnonblock() configura un apuntador de captura, abierto mediante pcap open live() en modo no bloqueante o deshabilita el modo no bloqueante según el argumento (0 para modo no bloqueante o cualquier otra cosa para modo 70 bloqueante). Si existe un error, -1 es regresado y errbuf contendrá el texto del error. Esta función no tiene efecto cuando se está leyendo o escribiendo en archivos. En caso de que la función pcap setnonblock() se ejecute con éxito 0 es regresado. En modo no bloqueante cualquier intento de leer del apuntaodr con pcap dispatch() regresará un valor al momento y no detendrá la ejecución del programa esperando la llegada de paquetes. pcap loop() y pcap next() no trabajan en modo no bloqueante. pcap getnonblock() pcap getnonblock() regresa el estado actual (no bloqueante o bloqueante) del apuntador; regresa 0 en caso de estar utilizando archivos de lectura o escritura. Si existe un error regresa -1 y errbuf contiene el mensaje de error. pcap findalldevs() pcap findalldevs() construye una lista de dispositivos de red que pueden ser abiertos con pcap open live(). (Nota: existen dispositivos que no pueden ser abiertos con pcap open live() por falta de privilegios por ejemplo). alldevsp es un apuntador al primer elemento de la lista; cada elemento de la lista es del tipo pcap if t. pcap freealldevs() pcap freealldevs() es utilizado para liberar de memoria una lista previamente creada con pcap findalldevs(). pcap lookupdev() pcap lookupdev() regresa un apuntador a un dispositivo de red que puede ser utilizado por pcap open live() y pcap lookup net(). Si existe un error entonces NULL es regresado y errbuf contiene el mensaje de error. pcap lookupnet pcap lookupnet() es utilizado para determinar el número de red y máscara asociada con el dispositivo de red. Tanto netp y maskp son punteros del tipo bpf u int32. Esta función regresa -1 cuando ocurrió un error y errbuf contiene el mensaje de error. pcap dispatch 71 pcap loop pcap next pcap next() lee el próximo paquete (llamando pcap dispatch() con cnt de 1) y regresa un puntero u char a los datos contenidos en el paquete. pcap dump pcap dump() envı́a la información del paquete al archivo abierto con cap dump open(). Nota: los argumentos de llamado de la función son utilizables con los usados por pcap dispatch() o pcap loop(). Si se llama directamente entonces el parámetro user es del tipo pcap dumper t igual al regresado por pcap dump open(). pcap compile pcap compile() es usado para compilar la cadena str como programa de filtrado. program es un apuntador a una estructura bpf program y su valor es proveı́do por pcap compile(). optimize controla si se aplicara optimización en el código resultante. Si la función regresa -1 indica un error y la función pcap geterr() deberá ser utilizada para desplegar el texto del error. pcap setfilter pcap setfilter() es utilizada para especificar el programa de filtrado. fp es un apuntador a una estructura bpf program. La función regresa -1 si ocurrió un error en cuyo caso la función pcap geterr() deberá ser utilizada para desplegar el texto del error. pcap freecode pcap freecode() es utilizada para liberar la memoria reservada para una estructura del tipo bpf program struct generada por la función pcap compile(). pcap datalink pcap datalink() regresa el tipo de capa de enlace, entre las mas importantes encontramos: DLT NULL, BSD loopback encapsulation. DLT EN10MB, Ethernet (10Mb, 100Mb, 1000Mb, and up). 72 DLT IEEE802, IEEE 802.5 Token Ring. DLT FDDI, FDDI. DLT ATM RFC1483, RFC 1483 LLC/SNAP-encapsulated ATM. DLT RAW, raw IP. DLT IEEE802 11, IEEE 802.11 wireless LAN. DLT LTALK, Apple LocalTalk. pcap snapshot pcap snapshot() regresa el tamaño especificado cuando pcap open live fue llamado. pcap is swapped pcap is swapped() regresa true si el archivo abierto usa diferente ordenamiento de bytes que el del sistema actual. pcap major version pcap major version() regresa el número mayor de la versión de pcap utilizada para escribir el archivo. pcap minor version pcap minor version() regresa el número menor de la versión de pcap utilizada para escribir el archivo. pcap file pcap file() regresa el estándar I/O stream del archivo abierto si el mismo fue abierto con pcap open offline(), o NULL si el dispositivo de red fue abierto con pcap open live(). pcap stats pcap stats() regresa 0 si se ejecuta con éxito guardando su resultado en una estructura pcap stat struct. Los valores almacenados representan estadı́sticas de los paquetes desde el inicio de ejecución de la librerı́a pcap. En caso de existir un 73 error un -1 es regresado y el texto del mensaje podrá ser obtenido con pcap perror() o pcap geterr(). pcap stats() solamente es soportada en capturas en vivo y no en archivos previamente guardados. pcap fileno pcap fileno() regresa el número de apuntador de archivo desde donde fueron capturados los paquetes si un dispositivo de red fue abierto con pcap open live(), o -1, si el archivo fue abierto con pcap open offline(). pcap perror pcap perror() imprime el texto del último error de la librerı́a pcap en el stderr, utilizando el prefijo establecido en prefix. pcap geterr pcap geterr() regresa el texto de error del último error de la librerı́a pcap. pcap strerror pcap strerror() es utilizada si el compilador no cuenta con la función strerror. pcap close pcap close() cierra el archivo asociado con p y libera las reservaciones de recursos. pcap dump close pcap dump close() cierra el archivo abierto para captura de paquetes. 74 Apéndice C IDMEF El grupo de trabajo Intrusion Detection de la IETF tiene como objetivo crear un protocolo para compartir información sobre incidentes de seguridad entre entidades de seguridad informática. Uno de los trabajos principales del grupo es The Intrusion Detection Message Exchange Format (llamado IDMEF en el resto del documento) descrito en un detallado draft[10]. Este draft pretende crear un RFC que podrá ser adoptado por las empresas que desarrollan sistemas de detección de intrusos como el formato estándar para compartir información sobre eventos sospechosos y lograr integrar estos sistemas de una forma eficiente. El protocolo esta modelado en UML y especificado en XML. El protocolo es orientado a contenido por lo que nuevos objetos son introducidos para representar contenido adicional permitiendo que no exista diferencia semántica entre las alertas. Esto es una meta importante, ya que la tarea de clasificar y nombrar vulnerabilidades computacionales es una tarea difı́cil y subjetiva. El protocolo IDMEF contempla una inmensa cantidad de casos ası́ como información que estará disponible para los administradores de sistemas para auxiliarlos en la identificación de ataques. Por ejemplo: el protocolo contempla el envı́o del bugtraq id que especifique la vulnerabilidad que esta siendo explotada. A continuación se describe a grandes rasgos el protocolo. 75 Clase Alert Generalmente cada vez que el sistema de detección de intrusos detecta un evento envı́a un mensaje a los administradores. Dependiendo del sistema de detección de intrusos, un mensaje de alerta puede corresponder a un evento sencillo o a múltiples eventos. Los eventos ocurren asincrónicamente en respuesta a los eventos del exterior. Clase ToolAlert La clase ToolAlert es utilizada para enviar información relacionada con la herramienta o el programa malicioso utilizado para realizar el ataque, y puede ser utilizada por el sistema de detección cuando es capaz de identificar plenamente estas herramientas. Clase CorrelationAlert La clase CorrelationAlert añade información relacionada con la correlación de la información de alerta. Esta diseñada para agrupar una o más alertas, es decir para definir que ciertas alertas están relacionadas. Clase OverflowAlert La clase OverflowAlert es utilizada para enviar información adicional relacionada con ataques de overflow. Su función es que el sistema de detección permita analizar ataques de overflow. Clase Analyzer La clase Analyzer identifica el sistema de detección (censor o consola) desde la cual fue enviada la alerta o el heartbeat. Solamente un sistema de detección puede ser codificado para cada alerta o heartbeat, y debe contener el sistema de detección donde se origina la alerta. Clase Classification La clase Classification contiene el nombre de la alerta, y otra información permitiendo a la consola decidir como y donde desplegar el mensaje. Clase Source La clase Source contiene información acerca de las posibles fuentes del evento que generó la alerta. Un evento puede tener más de una fuente. 76 Clase Target La clase Target contiene información acerca de los posibles destinos de un evento que generó la alerta. Clase Assessment La clase Assessment es utilizada para enviar información sobre las caracterı́sticas del ataque. Clase AdditionalData La clase AdditionalData es utilizada para enviar información que no puede ser representada por el modelo de datos. Clase Time El modelo de datos provee tres clases para representar el tiempo. Estas clases son agregadas de las clases de Alert y Hearbeat. Clase CreateTime La clase CreateTime es utilizada para indicar la fecha y hora en que la alerta o heartbeat fue creada por el sistema de detección de intrusos. Clase DetectTime La clase DetectTime es utilizada para indicar la fecha y la hora en que el evento que produjo la alerta fue detectada por el sistema de detección de intrusos. Clase AnalyzerTime La clase AnalyzerTime es utilizada para indicar la fecha y hora actual en el sistema donde esta corriendo el sistema de detección de intrusos. Clase Assessment El modelo de datos contempla tres tipos de .análisis de riesgos”, que el sistema de detección puede hacer acerca de un evento. Clase Impact La clase Impact es utilizada para permitir al analizador estimar un análisis de riesgo sobre el impacto del evento en el destino. Clase Action La clase Action es utilizada para describir cualquier acción de contraataque tomada por el sistema de detección de intrusos. 77 Clase Confidence La clase Confidence es usada para representar el estimado de la validez del análisis. Clase Support La clase de soporte ayuda a la integración entre las clases de Alert y Heartbeat. Clase Node La clase Node es utilizada para identificar los servidores y otros dispositivos de red. Clase User La clase User es usada para describir usuarios. Clase Process La clase Process es usada para describir el proceso que esta siendo ejecutado en fuentes, destinos y sistemas de detección. Clase Service La clase Service describe servicios de red en fuentes y destinos. Puede identificar servicios por nombre, puerto y protocolo. Cuando la clase Service es agregada a la clase Source se entiende que el servicio es interesante porque los ataques provienen de ese puerto. Cuando la clase Service es agregada a la clase Target se entiende que el servicio es interesante por los ataques están dirigidos a ese puerto. Clase FileList La clase FileList describe archivos y otros objetos sobre archivos en servidores destinos. 78 Apéndice D Software utilizado en la solución propuesta D.1. Clasificador Bayesiano El clasificador bayesiano que se eligió es la implementación de J. Cheng llamada BN PowerPredictor[6]. La herramienta desarrollada por Cheng recibe como entrada una base de datos compuesta por registros y campos. Los registros son una instancia de los campos o una consulta en el dominio del problema que se trata en esta tesis. Los campos son las variables de clasificación descritas con anterioridad. D.2. Procesamiento de archivos binarios libpcap Durante el desarrollo del sistema de preclasificación se llegó a la conclusión que seria más fácil procesar los archivos de captura de tráfico si estuvieran convertidos a un formato en texto o simplemente se hubiera obtenido la información del paquete del DNS del archivo binario de captura. Se decidió utilizar la herramienta DNS Analyzer[17] para leer los archivos binarios, buscar los paquetes de DNS y posteriormente almacenar en texto claro los campos de interés del paquete de UDP y de la capa de aplicación del DNS. El software DNS Analyzer fue modificado para funcionar en el sistema operativo FreeBSD versión 6.0 de forma adecuada con versiones nuevas del API de libpcap[14], 79 eliminando warnings que se obtuvieron en las primeras ejecuciones. Los archivos de tráfico en texto previamente generados por la herramienta DNS Analyzer son procesados por el sistema de preclasificación para obtener las variables de clasificación. D.3. Herramienta de captura de tráfico Las capturas de tráfico se obtuvieron al ejecutar la herramienta TCPDUMP sobre la interfaz de conexión a Internet del servidor, el tráfico capturado es almacenado como un archivo binario en formato libpcap. Almacenar el tráfico capturado en disco no es escalable para una herramienta de verificación en tiempo real que serı́a un trabajo posterior a esta tesis, por lo que, la utilización de un TAP serı́a la solución para el problema de escalabilidad en la parte de captura de trafico. 80