1. OBJETIVOS DEL PROYECTO ALCANCE DEL PROYECTO ESTADO DEL ARTE SISTEMAS DE DETECCION DE INTRUSOS... 8

Transcripción

1 1. OBJETIVOS DEL PROYECTO ALCANCE DEL PROYECTO ESTADO DEL ARTE SISTEMAS DE DETECCION DE INTRUSOS SEGURIDAD PERIMETRAL CLASIFICACIÓN DE IDS IMPLANTACIÓN DE IDS ATAQUES INFORMATICOS E INTRUSION EN REDES FASES DE UN ATAQUE ATAQUES CONOCIDOS MODELOS DISTRIBUIDOS MODELO CLIENTE-SERVIDOR MODELO PEER-TO-PEER (P2P) MODELO DE AGENTES INTELIGENTES MIDDLEWARE HERRAMIENTAS Y TECNOLOGÍAS USADAS TECNOLOGIA JAVA JADE MODELO DE ARQUITECTURA MODELO FUNCIONAL NTOP REDES NEURONALES PROCESO DE APRENDIZAJE TIPOS DE NEURONAS EL PERCEPTRÓN MULTICAPA

2 ENTRENAMIENTO REALIZADO CAPTURA DE DATOS ENTRENAMIENTO DE LA RED NEURONAL RESULTADOS DEL ENTRENAMIENTO DESCRIPCIÓN FUNCIONAL DOMINIO DEL SISTEMA DIAGRAMA DE DOMINIO DEFINICIÓN DE CONCEPTOS AGENTES DEL SISTEMA AGENTE SENSOR AGENTES SENSORES DE DATOS AGENTE INTÉRPRETE AGENTE PROCESADOR COMPORTAMIENTOS PERIÓDICO SIMPLE DIAGRAMA DE CLASES ARQUITECTURA DEL SISTEMA ARQUITECTURA JAVA JADE MULTIAGENTE ARQUITECTURA DEL SISTEMA DESARROLLADO MODELO DE ARQUITECTURA EN CAPAS MODELO DE ARQUITECTURA DEL SISTEMA DESARROLLADO MODELOS DE COMPORTAMIENTOS DISTRIBUCIÓN DEL PROYECTO

3 CARPETA DE PROYECTO IDSRN CARPETA DE PROGRAMAS E INSTALABLES INSTALACIÓN IDSRN PLANIFICACIÓN Y PRESUPUESTO DEL PROYECTO ORGANIZACIÓN DEL PROYECTO METODOLOGÍA Y RECURSOS PLANIFICACIÓN DE TAREAS PRESUPUESTO CONCLUSIONES BIBLIOGRAFÍA SIGLAS Y ACRÓNIMOS ANEXOS ANEXO 1: MANUAL DE INSTALACIÓN DEL SISTEMA IDSRN INSTALACIÓN DE LA MÁQUINA VIRTUAL JAVA INSTALACIÓN DE LA SONDA NTOP INSTALACIÓN DE CYGWIN INSTALACIÓN DE LA HERRAMIENTA RRDTOOL INSTALACIÓN DE LA PLATAFORMA IDSRN ANEXO 2: MANUAL DE USO DEL SISTEMA IDSRN CONFIGURACIÓN DE NTOP USO DE RRDTOOL ARRANQUE Y CONFIGURACIÓN DE LOS AGENTES CASO EJEMPLO ANEXO 3: REDES NEURONALES

4 4 1. OBJETIVOS DEL PROYECTO Hoy día una infraestructura de red es fundamental para todas las empresas, ya que mejora la comunicación en gran medida, y por consiguiente, la productividad. Por este mismo motivo una correcta administración de la misma es crítica, aun en el supuesto de que sea solamente interna, es decir, una intranet. Debido a la enorme cantidad de parámetros que el administrador de la red ha de tener en cuenta, sumado a que normalmente no es un experto en determinadas áreas, se hace necesaria una herramienta que facilite el trabajo de gestión así como el conocimiento específico de un experto para detectar situaciones anómalas (ataques, uso indebido ). Este experto, en conjunción con las herramientas adecuadas, sería capaz de desarrollar un sistema inteligente de adquisición de información, para así generar conclusiones cualitativas y/o cuantitativas sobre el estado de la red. Una de las mejores herramientas para este propósito es la sonda de red Ntop, potente software que permite monitorizar el estado de una red de una forma sencilla y gráfica, haciendo la información fácil de entender. Según lo planteado, el objetivo principal será el desarrollo de un sistema inteligente de detección de anomalías de red que integre la información de Ntop. Esa información tendrá que ser capaz de procesarla y generar conclusiones. Esta información que deja el programa se almacena en unas bases de datos de tipo roundrobin, qué, debidamente procesados, alimentan una red neuronal capaz de aprender lo que se supone que debe ser un comportamiento normal del tráfico de la red. De esta forma el sistema podrá saber cuándo hay una anomalía, y seguidamente dar el aviso correspondiente. Aparte de los objetivos principales existirán una serie de criterios. En resumen: 1. Desarrollar un sistema inteligente distribuido capaz de generar conclusiones sobre el estado y uso de una red. 2. Diseñar una interfaz gráfica de usuario sencilla y funcional que facilite al usuario el manejo del sistema. 3. Implantar el sistema desarrollado en una red de computadores real. 4. Economizar los recursos dedicados a la seguridad informática en redes con la utilización de un producto barato y eficaz y el uso de herramientas de código libre.

5 5 5. Incrementar la confianza de los administradores de redes en los Sistemas de detección de anomalías, como herramienta útil en la seguridad informática. 6. Concienciar a la sociedad informática de los problemas que pueden plantearse si no se utilizan sistemas adecuados de seguridad.

6 6 2. ALCANCE DEL PROYECTO La consecución de los objetivos planteados en el proyecto, se llevara a cabo a través de distintos procedimientos: - Se parte de una herramienta de monitorización de red. En este proyecto se ha elegido Ntop, por gozar de una gran confianza entre los usuarios, y mostrar de forma gráfica y sencilla una gran cantidad de información acerca del estado de la red, además de ser de libre distribución. - Se toma como modelo de arquitectura distribuida el paradigma de agentes inteligentes. Para ello se toma el middleware JADE como base de su desarrollo por ser una tecnología estable, bien documentada y de libre distribución. - Para optimizar los resultados del sistema se facilita la información necesaria para la adecuada distribución de sensores en la red y su configuración individual. - Se utiliza un entorno de pruebas para la verificación del correcto funcionamiento del sistema. - La implantación y uso del sistema se facilita mediante manuales que se proporcionan con la distribución del proyecto. - Tanto el software base del proyecto (monitorización, middleware...) como las herramientas de desarrollo utilizadas (lenguaje y entorno de programación, herramientas de documentación...) son gratuitos y de libre distribución. - La investigación realizada sobre los temas de seguridad informática, Sistemas de Detección de Intrusos y arquitecturas software distribuidas aporta nuevos conocimientos cuya aplicación mejora el rendimiento de los elementos de partida. - Los Sistemas de Detección de Intrusos, que en un principio tuvieron una gran aceptación, no gozan actualmente de una gran confianza por parte de sus usuarios. El presente proyecto intenta que los IDS (del inglés Intrusion Detection System, Sistemas de Detección de Intrusos) recuperen la credibilidad perdida, proponiendo una solución eficaz.

7 7 - Los administradores de red deben concienciarse de la utilidad de los Sistemas de Detección de Intrusos para la seguridad informática. Su mayor eficacia se alcanza combinándolos adecuadamente con otros componentes de seguridad, como los cortafuegos. - Los métodos de seguridad serán eficaces siempre y cuando los usuarios conozcan los peligros a los que están expuestos los sistemas informáticos a acciones malintencionadas llevadas a cabo por agentes externos a la red o debido al uso inadecuado de los recursos. En el proyecto se describen los ataques y errores más frecuentes que pueden llegar a comprometer la seguridad de una red de computadores. Finalmente, el alcance real y tangible del presente proyecto es el siguiente: - Captura de datos y entrenamiento de distintos tipos de redes neuronales. - Análisis e implantación de una de ellas. - Desarrollo de sensores sensibles a cada tipo de dato elegido en la captura. - Desarrollo de un sistema que avise al administrador de la red de la salida que produzcan los sensores mencionados.

8 8 3. ESTADO DEL ARTE Hoy en día son conocidos los constantes ataques que sufren los servidores y redes de computadores de las compañías más importantes del mundo. El robo y/o manipulación de la información almacenada en un servidor corporativo puede provocar graves pérdidas a una empresa y grandes beneficios a quien se lucre de ello. Qué ventaja de negocio supondría para una organización ver los equipos informáticos de sus competidoras completamente colapsados e inservibles durante horas?, qué precio tiene la confidencialidad de las comunicaciones de una importante compañía? Lo que comúnmente conocemos como ataques informáticos supone una gran preocupación para los administradores de red de cualquier organización que disponga de nuevas tecnologías de la información. Actualmente la comunicación entre computadores ha cobrado una importancia vital en el mundo de la informática y el volumen de redes conectadas entre sí a lo largo del mundo supera cualquier expectativa inicial. El valor de los datos corporativos que una empresa mueve a lo largo de sus canales de información es incalculable y por ello las compañías invierten gran cantidad de recursos económicos y humanos en preservar su seguridad. En los siguientes apartados se hará referencia a diversos temas de seguridad informática: Sistemas de Detección de Intrusos y seguridad perimetral, vulnerabilidades de los sistemas informáticos y tipos de ataques que una entidad maliciosa puede perpetrar contra ellos. Más adelante se hará una introducción a los modelos distribuidos que hoy en día se implantan en las aplicaciones multiplataforma y en particular el modelo JADE multiagente inteligente. Para terminar se comentarán los IDS basados en detección de anomalías SISTEMAS DE DETECCIÓN DE INTRUSOS Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es un hardware, software o combinación de ambos que monitoriza la red de un sistema informático en busca de actividad maliciosa [KOZI03]. Un IDS dispara alarmas a tener en cuenta por el administrador de la red advirtiendo la presencia de actividad intrusa, inusual, no autorizada o potencialmente dañina en el momento en que se está produciendo, lo que permite percatarse de una situación en la que la seguridad aparente de la red no es tal. Hay que destacar que un IDS se limita a notificar de situaciones anómalas y/o peligrosas en la

9 9 red, y por tanto no interviene activamente en su prevención (lo que deberá llevar a cabo el supervisor de la red aplicando las medidas correspondientes). Existen gran cantidad de productos IDS, ajustables a las necesidades especificas de cualquier infraestructura, ya sea a nivel de rendimiento (más rápido, con capacidades de gestión centralizada, etc.) o a nivel de configuración y mantenimiento (mas o menos configurable, más o menos simple de usar, etc.). Entre el software de libre distribución podemos encontrar múltiples herramientas de este tipo, herramientas que presumen de ser fiables y frecuentemente actualizables dada la masiva colaboración de la comunidad de usuarios que libremente aportan su conocimiento a la causa. Constantemente hay gente programando nuevos plugins y funcionalidades a estas aplicaciones que son supervisadas por un organismo dedicado para garantizar su calidad. Existen numerosos desarrollos comerciales de IDS. La imagen de confianza que aporta una marca conocida en aplicaciones de seguridad informática hace que muchos usuarios se decanten por estos productos. En este proyecto no se han investigado herramientas IDS comerciales debido a la orientación de este proyecto hacia el software libre.

10 SEGURIDAD PERIMETRAL La teoría de la seguridad perimetral trata de solucionar el problema de la seguridad de las redes corporativas. Esta teoría propone la disposición estratégica de los equipos en subredes debidamente protegidas de accesos externos no autorizados mediante cortafuegos. Un cortafuegos es un dispositivo que filtra las comunicaciones que entran y salen de una subred, cerrando todos los puertos innecesarios y bloqueando por tanto los servicios no autorizados. Sin duda es una herramienta fundamental para el control del tráfico en una red de computadores, pero no es suficiente para garantizar la seguridad del sistema. Un cortafuegos representa una puerta que prohíbe el paso a todas aquellas comunicaciones no permitidas, pero que deja pasar aquellas necesarias para el usuario al otro lado del dispositivo. Aunque sólo se permitan los servicios básicos y teóricamente seguros, existen debilidades y agujeros de seguridad ante los que un cortafuegos no puede hacer nada, ya que es incapaz de evitar que un atacante utilice un servicio autorizado para perpetrar una acción maliciosa. Si la seguridad que proporciona un cortafuegos se ve comprometida es necesario disponer de algún sistema que permita al administrador de red ser capaz de detectar esta situación. El IDS y el cortafuegos son por tanto herramientas complementarias. Sin un sistema que advierta de la presencia de una actividad sospechosa y no autorizada que se haya saltado el filtro del cortafuegos, un administrador podría creer que su red está bien protegida cuando realmente no es así. Las alarmas del IDS permiten configurar el cortafuegos que complementa de una manera más eficiente y tomar acciones reactivas eficaces en una situación en que se haya producido un daño en la red. Otra situación que alarmantemente es de las más frecuentes en temas de seguridad informática es el ataque desde dentro de la red, por parte de los propios usuarios autorizados, bien por ignorancia o por malicia, ponen en peligro los recursos de la empresa (según algunos estudios alrededor de un 80% del total de ataques proceden del interior, [DIAZ05]). Frente a estas circunstancias, un cortafuegos que controle el tráfico hacia fuera de la red es inútil, por lo que el único recurso en el que confiar es el IDS que alerte de esta situación de modo que un supervisor pueda tomar medidas internas en la compañía.

11 11 Un IDS no impide la consecución de un ataque, pero permite alertar de su presencia. Las capacidades de un IDS permiten realizar múltiples actividades relacionadas con la seguridad informática como son las siguientes [DIAZ05]: Monitorización y análisis de las actividades de los usuarios. Como se ha descrito anteriormente, una gran proporción de los ataques informáticos son perpetrados por parte de los propios usuarios autorizados de la red. Un control de sus actividades (respetando la intimidad de las personas) permite saber los servicios que utilizan y el uso que hacen de ellos. Auditoría de configuraciones y vulnerabilidades de sistemas. La detección de tráfico permite descubrir sistemas con servicios habilitados innecesarios o no autorizados, que de otra manera pasarían inadvertidos. El descubrimiento de una vulnerabilidad del sistema permite tomar medidas al respecto, eliminándola o si no es posible, poniendo especial atención en ella. Asegurar la integridad de los sistemas críticos. El análisis de tráfico permite saber si un determinado sistema ha sido atacado (o está en riesgo de ser atacado). De esta forma podemos estar seguros (en la medida de las posibilidades del IDS) de que los sistemas están libres de ataques, ya que nunca se puede garantizar al 100% la eficacia del cortafuegos. Análisis estadístico de ataques. Dado que la comparación de ataques contra una base de datos es algo limitada, existen herramientas heurísticas de búsqueda de patrones de ataques (como hacen los sistemas antivirus con el código malicioso). Sistemas basados en redes neuronales y demás métodos de inteligencia artificial se aplican cada vez con más frecuencia para este tipo de fines. Análisis de tráfico anormal. El tráfico autorizado que podemos considerar normal en nuestras funciones de negocio, puede dejar de serlo en determinadas circunstancias (conexiones fuera de las horas de trabajo, tráfico en segmentos de backup en estado de normalidad, accesos frecuentes a equipos de uso excepcional...). Un análisis detallado del tráfico puede revelar una maquina comprometida o la situación de un usuario con su clave al descubierto. Precisamente en este punto es en el que se centra el presente proyecto IDSRN. Auditorías del entorno. Un IDS tras un cortafuegos es una excelente herramienta para determinar qué tipos de ataques pasan a través del cortafuegos (y así comprobar su funcionamiento) y cuáles de ellos tienen éxito (y así comprobar la eficacia de los elementos menores de seguridad: cortafuegos de host y Antivirus).

12 12 Las ventajas del uso de IDS junto a un cortafuegos adecuadamente configurados son claras, y se ha hecho hincapié en ellas. Pero los IDS tienen también grandes desventajas, que se deben tener en cuenta para no confiar excesivamente en ellos: Un IDS no puede hacer nada frente a ataques nuevos y que por tanto es incapaz de reconocer como tales. La actualización de la base de reglas de reconocimiento de patrones de un IDS es una importante actividad rutinaria de su mantenimiento. Un IDS no puede detectar ataques en comunicaciones cifradas extremo-extremo, ya que es incapaz de reconocer patrones en un contenido ilegible. Un IDS no puede compensar mecanismos de autenticación débiles. Si es sencillo obtener usuarios y claves legales y acceder con ellos al sistema, el IDS será incapaz de alertar del acceso no autorizado. Un IDS no puede automatizar la investigación de los incidentes. Es necesaria la intervención humana (de un analista cualificado) para descubrir la naturaleza real del ataque, limpiar sus efectos, descubrir al atacante y protegerse para el futuro. Un IDS mal configurado puede dar lugar a errores y confusiones típicas de este tipo de sistemas [KOZI03]: o Falsos positivos: Alertas disparadas en condiciones normales. Este tipo de situación es indeseable, debido a que hace que el administrador de red se alarme innecesariamente y termine por ignorar alertas reales pensando que se trata de este tipo de errores. Esta situación se da en IDS configurados con excesivo nivel de detalle y propensos a alertar de la más mínima variación respecto a la normalidad. o Falsos negativos: Ausencia de alertas en condiciones de ataque y tráfico no autorizado. Este tipo de error es peor que el anterior, ya que el IDS no realiza su función de avisar de la situación, lo que implica que el ataque pase desapercibido y por tanto, no se tomen medidas adecuadas y eficaces a tiempo de evitar males mayores. Esta situación se da en IDS no actualizados o configurados con bajo nivel de detalle y propensos a alertar solamente situaciones muy claras, que los hackers más experimentados suelen saber evitar. El párrafo anterior deja constancia de lo importante que es la adecuada configuración de un IDS, cosa que no es trivial y requiere de un gran

13 13 conocimiento al respecto y experiencia en el campo de la seguridad informática. Puesto que no está al alcance de cualquiera, se recomienda no confiar en un sistema de este tipo si no se puede garantizar su correcto funcionamiento. El software de un IDS es muy pesado. Hacer pasar todo el tráfico de red por un juego de reglas de inferencia, por una función matemática o por una red neuronal para disparar una alerta por cada captura sospechosa requiere de una gran capacidad de procesamiento por parte del hardware de soporte para que no se pierda ningún paquete. Instalar un sistema IDS en un punto de paso del tráfico de red (por ejemplo en un router o en un cortafuegos) es la mejor manera para garantizar que no se deja de analizar ningún paquete de red. En la práctica se desaconseja colocar un IDS en un lugar propenso a convertirse en cuello de botella debido a que analizar en detalle cada uno de los paquetes antes de dejarlos pasar introduce un retardo indeseable en cualquier red de computadores. En futuros capítulos se abordara la cuestión de cómo y dónde colocar sistemas IDS en redes de diferentes tipos.

