UNIVERSIDAD DE CUENCA

Transcripción

1 UNIVERSIDAD DE CUENCA FACULTAD DE INGENIERIA ESCUELA DE INFORMATICA DISEÑO Y CONSTRUCCIÓN DE UN SISTEMA DE DETECCIÓN DE INTRUSIONES PARA LA UNIVERSIDAD DE CUENCA TESIS PREVIA A LA OBTENCION DEL TITULO DE INGENIERO DE SISTEMAS DIRECTOR: Ing. Otto Parra González AUTOR: Pablo Vladimir Astudillo Aguilar Cuenca Ecuador 2005

2 AGRADECIMIENTO A mis padres, sin su apoyo incondicional esto aún sería solo un sueño. Al Ing. Otto Parra González, por el soporte y la confianza depositada en mí para la terminación de la presente tesis. A Jessica, Pablo, Freddy, Camila, Karol, Elina, Iván, Cristóbal, Mauricio, compañeros de lucha que hicieron que el camino, aunque difícil, fuera más corto y agradable. Gracias por arrastrarme a la universidad cuando abandonarlo todo y dormir parecía la mejor idea. Gracias por el café, el sofá, los cumpleaños con vela y pan y, sobre todo, gracias por su compañía. 2

3 DEDICATORIA Al esfuerzo que requirió llegar hasta aquí. es hora de volver a mi, a contar las cosas que me hacían bien, de verdad, es hora de volver a mi, a cantar yo necesito ver el sol, de verdad. Fito Paez. 3

4 RESUMEN DE TESIS La presente tesis consiste en el diseño y construcción de un NIDS (Sistema de Detección de Intrusiones basado en Red), para la Red Académica Integral de la Universidad de Cuenca, que complemente la labor de los elementos de seguridad implementados tales como Firewalls, Intranet, Control de Acceso, etc. El NIDS desarrollado utiliza el algoritmo de comparación de patrones, el cual detecta ataques capturando y analizando paquetes de red en busca de firmas de intrusión en sus cabeceras y datos. Una firma de intrusión consiste en un grupo de valores determinados en los campos de cabecera de los paquetes que caracterizan y diferencian a un ataque del tráfico legítimo. 4

5 CONTENIDO PARTE I: MARCO TEORICO...10 CAPITULO Introducción a los Sistemas de Detección de Intrusiones Qué es un Sistema de Detección de Intrusiones? Por qué utilizar un IDS? Definiciones Seguridad, dos puntos de vista Confianza Vulnerabilidad Amenaza Políticas de seguridad Intruso Alarmas o Alertas Falsos positivos y falsos negativos Motivos que originan problemas de seguridad Diseño o desarrollo Gestión Confianza Elementos de la detección de intrusiones: Arquitectura de los IDS CIDF (Common Intrusion Detection Framework) Autopost de AusCERT Arquitectura de IDWG (Intrusion Detection Working Group) Clasificación de los IDS IDS basados en host (HIDS) IDS basados en red (NIDS) Topologías de los NIDS Un modelo de funcionamiento Fuentes de información basadas en máquina Registros de auditoría Registro de Sistema Información de aplicaciones

6 1.7.2 Fuentes de información basadas en red Paquetes de red Captura de paquetes en sistemas Windows Captura de paquetes en sistemas UNIX Limitaciones de los IDS...37 CAPITULO 2. Análisis y Diagnóstico Detección de usos indebidos Comparación de patrones Fortalezas y Debilidades Comparación simple de patrones Comparación de Patrones en contexto de Conexiones Análisis de Protocolos El ambiente del IDS El Futuro: Un modelo complementario Estudio de las Firmas de los Ataques más conocidos Escaneo de Puertos Escaneos abiertos Escaneos medio-abiertos Escaneos silenciosos IP Spoofing Sustento técnico del IP Spoofing Consecuencias del diseño TCP/IP Ataques spoofing Defensa contra el Spoofing Denegación de Servicios Smurf o Broadcast storm Fraggle TCP Syn Flood Land Winnuke o Supernuke Fragmentos IP Snork Chargen y Chargen-Echo DDoS Denegación de Servicios Distribuida

7 Trinoo Tribe Flood Network y TFN2K Stacheldraht Detección de anomalías Detección de anomalías basada en Estadística Detección de anomalías basada en Especificaciones Fortalezas y Debilidades de la Detección de Anomalías Estado actual de la Detección de Anomalías Métodos alternativos Sistemas Expertos Análisis basado en Heurística...91 Capítulo 3. Respuestas Activas Tipos de Respuesta Activas Cierre de sesión Actualizaciones de Firewall Observaciones sobre las Respuestas Activas Adopción de Políticas de Respuestas Activas Cronometraje Denegación de Servicios autoprovocada...98 PARTE II: ANALISIS, DISEÑO, IMPLEMENTACIÓN Y PRUEBAS DEL NIDS Capítulo 4. Análisis de la Red de la Universidad de Cuenca Características generales Descripción de los Servidores Diagrama de la DMZ de la Universidad de Cuenca Capítulo 5. Requerimientos y Casos de Uso Presentación general Cliente Metas Requisitos funcionales (Funciones del sistema) Requisitos no funcionales (Atributos del sistema) Actores del Sistema Casos de uso Clasificación de los Casos de Uso Asignación de los Casos de Uso a los Ciclos de Desarrollo

8 Capítulo 6. Análisis del NIDS Modelo Conceptual Diagramas de Secuencia Contratos Capítulo 7. Diseño del NIDS Diagramas de Colaboración Diagrama de Clases Descripción de las Clases del diseño Diagrama de Base de Datos Descripción de las Tablas de la Base de Datos Funcionamiento en tiempo real Ambiente gráfico de la herramienta Configuración de respuestas automáticas Asistente para responder a ataques Diagnóstico de vulnerabilidades después de un ataque Capítulo 8. Implementación y Pruebas Plataforma Base de Datos Lenguaje de Programación Interfaz Gráfica Herramienta de desarrollo Multihilo Pruebas Pruebas de Escaneos de Puertos (nmap) Saturación de conexiones (syn flooder) Direcciones IP y Puertos reflexivos (hping2) Cadenas sospechosas en payload (nemesis) PARTE III: CONCLUSIONES, RECOMENDACIONES, BIBLIOGRAFIA Y ANEXOS CONCLUSIONES RECOMENDACIONES BIBLIOGRAFIA ANEXOS Anexo 1. Cuadros Estadísticos del Tráfico de Red

9 Anexo 2. Manual de Instalación Anexo 3. Manual de Configuración Anexo 4. Manual de Operación y Administración Anexo 5. Denuncia de Tesis

10 PARTE I: MARCO TEORICO 10

11 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Cuando una organización conecta su red al Internet, esta se vuelve vulnerable a un gran número de amenazas relacionadas con la seguridad. La cantidad de bugs y agujeros de seguridad aumentan en proporción directa al crecimiento de la red. Tarde o temprano, estos escaparán al control del administrador más disciplinado. Las organizaciones están reconociendo el valor de una buena política de seguridad que defina lo que es y no permitido en términos del uso de la red y acceso desde el Internet. Para esto, emplean un grupo de herramientas que implementan estas políticas, usualmente en la forma de uno o varios firewalls. Antes de iniciar la compleja tarea de configurar el firewall, el administrador necesita un conocimiento detallado de lo que puede hacer un hacker, y de lo que debería o no debería dejar pasar el firewall. Basta con un pequeño error en esta configuración para abrir enormes agujeros de seguridad. El mensaje es claro: un firewall mal configurado puede ser peor que no tenerlo, debido a que este dará un falso sentido de seguridad. Por lo tanto, para brindar una protección más efectiva a las organizaciones, es necesario auditar la red constantemente. A fin de lograr esto, una nueva categoría de software ha tomado fuerza en los últimos años: los Sistemas de Detección de Intrusiones (IDS). Utilizando una analogía con la seguridad del hogar, se puede optar por instalar cerraduras de buena calidad en las puertas y ventanas. Esto ayuda a mantener fuera a los intrusos, y es el equivalente al firewall de la red, esto se conoce como defensa perimetral. Sin embargo, frecuentemente se encuentran formas de evadir estas medidas. Por ejemplo, un intruso puede vulnerar la ventana trasera de la casa, o ingresar directamente por la puerta cuando alguien olvido asegurarla. Autor: Pablo Astudillo Aguilar 26/06/

12 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Una vez que el intruso accede al interior, es libre de hacer lo que se le antoje, desde robar o destrozar objetos, hasta obtener copias de las llaves para romper las seguridades nuevamente sin mayor esfuerzo. De cualquier manera, no es buena idea enterarse del atraco al regresar a casa y ver el desastre. Es por esto que en muchos hogares se instala también una alarma contra robos, de manera que si el intruso supera la defensa perimetral, esta alarma alertará al dueño o a los vecinos para que intervengan y eviten que el robo se consume. Los IDS son el equivalente a las alarmas contra robos. Deben ser usados en combinación con los firewalls. No se puede tener un sistema 100% seguro. Sin embargo, si alguien lo suficientemente listo rompe la defensa perimetral, el administrador debe saberlo lo antes posible. El uso de los IDS ha crecido en importancia debido a la expansión de las compañías que basan sus actividades en el Internet. En los años 80 s y principios de los 90 s, los ataques de denegación de servicios (Denial of Service) no eran frecuentes y eran considerados problemas leves. En la actualidad, los ataque DoS exitosos dejan fuera de servicio organizaciones enteras basadas en el comercio electrónico Qué es un Sistema de Detección de Intrusiones? Un Sistema de Detección de Intrusiones o IDS (Intrusion Detection System) es una herramienta de seguridad encargada de monitorizar los eventos que ocurren en un sistema informático en busca de intentos de intrusión. 1 The NSS Group. Intrusion Detection Systems, Group Test [en línea]. Edición 3. Cambridgeshire, Inglaterra. The NSS Group. Diciembre 2000, revisado en Junio Introduction. Pagina 1. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

13 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Se define intento de intrusión como cualquier intento de comprometer la confidencialidad, integridad, disponibilidad o evitar los mecanismos de seguridad de una computadora o red. 2 Su tarea principal es buscar patrones previamente definidos que impliquen cualquier tipo de actividad sospechosa o maliciosa sobre nuestra red o host. Aumentan la seguridad de un sistema, vigilan el tráfico de red, examinan los paquetes analizándolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque, como por ejemplo: un barrido de puertos. 3 Dado que la mayoría de las veces no se puede detener un ataque, estos sistemas no deberían ser tenidos en cuenta como una alternativa a las buenas medidas tradicionales de seguridad. No existen sustitutos para una política de seguridad empresarial cuidadosamente pensada, respaldada por procedimientos eficaces que sean ejecutados por personal calificado, utilizando las herramientas adecuadas. Los IDS deberían visualizarse como una herramienta adicional en la batalla continua contra hackers y crackers. 1.2 Por qué utilizar un IDS? La detección de intrusiones permite a las organizaciones proteger sus sistemas de las amenazas que aparecen al incrementar la conectividad en red, y la dependencia que se tiene hacia los sistemas de información. 2 MIRA, Emilio. Implantación de un Sistema de Detección de intrusos en la Universidad de Valencia [en línea]. Edición 1. Valencia, España. Capítulo 1. Introducción a los Sistemas de Detección de Intrusos. Página 13. Disponible en: 3 MIRA, Alfonso. Sistemas de Detección de intrusos y Snort. Maestros del Web [en línea]. Edición 1. Publicado el Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

14 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Los IDS han ganado aceptación como una pieza fundamental en la infraestructura de seguridad de la organización. Hay varias razones para adquirir y usar un IDS: Prevenir problemas al disuadir a individuos hostiles. Al incrementar la posibilidad de descubrir y castigar a los intrusos, el comportamiento de algunos cambiará de forma que muchos ataques no llegarán a producirse. Detectar ataques y otras violaciones de la seguridad que no son prevenidas por otras medidas de protección. Los intrusos, usando técnicas ampliamente conocidas, pueden conseguir accesos no autorizados a muchos sistemas conectados a redes públicas. Esto ocurre cuando vulnerabilidades conocidas no son corregidas. Aunque los vendedores y administradores procuran dar a conocer y corregir estas vulnerabilidades, hay situaciones en las que esto no es posible: o En algunos sistemas heredados, los sistemas operativos no pueden ser parcheados o actualizados. o Incluso en los sistemas en los que se puede aplicar parches, los administradores a veces no tienen el suficiente tiempo y recursos para seguir e instalar las últimas actualizaciones necesarias, sobre todo en entornos que incluyen un gran número de computadores con sistemas operativos y hardware variado. o Los usuarios y administradores pueden equivocarse al configurar sus sistemas. o Un IDS puede detectar cuando un atacante ha intentado penetrar en un sistema explotando un fallo no corregido. De esta forma, el administrador podría ser advertido de respaldar la información del sistema inmediatamente, evitando así que se pierda información valiosa. Detectar preámbulos de ataques (normalmente pruebas de red y otras actividades). Cuando un intruso ataca un sistema, lo hace típicamente en fases predecibles. En la primera fase, este realiza pruebas y examina el sistema o red en busca de un punto de entrada óptimo. En sistemas o redes que no disponen de un IDS, el intruso es libre de examinar el sistema con un Autor: Pablo Astudillo Aguilar 26/06/

15 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones riesgo mínimo de ser detectado. Esto le facilita la búsqueda de puntos débiles en la red. La misma red, con un IDS monitorizando sus operaciones, le presenta una mayor dificultad. Aunque el intruso puede examinar la red, el IDS observará estas pruebas, las identificará como sospechosas, podrá activamente bloquear el acceso del atacante al sistema objetivo y avisará al personal de seguridad de lo ocurrido para que tome las acciones pertinentes. Documentar el riesgo de la organización. Cuando se hace un plan para la gestión de seguridad de la red o se desea redactar la política de seguridad de la organización, es necesario conocer cual es el riesgo de esta ante posibles amenazas, la probabilidad de ser atacada, o, si incluso ya está siendo atacada. Un IDS ayuda a conocer la amenaza existente, fuera y dentro de la organización, brindando soporte en la toma de decisiones acerca de los recursos de seguridad que se deben emplear, y del grado de cautela que se debe adoptar al redactar la política de seguridad. Proveer información útil sobre las intrusiones que se producen. Incluso cuando los IDS no son capaces de bloquear ataques, pueden recoger información relevante sobre éstos. Esta información puede ser usada para corregir fallos en la configuración de seguridad de los equipos o en la política de seguridad de la organización. 1.3 Definiciones Antes de hacer que un sistema o red sea seguro, primero es necesario definir lo que se entiende por términos como seguridad, confianza, vulnerabilidad, etc Seguridad, dos puntos de vista La seguridad se puede entender desde dos puntos de vista; el práctico y el formal. Desde una perspectiva práctica, un sistema seguro es "aquel con que se cuenta que actúe de la manera esperada". Este punto de vista tiene unas explícitas implicaciones de confianza. Pero la confianza no se puede medir. No es posible Autor: Pablo Astudillo Aguilar 26/06/

16 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones confiar en que un sistema se comporte como debe. Nadie puede asegurar que un sistema se está comportando como realmente tiene que hacerlo. Según el enfoque formal, más preciso, la seguridad se define a través de una "tríada de conceptos": confidencialidad, integridad y disponibilidad. La confidencialidad implica que la información sea accedida exclusivamente por el personal autorizado a la misma. La integridad consiste en la necesidad de mantener la información inalterada. La disponibilidad se refiere a la necesidad de ofrecer un servicio ininterrumpidamente, de forma que pueda ser accedido en cualquier momento y desde cualquier lugar, evitando en lo posible que algún tipo de incidencia detenga el mismo Confianza La confianza es la esperanza que se tiene de que un sistema se comporte como realmente debería. Establecer relaciones de confianza sin garantías conlleva la aparición de vulnerabilidades, que se convierten en potenciales amenazas Vulnerabilidad Las vulnerabilidades son deficiencias o agujeros de seguridad del sistema que pueden ser utilizadas para violar las políticas de seguridad. Estas pueden deberse a problemas en el diseño de una aplicación, bien de software o de hardware, o también a un plan poco exhaustivo o insuficiente de políticas de sistema. Autor: Pablo Astudillo Aguilar 26/06/

17 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Amenaza Las amenazas son el resultado de explotar las vulnerabilidades. Una amenaza es una situación que tiene la capacidad de perjudicar o dañar al sistema Políticas de seguridad Las políticas de seguridad son el resultado de documentar las expectativas de seguridad. El concepto de seguridad, como se explicó antes, está relacionado con el comportamiento esperado de un sistema. Se puede afirmar que las políticas de seguridad intentan plasmar de alguna manera en el mundo real, los conceptos abstractos de seguridad Intruso Se llama intruso o atacante a la persona que accede (o intenta acceder) sin autorización a un sistema ajeno, ya sea en forma intencional o no. Los tipos de intrusos se pueden caracterizar desde el punto de vista del nivel de conocimiento, formando una pirámide: 1. Clase A: el 80% en la base son los nuevos intrusos que bajan programas de Internet y juegan a probar lo que sucede. 2. Clase B: es el 12%, son más peligrosos. Saben compilar programas aunque no saben programar. Prueban programas, saben como detectar el sistema operativo que está usando la víctima, prueban las vulnerabilidades del mismo e ingresan por ellas. 3. Clase C: es el 5%. Son personas que saben, que conocen y definen sus objetivos. A partir de aquí buscan todos los accesos remotos e intentan ingresar. 4 GONZALEZ, Diego. Sistemas de Detección de Intrusiones [en línea]. Edición Julio 2003, revisado en julio del 2003 para correcciones tipográficas. Capítulo 2. Términos de Seguridad. Página 13. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

18 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones 4. Clase D: es el 3% restante. Cuando entran a determinados sistemas buscan la información que necesitan. Para llegar desde la base hasta el último nivel se tarda de 4 a 6 años, por el nivel de conocimiento que se requiere asimilar. 5 Figura 1-1. Tipos de Intrusos Alarmas o Alertas Una alarma es una advertencia emitida por el IDS hacia el administrador del sistema cuando detecta una actividad sospechosa. Los IDS envían alertas hacia una consola local o remota en una variedad de formas como: logs del sistema, archivos planos, s, ventanas emergentes e incluso mensajes de texto a teléfonos celulares. 6 5 BORGHELLO, Cristian. Seguridad Informática, sus Implicancias e Implementación [en línea]. Edición 1. Septiembre Capítulo 1, De quién debemos protegernos. Página 9. Disponible en: 6 CUFF, Andy. Intrusion Detection Terminology (Part One) [en línea]. SecurityFocus. Ultima actualización Septiembre 3, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

19 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Falsos positivos y falsos negativos Los falsos positivos son alarmas generadas por un IDS en las que se alerta sobre eventos que son en realidad benignos. En otras palabras, son falsas alarmas. Lo opuesto son los falsos negativos, que se dan cuando el IDS falla al identificar una actividad como intrusión cuando en efecto lo era. 7 La clave para cualquier IDS es maximizar las alertas correctas (verdaderos positivos) y, al mismo tiempo, minimizar la ocurrencia de falsos positivos Motivos que originan problemas de seguridad Los problemas de seguridad pueden deberse a una enorme variedad de razones. No obstante, las causas de la mayoría de los problemas de seguridad se divide en tres categorías: diseño/desarrollo, gestión, y confianza Diseño o desarrollo Los problemas originados por un diseño o desarrollo ineficaces afectan tanto al software como al hardware. Un ejemplo de esto ocurre cuando un usuario malicioso substituye un valor en un programa en el intervalo de tiempo en que este no lo está usando. Este fallo se denomina condición de carrera ("race condition"), y tiene lugar cuando aparece un intervalo entre el momento de creación de un valor y el de su chequeo. Otro ejemplo es el que consiste en desbordar el "buffer" de entrada de una determinada aplicación, pasándole como argumentos unos parámetros 7 RANUM, Marcus. False Positives: A User s Guide to Making Sense of IDS Alarms [en línea]. Edición 1. Febrero Definitions. Página 4. Disponible en: ids/whitepaper/falsepositives.pdf 8 FARSHCHI, Jamil. Intrusion Detection In Depth [en línea]. Edición 3.0. Assignment 1. Describe the State of Intrusion Detection. Página 2. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

20 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones intencionadamente largos, provocando la caída del programa y consiguiendo entrar al sistema. Muchos de estos problemas se pueden prevenir mediante una sólida formación en mecanismos de diseño y desarrollo seguro, y sometiendo a los productos a duros controles de calidad Gestión En este grupo entran los problemas debidos a una incorrecta configuración del sistema o de cualquier mecanismo encargado de protegerlo. Son de índole diversa, como por ejemplo una inadecuada aplicación de los permisos de los archivos de sistema o una plantilla de seguridad demasiado permisiva. También entrarían aquí situaciones en la que bien los administradores o los usuarios sortean los mecanismos de seguridad de alguna manera. Por ejemplo, cuando en una red local, protegida mediante un firewall, alguien decide utilizar un módem para establecer una conexión con el exterior. Esta conexión está burlando los controles establecidos por el administrador Confianza Los problemas más agudos son los relacionados con la confianza. Y muchas veces ocurren por no diferenciar entre el entorno de desarrollo y el de producción. Como ejemplo está el sistema operativo UNIX. Durante sus comienzos, fue desarrollado en un entorno universitario. Con el paso del tiempo, sin embargo, surgieron expectativas comerciales para este sistema. Ya no iba a ser utilizado exclusivamente por programadores o ingenieros de sistemas. Al principio los diseñadores confiaban en que los usuarios utilizaran el sistema según las especificaciones, en un determinado entorno bajo unas características especiales. Los usuarios confiaban Autor: Pablo Astudillo Aguilar 26/06/

21 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones en que hubiera un administrador controlando el sistema de forma fiable y competente. Este escenario sigue teniendo lugar, provocando fallos de seguridad Elementos de la detección de intrusiones: Arquitectura de los IDS Existen varias propuestas sobra la arquitectura de los IDS pero ninguna de ellas se usa mayoritariamente. Esto provoca que los productos de los fabricantes que trabajan con distinta arquitectura tengan serias dificultades para interoperar entre sí. Para que estos productos funcionen juntos debe aplicarse un estándar. Los estándares originales fueron el formato autopost de AusCERT y CIDF. En estos momentos, los esfuerzos de estandarización actuales parecen ser IDWG y CVE y posiblemente algunos productos comerciales CIDF (Common Intrusion Detection Framework) El Marco de Detección de Intrusiones Común fue un primer intento de estandarización de la arquitectura de un IDS. No logró su aceptación como estándar, pero estableció un modelo y un vocabulario para discutir sobre las intrusiones. Mucha gente que trabajó en el proyecto original está fuertemente involucrada en los esfuerzos del Grupo de Trabajo de Detección de Intrusiones (Intrusion Detección Working Group, IDWG) del Internet Engineering Task Force (IETF). Los cuatro tipos básicos de equipos que contempla el CIDF son los siguientes: 1. Equipos E, o generadores de eventos, son los sensores. Su trabajo es detectar eventos y lanzar informes. 2. Equipos A, reciben informes y realizan análisis. Pueden ofrecer una prescripción y un curso de acción recomendado. 9 GONZALEZ, Diego. Sistemas de Detección de Intrusiones [en línea]. Edición Julio 2003, revisado en julio del 2003 para correcciones tipográficas. Capítulo 2. Motivos que originan problemas de seguridad. Página 17. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

22 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones 3. Equipos D, son componentes de bases de datos. Pueden determinar si se ha visto antes una dirección IP o un ataque por medio de correlación y pueden realizar análisis de pistas. 4. Equipos R, o equipos de respuesta, pueden tomar el resultado de los equipos E, A y D y responder a los eventos. Figura 1-2. Diagrama de Bloques de la Arquitectura CIDF Estos componentes necesitan un lenguaje para comunicarse, aparece entonces CISL (Common Intrusion Specification Language). Este Lenguaje de Especificación de Intrusiones Común se creó con el objetivo de unir los cuatro tipos de equipos de CIDF. Los diseñadores de CISL pensaron que este lenguaje debería ser capaz, al menos, de transmitir los siguientes tipos de información: Información de eventos en bruto. Auditoría de registros y tráfico de red. Sería el encargado de unir equipos E con equipos A. Resultados de los análisis. Descripciones de las anomalías del sistema y de los ataques detectados. Uniría equipos A con D. Autor: Pablo Astudillo Aguilar 26/06/

23 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Prescripciones de respuestas. Detener determinadas actividades o modificar parámetros de seguridad de componentes. Encargado de la unión entre equipos A y R. CISL es un lenguaje bastante complicado, de sintaxis parecida a LISP, que no llegó a cuajar en la comunidad de seguridad Autopost de AusCERT A diferencia de CIDF/CISL, el CERT australiano (AusCERT) desarrolló un sistema de trabajo sencillo que permitía que se analizara y se agregara un informe en una base de datos con tan solo un par de líneas de Perl. Este sistema tiene una alta interoperabilidad y es muy sencillo de construir y analizar. El problema es que los analistas a menudo necesitan un gran nivel de detalle (una fidelidad alta) acerca del evento, por ejemplo, para análisis forense, y en este modelo toda esa información se perdería. La solución de interoperabilidad que parece ser la elegida es IDWG; según progresa el trabajo, la fidelidad de los datos es el indicador a vigilar más importante Arquitectura de IDWG (Intrusion Detection Working Group) El IETF rechazó el enfoque de CIDF debido a su complejidad, y creó un grupo de trabajo llamado IDWG (Intrusion Detection Working Group) que tenía como objetivo el de definir formatos y procedimientos de intercambio de información entre los diversos subsistemas del IDS. Los resultados de este grupo de trabajo serán: 1. Documentos que describan los requerimientos funcionales de alto nivel para la comunicación entre sistemas de detección de intrusiones, y entre estos y sus sistemas de gestión. 2. Un lenguaje común de especificación que describa el formato de los datos. Autor: Pablo Astudillo Aguilar 26/06/

24 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones 3. Un marco de trabajo que identifique los mejores protocolos que se pueden usar para la comunicación entre los IDS y que defina como se mapean en éstos lo formatos de datos. 10 Figura 1-3. Descripción de un Sistema de Detección de Intrusiones del IDWG 1.6 Clasificación de los IDS Generalmente existen dos grandes enfoques a la hora de clasificar a los sistemas de detección de intrusiones: o bien en función de qué sistemas vigilan, o bien en función de cómo lo hacen. Si se elige la primera de estas aproximaciones, se tienen dos grupos de IDS: Basados en Host: analizan actividades de una única máquina, revisando los eventos generados por los sistemas operativos o software de aplicación, en busca de posibles ataques. 10 MIRA, Emilio. Implantación de un Sistema de Detección de intrusos en la Universidad de Valencia [en línea]. Edición 1. Valencia, España. Capítulo 1. Arquitectura de los IDS. Página 15. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

25 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Basados en Red: analizan paquetes de red, capturados del backbone o de segmentos LAN, en busca de señales de intrusión IDS basados en host (HIDS) Operan sobre la información recogida desde dentro de un computador, como podrían ser los ficheros de auditoría del sistema operativo. Esto permite que el IDS analice las actividades que se producen con una gran precisión, determinando exactamente qué procesos y usuarios están involucrados en un ataque particular dentro del sistema operativo. Los HIDS pueden ver el resultado de un intento de ataque, al igual que pueden acceder directamente y monitorizar los ficheros de datos y procesos del sistema atacado. Ventajas: Al tener la capacidad de monitorizar eventos locales a un host, pueden detectar ataques que no pueden ser vistos por un IDS basado en red. Pueden operar en un entorno en el cual el tráfico de red viaja cifrado, ya que la fuente de información es analizada antes de que los datos sean cifrados en el host origen y/o después de que los datos sea descifrados en el host destino. Herramienta potente, registra comandos utilizados, ficheros abiertos, etc. Tienden a tener menor número de falsos positivos que los IDS basados en red, así como menor riesgo en las respuestas activas. Desventajas: Son costosos de administrar, ya que deben ser gestionados y configurados en cada host monitorizado. Si la estación de análisis se encuentra dentro del host monitorizado, el IDS puede ser deshabilitado si un ataque logra tener éxito sobre la máquina. Pueden ser deshabilitados por ciertos ataques de DoS. Autor: Pablo Astudillo Aguilar 26/06/

26 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Usan recursos del host que están monitorizando, influyendo en el rendimiento del sistema monitorizado. Tienden a confiar en las capacidades de auditoria y logging de la máquina en sí IDS basados en red (NIDS) Los NIDS detectan ataques capturando y analizando paquetes de la red. Escuchando en un segmento, un NIDS puede monitorizar el tráfico que afecta a múltiples hosts que están conectados a ese segmento de red, protegiendo así a estos hosts. Son capaces de comprender todas las diferentes banderas y opciones que pueden coexistir dentro de un paquete de red. Por lo tanto, un NIDS puede detectar paquetes armados maliciosamente y diseñados para no ser detectados por las reglas de filtrado de los firewalls. Habitualmente, los hackers arman ese tráfico para componer un mapa de la red, como una forma de reconocimiento pre-ataque. Los NIDS son capaces de identificar el programa al que se están enviando paquetes en el servidor, y las opciones que se están utilizando, produciendo alertas cuando un atacante intenta explotar alguna falla de esa codificación. La mayoría de las barreras de firewall no pueden hacer esta tarea. Ventajas: Cuando está bien localizado, puede monitorizar una red grande. Tienen un impacto pequeño en la red, siendo normalmente dispositivos pasivos que no interfieren en las operaciones habituales de ésta. Se pueden configurar para que sean muy seguros ante ataques, haciéndolos invisibles al resto de la red. 11 VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Capítulo 18. Sistemas de detección de intrusos. IDSes basados en máquina. Página 314. Disponible en: es.tldp.org/manuales-lucas/doc-unixsec/unixsec-html/ Autor: Pablo Astudillo Aguilar 26/06/

27 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Desventajas: Pueden tener dificultades procesando todos los paquetes en redes con mucho tráfico y pueden fallar en reconocer ataques lanzados durante periodos de tráfico alto. No analizan la información cifrada. Este problema se incrementa cuando la organización utiliza cifrado en el propio nivel de red (IPSec) entre hosts. Los IDS basados en red no saben si el ataque tuvo o no éxito, lo único que pueden saber es que el ataque fue lanzado. Esto significa que después de que un NIDS detecte un ataque, los administradores deben manualmente investigar cada host atacado para determinar si el intento de penetración tuvo éxito o no. Algunos NIDS tienen problemas al tratar con ataques basados en red que viajan en paquetes fragmentados. Estos paquetes hacen que el NIDS no detecte dicho ataque o que se vuelva inestable. Su implementación de la pila de protocolos de red puede diferir a la pila de los sistemas a los que protege. Muchos sistemas servidores y de escritorio actuales no cumplen en ciertos aspectos los estándares TCP/IP, pudiendo descartar paquetes que el NIDS ha aceptado. Esta inconsistencia de información entre el NIDS y el sistema protegido es la base para las técnicas de ocultación de ataques Topologías de los NIDS La decisión de donde ubicar el NIDS es primaria y determinante. De esta decisión dependerá tanto el equipo que se utilice, como el software NIDS y la base de datos. Existen principalmente tres zonas en las que se puede colocar un NIDS, tal y como muestra la Figura 1-4: Autor: Pablo Astudillo Aguilar 26/06/

