Sensores de red para un sistema de detección de intrusos distribuido

Texto completo

(1)i. ISC-2002-2-36. SENSORES DE RED PARA UN SISTEMA DE DETECCION DE INTRUSOS DISTRIBUIDO. EDGAR LEONARDO PRIETO PERILLA. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. 2002.

(2) ii. ISC-2002-2-36. SENSORES DE RED PARA UN SISTEMA DE DETECCION DE INTRUSOS DISTRIBUIDO. EDGAR LEONARDO PRIETO PERILLA. Tesis para optar al título de Ingeniero de Sistemas y Computación. Asesora Beatriz Acosta M. Ingeniera de Sistemas y Computación, M Sc.. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. 2002.

(3) iii. ISC-2002-2-36. DEDICATORIA. A mi familia por todo su amor y apoyo.

(4) iv. ISC-2002-2-36. AGRADECIMIENTOS. El autor expresa sus agradecimientos a:. A mis padres por su gran apoyo, amor y comprensión.. A Beatriz Acosta y Germán Vega por su continua y oportuna orientación.. A todos los integrantes del grupo de Investigación de Seguridad Informática de la Universidad de los Andes por su excelente trabajo.. A Marcela, Oscar y Alexander por su continua, valiosa y desinteresada colaboración en este proyecto.. A Andrés, Georgean, Juan José, Liliana, Marcela, y Raúl por su amistad a lo largo de estos años..

(5) ISC-2002-2-36. v.

(6) vi. ISC-2002-2-36. CONTENIDO. Lista de Figuras................................................................................................................ x. 1. Introducción................................................................................................................. 1. 2. Objetivos...................................................................................................................... 2. 2.1. Objetivos Generales.................................................................................................. 2. 2.2. Objetivos Específicos............................................................................................... 2. 3. Marco Teórico............................................................................................................. 4. 3.1. Introducción a los IDS.............................................................................................. 4. 3.2. Tipos de IDS............................................................................................................. 7. 3.2.1. IDS Basados en Host............................................................................................. 7. 3.2.2. IDS Basados en Red.............................................................................................. 8. 3.2.3. IDS Híbrido........................................................................................................... 9. 4. Modelo de un IDS Distribuido................................................................................... 10. 4.1. Arquitectura.............................................................................................................. 10. 4.1.1. Módulos................................................................................................................. 12. 4.1.1.1. Módulo de Comunicaciones............................................................................... 12. 4.1.1.2. Módulo de Eventos............................................................................................. 13. 4.1.1.3. Módulo de Análisis............................................................................................. 14. 4.1.1.4. Módulo de Respuestas........................................................................................ 15. 4.1.1.5. Módulo de Datos................................................................................................. 15.

(7) ISC-2002-2-36. vii. 4.2. Lenguaje de Intercambio de Información................................................................. 16. 4.2.1. Objetivos Del Lenguaje......................................................................................... 17. 4.2.2. Sintaxis del Lenguaje............................................................................................. 19. 4.2.3. Codificación Del Lenguaje.................................................................................... 20. 4.2.4. Ejemplo.................................................................................................................. 20. 5. Implementación de un Módulo de Eventos de Red: CNEG........................................ 22. 5.1. Alcance del Componente.......................................................................................... 22. 5.2 Arquitectura Lógica del Componente........................................................................ 24. 5.2.1. Motor de Captura................................................................................................... 25. 5.2.1.1. Filtro de Tráfico (Firewall)................................................................................ 25. 5.2.1.2. Filtro de Captura................................................................................................. 25. 5.2.2. Motor de Extracción de Datos............................................................................... 26. 5.2.3. Motor Generador de GIDOS.................................................................................. 26. 5.2.4. Interfaz de Comunicación...................................................................................... 27. 5.3. Decisiones de Implementación................................................................................. 28. 5.3.1. Lenguajes de Desarrollo........................................................................................ 28. 5.3.2. Ambiente de Desarrollo y Pruebas........................................................................ 29. 5.3.3. Protocolos.............................................................................................................. 30. 5.3.4. Filtro de Tráfico..................................................................................................... 31. 5.3.5. Captura de Tráfico de Red..................................................................................... 33. 5.3.6. Comunicación C – Java......................................................................................... 33.

(8) ISC-2002-2-36. viii. 5.3.7. Envío de GIDOS.................................................................................................... 35. 5.4. Mejoras al Modulo de Eventos de Red..................................................................... 37. 5.8. Mejoras al IDS.......................................................................................................... 39. 6. Conclusiones................................................................................................................ 40. 7. Bibliografía.................................................................................................................. 41. Anexo A. Requerimientos de Ejecución y Compilación................................................. 44. Anexo B. Características de CNEG................................................................................. 46. B.1. Selección de Dispositivo de Captura....................................................................... 46. B.2. Generación de GIDOS............................................................................................. 47. B.3. Despliegue de Ayuda............................................................................................... 47. B.4. Paquetes a Capturar.................................................................................................. 48. B.5. Modo Promiscuo...................................................................................................... 48. B.6. Despliegue de Información...................................................................................... 49. B.7. Uso de Reglas de Filtro de Tráfico.......................................................................... 51. B.8. Vaciado de Reglas de Filtro..................................................................................... 55. B.9. Ajuste De Política por Defecto del Filtro de Tráfico............................................... 55. B.10. Uso de Reglas de Filtro de Captura....................................................................... 56. Anexo C. Listado de los Archivos Fuente y Binarios..................................................... 61. C.1. Archivos Fuente....................................................................................................... 61. C.2. Archivos Binarios.................................................................................................... 64. Anexo D. Procedimiento de Ejecución en un Entorno Distribuido................................. 66.

(9) ISC-2002-2-36. ix. D.1. Configuración del Entorno....................................................................................... 66. D.2. Inicio del Módulo de Comunicaciones.................................................................... 67. D.3. Inicio del Módulo de Análisis.................................................................................. 68. D.4. Inicio del Módulo de Respuesta............................................................................... 68. D.5. Inicio del Módulo de Eventos de Red...................................................................... 69. Anexo E. Material Complementario................................................................................ 70.

(10) x. ISC-2002-2-36. LISTA DE FIGURAS. Figura. 1. Arquitectura............................................................................................... 11. Figura 2. GIDO en términos de una expresión S....................................................... 21. Figura 3. Expresión S codificada............................................................................... 21. Figura 4. Arquitectura del Sensor de Red.................................................................. 24. Figura 5. Modelo de comunicación C – Java............................................................ 34. Figura 6. Configuración de IDS Distribuido............................................................. 66.

(11) 1. ISC-2002-2-36. 1. INTRODUCCIÓN. El desarrollo de nuevas y mejores tecnologías ha sido ha sido una constante a lo largo de los últimos 25 años. El costo, acceso y disponibilidad de estas herramientas han permitido que sean parte indispensable de la sociedad actual.. En particular, el surgimiento de Internet como una gran herramienta de trabajo ha hecho necesaria la vinculación de nuevos y más complejos sistemas de información, así como la introducción o interconexión de servicios críticos.. Los últimos acontecimientos han hecho manifiesta la vulnerabilidad de estos sistemas ante ataques informáticos, creando la necesidad de una mejor infraestructura de seguridad informática.. El presente documento explica la utilización de Sistemas de Detección de Intrusos (IDS por las siglas en inglés de Intrusion Detection System), como parte de dicha infraestructura. Presenta además la arquitectura de un IDS propuesta por el CIDF, y explica detalladamente la implementación de un sensor de eventos de red para ésta arquitectura..

(12) 2. ISC-2002-2-36. 2. 2.1. •. OBJETIVOS. OBJETIVOS GENERALES. Introducir el concepto de un Sistema de Detección de Intrusos y su utilidad en una infraestructura de seguridad informática.. •. Describir la arquitectura propuesta por el CIDF para la implementación de un Sistema Distribuido de Detección de Intrusos (DIDS por las siglas en inglés de Distributed IDS).. 2.2. •. OBJETIVOS ESPECIFICOS. Definir el alcance de un módulo de eventos de red en la arquitectura de IDS propuesta por el CIDF. Este módulo se denominará sensor de red.. •. Definir la estructura de los mensajes a utilizar en la comunicación con los diferentes módulos de la arquitectura CIDF..