14 CLASIFICACIÓN DE IDS [KOZI03]: Existen tres tipos básicos de IDS según el fin para el cual están diseñados Network Intrusion Detection System (NIDS): Son instalados en un segmento de red en concreto, del cual pueden absorber todo el tráfico (escuchan en modo promiscuo) y analizarlo en tiempo real para disparar las alertas correspondientes. Cuanto más transparente sea su funcionamiento y menos interfiera en el tráfico de red, mejor. Network Node Intrusion Detection System (NNIDS): Son instalados en un host en concreto, analizando todo el tráfico destinado a dicho equipo. Se suelen utilizar sobre equipos críticos de la compañía propensos a ser objetivo de ataques o en un HoneyPot (host débilmente protegido que sirve de trampa para hackers desviando su atención de los equipos más importantes). Host Intrusion Detection System (HIDS): Son instalados en un host en concreto y permiten tomar una instantánea del sistema, para comprobar más adelante la integridad de la maquina. La diferencia con los NNIDS es que no tienen en cuenta las comunicaciones, sino que buscan rastros de un ataque en el propio equipo. Permiten saber si un ataque ha tenido éxito y cuáles han sido las consecuencias a posteriori. Los IDS también se pueden clasificar en las siguientes categorías según su forma de detectar las intrusiones: Búsqueda de patrones (Signature detection): Los IDS de este tipo disponen de una base de datos que contiene patrones o firmas de ataques conocidos, y cada paquete que se analiza se contrasta con esa base de conocimiento. Cuanto mayor sea la lista de firmas conocidas, mas tipos de ataques se podrán detectar, pero más costoso computacionalmente será para cada paquete, pudiéndose perder alguno si el ritmo de análisis no soporta el del flujo de información. Análisis de tráfico (Anomaly detection): Los IDS de este tipo están configurados para conocer la situación "normal" de la red. Recolectan todo el tráfico y crean estadísticas en tiempo real del estado de la red. Si en un momento determinado, la

15 15 estadística se sale de la normalidad, se genera la alerta para que el analista lo investigue. Verificación de integridad: Es el sistema que utilizan los HIDS. Se comprueban determinados aspectos de un equipo (checksum de ficheros críticos, registro del sistema, logs...). Permite saber a posteriori, que tipos de ataques se han perpetrado en un sistema y los daños que han producido IMPLANTACIÓN DE IDS Hasta aquí se ha pretendido dar una visión general de los IDS: sus funcionalidades, utilidad, ventajas e inconvenientes. Un IDS es un dispositivo que complementa las medidas de seguridad de la red, muy útil para tomar medidas concretas frente a una situación de crisis, e incluso para poder preverla. Este punto hace hincapié en la dificultad que conlleva el uso de este tipo de dispositivos, desde la necesidad de conocimientos avanzados de seguridad para configurarlos correctamente y saber interpretar sus alertas hasta la experiencia necesaria en seguridad perimetral para saber ubicarlos en la red de forma que den un resultado eficaz. La implantación de un IDS requiere una serie de pasos a seguir para hacerlo de forma eficiente: 1. Identificación de necesidades: Se debe determinar la importancia de la información. Cuantificar en términos económicos y subjetivos (confianza pública en la compañía, respeto por parte de otras empresas...) las perdidas en que se incurriría si los datos se perdieran y/o fueran robados. Esta cuantificación permitirá valorar si resulta rentable implantar el sistema o no y determinar la probabilidad de sufrir un ataque por parte de un hacker interesado en obtener beneficio. Si la red ya ha estado bajo ataque anteriormente, se conocen sus vulnerabilidades y ha mostrado signos de debilidad es probable que pueda volver a sufrir un ataque. Determinar el nivel de seguridad a implantar en la red es necesario para establecer un plan de seguridad concreto. 2. Obtener conocimientos sobre la detección de intrusos: Es necesario tener unas nociones básicas de lo que puede hacer un IDS y para qué sirve, o de lo contrario

16 16 se tendría una falsa ilusión de seguridad. El conocimiento sobre ataques informáticos y sobre el estado del arte en temas de seguridad es fundamental para poder interpretar adecuadamente los resultados del IDS. 3. Obtener conocimientos sobre la infraestructura de red: Una red debidamente estructurada en diferentes segmentos protegidos con cortafuegos es más segura que una mal administrada. La distribución de sensores en las diferentes subredes dará lugar a una variedad más rica y precisa de análisis. 4. Escoger el IDS más adecuado: Se debe elegir el sistema IDS que mejor se ajuste a las necesidades de protección de la red, condicionado su complejidad al nivel de conocimiento por parte del administrador/analista. Evaluar varios IDS simulando baterías de ataques en un entorno de pruebas similar a la red sobre la que implantar definitivamente el producto requiere trabajo y una gran pericia, pero es el mejor método para decantarse por un IDS en particular. 5. Especificar una política de seguridad: Es fundamental contar con un protocolo de actuación concreto frente a una situación de alerta por parte del IDS, ya que de nada sirve ser capaz de detectar ataques si luego no se sabe qué hacer en respuesta. Debe contarse con una documentación completa sobre lo que hacer en cada situación, de forma que no surjan dudas sobre el plan de acción. Esta documentación es específica de cada organización y no es trivial realizarla, por lo que debe ser creada por expertos en seguridad y planes de emergencia. El administrador de red encargado de seguir esta política también deberá tener conocimientos avanzados de este tipo para poder intervenir rápida y eficazmente sin dudar en ninguna situación. La implantación física del IDS en la red es muy importante. De ella dependerán las características que deberá tener y el rendimiento que se puede esperar. En la figura 1 se muestra un ejemplo tipo de red bien estructurada destacando los lugares estratégicos más comunes donde disponer de sistemas IDS [DIAZ05]:

17 17 Aunque dependiendo del entorno se pueden encontrar otras ubicaciones posibles, los puntos más típicos donde colocar un IDS (puntos rojos en la imagen) son: 1. Entre la Extranet e Internet: Para controlar el tráfico que sale/entra de la red externa de la compañía es imprescindible contar con un sensor IDS en el enlace VPN por el que se accede a través de Internet a la red corporativa. 2. En la DMZ: La zona desmilitarizada es el segmento de red entre el cortafuegos de la red corporativa e Internet. En él se suelen ubicar los servidores de acceso público que no albergan información importante y no requieren unas medidas de protección y seguridad exhaustivas (servidores web, por ejemplo). Por esta razón suelen ser objetivo de una primera aproximación a la red por parte de hackers y por tanto su vigilancia debería considerarse en todo momento. 3. Tras el cortafuegos: Esta suele ser la ubicación característica de un IDS, puesto que permite analizar todo el tráfico que entra en la red (ya filtrado por el cortafuegos). De la misma forma, permite comprobar que el cortafuegos funciona incorrectamente, si este ha dejado pasar tráfico no autorizado. Para comprobar el buen funcionamiento del cortafuegos es muy interesante comparar los resultados de este IDS con los que aporta el sensor ubicado en la DMZ. 4. En el acceso a servidores: La información estratégica del negocio se encuentra almacenada en los servidores de la empresa. La vigilancia en este punto es algo fundamental. 5. En el acceso a usuarios: Este sensor sirve para detectar ataques a maquinas de usuario, que pueden almacenar información de negocio y suelen tener acceso

18 18 privilegiado a los servidores de la compañía. Los ataques que se inicien en el interior de la organización también se detectaran más rápidamente si consideramos la instalación de este IDS. Como se puede ver, disponer de varios sensores IDS en distintos lugares estratégicos de la red es fundamental para completar el sistema de capas de seguridad que componen las subredes y cortafuegos de la empresa. Tomar decisiones en respuesta a alertas generadas por IDS concretos será mas rápido y eficaz que hacerlo si solo contamos con un sensor para toda la red. Además cada IDS se puede configurar en detalle según el tipo de tráfico de su segmento de red en particular, para así reducir el tamaño de su base de reglas y evitar la búsqueda de patrones superfluos. En entornos con múltiples IDS es muy útil tener centralizada la gestión. De esta forma se pueden recoger los registros y las alarmas en un único lugar. Esto facilitara el trabajo del personal de seguridad que según hemos explicado es indispensable que este tras la maquina interpretando los resultados e interviniendo en caso de ataque. Los logs deben ser revisados diariamente y la actualización del IDS debe ser constante, añadiendo las nuevas firmas conocidas. Además, el personal de seguridad es responsable de mantener los sistemas de recuperación ante emergencias. Por todo lo que se ha comentado hasta el momento, parece obvio que un IDS, más que cualquier otro producto de seguridad, necesita ser optimizado. Su uso de ancho de banda es intensivo y las operaciones que tiene que realizar son muy complejas, consumiendo gran cantidad de recursos computacionales. El resultado predecible de un IDS no optimizado es una pérdida potencial de paquetes y por tanto una pérdida potencial de ataques o incluso un elevado número de falsos positivos (si al perder paquetes, el IDS detecta discontinuidades en las secuencias TCP). En una situación de congestión de red debido a una inundación masiva de paquetes, el IDS empezará a fallar, por eso es importante que la carga de CPU en un IDS sea generalmente baja, para poder estar disponible en situaciones de emergencia. Las acciones que un administrador de red puede llevar a cabo para ajustar un IDS son [DIAZ05]: Optimizar la base de datos de firmas: En general, la configuración por defecto de los IDS busca todos los ataques conocidos posibles. Debido a las características de la red, muchos de ellos aunque se produjesen no tendrían efecto. Es importante

19 19 conocer bien la red que se pretende administrar para no perder tiempo de CPU chequeando firmas de ataques que nunca tendrían éxito en nuestra configuración. Ejemplos: Ataques de tipo RPC en entornos totalmente Microsoft o análisis de exploits de sistemas FTP en redes sin este tipo de servicio. Filtrar tráfico no deseado: Por defecto, el IDS analiza todo el tráfico que es capaz de capturar en su segmento de red. Como se ha explicado anteriormente, un IDS es incapaz de identificar firmas en tráfico cifrado, por lo que el sensor se puede configurar para que ignore el tráfico de este tipo, por ejemplo el SSH. Balanceo de carga: Al ser un IDS un dispositivo computacionalmente pesado, si el volumen de tráfico a analizar es muy importante (porque esté situado en una zona crítica como detrás del cortafuegos), es recomendable la instalación de varios sensores balanceados por tipo de tráfico. Reduciendo el número de reglas que se comparan en cada sensor se obtiene un mejor rendimiento por cada uno, pero hay que cuidarse de no dejar reglas relevantes sin supervisar. Optimización de la configuración: Además del juego de reglas, cada IDS tiene varias opciones de configuración que influyen en su rendimiento. Es muy importante adaptar cada sensor a la situación más adecuada ATAQUES INFORMÁTICOS E INTRUSIÓN EN REDES En los siguientes puntos se presentan unas breves reseñas sobre ataques informáticos e intrusión en redes que ayudarán a comprender mejor a qué se enfrentan los administradores de red y los motivos de la instalación de Sistemas de Detección de Intrusos FASES DE UN ATAQUE La intrusión de redes y los ataques a recursos críticos de una compañía por parte de hackers y usuarios con malas intenciones es algo que los administradores de red tienen muy presente y tratan de prevenir dentro de sus posibilidades. Los Sistemas de Detección de Intrusos y los procedimientos de registro de incidencias han evolucionado de forma paralela a la pericia de los hackers.

20 20 La estrategia de un hacker que pretende realizar un ataque preciso a una red de computadores es impredecible. Si un atacante siguiera un protocolo de acción concreto, sería muy sencillo prever sus ataques. No obstante la intervención de un hacker suele diferenciarse en 4 fases, que deben conocerse en detalle [KOZI03]: PLANTEAMIENTO Los buenos hackers generalmente se detienen a planear en detalle sus ataques antes de realizar ninguna acción sospechosa. Un hacker inteligente tratará de buscar por medios indirectos (los medios directos los aplicará en la fase de reconocimiento) información sobre la estructura de la red que pretende atacar y sobre sus vulnerabilidades (agujeros en aplicaciones de negocio, equipos desprotegidos...). Esta información se puede obtener de múltiples maneras: por medio de los propios empleados de la empresa, accediendo a documentación que descuidadamente publican los administradores del sistema, etc. En esta fase, si el hacker no tiene un objetivo concreto, lo determinará. La motivación y la información de la que parta el atacante le hará decantarse por uno o más ataques de entre los siguientes tipos: Negación de servicio (DoS, Denial of Service): Este tipo de ataque consiste en inutilizar un recurso del sistema, de forma que no pueda realizar su trabajo. La negación de servicio de una aplicación ubicada en un servidor consiste generalmente en el envío masivo de peticiones remotas con el objetivo de colapsar la aplicación de forma que no pueda atender a las peticiones ordinarias de los usuarios. Cualquier procedimiento que implique una reducción de los recursos computacionales del servidor de forma que no pueda atender adecuadamente las peticiones también puede considerarse una negación de servicio (por ejemplo un troyano pesado que agote la memoria de la máquina). Una negación de servicio puede extenderse a varios equipos si se consigue inundar de tráfico anormal un segmento de red entero. Un

21 21 ataque de este tipo bien planeado, puede inutilizar una red entera forzando a resetear cada una de las máquinas si se realiza con éxito. Escalada de privilegios: Este tipo de ataque consiste en obtener los permisos legítimos necesarios para acceder a un determinado recurso del sistema. De esta manera, un hacker puede acceder a cualquier recurso del sistema como si de un usuario autorizado se tratara. En la práctica, la escalada de privilegios consiste en obtener un usuario y contraseña válidos para el acceso al recurso deseado. Esto es relativamente sencillo en métodos de autenticación débiles (transmisión de contraseñas sin cifrar, passwords de diccionario...) si se consigue capturar el tráfico de un segmento de red. Instalar un troyano de tipo keylogger (registro de teclas) puede ser un sencillo método para obtener passwords de usuario si no se dispone de un antivirus que lo detecte. De hecho, cualquier troyano tiene como objetivo la escalada de privilegios, ya que al ser instalado en una sesión de usuario autorizado permite el acceso con esos permisos al atacante remoto. Un administrador de red de cuidado que publique cuentas de usuario raíz y no realice una gestión adecuada de contraseñas, actualizándolas frecuentemente, puede encontrarse con serios problemas de escalada de privilegios por parte de usuarios no autorizados. El acceso a un recurso utilizando una autenticación válida aunque el usuario no haya sido autorizado a ello es un hecho ante el que un IDS es inútil al no poderlo identificar como un ataque. Acceso no autorizado: Este tipo de ataque consiste en el acceso a un determinado recurso del sistema aprovechando las vulnerabilidades del hardware de soporte y del software que lo gestiona y en particular de sus agujeros de seguridad y errores de programación. Los métodos que explotan estas vulnerabilidades son comúnmente llamados exploits y son bien conocidos en general por comunidades de hackers y publicados abiertamente en páginas web y foros. Primeramente se debe saber de qué versión del software se trata, pero esto no es trivial y el atacante debe llevar a cabo una labor de investigación si no lo conoce de antemano. Más adelante, en la fase de reconocimiento, podrá poner en práctica métodos directos de obtención de esta información, aunque sean típicamente detectables por sistemas IDS. Un sistema operativo desactualizado al que no se le han instalado los parches de seguridad recomendados es una

22 22 fuente enorme de vulnerabilidades conocidas por la mayoría de hackers (y publicadas en Internet) y lo mismo ocurre con software de servicio remoto de uso común (servicios FTP, de páginas web, etc.). Según el tipo de ataque que se realice se atentará contra la propiedad de seguridad que se desee violar del recurso. Un ataque de tipo negación de servicio atenta exclusivamente contra la disponibilidad del recurso. Un ataque de los otros dos tipos permite el acceso a la información al hacker y por tanto viola la integridad de esos datos, ya que tras la intrusión no se puede garantizar la validez ni la fiabilidad ni la confidencialidad de la información manipulada RECONOCIMIENTO En esta fase, el atacante lleva a cabo acciones directas para la obtención de información sobre la red y soporte hardware y software de los datos a los que desea acceder para llevar a cabo un ataque de tipo acceso no autorizado. Este tipo de acciones son en general identificables por IDS, debido a que al no tratarse de accesos ordinarios al servicio, contienen particularidades que determinan patrones bien conocidos. Después de que un atacante haya recopilado información pública sobre la organización objetivo, tratará de descubrir vulnerabilidades concretas a explotar. Existen una gran variedad de técnicas de reconocimiento para obtener información detallada de este tipo. La primera acción que tendrá que llevar a cabo el atacante es comprobar si la víctima del ataque está arrancada en el instante actual, lo que llevará a cabo haciendo ping a la dirección víctima en concreto. Si el administrador de la red es cuidadoso habrá configurado los hosts del sistema para que no respondan a las peticiones de eco ICMP. En ese caso, una conexión TCP o un intento de comunicación UDP serán suficientes para comprobar si la dirección IP víctima está activa.

23 23 En el momento en que se está seguro de que la máquina objetivo está viva el atacante debe buscar puertos abiertos con la intención de saber qué aplicaciones se están corriendo en el equipo y sus versiones, de forma que pueda explotar sus vulnerabilidades. Esto se lleva a cabo a través de un escaneo de puertos, tipo de ataque de reconocimiento que se torna inevitable si se pretende saber para qué se utiliza realmente una máquina y que es fácilmente detectable por un IDS. Hosts seguros suelen estar configurados para no responder a intentos de conexión sospechosa y sus servicios corren en puertos no standard. Esto supondrá un esfuerzo extra al atacante a la hora de averiguar qué servicio está corriendo en un puerto en particular con lo que tendrá que arriesgarse a comunicarse con la aplicación (mediante Telnet, por ejemplo) para averiguar su verdadera naturaleza, mostrando abiertamente sus intenciones, lo que no pasará desapercibido al administrador de red. Muchos exploits remotos están dedicados a determinados sistemas operativos. El reconocimiento del sistema operativo que corre en una máquina se realiza mediante la respuesta que este da a un determinado estímulo (en general, paquetes de red no válidos a los que cada versión de sistema operativo reacciona de forma diferente, lo que se conoce como fingerprint). Se verán más detalles y ejemplos de ataques de estos tipos en el apartado 3.2.2: Ataques conocidos ATAQUE Tras la planificación del ataque y el reconocimiento de la víctima, el siguiente paso es hacer uso de la información obtenida para atacar el sistema objetivo. Según la naturaleza del ataque que se desea realizar y las vulnerabilidades del sistema escogido como víctima se llevarán a cabo las acciones que el hacker considere más apropiadas y menos llamativas en pos de impedir ser detectado por un IDS.