28 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Figura 1-4. Zonas de un NIDS dentro de una organización Las características que presenta cada una de estas zonas son: Zona roja: Esta es una zona de alto riesgo. El NIDS debe ser configurado para ser poco sensible, puesto que verá todo el tráfico que entre o salga de la red, y habrá más posibilidad de falsos positivos. Zona verde: El NIDS debería ser configurado para tener una sensibilidad un poco mayor que en la zona roja, puesto que ahora, el firewall deberá ser capaz de filtrar algunos accesos definidos mediante la política de nuestra organización. En esta zona aparecen un menor número de falsos positivos que en la zona roja, puesto que en este punto solo deberían estar permitidos accesos hacia nuestros servidores. Zona azul: Esta es la zona de confianza. Cualquier tráfico anómalo que llegue hasta aquí debe ser considerado como hostil. En este punto de la red se producirán el menor número de falsos positivos, por lo que cualquier alarma del NIDS debe ser inmediatamente estudiada. Es importante destacar que la zona azul no es parte de la red interna. Todo lo que llegue al NIDS de la zona azul irá hacia el firewall (por ejemplo, si se utiliza un proxy-cache para los usuarios de web) o hacia el exterior. El NIDS no escuchará ningún tipo de tráfico interno dentro de la red. Autor: Pablo Astudillo Aguilar 26/06/

29 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones En el caso de tener un NIDS escuchando tráfico interno (por ejemplo, colocado entre una VLAN y su router), las falsas alarmas vendrán provocadas en su mayor parte por máquinas internas al acceder a los servidores de nuestra red, por servidores nuestros (DNS sobre todo) y escaneadores de red, por lo que habrá que configurar el NIDS para que no sea muy sensible. 12 A continuación se analizarán algunos ejemplos de las diferentes posibilidades en una misma red. Considere una red dónde un firewall separa la Internet de la Zona Desmilitarizada (DMZ - Demilitarized Zone), y otro que divide la DMZ de la intranet de la organización como se muestra en la Figura 1-5. Por zona desmilitarizada se entiende la zona de acceso público que se muestra al exterior, desde la cual se ofrece servicios. Figura 1-5. Red con NIDS simple El situar el NIDS antes del firewall exterior permite detectar los escaneos de puertos, actividad típica de reconocimiento que señala el comienzo de una intrusión, y se obtendría como ventaja un aviso prematuro. Sin embargo, si los escaneos no son seguidos por un ataque real, se generará una gran cantidad de alertas innecesarias, con el peligro de comenzar a ignorarlas. En este escenario se captura todo el tráfico de entrada y salida de la red. La posibilidad de falsos positivos es grande. 12 MIRA, Emilio. Implantación de un Sistema de Detección de intrusos en la Universidad de Valencia [en línea]. Edición 1. Valencia, España. Capítulo 1. Dónde colocar un IDS?. Página 22. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

30 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Si se escoge colocar el NIDS en la DMZ, se tiene como ventaja la posibilidad de adecuar la base de datos de firmas del NIDS para considerar aquellos ataques dirigidos a los sistemas que están en la DMZ (servidores WEB, FTP, Correo, etc), y configurar el firewall para bloquear ese tráfico. Esta ubicación detrás del firewall monitorizará todo el tráfico que no sea detectado y detenido por el firewall, por lo que será considerado como malicioso en un alto porcentaje de los casos. La posibilidad de falsos positivos es muy inferior. Así mismo, un NIDS dentro de la red, por ejemplo de Recursos Humanos, podría monitorear todo el tráfico entrante y saliente de esa red. El resultado se puede visualizar en la Figura 1-6: Figura 1-6. Red con varios NIDS El NIDS 1 se encargaría de reportar el escaneo de puertos, enviando una alarma al responsable de la seguridad de la organización. El NIDS 2 se encargaría de vigilar la zona desmilitarizada y analizar el tráfico que reciben tanto el servidor WEB, como el servidor de correo. Los otros dos se encargarían de la red interna, el NIDS 3 de la totalidad de la red, y el NIDS 4 de una subred, en este caso la de RRHH. Estos dos NIDS internos podrían ser sensores que recogiesen la información y lo enviasen a una consola dónde se realizarían los cálculos. Autor: Pablo Astudillo Aguilar 26/06/

31 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Consideraciones adicionales sobre la topología Los estudios demuestran que la mayoría de los ataques ocurren en las redes internas, por eso debe considerarse seriamente la implementación de NIDS, no solo en la DMZ, sino también en la red interna. La habilidad de un NIDS para hacer su trabajo implica que el sensor es capaz de hacer "sniffing" (capturar y revisar los paquetes que circulan por una red) de todo el tráfico, desde y hacia los sistemas monitoreados, y comparar todos los paquetes con la base de datos de "firmas" maliciosas. Este hecho hace necesaria la instalación del NIDS en un segmento de red que le permita capturar TODO el tráfico a monitorear. Esto se puede lograr instalando puertos espejados en los switches, o instalando hubs en las conexiones uplink de las interfases de los routers o switches. En una red de arquitectura redundante, cada link redundante debe contar con su propio NIDS Un modelo de funcionamiento El modelo más aceptado para la detección de intrusiones tiene tres fases principales: 1. Fase de recogida de datos (fuentes de información). 2. Fase de análisis. 3. Fase de respuesta. En líneas generales, para que la detección de intrusiones pueda obtener buenos resultados, debe llevar a cabo un proceso de recopilación de información, que posteriormente deberá someter a diversas técnicas de análisis, y en función de los datos obtenidos tendrá que dar algún tipo de respuesta. 13 Presentando IDS. NEX Periódico de Networking [en línea]. Edición 3. Disponible en: nex_1/seguridad/nota1.asp Autor: Pablo Astudillo Aguilar 26/06/

32 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones En las siguientes secciones de este capítulo se analizará la fase de recogida de información y se analizarán las diferentes fuentes de información disponibles. En el Capítulo 2 se estudiará la fase de Análisis: las técnicas para procesar esta información. Finalmente, en el Capítulo 3 se expondrán algunos procedimientos de respuesta que implementan algunos IDS activos (detectan y responden a ataques). Como se comentó en la sección anterior, la detección de intrusiones se puede clasificar según las fuentes de información que utiliza. Aquí se estudiarán los casos pertenecientes a la recopilación de datos basados en máquina y en red Fuentes de información basadas en máquina Este tipo de fuentes de información consisten principalmente en registros de auditoría de sistemas operativos (registros generados por mecanismos del sistema operativo), y los registros de sistema (ficheros generados por el sistema y aplicaciones, generalmente ficheros de texto generados línea a línea). Los monitores basados en múltiples "hosts" utilizan las mismas fuentes, por lo que los apartados a continuación también son aplicables a estos Registros de auditoría El primer elemento de importancia en sistemas de detección basados en máquina son los registros de auditoría. Estos registros son una colección de información sobre las actividades del sistema, creados cronológicamente y dispuestos en un conjunto de ficheros de auditoría. Estos registros son originados por los usuarios y los procesos y comandos que estos invocan. Ventajas: La propia estructura del sistema operativo está diseñada para otorgar suficiente seguridad al sistema de auditoría, y los registros que este genera. El sistema de auditoría trabaja a bajo nivel, por lo que ofrece mayor nivel de detalle que el que puede ofrecer otro mecanismo. Autor: Pablo Astudillo Aguilar 26/06/

33 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Desventajas: Gran parte de los sistemas operativos comerciales existentes no cumplen con los requisitos de auditoría necesarios, a pesar de la documentación que hay sobre el tema. Añadir funcionalidades al núcleo del sistema para que genere la información de auditoría necesaria provoca costes en el rendimiento del sistema, y costes asociados al mantenimiento de las alteraciones de los sistemas operativos. Obtener datos excesivamente detallados dificulta la diferenciación entre las actividades originadas directamente por usuarios y aquellas originadas por programas que han tomado la identidad de un usuario Registro de Sistema El registro del sistema ("system log") es otro elemento importante a la hora de recopilar información del sistema. Es un fichero en el que se guardan los eventos generados por el sistema. El sistema operativo UNIX cuenta con una variedad importante de este tipo de registros, relacionados por un servicio común, denominado "syslog". Este servicio genera y actualiza los registros de eventos mediante el proceso syslogd. Ventajas: Aportan información muy útil a los programas de detección de intrusiones, y complementan a los datos provenientes de los registros de auditoría. Son más fáciles de revisar que los registros de auditoría de sistema. Siempre es más conveniente utilizar varias fuentes de información que una sola. Así, se pueden detectar signos de intrusiones a través de las discrepancias encontradas. Desventajas: La seguridad de los registros de sistema es uno de los puntos débiles frente a la de los de auditoría. En este sentido, los registros de sistema son menos fiables que los de auditoría. Autor: Pablo Astudillo Aguilar 26/06/

34 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Los registros de sistema son escritos por aplicaciones, más vulnerables que el subsistema de auditoría. Suelen almacenarse en directorios no protegidos del sistema, relativamente fáciles de localizar y alterar. Están escritos en texto en claro, y no en una forma más críptica como los registros de auditoría, que siempre ayuda más a detectar cambios Información de aplicaciones El nivel de sistema se supone el más robusto e inaccesible para todos salvo los más expertos. Sin embargo, los modelos de seguridad y de protección están en constante evolución, al mismo tiempo que los sistemas operativos. En el futuro, la mayoría de los datos de importancia procederán del nivel de aplicación. Uno de los ejemplos de esta realidad es el progresivo avance de los sistemas distribuidos y los sistemas orientados a objetos. En el sistema operativo Windows NT, muchos de los eventos generados por el nivel de registro de sistema operativo han migrado a almacenes de datos de aplicación. Además, casi todos los sistemas operativos comerciales soportan la entrada de registros de auditoría generados en el nivel de aplicación Fuentes de información basadas en red Los monitores basados en red son quizás los más famosos en el ámbito de la detección de intrusiones. El tráfico de red es el flujo de información tal como viaja por un segmento de red. La recopilación de datos de red tiene varias ventajas. Para empezar, utilizar como fuente de información el tráfico de red, no afecta al rendimiento del resto de las máquinas de la red. Por otra parte, el monitor puede ser transparente al resto de los miembros de la red. Esto significa que puede ser indetectable, lo que es una ventaja ya que no puede Autor: Pablo Astudillo Aguilar 26/06/

35 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones convertirse en objetivo directo de posibles intrusos. Con este propósito, existe la posibilidad de utilizar un cable de sólo recepción ("sniffing cable") para el monitor, de forma que sólo pueda recibir datos, impidiendo físicamente cualquier envío de señales. Una opción equivalente al cable de sólo recepción es el uso de un "network tap" (dispositivo de escucha de red); un dispositivo de aspecto similar a un concentrador de red, que permite a un sniffer pinchar las comunicaciones sin ser detectado. Por último, el tráfico de red puede revelar información sobre ataques que no podrían ser detectables por un monitor basado en máquina. Estos ataques podrían ser basados en paquetes malformados y algunos de denegación de servicio Paquetes de red Para extraer los paquetes de un segmento de red, un NIDS suele utilizar un dispositivo de red en modo promiscuo. Esto hace que el dispositivo genere una interrupción cada vez que detecta algún paquete en la red. Esté método es eficaz, pero tiene inconvenientes. Es útil en los casos en los que el dispositivo está situado en algún punto de la red en el que puede haber tráfico no destinado a sí mismo. Por ejemplo, en redes con switchs (conmutadores), el modo promiscuo no es efectivo, ya que el dispositivo de red sólo recibe el tráfico destinado a él. Por otra parte, un sniffer tampoco puede monitorizar conexiones hechas con un módem, puesto que utilizan distintas interfases. En la Figura 1-7 se observa a la izquierda un escenario con concentrador (hub), en el que el sniffer puede recibir todo el tráfico relacionado con las máquinas que comparten el medio. En la siguiente situación (con switch), el sniffer sólo detecta el tráfico enviado o destinado a él mismo. Por último, se ilustra un tipo de conexión que el sniffer no es capaz de interceptar. Autor: Pablo Astudillo Aguilar 26/06/

36 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones Figura 1-7. Escenarios de conexión de un sniffer Captura de paquetes en sistemas Windows Existen numerosas opciones para extraer y analizar los paquetes que pasan por un dispositivo de red utilizando estos sistemas operativos. Spynet, Iris, Windump Ethdump, Ethload, son sólo algunos de los productos que se pueden utilizar para llevar a cabo esta tarea. Con el desarrollo del "Systems Management Server" (SMS), apareció el "Microsoft Network Monitor". Este es el sniffer propuesto por Microsoft. Ofrece la capacidad de capturar paquetes de red con soporte para varios tipos de protocolos, un conjunto de filtros, y la interfaz de usuario común de Windows. También ofrece la posibilidad a una máquina remota conectarse y capturar los datos locales Captura de paquetes en sistemas UNIX Los sistemas UNIX cuentan con una infraestructura en materia de redes bastante más amplia y robusta que Windows. Esto no es así de forma arbitraria. No en vano, fueron los entornos más utilizados para desarrollar la mayoría de las tecnologías de red. El "Lawrence Berkeley National Laboratory" desarrolló el "Berkeley Packet Filter" (BPF). Este filtro utiliza dos componentes, un "network tap" (dispositivo de escucha Autor: Pablo Astudillo Aguilar 26/06/

37 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones de red) y un filtro de paquetes. Estos datos son enviados a las aplicaciones que están en modo de escucha. Entonces, el filtro procesa la información según los parámetros enviados, y muestra los datos resultantes. Hay dos aplicaciones de red destacables que utilizan BPF, y son tcpdump y arpwatch. Tcpdump es una herramienta de monitorización de red y adquisición de datos que permite realizar filtrados, recopilación de paquetes y visualización de los mismos. Arpwatch monitoriza la actividad que involucra los mapeos de direcciones IP y Ethernet, y avisa a los administradores cuando detecta nuevos registros o actividades anormales. Por otra parte, muchos monitores de red y programas de detección de intrusiones utilizan libpcap. Se trata de una librería de captura de paquetes, usada también por tcpdump. Libpcap es una interfaz independiente del sistema que permite hacer monitorizaciones de red a bajo nivel. Su portabilidad a distintas plataformas, como a Linux, que cada vez es más utilizado en entornos de monitorización de red y detección de intrusiones, es una de sus características más relevantes Limitaciones de los IDS Los siguientes son algunos de los problemas que enfrentan los IDS al intentar detectar las intrusiones: Los IDS actuales basan su funcionamiento en un esquema estático lo cual los convierte en sistemas muy ineficientes en el momento en el que un atacante codifica los datos de entrada. La base de datos de las firmas de ataques sufren los mismos inconvenientes que los antivirus, si la base de datos está desactualizada es muy probable que el sistema sea atacado sin ser detectado. 14 GONZALEZ, Diego. Sistemas de Detección de Intrusiones [en línea]. Edición Julio 2003, revisado en julio del 2003 para correcciones tipográficas. Capítulo 3. Fuentes de Información. Página 23. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

38 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones El tiempo entre el descubrimiento de un nuevo ataque y su inclusión es bastante alto, teniendo en cuenta que el tiempo entre la publicación de dicho ataque y el uso indebido por parte de un posible atacante es muy corto. Con respecto a los NIDS existen inconvenientes adicionales. Fragmentación de datos. El manejar este problema implica utilizar poder de procesamiento en la manipulación de datos, bajando el rendimiento del sistema y la probabilidad que detecte un ataque. 15 Encriptación. Es utilizada para evitar el acceso no autorizado a la información y es particularmente problemática para los sistemas de detección de intrusiones. Protocolos que son ampliamente utilizados como SSL (Secure Sockets Layer - Capa de Conexiones Segura), SSH (Secure Shell - Intérprete de comandos Seguro) o IPSec (IP Seguro) utilizado en las VPN (Virtual Private Networks - Redes Privadas Virtuales), evitan que los NIDS puedan inspeccionar el tráfico para compararlo contra las firmas de los ataques conocidos. Los payloads (datos dentro de los paquetes) encriptados convierten a estos protocolos en excelentes vehículos para que un atacante pueda evadir la detección por parte de un IDS. Velocidad de la red. Limitaciones de hardware y algoritmos de comparación ineficientes, imponen una limitación al número de paquetes que se pueden capturar y analizar dentro de un período de tiempo determinado. Una vez que éste límite es alcanzado, los IDS comienzan a "perder " paquetes (ignorar el tráfico). Pocos NIDS actualmente disponibles en el mercado pueden trabajar en redes gigabit. Desbordamiento de alarmas. Para hacer más fácil la tarea de los hackers, han aparecido herramientas que burlan los sensores de los IDS. Algunas de ellas (por ejemplo: stick) bombardean al NIDS con bases de datos de firmas de ataques, haciendo que algunos IDS desborden de falsos mensajes de alerta. Las organizaciones deben comprender claramente los riesgos que 15 TORRES, Efraín. Sistema Inmunológico para la detección de intrusos a nivel de protocolo HTTP [en línea]. Edición 1. Santafé de Bogotá. Mayo del Capítulo 5. Limitaciones de los IDS actuales. Página 22. Disponible en: pwp.007mundo.com/etorres1/articuloidshttp.pdf Autor: Pablo Astudillo Aguilar 26/06/

39 CAPITULO 1. Introducción a los Sistemas de Detección de Intrusiones encierran herramientas como esa, usados contra los NIDS y cómo responder a esas alertas. Alto coste de mantenimiento. Utilizar un NIDS, esperando obtener altos grados de efectividad, incluye una gran cantidad de mantenimiento. No se puede sencillamente instalar el software de NIDS y dejarlo funcionar desatendido. Nuevas firmas, cambios en la red, nuevo software, todos esos eventos requerirán un afinado en el NIDS. Para alcanzar la máxima efectividad, las firmas deben ser frecuentemente actualizadas, los límites deben ser ajustados para evitar falsas alarmas y los administradores deben monitorear los registros de eventos para conocer el comportamiento normal de la red en su propio entorno y poder diferenciarlo de comportamientos extraños. 16 Redes conmutadas. Los NIDS trabajan buceando en todo el flujo de tráfico que pasa por la red. Si simplemente se conecta el NIDS a un puerto normal de una red conmutada, será muy poco útil. La propia naturaleza de las redes conmutadas implica que solamente el tráfico destinado a un determinado dispositivo, es el que se envía al mismo. Existen dos maneras de enfocar esta situación. Una alternativa es conectar el NIDS a un puerto "espejado" sobre un switch apropiado. Un puerto espejado es aquel que está programado para recibir copias de todo el tráfico que fluye a través del switch o un subgrupo seleccionado del mismo. Con este enfoque, existe el problema que el ancho de banda acumulado que demanda el NIDS podría llegar a ser demasiado impactante. Una segunda opción es usar un dispositivo de interrupción de la red. Esto permite captar los paquetes que viajan en un sentido desde la conexión, pero es solamente aconsejable para la intercepción del tráfico dirigido a un solo dispositivo de la red. 16 Presentando IDS. NEX Periódico de Networking [en línea]. Edición 3. Disponible en: nex_1/seguridad/nota1.asp Autor: Pablo Astudillo Aguilar 26/06/

40 CAPITULO 2. Análisis y Diagnóstico CAPITULO 2. Análisis y Diagnóstico La segunda gran clasificación de los IDS se realiza en función de cómo actúan estos sistemas; actualmente existen dos grandes técnicas de detección de intrusiones: las basadas en la detección de usos indebidos del sistema (misuse detection), y las basadas en la detección de anomalías (anomaly detection). El funcionamiento de los IDS basados en la detección de usos indebidos presupone que es posible establecer patrones para los diferentes ataques conocidos y algunas de sus variaciones; mientras que la detección de anomalías conoce lo normal (en ocasiones se dice que tienen un conocimiento positivo ) y detecta lo que no lo es, este esquema se limita a conocer lo anormal para poderlo detectar (conocimiento negativo). El término firma en las siguientes secciones, se refiere a un grupo de condiciones observadas en el tráfico que indican algún tipo de intrusión. El algoritmo usado para detectar estas firmas podría basarse en cualquiera de las metodologías descritas en este capítulo Detección de usos indebidos Este esquema se basa en especificar, de una forma más o menos formal, las potenciales intrusiones que amenazan a un sistema y simplemente esperar a que alguna de ellas ocurra; para conseguirlo existen dos grandes aproximaciones: Comparación de patrones (Pattern Matching). Análisis de Protocolos 17 CISCO SYSTEMS. The Science of Intrusion Detection System Attack Identification [en línea]. Introduction. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

41 CAPITULO 2. Análisis y Diagnóstico Comparación de patrones En esta implementación basada en el uso de reglas de comparación de patrones o pattern matching, el detector se basa en la premisa de que el sistema llega a un estado comprometido cuando recibe como entrada el patrón de la intrusión, sin importar el estado en que se encuentre en ese momento. Dicho de otra forma, simplemente especificando patrones que denoten intentos de intrusión, el sistema puede ser capaz de detectar los ataques que sufre, sin importar el estado inicial en que esté cuando se produzca dicha detección. Actualmente, muchos de los sistemas de detección de intrusiones más conocidos (SNORT, RealSecure, etc.) están basados en el pattern matching. Utilizando una base de datos de patrones que denotan ataques, estos programas se dedican a examinar todo el tráfico que ven en su segmento de red y a comparar ciertas propiedades de cada trama observada con las registradas en su base de datos como potenciales ataques; si alguna de las tramas empareja con un patrón sospechoso, automáticamente se genera una alarma en el registro del sistema Fortalezas y Debilidades Los sistemas basados en la comparación de patrones tienen las siguientes fortalezas clave: Son muy rápidos, ya que la comparación es una tarea relativamente liviana para el procesador. Las reglas son fáciles de escribir y entender, además de muy personalizables. Existe una gran comunidad de soporte que genera firmas rápidamente para nuevas alertas. 18 VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Capítulo 18. Sistemas de detección de intrusos. Detección de usos indebidos. Página 324. Disponible en: es.tldp.org/manuales-lucas/doc-unixsec/unixsec-html/ Autor: Pablo Astudillo Aguilar 26/06/

42 CAPITULO 2. Análisis y Diagnóstico Estos sistemas se destacan en detectar ataques simples a bajo nivel, debido a que estos tienden a utilizar exploits preparados que son fáciles de reconocer. Comunican exactamente lo que ha sucedido debido a que emiten alarmas en base a eventos muy específicos. El número y tipo de eventos a monitorear se pueden reducir a esos ítems de datos necesarios para comparar un patrón. Si una organización no se preocupa acerca de los ataques a servidores WEB porque su sistema maneja únicamente un servidor mail, entonces no necesita activar todos los patrones de la base de datos. El motor de comparación de patrones tiende a ser más eficiente debido a la ausencia de cálculos de punto flotante para medidas estadísticas. Por otro lado, este método de detección tiene claras debilidades: Su rendimiento decrece dramáticamente conforme crece el grupo de firmas. Esto es particularmente problemático ya que el número de firmas usualmente crece muy rápido. Para cada ataque o exploit que es creado por intrusos, una o más nuevas reglas deben ser creadas para detectarlos. A pesar de las técnicas para normalizar los datos y reensamblar paquetes, existen incontables variaciones de los ataques que evaden la detección. Los ataques a nivel de aplicación como el Unicode y los programas de evasión mutan los shellcode (ADMutate), lo que provoca serios problemas para estos sistemas. La más leve variación en un ataque es suficiente para vencer a una firma. La única solución es más reglas, lo cual baja el rendimiento e incrementa la complejidad. Generan demasiados falsos positivos, debido eventualmente a la naturaleza simplista de sus evaluaciones y al querer compensar este hecho con demasiadas firmas. El exceso de falsos positivos puede también ser Autor: Pablo Astudillo Aguilar 26/06/

43 CAPITULO 2. Análisis y Diagnóstico ocasionado por las características particulares de un ataque, cuando son difíciles de aislar del tráfico normal. 19 Sólo son capaces de detectar lo que conocen, de forma que si se recibe un ataque desconocido para el IDS, éste no notificará ningún problema. Es algo similar a los programas antivirus, y, de igual manera, también es conveniente mantener al día la base de datos de este tipo de IDS. Aún así, son vulnerables a nuevos ataques. Algunos de los productos más populares que usan esta metodología de análisis son: Cisco NetRanger, ISS RealSecure, y Security Dynamics KSM Comparación simple de patrones La comparación simple de patrones fue el primer método implementado en detección de intrusiones. Se basa en la búsqueda de una secuencia determinada de bytes en un paquete. Como su nombre lo sugiere, este método es bastante rígido, pero simple de emplear. Un paquete entrante es comparado, byte por byte, con una firma. Esa firma podría contener una frase clave o comando que esta asociado frecuentemente con un ataque. Si se encuentra una equivalencia, se genera una alarma; de lo contrario, los datos del paquete son comparados con la siguiente firma de la lista. Una vez que todas las firmas han sido verificadas, se repite el proceso con el siguiente paquete. 20 Además de la secuencia de bytes que se busca, la mayoría de los IDS también comparan varias combinaciones de las direcciones IP origen y destino, de los puertos origen y destino y el protocolo utilizado. Con frecuencia, también es posible 19 LISTON, Kevin. Intrusion Detection FAQ-Can you explain traffic analysis and anomaly detection? Disponible en: 20 TANASE, Matt. The Great IDS Debate: Signature Analysis Versus Protocol Análisis [en línea]. SecurityFocus. Ultima actualización: Febrero 5, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

44 CAPITULO 2. Análisis y Diagnóstico afinar la firma, especificando un punto inicial y final para la inspección dentro del paquete, o una combinación particular de banderas TCP. Esto ayuda a reducir la cantidad de análisis realizado sobre cada paquete capturado, ya que mientras más específicos sean estos parámetros, menos inspecciones serán necesarias. Sin embargo, los sistemas que implementan este método suele tener dificultades al tratar con protocolos que no trabajan con los puertos de servicio (puertos entre 1 y 1023) y, en particular, los troyanos y su tráfico asociado, los cuales pueden ser cambiados a voluntad frecuentemente. 21 La estructura de una firma basada en el método simple de comparación de patrones podría ser como sigue: Si el paquete es IPv4 y TCP y el puerto destino es 2222 y los datos contienen la cadena foo, lanzar una alarma. Ventajas: Es el método más simple para detectar intrusiones. Permite correlación directa de un exploit con el patrón, es altamente específico. Alerta confiadamente sobre el patrón especificado. Es aplicable a todos los protocolos. Desventajas: Este método pueden presentar altos porcentajes de falsos positivos si el patrón no es tan único como asumió el diseñador de firmas. Se puede requerir múltiples firmas para enfrentar una sola vulnerabilidad. Múltiples herramientas de hackers inducen múltiples firmas. Usualmente, este método está limitado a la inspección de un solo paquete, por lo tanto, no se aplica bien a la naturaleza basada en flujos del tráfico de 21 CISCO SYSTEMS. The Science of Intrusion Detection System Attack Identification [en línea]. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

45 CAPITULO 2. Análisis y Diagnóstico red, tal como el tráfico HTTP. Esta limitación da popularidad a las técnicas de evasión de IDS que son fácilmente implementadas Comparación de Patrones en contexto de Conexiones Un método más sofisticado es el análisis basado en comparación de patrones en el contexto de una conexión (stateful pattern matching). Este método de desarrollo de firmas añade a la comparación de patrones el concepto de que, debido a que el flujo de red comprende más que paquetes atómicos individuales, las comparaciones deberían realizarse en contexto, dentro del estado del flujo. Esto significa que los sistemas que efectúen este tipo de análisis, deben considerar el orden de llegada de los paquetes en un flujo TCP, y deberían manejar la comparación de patrones más allá de los límites de los paquetes. Cómo afecta este escenario al ejemplo presentado en la discusión de la comparación simple de patrones? Ahora, en lugar de buscar patrones en cada paquete, el sistema tiene que mantener información del estado del flujo TCP que se esta monitoreando. Para entender la diferencia, considere el siguiente escenario: Suponga que el ataque que se está buscando es lanzado desde un cliente conectado a un servidor, y se tiene el método de comparación simple de patrones funcionando en el IDS. Si el ataque es lanzado de tal forma que en cualquier paquete TCP individual, con dirección al objetivo, sobre el puerto 2222, la cadena foo esta presente, la alarma es activada. Sin embargo, si el intruso se las arregla para que la cadena sea enviada de tal forma que fo este en el primer paquete y o en el segundo, ninguna alarma será activada. Si en lugar del método de comparación simple, se emplea el algoritmo de Stateful Pattern Matching, el sensor habrá almacenado la porción de la cadena fo y es capaz de completar la comparación cuando el cliente envía la cadena o. Ventajas: Además de las ventajas heredadas de su pariente más primitivo, se puede mencionar las siguientes: Autor: Pablo Astudillo Aguilar 26/06/

46 CAPITULO 2. Análisis y Diagnóstico Para poder emplear este método, solo se requiere un esfuerzo levemente mayor que el empleado en la comparación simple de patrones. Este método complica la tarea de las técnicas de evasión de IDS. Desventajas: A excepción de las dificultades para manejar la fragmentación de la información, presenta los mismos problemas que la comparación simple de patrones Análisis de Protocolos Este método de análisis se enfoca en revisar los datos estrictamente formateados de los protocolos en el tráfico de red. Cada paquete está envuelto en capas predefinidas de diferentes protocolos (IP, TCP, UDP, etc.). Tomando esto en cuenta, los desarrolladores de IDS implementaron motores que desenvuelven e inspeccionan estas capas, de acuerdo a los estándares del protocolo o RFC. Cada capa tiene varios campos con valores normales o esperados. Cualquier cosa que viole o esté fuera de estos estándares se considera como maliciosa, y generará una alarma. El análisis de protocolo usa un conocimiento detallado de los valores esperados o normales de los campos para descubrir tráfico malicioso. Este difiere enormemente del análisis de firmas, el cual usa características conocidas de los ataques para generar alarmas. La decodificación de los elementos del protocolo se realiza en la misma forma que lo haría un cliente o servidor durante una conversación. Cuando estos elementos son identificados, el IDS aplica las reglas definidas por los RFCs para buscar violaciones. En algunos casos, estas violaciones son encontradas mediante comparación de patrones dentro de un campo de protocolo específico, mientras que en otros se requieren técnicas más avanzadas que consideren variables tales como la longitud 22 The NSS Group. Intrusion Detection Systems, Group Test [en línea]. Edición 3. Cambridgeshire, Inglaterra. The NSS Group. Diciembre 2000, revisado en Junio Introduction, Detection Methods. Pagina 7. Disponible en: Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

