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