24 24 Esta fase es muy delicada por esta razón, y es muy frecuente en hackers experimentados el servirse de triquiñuelas que impidan al encargado de seguridad la localización del origen del ataque. El primer paso en estas operaciones suele ser la negación de servicio del sistema IDS que pueda dar la alarma del ataque, bien tratando de ocultar el ataque entre otros más descarados a otras máquinas en paralelo o inundando el segmento de red del IDS con tráfico anómalo para generar una respuesta confusa por su parte. Es deseable a su vez para el atacante, el realizar el ataque desde varios hosts zombies (es decir, controlados de forma remota de forma transparente a su usuario autorizado) a la vez, lo que generalmente se consigue mediante la instalación de virus troyanos en las máquinas controladas. Un ataque distribuido bien coordinado, es más eficaz que uno perpetrado desde una sola máquina y permite a la vez que la pista del atacante se pierda entre equipos irrelacionables con su persona. En la presentación de los tipos de ataques a realizar en la fase de planificación ya se hizo una breve introducción a ejemplos de ataque que no se repetirán en este punto, pero que se desarrollarán en detalle en el apartado 3.2.2: Ataques conocidos POST-ATAQUE Después de que el atacante haya penetrado satisfactoriamente en un host de una red, las acciones que lleve a cabo pueden ser de lo más variopinto. En esta fase el atacante demostrará su verdadera motivación y pericia, llevando a cabo una o mas de las siguientes acciones: Borrar huellas: Es una buena práctica de hackers experimentados el borrar todos los indicios de su presencia en la red objetivo. Eliminar ficheros de log o registros del sistema en los que haya quedado constancia de la presencia y acción de una entidad no autorizada, confirmará al administrador de red o al sistema HIDS la situación del ataque, pero no podrán investigarlo. Existen scripts que automatizan este procedimiento

25 25 para ocultar la actividad maliciosa tanto procedente del exterior (por la vía de las comunicaciones) como del interior (virus y troyanos). Estas aplicaciones que se denominan rootkits son una herramienta fundamental para los hackers. Profundizar en la infraestructura de red: La información importante para una compañía raramente es accesible desde hosts con acceso al exterior. Los servidores de negocio suelen ubicarse en subredes internas protegidas por cortafuegos configurados al efecto por lo que es muy complicado ejecutar un ataque directo desde el exterior hasta ese nivel de seguridad pasando por varios filtros de cortafuegos. El control remoto de varias máquinas en la capa menos segura de la red, suele ser la única manera de ejecutar ataques distribuidos de forma remota sobre equipos más protegidos de la red. Una escalada de privilegios en varias fases es tediosa y supone el riesgo de ser detectado en una de las etapas, pero es la forma más segura de tener éxito en el ataque. Robar, manipular o destruir datos: El acceso a la información de la empresa es el móvil básico de un hacker, que le sacará el máximo beneficio a la misma. Un cracker no se conformará sólo con la lectura y modificación de la información a su parecer, sino que además la destruirá haciendo perder a la empresa víctima tiempo y dinero. Notificar al administrador y abandonar: No todos los hackers pretenden lucrarse con sus actividades. Muchos de ellos practican lo que se denomina hacking ético, afición que consiste en perpetrar ataques a una red, con el único fin de demostrar sus habilidades sin la intención de causar ningún daño. Los hackers éticos suelen ponerse en contacto con el administrador de la red atacada disculpándose por su acción y detallándole las vulnerabilidades de su sistema por lo que aunque la acción realizada es ilegal, no suelen ser denunciados.

26 ATAQUES CONOCIDOS En este apartado se presentará un breve compendio de ataques conocidos, muchos de ellos con nombre propio, que son interesantes de conocer para percatarse mejor del alcance y limitaciones de la intrusión en redes ATAQUES DE RECONOCIMIENTO Estos ataques se dan en la fase de reconocimiento de un ataque (ver apartado : Reconocimiento) y su objetivo es la detección de equipos vivos en la red y de los servicios que se corren en ellos en cada uno de sus puertos [KOZI03]. Como anteriormente se ha dicho, el primer movimiento que hace un atacante para averiguar si un host está activo o no es ejecutar un comando ICMP Ping (ECHO Request) contra la dirección IP objetivo. La máquina contestará al origen con un mensaje ICMP ECHO Reply si está encendida y no lo hará en caso contrario. También se ha comentado anteriormente otra manera de detectar un host vivo: establecer una conexión TCP con él. Según el protocolo TCP, un host activo contesta a un paquete TCP connect con un paquete ACK.

27 27 El escaneo de puertos es la forma directa de reconocimiento de las aplicaciones que corren en una máquina. Si en un equipo remoto el puerto estándar de una determinada aplicación está abierto significa que hay un servicio escuchando por él y que se corresponde con una determinada aplicación. Si el escaneo del puerto estándar de una aplicación conocida resulta satisfactorio en una máquina se puede asegurar que en dicho servidor está corriendo ese programa. Un escaneo TCP se realiza mediante una conexión TCP al equipo objetivo por el puerto deseado. Dependiendo del tipo de mensaje de contestación se puede determinar si el puerto está abierto o cerrado y por tanto si su aplicación asociada está corriendo en el sistema y se puede establecer comunicación con ella o no. De una manera parecida, se puede realizar un escaneo UDP. La comprobación de que una aplicación está a la escucha de un puerto UDP se realiza mediante el envío de un paquete UDP. Al ser el protocolo UDP un protocolo de red sin conexión, no se tiene por qué esperar una respuesta al

28 28 mismo, de hecho, si no se recibe respuesta, es debido a que el puerto al que se ha enviado el mensaje está abierto, mientras que si se recibe un paquete ICMP Port Unreachable no será así. Si se desean explotar las vulnerabilidades del sistema operativo, se recomienda conocer la versión del mismo, para saber con qué parches cuenta y cuándo fue la última actualización de seguridad. Como se describió en el apartado : Reconocimiento, la forma de identificar la versión del sistema operativo de una máquina objetivo es analizando su fingerprint. El ejemplo típico de ataque de reconocimiento de sistema operativo es el ataque FIN. El envío de un paquete de cierre de una conexión TCP no abierta es una situación anómala frente a la cual, cada versión de sistema operativo suele dar una respuesta diferente. Conociendo las posibles respuestas se puede deducir con relativa exactitud el sistema operativo de la victima y su versión.

29 29 El escaneo de muchos puertos consecutivos con la intención de dar con alguno por el que comunicarse con una máquina objetivo (horizontal scan) consiste en iterar los escaneos anteriormente descritos para encontrar un puerto abierto en la víctima. El proceso contrario, el escaneo de un puerto concreto en varias víctimas (vertical scan) consiste en ir probando la existencia del puerto objetivo en múltiples máquinas en busca de una potencial víctima de un exploit conocido. Existen herramientas y scripts que automatizan estos procesos, pero no dejan de generar un tráfico anormal y tremendamente sospechoso que no se le suele escapar a ningún IDS. A medida que los Sistemas de Detección de Intrusos han incorporado más tipos de patrones de escaneos de puertos, los hackers han ido a su vez descubriendo nuevos métodos para evitar ser detectados. Un ejemplo es el ataque Xmas scan. Un paquete TCP enviado a una víctima con todos los flags TCP/IP activados no se corresponde con ninguna configuración válida de este protocolo y por tanto la máquina destinataria devuelve una respuesta característica, es decir un fingerprint. Cuando se descubrió este agujero del protocolo TCP/IP, este escaneo pasó desapercibido para todos los IDS hasta que tiempo más tarde se les añadió su firma. Un IDS detecta un escaneo de puertos cuando en un breve espacio de tiempo registra múltiples intentos de conexión a puertos o hosts consecutivos desde una misma IP. Una forma de solucionar esto es ser paciente y realizar el escaneo lentamente, durante horas o días para no sobrepasar el umbral de tiempo que marca el IDS por defecto. Otra manera de evitar que el atacante sea identificado como el origen de un escaneo es realizarlo de forma distribuida, desde múltiples orígenes, cosa que no es difícil si el hacker se ha hecho con el control de varias máquinas de la red ATAQUES DE NEGACIÓN DE SERVICIO (DoS) Se denomina ataque de negación de servicio (Denial of Service, DoS) a cualquier ataque que afecte al funcionamiento de un sistema de forma que no puede dar servicio normal a sus usuarios legítimos. Los ataques de

30 30 negación de servicio pueden darse sobre la mayoría del equipamiento de red, incluidos routers, servidores, cortafuegos, máquinas de acceso remoto e incluso el propio medio. Un ataque de negación de servicio puede tener como objetivo una aplicación específica (como la negación de un servicio FTP) o una máquina entera (colapsando sus comunicaciones o consumiéndole todos sus recursos). Los ataques de negación de servicio tienen diversas naturalezas, pero en general se pueden separar en dos categorías: Ataques de paquetes maliciosos (malicious packet attacks) o Ataques de agotamiento de recursos (resource depletion) [NORT01]. Ataques de paquetes maliciosos: Consisten en el envío de tráfico anormal de forma masiva hacia un host para provocar un fallo en el propio equipo o en un servicio concreto ejecutándose en el mismo. Este tipo de ataques se aprovechan de que tanto el software de aplicación como el de los sistemas operativos no está diseñado para esperar situaciones extraordinarias, por lo que el sistema se no sabe como reaccionar y colapsa. Para llevar a cabo con éxito un ataque de este tipo, el atacante debe tener un conocimiento exhaustivo sobre el servicio que pretende atacar, casi a nivel de programador. Un ejemplo de ataque de este tipo fue el Microsoft FTP DoS. En las primeras versiones del servidor FTP de Microsoft, se incluía la búsqueda de ficheros con caracteres comodín (* y?). Esta funcionalidad daba buenos resultados en búsquedas con uno o dos símbolos de este tipo, pero el sistema fallaba (por una cuestión de reserva insuficiente de memoria) cuando el comando de búsqueda incluía múltiples caracteres comodín intercalados (por ejemplo, *a*?*??*). La aplicación FTP se quedaba colgada y se producía la negación del servicio. La negación de servicio del sistema IDS instalado en la red es una de las acciones que los hackers suelen llevar a cabo para evitar que éste dispare las alarmas que generan sus ataques. Ataques de agotamiento de recursos: Consisten en la inundación de las capacidades de un servicio o máquina con gran cantidad de tráfico autorizado, de forma que no puede cumplir su función con respecto a los usuarios legítimos con normalidad. El objetivo del atacante es ocupar todo el ancho de banda de la conexión al servidor, o consumir sus recursos

31 31 computacionales básicos: CPU y memoria. Un ejemplo de consumo del ancho de banda de la conexión a la red de un host objetivo es el Ataque Smurf DoS. Este ataque está basado en la técnica de suplantación de IP (IP Spoofing), que consiste en enviar paquetes de red manipulando las cabeceras IP de manera que la dirección de origen no sea la propia. El envío de paquetes de red con una dirección ajena significa que las respuestas a dichos paquetes por parte de la estación destino se realizarán hacia esa dirección. El ataque Smurf consiste en el envío de paquetes ICMP ECHO Request a la dirección de broadcast, es decir, a todos los equipos de la red objetivo a la vez, poniendo como origen de los paquetes la dirección IP del host víctima. Cada una de las máquinas de la red contestarán a la víctima con los correspondientes paquetes ICMP ECHO Reply, consumiendo una fracción del ancho de banda de su enlace de red, y el conjunto de todos colapsará las comunicaciones de la víctima durante unos segundos.

32 32 Los ataques de negación de servicio generalmente utilizan la técnica de suplantación de IP, ya que el ataque no requiere una contestación por parte de la víctima para tener éxito y además mediante el cambio de la dirección IP de origen, hará más complicada la identificación del origen del ataque por parte del administrador de red EXPLOITS REMOTOS Los exploits o vulnerabilidades remotas son el método más común para obtener acceso no autorizado a un sistema. Estas técnicas están diseñadas para tomar ventaja de código software mal diseñado para comprometer y tomar control de un host vulnerable. Estas vulnerabilidades suelen ser ampliamente conocidas y los desarrolladores del software habrán publicado parches para resolverlas, por lo que es responsabilidad de los administradores de red tener actualizadas sus aplicaciones. Si no es así, significa que el hacker tiene un conocimiento profundo del aplicativo cuya vulnerabilidad ha descubierto y pretende explotar, por lo que el ataque será difícilmente predecible y sólo se podrán tomar medidas reactivas una vez se lleve a cabo. Los ataques de exploit remoto se asemejan a los ataques DoS de paquetes maliciosos en que se aprovechan de la debilidad del software que en situaciones inesperadas no es capaz de evaluar la entrada de datos, haciendo que el sistema no sepa cómo reaccionar y colapse [NORT01]. Una vulnerabilidad típica ante la que todo software es propenso a fallar es la del desbordamiento de búfer (buffer overflow). Los desbordamientos de búfer se producen cuando un atacante introduce más datos de los que un búfer o array puede manejar y esta condición no está adecuadamente evaluada en el código del programa. Al salirse de la zona reservada, los datos introducidos se sitúan por tanto en posiciones contiguas de memoria y esto no sólo provoca que el programa aborte sino que si se ha realizado de forma adecuada, se puede forzar al sistema a ejecutar la información fuera de rango sin restricciones de permisos. El Apache chunked

33 33 encoding exploit es un ejemplo de desbordamiento remoto de búfer. Apache fallaba al calcular los tamaños dinámicos de búfer debido a la malinterpretación de un entero sin signo definido en su código de programa. Peticiones codificadas de determinada manera permitían incluir comandos del sistema en las posiciones que quedaban fuera del búfer, lo que permitía a los hackers arrancar consolas remotas con permisos de administrador o crear cuentas de usuario raíz en la máquina comprometida. Los hackers más expertos pueden encontrar la forma de que una aplicación ejecute comandos o código binario en un sistema sin necesidad de provocar un desbordamiento de búfer, evitando así que la aplicación aborte para llevar a cabo un ataque más silencioso. Estos ataques requieren también de amplios conocimientos sobre el código fuente del software a explotar. Un ejemplo es el Unicode exploit for Microsoft's IIS, que permitía la navegación libre por la estructura de directorios de las máquinas que incorporaban las primeras versiones de este servidor Web. La vulnerabilidad consistía en que el módulo intérprete de las direcciones que se solicitan desde el navegador, traducía la representación Unicode del símbolo delimitador de directorio ( / ), permitiendo al hacker acceder a cualquier fichero en el sistema. La lógica de las aplicaciones Web dinámicas es muy propensa a fallo frente a usuarios malintencionados. La comprobación de la entrada de datos por parte de un programa para evitar la explotación de vulnerabilidades es fundamental, y un ejemplo de esto es el popular ataque de inyección de SQL. Este método consiste en la inserción de sentencias SQL en los campos de entrada de un formulario Web. Las queries debidamente introducidas pueden modificar la lógica del acceso a datos del programa, por ejemplo, permitiendo al atacante saltarse la fase de registro o lanzar comandos al sistema ACCESOS AUTORIZADOS En la mayoría de los casos, la intención de un ataque es el control de la máquina objetivo, el acceso a la información almacenada en ella, la explotación de sus recursos computacionales, etc. El uso de permisos

34 34 legítimos de usuario es la forma más cómoda y fiable de llevar a cabo ataques con éxito, pero con las debidas medidas de control, la identificación de un usuario que realice alguna acción maliciosa de esta manera es inmediata. Los propios empleados de una empresa, son en muchas ocasiones la persona que está detrás del ataque a un recurso de la misma, ya que disponen de una posición más ventajosa que la de un hacker externo de cara a que de alguna manera "ya están dentro". Por otra parte, los empleados que disfrutan de un acceso privilegiado a determinados recursos son en ocasiones los culpables de la publicación de contraseñas o de la desprotección de los sistemas bajo su responsabilidad, lo que suele ser aprovechado por terceros malintencionados para perpetrar ataques pudiendo inculpar al encargado. La adquisición de los permisos de un usuario autorizado para acceder a un recurso clave de la organización puede ser tan sencillo como obtener su contraseña de autenticación en el sistema. Una acción llevada a cabo utilizando los credenciales de la víctima exime al que se hace pasar por ella de cualquier acusación. El robo de contraseñas y certificados digitales se da con mucha frecuencia en entornos de confianza y exceso de ingenuidad por parte de los hombres que están detrás de las máquinas. Los sistemas de autenticación débiles son una fuente de problemas de este tipo; si es sencillo obtener permiso de acceso a un recurso por parte de una persona autorizada, también lo será para una que no lo es, por lo que una buena gestión de contraseñas es fundamental. Se recomienda a los administradores de red establecer contraseñas de usuario alfanuméricas, no estándar y no de diccionario que cambien periódicamente en todos los sistemas de una organización. El espionaje de las comunicaciones en una red mediante herramientas sniffers es una sencilla manera de hacerse con contraseñas de usuario aprovechando procesos no cifrados de autenticación remota. El control de las aplicaciones que los empleados tienen instaladas en sus terminales y la adecuada configuración de red que impide estas actividades es fundamental para evitar una situación comprometida. Las aplicaciones Web dinámicas generalmente usan cookies para mantener el estado de una comunicación entre el cliente y el servidor. Las cookies son ficheros ligeros que se instalan en la máquina del cliente, con su