47 CAPITULO 2. Análisis y Diagnóstico de un campo o el número de argumentos. Es importante notar que la comparación de patrones y el análisis de protocolos no se excluyen mutuamente. En la actualidad, además de decodificar las capas 3 y 4 de la suite TCP/IP, también se enfoca en un análisis detallado de los protocolos de la capa de aplicación. Los protocolos más populares, tales como HTTP, SMTP, TELNET, etc., pueden ser examinados en detalle en busca de violaciones e irregularidades. Actualmente, estas aplicaciones pueden anticipar las respuestas esperadas durante las etapas clave de una transacción. Por lo tanto, anomalías tales como valores inesperados, paquetes inusualmente grandes o pequeños, opciones extrañas, y todo lo que puede representar una señal de ataque, será detectado. Para ilustrar este método, se plantea el siguiente ejemplo: se sabe que el protocolo base sobre el que se realiza un ataque es el protocolo ficticio BGS; más específicamente, se asume que el ataque requiere que se pase el argumento ilegal foo en el campo Type de este protocolo. Para complicar más la situación, se asume que el campo BGS Type esta precedido por un campo de longitud variable llamado BGS Options. La lista de opciones válidas para Type es: fooh, mooh, tormer, y buildo. En este caso, los algoritmos de comparación simple de patrones o en contexto de conexión producen falsos positivos, porque la opción válida fooh contiene el patrón buscado. Además, debido a que la longitud de los campos es variable, sería imposible limitar tales falsos positivos especificando un punto de inicio y fin para la búsqueda. La única forma de comprobar que foo es enviado como argumento de Type es decodificar completamente el protocolo. Ventajas: Este método minimiza las probabilidades de falsos positivos si el protocolo está bien definido e implementado. Puede permitir correlación directa de un exploit. Puede ser más amplio y general para permitir capturar variaciones sobre un tema. Alerta confiadamente sobre la violación de las reglas de un protocolo. Autor: Pablo Astudillo Aguilar 26/06/

48 CAPITULO 2. Análisis y Diagnóstico Son mejores en términos de escalabilidad y rendimiento, cuando el grupo de reglas crece. Debido a que buscan violaciones genéricas, los motores de análisis de protocolo pueden frecuentemente detectar exploits de día cero. Desventajas: Puede inducir a altos porcentajes de falsos positivos si el RFC es ambiguo y deja a los desarrolladores la libertad para interpretar e implementar como ellos consideren correcto. Desgraciadamente, esta situación es bastante común. Se requiere más tiempo de desarrollo para implementar adecuadamente el analizador de protocolo. Puede ser bastante lento debido al pre-procesamiento requerido para la inspección avanzada del protocolo. Las reglas para estos sistemas son difíciles de escribir y entender. En muchas formas, dependen extremadamente del proveedor, debido a que se requiere un procesador para cada protocolo que será examinado. Pueden fallar eventualmente al no detectar eventos obviamente malintencionados, tales como una sesión Telnet de root, que no violan ningún protocolo El ambiente del IDS La efectividad de un IDS depende del ambiente en el que se desenvuelve. Monitorear una red grande y diversa es muy diferente que hacerlo en ambientes más pequeños y homogéneos. Los modelos de análisis de firmas se ajustan mejor a redes de tamaño medio, que buscan detectar amenazas estándar. Los administradores pueden obtener soporte en la actualización de firmas de la basta comunidad de desarrolladores que promueven esta metodología. Además, el rendimiento no es un factor crucial. Sin embargo, una red más grande y dinámica probablemente se beneficiaría de algunas de las fortalezas de los sistemas de análisis de protocolo: rendimiento, falsos Autor: Pablo Astudillo Aguilar 26/06/

49 CAPITULO 2. Análisis y Diagnóstico positivos al mínimo y alertas generalizadas. Una solución mejor, aunque más cara, sería tener una solución IDS desplegada en dos computadores, cada uno empleando un modelo diferente. Desafortunadamente, muy pocos pueden permitirse tal lujo El Futuro: Un modelo complementario Los ingenieros y programadores tras estos sistemas reconocen las obvias fortalezas y debilidades de cada método. Como se podía esperar, están intentando unir los mejores componentes de cada método, a fin de ofrecer un producto más robusto; hecho que es evidente en varias de las ofertas de IDS más recientes. Actualmente, casi todos los productos que efectúan análisis de protocolo, también realizan comparación de patrones en algún punto de la decodificación de la capa de aplicación. Existen sistemas IDS que, aún cuando realizan análisis de protocolo, también permiten al usuario crear firmas para un tráfico en particular. Similarmente, los sistemas basados en firmas están armando procesadores de aplicación para reconocer los ataques eficazmente Estudio de las Firmas de los Ataques más conocidos En esta sección se analizará la metodología de los ataques más conocidos en el ambiente de la seguridad de redes, para así obtener sus características distintivas y poder elaborar firmas que los detecten, utilizando el método de comparación de patrones simple. Estos ataques son: Escaneos de puertos IP Spoofing Denegación de Servicios (DoS) Denegación de Servicios Distribuida (DDoS) 23 TANASE, Matt. The Great IDS Debate: Signature Analysis Versus Protocol Análisis [en línea]. SecurityFocus. Ultima actualización: Febrero 5, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

50 CAPITULO 2. Análisis y Diagnóstico Antes de esto y para mejor compresión, se mencionarán algunos conceptos básicos sobre puertos y establecimiento/finalización de conexiones. Puertos Son interfases de usuario que garantizan el acceso simultáneo al módulo de TCP. Los puertos son utilizados por el kernel para identificar procesos de red y son estrictamente entidades de transporte (capa 4 del modelo OSI). Junto a una dirección IP, un puerto TCP forma lo que se conoce como extremo de una comunicación de red. De hecho, en un momento dado cualquier conexión de Internet puede ser descrita por 4 números: la dirección IP de inicio y su puerto, y la dirección IP de destino y el correspondiente puerto destino. Los servidores suelen ceñirse a puertos corrientes para que puedan ser localizados a través de puertos estándar en sistemas diferentes. Por ejemplo, el daemon de rlogin se encuentra en el puerto TCP 513. Establecimiento de una conexión TCP Para poder intercambiar datos usando TCP, los hosts deben establecer una conexión. TCP establece una conexión siguiendo un proceso de 3 pasos llamado three-way handshake (saludo de tres direcciones). El proceso, como se muestra en la Figura 2-1, es el siguiente: Figura 2-1. Esquema del "saludo de tres direcciones" 1. El programa cliente le comunica al servidor que quiere iniciar una conexión. Este es el único propósito del indicador SYN. El cliente le está diciendo al servidor que el campo de secuencia numérica es válido, y que debería ser Autor: Pablo Astudillo Aguilar 26/06/

51 CAPITULO 2. Análisis y Diagnóstico comprobado. El cliente configurará el campo de secuencia numérica en la cabecera TCP a su ISN (Initial Sequence Number, número inicial de la secuencia). 2. El servidor, al recibir este segmento, responderá con su propio ISN (por lo tanto el flag SYN está activado) y una autentificación (ACK) del primer segmento enviado por el cliente (que será el ISN_del_cliente + 1). Si el servidor ha sido incapaz o renuente a aceptar la conexión TCP del cliente, tendría que responder con un paquete RST/ACK (Reset Acknowledgement), o con un paquete ICMP Port Unreachable, para informar al cliente que su solicitud de conexión ha sido negada. 3. Si el cliente recibe el paquete SYN/ACK, entonces ACKea (autentifica) el ISN del servidor. Ahora ya puede tener lugar la transferencia de datos. 24 Finalización de una conexión TCP Al igual que la conexión TCP debe ser establecida de una forma correcta, la finalización (sin errores) de una conexión TCP también sigue unos pasos: Figura 2-2. Finalización de una conexión TCP 1. Tras una conexión con envío bidireccional de datos, el HOST A indica el deseo de finalizar la conexión mediante el envío de un paquete con el flag FIN levantado. 24 FERNANDEZ, Alberto y CRESPO, Abel. IP Spoofing [en línea]. Ultima revisión: Junio 1, Capítulo 5. Establecimiento de una conexión TCP. Página 17. Disponible en: ip-poofing.tinusi.com/es/ Autor: Pablo Astudillo Aguilar 26/06/

52 CAPITULO 2. Análisis y Diagnóstico 2. El HOST B responde con un paquete con el flag ACK levantado para confirmar la recepción del paquete FIN, tras lo cual termina de enviar los paquetes que tuviera pendientes para dar por finalizada la conexión. 3. Cuando todos son enviados, el HOST B envía un paquete con el flag FIN levantado al HOST A. 4. Este responde con un paquete con el flag ACK levantado para confirmar la recepción, y ambos consideran la conexión finalizada Escaneo de Puertos El escaneo de puertos es seguramente la técnica de hacking más usada en el mundo; en cualquier ataque medianamente bien planificado, uno de los primeros pasos es el escaneo metódico de los puertos de la máquina objetivo. Esta técnica permite a los intrusos elaborar una lista de vulnerabilidades potenciales y obtener otros detalles acerca del sistema objetivo, como el sistema operativo instalado en cada host o ciertas características de la arquitectura de la red. Analizando qué puertos están abiertos en un sistema, el intruso puede buscar agujeros de seguridad en cada uno de los servicios ofrecidos: cada puerto abierto en una máquina es una potencial puerta de entrada a la misma. Clasificación de los Escaneos de puertos Existen diferentes aproximaciones para clasificar los escaneos de puertos, tanto en función de las técnicas seguidas como en función de a qué sistemas o puertos concretos va dirigido. 25 Death Master (Seudónimo). Sabuesos en la Red: El escaneo de puertos [en línea]. Capítulo 1. Aspectos importantes en conexiones TCP. Página 9. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

53 CAPITULO 2. Análisis y Diagnóstico Según el objetivo: Escaneo horizontal: el intruso busca la disponibilidad de determinado servicio en diferentes máquinas de una red. Escaneo vertical: el intruso sólo escanea puertos de una máquina, suele denotar su interés en ese host concreto. o Si comprueba todos los puertos del sistema, al escaneo se le denomina vanilla. o Si sólo lo hace contra determinados puertos o rangos, se le denomina strobe (en referencia al programa del mismo nombre). 26 Escaneo en bloque: una combinación de escaneo vertical y horizontal. Estos patrones sobresalen cuando se elabora una gráfica de los puertos destino contra direcciones IP destino. El tamaño de la memoria utilizada puede ser calculado sumando las combinaciones de IP/puerto usadas en el escaneo. Este tamaño puede ser una métrica sobre cuan difícil será detectar un escaneo en bloque. Claramente, un escaneo NMAP sobre un servidor será más fácil de detectar que un escaneo del puerto 53 sobre 4 máquinas en la red. Según la técnica utilizada En base a las técnicas utilizadas, se puede dividir los escaneos en tres grandes familias: abiertos, medio-abiertos y silenciosos Escaneos abiertos TCP connect() Esta técnica es quizá la más común en cualquier software de escaneo de puertos. Se basa en el establecimiento de una conexión TCP completa mediante el procedimiento three-way handshake. 26 VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Capítulo 17. Ataques remotos. Escaneos de Puertos. Página 296. Disponible en: es.tldp.org/manuales- LuCAS/doc-unixsec/unixsec-html/ Autor: Pablo Astudillo Aguilar 26/06/

54 CAPITULO 2. Análisis y Diagnóstico La técnica consiste en usar la llamada connect() de TCP para intentar establecer una conexión con cada uno de los puertos del host a escanear. Si la conexión se establece, el puerto está abierto (escuchando conexiones). host local ---[SYN]---> [O] Puerto TCP abierto en el host remoto host local <--[SYN/ACK]-- [O] Puerto TCP abierto en el host remoto host local ---[ACK]---> [O] Puerto TCP abierto en el host remoto Si la respuesta es un aviso de cierre de conexión (RST), el puerto está cerrado; host local ---[SYN]---> [X] Puerto TCP cerrado en el host remoto host local <---[RST]--- [X] Puerto TCP cerrado en el host remoto En caso de no recibir respuesta, se deduce que el puerto está silencioso. host local ---[SYN]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Fortalezas Es extremadamente rápido, pues puede realizarse de forma paralela para distintos puertos mediante el uso de varios sockets. Es fácil de implementar. Es fiable. No se necesita de ningún privilegio especial en la máquina atacante. Debilidades Es llamativo en exceso, por lo que son muy sencillos de detectar y detener. Resulta a todas luces llamativo establecer cientos o miles de conexiones en un margen de pocos segundos. Además, al realizarse intentos completos de conexión, cualquier sistema guardará registros. Reverse Ident Se basa en explotar el Protocolo de Identificación que está definido en el RFC-1413 Identification Protocol. El fin del protocolo Ident es proporcionar información acerca de la identidad del usuario de una conexión TCP, para lo cual existe un demonio a la Autor: Pablo Astudillo Aguilar 26/06/

55 CAPITULO 2. Análisis y Diagnóstico escucha (generalmente en el puerto 113) al que, enviando una consulta en una determinada estructura (definida en el RFC), devuelve la información del usuario. Mediante Ident inverso es el intruso el que establece una conexión con el host remoto y luego pregunta a Ident por su usuario. De cara al host remoto, el usuario de esa conexión seguirá siendo el usuario de su sistema, aunque la conexión haya sido establecida por el intruso. Dado que esta técnica requiere que se establezca completamente una conexión TCP, su base es el escaneo TCP connect(). Una vez establecida la conexión con el puerto en el host remoto, el intruso redirige una consulta al puerto Ident, obteniendo así información sensible como quién es el usuario tras esa conexión, sus entidades, objetos y procesos. host local ---[SYN]---> [O] Puerto TCP abierto en el host remoto host local <--[SYN/ACK]-- [O] Puerto TCP abierto en el host remoto host local ---[ACK]---> [O] Puerto TCP abierto en el host remoto host local ---[query]---> [O] Puerto TCP/113 abierto en el host remoto host local <---[Ident]--- [O] Puerto TCP/113 abierto en el host remoto host local ---[SYN]---> [X] Puerto TCP cerrado en el host remoto host local <---[RST]--- [X] Puerto TCP cerrado en el host remoto host local ---[SYN]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Los intrusos utilizan este escaneo con el objetivo primario de encontrar demonios ejecutándose con privilegios de root. Luego, tratarán de atacar al servicio por medio de desbordamientos de pila u otros métodos, para obtener acceso con privilegios. Sin embargo, no todos los hosts corren el servicio de Ident, y de los que lo hacen, muchos usan algún tipo de sistema de identificación. Fortalezas Es rápido. No requiere privilegios adicionales. Devuelve información vital de los servicios. Autor: Pablo Astudillo Aguilar 26/06/

56 CAPITULO 2. Análisis y Diagnóstico Debilidades Fácilmente detectable Escaneos medio-abiertos TCP SYN Esta técnica es el escaneo medio abierto por excelencia, es parecida a la técnica TCP connect, con la importante salvedad de no establecer completamente las conexiones. En primer lugar, el intruso envía un paquete SYN que finge intentar establecer una conexión y espera la respuesta. Si la respuesta es un paquete SYN/ACK, el puerto está abierto. host local ---[SYN]---> [O] Puerto TCP abierto en el host remoto host local <--[SYN/ACK]-- [O] Puerto TCP abierto en el host remoto host local ---[RST]---> [O] Puerto TCP abierto en el host remoto Si la respuesta es un paquete RST, el puerto está cerrado. host local ---[SYN]---> [X] Puerto TCP cerrado en el host remoto host local <---[RST]--- [X] Puerto TCP cerrado en el host remoto Si no se recibe respuesta se asume que está silencioso. host local ---[SYN]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA En el caso de que el puerto esté abierto y el intruso recibe el paquete SYN/ACK (es decir, están completos dos de los tres pasos del three-way handshake), este no responde con un paquete ACK como se esperaría, sino que envía un paquete RST. Esto evita que se complete el inicio de conexión y, por tanto, evita que el sistema registre el suceso como un intento de conexión. Fortalezas En sistemas sin protección específica de firewall o IDS, este escaneo suele pasar desapercibido. Ofrece resultados bastante precisos. Autor: Pablo Astudillo Aguilar 26/06/

57 CAPITULO 2. Análisis y Diagnóstico Debilidades Un sistema con un firewall o un IDS (aunque algunos muy básicos no) lo detectará e identificará como escaneo de puertos. Una característica importante de este escaneo es que requiere elevados privilegios en el sistema para poder lanzarlo, debido a que este tipo de paquetes usan sockets TCP raw. Por tanto, solo el root puede lanzar escaneos TCP SYN. Escaneo Zombie Este tipo de escaneo es también conocido como Dumb scan, IP ID Header scan, e Idle scan. Su funcionamiento es bastante ingenioso y basa su técnica en particularidades de la pila TCP/IP de la mayoría de los sistemas operativos. Se realiza generalmente basándose en la técnica del escaneo SYN. Para que un intruso pueda aplicar esta técnica, debe encontrar un host zombie (dummy host, dumb host) en la red objetivo. Un host zombie es aquel que, estando online, tiene tráfico muy bajo o nulo. Por tanto, en este escaneo participan tres hosts: hosta (intruso), hostb (host zombie) y hostc (host remoto a escanear). El método consiste en enviar al hostc un paquete SYN falseado (ip spoofing) con dirección origen hostb. El comportamiento de hostc será parecido al caso de un escaneo SYN estándar: hostb <---[SYN/ACK]--- [O] Puerto TCP abierto en hostc hostb <---[RST/ACK]--- [X] Puerto TCP cerrado en hostc Así pues, hostb se encontrará con un paquete que no esperaba (él no ha lanzado ningún intento de conexión). La reacción de hostb viene dada por su implementación de la pila TCP/IP y depende del paquete recibido: hostb <---[SYN/ACK]--- [O] Puerto TCP abierto en hostc hostb ---[RST]---> [O] Puerto TCP abierto en hostc Autor: Pablo Astudillo Aguilar 26/06/

58 CAPITULO 2. Análisis y Diagnóstico hostb <---[RST/ACK]--- -SIN RESPUESTA [X] Puerto TCP cerrado en hostc De esta forma, si el puerto escaneado en hostc está abierto, se fuerza al hostb a enviar un paquete de respuesta, mientras que si el puerto de hostc está cerrado, hostb ignorará el paquete RST/ACK y no enviará nada. Obviamente, en el caso de que el puerto de hostc esté silencioso, no habrá ningún tipo de envío de tráfico. El intruso tendrá conocimiento de las flags que fueron enviadas entre hostc y hostb, desde su hosta, ya que durante todo este proceso, mantendrá un ping en paralelo constante con hostb. Si el puerto de hostc está abierto (hostc manda SYN/ACK a hostb y éste responde con RST): 60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms 60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+3 win=0 time=80 ms 60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+2 win=0 time=83 ms Si el puerto de hostc está cerrado (hostc manda RST/ACK y hostb no responde) ó el puerto de hostc está silencioso (no envía nada): 60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms 60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+1 win=0 time=80 ms 60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+1 win=0 time=83 ms En conclusión, el intruso puede asumir que en caso de que el incremento de ID sea mayor en un determinado momento, esto indica que el puerto escaneado estaba abierto. Este complejo método de escaneo es muy ingenioso, porque de cara a hostc, el escaneo provino de hostb, y de cara a hostb, el intruso solamente hacía ping. Autor: Pablo Astudillo Aguilar 26/06/

59 CAPITULO 2. Análisis y Diagnóstico Escaneos silenciosos Por escaneos silenciosos (stealth scanning) se conoce a una familia de técnicas de escaneo que cumplen alguna de las siguientes condiciones: Eludir firewalls o listas de control de acceso. No ser registradas por sistemas de detección de intrusiones, ni orientados a red ni en el propio host escaneado. Simular tráfico normal y real para no levantar sospechas ante un analizador de red. Estos escaneos operan usando valores de banderas ilegales que pueden evadir algunos filtros de paquetes simples. TCP FIN Se trata del escaneo silencioso más conocido, es uno de los más discretos dentro de las técnicas convencionales. Se apoya en una particularidad de los estándares internacionales de TCP/IP. A la hora de realizar el escaneo, el intruso envía un paquete FIN al puerto del host destino que desea escanear. Los estándares de TCP/IP dicen que al recibir un paquete FIN en un puerto cerrado, se ha de responder con un paquete RST. Así pues: Si la respuesta es un paquete RST, el puerto está cerrado. host local ---[FIN]---> [X] Puerto TCP cerrado en el host remoto host local <---[RST]--- [X] Puerto TCP cerrado en el host remoto En caso de no recibir respuesta (se ignora el paquete FIN) el puerto puede encontrarse abierto o silencioso. host local ---[FIN]---> [O] Puerto TCP abierto en el host remoto -SIN RESPUESTA host local ---[FIN]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Esto supone uno de los principales inconvenientes del escaneo TCP FIN para los intrusos, ya que los puertos que figuran como abiertos, pueden estar en realidad en Autor: Pablo Astudillo Aguilar 26/06/

60 CAPITULO 2. Análisis y Diagnóstico estado silencioso (un puerto silencioso, por definición, ignora cualquier paquete recibido). Así pues, este tipo de escaneos no ofrece resultados fiables. Fortalezas Estos escaneos pasan desapercibidos en la gran mayoría de los firewalls, al no intentar establecer ninguna conexión. Debilidades En los sistemas Windows, un puerto cerrado ignora los paquetes FIN, por lo que escanear un sistema de este tipo con SYN FIN generará una enorme lista de puertos abiertos, aunque realmente estén cerrados o silenciosos. Escaneo ACK La mayoría de las técnicas de escaneo permiten identificar con exactitud los puertos abiertos o cerrados, pero generalmente los puertos silenciosos no se pueden identificar con claridad. El escaneo ACK está destinado a identificar de forma precisa cuándo un puerto se encuentra en estado silencioso. Esta técnica es usada también para escanear hosts que están detrás de un firewall que bloquee los intentos de conexión (paquetes SYN). Su funcionamiento se basa en el envío de paquetes ACK con números de secuencia y confirmación aleatorios. Cuando el objetivo recibe el paquete: Si el puerto está abierto, responderá con un paquete RST, pues no identificará la conexión como suya: host local ---[ACK]---> [O] Puerto TCP abierto en el host remoto host local <---[RST]--- [O] Puerto TCP abierto en el host remoto Si el puerto está cerrado, responderá con un paquete RST: host local ---[ACK]---> [X] Puerto TCP cerrado en el host remoto host local <---[RST]--- [X] Puerto TCP cerrado en el host remoto Si no se obtiene respuesta, se identifica el puerto como filtrado (puerto silencioso). host local ---[ACK]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Autor: Pablo Astudillo Aguilar 26/06/