(13) ISC-2002-2-36. •. 3. Implementar un módulo de eventos en la arquitectura de IDS propuesta por el CIDF, capaz de detectar eventos de red. Esta implementación será publicada como CNEG (por las siglas en inglés de CIDF Network Event Generator).. •. El módulo sensor implementado deberá ofrecer al menos las siguientes características: captura de tráfico de red desde alguna de los dispositivos de red del sistema donde se ejecutará, despliegue de la información captura, filtro de captura y filtro de tráfico de red.. •. Utilizar los mecanismos de comunicación implementados por el módulo de comunicaciones, para garantizar la integración de los diversos módulos de la arquitectura..

(14) 4. ISC-2002-2-36. 3. 3.1. MARCO TEORICO. INTRODUCCION A LOS IDS. Un IDS es ante todo una de las muchas herramientas de seguridad informática que implementan y responden a las políticas de seguridad previamente definidas por la organización que se pretende proteger. No vale la pena considerar el uso de cualquiera de estas herramientas sin antes haber definido alguna clase de política para proteger los sistemas de información, y la información misma, de la organización1.. La literatura define un IDS como un sistema capaz de recolectar datos desde diversas entradas y responder cuando un posible ataque se esté efectuando. Los ataques pueden ser llevados a cabo por personal no autorizado intentando acceder a los sistemas de información, así como por personal autorizado intentado obtener privilegios sobre información, o sistemas de información, a los cuales no deben tener acceso. De igual forma, un ataque puede ser realizado ya sea desde el interior o exterior de la infraestructura informática, entendiendo esto como el conjunto de componentes de hardware y/o software que conforman el total de los sistemas de información de la organización. Un IDS, entonces, debe ser capaz de identificar o reconocer cierto tipo de entradas, recolectadas en puntos conocidos como sensores, y saber como responder ante ellas..

(15) ISC-2002-2-36. 5. Este proceso de reconocimiento se realiza generalmente utilizando alguna las siguientes técnicas2: ajuste de patrones, umbral de frecuencia, correlación de eventos y detección de estadísticas anormales. Sin embargo, la técnica más común involucra el método de ajuste de patrones (pattern matching), el cual consiste en hacer coincidir cada entrada con un patrón específico y determinar si este es o no un potencial ataque. Dichos patrones son conocidos como firmas de ataques3 y identifican de manera única cada posibles ataque. Generalmente las firmas definidas corresponden a entradas identificadas como incorrectas, inapropiadas o maliciosas, que violan una o más políticas de seguridad de la organización.. Una vez una entrada ha sido identificada como un posible ataque el IDS deberá ejecutar una acción como respuesta al mismo. Los tipos de respuesta pueden incluir desde acciones de registro, envío de alarmas a dispositivos (pantallas de consola, beepers, faxes, pagers, teléfonos celulares, etc.), envío de correo electrónico a personal autorizado, hasta reconfiguración de dispositivos de red como enrutadores o firewalls, o incluso una reconfiguración del IDS.. Es importante llevar un registro de toda actividad al interior del IDS (entradas recolectas, identificación de posibles ataques, respuesta ejecutada, condiciones o estado del funcionamiento interno, etc.), a fin de realizar análisis que permitan la continua evolución del mismo, así como evaluaciones sobre la utilidad de los patrones usados y la efectividad 1 2. [PARM02] y [OLOV92] [ISS98].

(16) ISC-2002-2-36. 6. de las respuestas ejecutadas. Las nuevas normas legislativas de varios países reconocen estos y otros tipos de registros como pruebas legales válidas, consideración importante si se desea tomar alguna acción legal frente a un (intento de) ataque realizado contra la organización.. Uno de los aspectos más importantes de un IDS es su configuración, entendiendo esto como las firmas de ataques que el IDS utiliza en el análisis de las entradas. Una configuración poco permisiva (exagerada restricción de las entradas permitidas) genera demasiados alertas conocidas como falsos positivos4, es decir identificación de entradas válidas e inofensivas como posibles ataques. Por otro lado, una configuración muy permisiva permitirá demasiados falsos negativos, ataques reales y verdaderos que no son detectados en el proceso de análisis de las entradas. En importante, entonces, guardar un balance en las firmas de ataques utilizadas, así como mantener actualizado el IDS con respecto a nuevos tipos de ataques, ie. nuevas firmas de ataques.. A continuación se presenta un listado con los objetivos principales de un IDS5:. •. Recolectar información desde diferentes fuentes de un sistema.. •. Reconocer violaciones a las políticas de seguridad de la organización a través de patrones que reflejen actividades no permitidas.. 3 4. [NAVA02a] y [NAVA02b] [SANS03a].

(17) ISC-2002-2-36. •. Realizar análisis estadístico de actividades anormales o no permitidas.. •. Mantener registros de las acciones realizadas por el IDS.. •. Permitir la valoración de daños ocurridos en el sistema durante un ataque.. •. Reconstruir e identificar las características de nuevos ataques.. •. Responder de manera automática ante entradas identificadas como ataques.. •. Reportar resultados del proceso de detección. 3.2. 7. TIPOS DE IDS. Existen tres grandes tipos de IDS.. 3.2.1. IDS BASADOS EN HOST. Los IDS basados en host (HIDS por las siglas en inglés de Host IDS) registran información de archivos, procesos, configuración y, en general, características del sistema que se desea proteger. Su objetivo principal es identificar cambios no autorizados en la configuración del sistema, así como accesos o actividades no permitidas.. 5. [LOPE02].

(18) ISC-2002-2-36. 8. El proceso de análisis de este tipo de IDS involucra generalmente el uso de algoritmos de suma de comprobación de manera regular sobre los archivos que se desean proteger. De igual forma, verifica nuevas entradas en los registros del sistema, comparándolas contra patrones bien conocidos de ataques. Puede incluso identificar accesos a archivos para evitar la instalación de archivos ejecutables o la eliminación de archivos sensibles. Algunos HIDS permiten además el registro de actividades de teclado o ratón, para un posterior análisis.. Las respuestas a los ataques en un HIDS suelen incluir desde el simple registro de actividades, hasta la eliminación de la cuenta de usuario involucrada, pasando por la restauración de los archivos o datos comprometidos o la detención de servicios afectados6.. 3.2.2. IDS BASADOS EN RED. Los IDS basados en red (NIDS por las siglas en inglés de Network IDS) verifican el tráfico de paquetes en un sistema o en una o más redes, analizando características de las cabeceras de los protocolos involucrados, así como el contenido o carga útil de los mismos.. Cada paquete o conjunto de paquetes es sometido a un análisis de ajuste de patrones intentando identificar tráfico de red irregular o malicioso..

(19) ISC-2002-2-36. 9. Las respuestas efectuadas por un NIDS ante un ataque suelen incluir cierre de conexiones y/o configuración de dispositivos de hardware y/o software para filtrar tráfico de red según determinadas características (éstas características son por lo general direcciones IP origen destino y/o puertos TCP/UDP origen/destino).. 3.2.3. IDS HIBRIDO. Un IDS híbrido es un sistema que combina características tanto de HIDS como de NIDS. Su descripción detallada depende mucho de su implementación, haciendo difícil obtener una definición exacta del mismo7. Dadas las restricciones de host, un IDS Híbrido se acerca más a la definición de un HIDS con capacidad de análisis de tráfico de red.. 6 7. [SANS03b] [MEIN98].

(20) 10. ISC-2002-2-36. 4. MODELO DE UN IDS DISTRIBUIDO. A continuación se pretende describir de manera general el modelo propuesto para la implementación de un IDS distribuido. Este modelo parte del esquema propuesto por el CIDF8, y se encuentra explicado en detalle en [CIDF98], [CIDF99], [CIDF01a] y [CIDF01b]. Se escogió éste modelo gracias a sus capacidades de escalabilidad, flexibilidad e interoperabilidad.. Se discutirá primero la arquitectura del IDS a implementar y se continuará con la descripción del lenguaje de comunicación de los distintos componentes de la arquitectura.. 4.1. ARQUITECTURA. El modelo arquitectónico propone cinco tipos diferentes de módulos de acuerdo a su funcionalidad dentro del IDS. Dichos módulos deben ser capaces de compartir información relacionada con el ambiente o infraestructura que se pretende proteger. Cada módulo debe poder ser utilizado en un ambiente diferente para el cual fue originalmente diseñado. El conjunto de módulos del IDS debe ser capaz de presentarse ante el mundo exterior como un único sistema independiente..