35 35 permiso, y que almacenan, entre otras cosas, información de autenticación de usuario. Aprovechando esto, existe una forma de escalada de privilegios que los hackers llevan a cabo mediante una sencilla técnica de engaño denominada cross-site scripting (XSS) [NORT01]. Consiste en presentar al usuario una ventana que le anime a hacer clic en un enlace malicioso haciéndole creer que se trata de una navegación normal y corriente. El objetivo de que el usuario haga esto es el de obtener su "permiso" para transferir sus cookies al atacante, que una vez las tenga en su poder podrá utilizar para acceder a otros sistemas y servicios con los mismos credenciales de la víctima. Debido a la inmadurez de muchos usuarios de Internet y a la navegación por sitios poco fiables, estos ataques tienen una alarmante tasa de éxito y se presentan con mucha frecuencia. La ingenuidad y el exceso de confianza por parte de los usuarios es lo que permite, según la misma filosofía de los ataques XSS, la proliferación de virus y troyanos y su entrada en el sistema con facilidad. Un usuario que permite la instalación de un programa malicioso en su máquina (tanto porque haya sido engañado como de forma inconsciente) está dando automáticamente a éste todos sus permisos. La actividad de un virus o un troyano suele ser detectada por un NIDS si genera tráfico anormal de red o por un NNIDS si se ejecuta en local. Los programas de este tipo que son más interesantes a la hora de acceder a los recursos de una máquina son los troyanos de control remoto, que instalados en un host objetivo, mantienen abierto un puerto de comunicaciones directo con el hacker. Estos troyanos pueden ser usados para llevar a cabo innumerables tipos de ataques, desde escaneos de puertos y negaciones de servicio hasta el envío de información local al exterior. Un ejemplo popular es el troyano Back Orifice, que encripta la comunicación con el atacante remoto y por ello en un principio fue indetectable por los IDS del momento. Otro ejemplo clásico de troyano es el Loki Trojan [KOZI03], que basa su interactuación con el host remoto del hacker en comunicaciones sobre el protocolo ICMP, que generalmente no se considera sospechoso y los administradores de red suelen permitir que pase a través del cortafuegos. Este es un típico caso de acceso autorizado, tanto por parte del usuario, que acepta la instalación del troyano (generalmente de

36 36 forma inconsciente), como por parte del administrador, que está autorizando el tráfico ICMP sin considerar esta situación MODELOS DISTRIBUIDOS A continuación, se dedicarán unos cuantos apartados a la introducción de los modelos de sistemas distribuidos para terminar por explicar el modelo de agentes inteligentes que es en el que se basa el sistema propuesto MODELO CLIENTE-SERVIDOR El modelo Cliente-Servidor es hoy en día el modelo de referencia y más difundido de comunicación entre aplicaciones software distribuidas. Este modelo está basado en una distinción rígida de roles entre nodos cliente (solicitantes de recursos) y nodos servidor (proveedores de recursos). Los nodos servidor proveen los servicios, es decir, las capacidades del sistema distribuido, pero no son capaces de tomar ninguna iniciativa (son de carácter reactivo). Los nodos cliente, por el contrario, representan la iniciativa del sistema: acceden y usan los servicios según las necesidades del cliente aunque no proporcionan ninguna funcionalidad compleja. Los clientes pueden aparecer y desaparecer en cualquier momento, disponiendo de direcciones dinámicas mientras que los servidores al tener que garantizar un mínimo de estabilidad, suelen utilizar una dirección estática bien conocida. Los clientes se comunican con los servidores, pero no pueden ni necesitan comunicarse con otros clientes. Del otro lado, un servidor no puede comunicarse con sus clientes hasta que ellos tomen la iniciativa y decidan establecer una sesión de comunicación con el servidor. Internet es el típico ejemplo de aplicación basada en el modelo clienteservidor.los servidores son los sitios o portales que proporcionan la lógica de aplicación y recursos de información. Los clientes son los navegadores (browsers),

37 37 simples herramientas que proporcionan una interfaz con el usuario y cuya única tarea es la de realizar las peticiones y presentar la información solicitada. Las aplicaciones distribuidas existentes no siempre se adaptan a este modelo. Por ejemplo, una simple aplicación de "chat", un sistema distribuido de compartición de archivos o un juego multijugador, requiere que los nodos activos en los terminales de usuario sean capaces de comunicarse unos con otros. Aunque estos ejemplos puedan implementarse en una arquitectura cliente-servidor pura (cosa que en muchas ocasiones se hace así), se perdería la flexibilidad y escalabilidad que aportan los nodos cliente autónomos. En el momento en que los nodos cliente se comunican directamente entre sí, responden a peticiones de recursos e incorporan lógica de negocio, un servidor físico deja de ser necesario ya que su funcionalidad se ha repartido entre los demás elementos de la arquitectura. Las redes de ordenadores con funciones cliente-servidor se disponen en una topología en estrella de servicios centralizados como se puede observar en la figura 8 [DIAZ05]: MODELO PEER-TO-PEER (P2P) El modelo peer-to-peer se caracteriza por no hacer distinción de roles entre cada nodo del sistema. Cada uno de los elementos que componen el modelo puede iniciar una comunicación, siendo origen o destinatario de una petición y pesentando o devolviendo la información solicitada. La lógica de la aplicación no está

38 38 concentrada en un sólo sitio sino que se encuentra distribuida entre los diferentes nodos de la red; cada nodo es capaz de descubrir a los demás (no tienen por qué disponer de direcciones bien conocidas) y pueden ingresar o abandonar la red en cualquier momento. La diferencia fundamental entre el modelo cliente-servidor y el peer-topeer está en la forma en que los nodos se conocen entre sí. En un sistema cliente-servidor, los clientes deben limitarse a conocer las direcciones estáticas de los servidores, ya que no necesitan comunicarse con los otros clientes ni tener conocimiento de su estado. En un sistema P2P, se debe contar con servicios que permitan a los diferentes participantes entrar o salir de la red en cualquier momento así como incluir procedimientos de búsqueda de recursos y descubrimiento de nodos. Estos mecanismos son generalmente conocidos como servicios de páginas blancas (descubrimiento de participantes) y páginas amarillas (búsqueda de recursos y servicios provistos por un participante desconocido). Una red P2P pura está absolutamente descentralizada y los participantes son completamente autónomos. La ausencia de un nodo de referencia hace muy difícil mantener la coherencia del sistema y el descubrimiento de participantes. Los beneficios de la escalabilidad y la flexibilidad de la red tienen como coste un mayor ancho de banda requerido y una complejidad de arquitectura de comunicaciones que crece exponencialmente con el número de nodos conectados. Del mismo modo, la autonomía de cada nodo a la hora de conectarse y desconectarse de la red implica un sistema de seguridad y autenticación no centralizado y por tanto potencialmente inseguro. Las redes de ordenadores con funciones peer-to-peer puras se disponen en una topología punto a punto entre todos los nodos como se puede observar en la figura 9 [DIAZ05]:

39 39 Los inconvenientes que implica una red P2P pura hacen plantearse la idea de implantar el sistema P2P en un entorno híbrido. Las arquitecturas P2P híbridas están basadas en un nodo especial que proporciona los servicios de búsqueda de recursos y descubrimiento de participantes de forma centralizada. Este participante está exclusivamente dedicado al control del estado de la red, manteniendo un índice actualizado en todo momento de nodos activos (páginas blancas) y servicios disponibles (páginas amarillas) que puede ser consultado centralizadamente por los demás participantes. Este tipo de redes generan menos tráfico y son más seguras, ya que la entrada a formar parte de la red por parte de un nodo requiere su registro y autenticación en el nodo central. Por otra parte el funcionamiento correcto del sistema requiere la disponibilidad del nodo central, convirtiéndose éste en un punto crítico de fallo y ataques. Las redes de ordenadores con funciones peer-to-peer híbridas se disponen en una topología punto a punto entre todos los nodos y en estrella respecto al nodo central, como se puede observar en la figura 10 [DIAZ05]:

40 40 El modelo peer-to-peer es el más adecuado para implantar un sistema de agentes inteligentes MODELO DE AGENTES INTELIGENTES El paradigma de los agentes inteligentes engloba conceptos de inteligencia artificial y sistemas distribuidos. Esta idea se basa en la abstracción de la entidad agente: componente software autónomo, proactivo y social [GARA04]: autónomo: un agente tiene control de sus propias acciones; desde el punto de vista del sistema local en que se ejecutan tienen su propio hilo de ejecución y dentro de su nivel de conocimiento es capaz de tomar decisiones inteligentes según su estado. proactivo: un agente no sólo responde a eventos externos (acciones de usuario o llamadas remotas); un agente posee un comportamiento propio orientado a un objetivo, siendo capaz de tomar iniciativas. social: un agente necesita y es capaz de interactuar con otros agentes para llevar a cabo su tarea y alcanzar el objetivo para el cual está diseñado. Un sistema distribuido basado en agentes inteligentes es intrínsecamente peer-topeer: cada agente es un participante que necesita comunicarse con otros agentes al

41 41 tiempo que es capaz de proveer de información y servicios al resto de participantes. El modelo de comunicación es muy importante en un sistema basado en agentes y está basado en las siguientes premisas [BELL03]: los agentes son entidades activas y desacopladas: la comunicación entre agentes es de tipo asíncrono, es decir, el agente que envía el mensaje y el destinatario del mismo no tienen porqué estar disponibles al mismo tiempo. Una vez un participante envía un mensaje a otro, el primero no se queda a la espera de la respuesta del segundo, sino que sigue funcionando para evaluar la contestación en el momento en que llegue. Esto permite al receptor seleccionar los mensajes a servir según sus propias prioridades y evita que el emisor se quede bloqueado a la espera del procesado de la petición y respuesta por parte del otro participante. De esta manera se evita la dependencia funcional entre el emisor y el receptor, propensa a dar problemas cuando uno de los dos extremos falla en mitad de una comunicación. los agentes realizan acciones: la comunicación con otros agentes es una más de las acciones que realizan los agentes inteligentes y por tanto es tratada al mismo nivel. De esta manera las acciones lógicas y las acciones de comunicación no interfieren entre sí y pueden ser planificables sobre el mismo hilo de ejecución. la comunicación tiene significado semántico: un agente debe ser capaz de comprender el mensaje de una comunicación y el significado de aquello que el emisor solicita. En un sistema de agentes inteligentes las comunicaciones no se limitan a llamadas remotas a servicios del destinatario, sino que un mensaje puede indicar a aquel que lo recibe desde un cambio de estado hasta la petición de una operación compleja en la que se puedan ver involucrados otros agentes. Todo esto significa la necesidad de implantar un protocolo semántico de comunicación estandarizado. En 1996, TILAB (Telecom Italian LABoratories) propuso la creación de la FIPA (Foundation for Intelligent Physical Agents), organización de empresas y grupos sin ánimo de lucro cuyo objetivo era el desarrollo de especificaciones estándar para la tecnología de agentes. TILAB y en particular el equipo JADE, lideraron esta iniciativa editando las primeras especificaciones del que más tarde sería el estándar FIPA (2002). Este estándar se centra en la interoperabilidad del sistema de agentes inteligentes definiendo bien el comportamiento externo de los

42 42 componentes del sistema y dejando abiertos los detalles de la implementación interna de la lógica de negocio. El estándar FIPA es fiel al paradigma de agentes inteligentes y define el modelo de referencia de la plataforma básica de agentes y los servicios básicos que debe garantizar. El conjunto de servicios básicos y sus interfaces estándar son todo lo que una sociedad de agentes necesita para existir, colaborar y ser administrada. Los servicios que el estándar FIPA determina como necesarios son [GARA04]: Control del ciclo de vida: Un agente inteligente debe mantener un control permanente sobre su propio ciclo de vida, ya que determina su interoperabilidad con el resto de la plataforma. Servicio de páginas blancas: Se debe disponer de un procedimiento común para todos los agentes de la plataforma que permita referenciar un agente remoto inequívocamente. Servicio de páginas amarillas: Se debe disponer de un procedimiento común para todos los agentes de la plataforma que permita referenciar un servicio remoto inequívocamente sea cual sea el agente que lo proporcione. Sistema de mensajería: La comunicación asíncrona entre agentes debe realizarse mediante un sistema de mensajería estándar, flexible y adaptable a cualquier lógica de negocio. Debido al interés en el aspecto social de los agentes y sus necesidades de comunicación con otros agentes, el capítulo Agent Comunication Language (ACL) es uno de los más importantes del estándar FIPA MIDDLEWARE Se denomina middleware al conjunto de librerías de medio-alto nivel que proveen de servicios genéricos para los diferentes tipos de aplicaciones distribuidas que las implementan haciendo su desarrollo más sencillo, y el producto software resultante más eficiente, escalable y mantenible. Aunque no se trata propiamente de un modelo de arquitectura distribuida, forma parte de cualquier diseño de una aplicación de este tipo de arquitecturas.

43 43 Servicios como comunicación, acceso a datos, cifrado o control de recursos son ejemplos típicos que aporta un Sistema Operativo local. Independizando estos servicios del entorno local e integrándolos en un paquete reutilizable, se confecciona una capa horizontal que permite dar soporte a las aplicaciones distribuidas que necesiten estos servicios comunes.

44 44 4. HERRAMIENTAS Y TECNOLOGÍAS USADAS 4.1. TECNOLOGÍA JAVA JADE Llegados a ese punto, se profundizará en el modelo de agentes inteligentes JADE, presentando las particularidades de esta tecnología, que ha sido preciso aprender a manejar para el desarrollo del presente proyecto. JADE (Java Agent DEvelopment Framework) es el middleware diseñado por TILAB que proporciona tanto un entorno de desarrollo como un entorno de ejecución para la realización y mantenimiento de de aplicaciones distribuidas multiagente basadas en la arquitectura de comunicación peer-to-peer. La inteligencia, la iniciativa, la información, los recursos y el control pueden distribuirse completamente entre los terminales móviles o los equipos informáticos que conformen la red. El entorno evoluciona dinámicamente con los participantes o agentes, que aparecen y desaparecen del sistema de acuerdo con las necesidades y requisitos de la aplicación. La comunicación entre los participantes, ya sea en una red cableada o inalámbrica es completamente simétrica asumiendo cada par de implicados el rol de origen y destinatario según sea la situación [BELL03]. JADE está completamente desarrollado en tecnología Java y proporciona una serie de herramientas que permiten al desarrollador controlar y depurar a los agentes en tiempo real. Está basado en los siguientes principios: Interoperabilidad: JADE cumple con las especificaciones FIPA. Esto garantiza que los agentes JADE pueden interactuar con otros agentes que asuman el mismo estándar aunque no estén desarrollados necesariamente con JADE. Uniformidad y portabilidad: JADE provee un juego de APIs independientes de la infraestructura de red y de la versión de la máquina virtual Java sobre la que se ejecuten. Intuitivo: La complejidad del middleware se encuentra encapsulada tras un simple e intuitivo interfaz de APIs. En los siguientes apartados se detallan más aspectos de la tecnología JADE, dentro de los modelos de arquitectura y funcional.

45 MODELO DE ARQUITECTURA JADE incluye tanto las librerías necesarias para desarrollar aplicaciones multiagente como el entorno de ejecución que provee los servicios básicos sobre el que arrancar los agentes. Cada instancia del entorno de ejecución JADE se denomina contenedor y se alberga en un host de la red concreto. El conjunto de todos los contenedores activos en un sistema multiagente se denomina plataforma y proporciona una capa homogénea que oculta a los agentes y al desarrollador la complejidad de las capas inferiores (Hardware, Comunicaciones, Sistema Operativo y versión de la JVM). En cada plataforma debe existir un contenedor particular denominado contenedor principal. Este contenedor alberga dos agentes especiales, además de los que se quieran arrancar en él [ARAN06]: AMS (Agent Management System): Proporciona el servicio de páginas blancas. Gracias a ello permite la búsqueda y reconocimiento entre agentes. En él se registra y se da de baja cada agente que se incorpora o que abandona la plataforma. El agente AMS garantiza que cada agente activo disponga de un nombre único dentro de la plataforma y proporciona la interfaz para arrancar y matar agentes en contenedores remotos. Representa la autoridad de la plataforma. DF (Directory Facilitator): Proporciona el servicio de páginas amarillas. Gracias a ello permite la búsqueda de agentes que provean de determinados servicios para lograr sus objetivos. No es necesario que los agentes de la plataforma registren sus funcionalidades en este agente, pero en ese caso el servicio de páginas amarillas no funcionará adecuadamente. El contenedor principal se arranca, como cualquier otro contenedor, en un host en particular. Por las funcionalidades avanzadas que incorporan los agentes especiales antes descritos, el host que alberga el contenedor principal resulta ser un nodo clave de la plataforma, al que los demás nodos acuden para buscar otros nodos o servicios. Es por esta razón por la que podemos hablar de una arquitectura peer-topeer híbrida cuando describimos la arquitectura de red de un sistema multiagente JADE.

46 MODELO FUNCIONAL Desde el punto de vista funcional, JADE proporciona los servicios básicos necesarios para dar soporte a aplicaciones distribuidas peer-to-peer tanto en entornos fijos como en móviles. JADE permite a cada agente el descubrimiento dinámico de otros agentes y de sus funcionalidades, gracias a los servicios de páginas blancas y páginas amarillas incorporados en los agentes dedicados a tal efecto (AMS y DF). La comunicación entre agentes se realiza exclusivamente a través de mensajes asíncronos por ser el sistema más adecuado para los sistemas distribuidos con bajo acoplamiento. La estructura de los mensajes cumple con el lenguaje estándar ACL definido por la FIPA [GARA04]: sender: Identificador del agente remitente del mensaje. receivers: Lista de identificadores de agentes destinatarios del mensaje. performative: Intención de la comunicación. El estándar ACL fija hasta 22 tipos de performative predefinidos: INFORM (comunicar un suceso), REQUEST (solicitar un recurso o acción), QUERY-IF (preguntar por una condición), PROPOSE (establecer una comunicación compleja o negociación)...

47 47 content: Contenido del mensaje. language: Tipo de sintaxis utilizada en el content. ontology: Diccionario de símbolos utilizados en el content. diversos campos de control para conversaciones concurrentes, timeouts... JADE abstrae la capa de comunicaciones del sistema con una interfaz de funciones sencillas para el envío y recepción de mensajes. La orientación de los agentes JADE a la consecución de objetivos concretos se implementa a través de los denominados comportamientos. Varios comportamientos arrancados por un agente se ejecutan de forma concurrente aunque lo hacen sobre el mismo hilo de ejecución. Esto evita problemas de sincronización entre comportamientos que acceden a recursos comunes. Un comportamiento puede interrumpirse en cualquier momento y reanudar su ejecución en el punto en que se dejó. Esto favorece la movilidad de agentes entre contenedores remotos. Algunos de los comportamientos básicos propuestos por la distribución básica de JADE son los siguientes: OneShotBehaviour: Comportamiento cuyo algoritmo se ejecuta una sola vez. CyclicBehaviour: Comportamiento cuyo algoritmo se ejecuta de forma cíclica; una vez que termina, vuelve a comenzar. CompositeBehaviour: Comportamiento que se compone de diferentes subcomportamientos que se pueden ejecutar siguiendo diferentes políticas de planificación: de forma secuencial (SequentialBehaviour), en paralelo (ParallelBehaviour), etc. WakerBehaviour: Comportamiento cuyo algoritmo se ejecuta una sola vez, pasado un tiempo especificado desde su arranque. TickerBehaviour: Comportamiento cuyo algoritmo se ejecuta periódicamente según un tiempo especificado desde su arranque. Como se detalló en el apartado 3.3.2: Modelo peer-to-peer, la propiedad de los participantes de una red de este tipo de poder ingresar y abandonar el sistema de forma autónoma y sin un control centralizado, es potencialmente peligrosa. En JADE, la existencia de un nodo central (agente AMS) que mantiene un registro de