61 CAPITULO 2. Análisis y Diagnóstico Generalmente, los intrusos realizan escaneos ACK como apoyo a un escaneo anterior, para determinar los puertos silenciosos y poder identificar, mediante una combinación de técnicas, el estado real de todos ellos. Por ejemplo, ante un host con un firewall que bloquee intentos de conexión (SYN), un intruso puede realizar un FIN scan para determinar los puertos cerrados, y después un ACK scan para determinar qué puertos están abiertos y cuáles silenciosos. Fortalezas Es difícil de registrar por parte de los detectores de intrusos. Debilidades Se basa en el código de red de BSD, por lo que es dependiente del operativo escaneado. Escaneo NULL Esta técnica tiene muchos puntos en común con el escaneo FIN. Su funcionamiento base es el mismo: se envía un paquete TCP malformado, con todos los flags desactivados, y se interpreta la respuesta: Si la respuesta es un paquete RST, el puerto destino está cerrado: host local ---[ ]--->[X] Puerto TCP cerrado en el host remoto host local <--[RST]-- [X] Puerto TCP cerrado en el host remoto En caso de no recibir respuesta, se trata de un puerto abierto o silencioso. host local ---[ ]--->[O] Puerto TCP abierto en el host remoto -SIN RESPUESTA host local ---[ ]--->[~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Fortalezas La ventaja frente al escaneo FIN radica en que ciertos firewalls vigilan los paquetes de finalización de conexión además de los de establecimiento, de forma que el escaneo nulo podrá realizarse allí dónde el FIN no sería posible. Autor: Pablo Astudillo Aguilar 26/06/

62 CAPITULO 2. Análisis y Diagnóstico Debilidades Aunque en principio este método sería aplicable a cualquier pila TCP/IP, la implementación incorrecta que de la misma hacen algunos operativos (entre ellos HP/UX o IRIX) hace que en ocasiones se envíen bits RST también desde los puertos abiertos, lo que proporciona a los intrusos demasiados falsos positivos. Escaneo XMAS El escaneo XMAS se basa también en el principio de la respuesta RST por parte de un puerto cerrado, al recibir un paquete incorrecto (como el escaneo FIN). En el caso del escaneo XMAS, se trata de un paquete con los flags FIN, URG y PSH activados (aunque ciertas implementaciones activan FIN, URG, PSH, ACK y SYN e incluso algunas activan todos los flags, también denominados escaneos árbol de navidad ). Si el puerto está cerrado devolverá un RST al intruso: host local ---[XMAS]--> [X] Puerto TCP cerrado en el host remoto host local <--[RST]---- [X] Puerto TCP cerrado en el host remoto Si el puerto está abierto, el núcleo del sistema operativo eliminará la trama, ya que evidentemente la considera una violación del three-way handshake. host local ---[XMAS]---> [O] Puerto TCP abierto en el host remoto -SIN RESPUESTA host local ---[XMAS]---> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Como antes, este método puede generar demasiados falsos positivos a los intrusos, y además sólo es aplicable contra máquinas Unix debido a que está basado en el código de red de BSD. Podría decirse que es lo contrario del escaneo NULL, pero logrando el mismo efecto. Al igual que el escaneo NULL, se usa bajo ciertas circunstancias en las que el escaneo FIN no es posible; y también comparte con éstos sus particularidades. Autor: Pablo Astudillo Aguilar 26/06/

63 CAPITULO 2. Análisis y Diagnóstico Escaneo SYN/ACK Este tipo de escaneo tiene una base parecida a los anteriormente citados FIN, NULL y XMAS, pero con la sustancial diferencia de que en este caso los paquetes malformados fingen ser un error en la transacción de una conexión legítima. Mediante esta técnica, un intruso envía un paquete SYN/ACK al puerto que desea escanear en el host remoto: Si el puerto está cerrado, lo considera un error, y responde con un paquete RST para finalizar la conexión. host local ---[SYN/ACK]--> [X] Puerto TCP cerrado en el host remoto host local <--[RST] [X] Puerto TCP cerrado en el host remoto En caso de estar abierto o silencioso, simplemente ignora el paquete y no emite ninguna respuesta. host local --[SYN/ACK]--> [O] Puerto TCP abierto en el host remoto -SIN RESPUESTA host local --[SYN/ACK]--> [~] Puerto TCP silencioso en el host remoto -SIN RESPUESTA Fortalezas Este tipo de escaneo evade la mayoría de firewalls e IDS sencillos Debilidades Falta de fiabilidad a la hora de determinar los puertos abiertos o silenciosos. Elevado número de falsos positivos que pueden generar: sólo se debe pensar en los múltiples motivos que pueden existir para que un sistema no responda ante una petición SYN+ACK: desde listas de control de accesos en los routers o firewalls hasta simples timeouts. Autor: Pablo Astudillo Aguilar 26/06/

64 CAPITULO 2. Análisis y Diagnóstico Escaneo UDP Esta técnica, frente a las demás orientadas a TCP, está orientada al protocolo UDP y sus puertos. Servicios como el rpcbind de Solaris, TFTP, SNMP, NFS, etc. usan UDP como protocolo de transferencia. El sistema de escaneo consiste en enviar un paquete UDP vacío (0 bytes de datos) al puerto que se desea escanear. Si el puerto está cerrado, el sistema responderá con un paquete ICMP de tipo 3 (destino inalcanzable). host local ---{UDP}---> {X} Puerto UDP cerrado en el host remoto host local <-- ICMP #3 --- {X} Puerto UDP cerrado en el host remoto En caso de no responder, el puerto puede estar abierto o silencioso. host local ---{UDP}---> {O} Puerto UDP abierto en el host remoto -SIN RESPUESTA host local ---{UDP}---> {~} Puerto UDP silencioso en el host remoto -SIN RESPUESTA Para los intrusos, este sistema puede presentar un grave problema de carencia de velocidad según el sistema al que se aplique, y es que en el RFC-1812 Requirements for IP version 4 routers se recomienda limitar la capacidad de generación de mensajes ICMP de error. En sistemas Linux, esta limitación está fijada en unos 20 mensajes por segundo. Sistemas como Solaris son más estrictos y tiene la limitación fijada en 2 por segundo. Fortalezas Windows no tiene ninguna limitación prefijada. Un escaneo UDP a un sistema Windows resulta extremadamente rápido como consecuencia de ello. Debilidades Estos ataques son muy sencillos de detectar y evitar tanto en un sistema de detección de intrusiones como en los núcleos de algunos Unix. Autor: Pablo Astudillo Aguilar 26/06/

65 CAPITULO 2. Análisis y Diagnóstico UDP no es un protocolo orientado a conexión (como lo es TCP), por lo que la pérdida de datagramas puede dar lugar a un elevado número de falsos positivos IP Spoofing IP spoofing es una de las formas más comunes de camuflarse en Internet. Con este método, un intruso obtiene acceso no autorizado a un computador o red, haciendo parecer que un mensaje malicioso ha llegado desde una máquina en la que se confía, falsificando la dirección IP de esta máquina. El concepto del IP spoofing fue discutido inicialmente en ambientes académicos en los 80 s. Por algún tiempo, su conocimiento fue únicamente teórico, hasta que Robert Morris, padre de quién escribió el primer gusano de Internet en 1988, descubrió una debilidad de seguridad en el protocolo TCP conocida como predicción de secuencia. En Abril de 1989 un artículo titulado "Security Problems in the TCP/IP Protocol Suite" de S.M. Bellovin de los laboratorios de AT&T Bell, fue el primero en identificar el IP Spoofing como un riesgo real a las redes de computadoras. Bellovin describe cómo Robert Morris Jr., creador del infame Internet Worm, dedujo la forma en que TCP crea los números de secuencia y falsificó una secuencia de paquetes TCP. Este paquete TCP incluía la dirección destino de su víctima y, usando IP spoofing, Morris fue capaz de obtener acceso al root del sistema atacado sin un ID de usuario o contraseña. 27 Mientras la popularidad de tales intrusiones ha decrecido debido a la desaparición de los servicios que explotaban, el spoofing aún puede ser usado y necesita ser atendido por todos los administradores de seguridad. 27 FERNANDEZ, Alberto y CRESPO, Abel. IP Spoofing [en línea]. Ultima revisión: Junio 1, Capítulo 2. Breve historia del IP Spoofing. Página 2. Disponible en: ip-spoofing.tinusi.com/es/ Autor: Pablo Astudillo Aguilar 26/06/

66 CAPITULO 2. Análisis y Diagnóstico Sustento técnico del IP Spoofing Para entender completamente el porque estos ataques son posibles, se debe examinar la estructura de la suite de protocolos TCP/IP. Internet Protocol (IP) El Internet Protocol (RFC-791) mantiene dos y sólo dos funciones: define un datagrama que puede ser enviado a través de Internet, y proporciona unos medios para fragmentar datagramas en paquetes y reensamblar paquetes en el datagrama original. Cita del RFC-791: El Internet Protocol está específicamente limitado en alcance a proporcionar las funciones necesarias para entregar un paquete de bits (un datagrama de Internet) de una fuente a un destino sobre un sistema de redes interconectadas. No hay ningún mecanismo para aumentar la fiabilidad de datos end-to-end, control de flujo, secuenciamiento, u otros servicios comúnmente encontrados en los protocolos host-a-host. Las siguientes son algunas propiedades significativas de este protocolo que se deben tener especialmente en cuenta: IP es el protocolo más empleado de todos los protocolos TCP/IP ya que casi todo el tráfico TCP/IP está encapsulado en datagramas IP. Su trabajo es el de enrutar paquetes de la red y no ofrece ningún mecanismo de comprobación (es un protocolo sin conexión ). Es decir, IP simplemente envía datagramas y confía en que lleguen intactos a su destino. Si no lo hacen, IP puede intentar enviar un mensaje ICMP de error al origen, aunque, por supuesto, este paquete también puede extraviarse. Se debe recordar que ICMP significa Internet Control Message Protocol, y se utiliza para informar sobre las condiciones en las que se encuentra una red y sobre los errores que se van produciendo. IP no mantiene ninguna información sobre el estado de la conexión. Cada datagrama IP es enviado sin ninguna relación con el último enviado o el siguiente a enviar. Autor: Pablo Astudillo Aguilar 26/06/

67 CAPITULO 2. Análisis y Diagnóstico Un datagrama IP posee dos campos de encabezamiento de 32 bits para la información de las direcciones IP (origen y destino) Transmission Control Protocol (TCP) TCP es un protocolo orientado a la conexión, el protocolo de transporte en el que se puede confiar plenamente dentro del sistema TCP/IP. Orientado a la conexión significa que dos hosts que quieran intercambiar datos deben establecer previamente una conexión. La seguridad se consigue a través de diferentes modos, pero los dos que son de interés en este momento son: secuenciación de datos e identificación. TCP asigna números secuenciales a cada segmento e identifica todos los segmentos de datos recibidos desde el otro extremo (revisa la secuencia de números, no los segmentos en sí). Estas características hacen que TCP sea mucho más difícil de adulterar que IP. Números secuenciales, identificaciones y otras indicaciones Dado que TCP posee una seguridad bastante aceptable, debe ser capaz de recuperar datos perdidos, duplicados, o fuera de servicio. Asignando una secuencia de números a cada byte transmitido, y requiriendo una identificación para cada uno recibido del extremo opuesto, TCP puede garantizar una transmisión sin errores. El extremo receptor utiliza la secuencia de números para asegurar el orden correcto de los datos y eliminar bytes duplicados. Los números secuenciales del TCP se pueden imaginar como contadores de 32 bits. Se encuentran en un rango desde el 0 hasta el Cada byte de datos intercambiado en una conexión va secuenciado. El campo del número secuencial en la cabecera TCP contendrá el número secuencial correspondiente al primer byte de datos en el segmento TCP. Autor: Pablo Astudillo Aguilar 26/06/

68 CAPITULO 2. Análisis y Diagnóstico El campo del número de identificación (ACK) en la cabecera TCP muestra el valor del siguiente número secuencial esperado, y también identifica todos los datos hasta este número de ACK menos uno. Para el control del flujo, TCP envía un paquete para decirle al otro extremo cuántos datos puede almacenar. Dado que este paquete es de 16 bits, se puede notificar un máximo de bytes. El objetivo de este método es enviar una notificación desde un TCP al otro sobre la amplitud de la secuencia de números a emplear, de manera que sea aceptable. Otros indicadores en la cabecera TCP a mencionar son RST (reset), PSH (push) y FIN (finish). Si se recibe un RST, se corta inmediatamente la comunicación. Los RST se envían normalmente cuando un extremo recibe un segmento que simplemente no tiene relación con la conexión que está establecida. El indicador PSH le dice al receptor que pase tan pronto como sea posible todos los datos que se han ido almacenando a la aplicación correspondiente. El indicador FIN es la manera en que una aplicación comienza el amable cierre de la conexión (el corte de una conexión es un proceso de 4 direcciones). Cuando un extremo recibe un FIN, lo ACKea (autentifica) y ya no espera recibir más datos (sin embargo el envío es todavía posible) Consecuencias del diseño TCP/IP Claramente, es muy fácil disfrazar una dirección fuente manipulando la cabecera IP. Esta técnica es usada por obvias razones y es empleada en los ataques discutidos en la siguiente sección. Otra consecuencia, específica a TCP, es la predicción de los números de secuencia, lo que puede conducir a secuestros de sesión o suplantación de hosts. 28 daemon9 / route / infinity [Seudónimo]. IP-SPoofing demystified. Phrack Magazine [en línea]. Volumen 7, Número 48. Junio Sección I. Información Previa. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

69 CAPITULO 2. Análisis y Diagnóstico La infraestructura de Internet consiste principalmente en un conjunto de computadoras de entrada (gateways) y enrutadores de paquetes (routers). Estos sistemas tienen múltiples interfases hardware. Mantienen tablas de enrutamiento para decidir por qué interfaz de salida enviar un paquete, basándose en la interfaz de entrada por el que llegó, y la dirección IP destino que en él se especifica. Cuando un paquete falsificado llega a un elemento de la infraestructura, éste dirigirá el paquete fielmente hacia la dirección de destino, exactamente como lo habría hecho con un paquete legítimo Ataques spoofing Existe un pequeño número de variaciones de los tipos de ataque que emplean el IP spoofing. Aunque algunos están relativamente caducos, otros son muy relevantes en los temas de seguridad actual. Spoofing No-Ciego Este tipo de ataques ocurren cuando el intruso está en la misma subred que la víctima. Los números de secuencia y reconocimiento pueden ser capturados, eliminando la dificultad potencial de calcularlos con precisión. La amenaza más grande del spoofing en este caso es el secuestro de sesión. Esto se logra corrompiendo el flujo de datos de una conexión establecida, para luego reestablecerla utilizando los números correctos de secuencia y reconocimiento con la máquina atacada. Usando esta técnica, un intruso podría efectivamente evitar cualquier medida de autenticación para construir la conexión. Spoofing Ciego Este es un ataque más sofisticado, debido a que los números de secuencia y reconocimiento son inalcanzables. Los intrusos, a fin de superar este obstáculo, 29 FERNANDEZ, Alberto y CRESPO, Abel. IP Spoofing [en línea]. Ultima revisión: Junio 1, Capítulo 3. Introducción al IP Spoofing. Página 3. Disponible en: ip-spoofing.tinusi.com/es/ Autor: Pablo Astudillo Aguilar 26/06/

70 CAPITULO 2. Análisis y Diagnóstico envían varios paquetes hacia la máquina objetivo para muestrear los números de secuencia. Aunque en la actualidad no es el caso, los computadores en el pasado usaban técnicas básicas para generar números de secuencia. Era relativamente fácil descubrir la fórmula exacta, estudiando los paquetes y sesiones TCP. En la actualidad, la mayoría de los sistemas operativos implementan la generación de números de secuencia randómicos, dificultando la tarea de predecirlos con exactitud. Sin embargo, en caso de que los números de secuencia fueran comprometidos, sería posible enviar datos hacia el objetivo. Varios años atrás, muchas máquinas usaban servicios con autenticación basada en host (es decir: Rlogin). Un ataque cuidadosamente elaborado podía crear una nueva cuenta de usuario, ciegamente, habilitando el acceso total para el intruso, quien estaba suplantando a un host de confianza. Ataque Man in the middle Los tipos de spoofing anteriores son formas de la violación común de seguridad conocida como ataque man in the middle (hombre en el medio). En estos ataques, la parte maliciosa intercepta una comunicación legítima entre dos partes amigas. Entonces, el host malicioso controla el flujo de comunicación y puede eliminar o alterar la información enviada por uno de los participantes originales, sin que se entere ninguno de los dos. De esta forma, un intruso puede engañar a la víctima, descubriendo información confidencial, mediante la falsificación de la identidad del emisor original, quien es supuestamente confiable para el host destino. Ataques de Denegación de servicios El IP spoofing es casi siempre usado en lo que es actualmente uno de los ataques más difíciles de bloquear: ataques de denegación de servicios o DoS. En estos ataques, los crackers se interesan únicamente en el consumo del ancho de banda y recursos de la red objetivo, inundando a la víctima con tantos paquetes como sea posible, en un corto intervalo de tiempo. A fin de prolongar la efectividad del ataque, falsean la dirección IP fuente para hacer que el rastreo y bloqueo del DoS sea Autor: Pablo Astudillo Aguilar 26/06/

71 CAPITULO 2. Análisis y Diagnóstico mucho más complicado. Cuando múltiples hosts comprometidos están participando en el ataque, todos enviando tráfico falseado, la tarea de bloquear rápidamente este tráfico es realmente un desafío. En la sección se analizarán varios de los ataques DoS más conocidos y utilizados en los últimos años, que se apoyan en mayor o menor medida en el IP spoofing Defensa contra el Spoofing Con la actual tecnología IP es imposible eliminar los paquetes falsificados, pero sí se puede evitar que circulen. Aunque para esta solución hay que tener en cuenta que individualmente poco se puede hacer para conseguirlo, sin embargo, como comunidad sería perfectamente factible. En lugar de que todos los elementos de la infraestructura redirijan todos y cada uno de los paquetes que le llegan, cada elemento de la infraestructura debería tener una simple regla: Dirigir sólo paquetes que podrían venir legítimamente de la interfaz por la que el paquete ha llegado. Esto puede parecer complicado, pero realmente no lo es. De hecho, la tecnología para hacer esto ya existe, y siempre ha existido, es lo que conocemos como: filtrado de paquetes. Virtualmente, cada router y gateway que hoy existe permite el filtrado de paquetes basado en su interfaz de entrada, dirección de origen y dirección destino. Éste es un componente necesario para su funcionamiento y es la base para la forma en que se dirigen todos los paquetes. El único cambio que debería ser hecho es en estos routers y gateways, y sería forzar a las estructuras de red a que estén legítimamente en su lugar. En otras palabras, los routers y gateways deben negarse a dirigir paquetes ridículos. Aquí están algunos de los ejemplos más simples de paquetes malintencionados conocidos: Autor: Pablo Astudillo Aguilar 26/06/

72 CAPITULO 2. Análisis y Diagnóstico La dirección IP únicamente se usa para enrutamiento interno de paquetes desde un host a si mismo. No hay ningún datagrama legítimo que deba atravesar un router o gateway con esta dirección de origen. De hecho, enrutar estos paquetes es peligroso puesto que se podrían utilizar para falsificar paquetes del localhost que a menudo tienen privilegios especiales. La dirección IP no es legítima. De hecho, no existe ninguna dirección IP legítima que deba cruzar gateways conteniendo un 0 en alguno de los elementos de la dirección (son las conocidas como direcciones IP de broadcast). Desgraciadamente, muchos routers utilizan los.0. en sus tablas de enrutamiento como convención para indicar alguna dirección de 0 a 255 (el rango entero). La especificación de IP incluye direcciones reservadas para redes privadas, diseñadas únicamente para uso interno. No hay ninguna razón legítima para enrutar paquetes con estas direcciones de origen (RFC-1597). Estos rangos de dirección incluyen 10. *. *. *, *. *, y *. * (donde * indica algún valor de 0 a 255). Ningún paquete debe ser enrutado a través de Internet con estas direcciones como su fuente o destino. El próximo paso para eliminar la falsificación IP se dirige a imponer estándares en los routers, gateways y cada elemento de la infraestructura. Generalmente, Internet se divide en servidores de su columna vertebral, que proporcionan servicios de transporte de paquetes de área ancha, redes privadas propiedad de compañías, instituciones, agencias gubernamentales, y proveedores de servicios de Internet (ISP) que proporcionan conexiones entre elementos de la columna vertebral y las redes privadas. Redes Privadas: cada red privada debe: Prevenir la entrada de paquetes con direcciones de origen internas a la red. Prevenir la salida de paquetes con direcciones de origen externas. Prevenir la entrada de paquetes con direcciones de destino externas. Prevenir la salida de paquetes con direcciones de destino internas. Autor: Pablo Astudillo Aguilar 26/06/

73 CAPITULO 2. Análisis y Diagnóstico ISPs: cada ISP debe: Prevenir que cualquier paquete entrante de cualquiera de sus clientes, con una dirección origen que no pertenece al rango de direcciones asignadas a ese cliente, salga de la red del cliente. Prevenir que cualquier paquete con una dirección destino que no esté en el rango de direcciones de su cliente entre en la red de su cliente. Prevenir que cualquier paquete con una dirección IP no legítima de su ISP salga de su red. Prevenir que cualquier paquete originado fuera de su red y no destinado para sus direcciones IP legítimas entre en su red. Prevenir el tráfico entrante del cliente con la dirección origen del cliente. Prevenir el tráfico saliente del cliente con la dirección destino del cliente. Redes de la columna vertebral: cada proveedor debe: Prevenir la entrada de paquetes originados en un ISP con dirección de origen que no pertenezca legítimamente a ese ISP. Prevenir la entrada en la red de un ISP cualquier paquete no destinado a una dirección legítima de ese ISP. Prevenir la entrada en su red de paquetes mal enrutados desde cualquier otro proveedor de la columna vertebral. Impedir el enrutamiento de cualquier paquete a cualquier otro servidor de la columna vertebral a no ser que ellos puedan enrutar legítimamente ese paquete para que alcance su destino. Para los servidores de la columna vertebral, esto requiere algún esfuerzo, sin embargo, el alto volumen de información que mueven justifica un poco el esfuerzo en la protección FERNANDEZ, Alberto y CRESPO, Abel. IP Spoofing [en línea]. Ultima revisión: Junio 1, Capítulo 4. Prevención del IP Spoofing. Página 6. Disponible en: ip-spoofing.tinusi.com/es/ Autor: Pablo Astudillo Aguilar 26/06/

74 CAPITULO 2. Análisis y Diagnóstico Denegación de Servicios Un ataque de denegación de servicios se centra en sobrepasar los límites de recursos establecidos para un servicio determinado, obteniendo como resultado la eliminación temporal del servicio. Por ejemplo, si un servidor es capaz de procesar 10 peticiones por segundo, y se le envían 30, parte del tráfico legítimo no recibirá servicio, o incluso, puede que la saturación del tráfico provoque que el servidor deje de responder a ninguna petición. Los destinos de estos ataques suelen ser objetivos visibles, como servidores Web, o DNS, o elementos básicos de la red, routers o enlaces de red. Se basa en el hecho comprobado de que es más fácil corromper un sistema que acceder clandestinamente al mismo. Este tipo de ataque no supone ningún peligro para la seguridad de las máquinas, ya que no modifica los contenidos de la información, por ejemplo: páginas Web, ni permite obtener información sensible. Simplemente persiguen entorpecer el acceso de los usuarios a los servicios del un sistema. Normalmente, una vez que el ataque finaliza, se vuelve a la situación normal. En este paradigma de ataque, se ha sustituido el ataque sistemático y elaborado a un sistema en concreto, por ataques mucho más sencillos pero masivos. Con el número de máquinas conectadas a Internet que existen en la actualidad, una vulnerabilidad explotable en el 0.01% de los casos supone millones de máquinas a merced de cualquiera Smurf o Broadcast storm Esta técnica se aprovecha de las características de broadcast de las redes y causa que su objetivo se vuelva inoperable durante el ataque. La dirección lógica de broadcast se utiliza en algunos protocolos para localizar el sistema que proporciona 31 HISPASEC. Ataques masivos. Es tan fiero el león como lo pintan? [en línea]. Ultima actualización: febrero 15, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

75 CAPITULO 2. Análisis y Diagnóstico un servicio concreto de forma sencilla, es decir, preguntando a la red, y no consultando uno por uno a todos los sistemas existentes. Si esta dirección se encuentra disponible también para usuarios externos a la red, es posible que un atacante construya un paquete con la dirección IP origen de la víctima (spoofing). El paquete contiene un mensaje ICMP ping (tipo 8) dirigido a una dirección de broadcast, es decir, a todas la direcciones IP en una red dada, de tal forma que todas las máquinas activas en esta red responderán con un mensaje ICMP echo reply a la víctima. Si se envían suficientes pings, los ecos resultantes pueden inundar la red de la víctima e inutilizarla para el tráfico real. Es decir, se realiza un ataque a una red desde otra red intermedia, que permite multiplicar los recursos existentes. Figura 2-3. Esquema que representa las partes del ataque Smurf Firma: 1. Un número grande de paquetes ICMP de tipo 0 (echo reply) son dirigidos hacia una máquina. 2. Estos paquetes pueden venir de una o varias fuentes diferentes Fraggle Es una variante del Smurf; en lugar de utilizar paquetes ICMP utiliza paquetes UDP echo (puerto 7), asignándoles a la dirección origen la dirección del objetivo igual que antes, y enviándolos a la dirección de broadcast de la red amplificadora. De esta Autor: Pablo Astudillo Aguilar 26/06/

76 CAPITULO 2. Análisis y Diagnóstico manera, devuelven un echo de lo recibido y se obtiene el mismo resultado anterior, DoS. Para evitar esto, es posible desactivar la función de difusiones dirigidas de los routers, también se pueden configurar los sistemas operativos para rechazar paquetes echo de difusión. Además se puede limitar el tráfico de ICMP, UDP en los routers. Los ataques smurf y fraggle no implican controlar las redes que se emplean como multiplicadoras. Firma: 1. Un número grande de paquetes UDP, con puerto destino 7 (echo), son dirigidos hacia una máquina. 2. Estos paquetes pueden venir de una o varias fuentes diferentes TCP Syn Flood Esta técnica esta asociada directamente al protocolo TCP. Consiste en el envío masivo de paquetes de establecimiento de conexión (SYN) contra un sistema. La recepción de estas solicitudes provoca que el sistema destino, objetivo del ataque, reserve cierta cantidad de memoria (buffers) para almacenar las estructuras de datos asociadas a cada una de las nuevas conexiones en curso. Como se explicó al principio de la sección, el protocolo TCP requiere el establecimiento de una conexión, que se realiza en tres pasos. Tras la recepción del paquete SYN, responderá con su paquete SYN/ACK, permaneciendo a la espera del paquete final (ACK) que confirma el establecimiento de la conexión TCP (three-way handshake). La conexión permanece en el estado semiabierto, concretamente SYN_RCVD. El intruso no enviará nunca ese ACK esperado, por lo que la memoria del destino es copada en su totalidad por conexiones falsas, no siendo posible el establecimiento de conexiones de clientes reales, y por tanto anulándose el servicio. Autor: Pablo Astudillo Aguilar 26/06/

77 CAPITULO 2. Análisis y Diagnóstico Este ataque se realiza variando la dirección IP del emisor, mediante direcciones falsas (IP spoofing), de forma que se simule de forma más fehaciente una situación real de conexiones realizadas por multitud de clientes. Además, es obligatorio que la IP origen sea inexistente o inactiva, de lo contrario, el objetivo logrará responderle al cliente con un SYK-ACK, y como esta IP no pidió ninguna conexión, le va a responder al objetivo con un RST, y el ataque no tendrá efecto. 32 Figura 2-4. Syn Flood Los sistemas imponen un número máximo de conexiones en este estado (del orden de 5 a 30 conexiones "semiabiertas"), por lo que una vez alcanzado este, no será posible establecer más conexiones. Tras un periodo de tiempo controlado por un temporizador (que suele ser de 2 minutos), las conexiones que continúan en este estado expiran, permitiendo la creación de nuevas conexiones, lo cual puede ser aprovechado para colar un paquete SYN destructivo o malicioso. Así que, este ataque se puede utilizar tanto para consumir los recursos de un sistema como para abrir el camino a otro tipo de ataque. 32 BORGHELLO, Cristian. Seguridad Informática, sus Implicancias e Implementación [en línea]. Edición 1. Septiembre Capítulo 7, Denial of Service. Página 18. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

78 CAPITULO 2. Análisis y Diagnóstico Entonces, la creación de conexiones legítimas solo será posible si el ataque TCP Syn Flood ha cesado, ya que mientras se mantenga, la probabilidad de que una conexión recién liberada sea capturada por un nuevo SYN malicioso es muy alta. Suponiéndose un número máximo de conexiones igual a 30, y el temporizador igual a 2 minutos, se podría desarrollar un ataque de este tipo enviando un paquete SYN cada 4 segundos: tiempo necesario por cada conexión para poder enviar el máximo de 30 conexiones en los 120 segundos de expiración. Esta velocidad se consigue fácilmente con cualquier módem, de aquí la fortaleza de este ataque, se necesita muy poca potencia en un PC. Algunas herramientas dedicadas a este tipo de ataques son: neptune y synk4 Firma: 1. Múltiples sesiones han sido iniciadas en forma inapropiada sobre cualquiera de los puertos de servicios bien conocidos : FTP (puerto 21), Telnet (puerto 23), WWW (puerto 80), (puerto 25), etc. Actualmente, los sistemas operativos ya tienen soluciones diversas. Linux por ejemplo utiliza SYN cookie, que contrarresta el flood de SYN mediante criptografía y permite a los usuarios legítimos seguir conectándose. WinNT utiliza la asignación de recursos adicionales cuando la cola cae por debajo de un umbral Land Este ataque consiste en un Bug (error) en la implementación de la pila TCP/IP en sistemas Windows. Permite bloquear un sistema, mediante el envío de un paquete TCP SYN cuya dirección IP fuente y destino es la misma. Existe una variación de este ataque, basada en que los puertos origen y destino también son iguales, generalmente el 113 (identd auth) o el 139 (NetBIOS File and Print Sharing). Para ello es necesario enviar paquetes IP mediante la técnica de spoofing. Al final la máquina termina por colapsarse. Autor: Pablo Astudillo Aguilar 26/06/

79 CAPITULO 2. Análisis y Diagnóstico Podría darse algún caso en el que se establezca una conexión a la propia máquina, se envíe por tanto un paquete [ :puerto_cliente ==> :puerto_servidor], y el sistema IDS lo detecte como un ataque cuando en realidad no lo es. Este ejemplo, aplicable a un gran número de las vulnerabilidades mencionadas, refleja la estrecha línea existente entre un ataque real y una situación convencional, denotando que su detección y automatización no es trivial. Firma: 1. Se detecta un paquete TCP SYN que tiene la misma dirección IP como origen y destino. Posibles excepciones: 1. Podría darse el caso de que se establezca una conexión a la propia máquina, y exista un paquete como este: [ :puerto_origen ==> :puerto_destino] Winnuke o Supernuke Este ataque afecta a los sistemas que utilizan el protocolo NetBIOS sobre TCP/IP, típicamente a los sistemas operativos Windows 9x y NT. Este protocolo emplea los puertos UDP 137, 138 y 139. El envío de un paquete urgente (bit URG=1 en los indicadores del encabezamiento TCP), conocido como paquete Out of Band (OOB) da lugar al envío de datagramas UDP a estos puertos. El sistema operativo utiliza el URGENT POINTER para determinar donde terminan los datos urgentes. Cuando el puntero apunta al final de la trama y encuentra datos no esperados o anormales, provoca el error del sistema. Firma: 1. Se detecta un paquete TCP con el bit URG en 1 y el puerto destino es 137,138 o 139. Autor: Pablo Astudillo Aguilar 26/06/

80 CAPITULO 2. Análisis y Diagnóstico Fragmentos IP La fragmentación IP ocurre cuando un router recibe un paquete más grande que el MTU (Unidad de transmisión máxima) del siguiente segmento de red. Todos estos fragmentos tendrán el mismo valor en el campo Identificación, y el campo offset indica la posición del fragmento actual en el contexto de paquete antes de fragmentarlo. No se espera que los routers intermedios reensamblen los fragmentos. El destino final reensamblará todos los fragmentos de un paquete IP y lo pasará al protocolo del siguiente nivel. Los intrusos crean artificialmente paquetes fragmentados con el fin de evadir firewalls que no realizan reensamblaje de paquetes. Estos solo consideran las propiedades de cada fragmento individual, y permiten a todos los fragmentos alcanzar la máquina objetivo. El primer fragmento es tan pequeño que no incluye toda la cabecera TCP, particularmente el puerto destino. El segundo fragmento contiene el resto de la cabecera TCP, incluyendo este puerto. 33 Firma: 1. Se detecta un datagrama IP con un valor pequeño en el campo offset. Esto indica que el primer fragmento fue inusualmente pequeño, y es probable un intento de evadir los filtros de la red Snork Este método consiste en enviar, mediante spoofing, paquetes UDP al puerto 135 de un servidor. (En este caso el spoofing consiste en incluir como dirección origen la de otro servidor). Cuando el servidor B recibe el paquete UDP parece que se ha equivocado y le envía un REJECT al servidor A, el cual responde con otro REJECT. Esto solo dura unos minutos hasta que rompan el paquete, pero si se utilizan muchos más se creará un loop que consumirá los recursos e incluso el ancho de banda. 33 MATETI, Prabhaker. IP Spoofing and Fragmentation[en línea]. Altavista Group. IP Fragment Attacks. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

81 CAPITULO 2. Análisis y Diagnóstico Firma: 1. Se detecta un paquete UDP con el puerto origen: 137, 7 o 19 y como puerto destino: Chargen y Chargen-Echo Es parecido al Fraggle; se basa en enviar datagramas UDP mediante spoofing (con la dirección origen = dirección objetivo) al puerto 19 (chargen) de todos los hosts de una subred (con dirección broadcast), de forma que responderán inundando el objetivo con el generador de caracteres. Combinando el puerto 19 (chargen) y el puerto 7 (echo) se puede conseguir un DoS, si se crea un socket UDP al puerto 7 y se envía un datagrama UDP al puerto 19. Esto provoca que el chargen genere caracteres que serán respondidos al puerto echo, y que este a su vez devolverá al puerto 19, y así sucesivamente. Firma: 1. Se detecta un paquete UDP con el puerto origen 17 y el puerto destino DDoS Denegación de Servicios Distribuida Son una variante más potente a los ataques de Denegación de Servicio, que se basan en realizar ataques DoS de forma masiva a un mismo objetivo, desde diferentes localizaciones en la red, de forma que la potencia de ataque sea mucho mayor. Si un ataque desde una fuente es potente, desde 1000 lo será mucho más. Aunque su origen se remota a los comienzos de la seguridad en Internet, su expansión se produjo principalmente en el año 2000, al surgir numerosas herramientas que permiten su ejecución, de forma coordinada y a gran escala. Un único intruso puede desencadenar una agresión desde centenares de máquinas repartidas por todo el mundo, y dado el elevado número de sistemas existentes en Internet, la capacidad de reclutar recursos es inmensa. Autor: Pablo Astudillo Aguilar 26/06/

82 CAPITULO 2. Análisis y Diagnóstico Debido a las vulnerabilidades de los sistemas operativos y de las aplicaciones, como los buffer overflows y los format-strings, un intruso es capaz de apoderarse de un conjunto de sistemas (de cientos a miles) e instalar en ellos un servicio que acepte sus órdenes y ejecutar un DDoS contra una máquina objetivo. La sofisticación de las herramientas actuales hace que no se requieran conocimientos técnicos avanzados para llevar a cabo este tipo de ataques; ellas se encargan de analizar y vulnerar los sistemas, para copiarse e instalarse automáticamente. El proceso esta compuesto de 4 pasos principales: Fase de escaneo con un conjunto objetivo de sistemas muy elevado, cien mil o más. Se prueban estos frente a una vulnerabilidad conocida. Se obtiene acceso a parte de esos sistemas a través de la vulnerabilidad. Se instala la herramienta de DDoS en cada sistema comprometido. Se utilizan estos sistemas para escanear y comprometer nuevos sistemas. El modo de operación genérico de las herramientas de DDoS tiene la siguiente topología: el intruso se comunica mediante comandos con un elemento denominado administrador (handler). Este se encarga de gestionar el registro, realizado previamente, de un conjunto de agentes, normalmente elevado en número, que son realmente el origen de los paquetes del DDoS. Por tanto, los agentes y el administrador conforman una red de ataque, que actúa en el momento en que el administrador retransmite a todos y cada uno de los agentes las órdenes invocadas por el intruso remotamente. Las comunicaciones entre estos elementos se realizaban originalmente por puertos fijos y, a la larga, conocidos, por lo que este modo de funcionamiento podía ser detectado por sistemas IDS con facilidad. La difusión en el uso del IRC o chat, a dado lugar a la utilización de este medio (y sus puertos TCP asociados, del 6660 al 6669) para constituir los canales de control de los elementos de un DDoS. Autor: Pablo Astudillo Aguilar 26/06/

83 CAPITULO 2. Análisis y Diagnóstico Trinoo Trinoo es una herramienta distribuida usada para lanzar ataques de denegación de servicios UDP FLOOD coordinados desde muchas fuentes. Una red trinoo consiste de un pequeño número de servidores, o maestros, y un gran número de clientes o demonios. Un ataque de denegación de servicio utilizando esta red es llevada a cabo por un intruso, que se conecta a un servidor trinoo y le indica lanzar el ataque contra una o más direcciones IP. El servidor se comunica con los demonios, dándoles instrucciones para atacar estas direcciones por un periodo de tiempo especificado. 1. Intruso > Sevidor, puerto destino 27665/tcp 2. Servidor > Demonios, puerto destino 27444/udp 3. Demonios > UDP flood hacia el objetivo con puertos destino aleatorios El binario del demonio contiene direcciones IP de uno o más servidores trinoo. Cuando el demonio es ejecutado, anuncia su disponibilidad enviando un paquete UDP conteniendo la cadena *HELLO* a las IP de sus servidores trinoo programados. Demonio > servidores; puerto destino 31335/udp El servidor trinoo almacena una lista de demonios conocidos en un archivo encriptado llamado en el mismo directorio que el binario del servidor. El servidor trinoo puede ser instruido de enviar un requerimiento broadcast a todos sus demonios conocidos para confirmar su disponibilidad. Los demonios responden al servidor con un paquete UDP que contiene la cadena PONG. Intruso > Servidor; puerto destino 27665/tcp Servidor > Demonios; puerto destino 27444/udp Demonios ----> Servidor; puerto destino 31335/udp Autor: Pablo Astudillo Aguilar 26/06/

84 CAPITULO 2. Análisis y Diagnóstico Todas las comunicaciones hacia el servidor en el puerto 27665/tcp requieren una contraseña, la cual es almacenada en el binario del demonio en forma encriptada. Todas las comunicaciones con el demonio en el puerto 27444/udp requieren un paquete UDP que contenga la cadena l44 (es una L minúscula, no el número uno). Un ataque de denegación de servicios trinoo probablemente parecerá venir de un gran número de diferentes direcciones IP fuente. Los demonios trinoo se instalan bajo una variedad de nombres diferentes, los más comunes son: ns, http, rpc.trinoo, rpc.listen, trinix, rpc.irix, irix. Firma: 1. Se detectan paquetes UDP, con puerto destino 27444, con las cadenas *HELLO* o l44 2. Se detectan paquetes UDP, con puerto destino 31335, con la cadena PONG Tribe Flood Network y TFN2K La comunicación entre clientes y servidores se realiza a través de paquetes de ping: ICMP echo request e ICMP echo reply, aunque posibilita ataques DoS basados en ICMP flood, SYN flood, UDP flood, y Smurf, así como obtener una shell de root asociada a un puerto TCP seleccionado. La comunicación entre clientes y servidores no emplea puertos concretos. Estos pueden determinarse en el momento de la ejecución o pueden elegirse aleatoriamente en el propio programa, pero consisten en una combinación de los protocolos ICMP, TCP y UDP. Asimismo, añade capacidades de encriptación, utilizando blowfish para enviar su lista de direcciones IP, eliminando así la detección por los sistemas IDS. Autor: Pablo Astudillo Aguilar 26/06/

85 CAPITULO 2. Análisis y Diagnóstico Stacheldraht Esta herramienta es una combinación de las anteriores, creando una sesión telnet encriptada entre clientes y servidores. La comunicación se realiza típicamente a través de los siguientes puertos: Intruso > Manejador: 16660/tcp Manejador ---> Agentes: 65000/tcp, ICMP echo, echo reply Firma: 1. Se detectan paquetes TCP con puerto destino Detección de anomalías La detección de anomalías puede ser descrita como una alarma para el comportamiento extraño del sistema. La idea es a priori muy interesante: estos modelos de detección conocen lo que es normal en nuestra red o nuestros computadores a lo largo del tiempo, desarrollando y actualizando conjuntos de patrones contra los que comparan los eventos que se producen en los sistemas. Si uno de esos eventos (por ejemplo, una trama procedente de una máquina desconocida) se sale del conjunto de normalidad, automáticamente se cataloga como sospechoso. Las firmas basadas en anomalías están típicamente diseñadas para buscar tráfico de red que se desvía de lo que se ve normalmente. El mayor problema con esta metodología es definir primero que es normal. Algunos sistemas tienen definiciones fuertemente codificadas de lo que es normal, mientras que otros sistemas son construidos para aprender lo que es normal. El desafío con estos últimos está en eliminar la posibilidad de clasificar inadecuadamente el 34 SILES, Raúl. Análisis de Seguridad de TCP/IP. Edición 1. Junio Capítulo 5. Vulnerabilidades Genéricas. DoS: Denial of ServicePágina. Página 41. Autor: Pablo Astudillo Aguilar 26/06/

86 CAPITULO 2. Análisis y Diagnóstico comportamiento anormal como normal. Además, si el patrón de tráfico aprendido se asume como normal, el sistema debe tratar con el problema de cómo diferenciar entre desviaciones aceptables y aquellas no permitidas o tráfico de ataque. El trabajo en esta área ha sido, en su mayor parte, limitado a ambientes universitarios. La respuesta a la pregunta de cómo determinar lo que es normal, y la clave para la efectividad de la detección de anomalías, son los perfiles. Generando Perfiles Lo que marca la diferencia en la tecnología de detección de anomalías son los métodos para construir un perfil del sistema. Actualmente, la modelación de un comportamiento normal puede estar basado en 2 métodos: Estadística: el sistema es capaz de aprender el comportamiento normal por sí mismo, usando métodos estadísticos (medias, varianzas, etc.) sobre variables como en el comportamiento de los usuarios, de sus procesos, del tráfico de nuestra red, etc. Especificaciones: se le especifica al sistema dicho comportamiento mediante un conjunto de reglas. Ambos pueden ser aplicados a computadores individuales, redes, protocolos, o incluso aplicaciones. Sin embargo, las técnicas usadas en cada método para generar un perfil son bastante diferentes Detección de anomalías basada en Estadística Este método emplea la estadística para construir un punto de referencia del comportamiento del sistema. El proceso comienza con el entrenamiento de un sensor de detección de anomalías. Se realiza observando eventos específicos en el ambiente monitoreado, durante un periodo de tiempo especificado. Algunos de estos eventos pueden ser: llamadas al sistema, tráfico de red, uso de aplicaciones, uso del CPU, actividad del disco, inicios de sesión, actividad sobre archivos, etc. Finalizada esta actividad, se usa alguno de los varios métodos matemáticos para generar una Autor: Pablo Astudillo Aguilar 26/06/

87 CAPITULO 2. Análisis y Diagnóstico medida cuantitativa de los datos observados. El resultado es una línea de referencia para algunas variables del comportamiento del sistema. Con un punto de referencia fijo, el proceso de monitoreo es repetido en un ambiente real. Los datos registrados son transformados en la misma métrica cuantitativa y comparados con la línea de referencia. Si la desviación excede un umbral especificado, el evento es etiquetado como anómalo. Aunque el proceso suena simple, no lo es. El primer problema es decidir que método se debe usar para medir la desviación. Múltiples técnicas han sido probadas; estas van desde análisis simples de frecuencia hasta complejos modelos estadísticos. El siguiente problema es la correlación de múltiples variables. En la explicación simplificada anterior, se mide solo un elemento de un sistema complejo. A fin de producir datos verdaderamente útiles, se requiere una compresión de múltiples variables y sus relaciones. Por ejemplo, la frecuencia de inicios de sesión, la utilización de la red, y un análisis de protocolo pueden ser usados para descubrir a un intruso que ha secuestrado una cuenta válida, con el propósito de transferir archivos. Un detector de anomalías probablemente notaría 3 anomalías independientes y las reportaría al administrador para que este una las piezas. Se puede ver que entrenar a un detector de anomalías basado en estadística es tarea difícil. Pero existe un problema mayor para estos sistemas: un ambiente dinámico. Como cada administrador sabe, las cosas cambian: se suman nuevos usuarios, los servicios son removidos/añadidos, se introducen nuevos computadores, etc. Cada uno de estos factores provoca una actualización del perfil. A la larga, un detector de anomalías requerirá un entrenamiento constante en ambientes dinámicos. Se definen diferentes tipos de datos o medidas que pueden ser útiles en la elaboración de estos perfiles: Intensidad de la actividad. Reflejan la relación de progreso de la actividad en el sistema, para lo cual recogen datos a intervalos muy pequeños, típicamente entre un minuto y una hora. Estas medidas detectan ráfagas de Autor: Pablo Astudillo Aguilar 26/06/

88 CAPITULO 2. Análisis y Diagnóstico comportamiento (por ejemplo, una excesiva generación de peticiones de entrada/salida en un cierto intervalo) que en espacios de tiempo más amplios no podrían ser detectadas. Numéricas. Se trata de medidas de la actividad cuyo resultado se puede representar en forma de valor numérico, como el número de ficheros leídos por cierto usuario en una sesión, o la cantidad de veces que ese usuario se ha equivocado al ingresar su contraseña de acceso al sistema. Categóricas. Son aquellas cuyo resultado es una categoría individual, y miden la frecuencia relativa o la distribución de una actividad determinada con respecto a otras actividades o categorías; por ejemplo, cual es la relación entre la frecuencia de acceso a un determinado directorio del sistema en comparación con la de acceso a otro. Distribución de registros de auditoría. Esta medida analiza la distribución de las actividades generadas en un pasado reciente, basándose en los logs generados por las mismas; dicho análisis se realiza de forma ponderada, teniendo más peso las actividades más recientes, y es comparado con un perfil de actividades habituales previamente almacenado, de forma que permite detectar si en un pasado reciente se han generado eventos inusuales Detección de anomalías basada en Especificaciones La segunda corriente de pensamiento depende menos de las matemáticas y más de las observaciones humanas y de la habilidad. Este método usa una descripción basada en la lógica del comportamiento esperado para construir un perfil. Se requiere un lenguaje o estándar que pueda ser interpretado por un detector de anomalías. Usando esta sintaxis, un administrador puede construir una lista similar a las reglas y firmas usadas por un detector de usos indebidos; pero en lugar de buscar usos indebidos, estas reglas ignorarían el uso normal. Sin embargo, 35 VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Capítulo 18. Sistemas de detección de intrusos. Detección de Anomalías. Página 322. Disponible en: es.tldp.org/manuales-lucas/doc-unixsec/unixsec-html/ Autor: Pablo Astudillo Aguilar 26/06/

89 CAPITULO 2. Análisis y Diagnóstico cualquier cosa fuera del comportamiento especificado, sería marcado como anómalo. Es un concepto similar al negar todo del firewall, donde las reglas son construidas para bloquear todo, excepto el tráfico explícitamente permitido. Un detector basado en especificaciones extiende esta idea a los múltiples elementos del sistema: una aplicación, un servidor, tráfico de red, etc., y, en lugar de bloquear un evento, genera una alarma. Al igual que el modelo estadístico, la detección de anomalías basada en especificaciones tiene desventajas. Dada una sintaxis apropiada, crear un grupo de reglas para el comportamiento normal no sería difícil. Sin embargo, afinar esas reglas para registrar un cantidad mínima de falsos positivos, sin dejar de capturar ocurrencias extrañas, es bastante complicado. Adicionalmente, la cantidad de variables requeridas para monitorear un ambiente relativamente simple es desalentadora. Las reglas, desde las más generales a las más específicas, necesitarían ser escritas para redes, aplicaciones y comportamiento de usuarios. A diferencia de los perfiles generados estadísticamente, no existe un grupo de datos para el entrenamiento. Todos los elementos normales de un sistema y los innumerables escenarios deben ser tomados en cuenta por el administrador Fortalezas y Debilidades de la Detección de Anomalías Entre las fortalezas o ventajas de la detección de anomalías tenemos: Posibilita la detección de ataques nuevos como intrusiones. Las anomalías son reconocidas sin profundizar en sus causas y características. Menos dependencia del IDS sobre el ambiente operativo (en comparación con los sistemas basados en detección de usos indebidos). Habilidad para detectar abusos de privilegios de usuario. Es liviano debido a que no se deben desarrollar nuevas firmas. Sus principales debilidades son: Autor: Pablo Astudillo Aguilar 26/06/

90 CAPITULO 2. Análisis y Diagnóstico No son capaces de ofrecer datos puntuales sobre las intrusiones. Parece como si algo terrible podría haber sucedido, pero los sistemas no pueden establecerlo categóricamente. Este método es altamente dependiente del ambiente en el cual los sistemas aprenden lo que es normal. Un porcentaje considerable de falsos positivos. El uso del sistema no es monitoreado durante la construcción del perfil y las fases de entrenamiento, por lo tanto, todas las actividades de los usuarios omitidas durante estas etapas serán ilegítimas. El comportamiento de los usuarios pueden variar con el tiempo, por esta razón se requiere una actualización constante de la base de datos de los perfiles de comportamiento normal (esto puede implicar la necesidad de cerrar el sistema de vez en cuando y podría también estar asociado con altos índices de falsos positivos). 36 Existen muchas dificultades a la hora de aprender o simplemente especificar lo habitual. Conforme aumentan las dimensiones de los sistemas (redes con un gran número de máquinas interconectadas o equipos con miles de usuarios), estos se hacen cada vez más aleatorios e impredecibles Estado actual de la Detección de Anomalías La detección de anomalías ha aparecido ya en productos open-surce y comerciales: Statistical Packet Anomaly Detection Engine (SPADE), producido por Silicon Defense, es un plug-in para el IDS open source Snort. Login Anomaly Detection (LAD), construido por Psionic Technologies para incluirlo en su programa HostSentry. Este programa aprende el comportamiento de los usuarios para registrarse en el sistema, entonces reacciona cuando detecta actividad extraña. 36 KAZIENKO, Przemyslaw y DOROSZ, Piotr. Intrusion Detection Systems (IDS) Part 2 - Classification; methods; techniques [en línea]. Ultima actualización: Julio 23, Disponible en: IDS-Part2-Classification-methods-techniques.html Autor: Pablo Astudillo Aguilar 26/06/

91 CAPITULO 2. Análisis y Diagnóstico Stealhwatch, producido por Lancope. Este programa distingue y registra actividades de red para diferenciar el comportamiento normal del anormal. Okena s Stormwatch es un paquete comercial que ejemplifica la detección de anomalías basada en especificación. Interactúa con una aplicación y su sistema operativo para tomar decisiones en tiempo real para permitir o denegar, de acuerdo a las políticas de seguridad de la aplicación del cliente. Proyectos distribuidos tales como SecurityFocus DeepSight Threat Management System hacen uso de datos estadísticos para detectar amenazas potenciales en Internet Métodos alternativos Sistemas Expertos Los primeros sistemas de detección de usos indebidos, como NIDES, se basaban en los sistemas expertos para realizar su trabajo; en ellos las intrusiones se codifican como reglas de la base de conocimiento del sistema experto, de la forma genérica ifthen (if CONDICIÓN then ACCIÓN). Cada una de estas reglas puede detectar eventos únicos o secuencias de eventos que denotan una potencial intrusión, y se basan en el análisis, generalmente en tiempo real, de los registros de auditoría proporcionados por cualquier sistema Unix: esta es una de las principales ventajas de los sistemas expertos Análisis basado en Heurística Las firmas basadas en la heurística usan algún tipo de algoritmo lógico en el cual basar sus decisiones de alarma. Estos algoritmos son frecuentemente evaluaciones estadísticas del tipo de tráfico presentado. Un buen ejemplo de este tipo de firma es la que sería usada para detectar un escaneo de puertos. Esta firma busca la 37 TANASE, Matthew. One of These Things is not Like the Others: The State of Anomaly Detection[en línea]. Ultima actualización en Julio 1, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

92 CAPITULO 2. Análisis y Diagnóstico presencia de un número umbral de puertos únicos accedidos en un computador particular. Esta firma podría restringirse a los tipos de paquetes en los que se está interesado, es decir, los paquetes SYN. Adicionalmente, podría existir el requerimiento de que todas las pruebas deben originarse desde una misma fuente. Las firmas de este tipo requieren cierto ajuste de los umbrales para adaptarlas a los patrones de utilización de la red que están monitoreando. Pueden ser usadas para buscar relaciones muy complejas, así como también, el simple ejemplo estadístico mencionado. Algunos tipos de actividad sospechosa o maliciosa no pueden ser detectados con ningún otro método. Estos algoritmos pueden requerir afinación o modificación a fin de adaptarse al tráfico de la red y limitar los falsos positivos CISCO SYSTEMS. The Science of Intrusion Detection System Attack Identification [en línea]. Introduction. Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

93 CAPITULO 3. Respuestas Activas Capítulo 3. Respuestas Activas Una pregunta importante con respecto al esquema de detección de intrusiones es qué hacer con la información obtenida del mismo. Se pueden considerar varias posibilidades. Por un lado, se podría procesar esta información manualmente de forma periódica y, en función de los datos que nuestros sensores hayan recogido, tomar una determinada acción: bloquear las direcciones atacantes en el firewall corporativo, enviar un correo de queja a los responsables de dichas direcciones, o simplemente no hacer nada. Dependerá casi por completo de la política de seguridad establecida. Mucho más interesante que cualquiera de estas respuestas manuales es que el propio sensor sea capaz de generar respuestas automáticas ante lo que él considere un intento de ataque. El concepto de mecanismos de respuesta activos, o contramedidas en IDS, está basado en la idea de tener un IDS capaz de reaccionar automáticamente, en cuanto se observe una amenaza de comprometer el sistema. La meta es prevenir que el sistema sea comprometido posteriormente, bloqueando la comunicación entre el intruso y el computador atacado. Se debe notar que si tales mecanismos son implementados o configurados incorrectamente, podrían ser engañados y utilizados para bloquear tráfico legítimo. 3.1 Tipos de Respuesta Activas La mayoría de los mecanismos de respuesta son de estos tipos: Cierre de sesión. Actualización del Firewall. Autor: Pablo Astudillo Aguilar 26/06/

94 CAPITULO 3. Respuestas Activas Cierre de sesión El cierre de sesión es con mucho la técnica más popular entre vendedores de IDS. Esto se debe a que no requiere drivers para ningún dispositivo externo (como firewalls) y es fácil de implementar. Se basa en el hecho de que una pila TCP/IP cierra una conexión cuando recibe un mensaje de error de red (TCP RST para el protocolo TCP o un paquete ICMP Red/Host/Puerto inalcanzable para el protocolo UDP). La idea es construir un paquete TCP RST o ICMP falsificado cuando el sistema detecta un ataque. 39 El mecanismo es simple: Considere un intruso con un exploit de 51 bytes ataca una red que puede transferir 20 bytes de datos por paquete. Imagine también que el IDS tiene una firma que detecta la cadena system32/cmd.exe y puede realizar defragmentación completa, reensamble de segmentos, decodificación unicode/hexcode/escape/base36. El IDS atrapará el exploit y generará una alerta. La pila IP del intruso escogerá un número de secuencia inicial (ISN) en forma aleatoria y repartirá el exploit en 3 paquetes como se muestra en la Figura 3-1: Figura 3-1. Ejemplo de exploit fragmentado Algunas implementaciones TCP/IP enviarán los paquetes uno a la vez, esperando el reconocimiento después de cada paquete. Otras implementaciones enviarán los 3 paquetes en forma inmediata y entonces reenviarán algunos de ellos si no se recibe el reconocimiento. Otros incluso, envían uno a la vez al principio y envían más 39 ZARASKA, Krzysztof. IDS Active Response Mechanisms: Countermeasure Subsytem for Prelude IDS [en línea]. Julio 9, Página 1. Disponible en: misc/lsm/2002/slides/krzysztof/lsm.pdf Autor: Pablo Astudillo Aguilar 26/06/

95 CAPITULO 3. Respuestas Activas cuando la sesión es establecida. El punto es que las implementaciones tienen que ser capaces de manejar cualquier número de paquetes al mismo tiempo. En el ejemplo citado, el IDS alertará en el tercer paquete debido a que se necesitan los paquetes 2 y 3 para completar la firma. Un IDS que emplea el cierre de sesión elaborará un paquete TCP RESET para que ambos finalicen la conexión. Las implementaciones interpretarán el paquete RESET como una petición desde el otro extremo para detener las comunicaciones. Ellos vaciarán todos los buffers relacionados con esta conexión. En este punto, existe la posibilidad de que el exploit aún permanezca en los buffers de la pila TCP/IP en la máquina objetivo, y no haya sido entregado a la aplicación. Si este es el caso, el exploit desaparecerá con el vaciamiento de la pila y nunca será entregado. Desafortunadamente, aunque la latencia de los paquetes de cierre de conexión sea mínima, estos llevan las de perder frente a los paquetes ya entregados enviados por el intruso. En la mayoría de los casos, el ataque se llega a consumar. Los paquetes RESET deben tener los números correctos de secuencia/reconocimiento o estos serán ignorados. En este caso el número de reconocimiento debe ser 152 (uno más alto que el último número de secuencia). Si se envía un paquete RESET con un número de reconocimiento de 141, este podría ser ignorado por la pila como tráfico fraccionado o inválido Actualizaciones de Firewall En este método, el IDS manipula el conjunto de reglas de firewall, añadiendo instrucciones que bloquean todo el tráfico que tenga como origen la dirección IP del intruso. Algunos sistemas remueven esta regla después de un periodo de tiempo establecido. Algunos IDS requieren múltiples detecciones para bloquear una dirección IP. La idea de este tipo de respuesta es detener al intruso antes de que este pueda aprovechar la posición ganada con la ejecución del exploit. Autor: Pablo Astudillo Aguilar 26/06/

96 CAPITULO 3. Respuestas Activas Las condiciones para que el IDS bloquee una IP son fáciles de deducir. El intruso simplemente envía paquetes que probablemente generarán alertas, mientras realiza un ping o una acción equivalente. Cuando el ping se detiene, el intruso sabe que él esta siendo bloqueado Observaciones sobre las Respuestas Activas Un correcto esquema de respuesta automática debería contemplar al menos los siguientes puntos: Probabilidad de que el ataque detectado sea un falso positivo. No todos los ataques que un sensor detecta tienen la misma probabilidad de serlo realmente: por ejemplo, alguien que busca en nuestros servidores web un CGI denominado phf (un programa que se encuentra en versiones antiguas de Apache, y que presenta graves problemas de seguridad) casi con toda probabilidad trata de atacar nuestros sistemas; en cambio, una alarma generada porque el sensor detecta un paquete ICMP de formato sospechoso no tiene por qué representar (y seguramente no lo hará) un verdadero ataque. Es necesario, o cuanto menos recomendable, asignar un peso específico a cada alarma generada en el sensor, y actuar sólo en el caso de que se detecte un ataque claro, o bien un evento que denote muy claramente un intento de intrusión; o bien varios menos sospechosos, pero cuya cantidad indique que no se trata de falsos positivos. Contemplar direcciones protegidas. Otro punto a tener en cuenta antes de lanzar una respuesta automática contra un potencial intruso es su origen; si se trata de una dirección externa, seguramente la respuesta será adecuada, pero si se trata de una interna a la red (o equivalentemente, de direcciones de empresas colaboradoras, aunque sean externas) la situación no es clara. Se debe plantear la posibilidad de que quizás se está bloqueando el acceso a alguien a quien, por los motivos que sea, no se debe bloquear. Aunque se trate de cuestiones más políticas que técnicas, es muy probable 40 LARSEN, Jason y HAILE, Jed. Understanding IDS Active Response Mechanisms [en línea]. Ultima actualización: Enero 29, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

97 CAPITULO 3. Respuestas Activas que en el IDS se deba establecer un conjunto de direcciones contra las que no se va actuar; si desde ellas se detecta actividad sospechosa, aunque se pueden preparar mecanismos que alerten a los responsables de seguridad. Establecer un límite al número de respuestas en un tiempo determinado. Dependiendo del entorno, se puede considerar una casualidad el recibir un ataque, desde dos o tres máquinas diferentes, al mismo tiempo; pero sin duda, más de este número resulta cuanto menos sospechoso. Un intruso puede simular ataques desde diferentes hosts de una forma más o menos sencilla, y, si el IDS se limita a bloquear direcciones (o redes completas), es fácil que una red se auto-provoque una importante negación de servicios contra potenciales usuarios legítimos, lo cual puede representar un ataque más importante que el que causaría ese mismo intruso si se le permitiera escanear la red. Si el sensor lanza demasiadas respuestas automáticas en un periodo de tiempo pequeño, el propio sistema debe encargarse de avisar a una persona que se ocupe de verificar que todo es normal. Es muy recomendable que ante cada respuesta se genere un aviso que pueda ser validado por un administrador de sistemas o por responsables de seguridad, mejor si es en tiempo real Adopción de Políticas de Respuestas Activas Para marcar diferencias comerciales en el mercado de IDS, muchos vendedores están agregando capacidades de respuesta a sus productos. El problema es que cualquier intruso, con conocimientos básicos de TCP/IP, puede fácilmente vencer estos mecanismos en forma directa, o provocar el bloqueo de la red tan frecuentemente que el administrador se ve forzado a deshabilitar esta opción. 41 VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Capítulo 18. Sistemas de detección de intrusos. Estrategias de respuesta. Página 335. Disponible en: es.tldp.org/manuales-lucas/doc-unixsec/unixsec-html/ Autor: Pablo Astudillo Aguilar 26/06/

98 CAPITULO 3. Respuestas Activas Al momento de establecer las políticas de utilización de mecanismos de respuestas activas, es importante que los administradores conozcan sus limitaciones, para evitar ser cegados por ellos Cronometraje Los métodos discutidos en esta sección son críticos en lo que al tiempo se refiere, es decir, un mecanismo de respuesta activo que reacciona después de un largo tiempo no es útil. Se debe notar, sin embargo, que el IDS reacciona después de que un evento peligroso ha tenido lugar. Esto significa que, incluso si la latencia es minimizada, el IDS podría no ser capaz de impedir que la intrusión en progreso se consume. Por ejemplo, cuando el IDS detecta un paquete que contiene una shellcode y envía paquetes RST para destruir la conexión, de todas formas la shellcode será ejecutada. Por lo tanto, el bloquear la comunicación entre el objetivo y el intruso es más bien para prevenir que este use la shell obtenida en el computador remoto, o aislar un computador que sufre una infección de gusano, para prevenir que infecte a otros hosts. Una solución a este problema podría ser bloquear al intruso en la etapa de preparación del ataque, por ejemplo, cuando se detecta un escaneo de puertos. Sin embargo, debido a que en los escaneos de puertos es fácil falsificar el origen, esto podría conducir a una situación de denegación de servicios en la propia red Denegación de Servicios autoprovocada Los IDS con subsistemas de respuestas activas, que utilizan el método de actualización de reglas del firewall, pueden ser abusados por un intruso a fin de causar una denegación de servicios. Por ejemplo, si un IDS es configurado para bloquear automáticamente cada dirección IP desde donde se origine un escaneo de puertos, un intruso puede fácilmente falsificar las direcciones origen con los hosts que él desea bloquear. Los servidores DNS son el ejemplo más común: un escaneo de puertos que falsifique la dirección del servidor DNS provocará que este sea bloqueado en el firewall, y ya que muchas aplicaciones (en el lado del cliente y del Autor: Pablo Astudillo Aguilar 26/06/

99 CAPITULO 3. Respuestas Activas servidor) dependen activamente de él, puede ocurrir una seria interrupción del servicio. Otra posible amenaza es congestionar el firewall con las reglas añadidas; debido a que los paquetes tienen que se comprobados contra un número grande de reglas, el tiempo de procesamiento aumenta, y así el rendimiento del firewall decrece. De acuerdo a estudios realizados sobre el comportamiento del firewall, su rendimiento cae significativamente cuando el conjunto de reglas es de varios centenares o más. En consecuencia, falsificando las direcciones de un número grande de hosts, los intrusos podrían incluso detener el firewall. Este problema puede ser prevenido usando reglas con tiempo de vida limitado, es decir, eliminándolas después de un tiempo dado, y/o limitando el número de reglas que pueden ser añadidas ZARASKA, Krzysztof. IDS Active Response Mechanisms: Countermeasure Subsytem for Prelude IDS [en línea]. Julio 9, Página 1. Disponible en: misc/lsm/2002/slides/krzysztof/lsm.pdf Autor: Pablo Astudillo Aguilar 26/06/

100 PARTE II: ANALISIS, DISEÑO, IMPLEMENTACIÓN Y PRUEBAS DEL NIDS Autor: Pablo Astudillo Aguilar 26/06/

101 CAPITULO 4. Análisis de la Red de la Universidad de Cuenca Capítulo 4. Análisis de la Red de la Universidad de Cuenca 4.1 Características generales Topología : Estrella Direcciones IP públicas : Bloque Servicios al público : Información en el WEB, Correo electrónico Sistemas de la Intranet : Sist. de Control de Gasto Interno (WEB) Sist. de Tesorería (WEB) Sist. de Mantenimiento (WEB) Sist. de Contabilidad Sist. de Rol de pagos (WEB) Sist. de Activos Fijos (WEB) Ancho de banda 3 Mbits simétrico. disponible: Horas pico de tráfico: 10h30, 16h00 (en promedio se alcanzan los 2Mbits de tráfico, ver Anexo 1) 4.2 Descripción de los Servidores Servidores/ Características ARQUITECTURA SISTEMA OPERATIVO APLICACION WEB Sun (RISC) Solaris 8 Apache 1.2 Aplicaciones Intel Pentium III Windows 2000 Server IIS, ASPX Correo Intel Pentium III Fedora Core 2 Exim 4.3 Bases de datos AS400 OS400 DB2 Usuarios Compaq Windows 2003 Dominio de Windows 2003 Proxy Intel Fedora Core 2 Squid, IPTABLES Autor: Pablo Astudillo Aguilar 26/06/

102 CAPITULO 4. Análisis de la Red de la Universidad de Cuenca 4.3 Diagrama de la DMZ de la Universidad de Cuenca Figura 4-1. Diagrama de la DMZ de la Universidad de Cuenca En la Figura 4-1 se puede observar que el NIDS a desarrollar se ubicará en la DMZ, detrás del firewall corporativo (red /28), y analizará todo el tráfico que llega a los servidores Web y Mail. Autor: Pablo Astudillo Aguilar 26/06/

103 CAPITULO 5. Requerimientos y Casos de Uso Capítulo 5. Requerimientos y Casos de Uso 5.1 Presentación general Este proyecto tiene por objeto crear un Sistema de Detección de Intrusiones basado en Red que se encargará de monitorear los paquetes de red en tiempo real y discriminará su accionar para detectar usos indebidos, en base a la comparación de estos con patrones de ataques conocidos (firmas, secuencias específicas de atributos dentro de los paquetes.), que estarán almacenados en una base de datos. 5.2 Cliente Universidad de Cuenca, Dpto. de Desarrollo Informático. 5.3 Metas En términos generales, la meta es la automatización de la detección de intrusiones en la Red de la Universidad de Cuenca. Más concretamente, la meta incluye: Detectar preámbulos de ataques. Detectar violaciones de seguridad. Proveer información útil sobre las intrusiones que ocurren. Detectar patrones de ataque. Incrementar la posibilidad de descubrir y castigar a los intrusos. Autor: Pablo Astudillo Aguilar 26/06/

104 CAPITULO 5. Requerimientos y Casos de Uso 5.4 Requisitos funcionales (Funciones del sistema) El NIDS deberá estar en capacidad de realizar las siguientes tareas: Ref # Función Categoría R1 Analizar tráfico de red en tiempo real. Oculta R2 Emitir alarmas en la consola del Administrador frente a Evidente actividad sospechosa o intrusiones en progreso. R3 Informar detalles de una intrusión como: origen, tipo, objetivo, Evidente avance, grado de peligro, etc. R4 Dar alternativas de respuesta frente a intentos de intrusión. Evidente R5 Responder a intrusiones automáticamente cuando el Evidente Administrador esta imposibilitado de hacerlo. R6 Registrar respuestas automáticas a intrusiones. Evidente R7 Reconstruir sesiones TCP/IP. Evidente R8 Actualizar la base de datos con nuevas firmas para detectar Evidente intrusiones. R9 Permitir configuración de respuestas automáticas frente a Evidente situaciones determinadas. R10 Gestionar historiales de alarmas. Oculta Autor: Pablo Astudillo Aguilar 26/06/

105 CAPITULO 5. Requerimientos y Casos de Uso 5.5 Requisitos no funcionales (Atributos del sistema) Los requisitos no funcionales son los atributos o características que definirán el comportamiento del NIDS: Atributo Detalles y restricciones de frontera Tiempo de respuesta El NIDS analizará todo el tráfico de la red en tiempo real. Fiabilidad Se asegurarán los registros de alarmas del NIDS. Exactitud Permitir a los administradores de seguridad analizar las intrusiones a la red. Interfaz Gráfica basada en ventanas y cuadros de diálogo; también ejecución y mensajes de alarma en modo texto. Plataforma Linux (Red Hat 9.0). Fuente de datos Paquetes de red. Técnica utilizada Detección de usos indebidos mediante comparación simple de firmas de ataques. Autor: Pablo Astudillo Aguilar 26/06/

106 CAPITULO 5. Requerimientos y Casos de Uso 5.6 Actores del Sistema Los actores del sistema son las entidades externas con las que este interactúa, de donde recibe los estímulos para realizar una u otra tarea. Los actores identificados en el entorno del NIDS son: Actor Actividades Servidor Un Servidor representa a cualquier computador dentro de la red que brinda un servicio. Además, el tráfico hacia él es alcanzable por el NIDS. Usuario Un Usuario representa a cualquier persona o sistema de software que usa los servicios brindados por los Servidores de la red. Este usuario puede ser interno a la red o externo, accediendo a través del Internet. Intruso Un Intruso es un Usuario (hacker, cracker, gusanos, sniffers, etc) que intenta cualquier conjunto de acciones que puede comprometer la integridad, confidencialidad o disponibilidad de una información o un recurso informático. Administrador Un Administrador representa a una persona que esta encargada del buen funcionamiento de la red y todos sus recursos. 5.7 Casos de uso Los casos de uso describe la secuencia de eventos de un actor (agente externo) que utiliza el sistema para completar un proceso. Son historias o casos de utilización de un sistema que ejemplifican e incluyen tácitamente los requerimientos en las historias que narran. A continuación se describen los Casos de Uso identificados en el entorno del NIDS: Autor: Pablo Astudillo Aguilar 26/06/

107 CAPITULO 5. Requerimientos y Casos de Uso Caso de uso 1: Monitorizar paquetes de red Actores: Usuario (iniciador), Servidor Tipo: Primario y esencial Descripción: Un Usuario negocia y establece una conexión con un Servidor de la red para utilizar los servicios que este proporciona. El NIDS monitorea los paquetes que el Usuario transmite y los envía al motor de análisis. Descripción paso a paso: 1. Este caso de uso comienza cuando un Usuario intenta establecer una conexión con cualquiera de los Servidores que la red expone al público en su DMZ. Para esto envía los paquetes de red que negocian esta conexión. 2. El NIDS, utilizando filtros de paquetes, recoge los datos que el Usuario transmite y los analiza, en busca de posibles intentos de intrusión. Esta tarea se realiza con todo el tráfico que el Usuario genere usando los servicios de la red. 3. El Servidor envía paquetes de respuesta a la solicitud; estas también son monitorizadas por el NIDS. 4. El caso de uso finaliza cuando la conexión con el Servidor termine por cualquier circunstancia. Caso de uso 2: Detectar intrusiones Actores: Usuario (iniciador), Servidor, Administrador Tipo: Primario y esencial Descripción: Un Usuario dispara este caso de uso cuando intenta explotar una vulnerabilidad en uno o varios Servidores de la red. El NIDS detecta estas acciones y advierte al Administrador mediante alarmas, que una intrusión ocurrió o está ocurriendo en esos momentos. Descripción paso a paso: 1. Un Usuario intenta vulnerar la seguridad de la red utilizando una firma de intrusión determinada, dependiendo del objetivo y tipo de ataque (denegación Autor: Pablo Astudillo Aguilar 26/06/

108 CAPITULO 5. Requerimientos y Casos de Uso de servicios, suplantación de identidad, uso de exploits, etc), contra uno o varios Servidores. 2. El NIDS detecta esta actividad maliciosa, en base a comparaciones del tráfico observado contra su base de datos de firmas de intrusión. 3. El NIDS registra la información relevante acerca de este evento (fecha y hora del evento, tipo, origen, objetivo, avance) en su base de datos. 4. El NIDS correlaciona la ocurrencia de este evento con los registros de eventos anteriores y chequea los valores umbral. 5. En caso de alcanzarse los valores umbral, el NIDS emite alarmas al Administrador en las que envía toda esta información registrada. Caso de uso 3: Responder a intrusiones Actores: Intruso, Administrador (iniciador) Tipo: Primario y esencial Descripción: El Administrador utiliza este caso de uso para bloquear una intrusión en progreso, o para evitar que el intruso comprometa en mayor grado los equipos de la red. El NIDS presenta al Administrador una lista con los procedimientos de respuesta (scripts) establecidos para el tipo de ataque detectado. Descripción paso a paso: Flujo básico 1. El NIDS lista en pantalla las alternativas de respuesta programadas para bloquear el tipo de intrusión detectado. 2. El Administrador selecciona la mejor alternativa de acuerdo a la situación. 3. El NIDS ejecuta el procedimiento de respuesta. Caminos alternativos En el paso 2, el Administrador podría no tener oportunidad de responder a la intrusión personalmente. Un ataque podría desarrollarse a cualquier hora del día, cuando no exista personal de seguridad revisando las alarmas del NIDS. En este caso, el NIDS podría ejecutar procedimientos de respuesta previamente Autor: Pablo Astudillo Aguilar 26/06/

109 CAPITULO 5. Requerimientos y Casos de Uso programados en forma autónoma. En este caso, se envía una notificación adicional al Administrador acerca de las acciones tomadas para bloquear el ataque. Diagrama de Casos de Uso: Escenario INTRUSION -iniciador -iniciador Monitorizar paquetes de red Usuario usa Servidor Detectar intrusiones -iniciador Responder a intrusiones Administrador Intruso Figura 5-1. Escenario INTRUSION Caso de uso 4: Mostrar sesión de intrusión Actores: Administrador (iniciador) Tipo: Secundario y esencial Descripción: El Administrador utiliza este caso de uso para conocer los detalles de las actividades efectuadas sobre los servicios de la red durante una intrusión, en una fecha y hora determinada. Ingresando estos datos, el NIDS mostrará los paquetes registrados, proporcionando opciones de filtrado. Descripción paso a paso: 1. El Administrador solicita al NIDS el registro de las intrusiones de una fecha determinada. 2. El NIDS toma la fecha ingresada y lista todas las intrusiones registradas. 3. El Administrador selecciona uno de los registros y solicita ver las actividades registradas en torno a esta intrusión. Autor: Pablo Astudillo Aguilar 26/06/

110 CAPITULO 5. Requerimientos y Casos de Uso 4. El NIDS muestra los paquetes almacenados durante la sesión del usuario donde se registró la intrusión seleccionada, reconstruyendo su escenario. Diagrama de Casos de Uso 2: Escenario ANALISIS DE INTRUSIONES Figura 5-2. Escenario ANALISIS DE INTRUSIONES Caso de uso 5: Registrar scripts de respuesta Actores: Administrador (iniciador) Tipo: Secundario y esencial Descripción: El Administrador utiliza este caso de uso para registrar en el sistema los scripts que se utilizarán como procedimientos de respuesta a intrusiones. Este registro se realiza como medida de seguridad para evitar que los scripts sean cambiados sin autorización del Administrador. Descripción paso a paso: 1. El Administrador solicita al NIDS registrar un nuevo script de respuesta, seleccionando el archivo correspondiente desde una ubicación en el disco. 2. El NIDS registra este archivo y su fecha de última modificación en su base de datos y lo hace disponible para configurarlo como procedimiento de respuesta a intrusiones. Caso de uso 6: Actualizar firmas Actores: Administrador (iniciador) Tipo: Primario y esencial Autor: Pablo Astudillo Aguilar 26/06/

111 CAPITULO 5. Requerimientos y Casos de Uso Descripción: El Administrador utiliza este caso de uso para dar mantenimiento (agregar, modificar y eliminar) a las reglas de la base de datos del NIDS. Tales actualizaciones a las firmas se obtienen como resultado del análisis de intrusiones o desde cualquier fuente fiable externa al sistema (grupos de seguridad en el Internet). Descripción paso a paso del caso Agregar nueva firma: 1. El Administrador ingresa una etiqueta y una descripción acerca de la nueva firma. 2. El Administrador ingresa los patrones que se buscarán en los paquetes capturados, siguiendo los siguientes pasos: a. Selecciona el protocolo que deberán tener los paquetes en una determinada capa del modelo TCP/IP. b. Selecciona los campos que se comprobarán en esta nueva firma. c. Para cada campo seleccionado, se establece una condición y un argumento que establecen el valor de verdad de la comparación. 3. El Administrador ingresa valores umbral que especifican el número de paquetes maliciosos que se deben detectar para que el NIDS emita alarmas. 4. El Administrador establece que procedimientos de respuesta se ejecutarán cuando esta firma sea detectada. Diagrama de Casos de Uso 3: Escenario ACTUALIZACIONES A continuación en la Figura 5-3. Escenario ACTUALIZACIONES Autor: Pablo Astudillo Aguilar 26/06/

112 CAPITULO 5. Requerimientos y Casos de Uso Figura 5-4, se presenta el modelo de casos de uso completo, junto con una descripción narrativa. Autor: Pablo Astudillo Aguilar 26/06/

113 CAPITULO 5. Requerimientos y Casos de Uso MODELO DE CASOS DE USO Figura 5-4. Modelo de Casos de Uso Autor: Pablo Astudillo Aguilar 26/06/

114 CAPITULO 5. Requerimientos y Casos de Uso Descripción del modelo Un Usuario dispara el caso de uso monitorizar paquetes de red cuando utiliza los servicios instalados en la DMZ y que son de libre acceso al público. Todo el tráfico que accede a los servidores es capturado y analizado por el NIDS en busca de patrones que indiquen una posible intrusión. Cuando se detecta tráfico malicioso, se identifica al usuario como Intruso, y en consecuencia, se dispara el caso de uso central en todo el modelo, detectar intrusiones. Es la función principal que debe cumplir el NIDS. Es disparado por el Intruso cuando este logra encontrar una vulnerabilidad en la red e inicia el proceso para explotarla, lo que de consumarse, ocasionará problemas diversos sobre los servicios implementados (servidores Web, mail, etc), según el tipo de ataque desarrollado. Inmediatamente después, el Administrador debería usar el caso de uso responder a intrusiones, el cual le permite ejecutar procedimientos que bloquearán el ataque y protegerán los recursos identificados como blancos. En algunas situaciones perfectamente establecidas en la configuración del NIDS, este podría responder a intrusiones en forma automática, es decir, sin la intervención directa del Administrador. Este sería un caso especial del caso de uso en el que el Administrador programa una respuesta automática a ciertos ataques considerados de alto riesgo. La actividad siguiente a toda intrusión, controlada o no, es el análisis forense. El Administrador utiliza el caso de uso Mostrar sesión de intrusión para realizar esta tarea. Este se encargará de mostrar los paquetes registrados que guardan relación con la intrusión. Como resultado del análisis forense, el Administrador puede descubrir nuevas firmas de intrusión que alimentarán la base de datos del NIDS. Para esta tarea, el Administrador utiliza el caso de uso Actualizar firmas. De considerarlo necesario, Autor: Pablo Astudillo Aguilar 26/06/

115 CAPITULO 5. Requerimientos y Casos de Uso puede también depurar los scripts de respuesta a intrusiones, para luego registrar los cambios utilizando el caso de uso Registrar scripts de respuesta. 5.8 Clasificación de los Casos de Uso En la siguiente tabla se muestra la clasificación, según su rango, de los casos de uso identificados. Esto permitirá planear de mejor manera los ciclos de desarrollo del NIDS. Clasificación Casos de Uso Justificación Alto Monitorizar paquetes de red (caso de uso de arranque) Tienen una fuerte repercusión en el diseño arquitectónico, incorporan muchas clases al dominio y requieren servicios de persistencia. Requieren Detectar intrusiones una investigación a fondo de tecnologías nuevas y riesgosas. Mediano Responder a intrusiones Representan procesos primarios en la línea de negocios. Mostrar sesión de intrusión Su definición depende de los casos de uso anteriores. Bajo Registrar scripts de respuesta Efecto mínimo en la arquitectura Actualizar firmas 5.9 Asignación de los Casos de Uso a los Ciclos de Desarrollo Se plantea el desarrollo del NIDS en cinco ciclos. Basados en la clasificación anterior, el desarrollo de los casos de uso de planifica de la siguiente manera: Autor: Pablo Astudillo Aguilar 26/06/

116 CAPITULO 5. Requerimientos y Casos de Uso CICLO 1 CICLO 2 CICLO 3 CICLO 4 CICLO 5 Monitorizar Detectar Detectar Responder a Registrar scripts paquetes intrusiones: intrusiones: intrusiones: de respuesta de red versión 2 versión 3 versión 2 Actualizar firmas Detectar Responder a Mostrar intrusiones: intrusiones: sesión de versión 1 versión 1 intrusión Autor: Pablo Astudillo Aguilar 26/06/

117 CAPITULO 6. Análisis del NIDS Capítulo 6. Análisis del NIDS 6.1 Modelo Conceptual Un modelo conceptual explica los conceptos significativos en el dominio del problema. Este modelo permite descomponer el espacio del problema en unidades comprensibles, además de contribuir a esclarecer la terminología o nomenclatura del dominio. Descripción del dominio del problema Un sistema de detección de intrusiones basado en red captura y analiza todos los paquetes que atraviesan un segmento, en busca de patrones predefinidos conocidos como firmas. Estas firmas consisten en ciertos valores en las cabeceras de paquetes maliciosamente forjados por intrusos, que son enviados con la finalidad de comprometer la seguridad de los servidores de la red, o desmejorar los servicios ofrecidos por los mismos. Un NIDS cuenta con una base de datos de estas firmas de ataque y su trabajo es compararlas con el tráfico capturado para detectar intentos de intrusión. Cuando el análisis refleja la coincidencia del contenido de un paquete con alguna de las firmas registradas, el NIDS emitirá una alarma al Administrador, informando los patrones encontrados, así como el origen y objetivo del ataque. Adicionalmente, es deseable que el NIDS disponga de procedimientos de respuesta que intenten bloquear en forma oportuna a los ataques, evitando que los servicios sean comprometidos seriamente. La captura del tráfico se realiza a través de un sniffer, que es un programa o librería que configura la interfaz de red en modo promiscuo, con lo que se escucha todo el tráfico de un segmento, cualquiera sea el destinatario del mismo. Autor: Pablo Astudillo Aguilar 26/06/

118 CAPITULO 6. Análisis del NIDS A continuación, en la Figura 6-1, se presenta el modelo conceptual del NIDS analizado, a la finalización del último ciclo de desarrollo. Autor: Pablo Astudillo Aguilar 26/06/

119 CAPITULO 6. Análisis del NIDS MODELO CONCEPTUAL Autor: Pablo Astudillo Aguilar 26/06/

120 CAPITULO 6. Análisis del NIDS Figura 6-1. Modelo Conceptual Autor: Pablo Astudillo Aguilar 26/06/

121 CAPITULO 6. Análisis del NIDS 6.2 Diagramas de Secuencia Los diagramas de secuencia de un sistema muestran gráficamente los eventos que fluyen de los actores al sistema. Sirven para investigar y definir el comportamiento de un sistema como una caja negra ; es decir, brinda una descripción de lo que hace, sin explicar la manera en que lo hace. A continuación, se presentan los diagramas de secuencia que indican el flujo de eventos de los casos de uso identificados. Autor: Pablo Astudillo Aguilar 26/06/

122 CAPITULO 6. Análisis del NIDS DIAGRAMA DE SECUENCIA 1. Casos de Uso: Monitorizar paquetes de red y Detectar intrusiones Figura 6-2. Diagrama de Secuencia 1. Casos de Uso "Monitorizar paquetes de red y "Detectar intrusiones" Autor: Pablo Astudillo Aguilar 26/06/

123 CAPITULO 6. Análisis del NIDS Descripción: 1. Se capturan los paquetes que el usuario envía al Servidor como producto del uso de sus servicios. 2. Se analizan las cabeceras y datos de estos paquetes en busca de coincidencias con las firmas de intrusión del NIDS. 3. En caso de un paquete contenga en sus cabeceras o datos una firma intrusión, se registra este Evento, almacenando los datos necesarios. 4. Este evento se somete a análisis para encontrar relaciones con otros eventos ocurridos. 5. Se emiten alarmas acerca del evento observado y su relación con otros eventos. 6. A partir de la detección de una firma, se almacenan los paquetes correspondientes a esa sesión para posterior análisis del Administrador. DIAGRAMA DE SECUENCIA 2. Caso de Uso: Responder a intrusiones Figura 6-3. Diagrama de Secuencia para el Caso de Uso Responder a intrusiones Descripción: 1. El NIDS muestra en pantalla al Administrador los procedimientos de respuesta configurados, si existen, para el tipo de firma detectada en ese momento. 2. El Administrador selecciona uno de ellos y ordena al NIDS ejecutarlo. Autor: Pablo Astudillo Aguilar 26/06/

124 CAPITULO 6. Análisis del NIDS DIAGRAMA DE SECUENCIA 3. Caso de Uso: Mostrar sesión de intrusión Figura 6-4. Diagrama de Secuencia para el Caso de Uso Mostrar sesión de intrusión Descripción: 1. El Administrador solicita al NIDS un reporte de las intrusiones detectadas, posiblemente especificando un intervalo de tiempo específico. 2. Una vez que el NIDS genera el reporte, el Administrador selecciona un registro particular y le ordena al NIDS mostrar los paquetes almacenados que guardan relación con la intrusión. DIAGRAMA DE SECUENCIA 4. Caso de Uso: Registrar scripts de respuesta Autor: Pablo Astudillo Aguilar 26/06/

125 CAPITULO 6. Análisis del NIDS Figura 6-5. Diagrama de Secuencia para el Caso de Uso Registrar scripts de respuesta Descripción: 1. El Administrador solicita al NIDS registrar un nuevo script como procedimiento de respuesta, seleccionándolo desde una ubicación en el disco. El NIDS guarda la ruta y la fecha de última modificación de este archivo. De esta forma, si al momento de ejecutar el script se detecta que las fechas no coinciden, la ejecución se cancela. 2. El Administrador registra los parámetros que debe recibir el script al momento de ejecutarse. DIAGRAMA DE SECUENCIA 5. Caso de Uso: Actualizar firmas Autor: Pablo Astudillo Aguilar 26/06/

126 CAPITULO 6. Análisis del NIDS Administrador NIDS registrardatosdescriptivos(etiqueta, descripcion) registrarpatrón(protocolo, campo, condición, argumento) establecerumbral(cantidadpaquetes) establecerprocedimientoderespuesta(scriptregistrado) Figura 6-6. Diagrama de Secuencia para el Caso de Uso Actualizar firmas Descripción: El Administrador solicita al NIDS ingresar o modificar una nueva firma de intrusión, para esto, sigue los siguientes pasos: 1. Ingresa una etiqueta y una descripción acerca de la nueva firma. 2. Ingresa los patrones que se buscarán en los paquetes capturados. 3. Ingresa valores umbral que especifican el número de paquetes maliciosos que se deben detectar para que el NIDS emita alarmas. 4. El Administrador establece que procedimientos de respuesta se ejecutarán cuando esta firma sea detectada. A continuación, se resumen las operaciones del sistema identificadas en los diagramas de secuencia: 1. capturarpaquete () 2. analizarpaquete (cabeceras) 3. registrareventodeintrusión (fecha-hora,tipo,origen,objetivo,avance) 4. correlacionareventodeintrusión(nuevoevento) 5. emitiralarmas () 6. almacenarsesióndeintruso (paquetes) 7. mostrarprocedimientosderespuesta () Autor: Pablo Astudillo Aguilar 26/06/

127 CAPITULO 6. Análisis del NIDS 8. ejectuarprocedimientoderespuesta (rutascript, parámetros) 9. mostrarreportedeintrusiones (fechadesde, fechahasta) 10. mostrarsesióndeintrusión () 11. registrarscriptderespuesta (rutaarchivo,fechaultimamodificación) 12. registrarparámetrosdescript (parámetros) 13. registrardatosdescriptivos (etiqueta,descripción) 14. registrarpatrón (protocolo,campo,condición,argumento) 15. establecerumbral (cantidadpaquetes) 16. establecerprocedimientoderespuesta (scriptregistrado) 6.3 Contratos Los contratos sirven para definir el comportamiento de un sistema; definen el efecto que sobre el tienen las operaciones. En esta sección se presentan los contratos establecidos para las operaciones más relevantes del sistema. Contrato 1. Nombre: capturarpaquete() Responsabilidades: Capturar la llegada de un paquete desde la interfaz de red. Tomar los valores de sus cabeceras y asignarlos a estructuras de datos adecuadas. Determinar la pila de protocolos que conforman este paquete. Notas: Se utilizará la librería libpcap para implementar esta operación. Excepciones: 1. El tipo de paquete no es soportado por el NIDS. En este caso, el paquete es ignorado. Poscondiciones: 1. Se creó una instancia de Paquete. 2. Se crearon varias instancias de CapaTCPIP, de acuerdo al número de capas de protocolo del Paquete. 3. Se asociaron las instancias de CapaTCPIP al Paquete. Autor: Pablo Astudillo Aguilar 26/06/

128 CAPITULO 6. Análisis del NIDS Contrato 2. Nombre: analizarpaquete (cabeceras) Responsabilidades: Comparar los valores de cabecera del paquete con todas las firmas registradas en el NIDS. Notas: Usar el algoritmo de comparación de patrones en contexto de conexión. Excepciones: Poscondiciones: 1. Si el análisis del paquete detectó una firma de intrusión en su contenido: a. Se creó una instancia EventoDeIntrusión. b. Se asignó la fecha-hora, tipo, origen y objetivo del evento registrado a EventoDeIntrusion.fecha-hora,EventoDeIntrusion.tipo, EventoDeIntrusion.origen, EventoDeIntrusion.objetivo, respectivamente. c. Se asoció una instancia Paquete a la instancia EventoDeIntrusión. 2. Si el análisis del paquete no detectó ninguna firma: a. Se eliminó una instancia Paquete. La operación del sistema registrareventodeintrusión ( ) está también incluida en el contrato anterior. Contrato 3. Nombre: correlacionareventodeintrusión(nuevoevento) Responsabilidades: Comparar el nuevo evento de intrusión con aquellos registrados anteriormente. Comprobar si el umbral de cantidad paquetes, correspondiente a la firma de este evento, ha sido superado. Notas: Excepciones: Poscondiciones: 1. Si se detecta que el umbral de una firma se ha superado: a. Se creó una instancia Intrusión. Autor: Pablo Astudillo Aguilar 26/06/

129 CAPITULO 6. Análisis del NIDS b. Se asoció una instancia EspecificacióndeIntrusión a la instancia Intrusión. Contrato 4. Nombre: emitiralarmas () Responsabilidades: Generar alarmas para advertir al Administrador acerca de la intrusión detectada. Notas: Como medio de entregar las alarmas hacia el Administrador se utilizarán: logs del sistema, ventanas emergentes, mails y mensajes a celular. Estos medios se podrán personalizar para cada firma por separado. Excepciones: 1. Los subsistemas de syslog y mail del sistema operativo, en los que se basa este contrato no están activos. En este caso, las alarmas no llegarán al Administrador a través de estos canales. Poscondiciones: 1. Se creó una instancia Alarma. 2. Se asoció una instancia de Alarma a Intrusión. Contrato 5. Nombre: ejectuarprocedimientoderespuesta (rutascript, parámetros) Responsabilidades: Ejecutar el script de respuesta configurado o seleccionado por el Administrador. Notificar errores en la ejecución de los scripts. Notas: Excepciones: 1. El script no se encuentra en la ruta registrada. 2. Se detecta que la fecha de modificación del script no coincide con la fecha registrada, es decir, no se ha notificado al NIDS de cambios en el script de respuesta. Poscondiciones: 1. Se creó una instancia de ScriptDeRespuesta. Autor: Pablo Astudillo Aguilar 26/06/

130 CAPITULO 6. Análisis del NIDS 2. Se asignó rutascript a ScriptDeRespuesta.rutaScript. 3. Se asoció una instancia de ScriptDeRespuesta a la Intrusión. Contrato 6. Nombre: registrarscriptderespuesta(rutascript,fechaultimamodificación) Responsabilidades: Registrar un nuevo script en el NIDS para que pueda ser configurado como procedimiento de respuesta a intrusiones. Actualizar el registro de un script, tomando su nueva fecha de última modificación, luego de haber sido alterado por el Administrador. Notas: El Administrador seleccionará desde una ventana la ubicación del script a registrar. Excepciones: Poscondiciones: 1. Si se trata de un nuevo Script, se crea una instancia ScriptDeRespuesta. 2. Si se trata de un nuevo Script, se asignó rutascript a ScriptDeRespuesta.rutaScript 3. Se asignó fechaultimamodificación a ScriptDeRespuesta.fechaUltimaModificacion. Contrato para inicio Nombre: inicio() Responsabilidades: Inicializar el NIDS. Notas: Excepciones: 1. Si la conexión a la base de datos falla, el sistema no puede iniciar. Poscondiciones: 1. Se crearon instancias Sniffer, Analizador, GestorDeEventos y GestorDeAlarmas. 2. Se crearon instancias Protocolo y CamposCabecera. 3. Se asociaron instancias CamposCabecera a las instancias Protocolo. Autor: Pablo Astudillo Aguilar 26/06/

131 CAPITULO 6. Análisis del NIDS 4. Se cargaron de la base de datos y se crearon instancias Firma. Autor: Pablo Astudillo Aguilar 26/06/

132 CAPITULO 7. Diseño del NIDS Capítulo 7. Diseño del NIDS 7.1 Diagramas de Colaboración Los diagramas de colaboración sirven para describir las interacciones entre los objetos en un formato de grafo o red. A continuación se presentan los diagramas de interacción para los contratos establecidos en la fase de análisis. Diagrama de Colaboración 1. Contrato: capturarpaquete () 1.2: crear() Figura 7-1. Diagrama de Colaboración para el Contrato capturarpaquete () Diagrama de Colaboración 2. Contrato: analizarpaquete (cabeceras) Autor: Pablo Astudillo Aguilar 26/06/

133 CAPITULO 7. Diseño del NIDS Figura 7-2. Diagrama de Colaboración para el Contrato analizarpaquete (cabeceras) Autor: Pablo Astudillo Aguilar 26/06/

134 CAPITULO 7. Diseño del NIDS Diagrama de Colaboración 3. Contrato: correlacionareventodeintrusión (nuevoevento) y emitiralarmas () 1: correlacionareventodeintrusión(nuevoevento) 1.a [umbral superado]: crear(origen, objetivo) NIDS GestorDeEventos Intrusión 1.b.1: crear(fecha-hora, nivel) GestorDeAlarmas Alarma Figura 7-3. Diagrama de Colaboración para los Contratos correlacionareventodeintrusión (nuevoevento) y emitiralarmas () Autor: Pablo Astudillo Aguilar 26/06/

135 CAPITULO 7. Diseño del NIDS Diagrama de Colaboración 4. Contrato: ejectuarprocedimientoderespuesta (rutascript,parámetros) Figura 7-4. Diagrama de Colaboración para el Contrato ejectuarprocedimientoderespuesta (rutascript,parámetros)" 7.2 Diagrama de Clases En la presente sección se presentan el diagrama de clases del NIDS y una descripción general de las funciones que cumple cada clase. Autor: Pablo Astudillo Aguilar 26/06/

136 CAPITULO 7. Diseño del NIDS Diagrama de Clases Autor: Pablo Astudillo Aguilar 26/06/

137 CAPITULO 7. Diseño del NIDS Figura 7-5. Diagrama de Clases Autor: Pablo Astudillo Aguilar 26/06/

138 CAPITULO 7. Diseño del NIDS Descripción de las Clases del diseño IDS La clase IDS representa el hilo de ejecución principal del sistema. Genera los hilos de las clases Sniffer, Analizador y GestorEventos. Desde su constructor, se encarga de obtener toda la información necesaria desde la base de datos: Firmas, Niveles de Alarma, Protocolos, Scripts, Ataques; y también los parámetros generales como: direcciones monitoreadas, rutas de scripts, mail de administradores, filtro del sniffer, etc. Existirá un único objeto de esta clase por cada arranque del sistema, su destrucción implica el cierre de la aplicación. Firma La clase Firma representa un contenedor de patrones que detectan un intento de intrusión determinado. Además, almacena un vector de niveles de firma que miden el avance de una intrusión en el tiempo. Ataque La clase Ataque se utiliza para categorizar en un nivel macro a las firmas de intrusiones registradas, asignándoles un objeto de esta clase para denotar el tipo de ataque que detectará la firma. NivelFirma Los objetos de la clase NivelFirma representan los diversos grados de ataque en que puede incurrir un intruso utilizando una firma determinada. Una firma tiene, al menos, un nivel de firma, cuyo umbral de cantidad de paquetes debe ser al menos 1. El sistema asigna a cada objeto de esta clase un vector de objetos ScriptsRespuesta, que son los mecanismos de respuesta que se ejecutarán cuando el umbral de cantidad sea alcanzado. Autor: Pablo Astudillo Aguilar 26/06/

139 CAPITULO 7. Diseño del NIDS NivelAlarma La clase NivelAlarma provee de un medio para categorizar la gravedad y avance de una intrusión. El administrador establecerá un grupo de objetos de esta clase que definirán el grado de importancia de las firmas detectadas. Luego, asignará para cada objeto NivelFirma un puntero a uno de los objetos NivelAlarma establecidos. El objeto principal IDS se encarga de crear un vector de estos objetos al arrancar el sistema. CapaTCPIP La clase CapaTCPIP se encarga de agrupar los patrones de una firma para el proceso de análisis. Patron Los objetos de la clase Patron representan los valores y condiciones que se deben observar en las cabeceras de los paquetes para que un objeto Evento sea creado. Asocia un objeto CampoProtocolo con una condición y un argumento; estos tres elementos son utilizados por el objeto Analizador para realizar las comparaciones. Protocolo La clase Protocolo provee propiedades y métodos para obtener información sobre los protocolos que organizan la información en la cabecera de los paquetes. De acuerdo a la pila de protocolos de cada uno, se decidirá si es factible o no compararlos con las firmas de intrusiones almacenadas. CampoProtocolo La clase CampoProtocolo se encarga de almacenar información relevante sobre los campos de cabecera de los protocolos reconocidos por el sistema. El objeto principal IDS forma un vector de objetos Protocolo, cada uno con un vector de objetos CampoProtocolo, al iniciar el sistema. Autor: Pablo Astudillo Aguilar 26/06/

140 CAPITULO 7. Diseño del NIDS Sniffer La clase Sniffer se encarga de la captura de los paquetes desde la interfaz de red. Esta clase crea un objeto Paquete cada vez que la interfaz de red (casi siempre en modo promiscuo) genera una interrupción. Estos objetos son almacenados en un vector global, de tal forma que el objeto Analizador realice su tarea de verificación de firmas. Se basa en la librería libpcap para la captura de paquetes. Existirá un único objeto de esta clase, creado (por la clase IDS) en el arranque del sistema, y trabaja en un hilo de ejecución independiente. Paquete La clase Paquete proporciona métodos sencillos para acceder a los valores de cabecera de los paquetes capturados por el objeto Sniffer. Analizador La clase Analizador se ejecuta en un hilo independiente, y se encarga del análisis de los paquetes que obtiene del Sniffer. Este análisis consiste en la comparación de los valores de firma con las cabeceras de estos paquetes. Si encuentra coincidencias, crea objetos Evento y los almacena en un vector global de la aplicación. Existirá un único objeto de esta clase, creado (por la clase IDS) al iniciar el sistema. Evento Los objetos de la clase Evento representan la ocurrencia de los patrones de una firma en uno de los paquetes analizados. Se encargan de mantener información relevante sobre este hecho. GestorEventos La clase GestorEventos se encarga de correlacionar los objetos Evento creados por el objeto Analizador. Esta tarea consiste en comprobar cuando son alcanzados los valores umbral de la Firma (a la que corresponden estos eventos), para entonces crear los objetos Alarma y GestorAlarmas correspondientes, y almacenarlos en un vector global de la aplicación. Existirá un único objeto de esta clase, creado (por la Autor: Pablo Astudillo Aguilar 26/06/

141 CAPITULO 7. Diseño del NIDS clase IDS) en el arranque del sistema, y trabaja en un hilo de ejecución independiente. FirmaSimple La clase FirmaSimple se utiliza para agrupar los eventos asociados a firmas con patrones simples. Una firma simple es aquella que no posee patrones que utilicen la condición de 'igual valor'. Esta condición se usa cuando se desea que el valor de un campo de cabecera determinado sea igual en todos los paquetes que coinciden con una firma. FirmaCompuesta La clase FirmaCompuesta se utiliza para agrupar los eventos asociados a firmas con patrones que utilizan la condición de 'igual valor'. FirmaEspecifica La clase FirmaEspecifica representa los valores de los campos que se mantienen constantes entre los objetos Evento que posee. Alarma Los objetos de la clase Alarma son creados cuando el primer nivel de cualquier firma de intrusión ha sido alcanzado. Almacena en un vector de instancias los niveles de firma que se alcanzan, conforme se superen los umbrales de cantidad de paquetes establecidos para ellos. InstanciaAlarma Un objeto de la clase InstanciaAlarma almacena información relevante sobre los objetos Evento que provocaron su creación. Son creados por el objeto GestorEventos para indicar que el umbral de un nivel de firma se ha alcanzado. En términos generales, se puede decir que el conjunto de Eventos relacionados forma un objeto InstanciaAlarma, y el conjunto de objetos InstanciaAlarma relacionados forman un objeto Alarma. Autor: Pablo Astudillo Aguilar 26/06/

142 CAPITULO 7. Diseño del NIDS GestorAlarmas Los objetos de la clase GestorAlarmas son creados por los objetos Alarma cuando se detecta una instancia de intrusión en los paquetes analizados. Su tarea principal es notificar al administrador sobre la intrusión, utilizando los mecanismos programados para este nivel de firma. Estos mecanismos pueden ser: logs del sistema, mails, mensajes SMS y ventanas emergentes. Para que estas notificaciones no interrumpan el análisis del tráfico que se mantiene constante, los objetos de esta clase se ejecutan en hilos independientes. LogSistema La clase LogSistema provee una interfaz con el sistema operativo y con su subsistema de logs, realizando las llamadas necesarias para registrar una alarma. Mail La clase Mail provee métodos que habilitan al sistema para enviar de correo electrónico. Se basa en la librería libvmime. Script Los objetos de la clase Script representan los archivos ejecutables que se utilizarán como mecanismos de respuesta a intrusiones. La clase principal IDS se encarga de crear un vector de este tipo de objetos, uno por cada registro en la base de datos, al iniciar el sistema. ParametroScript La clase ParametroScript es utilizada para representar la información de los parámetros que se configuran en cada objeto Script. ScriptRespuesta La clase ScriptRespuesta representa una asociación entre un script registrado por el administrador y el nivel de una firma. Los objetos de esta clase almacenan información relevante de esta asociación, tales como la acción que se adoptará para Autor: Pablo Astudillo Aguilar 26/06/

143 CAPITULO 7. Diseño del NIDS este script cuando el nivel de firma se alcance y el tiempo que se debe esperar para su ejecución. GestorRespuestas Los objetos de la clase GestorRespuestas son creados por los objetos Alarma cuando se alcanza una instancia de intrusión en los paquetes analizados. Su tarea principal es conducir la ejecución de los scripts de respuesta, representados por un vector de objetos Respuesta, programados para este nivel de firma. Para que la ejecución de estos scripts no interrumpa el análisis del tráfico que se mantiene constante, los objetos de esta clase se ejecutan en hilos independientes. Respuesta La clase Respuesta provee comunicación con el sistema operativo para la ejecución de scripts. Es la encargada de realizar la llamada al sistema, concatenando los argumentos, para la ejecución de estos archivos. Argumento La clase Argumento se encarga de almacenar la forma en que se configuraron los parámetros de un script de respuesta a intrusiones. Los parámetros se pueden configurar como dinámicos o estáticos. Los parámetros dinámicos toman sus valores argumento desde los campos de cabecera establecidos en la antes mencionada configuración; mientras que los parámetros estáticos son establecidos en un valor que no cambia con el tráfico observado. TipoDato La clase TipoDato provee funciones virtuales para comparación de patrones de firma con campos de cabecera. Su función principal es habilitar el uso del polimorfismo en estas funciones, redefiniéndolas en las clases hijas TipoEntero, TipoCadena y TipoDireccionIP. Autor: Pablo Astudillo Aguilar 26/06/

144 CAPITULO 7. Diseño del NIDS TipoCadena La clase TipoCadena se utiliza para representar datos de campos de cabecera que pueden ser expresados como cadenas de caracteres. Ejemplo: campo 'datos' de los protocolos en la capa de aplicación. TipoEntero La clase TipoEntero se utiliza para representar datos enteros de campos de cabecera. Ejemplo: bandera 'SYN' del protocolo TCP. TipoDireccionIP La clase TipoDireccionIP se utiliza para representar datos de campos de cabecera con formato de dirección IP. Ejemplo: campo 'ip_scr' del protocolo IP. Entidad La clase Entidad provee una abstracción de los atributos y métodos relacionados con el almacenamiento en base de datos de las clases especializadas. 7.3 Diagrama de Base de Datos En esta sección, se presenta la base de datos relacional del NIDS y se explica el propósito de sus tablas. Autor: Pablo Astudillo Aguilar 26/06/

145 CAPITULO 7. Diseño del NIDS Diagrama de Bases de Datos Autor: Pablo Astudillo Aguilar 26/06/

146 CAPITULO 7. Diseño del NIDS CP Protocolos Id Acronimo Descripcion Capa Puerto Numero ParametrosScript CP,CE1 ScrId CP ParametroId Nombre Secuencia CamposCabecera CP,CE1 PrtId CP CampoId Nombre Tamaño Tipo Secuencia CampoFirma TieneReflexivo Argumentos CP,CE1 ScrFirmaId CP,CE1 ScrNivelId CP,CE1,CE2 ScriptId CP,CE2 PrmParametroId CE3 CE3 CmpProtocoloId CmpCampoId ValorEstatico CP CE2 Id Patrones CP,CE1 CmpProtocoloId CP,CE1 CmpCampoId CP,CE2 FrmId Condicion Valor Firmas AtqId Etiqueta Descripcion UmbralTiempo PilaProtocolos Estado CP CP Ataques Id CE1 Descripcion Id Eventos FrmId DireccionIpOrigen DireccionIPDestino FechaHoraDetectado Parametros EstadoAnalizador EstadoSniffer DireccionesMonitoreadas ActivarRespuestas RutaScriptsRespuestas MailAdministradores MailCelularAdministradores TiempoVentanasAlarma FiltroSniffer InterfaceRed EventosAlarma CP,CE1 EvnId CP,CE2 InsAlarmaId CP,CE2 InsInstanciaId CP Id Scripts NombreArchivo FechaModificacion EstadoArchivo ScriptsFirma CP,CE2 NvlFirmaId CP,CE2 NvlNivelId CP,CE1 ScrId Accion Secuencia TiempoEspera NivelesFirma CP,CE2 FrmId CP NivelId CE1 NvlId UmbralCantidad FormasAlerta Respuestas CP Id CP,CE1 InsAlarmaId CP,CE1 InsInstanciaId ScriptEjecutado FechaHora Resultado Notas InstanciasAlarma CP,CE1 AlrId CP InstanciaId TiempoCreacion NivelFirma NivelFirmaUmbralCantidad NivelFirmaFormasAlerta NivelAlarma CP NivelesAlarma Id Nombre Descripcion FormasAlerta ColorAsociado Secuencia Figura 7-6. Base de Datos del NIDS CP Id Alarmas TiempoCreacion FirmaEtiqueta FirmaDescripcion FirmaUmbralTiempo Autor: Pablo Astudillo Aguilar 26/06/

147 CAPITULO 7. Diseño del NIDS Descripción de las Tablas de la Base de Datos 1. Protocolos: Almacena los protocolos sobre los cuales el NIDS tiene registradas sus firmas de intrusión. Conforme se diversifican los servicios de la red, las firmas tienen que ir ampliándose para cubrir nuevos protocolos. Los atributos más importantes son Puerto y Número, ya que sirven para identificar los protocolos que viajan en los paquetes. 2. CamposCabecera: Almacena los campos de las cabeceras de los protocolos. 3. Firmas: Almacena información descriptiva de las Firmas de intrusión. 4. Patrones: Unida a la tabla Firmas forma los patrones que se busca en el interior de los paquetes. Esta tabla registra que campos de que protocolos serán comparados con que valores. Precisamente, este es el propósito de los campos Condición y Valor. 5. NivelesFirma: Su propósito es almacenar valores umbrales para establecer niveles de progreso de un ataque. El campo UmbralCantidad registra cuántos paquetes deben detectarse para alcanzar este nivel de firma. Nótese que este umbral puede tener el valor de 1, es decir, basta con un solo paquete para deducir una intrusión. 6. NivelesAlarma: Sirve para diferenciar los diferentes niveles de gravedad entre varias intrusiones o niveles de firma. Personaliza también las formas de alerta que se efectuarán al detectarse una intrusión. 7. Ataques: Sirve para catalogar las firmas de intrusiones en grandes subgrupos que tienen características similares. 8. Eventos: Almacena información acerca de los paquetes que coincidieron con alguna firma. 9. InstanciasAlarmas: Se crea una fila cada vez que una intrusión ha alcanzado un nivel de firma establecido. 10. Alarmas: Sirve para agrupar las Instancias de Alarma, para salvar el recuerdo de su relación. 11. EventosAlarma: Relaciona las Instancias de Alarma con los eventos que las provocaron. Autor: Pablo Astudillo Aguilar 26/06/

148 CAPITULO 7. Diseño del NIDS 12. Scripts: Guarda el registro de los scripts seleccionados del disco para ser utilizados como procedimientos de respuesta a intrusiones. 13. ParametrosScript: Almacena los registros de los parámetros que necesita cada script para poder ejecutarse. 14. ScriptsFirma: Guarda la configuración de que scripts deben ejecutarse cuando una intrusión ha alcanzado un nivel de firma determinado. 15. Argumentos: Registra que campos de los paquetes se enviarán como parámetros para que se ejecute un script. Estos valores también pueden ser configurados manualmente como valores estáticos. 16. Respuestas: Registra los scripts de respuesta ejecutados, la fecha y la hora en la que se ejecutaron, así como si se lograron ejecutar o hubo algún problema externo al NIDS. 7.4 Funcionamiento en tiempo real En la implementación del NIDS se debe considerar que este debe analizar los paquetes capturados en tiempo real, es decir, inmediatamente después de subirlos a memoria, o con un retardo mínimo, de acuerdo a la cantidad de firmas de intrusión registradas. Esto permitirá que la notificación mediante alarmas a los administradores y los mecanismos de respuesta actúen a tiempo y sean efectivos. 7.5 Ambiente gráfico de la herramienta Las tareas de configuración y administración del NIDS se realizan a través de una interfaz gráfica (ventanas, botones, etc.) elaborada para el escritorio KDE. Además, el programa funciona como demonio, ocultándose en la bandeja del sistema. También se puede ejecutar el NIDS a través de la línea de comandos, en una sesión sin entorno gráfico, aunque las opciones de asistentes para ejecución de scripts de respuesta, así como las de configuración y administración, no están disponibles. Autor: Pablo Astudillo Aguilar 26/06/

149 CAPITULO 7. Diseño del NIDS 7.6 Configuración de respuestas automáticas El objetivo de esta funcionalidad es que el administrador pueda configurar el NIDS para ejecutar procedimientos de respuesta en forma autónoma, cuando determinados patrones de intrusión sean detectados. Se pueden especificar intervalos de tiempo entre la ejecución de los scripts, lo que permite personalizar aún más el bloqueo de los ataques. Cuando el NIDS ejecute procedimientos de respuesta automáticamente, notificará al administrador de tales acciones, a través de mensajes en pantalla, mails y logs. 7.7 Asistente para responder a ataques Este asistente consiste en una ventana emergente, junto al icono del NIDS en la bandeja del sistema, que además de los datos de la intrusión detectada, lista los procedimientos de respuesta (scripts) adecuados para bloquear el ataque. Estos procedimientos son configurados como sugeridos por el administrador, de tal forma que, al momento de la intrusión, él decida cual o cuales de ellos ejecutar. 7.8 Diagnóstico de vulnerabilidades después de un ataque El NIDS dispone de una herramienta de reportes de las intrusiones detectadas en un periodo de tiempo especificado. A través de esta opción, se listan los eventos que generaron una alarma determinada, haciendo posible determinar las vulnerabilidades que el intruso aprovechó para intentar alcanzar sus objetivos. Autor: Pablo Astudillo Aguilar 26/06/

150 CAPITULO 8. Implementación y Pruebas Capítulo 8. Implementación y Pruebas En este capítulo se describirá la fase de implementación del NIDS, el lenguaje y las herramientas utilizadas para este efecto. 8.1 Plataforma El presente proyecto NIDS se desarrolla para plataformas Linux, en su distribución Red Hat, versión Base de Datos La base de datos elegida para implementar la capa de almacenamiento es el PostgreSQL versión 7.4. El soporte de procedimientos almacenados y su lenguaje procedural PL/pgSQL facilitan el desarrollo en capas de las aplicaciones. La librería utilizada para acceder e interactuar con los datos es la libpqxx. 8.3 Lenguaje de Programación El lenguaje seleccionado para la implementación es el C++. Las razones para esta elección son las siguientes: El poder de procesamiento a bajo nivel que proporciona este lenguaje. Es orientado a objetos. Se puede realizar trabajo intenso con variables apuntador. Buen soporte de librerías de objetos de almacenamiento (STL). 8.4 Interfaz Gráfica La interfaz gráfica se desarrolla para el escritorio KDE versión 3.1., utilizando las librerías Qt 3.1. La herramienta para el diseño de los formularios es el Qt Designer. Autor: Pablo Astudillo Aguilar 26/06/

151 CAPITULO 8. Implementación y Pruebas 8.5 Herramienta de desarrollo Como entorno de desarrollo se utiliza el KDevelop versión 3.0. Este IDE ofrece varias ventajas a los desarrolladores, como por ejemplo: Entorno de desarrollo agradable y fácil de utilizar; además de muy personalizable. Integración con doxygen como herramienta de documentación. Asistente para empaquetado y distribución de aplicaciones. Control de versiones de la aplicación. Editor con opciones de finalización automática de código al llamar a funciones miembro de clases. Integración con la aplicación Qt Designer para la elaboración de la interfaz de usuario. 8.6 Multihilo El presente proyecto NIDS fue concebido utilizando los conceptos de programación multihilo, que dividen la ejecución central del programa en varios hilos de ejecución independientes, los cuales realizan una tarea determinada. A grandes rasgos, existen 5 hilos principales: El objeto IDS que administra todas las actividades del NIDS. El objeto Sniffer que obtiene los paquetes de la red. El objeto Analizador que compara las firmas con las cabeceras de los paquetes y genera eventos. El objeto GestorEventos que correlaciona los eventos creados. La interfaz gráfica de usuario. Durante el funcionamiento del sistema, nuevos hilos de ejecución pueden ser creados, tanto para emisión de alarmas como para responder a intrusiones; sin embargo, estos hilos tienen un tiempo de vida finito, que dura hasta que su tarea se ha terminado. Autor: Pablo Astudillo Aguilar 26/06/

152 CAPITULO 8. Implementación y Pruebas 8.7 Pruebas Las pruebas al NIDS se realizaron utilizando las siguientes herramientas: nmap 3.0: permite a los administradores de sistemas y a individuos curiosos buscar en redes grandes para determinar que hosts están habilitados y los servicios que estos ofrecen. syn flooder 1.6: satura los recursos de sockets del servicio destino. Esto provoca que el servicio no acepte más clientes. hping2.0.0: es una herramienta de red capaz de enviar paquetes TCP/IP personalizados y mostrar las respuestas del objetivo como lo hace el programa ping. nemesis 1.4: provee una interfase para armar y enviar una variedad de tipos de paquetes arbitrarios Pruebas de Escaneos de Puertos (nmap) Con la herramienta nmap se pueden lograr una amplia variedad de escaneos de puertos; a continuación se listan los más utilizados: Escaneo TCP connect(): $ nmap -vv -P0 -st xxx.xxx.xxx.xxx Escaneo TCP SYN: $ nmap -vv -P0 -ss xxx.xxx.xxx.xxx Escaneo TCP FIN: $ nmap -vv -P0 -sf xxx.xxx.xxx.xxx Escaneo ACK: $ nmap -vv -PT sw xxx.xxx.xxx.xxx Escaneo NULL: $ nmap -vv -P0 -sn xxx.xxx.xxx.xxx Escaneo XMAS: $ nmap -vv -P0 -sx xxx.xxx.xxx.xxx Escaneo UDP: $ nmap -vv -P0 -su xxx.xxx.xxx.xxx Saturación de conexiones (syn flooder) La herramienta syn flooder tiene las siguientes opciones y sintaxis: C:> syn.exe <objetivo> [opciones] Autor: Pablo Astudillo Aguilar 26/06/

153 CAPITULO 8. Opciones: -S: aleatoria). -p: -s: -n: -d: Implementación y Pruebas IP falsificada (0 es el valor por defecto y se envía una ip origen Lista de puertos destino separados por coma (0 es el valor por defecto y se envía los paquetes a puertos destino aleatorios). Lista de puertos origen separados por coma (0 es el valor por defecto y se envían los paquetes desde puertos origen aleatorios). Número de paquetes (0 es el valor por defecto y se envían paquetes indefinidamente) Demora (en milisegundos, 0 es el valor por defecto). Ejemplo: C:\> syn p 21,23,80,110 Descripción: - Objetivo: IP origen: Aleatoria - Puertos destino: 21, 23, 80, Puertos origen: Aleatorios - Cantidad: Indefinido - Demora: 0 mseg. (sin demora entre paquetes) Direcciones IP y Puertos reflexivos (hping2) Un ejemplo de utilización de hping2 para generar una firma conocida es generar un paquete con direcciones IP origen y destino iguales. Esto se realiza de la siguiente manera: $ hping2 spoof c 1 Este comando envía 1 paquete que tienen como direcciones ip origen y destino la Autor: Pablo Astudillo Aguilar 26/06/

154 CAPITULO 8. Implementación y Pruebas También se pueden generar paquetes que presenten el mismo número de puerto como origen y destino; utilizando las siguientes opciones: $ hping2 s 80 p Cadenas sospechosas en payload (nemesis) Con la herramienta nemesis es posible enviar un archivo cualquiera como el payload de un paquete TCP. Se utilizó esta opción para probar que el NIDS detecte cadenas de exploit en los paquetes que analiza. Asumiendo la existencia de un archivo llamado payload, que contiene la cadena de texto /bin/bash, la sintaxis para enviar este archivo hacia el objetivo utilizando nemesis es la siguiente: $ nemesis tcp y 80 P payload Con la opción y se especifica el puerto destino del paquete, es decir, la pila destino lo interpretará como un paquete HTTP. La opción P recibe como argumento el nombre de un archivo, que será enviado como el payload del paquete TCP a la máquina objetivo Autor: Pablo Astudillo Aguilar 26/06/

155 CONCLUSIONES PARTE III: CONCLUSIONES, RECOMENDACIONES, BIBLIOGRAFIA Y ANEXOS. Autor: Pablo Astudillo Aguilar 26/06/

156 CONCLUSIONES CONCLUSIONES 1. El Sistema de Detección de Intrusiones basado en red implementado, complementa la tarea del firewall en la seguridad perimetral de la Universidad de Cuenca, capturando y analizando en tiempo real los paquetes que atraviesan la DMZ, en busca de tráfico malicioso que se corresponda con alguna de las firmas de intrusión ingresadas en el sistema. 2. El sistema implementado representa un soporte importante para los administradores de la red, ya que automatiza la tarea de auditar los paquetes que viajan hacia los servidores, permitiendo seguir la pista de los patrones de intrusión detectados. Este trabajo se reduce a la revisión periódica de las alarmas generadas por el NIDS, lo que ahorra tiempo y esfuerzo. 3. La interfaz gráfica sencilla y práctica para la definición de firmas de ataques, confiere al sistema de una gran flexibilidad para que el administrador lo personalice, adecuándolo a las características de su red. Este método de definición de reglas permite efectuar una respuesta rápida ante nuevos ataques descubiertos, sin tener que esperar a que el fabricante suministre una actualización de las firmas, como ocurre con los NIDS comerciales. 4. El NIDS implementado permite la ejecución de scripts, programados por el administrador como medidas de respuesta activas, lo que dota de flexibilidad al sistema. Estos mecanismos, en algunos casos, son preferibles a no responder en ninguna forma, sin embargo, no representan en lo absoluto un método seguro y efectivo de proteger un sistema, ya que pueden ser utilizados en su contra. Autor: Pablo Astudillo Aguilar 26/06/

157 RECOMENDACIONES RECOMENDACIONES 1. En las primeras etapas de utilización del NIDS, se debería dedicar un tiempo considerable a la creación y afinación de las firmas de detección de ataques, hasta lograr en ellas un equilibrio entre exactitud y eficiencia. Esto permitirá reducir al mínimo los falsos positivos, evitando así que en lo posterior se emplee demasiado tiempo en la revisión de falsas alarmas. 2. Los scripts de actualización de reglas del firewall, programados como mecanismo de respuesta a intrusiones, deberían ser utilizadas con extrema precaución, con reglas que los prevengan de bloquear los servicios de Internet que la Universidad de Cuenca ofrece al público, así como sus recursos internos. El permitir que la red sea inutilizada repetidamente puede ser el camino más rápido hacia una red insegura. 3. El NIDS implementado está basado en red, por lo que es vulnerable al tráfico cifrado; sus esfuerzos son inútiles si lo que analiza no es en realidad lo que recibirá el servidor o aplicación final. Si el uso del cifrado de información se vuelve imprescindible, se recomienda utilizar paralelamente los IDS basados en host, o los IDS de aplicación, que interceptan los datos cuando ya han sido descifrados. 4. La detección de intrusiones ha evolucionado vertiginosamente en los últimos años, se recomienda a los administradores de la red mantenerse actualizados en cuanto a las nuevas técnicas y herramientas disponibles en esta importante área de la seguridad. Autor: Pablo Astudillo Aguilar 26/06/

158 BIBLIOGRAFIA BIBLIOGRAFIA Libros Electrónicos 1. MIRA, Emilio. Implantación de un Sistema de Detección de intrusos en la Universidad de Valencia [en línea]. Edición 1. Valencia, España. Disponible en: 2. GONZALEZ, Diego. Sistemas de Detección de Intrusiones [en línea]. Edición Julio 2003, revisado en julio del 2003 para correcciones tipográficas. Disponible en: 3. BORGHELLO, Cristian. Seguridad Informática, sus Implicancias e Implementación [en línea]. Edición 1. Septiembre Disponible en: 4. RANUM, Marcus. False Positives: A User s Guide to Making Sense of IDS Alarms [en línea]. Edición 1. Febrero Disponible en: ids/whitepaper/falsepositives.pdf 5. FARSHCHI, Jamil. Intrusion Detection In Depth [en línea]. Edición 3.0. Disponible en: 6. VILLALON, Antonio. Seguridad en Unix y Redes [en línea]. Edición 2.1. España. Julio Disponible en: es.tldp.org/manuales-lucas/docunixsec/unixsec-html/ 7. TORRES, Efraín. Sistema Inmunológico para la detección de intrusos a nivel de protocolo HTTP [en línea]. Edición 1. Santafé de Bogotá. Mayo del Disponible en: pwp.007mundo.com/etorres1/articuloidshttp.pdf Autor: Pablo Astudillo Aguilar 26/06/

159 BIBLIOGRAFIA 8. LISTON, Kevin. Intrusion Detection FAQ-Can you explain traffic analysis and anomaly detection? Disponible en: 9. FERNANDEZ, Alberto y CRESPO, Abel. IP Spoofing [en línea]. Ultima revisión: Junio 1, Disponible en: ip-poofing.tinusi.com/es/ 10. Death Master (Seudónimo). Sabuesos en la Red: El escaneo de puertos [en línea]. Disponible en: ZARASKA, Krzysztof. IDS Active Response Mechanisms: Countermeasure Subsytem for Prelude IDS [en línea]. Julio 9, Disponible en: misc/lsm/2002/slides/krzysztof/lsm.pdf Artículos y Publicaciones Electrónicas 1. The NSS Group. Intrusion Detection Systems, Group Test [en línea]. Edición 3. Cambridgeshire, Inglaterra. The NSS Group. Diciembre 2000, revisado en Junio Disponible en: 2. MIRA, Alfonso. Sistemas de Detección de intrusos y Snort. Maestros del Web [en línea]. Edición 1. Publicado el Disponible en: 3. CUFF, Andy. Intrusion Detection Terminology (Part One) [en línea]. SecurityFocus. Ultima actualización Septiembre 3, Disponible en: 4. Presentando IDS. NEX Periódico de Networking [en línea]. Edición 3. Disponible en: nex_1/seguridad/nota1.asp Autor: Pablo Astudillo Aguilar 26/06/

160 BIBLIOGRAFIA 5. CISCO SYSTEMS. The Science of Intrusion Detection System Attack Identification [en línea]. Disponible en: 6. TANASE, Matt. The Great IDS Debate: Signature Analysis Versus Protocol Análisis [en línea]. SecurityFocus. Ultima actualización: Febrero 5, Disponible en: 7. daemon9 / route / infinity [Seudónimo]. IP-SPoofing demystified. Phrack Magazine [en línea]. Volumen 7, Número 48. Junio Disponible en: 8. HISPASEC. Ataques masivos. Es tan fiero el león como lo pintan? [en línea]. Ultima actualización: febrero 15, Disponible en: 9. MATETI, Prabhaker. IP Spoofing and Fragmentation [en línea]. Altavista Group. Disponible en: KAZIENKO, Przemyslaw y DOROSZ, Piotr. Intrusion Detection Systems (IDS) Part 2 - Classification; methods; techniques [en línea]. Ultima actualización: Julio 23, Disponible en: IDS-Part2-Classification-methodstechniques.html 11. TANASE, Matthew. One of These Things is not Like the Others: The State of Anomaly Detection [en línea]. Ultima actualización en Julio 1, Disponible en: LARSEN, Jason y HAILE, Jed. Understanding IDS Active Response Mechanisms [en línea]. Ultima actualización: Enero 29, Disponible en: Autor: Pablo Astudillo Aguilar 26/06/

161 ANEXOS ANEXOS Anexo 1. Cuadros Estadísticos del Tráfico de Red A continuación se presentan dos cuadros estadísticos que ilustran el tráfico que atraviesa el Firewall CISCO Pix 525 que protege la DMZ de la Universidad de Cuenca. Estos gráficos fueron generados utilizando el software MRTG Multi Router Traffic Grapher, versión Los datos se obtienen calculando el tráfico promedio en intervalos de 5 minutos. Verde: Tráfico de entrada en bits por segundo. Azul: Tráfico de salida en bits por segundo. A1-1. Tráfico en la interfaz del Firewall CISCO Pix 525 A1-2. Tráfico en la interfaz del Firewall CISCO Pix 525 Se puede apreciar que el NIDS debe procesar un tráfico máximo promedio de 2.42 Mbits/sg en las horas pico de utilización de la red. Esto se puede reducir drásticamente si se configura el filtro del sniffer para que solo capture el tráfico dirigido a los servidores que se exponen al público, es decir, servidores WEB y correo electrónico (ver Anexo 3, Manual de Configuración). Autor: Pablo Astudillo Aguilar 26/06/

162 ANEXOS Anexo 2. Manual de Instalación Requisitos Este proyecto requiere instalarse en un computador con Sistema Operativo Linux Red Hat en su versión 9.0. Así mismo, debe instalarse el escritorio KDE 3.1 (incluido en la distribución) para utilizar el entorno gráfico de la aplicación, ya que este fue desarrollado usando las librerías Qt 3.1. Base de datos El motor de base de datos utilizado por esta aplicación es PostgreSQL. La base de datos se llama cerbero y puede crearse ejecutando los scripts que vienen en el CD adjunto a este documento de tesis. Los pasos para la creación de la base de datos son los siguientes (se asume que el paquete de PostgreSQL ya está instalado e inicializado): 1. $ su postgres 2. # createdb cerbero 3. # psql cerbero 4. # \i ruta de script /scripts Esto creará la estructura de la base de datos sobre la que trabajará la aplicación. Dependencia de Paquetes El proyecto requiere que se instale previamente los siguientes paquetes: 1. libpcap: Librería para la captura de paquetes de red. 2. libpqxx: Librería orientada a objetos para acceder a bases de datos PostgreSQL. 3. boost_date_time_gcc: Librería del paquete Boost para realizar operaciones con fracciones de segundo. Aunque deberá conseguirse el paquete completo Autor: Pablo Astudillo Aguilar 26/06/

163 ANEXOS de librerías Boost, no es necesario instalar todas sus librerías; esta aplicación únicamente requiere la que tiene relación con el manejo de fechas y horas. 4. libdnet: Librería con múltiples funciones para el manejo de direcciones ip. 5. libvmime: Librería para el envío de correo electrónico. Todos estos paquetes se pueden descargar gratuitamente desde el sitio web Instalación del Paquete Desde el archivo.rpm: 1. $ rpm ivh cerbero-1.0.rpm Desde el arvhivo fuente.tar.gz 1. $ gunzip cerbero-1.0.tar.gz 2. $ tar xvf cerbero-1.0.tar 3. $ cd cerbero $./configure 5. $ make 6. $ make install El archivo ejecutable se copiará en el directorio /usr/local/bin. Se recomienda crear un acceso directo en el escritorio de KDE para facilitar su ejecución. Autor: Pablo Astudillo Aguilar 26/06/

164 ANEXOS Anexo 3. Manual de Configuración Se puede acceder a las opciones de configuración del sistema activando la última pestaña del menú principal al margen izquierdo. Estas opciones se dividen en tres grupos: Parámetros, Niveles de Alarma y Ataques. Se estudia el detalle de cada una a continuación. Parámetros En esta pestaña se encuentran agrupados todos los parámetros que definen el comportamiento básico del programa; es importante que el administrador configure estas opciones de acuerdo a sus requerimientos antes de poner en funcionamiento la captura y análisis de paquetes. Interfase y Direcciones monitoreadas La opción de Interfase monitoreada nos permite seleccionar de un combo cual es la interfase de red que sistema configurará en modo promiscuo para capturar los paquetes. Usualmente, es la tarjeta de red que está conectada a un puerto espejado en uno de los switchs principales de la red, esto brinda una posición estratégica para ver toda la información que fluye por el cable. En este combo se listarán todas las interfases que posea el computador, incluyendo algunos valores especiales como lo que captura los paquetes enviados al localhost; y any, que captura TODOS que lleguen por las interfases disponibles. La opción de Direcciones monitoreadas nos permite filtrar el tráfico entrante, y capturar solo aquellos paquetes que tengan como dirección destino alguna de las direcciones ip especificadas. Esto permite concentrar los esfuerzos de análisis en aquellos hosts que sean más sensibles en la red. El sistema tomará esta lista y elaborará una cadena de filtro para enviarla como parámetro en la creación del Sniffer. Autor: Pablo Astudillo Aguilar 26/06/

165 ANEXOS Figura A3-1. Interfase de Red y Direcciones monitoreadas Respuestas La opción de ruta de Scripts de respuesta nos permite preestablecer donde están ubicados los procedimientos que utiliza el sistema para responder a intrusiones. La opción de Activar las Respuestas automáticas frente a intrusiones es un control maestro sobre el comportamiento del sistema frente a intrusiones. Mediante esta opción se activan o desactivan todos los mecanismos de respuesta configurados para cada firma. Autor: Pablo Astudillo Aguilar 26/06/

166 ANEXOS Figura A3-2. Opciones de los mecanismos de respuesta Mails Esta pestaña se utiliza para dar mantenimiento a las direcciones de correo electrónico a las que se envían las notificaciones de intrusión, según se hayan configurado para cada firma por separado. En pocas palabras, si una firma tiene activada la notificación por mail cuando coincide con el tráfico observado, las alarmas se envían a estas direcciones de correo. Autor: Pablo Astudillo Aguilar 26/06/

167 ANEXOS Figura A3-3. Direcciones de correo electrónico de los Administradores Mensajes Al igual que en el caso anterior, esta pantalla se utiliza para mantener la información de los mails de los celulares a los que se enviarán las notificaciones de intrusión. Aunque el principio es básicamente el mismo, estas opciones se deben tratar por separado, ya que la cantidad de información que se puede enviar a un teléfono celular es muy reducida. Además, estas alarmas deberían enviarse solo cuando la situación requiera la inmediata intervención del personal notificado. Autor: Pablo Astudillo Aguilar 26/06/

168 ANEXOS Figura A3-4. Direcciones de correo de celulares Sniffer Esta opción nos permite configurar parámetros extra al filtro del sniffer, además de las ingresadas en la opción de Direcciones monitorizadas. Por ejemplo, en la Figura A3-5 se puede observar la opción de filtrado not src ; esto hace que el sniffer no capture ningún paquete proveniente de esta dirección. Además, si esta es la dirección donde reside el NIDS, se interpreta como que el sistema solo procesará tráfico entrante, desechando el generado por el propio computador. Autor: Pablo Astudillo Aguilar 26/06/

169 ANEXOS Figura A3-5. Configuración del filtro del Sniffer Ventanas Esté último parámetro de configuración nos permite establecer el tiempo en que las ventanas emergentes de alarmas permanecerán en pantalla, antes de destruirse a si mismas. Para que las ventanas solo desaparezcan por la intervención del administrador, se configura el valor de cero. Autor: Pablo Astudillo Aguilar 26/06/

170 ANEXOS Figura A3-6. Configuración de las ventanas emergentes Una vez que estos parámetros generales han sido establecidos, o se modifiquen con el tiempo, se debe dar clic sobre el botón Aplicar cambios, de esta forma las configuraciones se guardan en la base de datos. Niveles de Alarma En esta segunda pestaña de configuración, el administrador debe establecer los Niveles de Alarma que necesita diferenciar para identificar la gravedad de una intrusión. Este formulario le permite ingresar n niveles de alarma, cada uno con un Nombre, una Descripción, un Color, y los medios que utilizará para enviar las notificaciones de intrusión. Estos medios son, de izquierda a derecha en la Figura A3-7, logs del sistema, correo electrónico, mensajes a celular y ventanas emergentes. Por ejemplo, en esta misma figura se observa una configuración con 3 niveles de alarma: bajo, medio y alto. El nivel Bajo solo notificará a través de logs del sistema; el nivel medio notificará también a través de logs, además de mails y Autor: Pablo Astudillo Aguilar 26/06/

171 ANEXOS ventanas emergentes. Unicamente el nivel Alto utiliza todos los medios disponibles para enviar las alarmas. Figura A3-7. Configuración de los Niveles de Alarma Ataques Este es un formulario de mantenimiento para registrar los diferentes tipos de intrusiones que el sistema puede detectar, conforme va creciendo su número de firmas. Esto permite catalogar las firmas en grandes subgrupos. Autor: Pablo Astudillo Aguilar 26/06/

172 ANEXOS Figura A3-8. Mantenimiento de Categorías de Ataques Autor: Pablo Astudillo Aguilar 26/06/

173 ANEXOS Anexo 4. Manual de Operación y Administración Pantalla Principal En la Figura A4-1 se puede apreciar la pantalla principal del sistema. Las opciones de apagado y encendido se utilizan para detener o reiniciar el analizador, y por tanto, toda la actividad del NIDS. Se debe detener el programa antes de efectuar cualquier cambio en su configuración (como los analizados en el anexo anterior), y, luego de guardar las modificaciones, encender el programa para que aplique los nuevos parámetros. A la derecha se dispone de algunos campos indicadores: Paquetes recibidos: indica cuántos paquetes se han capturado hasta el momento. Paquetes analizados: indica cuántos de los paquetes recibidos han sido procesados para verificar firmas de intrusión. Eventos detectados: indica cuántos paquetes han presentando alguna firma de intrusión. Alarmas generadas: indica cuántas alarmas se han generado, producto de relacionar los eventos ocurridos. En la lista inferior (Eventos y Alarmas) se mostrarán las alarmas que se van presentando desde que se inicia el programa. En la Figura A4-1 también se puede apreciar un ejemplo de una ventana emergente, generada como notificación visual al administrador de que una intrusión ha tenido lugar. Autor: Pablo Astudillo Aguilar 26/06/

174 ANEXOS Figura A4-1. Pantalla principal Scripts de respuesta Los métodos tradicionales que manejan los NIDS para bloquear una intrusión son: la actualización de reglas del firewall y el cierre de sesiones. En el presente proyecto se implementó un algoritmo genérico para ejecutar uno o varios scripts, en el orden y sincronización de tiempo que el Administrador configure, para el caso de cada firma en particular. Además, el administrador puede hacer uso de parámetros que provean dinamismo a la ejecución de estos scripts. Para que un script pueda ser utilizado como mecanismo de respuesta, el administrador debe primero registrar este script en el sistema. Utilizando el botón (cargar scripts) se selecciona los scripts del disco. El sistema entonces almacenará un registro en la base de datos con el nombre del script y su fecha de última modificación. De esta forma, si al momento de ejecutar el script, la fecha real y la almacenada no coinciden, significa que el script fue modificado, y el administrador no ha registrado este cambio en el sistema. Utilizando el botón Autor: Pablo Astudillo Aguilar 26/06/

175 ANEXOS (recargar scripts) se le ordena al sistema actualizar la fecha de última modificación del script seleccionado en la base de datos; así, el administrador notifica que los cambios al script están autorizados, y que la ejecución del mismo es segura para la red. Con el botón (nuevo parámetro) se configuran los parámetros que recibe el script seleccionado, luego, durante la configuración de este como respuesta a una firma puntual, se enlazarán los campos de cabecera que correspondan para que los argumentos se generen dinámicamente con el tráfico de la red. Figura A4-2. Configuración de los Scripts de Respuesta Creación de Firmas de intrusión En la Figura A4-3 se puede observar la pantalla de mantenimiento de las firmas de intrusión. Estas firmas no son más que valores específicos de campos de cabecera que se buscan en los paquetes de red. Autor: Pablo Astudillo Aguilar 26/06/

176 ANEXOS Figura A4-3. Mantenimiento de Firmas Presionando el botón (nueva firma) se carga un asistente que guiará al administrador a través de cuatro pantallas, en las que configurará una nueva firma de intrusión. Pantalla 1: General En este formulario se ingresan los datos generales de la firma: una Etiqueta, que la identifique en pocas palabras y la distinga de las demás firmas; un tipo de Ataque, en que subcategoría cae el ataque que detectará esta nueva firma (denegación de servicios, escaneo de puertos, etc.); una Descripción, que explica los detalles de la misma. Finalmente, mediante la opción Firma Habilitada, se indica si está firma entrará en vigencia inmediatamente después de terminado el asistente. Para el presente ejemplo, se desarrollará una firma que detecte el escaneo de puertos SYN, también denominado semi-abierto, ya que no finaliza adecuadamente el saludos de tres pasos entre un usuario y un servidor (three-way handshake). Autor: Pablo Astudillo Aguilar 26/06/

177 ANEXOS Figura A4-4. Paso 1: Información general Pantalla 2: Patrones En esta parte es donde se especifican que valores específicos se buscarán en los paquetes para determinar una intrusión. Siguiendo con el ejemplo, se necesita un patrón que identifique los paquetes que tengan la bandera SYN en 1; se especifica esta condición como se muestra en la Figura A4-5: Autor: Pablo Astudillo Aguilar 26/06/

178 ANEXOS Figura A4-5. Patrones de búsqueda Además, sería conveniente especificar que los paquetes recibidos con la bandera SYN levantada deben tener en común la dirección IP origen, de esta forma, se identifican a intrusos individuales tratando de escanear los puertos de los servidores. Esta condición se expresa como se ilustra en la Figura A4-6: Autor: Pablo Astudillo Aguilar 26/06/

179 ANEXOS Figura A4-6. Paso 2: Patrones de igual valor Las condiciones de igual valor permiten exigir un valor constante en cualquiera de los campos de cabecera de paquetes, esto vuelve muy específicas a las firmas de intrusión, provocando así que se reduzcan los falsos positivos. Todas las condiciones establecidas para una firma se evalúan con el operador and; es decir, basta con que una de las condiciones sea falsa para un paquete, para concluir con el análisis y continuar con la siguiente firma. Pantalla 3: Niveles y Umbrales En esta pantalla se pueden establecer valores umbral a las firmas, estableciendo niveles de crecimiento del ataque que se desea detectar. Aplicando esto al ejemplo de los escaneos de puertos, se pueden definir 3 niveles de firma con valores umbral, que consistirían en la cantidad de paquetes recibidos con la bandera SYN en 1, y que tienen la misma dirección IP. A cada nivel de firma se le asigna un nivel de alarma, esto ayuda a catalogar los niveles desde los menos peligrosos hasta los que Autor: Pablo Astudillo Aguilar 26/06/

180 ANEXOS requiere atención inmediata; además, es posible personalizar las formas en que se notifican las alarmas en cada nivel alcanzado. Finalmente, el umbral de tiempo de la firma es el tiempo máximo en que se espera que se alcancen los niveles establecidos (al menos uno de ellos); si se cumple este tiempo y no se alcanzan los valores umbral de paquetes, los recursos que almacenaban esta información son liberados, para dar cabida a la nueva información que se recepta. En la Figura A4-7 se puede apreciar gráficamente lo explicado: Figura A4-7. Niveles de Firma Pantalla 4: Respuestas La principal función de los niveles de firma es permitir escalonar las alternativas de respuesta, permitiendo tomar decisiones relajadas en las primeras etapas y posponer las actitudes drásticas hasta el final. En esta última pantalla del wizard, se dan las herramientas para configurar mecanismos de respuesta a intrusiones, diferenciándolos por los niveles de firma establecidos. Se crea una pestaña por cada nivel de firma y con el botón (nuevo script) se pueden añadir los scripts que Autor: Pablo Astudillo Aguilar 26/06/

181 ANEXOS se desean ejecutar en cada nivel. Por supuesto, como se anotó en la sección de Scripts de Respuesta (12.2), estos scripts deben estar registrados en el sistema. Una vez seleccionados los archivos, se puede escoger entre 3 alternativas: Ejecutar, Sugerir y Deshabilitar. Si se configura el script para ejecución, una vez alcanzado el nivel señalado, este tomará los argumentos configurados y se ejecutará. Si se escoge la opción sugerir, se listará este script como posible mecanismo de respuesta en una ventana emergente, cuando se detecte la intrusión en el nivel determinado. El administrador podrá ejecutar entonces la respuesta desde esta ventana. La opción deshabilitar inhibe el script de tomar un papel durante una intrusión. Una alternativa más para la programación de estos mecanismos es establecer un tiempo de espera en segundos, para que el siguiente script planificado se ejecute. Esto permite tomar acciones que tendrán un tiempo de vigencia, para luego ser desactivadas por el mismo sistema, mediante un script deshacer. Los valores que se tomarán como parámetros al ejecutar el script se pueden configurar de dos formas: dinámicos y estáticos. Los parámetros dinámicos toman sus valores de argumento de las cabeceras de los paquetes recibidos que generaron la intrusión. Los estáticos se establecen a un valor fijo en el momento mismo de la planificación del script, es decir, en esta misma pantalla final del wizard. En la Figura A4-8 se puede observar que se programan 2 scripts para ejecución; el segundo script deshará la acción del primero, la cual es bloquear una dirección IP mediante IPTABLES en un computador Linux. En conclusión, este bloqueo durará 30 segundos. Autor: Pablo Astudillo Aguilar 26/06/

182 ANEXOS Figura A4-8. Planificación de los Scripts de Respuesta A continuación en la Figura A4-9 y Figura A4-10 se presenta ejemplos de ejecución de scripts; la primera contiene una notificación generada por el sistema, luego de ejecutar un script deshacer, varios segundos después de que una dirección IP sea bloqueada en el firewall de la máquina. En la segunda se observa un checkbox con el nombre del script sugerido para ejecución. Autor: Pablo Astudillo Aguilar 26/06/

183 ANEXOS Figura A4-9. Ejecución de script "deshacer" Figura A4-10. Ejecución de un script configurado como "Sugerir" Autor: Pablo Astudillo Aguilar 26/06/

184 ANEXOS Reportes de Alarma En este formulario se ofrecen opciones de consulta de alarmas, ingresando un periodo de tiempo arbitrario. Se listan las alarmas, junto con sus instancias y mecanismos de repuesta, si los hubo. También se pueden eliminar cuando la información ya no es de utilizada, aligerando la base de datos y las futuras consultas. Figura A4-11. Reporte de Alarmas Autor: Pablo Astudillo Aguilar 26/06/

185 ANEXOS Anexo 5. Denuncia de Tesis 1. SELECCIÓN DEL TEMA: Diseño y Construcción de un Sistema de Detección de Intrusiones para la Red de la Universidad de Cuenca. 1.1 Antecedentes.- Desde su invención hasta nuestros días, el número de ordenadores ha creciendo hasta consolidarse como un instrumento casi imprescindible en la vida cotidiana del hombre. La posibilidad de interconectar múltiples ordenadores formando redes dio origen a una amplia variedad de aplicaciones, así como a nuevos retos de seguridad en el manejo de la información. La red ARPAnet, creada por el gobierno estadounidense en 1969 para actividades de desarrollo y defensa, sería la precursora de la que hoy conocemos como Internet. En aquel entorno, la seguridad era mínima. Se trataba de una red compuesta por una pequeña comunidad cuyos miembros eran de confianza. Actualmente Internet es una gigantesca red heterogénea compuesta por millones de ordenadores de diferentes plataformas, algunos de los cuales son proveedores de servicios y otros consumidores de dichos servicios. Cualquier sistema conectado a Internet, ya sea proveedor o consumidor de servicios, es susceptible de ser víctima o fuente de un ataque informático. Cuando se habla de seguridad en redes, por lo general se piensa en mecanismos de control de acceso como los Cortafuegos, Servidores Proxy y Listas de Control de Acceso de Routers. Todos ellos están diseñados para restringir el flujo de tránsito hacia y desde las redes privadas, en un intento por preservarlas del acceso de atacantes desde Internet. Sin embargo, incluso el mejor de los dispositivos de filtrado fallará en su misión de proteger la red, si los recursos accesibles desde Internet son vulnerables a ataques. Autor: Pablo Astudillo Aguilar 26/06/

186 ANEXOS Individuos maliciosos pueden utilizar los canales de comunicación abiertos (HTTP, FTP, e- mail, DNS) para comprometer, en forma remota, la seguridad de un sistema dentro de una red. A esta situación descrita se le añade un peligro más, los gusanos. Después de 15 años de que el gusano de Robert Morris causara el pánico en la red, la historia se repite. En el año 2000 el gusano RedCode hizo estragos en Internet. En los momentos más críticos de la infección se llegaron a registrar 15 ataques por minuto contra un mismo servidor Web. Al RedCode le sucedieron otros más avanzados como el RedCode II y el temido Nimbda. A diferencia de los ataques perpetrados por hackers y/o crackers, los gusanos no necesitan descansar, dedicándose 24 horas al día a barrer de forma continua Internet con el fin de encontrar nuevas víctimas. En este contexto, se hace estrictamente necesario automatizar el proceso de detección y respuesta frente a los ataques informáticos, surgen los IDS s. Que es un IDS? IDS es el acrónimo de Intrusion Detection System (Sistema de Detección de Intrusiones). La Detección de Intrusiones es un proceso de seguridad diseñado para monitorear y analizar eventos en sistemas y redes, para detectar un posible mal uso o accesos no autorizados. Los IDS aportan la capacidad de alertar anticipadamente acerca de toda actividad sospechosa que, típicamente, ocurre antes y durante un ataque. Esta tecnología es relativamente joven, surgiendo en los años 80; hoy en día es parte indispensable de la seguridad integral de las redes. Utilizando una analogía con el sistema de seguridad en una casa, los IDS pueden detectar movimiento en el interior de la casa y disparar una alarma. Por supuesto que es importante ubicar correctamente el sensor. Si se lo pone en el último rincón del garaje, no será capaz de detectar intrusos ingresando por la ventana de la cocina. Autor: Pablo Astudillo Aguilar 26/06/

187 ANEXOS Existen 2 tipos básicos de IDS: - Los HIDS (Host Based Intrusion Detection System).- Son instalados en el sistema que se pretende proteger y se encarga de detectar cualquier intento de intrusión sobre ese sistema. - Los NIDS (Network Based Intrusion Detection System).- Los NIDS o Sistemas de Detección de Intrusiones basados en Red se encargan de proteger a todos los sistemas de la red, independientemente de su arquitectura hardware y su sistema operativo. A pesar de que hoy en día existen diversos Sistemas de Detección de Intrusiones disponibles para diferentes necesidades, su utilización práctica dista mucho de la realidad. Se estima que tan solo el 0.001% de los sistemas de Internet están protegidos por algún tipo de Sistema de Detección de Intrusiones. Haciendo historia, los primeros Sistemas de Detección de Intrusiones fueron: El "Intrusion Detection Expert System" (IDES), desarrollado entre 1984 y 1986 por Dorothy Denning y Peter Neumann. Realizaba monitoreo en tiempo real. El "Multics Intrusion Detection and Alerting System" (MIDAS), creado por el National Computer Security Center (NCSC). Monitoreaba conexiones al Internet. El "Network Audit Director and Intrusion Reporter" (NADIR) fue desarrollado en Laboratorio Nacional de Los Alamos El primer paso para la fusión de sistemas de detección basados en máquina y red fue el "Distributed Intrusion Detection System" (DIDS). Fue el primer sistema capaz de hacer que un grupo de seguridad pudiera monitorizar las violaciones e intrusiones de seguridad a través de las redes. 1.2 Alcance Esta tesis consiste en el Diseño, Construcción, Configuración e Implantación de un Sistema de Detección de Intrusiones basado en Red (NIDS), que será usado como Autor: Pablo Astudillo Aguilar 26/06/

188 ANEXOS una herramienta adicional en el mantenimiento de la seguridad de la Red Académica Integral de la Universidad de Cuenca. 1.3 Justificación Las vulnerabilidades de los diferentes sistemas dentro de una red son los caminos para realizar los ataques. Es común la existencia de servidores que diariamente reciben algún tipo de ataque con diversos fines, desde detener sus servicios hasta obtener algún tipo de dato confidencial. La Universidad de Cuenca no es la excepción. Actualmente, esta institución cuenta con la Red Académica Integral (RAI) que presta servicios de navegación Web, transferencia de archivos, correo electrónico, comunicación entre los centros de cómputo, etc. Además, se encuentran en operación varios servicios adicionales de información al público tales como: la Red de Bibliotecas, sistemas de consulta, sistemas de Matrícula Diferenciada, sistemas de Registros de Calificaciones, información de Proyectos de Investigación, Reglamentos y Normativa universitaria, noticias, eventos, etc. A continuación, se explican las principales razones por las cuales se justifica la implementación de un NIDS en nuestra Universidad: Prevenir problemas al disuadir a individuos hostiles. El comportamiento de algunos cambiará de forma que muchos ataques no llegarán a producirse. Incrementar la posibilidad de descubrir y castigar a los atacantes. Detectar violaciones de seguridad que no pueden ser prevenidas. Los atacantes pueden conseguir accesos no autorizados a muchos sistemas cuando vulnerabilidades conocidas no son corregidas. Detectar preámbulos de ataques. Cuando un individuo ataca un sistema, lo hace típicamente en fases predecibles. En la primera fase, un atacante hace pruebas y examina el sistema o red en busca de un punto de entrada óptimo. Autor: Pablo Astudillo Aguilar 26/06/

189 ANEXOS En sistemas o redes que no disponen de un IDS, el atacante es libre de examinar el sistema con un riesgo mínimo de ser detectado. Documentar el riesgo de la organización. Un IDS nos puede ayudar a conocer la amenaza desde fuera y dentro de la organización, ayudándonos a hacer decisiones a cerca de los recursos de seguridad que deberemos emplear en nuestra red. Proveer información útil sobre las intrusiones que ocurren. Incluso cuando los IDS s no son capaces de bloquear ataques, pueden recoger información detallada y relevante sobre éstos. Se puede usar esta información para detectar fallos en la configuración de seguridad o en la política de seguridad de la organización. Detectar patrones de ataque. 1.4 Auspicio docente Director de Tesis: Otto Parra González, Ing. 2. OBJETIVOS 2.1 Objetivos Generales El objetivo de esta tesis es el Diseño y Construcción de un Sistema de Detección de Intrusiones basado en Red (NIDS, Network based Intrusion Detection System), que complemente la labor de los elementos de seguridad que se encuentren implementados en la Red Académica Integral de la Universidad de Cuenca, tales como Firewalls, Intranet, Control de Acceso, entre los principales. 2.2 Objetivos Específicos Rendimiento.- El NIDS debe ser capaz de procesar y analizar en tiempo real todo el tráfico de la red. Autor: Pablo Astudillo Aguilar 26/06/

190 ANEXOS Seguridad y estabilidad.- Este software no debe convertirse en un agujero de seguridad para la red. Información precisa.- Permitir a los administradores de seguridad el seguir la pista de las vulnerabilidades de la red. Minimizar el impacto en la red.- Utilizar los mínimos recursos de red posibles. Apego a los estándares del IETF.- Observar los estándares que el IDWG (Intrusion Detection Working Group) emita con respecto a los formatos de alarmas de los Sistemas de detección de Intrusiones basados en Red. 3. CONTENIDO 3.1 MARCO TEORICO Capítulo 1: Introducción 1.1 Introducción a los Sistemas de Detección de Intrusiones (IDS) 1.2 Definiciones 1.3 Motivos que originan problemas de seguridad 1.4 Elementos de la detección de intrusiones 1.5 Fuentes de información basadas en máquina 1.6 Fuentes de información basadas en red Capítulo 2: Análisis y Diagnóstico 2.1 Detección de usos indebidos 2.2 Estudio de las firmas de los ataques más conocidos 2.3 Detección de anomalías 2.4 Métodos alternativos Capítulo 3: Diseño del NIDS 3.1 Tipos de respuestas 3.2 Observaciones sobre las respuestas 3.3 Adopción de políticas de respuesta 3.2 DESARROLLO DEL SISTEMA Capítulo 4: Ciclo de desarrollo Autor: Pablo Astudillo Aguilar 26/06/

191 ANEXOS 4.1 Análisis de la red 4.2 Desarrollo del NIDS Análisis Diseño Funcionamiento (tiempo real o diferido) Ambiente gráfico de la herramienta Configuración de respuestas automáticas Asistente para responder ataques Diagnóstico de vulnerabilidades después de un ataque Implementación Pruebas Conclusiones y Recomendaciones Referencias Bibliográficas Anexos 9.1 Cuadros estadísticos y análisis de los resultados obtenidos. 9.2 Manuales de Instalación y Configuración del NIDS. 9.3 Manuales de Operación y Administración del NIDS. 4. METODOLOGIA 4.1. Método Para alcanzar los objetivos planteados, se llevarán a cabo las siguientes actividades: 1. Estudio preliminar sobre la estructura de la red que tiene implementada la Universidad de Cuenca. Se obtendrá información acerca de la topología, diseño, hardware, sistemas operativos, software, tráfico, servicios al público, etc. 2. En base al estudio anterior, se procederá al Análisis y Diseño del NIDS que se ajuste mejor a las necesidades y características de esta red. Autor: Pablo Astudillo Aguilar 26/06/

192 ANEXOS 3. Programación del sistema de detección de intrusiones en el lenguaje C++ para plataformas Linux. El sistema consta del Sensor de eventos que emite alarmas y del Analizador de alarmas que determinará si una intrusión tuvo lugar, en base a comparaciones con las firmas de los tipos de ataques registrados. 4. Instalación del Sensor en el lugar estratégico definido en el diseño del NIDS. Este reportará alarmas al analizador de acuerdo a las políticas establecidas. 5. Instalación del Analizador y Pruebas al Sistema. 6. Análisis de Resultados. 7. Elaboración de la Memoria Técnica del proyecto Requerimientos de Hardware y Software Los requerimientos de Hardware son: Una computadora con 2 interfaces de red conectadas. Su ubicación estará dada por el diseño del NIDS, posterior al estudio preliminar de la red. Enrutadores y Switches de la red Los requerimientos de Software son: Sistema Operativo Linux RedHat 9.0, Paquete del Lenguaje C++, Base de Datos PostgresSQL, Software NIDS 4.3 Resultados esperados Proveer una herramienta para Detección de Patrones de Ataque, Gestión de Alarmas y Diagnóstico de vulnerabilidades. El NIDS instalado deberá analizar el tráfico de la red en tiempo real en busca de paquetes sospechosos que coincidan con las firmas de ataques registradas en el sistema. Autor: Pablo Astudillo Aguilar 26/06/

193 ANEXOS La información provista por el NIDS debe ser clara y precisa, de tal forma que el administrador pueda rápidamente entender la naturaleza de los ataques y los estragos causados. El NIDS no debe ser en si mismo un agujero de seguridad para la red. En este sentido, se realizarán pruebas exhaustivas para asegurar este requisito. 5. BIBLIOGRAFIA 5.1 Libros Antonio Villalón Huerta, Ing.; "Seguridad en Unix y Redes"; Bajo licencia GNU Free Documentation License; versión 2.1; URL: Diego González Gómez, Ing.; Sistemas de detección de intrusiones ; Bajo licencia GNU Free Documentation License; versión 1.01; URL: Raúl Siles Peláez, Ing.; Análisis de Seguridad de TCP/IP ; Bajo licencia GNU Free Documentation License; Stephen Northcutt; Network Intrusion Detection An Analyst s Handbook ; 2000 Edward G. Amoroso, Dr.; "Intrusion Detection - An introduction to Internet Surveillance, Correlation, Trace Back, Traps, and Response" Cisco Press, IDS. 5.2 Estándares Bocetos emitidos por el IDWG Grupo de Trabajo para la detección de intrusiones del IETF: o Intrusion Detection Message Exchange Requirements o Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition o The TUNNEL Profile o The Intrusion Detection Exchange Protocol (IDXP) Autor: Pablo Astudillo Aguilar 26/06/

194 ANEXOS 5.3 Enlaces de interés Autor: Pablo Astudillo Aguilar 26/06/