(21) 11. ISC-2002-2-36. Adicionalmente los componentes9 deben poder reconocerse y comunicarse entre sí a medida que nuevos componentes estén disponibles en el IDS. Cada módulo consume salidas y produce entradas para los diversos módulos del sistema.. Es importante tener en cuenta que el mismo modelo conceptual de la arquitectura permite implementaciones centralizadas, de la misma forma en que permite diferentes grados de distribución de sus componentes.. A. E. Entrada. D. R. Salidas. A. D. C. R. E Figura 1. Arquitectura. 8 9. The Common Intrusion Detection Framework. http://www.isi.edu/gost/cidf/ Se entiende por componente una instancia de un módulo..

(22) ISC-2002-2-36. 4.1.1. 12. MODULOS. A continuación se detallan los cinco módulos que describen la arquitectura para IDS propuesta por el CIDF.. 4.1.1.1 MODULO DE COMUNICACIONES. El módulo de comunicaciones es él componente central del IDS, pues, en un ambiente distribuido, se encarga de localizar y autenticar las distintas instancias de cada uno de los componentes para luego permitir el flujo de información entre ellos. Es él quien identifica y registra a los diversos componentes del sistema, permitiéndoles localizarse entre sí10. Este módulo suele conocerse como módulo C o caja C (C Box).. Por supuesto, en un ambiente distribuido todas las comunicaciones entre los diferentes componentes deben protegerse, utilizando canales seguros de comunicación. Esta implementación particular utilizará el protocolo SSL para éste propósito11.. Se recomienda [CIDF98], [CIDF01b], [LOPE02], [LOPE01], [HOLG01a] y [HOLG01a] para un mejor entendimiento del mismo..

(23) ISC-2002-2-36. 13. 4.1.1.2 MODULO DE EVENTOS. El módulo de eventos es el encargado de capturar las entradas al sistema. Debido a esto, las instancias de este módulo son también conocidas como sensores. Dependido del sistema de información que se quiera proteger, así como de las actividades sobre las cuales se desea mantener control, se pueden encontrar diferentes tipos de sensores: de red, de teclado o ratón, de bases de datos, de sistemas de archivos, etc.. Además de capturar los distintos tipos de entradas, los sensores, también conocidos como módulos E o cajas E (E Box), deben traducir éstas entradas a estructuras de mensajes entendibles por todos y cada uno de los diferentes módulos del IDS, a excepción tal vez del módulo de comunicaciones. Estas estructuras de mensajes son conocidas como GIDOs (General Intrusion Detection Object) y serán discutidas más adelante en este documento.. El módulo de eventos se comunica directamente con el módulo de análisis enviando las entradas capturadas en términos de GIDOs, e idealmente se debe comunicar con el módulo de datos para mantener registros detallados de las entradas capturadas. Se recomienda [CIDF01b] y [PRIE01] para un mejor entendimiento de éste módulo.. 10 11. [HOLG01a], [HOLG01a], [LOPE02] y [LOPE01]. [LOPE02], [LOPE01] y [PRIE01].

(24) ISC-2002-2-36. 14. 4.1.1.3 MODULO DE ANALISIS. El módulo de análisis es el encargado de procesar todas las entradas capturadas por los módulos de eventos, y determinar si existe o no algún tipo de intrusión en el sistema. El componente de análisis puede estar compuesto de dos clases independientes de análisis: análisis fuera de línea (offline) o análisis en línea (online).. En un ambiente distribuido es viable encontrar distintas tipos de módulos, de acuerdo al tipo de actividades que se desean controlar. Es así, que es posible encontrar módulos de análisis especializados en tráfico de red, sentencias de consulta a bases de datos, eventos de teclado o ratón, eventos en procesos o archivos, etc.. El módulo de análisis, generalmente conocido como módulo A o caja A (A Box), se comunica con el módulo de respuesta, como resultado de un posible ataque detectado. Igualmente puede comunicarse con el módulo de datos para mantener un registro de las aciones realizadas.. Una discusión más detallada del módulo de análisis se puede encontrar en [CIDF01b], [MORE01a], [MORE01b], [NAVA02a] y [NAVA02b]..

(25) ISC-2002-2-36. 15. 4.1.1.4 MODULO DE RESPUESTAS. El módulo de respuestas, conocido también como módulo R o caja R (R Box), es, en efecto, el encargado de realizar las acciones requeridas una vez se ha determinado un (potencial) ataque, a fin de contrarrestarlo. La efectividad del IDS en general depende del tipo de acciones que sea capaz de realizar este módulo.. Este módulo debe comunicar al módulo de datos las acciones realizadas, a fin de mantener un registro detallado de las mismas. En algunas configuraciones es posible encontrar comunicaciones entre el módulo de respuestas y el módulo de eventos, para una eventual reconfiguración de este último.. Se recomienda [BLAN01], [BLAN02] y [CIDF01b] para una discusión más detallada de módulo.. 4.1.1.5 MODULO DE DATOS. El módulo de datos representa la base de conocimiento del IDS. Cumple funciones tan diversas como almacenamiento de registros, base de firmas de ataques, almacenamiento de códigos de comunicación, perfiles de componentes, almacenes de llaves (keystores) y certificados digitales..

(26) ISC-2002-2-36. 16. Sobre este módulo pueden realizarse diversos esquemas de minería de datos para obtener estadísticas de eventos correlacionados con ataques perpetrados contra la organización, y de esta forma retroalimentar el IDS con el fin de mantener una continua evolución del mismo. De igual manera se pueden extraer estadísticas de eventos, ataques y respuestas producidas por el IDS.. Este módulo, usualmente conocido como cómo módulo D o caja D (D Box), es el encargado de brindar ‘inteligencia’ al sistema12. Idealmente debe comunicarse con el módulo de análisis con el objetivo de retroalimentar la configuración (firmas de ataques) del mismo.. Detalles de este modulo se pueden encontrar en [VEGA01].. 4.2. LENGUAJE DE INTERCAMBIO DE INFORMACION. A continuación se discutirá de manera general el lenguaje utilizado por los diversos módulos del IDS. Se recomienda [CIDF99], [LOPE02] y [LOPE01] para una descripción más detallada del mismo.. 12. [CIDF01b].

(27) ISC-2002-2-36. 17. Como se mencionó anteriormente, es una característica del modelo propuesto, que todos y cada uno de los componentes sean capaces de compartir el máximo posible de información. Para asegurar el flujo correcto de la misma, y el entendimiento por parte de los diferentes interlocutores (componentes), el CIDF propone estructuras de mensajes conocidas como GIDOs (por las siglas en inglés de General Intrusion Detection Object). Un GIDO es entonces, la unidad más pequeña de información compartida entre componentes del IDS.. 4.2.1. OBJETIVOS DEL LENGUAJE. Los GIDOs persiguen al menos los siguientes objetivos:. •. Expresividad: los componentes deben ser capaces de comunicar una alta gama de eventos y acciones ocurridas el interior y exterior del IDS.. •. Unicidad: los componentes no deben poder expresar un mensaje de muchas maneras diferentes. Se pretende que el número de mensajes describiendo el mismo evento o acción sea considerablemente pequeño.. •. Precisión: el significado de un mensaje debe ser claro y bien definido para todos y cada uno de los componentes del IDS..

(28) ISC-2002-2-36. •. 18. Tratamiento por capas: una sentencia específica debe ser expresada como un caso particular de una sentencia más general. De esta forma un componente puede obtener el nivel de información que desee.. •. Autodefinición: el contenido de un mensaje debe tener tal nivel de detalle que no se requiera una negociación externa para obtener mayor información.. •. Eficiencia: la estructura del mensaje debe consumir tan pocos recursos como sea posible.. •. Extensibilidad: si dos componentes interlocutores determinan ampliar la información, ambos deben ser capaces de generar y/o reconocer tal información, sin perder interoperabilidad con otros componentes del sistema.. •. Simplicidad: los componentes productores de mensajes deben poder realizar esta tarea de manera eficiente. Del mismo modo los componentes consumidores de mensajes deben ser capaces de extraer la información sin una carga considerable en el procesamiento..