48 48 los agentes vivos en el sistema y garantiza el carácter unívoco de sus identificadores permite la incorporación de funciones de seguridad de gran interés. JADE proporciona mecanismos de autenticación y verificación de permisos asignados a participantes que entren a formar parte de una arquitectura multiagente. El sistema de intercambio de mensajes entre agentes JADE implementa sistemas de verificación y autenticación del remitente si se estima necesario en el lado del destinatario. Un agente JADE puede implementar tantos comportamientos como sean necesarios para llevar a cabo las tareas para las cuales ha sido diseñado. Esto es muy cómodo a la hora de ampliar la funcionalidad de un participante permitiéndole añadir tareas en paralelo sin incrementar excesivamente su consumo de recursos. La sencillez del proceso de incorporación de nuevos agentes a la plataforma en contenedores remotos hace de cualquier proyecto desarrollado sobre JADE un sistema escalable y fiable, ya que se simplifica considerablemente el arranque inmediato de agentes de backup o incluso contenedores enteros en caso de fallo de los principales [BELL03]. En entornos móviles, JADE asegura su eficacia con sus servicios de migración y movilidad. Un agente JADE puede suspender su ejecución en cualquier momento, migrar a un contenedor ubicado en un host diferente sin necesidad de instalar el código del agente en el sitio remoto y recuperar su ejecución en el punto en el que fue interrumpida. Esta funcionalidad permite realizar un balanceo de carga entre los equipos que soportan el sistema multiagente en tiempo de ejecución sin significar el más mínimo impacto en la aplicación [BELL03]. Por último, JADE proporciona un juego de herramientas gráficas de soporte de gran interés que permiten la monitorización en tiempo de ejecución del estado de la plataforma en todo momento. Con estas herramientas, es posible el control remoto de los agentes, la emulación de conversaciones, la visualización de las comunicaciones entre agentes en vivo y la comprobación del estado de los agentes y su ciclo de vida. La herramienta más interesante en este aspecto es el agente RMA (Remote Management Agent), cuya interfaz gráfica se muestra a continuación [ARAN06]:

49 49 Sólo puede existir un agente RMA por contenedor aunque puede haber varios por plataforma. La interfaz gráfica del agente RMA permite las siguientes acciones de monitorización y control de los agentes del sistema: Visualizar estado de la plataforma JADE, contenedores asociados y estado de los agentes arrancados en cada uno de ellos en una estructura de árbol. Terminar la ejecución de un agente (incluido él mismo). Terminar la ejecución de todos los agentes de un contenedor. Terminar la ejecución de la plataforma en la que se encuentra. Arrancar un nuevo agente. Detener la ejecución de un agente (suspenderlo). Recuperar la ejecución de agentes suspendidos, devolviéndolos al estado activo. Enviar un mensaje ACL a los agentes seleccionados. Una interfaz gráfica detallada permite rellenar los correspondientes campos de un mensaje. Migrar un agente de un contenedor a otro. Clonar un agente, replicando la funcionalidad, estado y comportamientos del agente seleccionado a un nuevo agente vivo en el contenedor que se desee.

50 50 Otra de las herramientas que proporciona JADE es el agente Dummy. Este modelo de agente permite fácilmente interactuar con otros agentes y proporciona un interfaz gráfico que permite construir mensajes ACL, enviarlos, almacenarlos y verlos en detalle. Este agente puede arrancarse desde el interfaz RMA.

51 51 La visualización en tiempo real de las comunicaciones que se dan entre agentes de la plataforma es posible gracias a otro de los agentes de monitorización que proporciona JADE. El agente Sniffer proporciona una interfaz gráfica intuitiva que permite ver el estado de las comunicaciones de los agentes deseados [ARAN06]:

52 NTOP Hoy en dia las redes son cada vez es más importantes, por eso conviene saber qué está pasando en cada momento. Hay muchos esnifadores, como por ejemplo el sniffit, el ethereal, pero no tienen nada que ver con el Ntop. Ntop (Network TOP) es una herramienta que no puede faltar al administrador de red, porque permite monitorizar en tiempo real los usuarios y aplicaciones que están consumiendo recursos de red en un instante concreto y además es capaz de ayudarnos a la hora de detectar malas configuraciones de algún equipo (esto salta a la vista porque al lado del equipo en cuestión sale un banderín amarillo o rojo, dependiendo si es un error leve o grave), o a nivel de servicio. Posee un microservidor web que permite que cualquier usuario que sepa la clave, pueda ver la salida Ntop de forma remota con cualquier navegador, y además es GNU. El software esta desarrollado para platarfomas Unix y Windows. En modo Web, actúa como un servidor Web, volcando en HTML el estado de la red. Viene con un recolector/emisor NetFlow/sFlow, una interfaz de cliente basada en HTTP para crear aplicaciones de monitorrización centradas en top, y plugin para almacenamiento de las estadísticas de tráfico en bases de datos de tipo Round-Robin. Los protocolos que es capaz de monitorizar son, principalmente: TCP/UDP/ICMP, (R)ARP, IPX, DLC, Decnet, AppleTalk, Netbios, y ya dentro de TCP/UDP es capaz de agruparlos por FTP, HTTP, DNS, Telnet, SMTP/POP/IMAP, SNMP, NFS, X11. Su instalación tanto en Windows como en Linux es muy sencilla, y para que funcione aprovechando todas las posibilidades que ofrece conviene tener instalados, además, los programas: GDChart: Es un programa para poder hacer gráficos. Ya viene integrado en el fichero ntop-current.tgz, pero también hay que dejarlo instalado. lsof: Es un programa capaz de listar qué ficheros están abiertos en el sistema. nmap: Es un programa capaz de escanear una red de ordenadores en busca de información. Librerías OpenSSL: Para poder montar el servidor web con conexiones seguras (SSL).

53 53 Servidor MySQL: Para permitir almacenar toda la información en una base de datos si es que necesitamos más detalle del que nos ofrece el plugin rrdtool. Para poder conectar Ntop con el MySQL, hay que ayudarse de un pequeño programita hecho en perl que viene dentro del paquete y se llama "mysqlserver.pl". Una vez instalado el Ntop y los componentes que necesitemos, hay a disposición nuestra una gran cantidad de opciones a la hora de ponerlo en marcha. Une ejemplo podría ser ntop -P /var/lib/ntop -w W i eth0 -b localhost:4000 -d -E -L -a /www/logs/ntop.log, donde: -P /var/lib/ntop; Donde se guardarán los archivos correspondientes a las bbdd Round-Robin. -w 3000; Abrimos el servidor en el puerto W 3003; Abrimos el servidor SSL en el puerto i eth0; Escuchamos todo el tráfico que pasa por el interfaz de red eth0. -b localhost:4000; Donde está el programa puente para el servidor MySQL. -d; Para que se convierta en demonio. -E; Para que se ayude de herramientas externas (lsof, nmap,...). -L; Habilita la salida al syslog. -a /www/logs/ntop.log; Es el fichero de acceso a la página web del ntop.

54 54 Una vez que ha arrancado, podemos ver qué está pasando en nuestra red visitando la página web o En general, con Ntop se puede hacer lo siguiente: Agrupar el tráfico de red según protocolos o muchos otros criterios, a gusto del administrador Mostrar estadísticas de tráfico Almacenarlas de forma permanente en disco, en ficheros con formato rrd (Round Robin database) Identificar los usuarios de cada equipo Identificar el SO de los equipos de forma pasiva

55 55 Analizar el tráfico IP según origen/destino Mostrar el tráfico IP de forma que podamos ver quién habla con quién Hacer informes de uso del protocolo IP según protocolos Construir estadísticas de tráfico de forma similar a cómo lo hace el protocolo RMON La opción más interesante, al menos desde el punto de vista del sistema IDSRN, es el hecho de almacenar la información que monitoriza en los mencionados ficheros.rrd, cuya estructura y funcionamiento se detallan en el punto 2. Uso de rrdtool, del anexo 2 Manual de uso del Sistema IDSRN.

56 REDES NEURONALES Qué es una red neuronal? Las neuronas son los constituyentes estructurales del cerebro, al cual siempre se le ha atribuído una tremenda capacidad de cálculo. El cerebro se puede definir mediante el símil de que es un ordenador muy complejo, no lineal y paralelo, cuyas cualidades alcanza mediante una sofisticada red de neuronas con interacciones sinápticas [ISAS04]. Una red neuronal artificial es un algoritmo matemático con capacidad para recordar experiencias y hacerlas disponibles para su uso. Recuerda al cerebro humano en dos aspectos: El conocimiento es adquirido por la red a través de un proceso de aprendizaje La fuerza de la conexión entre neuronas (pesos sinápticos) es usada para almacenar el conocimiento. Una red neuronal aprende mediante la modificación de sus pesos sinápticos. Se puede modificar también la topología. Hay otras formas de llamarlas: redes conexionistas, procesadores distribuidos paralelos, neurocomputadores, entre otros. En general, presentan varias e importantes ventajas: Modela relaciones no lineales Modela relaciones entrada-salida Capacidad de adaptación Tiene en cuenta el contexto de trabajo Posibilidad de desarrollo de dispositivos VLSI Uniformidad de análisis y diseño Analogía neurobiológica Una neurona artificial es la unidad de procesado básica de una red neuronal artificial. Sus elementos básicos son:

57 57 Sinapsis o conexiones, cada una de ellas con un peso Un sumador capaz de sumar entradas pesadas Una función de activación que limita la amplitud de la salida (esta puede ser de varios tipo, algunas de las más importantes y usadas son: umbral, rampa, sigmoidal, tangente hiperbólica, función signo) PROCESO DE APRENDIZAJE El proceso de aprendizaje de una red neuronal consta de 2 partes, entrenamiento y validación: Aprendizaje: Proceso por el que los pesos de las conexiones sinápticas de las neuronas son adaptados a través de una continua estimulación del entorno. El tipo de aprendizaje tiene determinado por la manera en que los cambios en los parámetros tienen lugar. La secuencia de sucesos en el aprendizaje son: Estimulación de la red neuronal por el entorno Modificación de la fuerza de las conexiones Respuesta de la red en esta nueva situación Validación: Una vez que ha terminado el proceso de aprendizaje y los pesos de la red neuronal han sido calculados, es importante comprobar la calidad del modelo resultante. Una medida de la calidad puede darse en términos de los errores entre los valores de salida deseados y los obtenidos por la red neuronal, como por ejemplo el error cuadrático.

58 58 Para el proceso de aprendizaje se pueden usar varios métodos. Los más destacados son el aprendizaje por corrección de error, el de Bolzmann, el Hebbiano y el competitivo. Cada uno de ellos pertenecerá a un paradigma distinto, supervisado, o no supervisado. Estos paradigmas se distinguen por la presencia (supervisado) o no (no supervisado) de un maestro cuyo conocimiento se transfiere a la red y por que los parámetros de la red se ajustan por una influencia combinada del vector de entrenamiento y la señal de error (supervisado) o por una medida independiente de la tarea (no supervisado) TIPOS DE NEURONAS Célula de McCulloch-Pitts: El primer modelo de neurona artificial fue propuesto por Warren McCulloch y Walter Pitts en 1943 en un artículo titulado: A Logical Calculus of the Ideas Immanent in NervousActivity. Esta propuesta simplificaba una estructura y funcionamiento parecido a las neuronas del cerebro. Consideraba solo 2 estados 0, apagado, y 1, encendido. La célula de McCulloch-Pitts recibe como entradas n valores binarios X= {x1, x2,..., xn} y produce una única salida binaria S. Cada célula además tinen n+1 valores reales, n pesos de las conexiones (wi) y un umbral Q. A partir de la célula de McCulloch-Pitts se puede definir una red neuronal como una colección de neuronas de McCulloch-Pitts, todas con las mismas escalas de tiempos y donde sus salidas están conectadas a las entradas de otras neuronas. El perceptrón: Las células de McCulloch-Pitts se consideran las neuronas precursoras de todos los tipos de neuronas y redes neuronales que vinieron después. El primer tipo de neurona nacido como tal es el Perceptrón de Rosenblatt en La neurona perceptrón se ideó como clasificador de ejemplos. Es un discriminante de clases.

59 59 El Perceptrón es similar a una célula de McCulloch-Pitts en su estructura pero no en su funcionamiento: o Es una neurona con pesos sinápticos ajustables y un umbral. o La salida de la neurona es +1 ó 1. Entradas reales. o La neurona permite clasificar un conjunto de entradas en dos clases separables de forma automática. ADALINE (ADAptive LInear NEuron): El perceptrón tiene los siguientes problemas entre otros: o Sólo puede clasificar 2 clases linealmente separables o No aprende teniendo en cuenta la magnitud del error que comete, sólo si hay error. Casi al mismo tiempo que Frank Rosenblatt expone su perceptrón (1958), Bernard Widrow y su estudiante Marcian Hoff introducen un modelo de neurona similar pero que establecía una manera de aprender diferente a la del perceptrón y que luego sirvió de base para los principales métodos de aprendizaje por corrección de error. La neurona se llamaba ADALINE y aprendía con la regla Delta. La regla Delta trata de obtener un valor de salida y=d cuando se introduce un estímulo x(p), x(p)=(x1, x2,.., xn). Si hay un conjunto de entrenamiento que tiene m ejemplos, el aprendizaje consistiría en ajustar los pesos w i de tal forma que el error cometido con todos los ejemplos sea el menor posible en su conjunto. Esto lleva a evaluar el error global como el error cuadrático medio. En concreto, los pasos que sigue la neurona ADALINE para aprender, son: 1. Inicialización aleatoria de pesos 2. Estímulo con un ejemplo o patrón de entrada 3. Cálculo de la salida (y) y comparación con la deseada (d): (dp-yp) 4. Para todos los pesos multiplicar esa diferencia por la entrada correspondiente y ponderarla con la tasa de aprendizaje h 5. Modificar el peso añadiendo al antiguo la cantidad obtenida en el paso 4

60 60 6. Si se ha convergido, acabar y si hay más ejemplos seguir. Si se han acabado los ejemplos y no se ha llegado a converger, empezar de nuevo a introducirlos. Diferencias entre la neurona Perceptrón y la ADALINE: o La salida del perceptrón es binaria y la del ADALINE es real o En el perceptrón se modifican los pesos cuando la salida de la red y la esperada son de clases diferentes. En el ADALINE siempre se modifican los pesos mediante la diferencia real entre salida esperada y real o En el ADALINE existe una medida de cuánto se ha equivocado la neurona. En el perceptrón sólo se determina si se ha equivocado o no o En el ADALINE hay una tasa de aprendizaje. En el perceptrón tiene siempre valor 0 ó 1. ADALINE como Perceptrón: Debido a las diferencias arriba mencionadas, se pensó en adaptar las ventajas de la neurona ADALINE al perceptrón. Si η=1 la expresión del cambio de pesos de la regla Delta se convierte en la regla de aprendizaje del perceptrón para la ADALINE con función de activación escalón 1 a 1. Así que sin pérdida de generalidad podríamos introducir la regla DELTA en el aprendizaje del perceptrón, es decir, en el cambio de sus pesos. Este tipo de neurona es el que se ha usado en el presente proyecto para modelar el tráfico de red capturado con el Ntop, descrito en el punto anterior, y de ahora en adelante se hará referencia a ella como perceptrón multicapa EL PERCEPTRÓN MULTICAPA El perceptrón multicapa es, como las anteriormente comentadas, una red neuronal artificial formada por múltiples capas. Esto, como a la neurona ADALINE,

61 61 le permite resolver problemas que no son linealmente separables, lo cual es la principal limitación del perceptrón (también llamado perceptrón simple). El perceptrón multicapa puede ser total o localmente conectado. En el primer caso cada salida de una neurona de la capa "i" es entrada de todas las neuronas de la capa "i+1", mientras que el segundo, cada neurona de la capa "i" es entrada de una serie de neuronas (región) de la capa "i+1". Las capas pueden clasificarse en tres tipos: Capa de entrada: Constituida ida por aquellas neuronas que introducen los patrones de entrada en la red. En estas neuronas no se produce procesamiento. Capas ocultas: Formada por aquellas neuronas cuyas entradas provienen de capas anteriores y las salidas pasan a neuronas de capas posteriores. Capa de salida: Neuronas cuyos valores de salida se corresponden con las salidas de toda la red. La propagación hacia atrás (también conocido como retropropagación del error o regla delta generalizada, o algoritmo de backpropagation), es el algoritmo supervisado utilizado normalmente en el entrenamiento de estas redes, y consiste en minimizar un error (comúnmente cuadrático) por medio de gradiente descendiente, por lo que la parte esencial del algoritmo es cálculo de las derivadas parciales de dicho error con respecto a los parámetros de la red neuronal. En resúmen, manera [ROJA96]: el algoritmo de retropropagación funciona de la siguiente 1. Calcular la salida de la red O (2) a partir de uno de los conjuntos de valores de prueba x. 2. Comparar con la salida correcta t y calcular el error según la fórmula: 3. Calcular las derivadas parciales del error con respecto a los pesos W (2) que unen la capa oculta con la de salida.

62 62 4. Calcular las derivadas parciales del error con respecto a los pesos W (1) que unen la capa de entrada con la oculta. 5. Ajustar los pesos de cada neurona para reducir el error. 6. Repetir el proceso varias veces por cada par de entradas-salidas de prueba ENTRENAMIENTO REALIZADO Llegados a este punto se va a explicar en detalle cómo se ha llevado a cabo el entrenamiento de la red neuronal, con qué datos, con qué parámetros, por qué se ha elegido cierta arquitectura y no otra y todo lo relativo a la misma CAPTURA DE DATOS La captura de datos se hizo en una red local pequeña (unos 5 ordenadores) con salida a Internet. Una vez instalado y arrancado el ntop (cosa que se explicará en sucesivos capítulos), se procedió a ejecutar un programa para descargar archivos.torrent, con el cual se descargaban archivos grandes sistemáticamente todos los días, desde las 15:00 horas hasta las 20:00 horas, esto es, un total de 5 horas, de lunes a viernes. Para, después del entrenamiento, poder diferenciar un tráfico anómalo de otro normal, a la hora de descargar se le impuso al programa un límite para la subida de datos de 5 kb/s y de 20 kb/s para la bajada. El ntop, por su parte, tiene configurado guardar la monitorización del tráfico de la red cada 2 minutos en los ficheros.rrd que crea para tal efecto, como se ha visto en el capítulo sobre él (4.2. Ntop). Esto se hizo durante 5 semanas, generando un total de 3750 valores para cada fichero.rrd. Como ya se ha visto, la cantidad de ficheros que crea el ntop es abrumadora, así que se eligieron los 6 siguientes para modelar y ser objetos del proyecto:

63 63 IP_BitTorrentBytes IP_BitTorrentFlows ethernetbytes ethernetpkts ipbytes icmpbytes Después de cada sesión de captura hay que procesar los datos, que en el fichero.rrd vienen con la forma : e+04. El preprocesado en cuestión consistía en transformar el primer valor, que están en milisegundos, a otros 2 valores, de forma que quedara e+04. El 3 corresponde al día de la semana, miércoles en este caso, y el 090 a la monitorización número 90 desde que se arrancase la sonda ntop. Teniendo en cuenta que se empezaba a monitorizar a las 15:00 horas y se hacía cada 2 minutos, ese 090 corresponde exactamente a las 18:00 horas en punto. Teniendo finalmente esos 6 archivos.txt con 3750 líneas cada uno, y cada una de ellas de la forma e+04, pasamos a la parte donde verdaderamente se entrena a la red neuronal. Para probar cómo funcionan las redes de cada uno de los tipos de datos, una vez entrenadas se procedió a alimentarlas con unos datos capturados de forma diferente a la de los del entrenamiento. En concreto se tomaron datos durante el mismo tiempo pero sólo de 1 semana, y con el mismo programa y el mismo tipo de fichero descargándose, sólo que esta vez no se impondría límite alguno a la bajada de datos, y la subida se quedaría en 20 kb/s en vez de en los exíguos 5 kb/s del entrenamiento. Esto aseguraba diferencias palpables de estos datos con los capturados la primera vez ENTRENAMIENTO DE LA RED NEURONAL Como se comentó en el apartado anterior, 4.3. Redes neuronales, el tipo de neurona utilizada será el perceptrón multicapa pero con las mejoras de la neurona ADALINE incorporadas.

64 64 En un principio, a parte del perceptrón multicapa, también se tuvo en cuenta la posibilidad de usar mapas de Kohonen para modelar los datos, aunque finalmente se desestimó debido a varias causas; entre otras ajustaba peor los datos, era más complicado ver y entender la información que producía el mapa, era mucho más laborioso pasarle grandes cantidades de ejemplos para validar el ajuste, y, por último, pero no por ello menos importante, el hecho de estudiarlo más a fondo e implementarlo no dejaba mucho tiempo para terminar el proyecto IDSRN dentro de las fechas exigidas. Una vez que queda el perceptrón multicapa como única opción se pasan a estudiar las posibles arquitecturas disponibles. En un principio se diseñaron neuronas con 3 entradas, correspondientes a los 3 valores que el preprocesado de datos dejaba en los ficheros.txt ( e+04 ), pero enseguida se cayó en la cuenta de que la salida de la red neuronal, si se quería algo del tipo si es tráfico anómalo, o no, no es tráfico anómalo, exigía capturar de nuevo 3750 datos (otras 5 semanas capturando datos), y además tenían que ser todos malos, por decirlo de alguna forma. Esto es así por que a la hora de entrenar un perceptrón multicapa se aconseja que la cantidad de ejemplos malos y buenos sea la misma. Considerando todo lo anterior se optó por que la salida fueran los propios kb, que se compararían con el valor de kb que había en la entrada y si fueran iguales (dentro de unos pequeños márgenes que luego se explicará cómo se ajustan) se da el dato por bueno, y por malo en caso contrario. Esto requería que, como se ha comentado, una de las 3 entradas de cada neurona fueran los kb, pero como no es aconsejable que la salida sea una de las entradas, se cogieron los kb del estímulo anterior. Esto aumenta la linealidad de los datos, que por otro lado ya es bastante fuerte al haberse capturado el tráfico de entrenamiento de una forma tan homogénea. Esto hace prácticamente imposible diferenciar un día de otro, es decir, un lunes de un jueves, por ejemplo, siendo el sistema capaz únicamente de saber si el tráfico que está observando en un momento dado es normal o anómalo. De todos modos, esta restricción es únicamente provocada por el entrenamiento elegido. En una red real de una empresa real, los datos capturados corresponderán al tráfico que normalmente se genere en la empresa, y se entrenará la

65 65 red según ellos, con todas las consecuencias. Así, si el tráfico es diferente de un día para otro, la red neuronal debe ser capaz de distinguir ese hecho también, ahora bien, si en la empresa el tráfico no varía en absoluto de un día para otro, el resultado del entrenamiento será el mismo que en el de este proyecto, pudiendo solamente diferenciar tráfico normal del anormal. Seguidamente se pasan a explicar los detalles de la arquitectura de la red neuronal para un caso ejemplo, en concreto para el archivo IP_BitTorrentBytes, que como se verá después, es el archivo que alimenta al SensorBB. Los detalles de la red de los demás archivos están en el anexo 1: Redes Neuronales RESULTADOS DEL ENTRENAMIENTO En este apartado se verán en detalle los pormenores del entrenamiento de la red neuronal para el sensor de BitTorrentBytes, esto es, para el futuro agente SensorBB. El entrenamiento se ha hecho con la herramienta Matlab, en su versión 7.1. Las primeras pruebas que se hicieron tuvieron en cuenta el uso de varias capas ocultas, pero el resultado era el mismo que con una capa de entrada y otra de salida. Esto está provocado por la fuerte relación lineal que tienen los datos y de la cual se habló en el punto inmediatamente anterior. En consecuencia se usa una capa de entrada y otra de salida para cada una de las redes de cada archivo (recordemos que cada archivo de los elegidos para ser estudiados tiene su propia red neuronal). Lo primero que llama la atención es el por qué del número de neuronas que tiene el SensorBB. Pero con un simple gráfico se responde a esa cuestión. En el siguiente eje de coordenadas tenemos en el eje y el error cuadrático medio, y en el x el número de neuronas de la capa de entrada:

66 66 Como se puede ver, con 2 neuronas ya se alcanza el mínimo error cuadrático medio. También se podrían usar 6 neuronas, pero se complicaría mucho la arquitectura para tener el mismo resultado. Una vez decidido el número de neuronas se pueden ver otros detalles, como por ejemplo la dispersión de datos en el conjunto de entrenamiento:

67 67 Cabe destacar que previamente se normaliza la columna de kb del fichero de datos que lee el código Matlab de la red neuronal que ajusta en este caso los bytes de BitTorrent. Junto con el histograma da una idea bastante precisa de cómo son los datos del entrenamiento: Con estos 2 gráficos se hace evidente la fuerte correlación lineal que hay entre los datos, en concreto entre el número de monitorización (que va de 1 a 150 durante las 5 horas de funcionamiento de ntop) y la cantidad de kb. Teniendo en cuenta cómo funcionan las redes de pares del protocolo torrent, parece lógico pensar que los datos están bien ajustados, ya que al principio de las 5 horas el flujo de información es lento, va creciendo, y llegado un punto el tráfico se estabiliza hasta que al cumplir las 5 horas se corta (manualmente y de golpe). Esa estabilidad queda reflejada en la gran concentración de datos que se observa. Otro de los detalles que se desprenden de estas figuras, en concreto del histograma, es la calidad del ajuste del conjunto de entrenamiento, que, como se ve,

68 68 la inmensa mayoría de los resultados no se diferencian de su propia entrada, aceptando un margen de +/- 0.1 (recordar que los valores están normalizados). El siguiente paso es pasar unos datos de validación que introduzcan anomalías, para ver cómo se comporta la red neuronal. Estos datos se tomaron de la forma que se describe en el apartado Captura de datos, y en resumidas cuentas consistía en, durante una semana, proceder a capturar datos de la misma forma que los del entrenamiento pero sin imponer límites de descarga al programa torrent y de 20 kb/s para la subida. Así se se ven claramente las diferencias con el conjunto de entrenamiento: Se ve perfectamente cómo la red ha dado como buenos los datos que forman el grupo de abajo, y como malos los que forman el grupo de arriba. También se diferencian en el histograma:

69 69 Precisamente con este histograma es con el que se ajusta el margen de bondad que va a tener el SensorBB en este caso. Para el desarrollo de este proyecto, se ha establecido que los márgenes, en el caso de los bytes de Bittorrent sean de -0.2 y de +0.4, valores que engloban a buena parte de los datos de validación. En el gráfico anterior, el de dispersión, podemos ver dibujadas las rectas -0.2 y 0.4, para hacernos una idea de la cantidad de datos que se quedan fuera o dentro del margen establecido. La calidad de la respuesta del SensorBB es bastante alta. En concreto, de los datos de validación, acierta alrededor de un 68% de las veces. Ese porcentaje se obtiene al dividir el número de fallos que ha visto, 134 en este caso concreto, entre el número de fallos total que hay de entre los 750 datos de validación, es decir, 198. Como dato malo se ha tomado cualquier valor de kb que superase los 55 kb/s, ya que es un valor que apenas se alcanza unas pocas veces de entre los 3750 datos del entrenamiento. Una vez terminado el proceso de entrenamiento y validación, hay que extraer de Matlab los pesos de los estímulos de cada una de las neuronas, a parte de sus valores de bias. Todos estos valores son los que multiplican a las entradas, e+04. La información del ajuste del resto de sensores se expone en el anexo 1: Redes Neuronales.

70 70 5. DESCRIPCIÓN FUNCIONAL En este capítulo se aborda la descripción funcional del proyecto IDSRN, con la enumeración y detalle de cada una de las clases que componen la aplicación, sus dependencias y la forma en que interactúan entre sí. La representación de las clases se ha realizado según el estándar UML 2.0, obviándose los siguientes conceptos, en pos de la simplificación de la representación (debido a su redundancia y funcionamiento autoexplicativo): Métodos constructores: Métodos propios de la clase cuya misión es la instanciación de objetos de la clase. Su lógica de programación se basa en inicializar los atributos básicos de la clase según los parámetros de llamada del método. No hay un número fijo de constructores y difieren entre sí en la forma de inicializar los atributos y en los parámetros con que se invocan. Métodos "getters": Métodos públicos de la clase (y por tanto invocables desde otras clases) que permiten leer el valor de sus atributos privados. Cada método "getter" está asociado a un único atributo. No tienen parámetros y devuelven una variable del mismo tipo que el atributo asociado. Métodos "setters": Métodos públicos de la clase (y por tanto invocables desde otras clases) que permiten escribir el valor de sus atributos privados. Cada método "setter" está asociado a un único atributo. Tienen como único parámetro una variable del mismo tipo que el atributo asociado. En los siguientes apartados se describirán por este orden, las clases que forman parte de cada uno de los paquetes en que se estructura el proyecto: dominio, agentes, comportamientos, interfaz de usuario y clases de acceso a datos y de cálculo. Para una visión global del diseño del sistema desde el punto de vista de la programación, ver el apartado 5.4. Diagrama de clases, donde en gran formato se representan cada una de las clases que se van a comentar DOMINIO DEL SISTEMA Se considera parte del dominio del sistema a todo concepto real que se modeliza en el sistema para manejarlo como una unidad de información.

71 DIAGRAMA DE DOMINIO El siguiente diagrama muestra la relación cardinal entre los conceptos que maneja el sistema y que se detallarán a continuación: DEFINICIÓN DE CONCEPTOS ALERTA Unidad de resultado básica del presente proyecto. Es el resultado de pasar el último valor de la monitorización del Ntop por el perceptrón que tiene implementado cada sensor, y que esta sea clasificada como mala. El Ntop monitoriza la red constantemente, volcando, como ya se ha dicho, la información que recoge en unos ficheros con formato.rrd. Esto lo hace cada 2 minutos. Posteriormente, con la herramienta rrdtool, se extrae ese último dato del fichero.rrd, resultando un archivo de texto (.txt) con una línea del tipo e+04, donde el primer valor es el tiempo UTC expresado en milisegundos transcurridos desde el 1 de Enero de 1970, fecha del nacimiento del SO Unix, y el segundo valor son los KB (o paquetes, según el archivo que estemos procesando) en ese preciso instante. Ese primer valor se convertirá en otros 2, quedarán entonces los datos de la forma e+04, que son el día de la seman, el número de minuto (cada 2 minutos de entre 5 horas), y los KB, que permanecen inalterados. Son precisamente las 3 entradas de cada neurona.

72 72 Estos valores entrarán como estímulos a la red neuronal implantada en cada sensor, que previamente ha sido entrenada con un conjunto de datos de entrenamiento, y el resultado se comparará con el valor de entrada, dándolo como bueno si la diferencia entre ellos está dentro de unos márgenes, o como mala si no lo está, generando una alerta. Desde el punto de vista de la programación, el concepto alerta es un simple contador (concretamente la variable contador1), que acumulará las alertas y provocará la aparición de una anomalía si es preciso, dependiendo del valor del mismo ANOMALÍA Una anomalía es un conjunto de alertas. En este proyecto en cuestión se ha decidido que el sistema identifique una anomalía si se producen 4 alertas en una ventana de 5 monitorizaciones sucesivas. En concreto, si estamos monitorizando cada 2 minutos, habrá una anomalía si en 10 minutos hay alertas durante 8. Todo eso es configurable, evidentemente. Se pueden modificar los sensores y el Ntop para tener más resolución a la hora de ver qué pasa en la red, o menos, según se desee, ya que a más resolución más consumo de recursos, tanto de red, como de procesador, como, sobretodo, de disco. También es posible variar la configuración del número de alertas que es necesario acumular para hacer saltar un mensaje de anomalía. Así podemos tener un sistema muy intransigente con las variaciones del tráfico en nuestra red, dando alarmas continuamente, o uno más relajado, con los consiguientes peligros tanto de una opción, como de la otra. Ajustar tanto la resolución de la monitorización, como la flexibilidad o inflexibilidad del sistema es absolutamente crítico, y variará de una situación a otra, exigiendo un análisis antes de calibrar esos valores.

73 73 Cuando un sensor acumula el suficiente número de alertas genera un mensaje ACL, descrito en el punto que desgrana la tecnología JAVA JADE, y se lo mandará al agente Intérprete, encargado de avisar, finalmente, al administrador de la red AVISO El concepto aviso es el último eslabón en la cadena de sucesos que componen el sistema. Cuando el agente intérprete recibe un mensaje ACL de anomalía proveniente de uno o varios de los sensores activos, se limita a imprimir por pantalla el hecho de que existe una anomalía, de qué sensor viene y a qué hora exacta se recibió. Este agente intérprete lleva implementado un sistema de prioridad de mensajes de anomalías. Así, en el caso de que lleguen 2 mensajes juntos, el que se anuncia es el que más prioridad o importancia tiene (este punto también es configurable, en cada situación puede ser deseable una cosa u otra). Por ejemplo, si estamos monitorizando el tráfico ethernet y el icmp, podemos conceder más importancia a las anomalías que se observen en el protocolo icmp, si lo que queremos es darnos cuenta de un aumento significativo de comandos ping o traceroute entre otros, ya que alguien puede estar intentando aprender cómo es nuestra red, antes que de algún usuario que esté descargando un archivo grande.

74 AGENTES DEL SISTEMA A continuación se detallan las funcionalidades y responsabilidades de cada uno de los agentes que integran el sistema IDSRN, elementos del dominio sobre los que trabajan y comportamientos que implementan. Todos los agentes del sistema son agentes JADE, de modo que por omisión en sus apartados correspondientes, heredan de la clase Agent cuyo esquema es el siguiente: Donde: setup(): Método que se dispara al arrancar el agente. takedown(): Método que se dispara al matar el agente. Estos métodos son generalmente sobrescritos por los agentes hijos para introducir su propia funcionalidad a los mismos (en la implementación de la clase Agent, no hacen nada) AGENTE SENSOR DESCRIPCIÓN El agente sensor es una clase abstracta de la que heredan los agentes de cada tipo de dato. Su misión no es más que inicializar 3 variables, que son contadores, con sus respectivos getters.

75 ATRIBUTOS contador0: es el contador que acumula los aciertos a la hora de procesar un dato con la red neuronal (ver Definición de Conceptos). contador1: es el contador que acumula los fallos, a la postre alertas, que resultan del proceso de la red neuronal (ver Definición de Conceptos). m: es el contador de los minutos, que es uno de los estímulos de la red neuronal. Este aumenta cada 2 minutos, hasta 150, esto es 5 horas completas, que es como se ha entrenado a la red. Para variar este dato habría que entrenar de nuevo a la red neuronal capturando datos diferentes a los usados en el entrenamiento MÉTODOS Ninguno de relevancia a parte de los heredados AGENTES SENSORES DE DATOS DESCRIPCIÓN En este apartado se explicará uno de los sensores de datos, esto es, un sensor que lee los datos y los procesa con la red neuronal basada en perceptrones multicapa que implementa.

76 76 Seguidamente, según el resultado que haya dado la red neuronal, y según una condición, se catalogará el resultado como bueno, no realizando ninguna acción, o como malo, aumentando la variable contador1 y enviando un mensaje de anomalía al agente intérprete si procede. Se explicará sólo un tipo de sensor, ya que todos son exactamente iguales, excepto en la arquitectura de la red neuronal, pero a nivel estructural el código es el mismo. También sobra decir que esta clase hereda de la clase abstracta Sensor, recuperando los valores de contador1, contador0 y m ATRIBUTOS milis: milisegundos desde el 1 de Enero de Con este valor se hará el cálculo para obtener el valor d, que representa el día de la semana, del 1 al 5, y que es uno de los estímulos de la red neuronal, a parte de m y de kb. kb: es el tercer estímulo de la red neuronal, representa los KB/s, o paquetes/s, dependiendo del tipo de datos a los que esté accediendo el sensor. kbn: es el mismo dato que kb, pero normalizado, ya que este valor es el que realmente entra en la red neuronal. v1: es el estímulo de entrada de la primera neurona de la capa de entrada

77 77 v2: es el estímulo de entrada de la segunda neurona de la capa de entrada v3: es el estímulo de entrada de la neurona de la capa de salida y1: es el resultado de la primera neurona de la capa de entrada y2: es el resultado de la segunda neurona de la capa de entrada y3: es el resultado de la neurona de la capa de salida, y, por ende, el resultado final de la red neuronal. Este es el resultado que se da por bueno o malo, dependiendo de unos márgenes establecidos en el entrenamiento de la red neuronal Cabe reseñar que las variables v1, v2, v3, y1, y2 e y3 son válidas para una red que tenga 3 neuronas, 2 de entrada, y una de salida. En el momento en el que la arquitectura de la red sea distinta, la cantidad de variables de este tipo también lo será. Así por ejemplo, si tuviéramos 3 neuronas de entrada, y una de salida, 4 en total, habría que añadir las variables v4 e y MÉTODOS Ninguno de relevancia a parte de los heredados AGENTE INTÉRPRETE DESCRIPCIÓN Este agente se limita a recibir los mensaje ACL que van mandando los diferentes sensores. La poca funcionalidad que tiene se limita a extraer el contenido del mensaje, que es una cadena de texto, y almacenarla en la variable mens. A su vez sacará un mensaje por pantalla compuesto del

78 78 contenido de mens, más la hora del sistema en ese momento, esto es, avisará al administrador de que se está produciendo una anomalía en la red ATRIBUTOS mens: variable de tipo cadena que guarda el contenido del mensaje ACL enviado por un sensor MÉTODOS Ninguno de relevancia a parte de los heredados AGENTE PROCESADOR DESCRIPCIÓN Este agente lo único que hace es, cada 2 minutos, como los agentes sensores, lanzar una instancia de cygwin, que está ya preparado para lanzar el script que preprocesa los datos.