(29) ISC-2002-2-36. •. 19. Portabilidad: el lenguaje debe soportar una gran variedad de plataformas, así como mecanismos de transporte, evitando así que el ambiente o entorno en que se encuentra el IDS sea un factor limitante del mismo.. •. Fácil de implementar. 4.2.2. SINTAXIS DEL LENGUAJE. El CIDF propone el uso de expresiones S (S-expressions, o S-exp)13 para el manejo de la sintaxis del lenguaje de intercambio de información.. Una expresión S es un agrupamiento recurrente de marcas (tags) y datos, que describen características de un entorno, o evento particular. La ventaja de su utilización es que proveen una asociación explícita entre los términos, sin limitar lo que ellos significan.. A cada nivel de recurrencia en la expresión S se la añade una característica que permite una ayuda semántica para la interpretación del contenido de la misma. Esta característica se conoce como Identificador Semántico (SID, por las siglas en ingles de Semantic Identifier). De ésta forma se obtiene los siguientes tipos de identificadores semánticos: verbos, roles, adverbios, atributos, atómicos, referenciales y conjunción..

(30) ISC-2002-2-36. 20. 4.2.3 CODIFICACION DEL LENGUAJE. Es claro que para describir detalladamente un evento se requiere la construcción de una expresión S lo suficientemente compleja y grande. Para evitar una carga excesiva en los recursos necesarios para el manejo de las mismas, el CIDF propone una codificación para este tipo de mensajes o expresiones.. Dicha codificación intenta codificar una expresión S en un flujo de octetos14, asignándole a cada identificador semántico un código único de cuatro octetos, y organizando el flujo de octetos de la misma manera jerárquica de la S expresión. Se recomienda [CIDF99] para una descripción detallada del algoritmo de codificación y decodificación.. 4.2.4. EJEMPLO. A manera de ejemplo se muestra un GIDO expresado en términos de una expresión S, y su correspondiente codificación:. 13 14. [RIVE97] Se define un octeto como un conjunto de 8 bits. Esta definición coincide con la definición estándar de un byte..