79 ATRIBUTOS cmd: variable de tipo cadena que guarda la ruta del ejecutable y los parámetros que necesite proceso: variable de tipo Process, necesaria para que Java lance aplicaciones externas a través de las librerías Java.lang.Runtime MÉTODOS Ninguno de relevancia a parte de los heredados COMPORTAMIENTOS A continuación se detallan las funcionalidades y responsabilidades de cada uno de los comportamientos que implementan los agentes que integran el sistema. Todos los comportamientos del sistema son instancias de clases JADE, más concretamente de los comportamientos Periódico y Simple que se pasan a detallar a continuación PERIÓDICO Comportamiento JADE que ejecuta periódicamente su método principal según el periodo introducido como parámetro de su constructor. El comportamiento Periódico se representa en el sistema con la clase TickerBehaviour, que tiene la estructura resumida siguiente: Este comportamiento es el que implementan los sensores.

80 ATRIBUTOS Ninguno relevante para este proyecto MÉTODOS El método más relevante implementado en la clase TickerBehaviour es el siguiente: ontick(): Método principal que se ejecuta periódicamente según el periodo especificado en el constructor de la clase. Este método es sobrescrito por los agentes hijos para introducir su propia funcionalidad SIMPLE Comportamiento JADE atómico, hace una única tarea que no se puede interrumpir. El comportamiento Simple se representa en el sistema con la clase SimpleBehaviour, que tiene la estructura resumida siguiente: Este comportamiento es el que implementa el agente Intérprete.

81 ATRIBUTOS Ninguno relevante para este proyecto MÉTODOS El método más relevante implementado en la clase SimpleBehaviour es el siguiente: reset(): Método principal reinicia continuamente el comportamiento en cuestión. Este método es sobrescrito por los agentes hijos para introducir su propia funcionalidad.

82 DIAGRAMA DE CLASES Se presenta a continuación el diagrama de clases completo:

83 83 6. ARQUITECTURA DEL SISTEMA En este capítulo se aborda la arquitectura del sistema desarrollado, y por tanto la implantación de las clases y conceptos anteriormente descritos en una estructura global. En el diseño de la arquitectura en capas de agentes inteligentes JADE y del modelo de comportamientos en el sistema, se aplican los conocimientos adquiridos sobre la configuración e implantación de las sondas Ntop en la red y seguridad informática necesarios para la realización del proyecto ARQUITECTURA JAVA JADE MULTIAGENTE Al abordar el presente proyecto se planteó un problema de base: la inexperiencia del desarrollador en el diseño de sistemas distribuidos y el desconocimiento del paradigma de los agentes inteligentes, por lo que se optó por la tecnología más en boga en estos momentos sobre el tema: JADE. El middleware JADE proporciona una capa estable sobre la que desarrollar aplicaciones distribuidas que oculta al desarrollador la complejidad de las capas inferiores. Este proyecto pretende ser un Sistema de Detección de Intrusos distribuido, fiable, escalable y fácilmente adaptable a las nuevas amenazas que puedan surgir en redes de ordenadores. JADE permite componer un sistema distribuido a través del desarrollo de entidades software autónomas y colaborativas en pos de alcanzar un objetivo común, por lo que es la base ideal para alcanzar estos fines. JADE proporciona facilidades en cuanto a la coordinación de agentes, seguridad, comunicación, movilidad, redundancia, y muchos otros servicios básicos en una arquitectura distribuida. Todo ello sobre un lenguaje cuyas virtudes son de sobra conocidas como Java. Su carácter abierto (open-source) permite el desarrollo de aplicaciones sobre esta tecnología sin coste alguno y la flexibilidad del código lo hace verdaderamente atractivo. La potencia de JADE estimula a su vez la aparición de nuevas ideas que permiten ampliar la funcionalidad de un sistema en las diferentes fases del desarrollo. Por otra parte, la tecnología Java simplifica la extensión de funcionalidades y la incorporación de nuevas

84 84 características a anteriores versiones de un producto software. Al optar por estas tecnologías de desarrollo se garantiza que el resultado no será un software estático y caduco en el tiempo, sino que será fácilmente actualizable y podrá incorporar los avances y funcionalidades necesarias para mantenerse al día durante un largo periodo de mantenimiento ARQUITECTURA DEL SISTEMA DESARROLLADO la sonsa Ntop. Este sistema es una distribución a medida, basada en agentes inteligentes JADE y en Como se ha descrito en el apartado 3.1: Sistemas de Detección de Intrusos, un IDS es un sistema muy delicado que no se puede permitir la pérdida de información en situaciones críticas y por tanto al tener que garantizarle un mínimo de recursos computacionales se recomienda instalar en máquinas dedicadas. Esto implica que en general, no se instalen en la misma máquina pesadas interfaces gráficas u otros módulos que puedan interferir con el Sistema de Detección de Intrusos. En estos casos, se suele disponer de máquinas de monitorización remotas donde mostrar los resultados, aunque en este sistema en concreto no es tan crítico como normalmente es (aunque también depende del número de sensores activos en la misma máquina), ya que no es necesaria ninguna interfaz gráfica para el proyecto, si no que los resultados se muestran por pantalla en un intérprete de comandos. Los productos básicos que devuelve un IDS a la persona encargada de su supervisión son las alertas, que como ya se ha dicho se presentan en pantalla, y tienen el siguiente aspecto: Anomalia BB Wed Aug 27 19:33:57 CEST 2008 La primera parte, Anomalía BB, indica el tipo de anomalía que se ha producido, y por consiguiente, el sensor que la ha lanzado. En este caso tenemos una cantidad anómala de bytes de BitTorrent en la fecha indicada en la segunda parte del aviso.

85 85 El análisis en tiempo real del estado del tráfico de una red por parte de un humano es prácticamente imposible y requeriría de una dedicación completa. La persona encargada de supervisar los avisos de este IDS debería limitarse a atender en tiempo real las situaciones verdaderamente críticas dejando para una posterior revisión las menos importantes. Pero, cuándo se da una situación crítica?, cómo un analista puede darse cuenta de la criticidad de una situación y de lo que realmente está ocurriendo en la red si de lo único que dispone es de líneas y líneas de alertas inconexas?. Evidentemente se hace necesario un análisis asistido por ordenador sobre esa cantidad de información que aporte al administrador de red una visión general de la situación de la red en cada momento y un sistema de navegación más exhaustivo que le aporte mayor detalle en los puntos en que estime necesario. Estas funcionalidades tan avanzadas restan capacidad computacional si se ejecutan en la misma máquina en la que corre un IDS lo cual no es deseable, como antes se ha descrito. El sistema descrito pretende dar una solución a este problema. Aunque como se ha comentado la interfaz que informa al administrador no es pesada computacionalmente hablando (repetimos que también hay que tener en cuenta el número de sensores activos en una misma máquina), siempre es interesante que, mediante una arquitectura distribuida basada en agentes inteligentes se puedan repartir los módulos de los sensores IDS y del Intérprete de una forma estructurada, escalable y funcional, sin mencionar el hecho de que las máquinas donde se instale el sistema no tienen por qué tener un acceso cómodo MODELO DE ARQUITECTURA EN CAPAS La distribución de las funcionalidades de un IDS se realiza generalmente en una arquitectura distribuida basada en capas con diferentes funcionalidades a distinto nivel. En los modelos basados en capas (como por ejemplo el conocido modelo de red OSI), cada capa se alimenta de los productos de la capa inferior, aportar una funcionalidad más general o especializada y devuelve sus resultados a la capa superior. Un típico modelo IDS distribuido basado en capas se compone de 3 niveles bien diferenciados [KOZI03]:

86 86 Donde se distinguen las siguientes capas: Capa Sensor: Encargada de la captura del tráfico de red y generación de alertas. Capa Analista: Encargada del análisis de las alertas. Capa Supervisor: Encargada de la presentación visual de los análisis y la visión general del sistema al supervisor de la red. Esta sencilla división de responsabilidades en capas es la base de todas las arquitecturas distribuidas de IDS y en particular del presente sistema MODELO DE ARQUITECTURA DEL SISTEMA DESARROLLADO El modelo distribuido del sistema es un modelo de arquitectura en capas basado en agentes inteligentes. Cada uno de los niveles de la arquitectura está representado por una serie de agentes inteligentes con funcionalidades similares que se disponen en una estructura de capas, sirviendo los pertenecientes a una capa inferior a los de las capas superiores. La ventaja del uso de agentes inteligentes para la implantación de los elementos que forman cada capa, es sin duda la escalabilidad del sistema y la capacidad de especialización que permite aportar cada agente. De esta manera el

87 87 modelo de capas de este proyecto, cambia ligeramente respecto al esquema por defecto, haciéndose un poco más simple: La función de cada capa es la siguiente: Capa Sonda: es la encargada de capturar el tráfico de red y almacenarlo en los ficheros con formado rrd. Esta capa la compone exclusivamente la sonda Ntop (ver capítulo 4.2. Ntop). Es recomendable instalar una sonda en cada segmento de la red, especialmente en aquellos que sean críticos, tales como los que tengan conectados servidores o máquinas importantes de la organización. Capa Sensor: el cometido de esta capa es determinar si el valor que deja el Ntop cada 2 minutos es válido o no, creando una alerta en este último caso. Como ya se ha comentado (ver capítulo Agentes Sensores de Datos), el dato entra en el sensor con la forma e+04 y se transforma en e+04 que no son otra cosa que los tres estímulos que le llega a cada neurona. Estos estímulos, multiplicados por los pesos (que se obtienen en el entrenamiento de la red con Matlab, ver anexo 1 - Red Neuronal) darán un valor, que se mete en una función de activación (lineal, o tanh, según el sensor, esto se obtiene también del entrenamiento de la red neuronal) y da un valor que a su vez es el estímulo de entrada de la neurona de la capa de salida, con sus pesos y su función de activación, igual que las neuronas de la capa de entrada.

88 88 Este último valor será el que se compare con el valor real que estimuló la red neuronal, y, si es igual, dentro unos márgenes (obtenidos de nuevo en el entrenamiento con Matlab), será dando por bueno y no se realizará ninguna acción. En el caso contrario, la variable contador1 (ver capítulo Agente Sensor) aumentará en 1 unidad. Si este contador llega a sumar 4, de cada 5 valores monitorizados, la capa sensor generará automáticamente un mensaje de anomalía para la capa intérprete. Los agentes de esta capa pueden existir en cualquier número, si bien más de 1 del mismo tipo en la misma máquina es redundante. Destacar también que para que esta capa funcione, ha de estar en una máquina que también tenga la capa Sonda. Capa Intérprete: Es la última capa, y simplemente se encarga de recibir los mensajes de anomalía de los sensores y mostrarlos por pantalla para que el administrador los vea y actúe según crea conveniente. En el caso de llegar más de 1 mensaje de anomalía de sensores distintos, entrará en acción un sencillo algoritmo de prioridades, que nos mostrará primero la anomalía del sensor que creamos que es más crítico MODELOS DE COMPORTAMIENTOS El funcionamiento de la arquitectura del proyecto está regido por los comportamientos que incorporan los agentes que componen cada una de las capas del sistema. Los agentes que forman el sistema implementan, en su totalidad, comportamientos simples y periódicos que no terminan mientras los agentes estén vivos. Esto debe ser así porque mientras el Ntop esté arrancado, puede estar monitorizando un tráfico anormal en cualquier momento y los agentes activos del sistema deben reaccionar inmediatamente ante cualquier tipo de evento.

89 89 7. DISTRIBUCIÓN DEL PROYECTO El proyecto se distribuye en soporte electrónico y consiste en dos partes: Carpeta de proyecto IDSRN con todos los archivos necesarios para el arranque de la plataforma de agentes inteligentes. Carpeta de instalables INSTALACION IDSRN con todos los recursos (programas externos) necesarios para la implantación de la plataforma de agentes CARPETA DE PROYECTO IDSRN La carpeta de proyecto IDSRN es el producto del equipo de desarrollo del proyecto IDSRN, y dispone todos los archivos necesarios para el arranque de la plataforma de agentes inteligentes y su mantenimiento: Donde: MTPs-Main-Container.txt y APDescription.txt: Ficheros propios de la ejecución del entorno de desarrollo JADE.

90 90 arranqueinterprete.bat y arranquesensor.bat: scripts para automatizar el arranque de la plataforma Jade con los agentes desarrollados. runjade.bat y compila.bat: scripts para compilar y ejecutar el código de los agentes por separado. bin: carpeta que contiene los archivos.java y.class del desarrollo. datos: carpeta que contiene datos de ejemplo para ver cómo funciona el sistema. doc: aquí está la documentación, los anexos y los ficheros.m de matlab para entrenar la red neuronal. lib: librerías necesarias para el funcionamiento del sistema de agentes distribuidos Jade CARPETA DE PROGRAMAS E INSTALABLES INSTALACIÓN IDSRN La carpeta de instalables INSTALACION IDSRN contiene una recopilación de recursos (programas externos) necesarios para la implantación de una plataforma de agentes IDSRN. Todos los productos que se proporcionan en esta compilación son de libre distribución o pueden obtenerse de forma gratuita por lo que no se viola ninguna ley de derechos de autor o similares:

91 91 Donde: Jade: carpeta que contiene la plataforma Jade, con sus librerías, su documentación, sus ejemplos cygwin.exe: programa para el SO Windows que emula un terminal Linux. Es necesario para el correcto funcionamiento del programa rrdtool y los scripts que necesita para sacar la información de los ficheros.rrd que deja el Ntop. jdk-6u7-windows-i586-p.exe: última version del Java Development Kit. NTop_XTRA_3_18_0.exe: distribución del Ntop para Windows. rrdtool cygwin zip: comprimido que contiene el programa rrdtool. Si nos fijamos en el nombre, figura la versión del mismo, y la versión mínima de cygwin que necesita para funcionar. extraerdatos: script que recoge el último valor de los ficheros rrdtool usados por el sistema como ejemplo.

92 92 8. PLANIFICACIÓN Y PRESUPUESTO DEL PROYECTO En el presente capítulo se hace referencia a la planificación del proyecto: las etapas de su desarrollo y diferentes actividades llevadas a cabo en cada una de las mismas por los miembros de su organización ORGANIZACIÓN DEL PROYECTO Donde las tareas y responsabilidades principales de cada uno de los grupos que forman la organización del proyecto a lo largo de la realización del mismo se presentan a continuación: Coordinador: o Explicar la Normativa de Proyectos Fin de carrera y facilitar la información pertinente a lo largo de su desarrollo. o Concretar la definición del proyecto y los objetivos. o Controlar y supervisar el trabajo en sesiones de presentación pública de los avances realizados. o Evaluar el producto final. o Calificar al alumno en calidad de profesor de la asignatura Proyecto Fin de Carrera.

93 93 Directores: o Proponer un proyecto de calidad y establecer las líneas y los criterios de verificación de los resultados de forma práctica. o Facilitar al alumno las orientaciones adecuadas ante los problemas que vayan surgiendo en el desarrollo del proyecto. o Supervisar la realización del proyecto, la calidad de sus contenidos, y que se desarrolla de acuerdo con la Normativa de Proyectos Fin de carrera. o Dar su opinión al Coordinador sobre el alumno y el trabajo realizado. Equipo de trabajo: o Asistir a las sesiones de control del proyecto tanto a las propuestas por los Directores del proyecto como las programadas por el Coordinador. o Determinar el alcance del proyecto y la planificación del mismo, que deben ser validadas por los Directores del proyecto. o Realizar la adquisición de información para la realización del proyecto. Esto incluye tanto la investigación y formación autónoma sobre los temas que trata el proyecto, como la obtención del conocimiento necesario para llevar a cabo los objetivos del mismo. o Realizar el diseño del aplicativo. Esto implica la elección, diseño y documentación de la arquitectura a montar. o Realizar la programación del software. Esto implica la codificación del diseño sobre el lenguaje elegido y las pruebas pertinentes. o Llevar a cabo la documentación y presentación del producto y de cada uno de los prototipos a los Directores y Coordinador del proyecto METODOLOGÍA Y RECURSOS El alcance del proyecto impone como software base sobre el que desarrollar el aplicativo la sonda Ntop y sus ficheros.rrd. Del mismo modo, se propone como solución para la arquitectura distribuida sobre la que desplegar el sistema, la tecnología de agentes inteligentes JADE. El desconocimiento sobre estos temas por parte del equipo de trabajo al comenzar el proyecto impide que su desarrollo se realice mediante una metodología lineal, ya que a medida que se avanza en él se irán descubriendo nuevas funcionalidades y

94 94 surgiendo nuevas ideas a incorporar al resultado. Por estas razones, el proyecto se realizará mediante una metodología espiral. En el apartado 10.3: Planificación de tareas, se representará la metodología del proyecto junto con las actividades a realizar en cada etapa. El objetivo del proyecto, que impone la implantación del mismo en una red real, hace escoger como sistema operativo el entorno Windows, tanto para el desarrollo como para la puesta en marcha del aplicativo, por ser el más utilizado en la actualidad. El software base del proyecto implica que el desarrollo se realice en lenguaje Java, ya que el middleware JADE está construido sobre esta tecnología. Al no presentarse especificaciones hardware concretas, se considerará la implantación del producto en equipos PC ordinarios (CPU 2 GHz y Memoria 1 GB), por lo que el desarrollo se llevará a cabo también en máquinas de estas características. Tal y como se especifica en el alcance del proyecto, tanto el software de desarrollo como el base sobre el que se implantará el sistema debe ser gratuito y de libre distribución, lo que condiciona en gran manera los recursos software de los que disponer: Software base (para Windows): o Sonda Ntop o Máquina virtual Java (JVM) o rrdtool o cygwin o Middleware Jade Software de desarrollo (en máquina con Windows XP): o Kit de Desarrollo Java (JDK 6u7) o Entorno de desarrollo notepad++ o Herramienta de documentación MS Word y PowerPoint (MS Office 2007) o Matlab 7.1 Software de pruebas (para Windows) o Sirve cualquier programa o método para enviar y recibir información entre 2 o más equipos, que se monitorizará o se usará para entrenar la red neuronal

95 95 siguientes: Los recursos hardware que se requieren para la realización del proyecto son los Hardware de desarrollo y pruebas: o PC sobremesa para desarrollo y pruebas y necesario para la distribución del sistema en varias máquinas (Intel Core 2 Duo 6300, 1 8 GHz, 2 GB RAM). Incluye Windows XP. o PC portátil para pruebas (Pentium Centrino 1.7 GHz, 1 GB RAM). Incluye Windows XP. o Hub y cableado de red para pruebas PLANIFICACIÓN DE TAREAS En este apartado se presenta la planificación de las fases en que se divide el desarrollo del sistema. Debido a la metodología en espiral en la que se ha llevado a cabo el proyecto, cada una de las etapas del desarrollo repasa el resultado de las anteriores, a las que se van incorporando las nuevas funcionalidades. El proyecto dió comienzo en octubre de 2007 y termina en septiembre de Tras la revisión de la planificación inicial de tareas, en la que se preveía el final del proyecto para junio de 2008 y que mostraba una ejecución lineal de actividades que resultó inviable en las fases de la programación, sumado a que el equipo de trabajo tenía una jornada laboral de 8 horas hasta marzo de 2008, se opta por la metodología en espiral y posponer el final del proyecto. Debido principalmente al empleo remunerado del equipo de trabajo hasta marzo, como se ha dicho, se avanzó en el desarrollo del sistema de una forma bastante más pausada que a partir de entonces. El siguiente esquema muestra las actividades llevadas a cabo: a. Estudio de principios de seguridad en las redes de computadores b. Estudio de sistemas de detección de intrusos (IDS) c. Familiarización con el entorno de la sonda Ntop d. Captura de datos para su posterior uso en redes neuronales