(31) 21. ISC-2002-2-36. (Delete (World Unix) (When (Time 14:58:12 24 Feb 1998 UTC) ) (Initiator (ReferTo 0x12345678) ) (FileSource (HostName 'ten.ada.net') (FullFileName '/etc/passwd') Figura 2. GIDO en términos de una expresión S. 00 08 00 06 00 00 08 00 02 yy 00 08 00 02 12 00 08 00 04 00 74 61 6e 00 00 00 65 70 77. 00 00 00 00 00 00 00 00 00 yy 00 00 00 00 34 00 00 00 00 00 65 64 65 00 00 00 74 61 6f. 00 00 00 00 00 00 50 00 00 yy 00 10 00 00 56 00 10 00 00 00 6e 61 74 15 13 0d 63 73 72. 70 13 08 7a 01 10 02 08 01 yy 10 01 08 78 78 34 21 13 0c 0b 2e 2e 00 04 00 2f 2f 73 64. Figura 3. Expresión S codificada.

(32) ISC-2002-2-36. 5. 22. IMPLEMENTACION DE UN MÓDULO DE EVENTOS DE RED: CNEG. A continuación se discutirá en detalle las características de implementación de un módulo de eventos de red, sensor de red. Dicho componente será publicado como CNEG (por las siglas en inglés de CIDF Network Event Generator).. 5.1. ALCANCE DEL COMPONENTE. El sensor de red deberá cumplir al menos las siguientes características:. •. Captura de eventos de red: el componente deberá ser capaz de capturar tráfico de red desde alguna de las interfaces de red disponibles en el sistema sobre el cual se ejecutará el componente.. •. Despliegue de información: el componente deberá facilitar el despliegue de la información capturada, ya sea por pantalla, archivos de registros o cualquier otro medio que se considere apropiado.. •. Intercambio de información: el componente deberá producir estructuras de mensajes, GIDOs, expresadas en términos de expresiones S, y comunicarlas a cualquier módulo de análisis que se encuentre disponible en el IDS..

(33) ISC-2002-2-36. 23. •. Filtro de captura: el componente deberá poder filtrar el tipo de eventos a capturar.. •. Filtro de tráfico (firewall): el componte deberá ser capaz de filtrar eventos de red, de manera que pueda permitir o negar el paso de los mismos al sistema donde se está ejecutando..

(34) 24. ISC-2002-2-36. 5.2. ARQUITECTURA LOGICA DEL COMPONENTE. Se propone el siguiente modelo arquitectónico del componente:. Sensor de Red. Motor de Captura. Tráfico de red capturado. Filtro de Captura. Tráfico de red. Tráfico de red filtrado. Motor de Extracción de Datos. Datos procesados. Filtro de Tráfico (Firewall) Componente de Análisis. GIDOs Generados. Interfaz de Comunicación. Figura 4. Arquitectura del Sensor de Red. Motor Generador de GIDOs.

(35) ISC-2002-2-36. 5.2.1. 25. MOTOR DE CAPTURA. El motor de captura es el eje central del componente sensor de eventos de red. En efecto, es él quien obtiene el tráfico de red directamente de un dispositivo físico. Este motor está dividido en dos módulos: filtro de tráfico y filtro de captura.. 5.2.1.1. FILTRO DE TRAFICO (FIREWALL). Este filtro es el encargado de permitir o rechazar el paso de tráfico de red hacia y desde el sistema en el cual sé esta ejecutando el componente sensor de red. Basa sus decisiones de acuerdo a características en los eventos de red, tales como origen y/o destino del tráfico, sentido del tráfico (entrante o saliente), etc. No hay forma de que ningún evento de red salga o entre del sistema si este filtro así no lo permite.. 5.2.1.2 FILTRO DE CAPTURA. Una vez el Filtro de Tráfico decide que tipo de eventos de red son permitidos, se procede ahora a capturar tales eventos. El filtro de captura permite seleccionar entre los eventos aceptados, cuales son de interés para el entorno del IDS. Este filtro basa sus decisiones de acuerdo a parámetros similares a los utilizados por el Filtro de Tráfico..

(36) ISC-2002-2-36. 26. Una vez los eventos de red son aceptados por el Filtro de Captura, se convierten en entradas del sensor, ie. del IDS.. 5.2.2. MOTOR DE EXTRACCION DE DATOS. Una vez los eventos de red son aceptados y permitidos tanto por el Filtro de Tráfico como por el Filtro de Captura, el componente se dispone a extraer datos relevantes de las entradas. El Motor de Extracción de Datos realiza esta labor tratando cada tipo de entrada de acuerdo a sus especificaciones15.. 5.2.3. MOTOR GENERADOR DE GIDOS. Este motor se encarga de generar los GIDOs, en términos de expresiones S. Este proceso se realiza llenando estructuras GIDOs previamente definidas, con las salidas resultantes del Motor de Extracción de Datos. Una vez este motor ha procesado una entrada, ésta está lista para ser comunicada al IDS.. 15. Las especificaciones de cada tipo de entrada están definidas en los RFC (Request For Comments) de los protocolos implementados en el sensor de red..

(37) ISC-2002-2-36. 27. En versiones posteriores de este sensor de eventos de red, éste motor debe, una vez generada la expresión S, codificarla de acuerdo al algoritmo de codificación especificado en [CIDF99].. 5.2.4. INTERFAZ DE COMUNICACION. Este componente interno cumple dos funciones básicas en el sensor de eventos de red. Por una parte, es el encargado de ubicar él (los) componente(s) con quien(es) se debe comunicar. Este proceso se realiza primero localizando el componente en el ambiente distribuido a través de una instancia del módulo comunicaciones, y luego conectándose al componente ubicado.. Una vez realizada la conexión, es él quien se encarga de enviar físicamente los GIDOs generados por el Motor de Generación de GIDOs..

(38) ISC-2002-2-36. 5.3. DECISIONES DE IMPLEMENTACION. 5.3.1. LENGUAJES DE DESARROLLO. 28. Dado que CNEG debe acceder dispositivos físicos, a saber tarjetas de red o NICs (por las siglas en ingles de Network Interface Card), y para agilizar el procesamiento interno previo al envió de un GIDO generado, se escogió el lenguaje de programación C. El mismo, permite una manejo muy eficiente y flexible en las estructuras requeridas para la captura de datos directamente desde una interfaz de red, así como para las estructuras necesarias para el manejo mismo de las entradas capturadas. Los submódulos Motor de Captura, Motor de Extracción de Datos y Motor de Generación de GIDOs están implementados en este lenguaje.. Si bien es cierto que, a pesar de los múltiples esfuerzos para estandarizar el lenguaje, C sufre de algunos problemas de portabilidad entre plataformas, estos son resueltos utilizando librerías ampliamente difundidas en varios ambientes de desarrollo y producción. Sin embargo es posible encontrar plataformas donde se requieran pequeñas modificaciones al sensor para lograr su puesta en producción. Futuras versiones del componente deben resolver este inconveniente.. Por otro lado, y teniendo en cuenta que la totalidad de los componentes de comunicaciones, análisis y respuesta utilizados en esta iteración del proyecto están desarrollados en un.

(39) ISC-2002-2-36. 29. ambiente Java, se escogió este lenguaje para la implementación de la Interfaz de Comunicación. Java no presenta los inconvenientes de portabilidad encontrados en el lenguaje C.. 5.3.2. AMBIENTE DE DESARROLLO Y PRUEBAS. Como ambiente de desarrollo y pruebas para la implementación de CNEG se utilizó el sistema operativo Linux16, principalmente por las características de su licencia de uso17 y por la amplia documentación de su ambiente de desarrollo18. Se escogió la distribución Red Hat197.3, por ser una de las más completas y populares. Esta distribución utiliza la versión de kernel20 2.4.18-321.. Los submódulos del sensor implementados en C fueron compilados exitosamente utilizando el compilador gcc22. Debido a que la compilación de CNEG requiere una serie de pasos especiales, se utilizo la herramienta make23, para la automatización de este proceso.. 16. http://www.linux.org/ GNU/GPL. http://www.gnu.org/copyleft/gpl.html. http://www.gnu.org/home.html. 18 http://www.tldp.org/ 19 http://www.redhat.com/ 20 http://www.kernel.org/ 21 Versión 2.4.18 de Kernel de Linux, revisión 3 de Red Hat. 22 GNU C Collection, versión 2.96. http://gcc.gnu.org/ 23 GNU Make, versión 3.79.1. http://www.gnu.org/software/make/ 17.

(40) ISC-2002-2-36. 30. Para la compilación y ejecución del submódulo implementado en Java se utilizó la versión Linux del SDK24 1.3.1_0625 de Sun Microsystems26, que corresponde a una revisión del SDK utilizado por los componentes de comunicaciones, análisis y respuesta. Es posible que se requieran modificaciones menores en el sensor para ser utilizado bajo SDKs 1.4.0_01 o posteriores.. 5.3.3. PROTOCOLOS. Esta implementación del módulo de eventos de red reconoce y procesa los siguientes protocolos de red: Ethernet, IP, ICMP, TCP y UDP. Se recomienda [TANE97], [RUSS01], [RFC768], [RFC777], [RFC791], [RFC792] y [RFC793] para una descripción detallada de dichos protocolos.. Esta selección se debe a que ellos representan y/o soportan la gran mayoría del tráfico de red encontrado en la actualidad. Sin embargo futuras versiones del componente podrán incluir nuevos protocolos de red.. Se debe tener presente que la versión actual del sensor de red no incluye el tratamiento de opciones en las cabeceras en los protocolos IP y TCP. 24 25. Standar Develpment Kit http://java.sun.com/j2se/1.3/.

(41) ISC-2002-2-36. 31. A partir de este momento se entenderá por entrada al componente, un datagrama o paquete Ethernet que contenga un paquete IP. A su vez este último puede contener paquetes TCP, UDP ó ICMP. Cada paquete Ethernet que sea capturado por CNEG generará un mensaje GIDO de salida, que podrá ser usado por un componente de análisis de red.. 5.3.4. FILTRO DE TRAFICO. CNEG se apoya en la herramienta iptables27. Esta herramienta es un filtro de tráfico de red al nivel de kernel de Linux que se basa en el uso de reglas configurables para determinar si un paquete es aceptado o no.. iptables utiliza tres listas o cadenas conocidas como INPUT, OUTPUT y FORWARD, aunque el componente solo hace uso de las dos primeras. La cadena INPUT es utilizada cuando se detecta un paquete entrando al sistema, de igual forma en que la cadena OUTPUT es usada cuando se detecta un paquete saliendo del mismo.. Cada cadena puede contener una lista de reglas que determinan la aceptación o el rechazo del paquete. Esta determinación utiliza un mecanismo de ajuste de patrones utilizando características tales como el protocolo del paquete, la dirección Ethernet origen del. 26 27. http://www.sun.com/ Versión 1.2.5. http://www.iptables.org.

(42) ISC-2002-2-36. 32. paquete, las direcciones IP origen/destino del paquete o los puertos TCP/UDP origen/destino del paquete.. Cuando un paquete alcanza una cadena, es decir el paquete está intentando entrar o salir del sistema, se examinan una a una las reglas de la cadena, hasta encontrar una regla cuyo patrón coincida con el paquete. Si esto sucede, la política asignada a esta regla determina si el paquete puede o no continuar su camino. Si después de examinar todas las reglas de una cadena no se ha encontrado ninguna cuyo patrón coincida con el paquete, entonces la política por defecto de la cadena determina la suerte del mismo. iptables evalúa todos y cada uno de los paquetes que intentan entrar o salir del sistema, incluso aquellos cuya dirección de origen y/o destino es 127.0.0.1, a saber la dirección local del sistema. Cabe recordar que este tipo de paquetes no alcanza nunca el nivel 2 del modelo OSI de ISO28, y por lo tanto no pasan a través de un dispositivo físico de red.. CNEG utiliza el potencial de iptables, a través de la opción de línea de comandos -w, así como las opciones adicionales -c y -r, las cuales serán discutidas más adelante en este documento.. Se recomienda [RUSS02] para un mejor entendimiento del filtro de tráfico usando iptables, así como el uso general de esta herramienta..

(43) ISC-2002-2-36. 5.3.5. 33. CAPTURA DE TRAFICO DE RED. La implementación del módulo de red utiliza la librería libpcap29 como interfaz de captura de paquetes a través de dispositivos físicos de red. Se recomienda [CARS00], [CASA01] y [TCPD02] para un mejor entendimiento del funcionamiento de ésta librería.. Se debe tener presente que las entradas capturadas por esta librería deben prevenir directamente de un dispositivo físico de red. Es por esto que los paquetes cuya dirección IP origen y/o destino sea 127.0.0.1 no serán procesados por CNEG.. 5.3.6. COMUNICACION C - JAVA. Para la comunicación entre los submódulos implementados en C y los submódulos implementados en Java, a saber Motor de Generación de GIDOs e Interfaz de Comunicación, se utiliza un esquema CORBA30, donde el Motor de Generación de GIDOs es cliente de la Interfaz de Comunicación.. 28. [TANE97] Versión 0.6.2. http://sourceforge.net/projects/libpcap/. http://www.tcpdump.org/ 30 Common Object Request Broker Architecture. http://www.corba.org/ 29.

(44) 34. ISC-2002-2-36. Para lograr ésta comunicación, el sensor de red utiliza el ORB del SDK del Java para controlar el lado del servidor en la comunicación. Por otro lado para el lado del cliente se utiliza el ORB31 para C ORBit32.. La siguiente figura explica el funcionamiento de la comunicación C – Java.. Motor de Generación de GIDOs. Interfaz de Comunicación. ORB - ORBit. ORB – JavaORB IIOP TCP. Sistema local (localhost). Figura 5. Modelo de comunicación C - Java. 31 32. Object Request Broker. Versión 0.5.17. http://www.labs.redhat.com/orbit/. http://orbit-resource.sourceforge.net/.

(45) ISC-2002-2-36. 5.3.7. 35. ENVIO DE GIDOS. Una vez un paquete Ethernet ha sido capturado y procesado por CNEG, este debe enviar un GIDO, en términos de una expresión S al componente de análisis previamente localizado.. Se propone entonces la siguiente estructura de expresión S para el manejo el flujo de información entre el componente sensor de eventos de red y el componente de análisis de red..

(46) ISC-2002-2-36. (And (ByMeansOf (Attack (Outcome (When (Time hh:mm.ss dd mm aa) ) (Initiator (ReferTo 1) ) (Target (ReferTo 2) ) ) (And (OpenApplicationSession (When (Time hh:mm.ss dd mm aaaa) ) (Initiator (IP (IPVersion 4) (IPAddressI xx.xx.xx.xx) ) (TCPPort xxx) (ReferAs 1) ) (Receiver (IPAddressR yy.yy.yy.yy) (StandardTCPPort 161) (ReferAs 2) ) ) (SendMessage (When (Time hh:mm.ss dd mm aa) ) (Initiator (ReferTo 1) ) (Receiver (ReferTo 2) ) (Message (IPServiceType 0) (IPTotalLenght 72) (IPIdentifier xxxx) (IPChecksum xxxx) (IPFlagsValue xxxx) (ICMPType xxxx) (ICMPCode xxxx) (TCPFlags xxxx) (TCPSequenceNumber xxxx) (TCPAckNumber xxxx) (TCPWindow xxxx) (TCPChecksum xxxx) (TCPUrgentPointer xxxx) (TCPMss xxxx) (PacketContent 'xxxx') (Comments 'xxxx') ) (Multiplier 1) ) ) ) ) ). 36.

(47) ISC-2002-2-36. 5.4. 37. MEJORAS AL MODULO DE EVENTOS DE RED. Se proponen las siguientes mejoras para futuras versiones de CNEG:. •. Codificación de las expresiones S generadas por el submódulo Motor Generador de GIDOs, antes de ser pasadas a la Interfaz de Comunicación. Dicha codificación debe realizarse usando el algoritmo descrito en [CIDF99].. •. Inclusión de procesamiento de opciones de cabecera de los protocolos IP y TCP en el submódulo Motor de Extracción de Datos.. •. En la actualidad la comunicación entre el Modulo Generador de GIDOs y la Interfaz de Comunicación es unidireccional, debido a restricciones en el ORB Orbit. Se recomienda la actualización de este ORB a la plataforma Orbit233 para resolver este inconveniente. Se debe considerar también la utilización de JNI34 como alternativa para comunicación entre ambos submódulos.. •. Incluir la opción de reconfiguración de los filtros de tráfico y captura en caliente, como una posible alternativa para un módulo de respuestas.. 33 34. Versión 2.5.0. Java Native Interface. http://java.sun.com/products/jdk/1.2/docs/guide/jni/.

(48) ISC-2002-2-36. 38. •. Actualización a la versión 0.7.1 de la librería libpcap.. •. Inclusión de archivos de autoconfiguración, para la compilación e instalación del sensor, independiente de la plataforma de desarrollo o producción.. •. Soporte para el manejo de la herramienta ipchains. Esto deberá permitir plataformas Linux, cuya versión de kernel corresponda a 2.2.x.. •. Generación de páginas de manual con la documentación del sensor.. •. Generación de archivos de registro.. •. Mejoras en la sintaxis de las reglas de los filtros de tráfico y captura.. •. Creación de una interfaz gráfica de usuario.. •. Acoplamiento de un módulo sensor de red/análisis de red como un único componente..

(49) ISC-2002-2-36. 5.5. 39. MEJORAS AL IDS. Se proponen las siguientes mejoras para futuras iteraciones del IDS:. •. Por razones de eficiencia el módulo de análisis de red dispone de buffers de almacenamiento de GIDOs a analizar de tamaño limitado. En un ambiente de producción estas estructuras se llenan rápidamente, evitando así el análisis de todos y cada uno de los eventos capturados por el módulo sensor de red. Esto permite el paso no detectado a ataques. Se espera que nuevas versiones de éste módulo corrijan este problema.. •. Los GIDOs generados por los diferentes módulos deben ser codificados según el algoritmo descrito en [CIDF99]..

(50) 40. ISC-2002-2-36. 6. CONCLUSIONES. La tecnología cumple un papel fundamental en el desarrollo de sociedad. Los últimos acontecimientos sugieren que se deben realizar grandes esfuerzos para proteger y asegurar el correcto funcionamiento de los sistemas información de las organizaciones.. Gran parte de ese esfuerzo debe centrarse en la definición de políticas de seguridad al interior de las organizaciones. Una vez se cuenta con esto, deben buscarse herramientas que ayuden en la implementación de dichas políticas.. Nuevas tecnologías han surgido para facilitar esta labor. En particular los IDSs ayudan a proteger la infraestructura informática. La utilización de IDS distribuidos permite una mayor visión y cubrimiento de los riesgos informáticos a los cuales está sometida una organización.. Nuevas arquitecturas distribuidas han evolucionado los IDSs. Estos nuevos modelos dan mayor flexibilidad, eficiencia y eficacia al momento de contrarrestar un ataque, a la vez que permiten la temprana identificación de nuevos tipos de ataques..

(51) 41. ISC-2002-2-36. 7. BIBLIOGRAFÍA. [BLAN01]. BLANCO, Marcela. Respuestas Avanzadas en un IDS. Universidad de Los Andes, Bogotá, D.C., Colombia. 2001.. [BLAN02]. BLANCO, Marcela. Respuestas avanzadas en un Sistema de Detección de Intrusos. Universidad de Los Andes, Bogotá, D.C., Colombia. 2002.. [CARS00]. CARSTENS, Tim. Programming with Libpcap: a PCAP Tutorial. http://reactor-core.org/security/libpcap-tutorial.html. 2000.. [CASA01]. CASADO, Martin. Packet Capture With libpcap and other Low Level Network Tricks. http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.html. 2001.. [CIDF98]. CIDF. Communication in the Common Intrusion Detection Framework. http://www.isi.edu/gost/cidf/drafts/communication.txt. 1998.. [CIDF99]. CIDF. A Common Intrusion Specification http://www.isi.edu/gost/cidf/drafts/language.txt. 1999.. [CIDF01a]. CIDF. CIDF API. http://www.isi.edu/gost/cidf/drafts/api.txt. 2001.. [CIDF01b]. CIDF. The Common Intrusion Detection Framework Architecture. http://www.isi.edu/gost/cidf/drafts/architecture.txt. 2001.. [HOLG01a]. HOLGUÍN, Andrés. Módulo de Autenticación LAD Para Sistemas de Información e IDSs. Universidad de Los Andes, Bogotá, D.C., Colombia. 2001.. Language.. [HOLG01b] HOLGUÍN, Andrés. Análisis Del Sistema De Información LAD (LDAP Autentication Deamon). Mayo de 2001. Universidad de Andes, Bogotá, D.C., Colombia. 2001. [ISS98]. Internet Security Systems. Network- vs. Host-based Intrusion Detection. A Guide to Intrusion Detection Technology. Atlanta, Estados Unidos de Norteamérica. 1998.. [LOPE01]. LÓPEZ, Oscar y PRIETO, Misael. Arquitectura de Comunicaciones para un IDS en un Ambiente TCP/IP. Universidad de Los Andes, Bogotá, D.C., Colombia. 2001..

(52) ISC-2002-2-36. 42. [LOPE02]. LÓPEZ, Oscar y PRIETO, Misael. Comunicaciones en un Sistema de Detección de Intrusos. Diseño e Implementación. Universidad de Los Andes, Bogotá, D.C., Colombia. 2002.. [McCA92]. McCANNE, Steven y JACOBSON, Van. The BSD Packet Filter: A New Architecture for User-level Packet Capture. Berkeley, Estados Unidos de Norteamérica. 1992. [MEIN98]. MEINEL, Carolyn. The ABCs of IDSs (Intrusion Detection Systems). http://messageq.ebizq.net/security/meinel_2.html. 1998.. [MORE01a] MORENO, Andrés. Procesamiento de Información en un IDS. Implementación en un Ambiente TCP/IP. Universidad de Los Andes, Bogotá, D.C., Colombia. 2001. [MORE01b] MORENO, Andrés. Procesamiento de Información en un IDS. Implantación de una Arquitectura Articulada. Universidad de Los Andes, Bogotá, D.C., Colombia. 2001. [NAVA02a] NAVARRETE, Alexander y PEÑA, Mario. Desarrollo e Implementación del Módulo De Análisis In-Line de un IDS, a Partir de Agentes Distribuidos Sobre Una Red TCP/IP. Universidad de Los Andes. Bogotá, D.C., Colombia. 2002. [NAVA02b] NAVARRETE, Alexander y PEÑA, Mario. Desarrollo e Implementación del Módulo De Análisis In-Line de un IDS, a Partir de Agentes Distribuidos Sobre Una Red TCP/IP. Artículo. Universidad de Los Andes. Bogotá, D.C., Colombia. 2002. [NORT01]. NORTHCUTT, Stephen y NOVAK, Judy. Guía Avanzada Detección de Intrusos 2a. Edición. Madrid, España. 2001.. [OLOV92]. OLOVSSON, Tomas. A Structured Approach to Computer Security. http://downloads.securityfocus.com/library/tr122to.pdf. Suecia. 1992.. [PARM02]. PARMAR, S. An Introduction to http://downloads.securityfocus.com/library/index.html. 2000.. [PRIE01]. PRIETO, Edgar. Sensores Basados en Firewalls. Universidad de Los Andes. Bogotá, D.C., Colombia. 2001.. [RFC768]. Postel, J. RFC 768 User Datagram Protocol. 1980.. Security..

(53) 43. ISC-2002-2-36. [RFC777]. Postel, J. RFC 777 Internet Control Message Protocol. 1981.. [RFC791]. Information Sciences Institute. RFC 791 Internet Protocol. Marina del Rey, Estados Unidos de Norteamérica. 1981.. [RFC792]. Postel, J. RFC 792 Internet Control Message Protocol. 1981.. [RFC793]. Information Sciences Institute. RFC 793 Transmission Control Protocol. Marina del Rey, Estados Unidos de Norteamérica. 1981.. [RIVE97]. RIVEST, Ronald. http://theory.lcs.mit.edu/~rivest/sexp.html. 1997.. [RUSS01]. RUSSELL, Rusty. Linux Networking-concepts HOWTO. http://www.netfilter.org/documentation/HOWTO/networking-conceptsHOWTO.html. 2001.. [RUSS02]. RUSSELL, Rusty. Linux 2.4 Packet Filtering HOWTO. http://www.netfilter.org/documentation/HOWTO/packet-filteringHOWTO.html. 2002.. [SANS03a]. SysAdmin, Audit, Network, Security. Intrusion Detection http://www.sans.org/resources/idfaq/false_alarms.php. 2003.. [SANS03b]. SysAdmin, Audit, Network, http://www.sans.org/rr/intrusion/IDS.php. 2003.. [TANE97]. TANENBAUM, Andrew. Redes de computadoras Tercera Edición. Prentice Hall. 1997.. [TCPD02]. Tcpdump. pcap Packet http://www.tcpdump.org/pcap3_man.html. 2002.. [VEGA01]. VEGA, Juan. Módulo de Análisis off-line. Universidad de Los Andes, Bogotá D.C., Colombia. 2001.. SEXP---(S-expressions).. FAQ.. SecurityIDS.. Capture. library..

(54) 44. ISC-2002-2-36. ANEXO A. REQUERIMIENTOS DE EJECUCION Y COMPILACION. La implementación CNEG ha sido compilada y probada exitosamente en plataformas Red Hat 7.1, 7.2 y 7.3. Se espera, sin embargo, que pueda ser puesta en producción en cualquier ambiente Linux con versión de kernel 2.4.x35 siempre y cuando este cuente con:. •. ORBit versión 0.5.17 o superior. Es importante tener cuenta que la plataforma de ORB ORBit no es compatible con la plataforma ORBit2. Requerido para compilación y ejecución.. •. libpcap versión 0.6.2 o superior. Requerido para compilación y ejecución.. •. iptables versión 1.2.5 o superior. Requerido para ejecución.. •. SDK de Java versión 1.3.x. Requerido para compilación y ejecución.. •. gcc o cualquier otro compilador de C. Requerido para compilación.. 35. iptables requiere una versión de kernel de Linux igual o superior a 2.4.0. Versiones anteriores deben utilizar ipchains como herramienta de filtro de tráfico..

(55) ISC-2002-2-36. •. 45. make. Requerido para compilación, sí y solo si se desea utilizar el guión de compilación.

(56) 46. ISC-2002-2-36. ANEXO B. CARACTERISTICAS DE CNEG. CNEG provee las siguientes opciones de configuración disponibles como opciones de línea de comandos.. B.1. SELECCIÓN DE DISPOSITIVO DE CAPTURA. CNEG permite configurar el dispositivo físico de captura de tráfico de red a través de la opción -d (device o dispositivo). El dispositivo especificado deber ser alguna de las interfaces de red Ethernet disponibles en el sistema donde se ejecuta el sensor de red. En plataformas Linux estas son generalmente numeradas como eth0, ..., ethN –1, siendo N el número de dispositivos de red configurados en el sistema.. Si esta opción no está especificada, CNEG intentará ubicar cualquier dispositivo de red disponible (usualmente eth0).. Uso: ./cneg –d eth<N>, donde N es un número entero positivo..

(57) ISC-2002-2-36. B.2. 47. GENERACION DE GIDOS. CNEG tiene tres modos, no excluyentes, de funcionamiento. El primero de ellos es un sencillo pero poderoso recolector de eventos de red36 y es el modo mínimo de funcionamiento del componente. Este modo corresponde al seleccionado por defecto.. A través de la opción -g (generate GIDOs o generación de GIDOs), CNEG se puede acoplar a un entorno IDS distribuido. Esta opción le indica a CNEG que debe funcionar en el segundo modo de funcionamiento, y entonces debe iniciar el submódulo de Interfaz de Comunicación, ubicar y conectar un componente de análisis de red y generar GIDOs como respuesta a cada paquete de red capturado por el sensor.. Uso: ./cneg -g. B.3. DESPLIEGUE DE AYUDA. Con la opción –h (help o ayuda), el componente despliega en pantalla una breve descripción de las opciones disponibles al usuario en línea de comandos. Esta ayuda también se muestra al introducir opciones incorrectas o inválidas en la línea de comandos..

(58) ISC-2002-2-36. 48. Uso: ./cneg –h. B.4. PAQUETES A CAPTURAR. Se puede configurar el sensor de red para capturar únicamente un determinado número de paquetes utilizando la opción –n (number of packets to capture o número de paquetes a capturar). Una vez se hayan capturado el número de paquetes especificados, CNEG se detendrá.. El número de paquetes a capturar debe ser un número entero positivo. De lo contrario, el sensor leerá paquetes indefinidamente, hasta que sea señalizado para detener su ejecución. Este comportamiento es el modo de funcionamiento por defecto.. Uso: ./cneg –n <N>, donde N es un número entero positivo.. B.5. MODO PROMISCUO. CNEG puede capturar tráfico de red cuyo origen y/o destino sea diferente al sistema donde se está ejecutando, usando la opción –p (promiscous o promiscuo). Esta característica sólo 36. Este modo de funcionamiento es conocido en la literatura como sniffer..

(59) ISC-2002-2-36. 49. está disponible si el dispositivo de captura utilizado está conectado a un concentrador (hub) o a un puerto espejo37 de un dispositivo de enrutamiento. Si esto no sucede, CNEG funcionará en su modo por defecto, es decir, solo podrá capturar tráfico de red que provenga y/o vaya dirigido al dispositivo de red especificado para la captura de eventos. Esta opción es extremadamente útil si se desea controlar el tráfico en un segmento de red.. Uso: ./cneg -p. B.6. DESPLIEGUE DE INFORMACION. A través de la opción –v (verbose o despliegue de información) es posible configurar el nivel de información mostrada en pantalla a medida que CNEG va capturando y procesando entradas. Existen cuatro modos diferentes de despliegue de información.. •. Despliegue apagado: (opción por defecto) CNEG sólo mostrará en pantalla información concerniente al inicio y finalización del sensor, así como algunos errores sucedidos durante la ejecución.. 37. Se entiende por puerto espejo un puerto especial al cual se dirige todo el tráfico de red que circula por el dispositivo de enrutamiento..

(60) ISC-2002-2-36. •. 50. Tráfico de red: (-v) esta opción permite el despliegue de información del último paquete procesado. Esta información incluye detalles de los protocolos Ethernet, IP, ICMP, TCP y UDP, según sea el caso.. •. GIDOs generados: (-vv) usando esta opción CNEG mostrará en pantalla la expresión S generada utilizando la información del último paquete procesado. Esta opción sólo es válida si se usa en conjunto con la opción -g.. •. Despliegue total: (-vvv) esta opción permite el despliegue tanto de los detalles como de la expresión S del último paquete procesado. Esta opción sólo es válida si se usa en conjunto con la opción -g.. En un ambiente de producción se recomienda no seleccionar ningún nivel de despliegue debido a que las operaciones de escritura en pantalla pueden afectar el rendimiento del sensor. De igual forma la cantidad de paquetes que se pueden llegar a procesar en poco tiempo es tal, que simplemente la generación de información resulta inteligible y por ende inútil.. Uso: ./cneg –v[ v [ v ] ].

(61) ISC-2002-2-36. B.7. 51. USO DE REGLAS DE FILTRO DE TRAFICO. Usando la opción –w (firewall o filtro de tráfico), CNEG podrá activar reglas en el filtro de tráfico de red. Este modo de corresponde el tercer modo básico de funcionamiento del sensor. El filtro activado corresponde a un conjunto de reglas iptables generadas a través del archivo que se pasa como argumento a esta opción. Cada línea en el archivo es tratada como una regla de filtro. Cada línea debe tener la siguiente sintaxis: [cad] [pol] proto [ori] [> dest] y cumplir las siguientes normas:. •. cad: indica la cadena a la cual será añadida la regla que se está procesando. Sí está presente debe ser la primera palabra de la regla. Puede tomar los valores in (cadena INPUT de iptables) ó out (cadena OUTPUT de iptables). Sí no está presente se asume el valor in.. •. pol: indica la política de la regla que se está procesando. De estar presente debe ser estar ubicada después de cad (sí cad está presente) y antes de proto. Puede tomar los valores + (el paquete que se ajuste a este patrón será aceptado) ó – (el paquete que se ajuste a este patrón será rechazado). Sí no está presente se asume el valor +..

(62) ISC-2002-2-36. •. 52. proto: indica el protocolo sobre el cual se evaluará la regla. Debe estar presente. Puede tomar los valores de ether, icmp, ip, tcp, udp ó * (indicando que se permiten ambos protocolos TCP y UDP).. •. ori: indica el origen del paquete. Sí está presente debe estar ubicado después de proto y antes de antes de > dest (sí > dest está presente). Su valor depende del protocolo que se está evaluando:. •. Sí proto es ether, ori debe ser una cadena con el formato a:b:c:d:e:f, donde a, b, c, d, e y f son numero hexadecimales de hasta dos dígitos, (ie. su valor estará entre 0 y FF). Este formato corresponde al formato estándar de una dirección mac o Ethernet.. •. Sí proto es icmp ó ip, ori puede ser una cadena con el formato a.b.c.d donde a, b, c y d son número decimales cuyo valor oscila entre 0 y 255. Este formato corresponde al formato estándar de una dirección IP. Adicionalmente ori puede tener el formato ‘<nombre_sistema>’, donde <nombre_sistema> es una cadena que contiene caracteres alfanuméricos y que representa el nombre de un sistema. El formato * también es válido.. •. Sí proto es tcp o udp, ori puede ser una cadena con cualquiera de los siguientes formatos: dir, port, dir:port ó *, donde port es un número decimal entre 0 y 65535.

(63) ISC-2002-2-36. 53. y dir es una cadena en el formato especificado en el numeral anterior (proto igual a ip ó icmp).. •. Finalmente, sí proto es *, ori debe ser una cadena en el formato port ó *, donde port corresponde a la definición dada en el numeral anterior (proto es udp ó tcp).. Si el valor de ori corresponde a *, esto será equivalente a cualquier dirección/puerto o cualquier dirección /puerto origen38.. •. > dest: indica el destino del paquete. Sí está presente debe estar ubicada después de ori y debe ser la última palabra de la línea. Su valor depende del protocolo que se esté evaluando, y corresponde a la misma definición del valor de ori, excepto en los siguientes casos:. •. Sí proto es ether, > dest no debe estar presente.. •. Sí proto es tcp o udp y el valor de ori corresponde al uno de los formatos dir ó dir:port, el valor de dest no podrá ser *. De igual forma sí el valor de ori corresponde a *, el valor de dest no podrá tener los formatos dir ó dir:port.. 38. Sí > dest está presente indica cualquier dirección /puerto origen, de lo contrarío indica cualquier dirección /puerto origen/destino..

(64) ISC-2002-2-36. 54. Si el valor de dest corresponde a *, esto indicará cualquier dirección/puerto destino, en el protocolo que se esté evaluando actualmente.. Se permite el uso de comentarios a través de los caracteres //. Todo contenido que se encuentre entre estos caracteres y el fin de línea será ignorado.. Si alguna de las líneas no cumple cualquiera de las normas citadas anteriormente no será tenida en cuenta en la generación del filtro de tráfico.. El orden de las reglas contenidas en el archivo representa el orden en que son evaluadas dentro de una cadena iptables. Debido a esto el filtro icmp - icmp. permitirá todo el tráfico ICMP que entre al sistema, mientras que el filtro -icmp icmp. rechazará todo el tráfico ICMP que entre al sistema.. Uso: ./cneg –w <firewall_file>, donde <firewall_file> corresponde a la ruta del archivo que contiene las regles de filtro de tráfico..

(65) ISC-2002-2-36. B.8. 55. VACIADO DE REGLAS DE FILTRO. Usando la opción –c (clean o limpiar), CNEG podrá eliminar las reglas del filtro de tráfico existentes antes de la ejecución del sensor. Esta opción sólo es válida si se usa en conjunto con la opción –w. Se debe tener presente que esta opción eliminará las reglas de todas las cadenas iptables, incluso las de la cadena FORWARD. La regla generada por ésta opción será ejecutada antes de aplicar cualquier otra regla iptables.. Uso: ./cneg –w <firewall_file> -c, donde <firewall_file> corresponde a la ruta del archivo que contiene las regles de filtro de tráfico.. B.9. AJUSTE DE POLITICA POR DEFECTO DEL FILTRO DE TRAFICO. La opción –r permite ajustar la política por defecto de las cadenas iptables INPUT y OUTPUT. Está política define la suerte del paquete una vez haya recorrido todas y cada una de las reglas de la cadena que esta siendo evaluada, sin encontrar alguna cuyo patrón coincida con el paquete que se está procesando. Si ésta opción no está presente, la política por defecto es aceptar el paquete. De lo contrario el paquete será rechazado.. Si esta opción se usa en conjunto con la opción -g, se incluirá una regla al principio de cada cadena, que permita el tráfico TCP desde la dirección IP 127.0.1 hacia la dirección IP.

(66) ISC-2002-2-36. 56. 127.0.0.1, a saber la dirección local del sistema, con cualquier puerto origen/destino. Esto debido a que la comunicación realizada a través de CORBA se hace utilizando el protocolo TCP. Es importante recordar que este tráfico nunca será físicamente enviado fuera del sistema, por lo que las reglas generadas no deberían afectar las políticas de seguridad de la organización.. Esta opción debe usarse en conjunto con la opción –w.. Uso: ./cneg –w <firewall_file> -r, donde <firewall_file> corresponde a la ruta del archivo que contiene las regles de filtro de tráfico.. B.10. USO DE REGLAS DE FILTRO DE CAPTURA. Usando la opción –f (filter o filtro de captura), CNEG podrá activar reglas en el filtro de captura. El filtro activado corresponde a un conjunto de son reglas BPF39 generadas a través del archivo que se pasa como argumento a esta opción. Cada línea en el archivo es tratada como una regla de filtro. Cada línea debe tener la siguiente sintaxis: [op] [pol] proto [ori] [> dest] y cumplir las siguientes normas:.

(67) ISC-2002-2-36. •. 57. op: indica el operador de la regla que se está procesando. Sí está presente debe ser la primera palabra de la regla. Puede tomar los valores and (condición lógica Y) ó or (condición lógica O). Sí no está presente se asume el valor or, excepto para la primera regla, la cual de debe contener un operador.. •. pol: indica la política de la regla que se está procesando. De estar presente debe ser estar ubicada después de op (sí cad está presente) y antes de proto. Puede tomar los valores + (el paquete que se ajuste a este patrón será aceptado) ó – (el paquete que se ajuste a este patrón será rechazado). Sí no está presente se asume el valor +.. •. proto: indica el protocolo sobre el cual se evaluará la regla. Debe estar presente. Puede tomar los valores de ether, icmp, ip, tcp, udp ó * (indicando que se permiten ambos protocolos TCP y UDP).. •. ori: indica el origen del paquete. Sí está presente debe estar ubicado después de proto y antes de antes de > dest. Su valor depende del protocolo que se está evaluando:. •. Sí proto es ether, ori debe ser una cadena con el formato a:b:c:d:e:f, donde a, b, c, d, e y f son numero hexadecimales de hasta dos dígitos, (ie. su valor estará entre 0 y FF). Este formato corresponde al formato estándar de una dirección mac o Ethernet. El formato * también es válido.. 39. [McCA92].