96 96 e. Estudio del perceptrón multicapa, los mapas de Kohonen y las redes neuronales y entrenamiento con los datos capturados f. Estudio de la arquitectura Jade multiagente g. Captura de más datos para validar los entrenamientos hechos con los distintos tipos de redes neuronales h. Ajuste del mapa de Kohonen i. Presentación intermedia al coordinador del proyecto j. Ajuste del perceptrón multicapa y elección del mismo como base del sistema k. Presentación intermedia al coordinador del proyecto l. Desarrollo y pruebas del código del sistema IDSRN m. Documentación del sistema IDSRN n. Presentación final del proyecto La ubicación temporal de las actividades enumeradas anteriormente, no es estricta en el periodo de desarrollo del proyecto, por lo que la realización de éstas se planifica aproximadamente según el siguiente diagrama:

97 PRESUPUESTO Debido al punto del apartado 2. Alcance del proyecto, que determina que tanto el software base del proyecto como las herramientas de desarrollo utilizadas sean gratuitas y de libre distribución, el coste del proyecto es nulo en ese aspecto. No obstante en las fases de desarrollo e implantación de entornos de pruebas del sistema hay que tener en cuenta los siguientes gastos: Materiales: Hardware de desarrollo y pruebas. o PC sobremesa necesario para el desarrollo, pruebas y distribución del sistema en varias máquinas (Intel Core 2 Duo 6300, 1 8 GHz, 2 GB RAM). Incluye Windows XP: o PC portátil para desarrollo y pruebas (Pentium Centrino 1.7 GHz, 1 GB RAM): 500. o Concentrador y cableado de red para pruebas: 50. Recursos humanos: Mano de obra y otros costes (incluidos en cuota laboral). Estimación de esfuerzo, tiempo en horas (Dir1 = Mario Castro; Dir2 = Miguel Ángel Sanz): El equipo de trabajo, formado como ya hemos dicho por una única persona, hace las veces de analista y/o de programador, según requiera la situación.

98 98 Estimación del coste, en euros (Dir1 = Mario Castro; Dir2 = Miguel Ángel Sanz): Coste total del proyecto: Materiales: Recursos Humanos: = COSTE TOTAL:

99 99 9. CONCLUSIONES Al término del proyecto, en septiembre de 2008, se han llegado a las siguientes conclusiones referentes a las diferentes cuestiones que han ido surgiendo a lo largo del mismo: Respecto a la definición del proyecto, los objetivos del mismo estuvieron claros desde el principio, pero el modo de llevarlos a cabo y el alcance no quedaron determinados hasta bien entrado el proceso de desarrollo. Por otra parte, el entrenamiento inicial de los datos no cumplía los requisitos del proyecto, por lo que tuvo que ser rehecho a medida que se iba capturando nuevos datos y analizando diferentes arquitecturas de redes neuronales. Esto significó tener que desechar la planificación lineal realizada inicialmente para dar lugar a la planificación en espiral basada en prototipos de la que se ha hablado en apartados anteriores. Como ya se ha explicado, las fases iniciales de captura de datos y análisis de las diferentes técnicas de inteligencia artificial, se alargaron mucho en el tiempo, y esto, sumado a la poca disponibilidad del equipo de trabajo hasta el mes de abril, propiciaron el tener que eliminar algunas funciones y simplificar otras, entre ellas un análisis y ajuste más profundo de los mapas de Kohonen, por ejemplo. Respecto al tema de la documentación, aunque los diagramas y estudio de las técnicas de IA se iban haciendo de forma concurrente con el desarrollo, la realización de la memoria final ha llevado más horas de las previstas. El resultado del proyecto cumple con los objetivos, aunque muchas de las ideas que fueron surgiendo durante el desarrollo del mismo no llegaron a implantarse por razones de tiempo. Algunas de estas ideas y cuestiones, podrían quedar pendientes para futuras versiones del producto: El arranque de los agentes de la plataforma, que se hace en forma de script de línea de comandos, podría realizarse mediante una interfaz gráfica más cómoda. Puesto que tanto el entorno de pruebas como la red en la que se implantó el sistema eran redes pequeñas, el sistema de manipulación de scripts no era muy engorroso, pero en una gran distribución del producto, ésta no es la forma más adecuada de hacerlo. Se sugiere una interfaz que permita ubicar las máquinas que alojan los agentes en el espacio y que permita gestionarlos de forma remota. Por la misma razón, en una gran distribución de la aplicación resultaría interesante que los agentes Intérpretes propagaran su posición en la red, de forma que esto permitiera hacer diagnósticos más especializados y se tuviera en cuenta para la toma de decisiones. Se sugiere que la criticidad del sistema definida por el agente Supervisor, dependa también de la importancia de

100 100 los segmentos de red en que se detecten los ataques y que las acusaciones se representen, además de con las direcciones IP origen y destino, con la ubicación física de las máquinas atacante y víctima. La fiabilidad de los agentes Intérpretes también tiene que tenerse en cuenta para posteriores versiones del aplicativo. Actualmente, si el agente Inérprete recibe avisos de varios sensores a la vez, desecha aquellos que tienen menor prioridad. Esos avisos rechazados no debería ser ignorados de esa manera, ya que podría aportar mayor información al conjunto, defendiendo o refutando un diagnóstico que actualmente se está basando en una única fuente. Prácticamente todas las opciones que se pueden cambiar tanto en los sensores como en el intérprete son estáticas. Esto obliga a recodificar si se quiere cambiar alguna de ellas e incluso algunas de ellas también obligarán a repetir el proceso de captura de datos y entrenamiento de las redes, lo cual es sumamente engorroso. Como ya se ha comentado, la técnica de IA de los mapa de Kohonen no se llegó a implantar por razones de tiempo. Hubiera sido interesante hacerlo y comparar la calidad de su respuesta frente al perceptrón multicapa.

101 BIBLIOGRAFÍA [KOZI03] Jack Koziol, "Intrusion Detection with Snort", Sams Publishing 2003, 1ª Ed. [NORT01] Stephen Northcutt, Judy Novak, "Network Intrusion Detection", Sams Publishing [DIAZ05] Luis Díaz Vizcaíno, "Sistemas de Detección de Intrusos", Departamento de Ingeniería Telemática, Universidad Carlos III de Madrid, [ARAN06] Gonzalo A. Aranda Corral, "Construcción de un sistema multiagente mediante JADE", Curso de Agentes Inteligentes, Universidad de Sevilla, [CAIR03] Giovanni Caire, "JADE Tutorial: Jade Programming for Beginners", TILAB, [BELL03] Fabio Bellifemine, G. Caire, A. Poggi, G. Rimassa, "JADE A White Paper", TILAB, [BELL05] Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, Giovanni Rimassa, "JADE Programmer's Guide", TILAB, [BELL06] Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, Giovanni Rimassa, Roland Mungenast, "JADE Administrator's Guide", TILAB, [GARA04] Juan Fco. Garamendi Bragado, "Agentes Inteligentes: JADE", Programa de Doctorado: Informática y Modelización Matemática, Universidad Rey Juan Carlos, [ISAS04] P. Isasi, I. Galván. Pearson. Redes de Neuronas Artificiales. Un enfoque práctico. Prentice Hall, 2004 [ROJA96] R. Rojas. Neural Networks: A Systematic Introduction. Springer, JADE, Ntop, Rrdtool, Universidad Pontificia de Comillas,

102 SIGLAS Y ACRÓNIMOS ACL - Agent Communication Language. FIPA - Foundation for Intelligent Physical Agents. HIDS - Host Intrusion Detection System. IDS - Intrusion Detection System. (Sistema de Detección de Intrusos). IDSRN IDS - Sistema de Detección de Intrusos, basado en Redes Neuronales. JDK - Java Development Kit. JVM - Java Virtual Machine. ICMP - Internet Control Message Protocol. IP - Internet Protocol. JADE - Java Agents Development Environment (Entorno de Desarrollo de Agentes Java). NNIDS - Network Node Intrusion Detection System. NIDS - Network Intrusion Detection System. OSI - Open System Interconnection SDK - Standard Development Kit. SSH - Secure Socket Layer. TCP - Transmission Control Protocol. TILAB - Telecom Italian LABoratories. UDP - User Datagram Protocol. IA Inteligencia Artificial. P2P peer to peer, redes de pares o punto a punto.

103 ANEXOS ANEXO 1: Manual de Instalación del Sistema IDSRN El sistema IDSRN ha sido desarrollado para ser desplegado en plataformas Windows, aunque en la red en que funcione pueden coexistir otros sistemas operativos. Engloba una serie de subsistemas que es necesario instalar de la forma adecuada para su correcto funcionamiento en conjunto. Estos subsistemas son los siguientes: 1. INSTALACIÓN DE LA MÁQUINA VIRTUAL JAVA El sistema basa su despliegue en agentes Java JADE, por lo que para su ejecución en cada una de las máquinas que albergan entidades de este tipo es necesaria la presencia de una Máquina Virtual Java (JVM, en inglés, Java Virtual Machine). Si no se cuenta con una JVM instalada previamente en el sistema, la distribución de la aplicación proporciona una copia de la versión 6.0. Para su instalación en cada máquina implicada en el sistema IDSRN se debe ejecutar el instalable jdk-6u7-windows-i586-p.exe, que se proporciona con la distribución de la aplicación. La instalación se hace de manera sencilla e intuitiva, recomendando dejar los parámetros por defecto, incluída la ruta de instalación. 2. INSTALACIÓN DE LA SONDA NTOP La instalación de la sonda Ntop es muy sencilla. No hay más que ejecutar el fichero NTop_XTRA_3_18_0.exe y seguir los pasos de la instalación, que son totalmente intuitivos. La única elección que hay que tomar es la de la carpeta de su instalación.

104 INSTALACIÓN DE CYGWIN La instalación del emulador de terminal de Linux es un poco más complicada de lo normal. Al ser una instalación en línea, deberemos elegir la forma en la que nos conectamos a internet según nos lo vaya preguntando. Llega un momento en el que nos da a elegir varios repositorios para descargar los paquetes que se van a instalar, eligiendo estos en el siguiente paso: Este punto es importante, ya que a los que vienen por defecto hay que añadir algunos más para el correcto funcionamiento de la herramiento rrdtool, que instalaremos a continuación. En concreto son: Todos los del paquete Base En el paquete Libs o libart_lgpl o libfreetype26 o libintl3 o libpng12 o readline o zlib En el paquete Utils o patch

105 105 En el paquete Web o Wget Una vez hecho esto, procederemos a terminar la instalación, la cual tardará un poco, ya que hay que recordar que es una instalación en línea. 4. INSTALACIÓN DE LA HERRAMIENTA RRDTOOL La instalación de esta herramienta es la más sencilla de todas las instalaciones que hay que hacer. No hay más que coger el archivo rrdtool.exe que hay dentro del fichero.zip, y ponerlo en la carpeta bin de la instalación de cygwin que se ha hecho en el paso inmediatamente anterior. 5. INSTALACIÓN DE LA PLATAFORMA IDSRN La instalación de la plataforma de agentes inteligentes IDSRN es muy sencilla. Basta con coger la carpeta IDSRN y copiarla al directorio raíz C:, quedando C:\IDSRN, desde donde los agentes IDSRN funcionarán adecuadamente. Se recomienda hacerlo en esa carpeta, ya que un cambio de la ruta obligaría a retocar scripts y códigos fuente. Copiar la carpeta entera y no de forma selectiva significará que en muchos casos habrá instalados en una máquina más tipos de agentes de los que se van a correr en ella. Por cuestión de flexibilidad, si se pretende introducir un cambio en el esquema de agentes planificado en un principio, resulta más cómodo disponer de todas las posibilidades en todos los equipos. De esta manera se simplifica la instalación de los agentes sin comprometer la capacidad del equipo, ya que el volumen de código es muy pequeño. Llegados a este punto, la instalación de los componentes básicos sobre los que ejecutar el sistema en las diferentes máquinas de la distribución está completa, por lo que el arranque y uso de los diferentes agentes que lo conforman será tarea exclusiva del administrador del sistema desde el punto de vista del usuario.

106 ANEXO 2: Manual de uso del Sistema IDSRN El sistema, al ser un IDS basado en una arquitectura distribuida, requiere amplios conocimientos por parte de sus usuarios (típicamente administradores de red y personal de seguridad informática) tanto del tema de los Sistemas de Detección de Intrusos como de los sistemas distribuidos en entornos de red. Por las particularidades que puede presentar la red a supervisar con la instalación del sistema, la puesta a punto de los agentes forma parte del trabajo del administrador de la red desde el punto de vista del usuario: Configuración de la sonda Ntop. Diseño del plan de distribución de los agentes de la plataforma. Sobre este punto se ha hecho hincapié en el apartado 3.1.3: Implantación de IDS, por lo que no se volverá a insistir en este punto. Edición y recompilación del código fuente de los agentes Edición y ejecución de los scripts de arranque de los agentes de la plataforma. Eventualmente, reentrenamiento de la red neuronal 1. CONFIGURACIÓN DE NTOP Antes de nada hay que arrancar el programa. Se abre un intérprete de comandos y se ejecuta el fichero ntop.exe que estará en la carpeta de la instalación de Ntop. Es conveniente antes de nada ejecutar el comando ntop /h, por que si hay más de un interfaz de red en el sistema, hay que pasarlo como opción al ejecutar, y la ayuda nos dice qué número tiene cada interfaz. Una vez se sepa en qué número de interfaz se quiere que el Ntop escuche, se procede a ejecutarlo con la opción /c, para que lo ejecute como programa y no lo instale como servicio, cosa que se desaconseja sobretodo en el caso de tener más de un interfaz de red en la máquina en cuestión. Así, quedaría por ejemplo: ntop /c i 2, donde i es la opción que permite cambiar de interfaz de red. El siguiente paso es abrir un navegador de internet y entrar en la página y se cargará la pantalla vista en el apartado 4.2. Ntop. En el menú de la parte de arriba, en plugins/round Robin databases/configure están las opciones que tiene el Ntop a la hora de volcar la información a los ficheros.rrd. La más importante es poner en dump interval

107 segundos, es decir, 2 minutos. Si se cambia este valor, habría que recompilar los agentes y reentrenar la red neuronal. Todo el proyecto se ha construido con esa opción en 120 segundos. Las demás opciones se pueden modificar a placer, teniendo en cuenta que cuanta más información queramos volcar, más ocuparán en disco los archivos.rrd. En la opción RRD files path está la ruta en la que se guardarán los mencionados archivos. 2. USO DE RRDTOOL Para extraer la información de los ficheros.rrd y volcarlos a ficheros.txt, que es lo que entienden los sensores, hay que abrir un terminal cygwin y posicionarse en la ruta descrita en la opción RRD files path anterioremente mencionada. Dentro de esta carpeta ha de haber otra llamada interfaces, dentro de ella otra con el nombre del interfaz de red en el que está el Ntop escuchando, y dentro de esta última habrá otras 3 carpetas y multitud de ficheros.rrd, típicamente: En este punto se puede hacer uso del script extraerdatos, que se encuentra en la carpeta INSTALACIÓN IDSRN, el cual extrae los datos de los siguientes ficheros, a modo de ejemplo para el objetivo del proyecto:

108 108 IP_BitTorrentBytes.rrd IP_BitTorrentFlows.rrd ethernetbytes.rrd ethernetpkts.rrd ipbytes.rrd icmpbytes.rrd Esto es, el tráfico del tipo que el propio nombre del fichero indica que hay en esa máquina. El scritp en cuestión se puede editar para extraer los datos de cualquier otro fichero, ya que, como se puede observar en la captura, hay un fichero por protocolo como mínimo, a parte de haber en la carpeta hosts, por ejemplo, quién ha hablado con quién y cuánto, en la carpeta domains lo mismo pero a nivel de dominio En definitiva, la información que vuelca aquí el Ntop es más que exhaustiva. Al finalizar este paso, y según los datos que extrae el scritp tal y como está, en la carpeta datos del proyecto, es decir, en c:/idsrn/datos, debe haber sendos ficheros de texto, con una línea cada uno, que son los que alimentarán directamente a los sensores. 3. ARRANQUE Y CONFIGURACIÓN DE LOS AGENTES Para iniciar los agentes, tanto los sensores como el intérprete, no hay más que ejecutar sendos ficheros.bat (scripts) que hay en la carpeta IDSRN. Así, en la ventana del RMA de Jade veremos algo parecido a esto:

109 109 Las opciones de configuración no son muy variadas y la mayoría de ellas dependen de reentrenar la red neuronal: En los sensores: o Se puede variar el periodo en el que el sensor repite su función, que por defecto son 2 minutos, el mismo periodo que usa el Ntop para monitorizar. Se cambia en el constructor del comportamiento TickerBehaviour, concretamente addbehaviour(new TickerBehaviour(this, ). El tiempo que queramos poner tiene que estar en milisegundos. o También se puede variar el rango usado a la hora de normalizar la columna de los kilobytes, concretamente double kbn = (kb )/( );. Los valores que se han cogido son el máximo y el mínimo del conjunto de entrenamiento. o Se puede configurar también la arquitectura de la red neuronal, eso se hace en los bloques donde están los comentarios acerca de las neuronas de la capa de entrada y de salida. Para esto se hace necesaria la ayuda de Matlab, aunque no se vaya a hacer un nuevo entrenamiento, ya que necesitamos saber las funciones de activación y los pesos de cada neurona. o Por último se puede variar también el margen usado para dar como buena o mala una lectura, eso se hace en el bloque if que tiene la doble condición, y nuevamente se hace necesario el Matlab para saber cómo colocar esos márgenes.

110 110 En el intérprete: o Aquí lo único que se puede cambiar es la prioridad de los mensajes que lleguen desde los sensores, y es tan fácil como variar su orden dentro del bloque de condiciones En el procesador: o En este sensor habrá que variar el periodo en el que el procesador de datos repite su función en la misma medida en la que se haya cambiado el periodo de los sensores. Una vez puesto en marcha el sistema, tendremos en pantalla la información siguiente, a parte de la ventana del agente RMA: Se observa el arranque de los agentes y los mensajes de incorporación de un segundo contenedor, que están en otro intérprete de comandos.