Índice: Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)
Javier Santos Ferreras
NDICE
NDICE......................................................................................................................................... 1 1. 2. 3. OBJETIVOS DEL PROYECTO ...................................................................................... 5 ALCANCE DEL PROYECTO ......................................................................................... 7 ESTADO DEL ARTE...................................................................................................... 10 3.1. 3.1.1. 3.1.2. 3.1.3. 3.2. 3.2.1. 3.2.2. 3.3. 3.3.1. SISTEMAS DE DETECCIN DE INTRUSOS ....................................................... 11 SEGURIDAD PERIMETRAL .............................................................................. 13 CLASIFICACIN DE IDS................................................................................... 18 IMPLANTACIN DE IDS ................................................................................... 20 ATAQUES INFORMTICOS E INTRUSIN EN REDES .................................... 26 FASES DE UN ATAQUE..................................................................................... 26 ATAQUES CONOCIDOS .................................................................................... 35 MODELOS DISTRIBUIDOS .................................................................................. 49 MODELO CLIENTE-SERVIDOR........................................................................ 49
MODELO PEER-TO-PEER (P2P) .................................................................................... 52 3.3.2. 3.3.3. 3.4. 3.4.1. 3.4.2. 3.5. 3.5.1. 3.5.2. 4. MODELO DE AGENTES INTELIGENTES......................................................... 55 MIDDLEWARE ................................................................................................... 58 TECNOLOGA JAVA JADE................................................................................... 59 MODELO DE ARQUITECTURA ........................................................................ 61 MODELO FUNCIONAL ..................................................................................... 63 SNORT..................................................................................................................... 72 MODOS DE FUNCIONAMIENTO ..................................................................... 73 COMPONENTES DE SNORT ............................................................................. 74
DESCRIPCIN FUNCIONAL....................................................................................... 85 4.1. 4.1.1. 4.1.2. 4.2. 4.2.1. 4.2.2. 4.2.3. DOMINIO DEL SISTEMA...................................................................................... 87 DIAGRAMA DE DOMINIO................................................................................. 87 DEFINICIN DE CONCEPTOS......................................................................... 88 AGENTES DEL SISTEMA ................................................................................... 106 Agente RELOJ ................................................................................................... 107 Agente SENSOR................................................................................................. 109 Agente INTRPRETE ........................................................................................ 113
4.2.4. 4.2.5. 4.2.6. 4.2.7. 4.2.8. 4.2.9. 4.2.10. 4.2.11. 4.2.12. 4.2.13. 4.2.14. 4.2.15. 4.2.16. 4.2.17. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6. 4.3.7. 4.3.8. 4.3.9. 4.3.10. 4.3.11. 4.3.12. 4.3.13. 4.3.14. 4.4. 4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5.
Agente INTRPRETE ATTEMPTED-ADMIN................................................... 115 Agente INTRPRETE ATTEMPTED-DOS........................................................ 117 Agente INTRPRETE ATTEMPTED-RECON .................................................. 119 Agente INTRPRETE BAD-UNKNOWN .......................................................... 121 Agente INTRPRETE OTROS........................................................................... 123 Agente INTRPRETE UNKNOWN-CLASS ....................................................... 125 Agente ANALISTA ............................................................................................ 127 Agente ANALISTA ATTEMPTED-ADMIN....................................................... 130 Agente ANALISTA ATTEMPTED-DOS............................................................ 132 Agente ANALISTA ATTEMPTED-RECON ...................................................... 134 Agente ANALISTA BAD-UNKNOWN............................................................... 136 Agente ANALISTA OTROS............................................................................... 138 Agente ANALISTA UNKNOWN-CLASS ........................................................... 140 Agente SUPERVISOR....................................................................................... 142
COMPORTAMIENTOS ........................................................................................ 146 PERIDICO...................................................................................................... 147 CCLICO ........................................................................................................... 148 RECIBIR NOTIFICACIONES ........................................................................... 149 SINCRONIZAR .................................................................................................. 152 LIMPIAR BD ..................................................................................................... 154 OBTENER ANOMALAS ................................................................................... 156 ANALIZAR ANOMALAS .................................................................................. 160 ANALIZAR ANOMALAS ATTEMPTED-ADMIN ............................................. 169 ANALIZAR ANOMALAS ATTEMPTED-DOS.................................................. 172 ANALIZAR ANOMALAS ATTEMPTED-RECON ........................................... 175 ANALIZAR ANOMALAS BAD-UNKNOWN.................................................... 178 ANALIZAR ANOMALAS OTROS.................................................................... 181 ANALIZAR ANOMALAS UNKNOWN-CLASS ................................................ 184 DIAGNOSTICAR RESMENES ...................................................................... 187
CLASES DE LA INTERFAZ GRFICA............................................................... 215 MODELO DE TABLA........................................................................................ 215 VENTANA RELOJ ............................................................................................. 217 VENTANA AGENTE .......................................................................................... 220 VENTANA AGENTE AVANZADO..................................................................... 223 VENTANA AGENTE ANALISTA ....................................................................... 226
4.4.6. 4.4.7. 4.4.8. 4.4.9. 4.4.10. 4.4.11. 4.4.12. 4.5. 4.5.1. 4.5.2. 4.6. 4.6.1. 4.6.2. 5.
VENTANA DETALLES ...................................................................................... 231 VENTANA AGENTE SUPERVISOR.................................................................. 234 LEYENDA .......................................................................................................... 239 LIENZO SUPERVISOR ..................................................................................... 240 VENTANA DETALLES CON GRFICO Y TABLA .......................................... 244 VENTANA DETALLES CON TABLA ............................................................... 248 LIENZO DETALLES ........................................................................................ 252
CLASES DE LA CAPA DE PERSISTENCIA ....................................................... 256 EVENTO DAO ................................................................................................... 256 ANOMALA DAO .............................................................................................. 259 CLASES DE FUNCIONES DE CLCULO .......................................................... 263 FUZZY ............................................................................................................... 263 CONTROL BORROSO ...................................................................................... 264
ARQUITECTURA DEL SISTEMA IDSAI................................................................. 277 5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. ARQUITECTURA JAVA JADE MULTIAGENTE .............................................. 277 ARQUITECTURA DEL SISTEMA IDSAI ........................................................... 279 MODELO DE ARQUITECTURA EN CAPAS .................................................. 281 MODELO DE ARQUITECTURA IDSAI ........................................................... 283 MODELO DE COMPORTAMIENTOS ............................................................. 290
6.
DISTRIBUCIN DEL PROYECTO IDSAI ............................................................... 293 6.1. 6.2. CARPETA DE PROYECTO IDSAI....................................................................... 293 CARPETA DE INSTALABLES INSTALACION IDSAI ..................................... 298
7.
MANUAL DE INSTALACIN DEL SISTEMA IDSAI ............................................ 302 7.1. 7.2. 7.3. 7.4. INSTALACIN DE LA MQUINA VIRTUAL JAVA........................................ 303 INSTALACIN DEL IDS SNORT........................................................................ 304 INSTALACIN DEL SGBD MYSQL ................................................................... 311 INSTALACIN DE LA PLATAFORMA IDSAI .................................................. 317
8.
MANUAL DE USO DEL SISTEMA IDSAI................................................................ 318 8.1. 8.2. 8.3. 8.3.1. CONFIGURACIN DE LOS SENSORES ............................................................ 319 ARRANQUE DE LOS AGENTES......................................................................... 320 EXPLOTACIN DEL SISTEMA.......................................................................... 326 INTERFAZ DEL AGENTE SUPERVISOR ........................................................ 327
8.3.2. 8.3.3. 8.3.4. 9.
INTERFAZ DEL AGENTE ANALISTA.............................................................. 342 INTERFAZ DEL AGENTE INTRPRETE......................................................... 349 INTERFAZ DEL AGENTE RELOJ.................................................................... 352
PLANIFICACIN Y PRESUPUESTO DEL PROYECTO....................................... 355 9.1. 9.2. 9.3. 9.4. ORGANIZACIN DEL PROYECTO ................................................................... 355 METODOLOGA Y RECURSOS.......................................................................... 358 PLANIFICACIN DE TAREAS ........................................................................... 361 PRESUPUESTO .................................................................................................... 368
10. 11. 12. 13.
CONCLUSIONES.......................................................................................................... 370 BIBLIOGRAFA............................................................................................................ 374 SIGLAS Y ACRNIMOS............................................................................................. 376 ANEXOS......................................................................................................................... 379
1. OBJETIVOS DEL PROYECTO

El proyecto IDSAI (IDS, Sistema de Deteccin de Intrusos, basado en Agentes Inteligentes) aborda el tema de la deteccin de intrusiones en redes de ordenadores, y en particular, los Sistemas de Deteccin de Intrusos como solucin a esta problemtica. Hoy en da, la proteccin de las redes de computadores es tan importante como la de los equipos que se conectan a ellas, y en este aspecto los Sistemas de Deteccin de Intrusos cobran una importancia capital. Este proyecto trata de aportar soluciones acerca de estas cuestiones y para ello se fijan los siguientes objetivos: Desarrollar una arquitectura distribuida sobre un Sistema de Deteccin de Intrusos que permita la introduccin de nuevos mtodos heursticos de deteccin y conocimiento de diagnstico de una forma sencilla y sin cambiar la estructura de la distribucin. Disear una interfaz grfica de usuario sencilla y funcional que facilite al usuario el manejo del sistema. Optimizar los resultados del Sistema de Deteccin de Intrusos, reduciendo los falsos positivos y falsos negativos. Implantar el sistema desarrollado en una red de computadores real. Economizar los recursos dedicados a la seguridad informtica en redes con la utilizacin de un producto barato y eficaz. Aportar nuevas tcnicas y conocimientos que contribuyan a mejorar el desarrollo tecnolgico de la sociedad.
Incrementar la confianza de los administradores de redes en los Sistemas de Deteccin de Intrusos, como herramienta til en la seguridad informtica.
Concienciar a la sociedad informtica de los problemas que pueden plantearse si no se utilizan sistemas adecuados de seguridad.
2. ALCANCE DEL PROYECTO

La consecucin de los objetivos planteados en el proyecto IDSAI, se llevar a cabo a travs de distintos procedimientos: Se parte de un Sistema de Deteccin de Intrusos ya existente. En este proyecto se ha elegido el IDS Snort, por gozar de una gran confianza entre los usuarios, se adapta a las caractersticas del proyecto y es de libre distribucin. 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 tecnologa estable, bien documentada y de libre distribucin. Para el diseo de la interfaz grfica del sistema se opta por un esquema de ventanas interactivas, asociadas a cada uno de los agentes, que muestren los resultados del IDS de forma visual y permitan interactuar con cada uno de ellos. Para optimizar los resultados del IDS se facilita la informacin necesaria para la adecuada distribucin de sensores en la red y su configuracin individual. La primera distribucin del sistema incluir los parmetros heursticos y clases necesarias para la evaluacin de la criticidad del sistema en base a ataques de tipo escalada de privilegios, negacin de servicio, reconocimiento (profundizando en el escaneo de puertos) y situaciones anormales en general.
Se aportan heursticas en forma de rbol de decisin y controladores borrosos para la reduccin de falsos positivos y falsos negativos disparados por el Sistema de Deteccin de Intrusos.
Se utiliza un entorno de pruebas para la verificacin del correcto funcionamiento del sistema en cada una de las versiones del aplicativo.
La implantacin y uso del sistema se facilita mediante manuales que se proporcionan con la distribucin del proyecto.
Tanto el software base del proyecto (IDS, Gestor de bases de datos, middleware...) como las herramientas de desarrollo utilizadas (lenguaje y entorno de programacin, herramientas de diagramacin, herramientas de documentacin...) son gratuitos y de libre distribucin.
La investigacin realizada sobre los temas de seguridad informtica, Sistemas de Deteccin de Intrusos y arquitecturas software distribuidas aporta nuevos conocimientos cuya aplicacin mejora el rendimiento de los elementos de partida.
Los Sistemas de Deteccin de Intrusos, que en un principio tuvieron una gran aceptacin, no gozan actualmente de una gran confianza por parte de sus usuarios. El presente proyecto intenta que los IDS recuperen la credibilidad perdida, proponiendo una solucin eficaz.
Los administradores de red deben concienciarse de la utilidad de los Sistemas de Deteccin de Intrusos para la seguridad informtica. Su mayor eficacia se alcanza combinndolos adecuadamente con otros componentes de seguridad, como los Firewall.
Los mtodos de seguridad sern eficaces siempre y cuando los usuarios conozcan los peligros a los que estn expuestos los sistemas informticos 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 ms frecuentes que pueden llegar a comprometer la seguridad de una red de computadores.
3. ESTADO DEL ARTE

Hoy en da son conocidos los constantes ataques que sufren los servidores y redes de computadores de las compaas ms importantes del mundo. El robo y/o manipulacin de la informacin almacenada en un servidor corporativo puede provocar graves prdidas a una empresa y grandes beneficios a quien se lucre de ello. Qu ventaja de negocio supondra para una organizacin ver los equipos informticos de sus competidoras completamente colapsados e inservibles durante horas? Qu precio tiene la confidencialidad de las comunicaciones de una importante compaa? Lo que comnmente conocemos como ataques informticos supone una gran preocupacin para los administradores de red de cualquier organizacin que disponga de nuevas tecnologas de la informacin. Actualmente la comunicacin entre computadores ha cobrado una importancia vital en el mundo de la informtica 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 informacin es incalculable y por ello las compaas invierten gran cantidad de recursos econmicos y humanos en preservar su seguridad. En los siguientes apartados se har referencia a diversos temas de seguridad informtica: Sistemas de Deteccin de Intrusos y seguridad perimetral, vulnerabilidades de los sistemas informticos y tipos de ataques que una entidad maliciosa puede perpetrar contra ellos. Ms adelante se har una introduccin a los modelos distribuidos que hoy en da se implantan en las aplicaciones multiplataforma y en particular el modelo JADE multiagente inteligente. Para terminar se hablar del IDS concreto utilizado como base del proyecto IDSAI: Snort.
10
3.1.
SISTEMAS DE DETECCIN DE INTRUSOS

Un Sistema de Deteccin de Intrusos o IDS (Intrusion Detection System) es
un hardware, software o combinacin de ambos que monitoriza la red de un sistema informtico 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 daina en el momento en que se est produciendo, lo que permite percatarse de una situacin en la que la seguridad aparente de la red no es tal. Hay que destacar que un IDS se limita a notificar de situaciones anmalas y/o peligrosas en la red, y por tanto no interviene activamente en su prevencin (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 especficas de cualquier infraestructura, ya sea a nivel de rendimiento (ms rpido, con capacidades de gestin centralizada, etc.) o a nivel de configuracin y mantenimiento (ms o menos configurable, ms o menos simple de usar, etc.). Entre el software de libre distribucin podemos encontrar mltiples herramientas de este tipo, herramientas que presumen de ser fiables y frecuentemente actualizables dada la masiva colaboracin 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. Algunos de los IDS de libre distribucin ms conocidos son [DIAZ05]: o Snort: Este es el IDS ms famoso y potente de cuantos hay en el mercado. Est basado en anlisis de patrones, aunque poco a poco empieza a implementar otras funcionalidades como el anlisis estadstico (SPADE). Puede ser implantado tanto como NIDS como
11
NNIDS. Requiere conocimientos avanzados de seguridad y sobre ataques e intrusin en redes, ya que su configuracin en detalle es muy compleja. Este IDS se tratar en detalle ms adelante, ya que es el sistema de deteccin de intrusos en el que se basa el proyecto IDSAI. o Shadow: Menos extendido que el anterior, representa otra filosofa de IDS. Est basado en anlisis de trfico, ya que combina tcpdump para recolectar todos los paquetes, ssh para enviar esos paquetes a un servidor Web Apache, donde son procesados por varios filtros tcpdump y scripts Perl que generan una pgina html donde se puede ver el resultado de forma simple y resumida. Permite comparar capturas para buscar diferencias significativas. Este tipo de IDS requiere ms trabajo que los basados en patrones, pero permite localizar nuevos ataques desconocidos e identificar la firma. o Dragon: IDS dedicado a entornos Linux/Unix. Tiene 3 componentes: NIDS, HIDS y un monitor que permite recopilar la informacin de ambos en una misma interfaz. Tiene un alto grado de automatizacin y es sencillo de configurar. Existen numerosos desarrollos comerciales de IDS. La imagen de confianza que aporta una marca conocida en aplicaciones de seguridad informtica hace que muchos usuarios se decanten por estos productos. En el proyecto IDSAI no se han investigado herramientas IDS comerciales y el autor del presente documento se abstiene de citar ejemplos.
12
3.1.1. SEGURIDAD PERIMETRAL

La teora de la seguridad perimetral trata de solucionar el problema de la seguridad de las redes corporativas. Esta teora propone la disposicin estratgica de los equipos en subredes debidamente protegidas de accesos externos no autorizados mediante Firewalls. Un Firewall 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 trfico en una red de computadores, pero no es suficiente para garantizar la seguridad del sistema. Un Firewall representa una puerta que prohbe el paso a todas aquellas comunicaciones no permitidas, pero que deja pasar aquellas necesarias para el usuario al otro lado del dispositivo. Aunque slo se permitan los servicios bsicos y tericamente seguros, existen debilidades y agujeros de seguridad ante los que un Firewall no puede hacer nada, ya que es incapaz de evitar que un atacante utilice un servicio autorizado para perpetrar una accin maliciosa. Si la seguridad que proporciona un Firewall se ve comprometida es necesario disponer de algn sistema que permita al administrador de red ser capaz de detectar esta situacin [DIAZ05]. El IDS y el Firewall 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 Firewall, un administrador podra creer que su red est bien protegida cuando realmente no es as. Las alarmas del IDS permiten configurar el Firewall que complementa de una manera ms eficiente y tomar acciones reactivas eficaces en una situacin en que se haya producido un dao en la red. Otra situacin que alarmantemente es de las ms frecuentes en temas de seguridad informtica es el ataque desde dentro de la red, por parte de los propios usuarios autorizados, que bien por ignorancia o por malicia, ponen en peligro los recursos de la empresa (segn los estudios alrededor de un 80%
13
del total de ataques proceden del interior). Frente a estas circunstancias, un Firewall que controle el trfico hacia fuera de la red es intil, por lo que el nico recurso en el que confiar es el IDS que alerte de esta situacin de modo que un supervisor pueda tomar medidas internas en la compaa. Un IDS no impide la consecucin de un ataque, pero permite alertar de su presencia. Las capacidades de un IDS permiten realizar mltiples actividades relacionadas con la seguridad informtica como son las siguientes [DIAZ05]: o Monitorizacin y anlisis de las actividades de los usuarios. Como se ha descrito anteriormente, una gran proporcin de los ataques informticos 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. o Auditoria de configuraciones y vulnerabilidades de sistemas. La deteccin de trfico permite descubrir sistemas con servicios habilitados innecesarios o no autorizados, que de otra manera pasaran inadvertidos. El descubrimiento de una vulnerabilidad del sistema permite tomar medidas al respecto, eliminndola o si no es posible, poniendo especial atencin en ella. o Asegurar la integridad de los sistemas crticos. El anlisis de trfico permite saber si un determinado sistema ha sido atacado (o esta intentando ser atacado). De esta forma podemos estar seguros (en la medida de las posibilidades del IDS) de que los sistemas estn libres de ataques, ya que nunca se puede garantizar al 100% la eficacia del Firewall.
14
o Anlisis estadstico de ataques. Dado que la comparacin de ataques contra una base de datos es algo limitado, existen herramientas heursticas de bsqueda de patrones de ataques (como hacen los sistemas Antivirus con el cdigo malicioso). Sistemas basados en redes neuronales y dems mtodos de inteligencia artificial se aplican cada vez con ms frecuencia para este tipo de fines. o Anlisis de trfico anormal. El trfico autorizado que podemos considerar normal en nuestras funciones de negocio, puede dejar de serlo en determinadas circunstancias (conexiones fuera de las horas de trabajo, trfico en segmentos de backup en estado de normalidad, accesos frecuentes a equipos de uso excepcional...). Un anlisis detallado del trfico puede revelar una mquina comprometida o la situacin de un usuario con su password al descubierto. o Auditorias del entorno. Un IDS tras un Firewall es una excelente herramienta para determinar qu tipos de ataques pasan a travs del Firewall (y as comprobar su funcionamiento) y cuales de ellos tienen xito (y as comprobar la eficacia de los elementos menores de seguridad: Firewalls de host y Antivirus). Las ventajas del uso de IDS junto a Firewalls adecuadamente configurados son claras, y se ha hecho hincapi en ellas. Pero los IDS tienen tambin grandes desventajas, que se deben tener en cuenta para no confiar excesivamente en ellos [DIAZ05]: o Un IDS no puede hacer nada frente a ataques nuevos y que por tanto es incapaz de reconocer como tales. La actualizacin de la base de reglas de reconocimiento de patrones de un IDS es una importante actividad rutinaria de su mantenimiento.
15
o Un IDS no puede detectar ataques en comunicaciones cifradas extremo-extremo, ya que es incapaz de reconocer patrones en un contenido ilegible. o Un IDS no puede compensar mecanismos de autenticacin dbiles. Si es sencillo obtener usuarios y passwords legales y acceder con ellos al sistema, el IDS ser incapaz de alertar del acceso no autorizado. o Un IDS no puede automatizar la investigacin de los incidentes. Es necesaria la intervencin humana (de un analista cualificado) para descubrir la naturaleza real del ataque, limpiar sus efectos, descubrir al atacante y protegerse para el futuro. o Un IDS mal configurado puede dar lugar a errores y confusiones tpicas de este tipo de sistemas [KOZI03]: Falsos positivos: Alertas disparadas en condiciones normales. Este tipo de situacin 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 situacin se da en IDS configurados con excesivo nivel de detalle y propensos a alertar de la ms mnima variacin respecto a la normalidad. Falsos negativos: Ausencia de alertas en condiciones de ataque y trfico no autorizado. Este tipo de error es peor que el anterior, ya que el IDS no realiza su funcin de avisar de la situacin, 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 situacin se da en IDS no actualizados o configurados con bajo nivel de detalle y
16
propensos a alertar solamente situaciones muy claras, que los hackers ms experimentados suelen saber prevenir. o El prrafo anterior deja constancia de lo importante que es la adecuada configuracin de un IDS, cosa que no es trivial y requiere de un gran conocimiento al respecto y experiencia en el campo de la seguridad informtica. 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. o El software de un IDS es muy pesado. Hacer pasar todo el trfico de red por un juego de reglas de inferencia 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 ningn paquete. Instalar un sistema IDS en un punto de paso del trfico de red (por ejemplo en un router o en un Firewall) es la mejor manera para garantizar que no se deja de analizar ningn paquete de red. En la prctica 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 captulos se abordar la cuestin de cmo y dnde colocar sistemas IDS en redes de diferentes tipos.
17
3.1.2. CLASIFICACIN DE IDS

Existen tres tipos bsicos de IDS segn el fin para el cual estn diseados [KOZI03]: o Network Intrusion Detection System (NIDS): Son instalados en un segmento de red en concreto, del cual pueden absorber todo el trfico (escuchan en modo promiscuo) y analizarlo en tiempo real para disparar las alertas correspondientes. Cuanto ms transparente sea su funcionamiento y menos interfiera en el trfico de red, mejor. o Network Node Intrusion Detection System (NNIDS): Son instalados en un host en concreto, analizando todo el trfico destinado a dicho equipo. Se suelen utilizar sobre equipos crticos de la compaa propensos a ser objetivo de ataques o en un HoneyPot (host dbilmente protegido que sirve de trampa para hackers desviando su atencin de los equipos ms importantes). o Host Intrusion Detection System (HIDS): Son instalados en un host en concreto y permiten tomar una instantnea del sistema, para comprobar mas adelante la integridad de la mquina. 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 cuales han sido las consecuencias a posteriori. El sistema IDSAI se basa en NIDS, por lo que en adelante ser el modelo de IDS al que se har referencia.
18
Los IDS tambin se pueden clasificar en las siguientes categoras segn su forma de detectar las intrusiones [KOZI03]: o Bsqueda 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, ms tipos de ataques se podrn detectar, pero ms costoso computacionalmente ser para cada paquete, pudindose perder alguno si el ritmo de anlisis no soporta el del flujo de informacin. o Anlisis de trfico (Anomaly detection): Los IDS de este tipo estn configurados para conocer la situacin "normal" de la red. Recolectan todo el trfico y crean estadsticas en tiempo real del estado de la red. Si en un momento determinado, la estadstica se sale de la normalidad, se genera la alerta para que el analista lo investigue. o Verificacin de integridad: Es el sistema que utilizan los HIDS. Se comprueban determinados aspectos de un equipo (checksum de ficheros crticos, registro del sistema, logs...). Permite saber a posteriori, que tipos de ataques se han perpetrado en un sistema y los daos que han producido.
19
3.1.3. IMPLANTACIN DE IDS

Hasta aqu se ha pretendido dar una visin 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 situacin 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 implantacin de un IDS requiere una serie de pasos a seguir para hacerlo de forma eficiente [KOZI03]: 1. Identificacin de necesidades: Se debe determinar la importancia de la informacin. Cuantificar en trminos econmicos y subjetivos (confianza pblica en la compaa, respeto por parte de otras empresas...) las prdidas en que se incurrira si los datos se perdieran y/o fueran robados. Esta cuantificacin 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 deteccin de intrusos: Es necesario tener unas nociones bsicas de lo que puede hacer un IDS y para qu
20
sirve, o de lo contrario se tendra una falsa ilusin de seguridad. El conocimiento sobre ataques informticos 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 Firewalls es ms segura que una mal administrada. La distribucin de sensores en las diferentes subredes dar lugar a una variedad ms rica y precisa de anlisis. 4. Escoger el IDS ms adecuado: Se debe elegir el sistema IDS que mejor se ajuste a las necesidades de proteccin de la red, condicionado su complejidad al nivel de conocimiento por parte del administrador/analista. Evaluar varios IDS simulando bateras 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 mtodo para decantarse por un IDS en particular. 5. Especificar una poltica de seguridad: Es fundamental contar con un protocolo de actuacin concreto frente a una situacin de alerta por parte del IDS, ya que de nada sirve ser capaz de detectar ataques si luego no se sabe que hacer en respuesta. Debe contarse con una documentacin completa sobre lo que hacer en cada situacin, de forma que no surjan dudas sobre el plan de accin. Esta documentacin es especfica de cada organizacin 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 poltica tambin deber tener conocimientos avanzados de este
21
tipo para poder intervenir rpida y eficazmente sin dudar en ninguna situacin. La implantacin fsica del IDS en la red es muy importante. De ella dependern las caractersticas 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 estratgicos ms comunes donde disponer de sistemas IDS [DIAZ05]:
Subred servidores
DMZ
4
Red corporativa
5
Subred usuarios
I n t e r n e t
Red corporativa externa
Fig. 1: Ejemplo configuracin de red.
Aunque dependiendo del entorno se pueden encontrar otras ubicaciones posibles, los puntos ms tpicos donde colocar un IDS (puntos rojos en la imagen) son:
22
1. Entre la Extranet e Internet: Para controlar el trfico que sale/entra de la red externa de la compaa es imprescindible contar con un sensor IDS en el enlace VPN por el que se accede a travs de Internet a la red corporativa. 2. En la DMZ: La zona desmilitarizada es el segmento de red entre el firewall de la red corporativa e Internet. En l se suelen ubicar los servidores de acceso pblico que no albergan informacin importante y no requieren unas medidas de proteccin y seguridad exhaustivas (servidores web, por ejemplo). Por esta razn suelen ser objetivo de una primera aproximacin a la red por parte de hackers y por tanto su vigilancia debera considerarse en todo momento. 3. Tras el Firewall: Esta suele ser la ubicacin caracterstica de un IDS, puesto que permite analizar todo el trfico que entra en la red (ya filtrado por el Firewall). De la misma forma, permite comprobar que el Firewall funciona incorrectamente, si este ha dejado pasar trfico no autorizado. Para comprobar el buen funcionamiento del Firewall 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 informacin estratgica 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 mquinas de usuario, que pueden almacenar informacin de negocio y suelen tener acceso privilegiado a los servidores de la compaa. Los ataques que se inicien en el interior de la organizacin tambin se detectarn ms rpidamente si consideramos la instalacin de este IDS.
23
Como se puede ver, disponer de varios sensores IDS en distintos lugares estratgicos de la red es fundamental para completar el sistema de capas de seguridad que componen las subredes y Firewalls de la empresa. Tomar decisiones en respuesta a alertas generadas por IDS concretos ser ms rpido y eficaz que hacerlo si slo contamos con un sensor para toda la red. Adems cada IDS se puede configurar en detalle segn el tipo de trfico de su segmento de red en particular, para as reducir el tamao de su base de reglas y evitar la bsqueda de patrones superfluos. En entornos con mltiples IDS es muy til tener centralizada la gestin. De esta forma se pueden recoger los registros y las alarmas en un nico lugar. Esto facilitar el trabajo del personal de seguridad que segn hemos explicado es indispensable que est tras la mquina interpretando los resultados e interviniendo en caso de ataque. Los logs deben ser revisados diariamente y la actualizacin del IDS debe ser constante, aadiendo las nuevas firmas conocidas. Adems, el personal de seguridad es responsable de mantener los sistemas de recuperacin ante emergencias. Por todo lo que se ha comentado hasta el momento, parece obvio que un IDS, ms 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 perdida potencial de paquetes y por tanto una perdida potencial de ataques o incluso un elevado nmero de falsos positivos (si al perder paquetes, el IDS detecta discontinuidades en las secuencias TCP). En una situacin de congestin de red debido a una inundacin 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]:
24
o Optimizar la base de datos de firmas: En general, la configuracin por defecto de los IDS busca todos los ataques conocidos posibles. Debido a las caractersticas de la red, muchos de ellos aunque se produjesen no tendran efecto. Es importante conocer bien la red que se pretende administrar para no perder tiempo de CPU chequeando firmas de ataques que nunca tendran xito en nuestra configuracin. Ejemplos: Ataques de tipo RPC en entornos totalmente Microsoft o anlisis de exploits de sistemas FTP en redes sin este tipo de servicio. o Filtrar trfico no deseado: Por defecto, el IDS analiza todo el trfico que es capaz de capturar en su segmento de red. Como se ha explicado anteriormente, un IDS es incapaz de identificar firmas en trfico cifrado, por lo que el sensor se puede configurar para que ignore el trfico de este tipo, por ejemplo el SSH. o Balanceo de carga: Al ser un IDS un dispositivo computacionalmente pesado, si el volumen de trfico a analizar es muy importante (porque est situado en una zona crtica como detrs del Firewall), es recomendable la instalacin de varios sensores balanceados por tipo de trfico. Reduciendo el nmero 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. o Optimizacin de la configuracin: Adems del juego de reglas, cada IDS tiene varias opciones de configuracin que influyen en su rendimiento. Es muy importante adaptar cada sensor a la situacin ms adecuada.
25
3.2.
ATAQUES INFORMTICOS E INTRUSIN EN REDES

En los siguientes puntos se presentan unas breves reseas sobre ataques
informticos e intrusin en redes que ayudarn a comprender mejor a qu se enfrentan los administradores de red y los motivos de la instalacin de Sistemas de Deteccin de Intrusos.
3.2.1. FASES DE UN ATAQUE

La intrusin de redes y los ataques a recursos crticos de una compaa 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 Deteccin de Intrusos y los procedimientos de registro de incidencias han evolucionado de forma paralela a la pericia de los hackers. 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 accin concreto, sera muy sencillo prever sus ataques. No obstante la intervencin de un hacker suele diferenciarse en 4 fases, que deben conocerse en detalle [KOZI03]:
3.2.1.1. PLANTEAMIENTO
Los buenos hackers generalmente se detienen a planear en detalle sus ataques antes de realizar ninguna accin sospechosa. Un hacker inteligente tratar de buscar por medios indirectos (los medios directos los aplicar en la fase de reconocimiento) informacin sobre la estructura de la
26
red que pretende atacar y sobre sus vulnerabilidades (agujeros en aplicaciones de negocio, equipos desprotegidos...). Esta informacin se puede obtener de mltiples maneras: por medio de los propios empleados de la empresa, accediendo a documentacin que descuidadamente publican los administradores del sistema, etc. En esta fase, si el hacker no tiene un objetivo concreto, lo determinar. La motivacin y la informacin de la que parta el atacante le har decantarse por uno o ms ataques de entre los siguientes tipos: Negacin 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 negacin de servicio de una aplicacin ubicada en un servidor consiste generalmente en el envo masivo de peticiones remotas con el objetivo de colapsar la aplicacin de forma que no pueda atender a las peticiones ordinarias de los usuarios. Cualquier procedimiento que implique una reduccin de los recursos computacionales del servidor de forma que no pueda atender adecuadamente las peticiones tambin puede considerarse una negacin de servicio (por ejemplo un troyano pesado que agote la memoria de la mquina). Una negacin de servicio puede extenderse a varios equipos si se consigue inundar de trfico anormal un segmento de red entero. Un ataque de este tipo bien planeado, puede inutilizar una red entera forzando a resetear cada una de las mquinas si se realiza con xito. Escalada de privilegios: Este tipo de ataque consiste en obtener los permisos legtimos necesarios para acceder a un
27
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 prctica, la escalada de privilegios consiste en obtener un usuario y contrasea vlidos para el acceso al recurso deseado. Esto es relativamente sencillo en mtodos de autenticacin dbiles (transmisin de contraseas sin cifrar, passwords de diccionario...) si se consigue capturar el trfico de un segmento de red. Instalar un troyano de tipo keylogger (registro de teclas) puede ser un sencillo mtodo 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 sesin de usuario autorizado permite el acceso con esos permisos al atacante remoto. Un administrador de red descuidado que publique cuentas de usuario raz y no realice una gestin adecuada de contraseas, actualizndolas frecuentemente, puede encontrarse con serios problemas de escalada de privilegios por parte de usuarios no autorizados. El acceso a un recurso utilizando una autenticacin vlida aunque el usuario no haya sido autorizado a ello es un hecho ante el que un IDS es intil al no poderlo identificar como un ataque.
28
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 programacin. Los mtodos que explotan estas vulnerabilidades son comnmente llamados exploits y son bien conocidos en general por comunidades de hackers y publicados abiertamente en pginas web y foros. Primeramente se debe saber de qu versin del software se trata, pero esto no es trivial y el atacante debe llevar a cabo una labor de investigacin si no lo conoce de antemano. Ms adelante, en la fase de reconocimiento, podr poner en prctica mtodos directos de obtencin de esta informacin, aunque sean tpicamente detectables por sistemas IDS. Un sistema operativo desactualizado al que no se le han instalado los parches de seguridad recomendados es una fuente enorme de vulnerabilidades conocidas por la mayora de hackers (y publicadas en Internet) y lo mismo ocurre con software de servicio remoto de uso comn (servicios FTP, de pginas web, etc.). Segn el tipo de ataque que se realice se atentar contra la propiedad de seguridad que se desee violar del recurso. Un ataque de tipo negacin de servicio atenta exclusivamente contra la disponibilidad del recurso. Un ataque de los otros dos tipos permite el acceso a la informacin al hacker y por tanto viola la integridad de esos datos, ya que tras la intrusin no se puede garantizar la validez ni la fiabilidad ni la confidencialidad de la informacin manipulada.
29
3.2.1.2. RECONOCIMIENTO
En esta fase, el atacante lleva a cabo acciones directas para la obtencin de informacin 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. Despus de que un atacante haya recopilado informacin pblica sobre la organizacin objetivo, tratar de descubrir vulnerabilidades concretas a explotar. Existen una gran variedad de tcnicas de reconocimiento para obtener informacin detallada de este tipo. La primera accin que tendr que llevar a cabo el atacante es comprobar si la vctima del ataque est arrancada en el instante actual, lo que llevar a cabo haciendo ping a la direccin vctima 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 conexin TCP o un intento de comunicacin UDP sern suficientes para comprobar si la direccin IP vctima est activa. En el momento en que se est seguro de que la mquina objetivo est viva el atacante debe buscar puertos abiertos con la intencin de saber qu aplicaciones se estn corriendo en el equipo y sus versiones, de forma que pueda explotar sus vulnerabilidades. Esto se lleva a cabo a travs de un escaneo de puertos, tipo de ataque de reconocimiento que se torna inevitable si se pretende saber para qu se utiliza realmente una mquina y que es fcilmente detectable por un IDS.
30
Hosts seguros suelen estar configurados para no responder a intentos de conexin 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 aplicacin (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 estn dedicados a determinados sistemas operativos. El reconocimiento del sistema operativo que corre en una mquina se realiza mediante la respuesta que este da a un determinado estmulo (en general, paquetes de red no vlidos a los que cada versin de sistema operativo reacciona de forma diferente, lo que se conoce como fingerprint). Se vern ms detalles y ejemplos de ataques de estos tipos en el apartado 3.2.2: Ataques conocidos.
31
3.2.1.3. ATAQUE
Tras la planificacin del ataque y el reconocimiento de la vctima, el siguiente paso es hacer uso de la informacin obtenida para atacar el sistema objetivo. Segn la naturaleza del ataque que se desea realizar y las vulnerabilidades del sistema escogido como vctima se llevarn a cabo las acciones que el hacker considere ms apropiadas y menos llamativas en pos de impedir ser detectado por un IDS. Esta fase es muy delicada por esta razn, y es muy frecuente en hackers experimentados el servirse de triquiuelas que impidan al encargado de seguridad la localizacin del origen del ataque. El primer paso en estas operaciones suele ser la negacin de servicio del sistema IDS que pueda dar la alarma del ataque, bien tratando de ocultar el ataque entre otros ms descarados a otras mquinas en paralelo o inundando el segmento de red del IDS con trfico anmalo 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 instalacin de virus troyanos en las mquinas controladas. Un ataque distribuido bien coordinado, es ms eficaz que uno perpetrado desde una sola mquina y permite a la vez que la pista del atacante se pierda entre equipos irrelacionables con su persona. En la presentacin de los tipos de ataques a realizar en la fase de planificacin ya se hizo una breve introduccin a ejemplos de ataque que no se repetirn en este punto, pero que se desarrollarn en detalle en el apartado 3.2.2: Ataques conocidos.
32
3.2.1.4. POST-ATAQUE
Despus de que el atacante haya penetrado satisfactoriamente en un host de una red, las acciones que lleve a cabo pueden ser de lo ms variopinto. En esta fase el atacante demostrar su verdadera motivacin y pericia, llevando a cabo una o mas de las siguientes acciones: Borrar huellas: Es una buena prctica 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 accin de una entidad no autorizada, confirmar al administrador de red o al sistema HIDS la situacin del ataque, pero no podrn investigarlo. Existen scripts que automatizan este procedimiento para ocultar la actividad maliciosa tanto procedente del exterior (por la va 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 informacin importante para una compaa raramente es accesible desde hosts con acceso al exterior. Los servidores de negocio suelen ubicarse en subredes internas protegidas por Firewalls 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 Firewall. El control remoto de varias mquinas en la capa menos segura de la red, suele ser la nica manera de ejecutar ataques distribuidos de forma remota sobre equipos ms protegidos de la red. Una
33
escalada de privilegios en varias fases es tediosa y supone el riesgo de ser detectado en una de las etapas, pero es la forma ms segura de tener xito en el ataque. Robar, manipular o destruir datos: El acceso a la informacin de la empresa es el mvil bsico de un hacker, que le sacar el mximo beneficio a la misma. Un cracker no se conformar slo con la lectura y modificacin de la informacin a su parecer, sino que adems la destruir haciendo perder a la empresa vctima 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, aficin que consiste en perpetrar ataques a una red, con el nico fin de demostrar sus habilidades sin la intencin de causar ningn dao. Los hackers ticos suelen ponerse en contacto con el administrador de la red atacada disculpndose por su accin y detallndole las vulnerabilidades de su sistema por lo que aunque la accin realizada es ilegal, no suelen ser denunciados.
34
3.2.2. 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 intrusin en redes.
3.2.2.1. ATAQUES DE RECONOCIMIENTO

Estos ataques se aplican en la fase de reconocimiento de un ataque (ver apartado 3.2.1.2: Reconocimiento) y su objetivo es la deteccin 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 direccin IP objetivo. La mquina contestar al origen con un mensaje ICMP ECHO Reply si est encendida y no lo har en caso contrario.
ECHO Request ECHO Reply
Fig. 2: ICMP Ping
Tambin se ha comentado anteriormente otra manera de detectar un host vivo: establecer una conexin TCP con l. Segn el protocolo TCP, un host activo contesta a un paquete TCP connect con un paquete ACK.
35
TCP ACK
Fig. 3: Conexin TCP El escaneo de puertos es la forma directa de reconocimiento de las aplicaciones que corren en una mquina. Si en un equipo remoto el puerto estndar de una determinada aplicacin est abierto significa que hay un servicio escuchando por l y que se corresponde con una determinada aplicacin. Si el escaneo del puerto estndar de una aplicacin conocida resulta satisfactorio en una mquina se puede asegurar que en dicho servidor est corriendo ese programa. Un escaneo TCP se realiza mediante una conexin TCP al equipo objetivo por el puerto deseado. Dependiendo del tipo de mensaje de contestacin se puede determinar si el puerto est abierto o cerrado y por tanto si su aplicacin asociada est corriendo en el sistema y se puede establecer comunicacin con ella o no.
SYN SYN/ACK
Puerto TCP abierto
SYN RST/ACK
Puerto TCP cerrado
Fig. 4: Escaneo de puerto TCP
36
De una manera parecida, se puede realizar un escaneo UDP. La comprobacin de que una aplicacin est a la escucha de un puerto UDP se realiza mediante el envo de un paquete UDP. Al ser el protocolo UDP un protocolo de red sin conexin, no se tiene por qu esperar una respuesta al 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.
<UDP>
Puerto UDP abierto
<UDP> ICMP Port Unreachable
Puerto UDP cerrado Fig. 5: Escaneo de puerto UDP
Si se desean explotar las vulnerabilidades del sistema operativo, se recomienda conocer la versin del mismo, para saber con qu parches cuenta y cundo fue la ltima actualizacin de seguridad. Como se describi en el apartado 3.2.1.2: Reconocimiento, la forma de identificar la versin del sistema operativo de una mquina objetivo es analizando su fingerprint. El ejemplo tpico de ataque de reconocimiento de sistema operativo es el ataque FIN. El envo de un paquete de cierre de una conexin TCP no
37
abierta es una situacin anmala frente a la cual, cada versin 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 versin.
FIN fingerprint
Fig. 6: Ataque FIN
El escaneo de muchos puertos consecutivos con la intencin de dar con alguno por el que comunicarse con una mquina objetivo (horizontal scan) consiste en iterar los escaneos anteriormente descritos para encontrar un puerto abierto en la vctima. El proceso contrario, el escaneo de un puerto concreto en varias vctimas (vertical scan) consiste en ir probando la existencia del puerto objetivo en mltiples mquinas en busca de una potencial vctima de un exploit conocido. Existen herramientas y scripts que automatizan estos procesos, pero no dejan de generar un trfico anormal y tremendamente sospechoso que no se le suele escapar a ningn IDS. A medida que los Sistemas de Deteccin de Intrusos han incorporado ms tipos de patrones de escaneos de puertos, los hackers han ido a su vez descubriendo nuevos mtodos para evitar ser detectados. Un ejemplo es el ataque Xmas scan. Un paquete TCP enviado a una vctima con todos los flags TCP/IP activados no se corresponde con ninguna configuracin vlida de este protocolo y por tanto la mquina destinataria devuelve una respuesta caracterstica, es decir un fingerprint. Cuando se descubri este agujero del protocolo TCP/IP, este escaneo pas
38
desapercibido para todos los IDS hasta que tiempo ms tarde se les aadi su firma. Un IDS detecta un escaneo de puertos cuando en un breve espacio de tiempo registra mltiples intentos de conexin 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 das 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 mltiples orgenes, cosa que no es difcil si el hacker se ha hecho con el control de varias mquinas de la red.
39
3.2.2.2. ATAQUES DE NEGACIN DE SERVICIO (DOS)

Se denomina ataque de negacin 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 legtimos. Los ataques de negacin de servicio pueden darse sobre la mayora del equipamiento de red, incluidos routers, servidores, firewalls, mquinas de acceso remoto e incluso el propio medio. Un ataque de negacin de servicio puede tener como objetivo una aplicacin especfica (como la negacin de un servicio FTP) o una mquina entera (colapsando sus comunicaciones o consumindole todos sus recursos). Los ataques de negacin de servicio tienen diversas naturalezas, pero en general se pueden separar en dos categoras: Ataques de paquetes maliciosos (malicious packet attacks) o Ataques de agotamiento de recursos (resource depletion) [NORT01]. Ataques de paquetes maliciosos: Consisten en el envo de trfico anormal de forma masiva hacia un host para provocar un fallo en el propio equipo o en un servicio concreto ejecutndose en el mismo. Este tipo de ataques se aprovechan de que tanto el software de aplicacin como el de los sistemas operativos no est diseado 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
40
Microsoft, se inclua la bsqueda de ficheros con caracteres comodn (* y ?). Esta funcionalidad daba buenos resultados en bsquedas con uno o dos smbolos de este tipo, pero el sistema fallaba (por una cuestin de reserva insuficiente de memoria) cuando el comando de bsqueda inclua mltiples caracteres comodn intercalados (por ejemplo, *a*?*??*). La aplicacin FTP se quedaba colgada y se produca la negacin del servicio. La negacin 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. En la versin 1.8.3 de Snort, la evaluacin del tamao de paquetes ICMP tena un error, y era que cuando ste tena valor 1, el sistema quedaba bloqueado en ese punto. La inyeccin de paquetes ICMP manipulados con esta
caracterstica, negaba el servicio del IDS, y el ataque posterior poda llevarse a cabo sin vigilante que alertara la situacin. Ataques de agotamiento de recursos: Consisten en la inundacin de las capacidades de un servicio o mquina con gran cantidad de trfico autorizado, de forma que no puede cumplir su funcin con respecto a los usuarios legtimos con normalidad. El objetivo del atacante es ocupar todo el ancho de banda de la conexin al servidor, o consumir sus recursos computacionales bsicos: CPU y memoria. Un ejemplo de consumo del ancho de banda de la conexin a la red de un host objetivo es el Ataque Smurf DoS. Este
41
ataque est basado en la tcnica de suplantacin de IP (IP Spoofing), que consiste en enviar paquetes de red manipulando las cabeceras IP de manera que la direccin de origen no sea la propia. El envo de paquetes de red con una direccin ajena significa que las respuestas a dichos paquetes por parte de la estacin destino se realizarn hacia esa direccin. El ataque Smurf consiste en el envo de paquetes ICMP ECHO Request a la direccin de broadcast, es decir, a todos los equipos de la red objetivo a la vez, poniendo como origen de los paquetes la direccin IP del host vctima. Cada una de las mquinas de la red contestarn a la vctima con los correspondientes paquetes ICMP ECHO Reply, consumiendo una fraccin del ancho de banda de su enlace de red, y el conjunto de todos colapsar las comunicaciones de la vctima durante unos segundos.
42
ECHO Reply ECHO Reply ECHO Reply ECHO Reply VCTIMA ECHO Reply
ECHO Request ATACANTE
Fig. 7: Ataque Smurf DoS
Los ataques de negacin de servicio generalmente utilizan la tcnica de suplantacin de IP, ya que el ataque no requiere una contestacin por parte de la vctima para tener xito y adems mediante el cambio de la direccin IP de origen, har ms complicada la identificacin del origen del ataque por parte del administrador de red.
43
3.2.2.3. EXPLOITS REMOTOS

Los exploits o vulnerabilidades remotas son el mtodo ms comn para obtener acceso no autorizado a un sistema. Estas tcnicas estn diseadas para tomar ventaja de cdigo software mal diseado para comprometer y tomar control de un host vulnerable. Estas vulnerabilidades suelen ser ampliamente conocidas y los desarrolladores del software habrn 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 difcilmente predecible y slo se podrn 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 cmo reaccionar y colapse [NORT01]. Una vulnerabilidad tpica ante la que todo software es propenso a fallar es la del desbordamiento de bfer (buffer overflow). Los desbordamientos de bfer se producen cuando un atacante introduce ms datos de los que un bfer o array puede manejar y esta condicin no est adecuadamente evaluada en el cdigo del programa. Al salirse de la zona reservada, los datos introducidos se sitan por tanto en posiciones contiguas de memoria y esto no slo provoca que el programa aborte sino que si se ha realizado de forma adecuada, se puede forzar al sistema a ejecutar la informacin fuera de rango sin restricciones de permisos. El Apache chunked encoding exploit es un ejemplo de desbordamiento remoto de bfer. Apache fallaba al calcular los tamaos dinmicos de bfer debido a la
44
malinterpretacin de un entero sin signo definido en su cdigo de programa. Peticiones codificadas de determinada manera permitan incluir comandos del sistema en las posiciones que quedaban fuera del bfer, lo que permita a los hackers arrancar consolas remotas con permisos de administrador o crear cuentas de usuario raz en la mquina comprometida. Los hackers ms expertos pueden encontrar la forma de que una aplicacin ejecute comandos o cdigo binario en un sistema sin necesidad de provocar un desbordamiento de bfer, evitando as que la aplicacin aborte para llevar a cabo un ataque ms silencioso. Estos ataques requieren tambin de amplios conocimientos sobre el cdigo fuente del software a explotar. Un ejemplo es el Unicode exploit for Microsoft's IIS, que permita la navegacin libre por la estructura de directorios de las mquinas que incorporaban las primeras versiones de este servidor Web. La vulnerabilidad consista en que el mdulo intrprete de las direcciones que se solicitan desde el navegador, traduca la representacin Unicode del smbolo delimitador de directorio ( / ), permitiendo al hacker acceder a cualquier fichero en el sistema. La lgica de las aplicaciones Web dinmicas es muy propensa a fallo frente a usuarios malintencionados. La comprobacin de la entrada de datos por parte de un programa para evitar la explotacin de vulnerabilidades es fundamental, y un ejemplo de esto es el popular ataque de inyeccin de SQL. Este mtodo consiste en la insercin de sentencias SQL en los campos de entrada de un formulario Web. Las queries debidamente introducidas pueden modificar la lgica del acceso a datos del programa, por ejemplo, permitiendo al atacante saltarse la fase de registro o lanzar comandos al sistema.
45
3.2.2.4. ACCESOS AUTORIZADOS

En la mayora de los casos, la intencin de un ataque es el control de la mquina objetivo, el acceso a la informacin almacenada en ella, la explotacin de sus recursos computacionales, etc. El uso de permisos legtimos de usuario es la forma ms cmoda y fiable de llevar a cabo ataques con xito, pero con las debidas medidas de control, la identificacin de un usuario que realice alguna accin maliciosa de esta manera es inmediata. Los propios empleados de una empresa, son en muchas ocasiones la persona que est detrs del ataque a un recurso de la misma, ya que disponen de una posicin ms ventajosa que la de un hacker externo de cara a que de alguna manera "ya estn dentro". Por otra parte, los empleados que disfrutan de un acceso privilegiado a determinados recursos son en ocasiones los culpables de la publicacin de contraseas o de la desproteccin de los sistemas bajo su responsabilidad, lo que suele ser aprovechado por terceros malintencionados para perpetrar ataques pudiendo inculpar al encargado. La adquisicin de los permisos de un usuario autorizado para acceder a un recurso clave de la organizacin puede ser tan sencillo como obtener su contrasea de autenticacin en el sistema. Una accin llevada a cabo utilizando los credenciales de la vctima exime al que se hace pasar por ella de cualquier acusacin. El robo de contraseas y certificados digitales se da con mucha frecuencia en entornos de confianza y exceso de ingenuidad por parte de los hombres que estn detrs de las mquinas. Los sistemas de autenticacin dbiles son una fuente de problemas de este tipo; si es sencillo obtener permiso de acceso a un recurso por parte de una persona autorizada, tambin lo ser para una que no lo es, por lo que una buena gestin de contraseas es fundamental. Se recomienda a los administradores de red establecer contraseas de usuario alfanumricas, no
46
estndar y no de diccionario que cambien peridicamente en todos los sistemas de una organizacin. El espionaje de las comunicaciones en una red mediante herramientas sniffers es una sencilla manera de hacerse con contraseas de usuario aprovechando procesos no cifrados de autenticacin remota. El control de las aplicaciones que los empleados tienen instaladas en sus terminales y la adecuada configuracin de red que impide estas actividades es fundamental para evitar una situacin comprometida. Las aplicaciones Web dinmicas generalmente usan cookies para mantener el estado de una comunicacin entre el cliente y el servidor. Las cookies son ficheros ligeros que se instalan en la mquina del cliente, con su permiso, y que almacenan, entre otras cosas, informacin de autenticacin de usuario. Aprovechando esto, existe una forma de escalada de privilegios que los hackers llevan a cabo mediante una sencilla tcnica de engao denominada cross-site scripting (XSS) [NORT01]. Consiste en presentar al usuario una ventana que le anime a hacer clic en un enlace malicioso hacindole creer que se trata de una navegacin 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 vctima. Debido a la inmadurez de muchos usuarios de Internet y a la navegacin 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, segn la misma filosofa de los ataques XSS, la proliferacin de virus y troyanos y su entrada en el sistema con facilidad. Un usuario que permite la instalacin de un programa malicioso en su mquina (tanto porque haya sido engaado como de forma inconsciente) est dando automticamente a ste todos sus permisos. La actividad de un virus o un
47
troyano suele ser detectada por un NIDS si genera trfico anormal de red o por un NNIDS si se ejecuta en local. Los programas de este tipo que son ms interesantes a la hora de acceder a los recursos de una mquina 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 envo de informacin local al exterior. Un ejemplo popular es el troyano Back Orifice, que encripta la comunicacin con el atacante remoto y por ello en un principio fue indetectable por los IDS del momento. Otro ejemplo clsico de troyano es el Loki Trojan [KOZI03], que basa su interactuacin 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 travs del Firewall. Este es un tpico caso de acceso autorizado, tanto por parte del usuario, que acepta la instalacin del troyano (generalmente de forma inconsciente), como por parte del administrador, que est autorizando el trfico ICMP sin considerar esta situacin.
48
3.3.
MODELOS DISTRIBUIDOS
A continuacin, se dedicarn unos cuantos apartados a la introduccin a los
modelos de sistemas distribuidos para terminar por explicar el modelo de agentes inteligentes que es en el que se basa el sistema IDSAI.
3.3.1. MODELO CLIENTE-SERVIDOR

El modelo Cliente-Servidor es hoy en da el modelo de referencia y ms difundido de comunicacin entre aplicaciones software distribuidas. Este modelo est basado en una distincin rgida 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 carcter reactivo). Los nodos cliente, por el contrario, representan la iniciativa del sistema: acceden y usan los servicios segn las necesidades del cliente aunque no proporcionan ninguna funcionalidad compleja. Los clientes pueden aparecer y desaparecer en cualquier momento, disponiendo de direcciones dinmicas mientras que los servidores al tener que garantizar un mnimo de estabilidad, suelen utilizar una direccin esttica 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 sesin de comunicacin con el servidor. Internet es el tpico ejemplo de aplicacin basada en el modelo clienteservidor. Los servidores son los sitios o portales que proporcionan la lgica de
49
aplicacin y recursos de informacin. Los clientes son los navegadores (browsers), simples herramientas que proporcionan una interfaz con el usuario y cuya nica tarea es la de realizar las peticiones y presentar la informacin solicitada. Las aplicaciones distribuidas existentes no siempre se adaptan a este modelo. Por ejemplo, una simple aplicacin de "chat", un sistema distribuido de comparticin 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 clienteservidor pura (cosa que en muchas ocasiones se hace as), se perdera la flexibilidad y escalabilidad que aportan los nodos cliente autnomos. En el momento en que los nodos cliente se comunican directamente entre s, responden a peticiones de recursos e incorporan lgica de negocio, un servidor fsico deja de ser necesario ya que su funcionalidad se ha repartido entre los dems elementos de la arquitectura. Las redes de ordenadores con funciones cliente-servidor se disponen en una topologa en estrella de servicios centralizados como se puede observar en la figura 8 [DIAZ05]:
50
Fig. 8: Arquitectura Cliente-Servidor.
51
MODELO PEER-TO-PEER (P2P)

El modelo peer-to-peer se caracteriza por no hacer distincin de roles entre cada nodo del sistema. Cada uno de los elementos que componen el modelo puede iniciar una comunicacin, siendo origen o destinatario de una peticin y pesentando o devolviendo la informacin solicitada. La lgica de la aplicacin no est concentrada en un slo sitio sino que se encuentra distribuida entre los diferentes nodos de la red; cada nodo es capaz de descubrir a los dems (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 clienteservidor, los clientes deben limitarse a conocer las direcciones estticas 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 bsqueda de recursos y descubrimiento de nodos. Estos mecanismos son generalmente conocidos como servicios de pginas blancas (descubrimiento de participantes) y pginas amarillas (bsqueda de recursos y servicios provistos por un participante desconocido). Una red P2P pura est absolutamente descentralizada y los participantes son completamente autnomos. La ausencia de un nodo de referencia hace muy difcil 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 nmero de nodos conectados. Del mismo modo, la autonoma de cada nodo a la hora de conectarse
52
y desconectarse de la red implica un sistema de seguridad y autenticacin no centralizado y por tanto potencialmente inseguro. Las redes de ordenadores con funciones peer-to-peer puras se disponen en una topologa punto a punto entre todos los nodos como se puede observar en la figura 9 [DIAZ05]:
Fig. 9: Arquitectura P2P pura.
Los inconvenientes que implica una red P2P pura hacen plantearse la idea de implantar el sistema P2P en un entorno hbrido. Las arquitecturas P2P hbridas estn basadas en un nodo especial que proporciona los servicios de bsqueda 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 (pginas blancas) y servicios disponibles (pginas amarillas) que puede ser consultado centralizadamente por los dems participantes. Este tipo de redes generan menos
53
trfico y son ms seguras, ya que la entrada a formar parte de la red por parte de un nodo requiere su registro y autenticacin en el nodo central. Por otra parte el funcionamiento correcto del sistema requiere la disponibilidad del nodo central, convirtindose ste en un punto crtico de fallo y ataques. Las redes de ordenadores con funciones peer-to-peer hbridas se disponen en una topologa punto a punto entre todos los nodos y en estrella respecto al nodo central, como se puede observar en la figura 10 [DIAZ09]:
Fig. 10: Arquitectura P2P hbrida.
El modelo peer-to-peer es el ms adecuado para implantar un sistema de agentes inteligentes .
54
3.3.2. MODELO DE AGENTES INTELIGENTES

El paradigma de los agentes inteligentes engloba conceptos de inteligencia artificial y sistemas distribuidos. Esta idea se basa en la abstraccin de la entidad agente: componente software autnomo, proactivo y social [GARA04]: o autnomo: 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 ejecucin y dentro de su nivel de conocimiento es capaz de tomar decisiones inteligentes segn su estado. o proactivo: un agente no slo 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. o 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 diseado. Un sistema distribuido basado en agentes inteligentes es intrnsecamente peer-to-peer: cada agente es un participante que necesita comunicarse con otros agentes al tiempo que es capaz de proveer de informacin y servicios al resto de participantes. El modelo de comunicacin es muy importante en un sistema basado en agentes y est basado en las siguientes premisas [BELL03]: o los agentes son entidades activas y desacopladas: la comunicacin entre agentes es de tipo asncrono, es decir, el agente que enva el mensaje y el destinatario del mismo no tienen porqu estar disponibles al mismo tiempo. Una vez un participante enva un mensaje a otro, el primero no se queda a la espera de la respuesta del
55
segundo, sino que sigue funcionando para evaluar la contestacin en el momento en que llegue. Esto permite al receptor seleccionar los mensajes a servir segn sus propias prioridades y evita que el emisor se quede bloqueado a la espera del procesado de la peticin 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 comunicacin. o los agentes realizan acciones: la comunicacin con otros agentes es una ms de las acciones que realizan los agentes inteligentes y por tanto es tratada al mismo nivel. De esta manera las acciones lgicas y las acciones de comunicacin no interfieren entre s y pueden ser planificables sobre el mismo hilo de ejecucin. o la comunicacin tiene significado semntico: un agente debe ser capaz de comprender el mensaje de una comunicacin 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 peticin de una operacin compleja en la que se puedan ver involucrados otros agentes. Todo esto significa la necesidad de implantar un protocolo semntico de comunicacin estandarizado.
En 1996, TILAB (Telecom Italian LABoratories) propuso la creacin de la FIPA (Foundation for Intelligent Physical Agents), organizacin de empresas y grupos sin nimo de lucro cuyo objetivo era el desarrollo de especificaciones estndar para la tecnologa de agentes. TILAB y en particular el equipo JADE,
56
lideraron esta iniciativa editando las primeras especificaciones del que ms tarde sera el estndar FIPA (2002). Este estndar se centra en la interoperabilidad del sistema de agentes inteligentes definiendo bien el comportamiento externo de los componentes del sistema y dejando abiertos los detalles de la implementacin interna de la lgica de negocio. El estndar FIPA es fiel al paradigma de agentes inteligentes y define el modelo de referencia de la plataforma bsica de agentes y los servicios bsicos que debe garantizar. El conjunto de servicios bsicos y sus interfaces estndar son todo lo que una sociedad de agentes necesita para existir, colaborar y ser administrada. Los servicios que el estndar FIPA determina como necesarios son [GARA04]: o 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. o Servicio de pginas blancas: Se debe disponer de un procedimiento comn para todos los agentes de la plataforma que permita referenciar un agente remoto inequvocamente. o Servicio de pginas amarillas: Se debe disponer de un procedimiento comn para todos los agentes de la plataforma que permita referenciar un servicio remoto inequvocamente sea cual sea el agente que lo proporcione. o Sistema de mensajera: La comunicacin asncrona entre agentes debe realizarse mediante un sistema de mensajera estndar, flexible y adaptable a cualquier lgica de negocio. Debido al inters en el aspecto social de los agentes y sus necesidades de comunicacin con otros agentes, el captulo Agent Comunication Language (ACL) es uno de los ms importantes del estndar FIPA.
57
3.3.3. MIDDLEWARE
Se denomina middleware al conjunto de libreras de medio-alto nivel que proveen de servicios genricos para los diferentes tipos de aplicaciones distribuidas que las implementan haciendo su desarrollo ms sencillo, y el producto software resultante ms eficiente, escalable y mantenible. Aunque no se trata propiamente de un modelo de arquitectura distribuida, forma parte de cualquier diseo de una aplicacin de este tipo de arquitecturas. Servicios como comunicacin, acceso a datos, cifrado o control de recursos son ejemplos tpicos que aporta un Sistema Operativo local. Independizando estos servicios del entorno local e integrndolos en un paquete reutilizable, se confecciona una capa horizontal que permite dar soporte a las aplicaciones distribuidas que necesiten estos servicios comunes.
Aplicaciones Aplicaciones locales middleware distribuidas
SO local + HW
Fig. 11: Capas horizontales y verticales en sistema local.
58
3.4.
TECNOLOGA JAVA JADE

Llegados a ese punto, se profundizar en el modelo de agentes inteligentes
JADE, presentando las particularidades de esta tecnologa, que ha sido preciso aprender a manejar para el desarrollo del aplicativo IDSAI. JADE (Java Agent DEvelopment Framework) es el middleware diseado por TILAB que proporciona tanto un entorno de desarrollo como un entorno de ejecucin para la realizacin y mantenimiento de de aplicaciones distribuidas multiagente basadas en la arquitectura de comunicacin peer-to-peer. La inteligencia, la iniciativa, la informacin, los recursos y el control pueden distribuirse completamente entre los terminales mviles o los equipos informticos que conformen la red. El entorno evoluciona dinmicamente con los participantes o agentes, que aparecen y desaparecen del sistema de acuerdo con las necesidades y requisitos de la aplicacin. La comunicacin entre los participantes, ya sea en una red cableada o inalmbrica es completamente simtrica asumiendo cada par de implicados el rol de origen y destinatario segn sea la situacin [BELL03]. JADE est completamente desarrollado en tecnologa 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 [BELL03]: o Interoperabilidad: JADE cumple con las especificaciones FIPA. Esto garantiza que los agentes JADE pueden interactuar con otros agentes que asuman el mismo estndar aunque no estn desarrollados necesariamente con JADE. o Uniformidad y portabilidad: JADE provee un juego de APIs independientes de la infraestructura de red y de la versin de la mquina virtual Java sobre la que se ejecuten.
59
o Intuitivo: La complejidad del middleware se encuentra encapsulada tras un simple e intuitivo interfaz de APIs. En los siguientes apartados se detallan ms aspectos de la tecnologa JADE, dentro de los modelos de arquitectura y funcional.
60
3.4.1. MODELO DE ARQUITECTURA

JADE incluye tanto las libreras necesarias para desarrollar aplicaciones multiagente como el entorno de ejecucin que provee los servicios bsicos sobre el que arrancar los agentes. Cada instancia del entorno de ejecucin 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 homognea que oculta a los agentes y al desarrollador la complejidad de las capas inferiores (Hardware,
Comunicaciones, Sistema Operativo y versin de la JVM). En cada plataforma debe existir un contenedor particular denominado contenedor principal. Este contenedor alberga dos agentes especiales, adems de los que se quieran arrancar en l [ARAN06]: o AMS (Agent Management System): Proporciona el servicio de pginas blancas. Gracias a ello permite la bsqueda 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. o DF (Directory Facilitator): Proporciona el servicio de pginas amarillas. Gracias a ello permite la bsqueda 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 pginas amarillas no funcionar adecuadamente.
61
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 dems nodos acuden para buscar otros nodos o servicios. Es por esta razn por la que podemos hablar de una arquitectura peer-to-peer hbrida cuando describimos la arquitectura de red de un sistema multiagente JADE.
Plataforma 1 Contenedor1
A2
Contenedor Principal
AMS DF A1
Contenedor2
A3 A4
RED
Fig. 12: Esquema de distribucin de agentes en contenedores de una plataforma JADE.
62
3.4.2. MODELO FUNCIONAL

Desde el punto de vista funcional, JADE proporciona los servicios bsicos necesarios para dar soporte a aplicaciones distribuidas peer-to-peer tanto en entornos fijos como en mviles. JADE permite a cada agente el descubrimiento dinmico de otros agentes y de sus funcionalidades, gracias a los servicios de pginas blancas y pginas amarillas incorporados en los agentes dedicados a tal efecto (AMS y DF) [GARA04]. La comunicacin entre agentes se realiza exclusivamente a travs de mensajes asncronos por ser el sistema ms adecuado para los sistemas distribuidos con bajo acoplamiento. La estructura de los mensajes cumple con el lenguaje estndar ACL definido por la FIPA [GARA04]: o sender: Identificador del agente remitente del mensaje. o receivers: Lista de identificadores de agentes destinatarios del mensaje. o performative: Intencin de la comunicacin. El estndar ACL fija hasta 22 tipos de performative predefinidos: INFORM (comunicar un suceso), REQUEST (solicitar un recurso o accin), QUERY-IF (preguntar por una condicin), PROPOSE (establecer una
comunicacin compleja o negociacin)... o content: Contenido del mensaje. o language: Tipo de sintaxis utilizada en el content. o ontology: Diccionario de smbolos utilizados en el content.
63
o diversos campos de control para conversaciones concurrentes, timeouts... JADE abstrae la capa de comunicaciones del sistema con una interfaz de funciones sencillas para el envo y recepcin de mensajes. Cada agente es responsable del control de su ciclo de vida estandarizado por la FIPA [BELL05]:
Create Initiated Suspended Resume Destroy Invoke Suspend Active
Move
Wake Up Execute Wait Waiting
Transit
Fig. 13: Ciclo de vida de agente definido por la FIPA.
64
Los diferentes estados del ciclo de vida de un agente JADE son los siguientes: o INITIATED: El agente se ha creado pero an no se ha registrado en el agente AMS. No dispone de nombre propio y no puede comunicarse con otros agentes. o ACTIVE: El agente est registrado en el agente AMS, tiene un nombre unvoco y puede acceder a toda la funcionalidad que proporciona la infraestructura JADE. o SUSPENDED: El agente est detenido. Su hilo de ejecucin est suspendido y no ejecuta ningn comportamiento. o WAITING: El agente est bloqueado esperando algn evento concreto. Su hilo de ejecucin est dormido y despertar en cuanto se de el evento. o TRANSIT: El agente mvil est migrando a una nueva ubicacin (a otro contenedor en el mismo u otro host). Los mensajes que lleguen a su direccin se redireccionarn a su nueva localizacin. Los cambios de estado se deben a la invocacin de las funciones del agente que llevan a cabo explcitamente los cambios de estado o a condiciones extraordinarias y excepciones que pueden implicar un cambio de estado inesperado. La orientacin de los agentes JADE a la consecucin de objetivos concretos se implementa a travs de los denominados comportamientos. Varios comportamientos arrancados por un agente se ejecutan de forma concurrente aunque lo hacen sobre el mismo hilo de ejecucin. Esto evita problemas de sincronizacin entre comportamientos que acceden a recursos comunes. Un
65
comportamiento puede interrumpirse en cualquier momento y reanudar su ejecucin en el punto en que se dej. Esto favorece la movilidad de agentes entre contenedores remotos. Algunos de los comportamientos bsicos propuestos por la distribucin bsica de JADE son los siguientes [BELL05]: o OneShotBehaviour: Comportamiento cuyo algoritmo se ejecuta una sola vez. o CyclicBehaviour: Comportamiento cuyo algoritmo se ejecuta de forma cclica; una vez que termina, vuelve a comenzar. o CompositeBehaviour: Comportamiento que se compone de diferentes sub-comportamientos que se pueden ejecutar siguiendo diferentes polticas de planificacin: de forma secuencial
(SequentialBehaviour), en paralelo (ParallelBehaviour), etc. o WakerBehaviour: Comportamiento cuyo algoritmo se ejecuta una sola vez, pasado un tiempo especificado desde su arranque. o TickerBehaviour: Comportamiento cuyo algoritmo se ejecuta peridicamente segn 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 autnoma y sin un control centralizado, es potencialmente peligrosa. En JADE, la existencia de un nodo central (agente AMS) que mantiene un registro de los agentes vivos en el sistema y garantiza el carcter unvoco de sus identificadores permite la incorporacin de funciones de seguridad de gran inters. JADE proporciona mecanismos de autenticacin y verificacin de permisos asignados a participantes que entren a formar parte de
66
una arquitectura multiagente. El sistema de intercambio de mensajes entre agentes JADE implementa sistemas de verificacin y autenticacin 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 diseado. Esto es muy cmodo a la hora de ampliar la funcionalidad de un participante permitindole aadir tareas en paralelo sin incrementar excesivamente su consumo de recursos. La sencillez del proceso de incorporacin 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 mviles, JADE asegura su eficacia con sus servicios de migracin y movilidad. Un agente JADE puede suspender su ejecucin en cualquier momento, migrar a un contenedor ubicado en un host diferente sin necesidad de instalar el cdigo del agente en el sitio remoto y recuperar su ejecucin 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 ejecucin sin significar el ms mnimo impacto en la aplicacin [BELL03]. Por ltimo, JADE proporciona un juego de herramientas grficas de soporte de gran inters que permiten la monitorizacin en tiempo de ejecucin del estado de la plataforma en todo momento. Con estas herramientas, es posible el control remoto de los agentes, la emulacin de conversaciones, la visualizacin de las comunicaciones entre agentes en vivo y la comprobacin del estado de los agentes y su ciclo de vida. La herramienta ms interesante en este
67
aspecto es el agente RMA (Remote Management Agent), cuya interfaz grfica se muestra a continuacin [ARAN06]:
Fig. 14: Interfaz grfica del agente RMA.
Slo puede existir un agente RMA por contenedor aunque puede haber varios por plataforma. La interfaz grfica del agente RMA permite las siguientes acciones de monitorizacin y control de los agentes del sistema: o Visualizar estado de la plataforma JADE, contenedores asociados y estado de los agentes arrancados en cada uno de ellos en una estructura de rbol. o Terminar la ejecucin de un agente (incluido l mismo).
68
o Terminar la ejecucin de todos los agentes de un contenedor. o Terminar la ejecucin de la plataforma en la que se encuentra. o Arrancar un nuevo agente. o Detener la ejecucin de un agente (suspenderlo). o Recuperar la ejecucin de agentes suspendidos, devolvindolos al estado activo. o Enviar un mensaje ACL a los agentes seleccionados. Una interfaz grfica detallada permite rellenar los correspondientes campos de un mensaje. o Migrar un agente de un contenedor a otro. o Clonar un agente, replicando la funcionalidad, estado y
comportamientos del agente seleccionado a un nuevo agente vivo en el contenedor que se desee. Otra de las herramientas que proporciona JADE es el agente Dummy. Este modelo de agente permite fcilmente interactuar con otros agentes y proporciona un interfaz grfico que permite construir mensajes ACL, enviarlos, almacenarlos y verlos en detalle. Este agente puede arrancarse desde el interfaz RMA. La visualizacin en tiempo real de las comunicaciones que se dan entre agentes de la plataforma es posible gracias a otro de los agentes de monitorizacin que proporciona JADE. El agente Sniffer proporciona una interfaz grfica intuitiva que permite ver el estado de las comunicaciones de los agentes deseados [ARAN06]:
69
Fig. 15: Interfaz grfica del agente Sniffer.
Los mensajes esquematizados en la interfaz se pueden consultar haciendo clic sobre ellos para ver su contenido en detalle:
70
Fig. 16: Detalles de la captura de un mensaje ACL.
71
3.5.
SNORT
El proyecto IDSAI se construye alrededor de Snort, el Sistema de Deteccin de Intrusos ms extendido en la actualidad. Este NIDS, de libre distribucin ha ido ganando adeptos con el paso del tiempo gracias a su capacidad de crecimiento y optimizacin, que lo convierten en uno de los IDS's ms rpidos de la actualidad. Fue creado en 1998 por el norteamericano Martin Roesch, que partiendo de la simple idea de un sniffer basado en tcpdump construy el esqueleto de la herramienta de deteccin de intrusos que es en la actualidad [KOZI03]. Snort utiliza una interfaz de captura basada en libpcap, librera estndar de libre distribucin disponible para multitud de plataformas, y mantiene su condicin de software libre gracias a la colaboracin de la comunidad de usuarios que da a da incorporan nuevas funcionalidades y juegos de reglas que ponen a disposicin del pblico sin afn de lucro. La extensa documentacin sobre este producto y la sencillez del diseo y distribucin de reglas hacen que la comunidad de usuarios de Snort pueda tener su IDS actualizado en todo momento, teniendo a su disposicin la mayor coleccin de patrones de ataques conocidos de todos los IDS. Snort presume de un diseo ptimo, tanto en tamao, ya que apenas ocupa unos pocos megabytes de espacio en disco, como en consumo de recursos, lo que le permite instalarse en mquinas viejas sin problema. Snort es capaz de monitorizar la informacin almacenada en todos los paquetes de una conexin saturada de hasta 100 Mbps con una configuracin estndar y empieza a perder eficacia a partir de los 200 Mbps hasta niveles de trfico superiores a 500 Mbps, que no los soporta.
72
3.5.1. MODOS DE FUNCIONAMIENTO

Snort puede funcionar de tres formas distintas, todas basadas en la captura del trfico de red mediante una interfaz promscua [DIAZ05]: o Modo Sniffer: Es el modo original y ms bsico de funcionamiento. Basado en tcpdump, lee los paquetes de red y los muestra por pantalla o los vuelca en un fichero. o Modo Logging: Ms interesante que el modo Sniffer a la hora de analizar los resultados, guarda la informacin de los paquetes recibidos de red en una estructura de directorios basada en las direcciones origen o destino de los paquetes. o Modo NIDS: La funcin ms importante de Snort es el modo de funcionamiento como Sistema de Deteccin de Intrusos. El comando de arranque de este modo incluye una referencia al fichero de configuracin de Snort, pieza clave de la optimizacin del IDS donde se definen, entre otras cosas, las listas de reglas a incorporar en el proceso de inferencia de los ataques. La construccin de un conjunto de reglas apropiado, que no pierda el tiempo analizando patrones de ataques que no se puedan dar en el sistema, y la instalacin de sensores en zonas estratgicas de la red es fundamental a la hora de obtener el mximo rendimiento en esta modalidad, que es en la que se basa el proyecto IDSAI para la capa de sensores.
73
3.5.2. COMPONENTES DE SNORT

La configuracin de Snort para maximizar su rendimiento en una instalacin requiere de amplios conocimientos sobre su estructura interna y componentes bsicos. El siguiente esquema muestra el flujo de informacin por cada una de las partes del programa, desde la captura de datos hasta la presentacin de las alertas [KOZI03]:
Decodificador de paquetes (Packet Decoder)
libpcap
Preprocesadores
Trfico de red
(Preprocessors)
Motor de inferencias (Detection Engine)
Mdulos externos (Output Plugins)
alertas
Fig. 17: Flujo de datos entre los mdulos de Snort
En los siguientes apartados se comentar cada uno de los mdulos representados en la imagen.
74
3.5.2.1. DESCODIFICADOR DE PAQUETES

Tan pronto como los paquetes son capturados por la librera libpcap, Snort descodifica los paquetes segn cada uno de los principales niveles de comunicacin: enlace, red y transporte. A medida que Snort va
almacenando en estructuras internas la informacin as recogida, se la va cediendo a los Preprocesadores correspondientes. El descodificador de paquetes de Snort dispara alertas ante condiciones anormales de paquetes de red, como cabeceras incompletas, campos de opciones de tamao inusual u obsoletos. Esto puede generar una gran cantidad de falsos positivos dependiendo de la infraestructura de red y aplicaciones que se usen en la organizacin, por lo que se pueden deshabilitar estas funciones en el propio fichero de configuracin de Snort.
75
3.5.2.2. PREPROCESADORES
Los preprocesadores de Snort son una parte fundamental de la arquitectura del programa y proporcionan diversas funciones dependiendo de cada uno de ellos. Pueden habilitarse o no, dependiendo de las necesidades de anlisis y son independientes entre s por lo que son un exponente fundamental en la flexibilidad y escalabilidad de la herramienta. La primera de sus funciones es la de examinar la informacin recogida de los paquetes de red en busca de detalles sospechosos y por tanto para detectar los ataques que no tienen un patrn claro o aquellos preparados para saltarse las reglas conocidas de Snort. La otra de sus funciones es la de normalizar los datos y prepararlos para pasarlos por el juego de reglas de Snort y facilitar la deteccin de patrones. Muchos ataques requieren del trabajo de ms de un preprocesador para ser detectados, por lo que la informacin de un paquete de red pasa por todos ellos aunque ya se haya disparado una alerta relacionada con un tipo de anomala. Los preprocesadores de Snort habilitados en el proyecto IDSAI, sin entrar en detalle en las opciones activadas en cada uno de ellos son [KOZI03]: flow: El mdulo de seguimiento de flujo (flow tracking module) es el encargado de almacenar el estado de las diferentes comunicaciones cuyos paquetes se han
interceptado. Las anomalas en la secuencia de paquetes y dems irregularidades en el orden e interpretacin de los mensajes intercambiados por los equipos de la red son detectadas por este preprocesador que disparar las alertas correspondientes.
76
frag2: El mdulo de fragmentacin es el arma de Snort frente a los ataques basados en fragmentacin. La fragmentacin es una caracterstica propia de las redes IP, que consiste en que si un mensaje es demasiado voluminoso para enviarlo en un nico paquete por el ancho de banda de una red, se puede dividir y transmitir por ella, en una secuencia numerada de paquetes ms pequeos. Esta accin propia de la capa de red y llevada a cabo por routers y hosts intermedios, es la que permite la comunicacin entre diferentes tipos de redes y protocolos, cada uno con su propia unidad mxima de transmisin (MTU, Maximum Transmission Unit). Los paquetes fragmentados deben ser reensamblados en el destino en el orden adecuado (que no tiene por qu ser el orden en que se han recibido), y en el caso de no contar con todas las partes, se disparar una peticin de reenvo. La
fragmentacin, que es una actividad automtica y predecible ha sido utilizada tpicamente por los hackers en sus ataques para que ganen en eficacia. Un paquete fragmentado es irreconocible para un Firewall o un IDS mal configurado ya que si cada una de las partes no resulta sospechosa, llegarn a su destino sin problemas y causarn el dao tras el reensamblado (comandos RPC, negaciones de servicio si el sistema se queda bloqueado con una entrada inesperada, etc.). Multitud de ataques que tratan de penetrar en una red evitando los IDS y el filtro de los Firewall incorporan esta tcnica por lo que siempre se recomienda que este preprocesador est habilitado, ya que de lo contrario, Snort no llevara un control de los fragmentos de red, y no alertara de muchas intrusiones.
77
stream4: El mdulo de control de flujo TCP es con lo que Snort controla el estado de la capa de transporte de las conexiones TCP. Es imprescindible para detectar los escaneos de puertos y otros mtodos de reconocimiento basados en explotar las vulnerabilidades del protocolo TCP. Stream4 almacena el flujo de informacin de todas las comunicaciones TCP establecidas en la red, y los evala en su conjunto para alertar de la realizacin de ataques repartidos entre varios paquetes, en los que individualmente es imposible reconocer un patrn. stream4_reassemble: Este mdulo est ntimamente
relacionado con stream4, siendo el encargado de realizar el reensamblado de todas las comunicaciones TCP para evitar situaciones similares a las de la fragmentacin en ataques repartidos entre varios ataques con mayor precisin que stream4. http_inspect: El mdulo de inspeccin de trfico HTTP es el responsable de detectar irregularidades en el trfico HTTP, y de normalizarlo para que el motor de inferencias pueda interpretarlo adecuadamente. La normalizacin consiste en traducir el contenido extrao de los paquetes (como caracteres Unicode o en hexadecimal) en un juego de caracteres que encaje con las reglas a contrastar por el motor de inferencias y as poder detectar patrones de contenido malicioso.
Http_inspect analiza con detalle las cadenas URI de las peticiones HTTP y alerta del trfico de este tipo que requiere descodificacin. La codificacin u ofuscacin de trfico HTTP es un mtodo que utilizan los hackers para evitar ser
78
descubiertos por un IDS en ataques a servidores Web aprovechando alguno de sus exploits, que no se citan aqu por ser muy especficos para cada versin de servidor. rpc_decode: Este mdulo tiene una funcionalidad similar al http_decode pero sobre el protocolo RPC. Las llamadas a procedimientos remotos son utilizadas por los hackers tanto para ataques de reconocimiento como para exploits en sistemas que admiten este protocolo. El anlisis exhaustivo de toda instruccin RPC es fundamental para encontrar patrones maliciosos en un protocolo tan delicado. BO: El preprocesador BO es el encargado de detectar la actividad del troyano Back Orifice. Este troyano tan popular descrito en el apartado 3.2.2.4: Accesos autorizados, tiene un mdulo propio en este IDS ya que su idea original ha sido adoptada por muchos otros troyanos ms avanzados. BO detecta el trfico encriptado que intercambian las
instalaciones de este troyano telnet_decode, ftp_telnet, smtp...: Son otros mdulos de deteccin de contenidos maliciosos en los paquetes de trfico de estos protocolos. Normalizan el contenido de los paquetes para evitar la ofuscacin del cdigo y alertan de las irregularidades detectadas. sfportscan: Este mdulo es el encargado de reconocer los ataques de tipo escaneo de puertos analizando la frecuencia con que se envan paquetes a diferentes puertos de los hosts de la red. Es muy importante ajustar los parmetros de este
79
preprocesador para evitar el disparo de falsos positivos por parte del IDS. arpspoof: Este mdulo est diseado para detectar trfico malicioso ARP. El protocolo ARP presente en las redes IP para asociar la direccin MAC del interfaz de red con la direccin IP del mismo y as compaginar el enrutamiento en nivel de red con el enrutamiento a nivel enlace. El protocolo ARP tiene la vulnerabilidad de que no proporciona autenticacin, por lo que si un atacante malicioso publica a los dems hosts de su red una correspondencia MAC-IP falsa, los dems lo tomarn como vlido y se producir una suplantacin de direccin MAC que provocar conflictos en el direccionamiento de paquetes a nivel enlace. Este ataque es conocido como ARP spoofing y se utiliza para interceptar comunicaciones en entornos switcheados donde un sniffer no puede intervenir el trfico. La suplantacin de ARP sirve para realizar ataques del tipo Man-in-the-middle (interceptar las comunicaciones hacia o desde un host particular) y negaciones de servicio del tipo Smurf, como la explicada en el apartado 3.2.2.2: Ataques de negacin de servicio, pero en vez de a nivel de red, a nivel enlace. SPADE: Statistical Packet Anomaly Detection Engine. Este mdulo permite la deteccin de patrones de trfico anmalos. Bsicamente implementa un tipo de inspeccin, basado en anlisis estadstico en vez de en comparacin de patrones. Para ello ser necesario el entrenamiento del mdulo en condiciones "normales" de red para que en la prctica sea capaz de detectar las diferencias. Este mdulo no se ha
80
estudiado a fondo por salirse del alcance del proyecto y por tanto no se ha implementado en la versin final de IDSAI.
81
3.5.2.3. MOTOR DE INFERENCIAS

El motor de inferencias de Snort es el componente encargado de hacer pasar la informacin recogida de los paquetes capturados de la red tras su normalizacin en los diferentes preprocesadores por cada una de las reglas que conforman la base de conocimiento de patrones de ataques. Las reglas se agrupan en ficheros editables, y son incorporadas al motor de inferencias incluyndolas en el fichero de configuracin de Snort. Hay que ser muy selectivos a la hora de aadir reglas al motor de inferencias, porque cuantas ms patrones haya que comparar para cada paquete, ms retardo acumularn en el motor y si no se es capaz de atender a todos los paquetes entrantes, se perder informacin y podrn colarse ataques. Las reglas de Snort tienen dos partes: cabecera y opciones. En la cabecera se especifican la accin, el protocolo, el origen y el destino (IP/Mscara) y los puertos. En la parte de opciones, entre parntesis, se especifica qu campos del paquete deben ser inspeccionadas y los mensajes de alerta a disparar en el caso de que coincidan todos los valores indicados en la regla. Las siguientes lneas corresponden a un ejemplo de regla que disparara una alerta si se observa un paquete tcp, de cualquier host externo por el puerto 21 a cualquier host de la red por cualquier puerto, cuyas opciones se corresponden con las especificadas entre parntesis:
alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (msg:"EXPLOIT NextFTP client overflow"; flow:to_client,established; content:"|B4| |B4|!|8B CC 83 E9 04 8B 19|3|C9|f|B9 10|"; reference:bugtraq,572; reference:cve,1999-0671; classtype:attempteduser; sid:308; rev:8;)
82
3.5.2.4. MDULOS EXTERNOS

El cdigo abierto de Snort proporciona una excelente base para aadirle multitud de interfaces de salida por las que presentar los resultados de su trabajo. Estos mdulos se habilitan en el fichero de configuracin de Snort en su arranque. Entre los mdulos de salida de Snort se encuentran los siguientes [DIAZ05]: Alert syslog: Este mdulo manda las alarmas al registro del sistema. Este mdulo permite que el usuario especifique la prioridad de las alarmas y su categora dentro de las opciones que proporciona el servicio. Alert fast/full: Imprime las alarmas en un fichero especificado con mayor o menor detalle. Alert smb/unixsock: Enva alarmas a travs de NETBIOS o sockets UNIX hacia un servidor externo que sirve como monitor del sistema y as libera de carga los sensores Snort. XML/tcpdump/CVS: Imprime las alarmas en ficheros con el formato de cada tipo que se desee. XML es un lenguaje estndar que permite la integracin de Snort con otras aplicaciones de forma universal. Tcpdump es la forma de exportar informacin que optimiza la velocidad de Snort y se puede combinar con los anteriores modos de alerta. CVS es una forma de fichero fcilmente importable a cualquier base de datos donde se pueden escoger los campos a registrar. Unified: Es el modo estndar de almacenamiento de Snort. Separa los eventos en archivos de alerta, que almacenan los
83
datos de alto nivel y archivos de log, que almacenan el paquete asociado a cada evento. SNMP: Este mdulo permite a Snort interoperar con agentes SNMP mediante el envo de traps. De este modo se integra este servicio de gestin de redes con el IDS. Base de Datos: Este mdulo permite exportar los datos de Snort a una base de datos MySQL, PostgreSQL, Oracle o UnixODBC. Es el mdulo habilitado en el sistema IDSAI, que vuelca su informacin en la base de datos estndar MySQL snortdb. Ver diagrama del diseo de la base de datos en el anexo 5: Esquema snortdb.
84
4. DESCRIPCIN FUNCIONAL
En este captulo se aborda la descripcin funcional del proyecto IDSAI, con la enumeracin y detalle de cada una de las clases que componen la aplicacin, sus dependencias y la forma en que interactan entre s. La representacin de las clases se ha realizado segn el estndar UML 2.0, obvindose los siguientes conceptos, en pos de la simplificacin de la representacin (debido a su redundancia y funcionamiento autoexplicativo): Mtodos constructores: Mtodos propios de la clase cuya misin es la instanciacin de objetos de la clase. Su lgica de programacin se basa en inicializar los atributos bsicos de la clase segn los parmetros de llamada del mtodo. No hay un nmero fijo de constructores y difieren entre s en la forma de inicializar los atributos y en los parmetros con que se invocan. Mtodos "getters": Mtodos pblicos de la clase (y por tanto invocables desde otras clases) que permiten leer el valor de sus atributos privados. Cada mtodo "getter" est asociado a un nico atributo". No tienen parmetros y devuelven una variable del mismo tipo que el atributo asociado. Mtodos "setters": Mtodos pblicos de la clase (y por tanto invocables desde otras clases) que permiten escribir el valor de sus atributos privados. Cada mtodo "setter" est asociado a un nico atributo. Tienen como nico parmetro una variable del mismo tipo que el atributo asociado. En los siguientes apartados se describirn 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 clculo. Para una visin global del diseo del sistema desde el punto de vista de la programacin, ver el
85
anexo 2: Diagrama de clases, donde en gran formato se representan cada una de las clases que se van a comentar.
86
4.1.
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 informacin.
4.1.1. DIAGRAMA DE DOMINIO

El siguiente diagrama muestra la relacin cardinal entre los conceptos de seguridad que maneja el sistema y que se detallarn en el siguiente apartado:
Fig. 18: Diagrama de dominio.
87
4.1.2. DEFINICIN DE CONCEPTOS
4.1.2.1. EVENTO (ALERTA)

Unidad de resultado bsica del IDS. Es el resultado de pasar un paquete sospechoso de red por los preprocesadores y motor de inferencias del Snort aplicndole la base de reglas del mismo. La alerta bsica de Snort aporta la siguiente informacin: CID (Component ID): Identificador unvoco de la instancia de Snort que detect la alerta. SID (Signature ID): Identificador unvoco de la firma caracterstica de la alerta detectada. RID (Revision ID): Revisin del juego de reglas que han inferido la firma. Breve descripcin de la firma caracterstica de la alerta. Clase de la firma. Prioridad de la alerta asignada por el sistema. Fecha y hora de la captura. @MAC origen y @MAC destino del paquete sospechoso. @IP origen y @IP destino del paquete sospechoso. Puertos origen y destino del paquete sospechoso.
88
Dems datos del paquete: nmero de secuencia, flags, tamao de cabeceras TCP/IP/UDP... URL de referencia para consulta va Web de detalles del tipo de firma
Ejemplo de alerta de Snort:

[**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] 04/29-20:18:41.593191 0:16:76:47:1B:AD -> 0:16:76:47:1B:6E type:0x800 192.168.20.103:51889 0x400 TcpLen: 20 -> 192.168.20.199:10005 TCP TTL:52 TOS:0x0 Win:
ID:28064 IpLen:20 DgmLen:40 **U*P**F Seq: 0x30710427 UrgPtr: 0x0
Ack: 0x0
[Xref => http://www.whitehats.com/info/IDS30]
El anlisis de las numerosas alertas que Snort genera en cortos periodos de tiempo sobre redes comprometidas no requiere de toda la informacin indicada anteriormente ya que en la mayora de los casos es redundante y/o superflua. En su lugar se ha reducido el alcance de este concepto a la clase Evento (por ser el nombre de la tabla de la base de datos de Snort que registra la informacin bsica de las alertas), representada en el sistema como sigue:
89
Donde: sid: Identificador unvoco de la instancia de Snort que detect la alerta. cid: Identificador unvoco de la alerta. signature: Identificador de la firma en la instancia actual de Snort. timestamp: Fecha y hora de la captura. iporig: @IP origen del paquete sospechoso ipdest: @IP destino del paquete sospechoso sport: Puerto origen del paquete sospechoso ipdest: Puerto destino del paquete sospechoso
90
4.1.2.2. SIGNATURE (FIRMA)

Tipo de comportamiento malicioso y conocido que se asocia a una alerta. Cada firma se corresponde con un patrn de ataque reconocible por la base de conocimientos de Snort. Un solo paquete de red sospechoso puede disparar una alerta con su firma correspondiente por s mismo, pero en general una firma, o lo que es lo mismo, un patrn, se contrasta con un conjunto de paquetes de red semejantes delimitado por el tamao del bfer que Snort es capaz de almacenar para este fin. Las signatures se clasifican en clases en base a la intencin que el evento que genera la alerta puede tener en el sistema. En funcin de este detalle, las firmas se ordenan asimismo por un valor de prioridad. El sistema IDSAI maneja este concepto con la clase Signature, que queda representada de la siguiente manera:
Donde: sig_id: Identificador de la firma en la instancia actual de Snort. signature: Descripcin breve de la firma prioridad: Valor de prioridad de la firma asignado por Snort. Valorada de 1 (mn) a 3 (mx). clase: Tipo de firma segn la intencin del ataque.
91
4.1.2.3. ATAQUE
El concepto de ataque es un concepto a veces ambiguo. En el proyecto IDSAI se define como sigue: Secuencia de eventos (alertas) con la misma signature y relativamente continuos en el tiempo (mnima separacin temporal entre eventos menor de 3 segundos). De esta forma se pretenden agrupar los eventos que, compartiendo una misma intencin (clase de signature), corresponden a una accin comn del atacante. Clasificando de esta manera los eventos, se puede introducir el concepto de compactacin eventual, valor porcentual de gran inters que indica la proporcin de eventos con cid consecutivo del ataque respecto al nmero total de eventos que lo componen. Este parmetro permite medir fcilmente la exhaustividad del ataque. Si el valor es muy alto significara que Snort solamente detecta este tipo de actividad y por tanto est experimentando una presencia clave en la red. Si por el contrario la compactacin es muy baja significa que Snort est detectando diferentes tipos de signatures y est registrando los eventos intercalando los de una y otra. De alguna manera, una compactacin alta, destaca la agresividad del ataque y por tanto una mayor exposicin de las vulnerabilidades del sistema. El sistema IDSAI almacena la informacin relativa a ataques en la siguiente estructura:
92
Donde: n_eventos: Nmero de eventos que conforman el ataque. evento1: Primer evento (Evento) del ataque. eventon: ltimo evento (Evento) del ataque. NOTA: Debe recordarse que un ataque termina de registrarse cuando se procesa la ltima alarma de la firma correspondiente o bien cuando se detecta una diferencia de ms de 3 segundos entre dos eventos con la misma firma. intervalo_temporal: Segundos transcurridos entre el primer evento del ataque y el ltimo. compactacion_eventual: Valor porcentual que indica el ratio de eventos consecutivos del ataque respecto al total. iporigmaxratio: Par de valores que indican la direccin IP de origen ms frecuente en el ataque y el valor porcentual de la cantidad de veces que se repite respecto al total de eventos. En futuros procesos ser considerado el atacante en este ataque. ipdestmaxratio: Par de valores que indican la direccin IP de destino ms frecuente en el ataque y el valor porcentual de la cantidad de veces que se repite respecto al total de eventos. En futuros procesos ser considerada la vctima en este ataque. portorigmaxratio: Par de valores que indican el puerto de origen ms frecuente en el ataque y el valor porcentual de la
93
cantidad de veces que se repite respecto al total de eventos. Pretende dar una pista sobre la aplicacin utilizada para la realizacin del ataque por parte del atacante. portdestmaxratio: Par de valores que indican el puerto de destino ms frecuente en el ataque y el valor porcentual de la cantidad de veces que se repite respecto al total de eventos. Pretende dar una pista sobre la vulnerabilidad del sistema explotada para la realizacin del ataque por parte del atacante.
94
4.1.2.4. ANOMALA
En este proyecto, el trmino de anomala cobra una importancia clave, al ser la estructura de informacin bsica que integra los conceptos descritos hasta el momento. Una anomala es, por tanto, el conjunto de ataques y eventos (agrupados en ataques) con firma comn registrados en un intervalo de tiempo concreto, al que llamaremos ventana. El sistema IDSAI generar peridicamente, segn el tamao de ventana fijado, tantas anomalas como tipos de firma haya entre las alertas disparadas por Snort. El tiempo de ventana es una variable muy importante a fijar de cara a maximizar el rendimiento de la aplicacin, ya que con valores muy pequeos (pocos segundos) apenas se detectan cambios entre ventanas y la gran cantidad de informacin devuelta es redundante y tiende a ser ignorada. Por contra, si el tiempo de ventana se fija a valores altos, la gran cantidad de datos que Snort puede registrar en un intervalo de tiempo suele ser tan grande que se hace inviable el procesamiento rpido de toda la informacin. La distribucin inicial de la aplicacin recomienda fijar este valor en el arranque del agente Reloj (ver apartado 4.2.1: Agente Reloj) a 20 segundos, ya que se considera el intervalo ms adecuado para la realizacin de pruebas de carga y rendimiento del sistema. El sistema maneja las anomalas utilizando la clase Anomalia, que se describe como sigue:
Donde:
95
ventana: Identificador de la ventana en la que se registra la anomala. tiempo: Fecha y hora de registro de la anomala. signature: Firma (Signature) comn de los eventos que conforman la anomala. eventos: Lista de eventos (Evento) que conforman la anomala. ataques: Lista de ataques (Ataque) en que se agrupan los eventos de la anomala.
96
4.1.2.5. ANLISIS
Los agentes del sistema IDSAI con una visin ms general del estado de la red no pueden trabajar a nivel de anomalas, ya que tendran que trabajar con una cantidad de informacin inmanejable. Resulta por tanto necesario simplificar las listas contenidas en la estructura Anomalia a datos estadsticos que permitan tener una visin ms general de la situacin. Un anlisis est asociado a una nica anomala y se representa en el sistema mediante la clase Analisis:
Donde: ventana: Identificador de la ventana en la que se realiza el anlisis. tiempo: Fecha y hora de registro de la anomala analizada. signature: Firma (Signature) de la anomala analizada. prioridad: Prioridad de la anomala analizada. Se obtiene en funcin de la prioridad de la firma de la anomala y el nmero
97
de eventos que la forman segn un juego de reglas fijas adaptadas a cada tipo de analista. Valorada de 1 (mx) a 6 (mn). compactacion: Compactacin de la anomala analizada. Se obtiene en funcin del nmero y compactacin eventual de los ataques que forman la anomala y de la diferencia entre la desviacin de tiempos en ataques y la media de stos, segn un juego de reglas fijas adaptadas a cada tipo de analista. Valorada de 1 (mx) a 12 (mn). media_eventosataques: Media estadstica del nmero de eventos en los ataques que forman la anomala. stdev_eventosataques: Desviacin tpica del nmero de eventos en los ataques que forman la anomala. media_tiempoataques: Media estadstica del tiempo de los ataques que forman la anomala. stdev_tiempoataques: Desviacin tpica del tiempo de los ataques que forman la anomala. iporigmaxratio: Par de valores que indican la direccin IP de origen ms frecuente en los ataques de la anomala y el valor porcentual de la cantidad de veces que se da en el conjunto. Esta direccin IP ser considerada en adelante como el atacante de la anomala. ipdestmaxratio: Par de valores que indican el puerto de destino ms frecuente en los ataques de la anomala y el valor porcentual de la cantidad de veces que se da en el conjunto.
98
Esta direccin IP ser considerada en adelante como la vctima de la anomala. portorigmaxratio: Par de valores que indican el puerto de origen ms frecuente en los ataques de la anomala y el valor porcentual de la cantidad de veces que se da en el conjunto. Este puerto dar en adelante pistas sobre la posible aplicacin utilizada para la realizacin de los ataques por parte del atacante. portdestmaxratio: Par de valores que indican el puerto de destino ms frecuente en los ataques de la anomala y el valor porcentual de la cantidad de veces que se da en el conjunto. Este puerto dar en adelante pistas sobre la vulnerabilidad explotada del sistema de la vctima para la realizacin del ataque.
99
4.1.2.6. ACUSACIN
Este concepto es necesario a la hora de relacionar todas las anomalas con misma clase de firma detectadas en una ventana. Representa simplemente la lista de firmas de las anomalas detectadas en la ventana actual con clase, y direccin IP de origen y destino comunes. Este concepto se modeliza en el proyecto IDSAI mediante la clase Acusacin como sigue:
Donde: prioridad: Prioridad de la anomala correspondiente.
Equivalente a la del anlisis. compactacion: Compactacin de la anomala analizada. signatures: Lista de estructuras (ParSig) que almacenan cada una de las firmas (Signature) de la acusacin y el par de puertos origen y destino. Como se puede observar, la informacin almacenada en la estructura Acusacin se encuentra incompleta al no indicarse dentro de ella las direcciones IP origen y destino de cada anomala. Por ello, Acusacin es una clase auxiliar fundamental en la clase Resumen, en la que s que caben conceptualmente los detalles no plasmados en esta clase.
100
4.1.2.7. RESUMEN
El carcter distribuido del sistema IDSAI requiere de una clase que contenga la informacin suficiente y necesaria para que a partir de ella se pueda tener una visin completa del estado de la red en un equipo remoto. Por este motivo, se ha confeccionado la clase Resumen, que pretende representar un resumen del estado de la red en la ventana actual desde el punto de vista de una sola clase de firma, sin almacenar toda la lista de eventos o anomalas relacionadas con ella. El resumen no solo se basa en los anlisis de la ventana actual para reflejar el estado de la red, sino que utiliza para ello un histrico de los anlisis de las ltimas 4 ventanas y la actual. De esta manera, las variaciones entre la situacin de ventanas consecutivas no varan bruscamente, evitndose situaciones confusas al tiempo que se destaca la presencia de alertas crticas, que suelen darse aisladamente y de esta forma se pueden comparar con la situacin de la red en momentos cercanos. La clase Resumen queda representada por tanto de la siguiente manera:
Donde:
101
ventana: Identificador de la ventana en la que se realiza el anlisis. tiempo: Fecha y hora de registro de la anomala analizada. fiabilidad: Fiabilidad o confianza en el agente que ha registrado el conjunto de anomalas analizadas (valorada de 1 (mn) a 10 (mx)) determinada en el arranque de ste. analisisactuales: Lista de anlisis (Analisis) de las anomalas registradas en la ventana actual. clase: Tipo de firma segn la intencin del ataque, comn a todas las anomalas analizadas. prioridad: Borrosificacin del valor medio de la prioridad de los anlisis resumidos segn un controlador borroso fijo. compactacin: Borrosificacin del valor medio de la compactacin de los anlisis resumidos segn un controlador borroso fijo. atacantes: Lista de direcciones IP de los atacantes de las anomalas analizadas. victimas: Lista de direcciones IP de las vctimas de las anomalas analizadas. acusaciones: Matriz de acusaciones (Acusacion) cuyos ndices se corresponden con los elementos de las listas "atacantes" y "victimas". Representa por tanto, para cada pareja atacante-vctima la lista de firmas (del mismo tipo de clase) de las anomalas detectadas entre dichos hosts
102
especificando los puertos origen y destino correspondientes para cada caso. Un conjunto de resmenes que engloben todas las clases de firma que el sistema sea capaz de procesar, debera dar una visin completa del estado de seguridad de la red a un agente de alto nivel.
103
4.1.2.8. DIAGNSTICO
Concepto tpico de sistema experto que trata de englobar la informacin recibida, y determinar la causa de los problemas detectados. En el sistema IDSAI representa una descripcin del estado de la red en la ventana actual y una valoracin de su situacin en base al parmetro criticidad. La codificacin de este concepto se hace mediante la clase Diagnostico. Por cuestiones de coherencia y dado que es la estructura de ms alto nivel manejada por el sistema, adems de los datos anteriores tambin necesita almacenar informacin relevante sobre los resmenes (Resumen) que sirven de base para su elaboracin:
Donde: ventana: Identificador de la ventana en la que se realizaron los resmenes que sirven de base para la elaboracin del diagnstico (no se corresponde con el tiempo en que se realiza el diagnstico) tiempo: Fecha y hora de realizacin del diagnstico.
104
atacantes: Unin sin repeticin de las listas de direcciones IP de los atacantes de todos los resmenes. victimas: Unin sin repeticin de las listas de direcciones IP de las victimas de todos los resmenes. acusaciones: Unin acumulativa de las matrices de
acusaciones de todos los resmenes. estado: Valor numrico que codifica la situacin de la red segn el nmero de atacantes y vctimas en la ventana actual. atacanteprincipal: Direccin IP del atacante con ms presencia en la red en la ventana actual. En caso de ser un estado con mltiples atacantes, esta variable almacenar aquel que protagonice el mayor nmero de firmas entre las acusaciones correspondientes a la ventana actual. victimaprincipal: Direccin IP de la vctima con ms presencia en la red en la ventana actual. En caso de ser un estado con mltiples vctimas, esta variable almacenar aquella que protagonice el mayor nmero de firmas entre las acusaciones correspondientes a la ventana actual. criticidad: Valor continuo que representa el nivel de riesgo de seguridad en la red en la ventana actual. Se obtiene a partir de los valores borrosos de la prioridad y la compactacin de cada resumen generado en la ventana actual segn un conjunto de reglas de inferencia borrosas fijas. Las inferencias borrosas devueltas se desborrosifican por el mtodo del centro de gravedad. Valorada de 1 (mx) a 10 (mn).
105
4.2.
AGENTES DEL SISTEMA

A continuacin se detallan las funcionalidades y responsabilidades de cada
uno de los agentes que integran el sistema IDSAI, elementos del dominio sobre los que trabajan y comportamientos que implementan. Todos los agentes del sistema son agentes JADE, de modo que por omisin en sus apartados correspondientes, heredan de la clase Agent cuyo esquema es el siguiente:
Donde: o setup(): Mtodo que se dispara al arrancar el agente. o takedown(): Mtodo que se dispara al matar el agente. Estos mtodos son generalmente sobrescritos por los agentes hijos para introducir su propia funcionalidad a los mismos (en la implementacin de la clase Agent, no hacen nada).
106
4.2.1. Agente RELOJ
4.2.1.1. DESCRIPCIN
El agente Reloj es el encargado de llevar la cuenta de ventanas de anlisis del sistema IDSAI. Del mismo modo es responsable de saber en todo momento que agentes se encuentran vivos en cada instante y de sincronizarlos, para mantener la coherencia temporal de los procesos del sistema. Solamente debe arrancarse un agente Reloj (de nombre "reloj") en una instalacin del sistema IDSAI. El agente Reloj se representa en el sistema con la clase AgenteReloj que tiene la estructura siguiente:
El agente Reloj debe arrancarse con el siguiente parmetro: parmetro 1: nmero entero que indica el periodo de sincronizacin de los agentes del sistema y por tanto el tamao de la ventana temporal en segundos. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
107
4.2.1.2. ATRIBUTOS
Los atributos mantenidos por la clase AgenteReloj son los siguientes: frame: Referencia a la interfaz grfica del agente. Ver apartado 4.4.2: Ventana Reloj. agentes: Lista de identificadores de los agentes vivos en el sistema en el momento actual. ventana: Contador que almacena el valor de la ventana actual.
4.2.1.3. MTODOS
El mtodo implementado en la clase AgenteReloj es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.2: Ventana Reloj. 2. Arrancar el comportamiento Recibir Notificaciones. Ver apartado 4.3.3: Recibir Notificaciones. 3. Arrancar el comportamiento Sincronizar con un periodo inicializado al valor del parmetro 1. Ver apartado 4.3.4: Sincronizar.
108
4.2.2. Agente SENSOR
4.2.2.1. DESCRIPCIN
El agente Sensor es el encargado de arrancar la instancia de Snort adecuadamente configurada para la red a analizar por el sistema IDSAI. Del mismo modo es responsable de mantener la base de datos "snortdb" actualizada en todo momento, eliminando los registros antiguos
peridicamente. La repercusin en el rendimiento del sistema que implica esta funcionalidad, ha supuesto que no se implante este proceso en la versin final del sistema. En una instalacin del sistema IDSAI, el nmero de agentes Sensores que se pueden arrancar (de nombre libre) es ilimitado. De hecho, es deseable arrancar ms de una instancia de Snort en diferentes lugares de la red, para poder recolectar informacin desde diferentes fuentes y as explotar las ventajas del sistema multiagente. Hay que destacar que en el host en que se arranque un agente Sensor es necesario arrancar una serie de agentes Intrpretes especializados en cada uno de los tipos de Signature que se desee analizar. El agente Sensor se representa en el sistema con la clase AgenteSensor que tiene la estructura siguiente:
El agente Sensor debe arrancarse con los siguientes parmetros:
109
parmetro 1: nmero que indica la interfaz de red del host que aloja el agente de donde Snort recibir la informacin de la red. Si se desea que Snort trabaje sobre un fichero de captura de red .pcap, el valor de este parmetro debe ser 0. parmetro 2: Slo es necesario introducirlo si el valor del primer parmetro es 0. Indica la ruta del fichero de captura de red .pcap sobre el que trabajar Snort. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.2.2. ATRIBUTOS
Los atributos mantenidos por la clase AgenteSensor son los siguientes: cmd: Llamada al proceso snort.exe, ubicado en la ruta C:\Snort\bin del equipo en el que se arranque el agente, utilizando el fichero de configuracin de Snort
C:\Snort\etc\IDSAI.conf previamente adaptado a la red en cuestin. proceso: Referencia al proceso snort.exe arrancado por el agente.
110
4.2.2.3. MTODOS
Los mtodos implementados en la clase AgenteSensor son los siguientes: setup(): Sobrescribe el mtodo de la clase padre. El siguiente diagrama, representa su algoritmo bsico:
INICIO
SI
parmetro1 = 0
NO
Actualizar cmd con ruta de fichero .pcap
Actualizar cmd con interfaz de red
Arrancar proceso con llamada cmd
Arrancar comportamiento Limpiar BD
FIN
Fig. 19: Mtodo setup() del agente Sensor.
111
Actualizar cmd con ruta del fichero .pcap: Actualizar atributo cmd con la ruta del fichero .pcap pasada como parmetro 2 en el arranque del agente.
Actualizar cmd con interfaz de red: Actualizar atributo cmd con la interfaz de red pasada como parmetro 1 en el arranque del agente.
Arrancar proceso con llamada cmd: Arrancar el proceso snort.exe mediante una llamada en tiempo real al sistema segn lo establecido en el atributo cmd.
Arrancar comportamiento Limpiar BD (no implantado por cuestin de rendimiento): Arrancar el comportamiento Limpiar BD. Ver apartado 4.3.5: Limpiar BD.
takedown(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Matar el proceso snort.exe referenciado por el atributo proceso.
112
4.2.3. Agente INTRPRETE
4.2.3.1. DESCRIPCIN
El agente Intrprete es el encargado de acceder peridicamente a la base de datos en busca de Anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature sobre la cual est especializado. Esta especializacin se consigue en el sistema a travs de herencia, ya que todas las especialidades de Intrprete tienen conceptos en comn y conceptos que los diferencian. En una instalacin del sistema IDSAI, el nmero de agentes Intrpretes que se pueden arrancar (de nombre libre) por cada Sensor es ilimitado. No obstante, dos agentes Intrpretes del mismo tipo accediendo a los datos recogidos por el mismo Sensor, son redundantes. El agente Intrprete se representa en el sistema con la clase AgenteInterprete que tiene la estructura siguiente:
Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.3.2. ATRIBUTOS
Los atributos mantenidos por la clase AgenteInterprete son los siguientes:
113
frame: Referencia a la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. ventana: Contador que almacena el valor de la ventana actual.
4.2.3.3. MTODOS
Los mtodos implementados en la clase AgenteInterprete son los siguientes: takedown(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Deshabilitar la interfaz grfica del agente. 2. Dar de baja el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "BAJA"
114
4.2.4. Agente INTRPRETE ATTEMPTED-ADMIN
4.2.4.1. DESCRIPCIN
El agente Intrprete Attempted-Admin es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature attempted-admin. El agente Intrprete Attempted-Admin es un agente Inteprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteAttemptedAdmin que tiene la estructura siguiente:
El agente Intrprete Attempted-Admin debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.4.2. ATRIBUTOS
Ninguno relevante aparte de los heredados.
115
4.2.4.3. MTODOS
El mtodo implementado en la clase
AgenteInterpreteAttemptedAdmin es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "attempted-admin" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
116
4.2.5. Agente INTRPRETE ATTEMPTED-DOS
4.2.5.1. DESCRIPCIN
El agente Intrprete Attempted-Dos es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature attempted-dos. El agente Intrprete Attempted-Dos es un agente Intrprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteAttemptedDos que tiene la estructura siguiente:
El agente Intrprete Attempted-Dos debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.5.2. ATRIBUTOS
117
4.2.5.3. MTODOS
El mtodo implementado en la clase AgenteInterpreteAttemptedDos es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "attempted-dos" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
118
4.2.6. Agente INTRPRETE ATTEMPTED-RECON
4.2.6.1. DESCRIPCIN
El agente Intrprete Attempted-Recon es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature attempted-recon. El agente Intrprete Attempted-Recon es un agente Intrprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteAttemptedRecon que tiene la estructura siguiente:
El agente Intrprete Attempted-Recon debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.6.2. ATRIBUTOS
119
4.2.6.3. MTODOS
AgenteInterpreteAttemptedRecon es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "attempted-recon" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
120
4.2.7. Agente INTRPRETE BAD-UNKNOWN
4.2.7.1. DESCRIPCIN
El agente Intrprete Bad-Unknown es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature bad-unknown. El agente Intrprete Bad-Unknown es un agente Intrprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteBadUnknown que tiene la estructura siguiente:
El agente Intrprete Bad-Unknown debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.7.2. ATRIBUTOS
121
4.2.7.3. MTODOS
El mtodo implementado en la clase AgenteInterpreteBadUnknown es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "bad-unknown" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
122
4.2.8. Agente INTRPRETE OTROS
4.2.8.1. DESCRIPCIN
El agente Intrprete Otros es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signatures en las que no est especializado en particular ningn otro Intrprete en el sistema IDSAI. El agente Intrprete Otros es un agente Intrprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteOtros que tiene la estructura siguiente:
El agente Intrprete Otros debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.8.2. ATRIBUTOS
123
4.2.8.3. MTODOS
El mtodo implementado en la clase AgenteInterpreteOtros es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "otros" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
124
4.2.9.
Agente INTRPRETE UNKNOWN-CLASS
4.2.9.1. DESCRIPCIN
El agente Intrprete Unknown-Class es el Intrprete especializado en la busca de anomalas (Ver apartado 4.1.2.4: Anomala) de la clase de signature Unknown-Class. El agente Intrprete Unknown-Class es un agente Intrprete (hereda de AgenteInterprete) que se representa en el sistema con la clase AgenteInterpreteUnknownClass que tiene la estructura siguiente:
El agente Intrprete Unknown-Class debe arrancarse con el siguiente parmetro: parmetro 1: nmero que indica la fiabilidad de la informacin recogida en el host que aloja el agente de donde Snort recibir la informacin de la red. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.2.9.2. ATRIBUTOS
125
4.2.9.3. MTODOS
El mtodo implementado en la clase AgenteInterpreteUnknownClass es el siguiente: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.3: Ventana Agente. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Obtener Anomalas con la especialidad "unknown-class" y la fiabilidad segn el parmetro 1. Ver apartado 4.3.6: Obtener Anomalas.
126
4.2.10.
Agente ANALISTA
4.2.10.1. DESCRIPCIN
El agente Analista es el encargado de extraer valores estadsticos del conjunto de Anomalas recibidas del correspondiente agente Intrprete. Estos datos permiten tener una visin ms general acerca de la situacin de la red desde el punto de vista de la clase de signature sobre la cual est especializado el agente. Esta especializacin se representa en el sistema a travs de herencia tal y como se describir en las siguientes subsecciones, ya que todas las especialidades de Analista tienen conceptos en comn y conceptos que los diferencian. Se debe arrancar un agente Analista por cada clase de Signature que se desee analizar en la instalacin del sistema IDSAI (de nombre "analista"+tipo). El agente Analista se representa en el sistema con la clase AgenteAnalista que tiene la estructura siguiente:
127
4.2.10.2. ATRIBUTOS
Los atributos mantenidos por la clase AgenteAnalista son los siguientes: frame: Referencia a la interfaz grfica del agente. Ver apartado 4.4.5: Ventana Agente Analista. analisis: Lista de Anlisis realizados. Ver apartado 4.1.2.5: Anlisis. anomalias: Lista de Anomalas recibidas. Ver apartado 4.1.2.4: Anomala. ventana: Contador que almacena el valor de la ventana actual.
4.2.10.3. MTODOS
Los mtodos implementados en la clase AgenteAnalista son los siguientes: takedown(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Deshabilitar la interfaz grfica del agente. 2. Dar de baja el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj"
128
Content = "BAJA"
129
4.2.11.
Agente ANALISTA ATTEMPTED-ADMIN
El agente Analista Attempted-Admin es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de clase attempted-admin. El agente Analista Attempted-Admin es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase AgenteAnalistaAttemptedAdmin que tiene la estructura siguiente:
4.2.11.2. ATRIBUTOS
4.2.11.3. MTODOS
AgenteAnalistaAttemptedAdmin es el siguiente:
130
setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.5: Ventana Agente Analista. 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Analizar Anomalas Attempted-Admin. Ver apartado 4.3.8: Analizar Anomalas Attempted-Admin.
131
4.2.12.
Agente ANALISTA ATTEMPTED-DOS
El agente Analista Attempted-Dos es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de clase attempted-dos. El agente Analista Attempted-Dos es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase
AgenteAnalistaAttemptedDos que tiene la estructura siguiente:
4.2.12.2. ATRIBUTOS
4.2.12.3. MTODOS
El mtodo implementado en la clase AgenteAnalistaAttemptedDos es el siguiente:
132
3. Arrancar el comportamiento Analizar Anomalas Attempted-Dos. Ver apartado 4.3.9: Analizar
Anomalas Attempted-Dos.
133
4.2.13.
Agente ANALISTA ATTEMPTED-RECON
El agente Analista Attempted-Recon es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de clase attempted-recon. El agente Analista Attempted-Recon es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase AgenteAnalistaAttemptedRecon que tiene la estructura siguiente:
4.2.13.2. ATRIBUTOS
4.2.13.3. MTODOS
AgenteAnalistaAttemptedRecon es el siguiente:
134
3. Arrancar el comportamiento Analizar Anomalas Attempted-Recon. Ver apartado 4.3.10: Analizar Anomalas Attempted-Recon.
135
4.2.14.
Agente ANALISTA BAD-UNKNOWN
El agente Analista Bad-Unknown es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de clase bad-unknown. El agente Analista Bad-Unknown es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase
AgenteAnalistaBadUnknown que tiene la estructura siguiente:
4.2.14.2. ATRIBUTOS
4.2.14.3. MTODOS
El mtodo implementado en la clase AgenteAnalistaBadUnknown es el siguiente:
136
setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.5: Ventana Agente Analista 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Analizar Anomalas BadUnknown. Ver apartado 4.3.11: Analizar Anomalas Bad-Unknown.
137
4.2.15.
Agente ANALISTA OTROS
El agente Analista Otros es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de la clase de signatures en las que no est especializado en particular ningn otro Analista en el sistema IDSAI. El agente Analista Otros es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase
AgenteAnalistaOtros que tiene la estructura siguiente:
4.2.15.2. ATRIBUTOS
4.2.15.3. MTODOS
El mtodo implementado en la clase AgenteAnalistaOtros es el siguiente:
138
3. Arrancar el comportamiento Analizar Anomalas Otros. Ver apartado 4.3.12: Analizar Anomalas Otros.
139
4.2.16.
Agente ANALISTA UNKNOWN-CLASS
El agente Analista Unknown-Class es el Analista especializado en la realizacin de Anlisis (Ver apartado 4.1.2.5: Anlisis) de las Anomalas de clase unknown-class. El agente Analista Unknown-Class es un agente Analista (hereda de AgenteAnalista) que se representa en el sistema con la clase
AgenteAnalistaUnknownClass que tiene la estructura siguiente:
4.2.16.2. ATRIBUTOS
4.2.16.3. MTODOS
El mtodo implementado en la clase AgenteAnalistaUnknownClass es el siguiente:
140
3. Arrancar el comportamiento Analizar Anomalas Unknown-Class. Ver apartado 4.3.13: Analizar Anomalas Unknown-Class.
141
4.2.17.
Agente SUPERVISOR
El agente Supervisor representa la capa superior de la arquitectura del sistema IDSAI. Es el encargado de presentar al usuario las incidencias ocurridas en el sistema a grandes rasgos y de forma grfica, encapsulando el nivel de detalle con el que trabajan los agentes Analistas e Intrpretes, por debajo de l en la arquitectura multiagente. Partiendo del conjunto de Resmenes recibidos de los agentes Analistas del sistema, devuelve un Diagnstico, nico para cada ventana temporal, que refleja la situacin actual del sistema. Asimismo, a la hora de presentar los resultados al usuario compara el Diagnstico de la ventana actual con el de la anterior para dar una explicacin textual de los cambios acontecidos. La interfaz grfica que incorpora este agente, junto con las de los agentes que le sirven de fuente, permite la navegacin hacia atrs de forma que el usuario que desee profundizar en el detalle de la situacin mostrada por el Diagnstico, puede hacerlo siguiendo la traza del mismo. Solamente debe arrancarse un agente Supervisor (de nombre "supervisor") en una instalacin del sistema IDSAI. El agente Supervisor se representa en el sistema con la clase AgenteSupervisor que tiene la estructura siguiente:
142
4.2.17.2. ATRIBUTOS
Los atributos mantenidos por la clase AgenteSupervisor son los siguientes: frame: Referencia a la interfaz grfica del agente. Ver apartado 4.4.7: Ventana Agente Supervisor. ultimodiagnostico: Almacena el ltimo Diagnstico realizado por el agente en el tiempo, es decir, el correspondiente a la ventana actual del sistema. Ver apartado 4.1.2.8:
Diagnstico. diagnosticos: Lista de Diagnsticos realizados. Ver apartado 4.1.2.8: Diagnstico. resumenes: Lista de Resmenes recibidos. Ver apartado 4.1.2.7: Resumen.
143
ventana: Contador que almacena el valor de la ventana actual. topatacantes: Lista de los 5 atacantes principales en la red. topvictimas: Lista de las 5 vctimas principales en la red.
4.2.17.3. MTODOS
Los mtodos implementados en la clase AgenteAnalista son los siguientes: setup(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Arrancar la interfaz grfica del agente. Ver apartado 4.4.7: Ventana Agente Supervisor 2. Dar de alta el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "ALTA"
3. Arrancar el comportamiento Diagnosticar Resmenes. Ver apartado 4.3.14: Diagnosticar Resmenes.
144
takedown(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Deshabilitar la interfaz grfica del agente. 2. Dar de baja el agente en el sistema, enviando un mensaje ACL al agente Reloj del sistema con la siguiente forma: Receiver = "reloj" Content = "BAJA"
145
4.3.
COMPORTAMIENTOS
A continuacin se detallan las funcionalidades y responsabilidades de cada
uno de los comportamientos que implementan los agentes que integran el sistema IDSAI. Todos los comportamientos del sistema son instancias de clases que heredan de comportamientos JADE, ms concretamente de los comportamientos Peridico y Cclico que se pasan a detallar a continuacin junto con los dems comportamientos desarrollados en el sistema.
146
4.3.1. PERIDICO
Comportamiento JADE que ejecuta peridicamente su mtodo principal segn el periodo introducido como parmetro de su constructor. El comportamiento Peridico se representa en el sistema con la clase TickerBehaviour, que tiene la estructura resumida siguiente:
4.3.1.1. ATRIBUTOS
Ninguno relevante en el proyecto IDSAI.
4.3.1.2. MTODOS
El mtodo ms relevante implementado en la clase TickerBehaviour es el siguiente: onTick(): Mtodo principal que se ejecuta peridicamente segn el periodo especificado en el constructor de la clase. Este mtodo es sobrescrito por los agentes hijos para introducir su propia funcionalidad (en la implementacin de la clase TickerBehaviour, no hace nada).
147
4.3.2. CCLICO
Comportamiento JADE que ejecuta cclicamente su mtodo principal. El comportamiento Cclico se representa en el sistema con la clase CyclicBehaviour, que tiene la estructura resumida siguiente:
4.3.2.1. ATRIBUTOS
4.3.2.2. MTODOS
El mtodo ms relevante implementado en la clase TickerBehaviour es el siguiente: action(): Mtodo principal que se ejecuta de forma continua, desde el arranque del comportamiento. Este mtodo es sobrescrito por los agentes hijos para introducir su propia funcionalidad (en la implementacin de la clase CyclicBehaviour, no hace nada).
148
4.3.3. RECIBIR NOTIFICACIONES

Comportamiento dedicado a mantener actualizada la lista de
identificadores de agentes vivos que es atributo del agente que lo implementa (agente Reloj). El comportamiento Recibir Notificaciones es un comportamiento Cclico (hereda de CyclicBehaviour) que se representa en el sistema con la clase BehaviourRecibirNotificaciones que tiene la estructura siguiente:
4.3.3.1. ATRIBUTOS
El atributo mantenido por la clase BehaviourRecibirNotificaciones es el siguiente: agente: Referencia al agente que implementa el
comportamiento. Ver apartado 4.2.1: Agente Reloj.
4.3.3.2. MTODOS
El mtodo implementado en la clase BehaviourRecibirNotificaciones es el siguiente:
149
action(): Sobrescribe el mtodo de la clase padre. El siguiente diagrama, representa su algoritmo bsico:
INICIO
mensaje recibido? SI
NO
nuevo ciclo NO contenido = "ALTA"? SI
Eliminar remitente de la lista de agentes vivos
Aadir remitente a la lista de agentes vivos
FIN
Fig. 20: Mtodo action() del comportamiento Recibir Notificaciones.
Eliminar remitente de la lista de agentes vivos: Buscar remitente del mensaje en el ArrayList "agentes" que es atributo del agente que implementa el comportamiento (agente Reloj) y eliminar dicha posicin. La bsqueda es lineal, de principio a fin del array hasta que se encuentre el elemento. El elemento siempre debera encontrarse salvo caso de error extraordinario, en cuyo caso no se hace nada,
150
porque el elemento a borrar ya no estara en la lista. Finalmente, se actualiza la interfaz grfica del agente Reloj invocando la funcin actualizarTabla() de la clase FrameReloj. Ver apartado 4.4.2: Ventana Reloj.
Aadir remitente a la lista de agentes vivos: Aadir remitente del mensaje al final del ArrayList "agentes" que es atributo del agente que implementa el comportamiento (agente Reloj). Finalmente, se actualiza la interfaz grfica del agente Reloj invocando la funcin actualizarTabla() de la clase FrameReloj. Ver apartado 4.4.2: Ventana Reloj.
151
4.3.4. SINCRONIZAR
Comportamiento dedicado a mantener el control de la ventana temporal de todos los agentes del sistema. El comportamiento Sincronizar es un comportamiento Peridico (hereda de TickerBehaviour) que se representa en el sistema con la clase BehaviourSincronizar que tiene la estructura siguiente:
4.3.4.1. ATRIBUTOS
Los atributos mantenidos por la clase BehaviourSincronizar son los siguientes: agente: Referencia al agente que implementa el
comportamiento. Ver apartado 4.2.1: Agente Reloj. contadorventana: Entero que mantiene el valor de la ventana actual del sistema.
152
4.3.4.2. MTODOS
El mtodo implementado en la clase BehaviourSincronizar es el siguiente: onTick(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Incrementar el valor del atributo contadorventana. 2. Actualizar la interfaz grfica del agente Reloj invocando la funcin actualizarContador() de la clase FrameReloj. Ver apartado 4.4.2: Ventana Reloj. 3. Sincronizar cada uno de los agentes vivos enviando un mensaje ACL a cada uno de ellos (recorriendo la lista de agentes actuales que es atributo del agente que implementa el comportamiento. Ver apartado 4.3.3: Recibir Notificaciones.) con la siguiente forma: Performative = valor del atributo contadorventana Language = "sync" Content = tamao de la ventana con la que se ha arrancado el comportamiento (parmetro periodo). Dado el carcter peridico de este mtodo, se garantiza que todo agente vivo en el sistema recibe a intervalos constantes un mensaje como el anteriormente indicado con el valor de Performative actualizado.
153
4.3.5. LIMPIAR BD
Comportamiento dedicado a mantener la base de datos "snortdb" con un volumen de datos aceptable, eliminando los registros antiguos peridicamente. Esta funcionalidad es muy costosa para el sistema gestor de bases de datos e influye considerablemente en el acceso a la informacin de los agentes arrancados en paralelo. Por esta razn se ha optado por no implantar este proceso en la versin final del sistema, aunque queda pendiente para futuras revisiones. El comportamiento Limpiar BD es un comportamiento Peridico (hereda de TickerBehaviour) que se representa en el sistema con la clase BehaviourLimpiarBD que tiene la estructura siguiente:
4.3.5.1. ATRIBUTOS
Los atributos mantenidos por la clase BehaviourLimpiarBD son los siguientes: ret: Cdigo de retorno de las llamadas al sistema gestor de bases de datos a travs de las llamadas a las funciones de la capa de persistencia.
154
segundos: Entero largo que indica el margen desde el momento actual en que se mantienen los registros antiguos de la base de datos (los anteriores se eliminan).
4.3.5.2. MTODOS
El mtodo implementado en la clase BehaviourLimpiarBD es el siguiente: onTick(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Llama a la funcin de la capa de persistencia eliminarEventosAnterioresA() con el nmero de segundos que es atributo de esta clase. Ver apartado 4.6.1: Evento DAO.
155
4.3.6. OBTENER ANOMALAS

Comportamiento dedicado a buscar peridicamente anomalas (Ver apartado 4.1.2.4: Anomala) del tipo especificado en el arranque, en la base de datos snortdb alojada en el host donde Snort vuelca la informacin obtenida de la red. El comportamiento Obtener Anomalas es un comportamiento Cclico (hereda de CyclicBehaviour) que se representa en el sistema con la clase BehaviourObtenerAnomalas que tiene la estructura siguiente:
4.3.6.1. ATRIBUTOS
Los atributos mantenidos por la clase BehaviourObtenerAnomalias son los siguientes: agente: Referencia al agente que implementa el
comportamiento. (Ver apartado 4.2.3: Agente Intrprete). tipo: Especialidad del agente Intrprete que implementa el comportamiento.
156
fiabilidad: valoracin numrica de la fiabilidad de la informacin recogida por este comportamiento que es indicada en la construccin del agente Intrprete que lo implementa.
4.3.6.2. MTODOS
El mtodo implementado en la clase BehaviourObtenerAnomalias es el siguiente: action(): Sobrescribe el mtodo de la clase padre. El siguiente diagrama, representa su algoritmo bsico:
157
INICIO
mensaje recibido? SI Actualizar ventana del agente Intrprete
NO
Obtener Anomalas
nuevo ciclo
NO
anomalas recibidas? SI Enviar Anomalas
FIN
Fig. 21: Mtodo action() del comportamiento Obtener Anomalas.
Actualizar ventana del agente Intrprete: Actualizar el valor del atributo ventana del agente Intrprete que implementa el comportamiento. Ver apartado 4.2.3: Agente Intrprete.
Obtener Anomalas: Obtener la lista de anomalas de la clase de la que es especialista el agente Intrprete que
158
implementa el comportamiento. Para ello se invoca la funcin de la capa de persistencia obtenerAnomalias() con el tipo de clase especificada por el atributo tipo de este comportamiento. Ver apartado 4.5.2: Anomala DAO. Enviar Anomalas: Enviar un mensaje ACL al agente Analista, especializado en la clase de signature en que est especializado el agente Intrprete que implementa este comportamiento, con la siguiente forma: Receiver = "analista"+tipo Content = Lista de anomalias de la misma clase obtenidas anteriormente Language = "data" Performative = fiabilidad
159
4.3.7. ANALIZAR ANOMALAS

Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.10: Agente Analista). De esta forma, este comportamiento introduce en el sistema el concepto Anlisis (Ver apartado 4.1.2.5: Anlisis). El manejo de un Anlisis por cada Anomala recibida se considera inviable en niveles superiores de la arquitectura, por lo que es este proceso el que construye la estructura Resumen (Ver apartado 4.1.2.7: Resumen) que es el producto final del agente Analista. Finalmente, este comportamiento permite a su vez la sincronizacin del agente Analista que lo implementa. El comportamiento Analizar Anomalas es un comportamiento Cclico (hereda de CyclicBehaviour) que se representa en el sistema con la clase BehaviourAnalizarAnomalas que tiene la estructura siguiente:
4.3.7.1. ATRIBUTOS
Los atributos mantenidos por la clase BehaviourObtenerAnomalias son los siguientes:
160
agente:
Referencia
al
agente
que
implementa
el
comportamiento. (Ver apartado 4.2.10: Agente Analista). tipo: Especialidad del agente Analista que implementa el comportamiento.
4.3.7.2. MTODOS
Los mtodos implementados en la clase
BehaviourAnalizarAnomalias son los siguientes: action(): Sobrescribe el mtodo de la clase padre. El siguiente diagrama, representa su algoritmo bsico:
161
INICIO
mensaje recibido? SI SI
NO
mensaje de sincronizacin?
NO (lista de Anomalas) for Anomala
Actualizar ventana del agente Analista Actualizar anomalas del agente Analista Limpiar anomalas del agente Analista Realizar Anlisis de la Anomala actual Limpiar anlisis del agente Analista
Realizar Resumen de los Anlisis actuales
Enviar Resumen
FIN
Fig. 22: Mtodo action() del comportamiento Analizar Anomalas.
162
Actualizar ventana del agente Analista: Actualizar el valor del atributo ventana del agente Analista que implementa el comportamiento. Ver apartado 4.2.10: Agente Analista.
Limpiar anomalas del agente Analista: Eliminar de la lista de anomalas recibidas del agente Analista, representada en el sistema por el atributo anomalias, aquellas que lleven almacenadas ms de 20 ventanas. Externalizar al fichero de log anomalias.txt la informacin eliminada y actualizar la interfaz grfica.
Limpiar anlisis del agente Analista: Eliminar de la lista de anlisis realizados por el agente Analista, representada en el sistema por el atributo analisis, aquellos que lleven almacenados ms de 20 ventanas. Externalizar al fichero de log analisis.txt la informacin eliminada y actualizar la interfaz grfica.
Actualizar anomalas del agente Analista: Introducir la Anomala considerada en el bucle actual en la lista de anomalas recibidas del agente Analista, representada en el sistema por el atributo anomalias. Actualizar la interfaz grfica.
Realizar Anlisis de la Anomala actual: Invocar el mtodo local realizarAnalisis() sobre la anomala
considerada en el bucle actual. Introducir el Anlisis obtenido en la lista de anlisis realizados por el agente
163
Analista, representada en el sistema por el atributo analisis. Actualizar la interfaz grfica. Realizar Resumen de los Anlisis actuales: Invocar el mtodo local resumir() sobre la lista de anlisis realizados en el bucle anterior y pasndole la fiabilidad del agente Intrprete de quien se recibieron las correspondientes Anomalas.
Enviar Resumen: Enviar un mensaje ACL al agente Supervisor, con la siguiente forma: Receiver = "supervisor" Content = Resumen obtenido anteriormente Language = "data"
resumir(): Elabora y retorna el Resumen asociado al conjunto de Anlisis pasados como parmetro. El siguiente diagrama, representa su algoritmo bsico:
164
INICIO
for Anlisis
Obtener lista de atacantes
Obtener lista de vctimas
Obtener prioridad media
Obtener compactacin media
Borrosificar prioridad media
Borrosificar compactacin media
Obtener matriz de Acusaciones
Construir Resumen
FIN (devolver Resumen)
Fig. 23: Mtodo resumir() del comportamiento Analizar Anomalas.
165
Obtener lista de atacantes: Obtener lista de los atacantes que han participado en los Anlisis a resumir.
Obtener lista de vctimas: Obtener lista de las vctimas que han participado en los Anlisis a resumir.
Obtener prioridad media: Obtener prioridad media de los Anlisis a resumir.
Obtener compactacin media: Obtener compactacin media de los Anlisis a resumir.
Borrosificar prioridad media: Obtener el valor borroso de la prioridad media de los Anlisis a resumir, invocando la funcin de control borroso borrosificarprioridad(). Ver apartado 4.6.2: Control Borroso.
Borrosificar compactacin media: Obtener el valor borroso de la compactacin media de los Anlisis a resumir, invocando la funcin de control borroso borrosificarcompactacin(). Ver apartado 4.6.2: Control Borroso.
Obtener matriz de Acusaciones: Recorrer las listas de atacantes y vctimas junto con la lista de Anlisis para obtener la matriz de Acusaciones caracterstica del Resumen para el conjunto de Anomalas analizadas. Ver apartado 4.1.2.6: Acusacin.
Construir
Resumen:
Construir
estructura
Resumen
integrando la informacin anteriormente obtenida: listas
166
de atacantes y vctimas, prioridad y compactacin borrosas y matriz de acusaciones.
realizarAnalisis(): Extrae valores estadsticos de la Anomala que se le pasa como parmetro introduciendo la estructura Anlisis en el sistema. Ver apartado 4.1.2.5: Anlisis. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Obtener media del nmero de eventos por Ataque. 2. Obtener desviacin tpica del nmero de eventos por Ataque. 3. Obtener media de la duracin de los Ataques de la Anomala. 4. Obtener desviacin tpica de la duracin de los Ataques de la Anomala. 5. Obtener el ratio de tiempo en que se dan Ataques compactos respecto al total del tiempo de la Anomala. 6. Realizar el clculo heurstico de la prioridad y compactacin del Anlisis en base a la Anomala analizada y el ratio obtenido anteriormente. Para ello se invoca el mtodo local realizarAnalisisParticular(). 7. Obtener la direccin IP de origen predominante entre los eventos de la Anomala.
167
8. Obtener la direccin IP de destino predominante entre los eventos de la Anomala. 9. Obtener el puerto origen predominante entre los eventos de la Anomala. 10. Obtener el puerto destino predominante entre los eventos de la Anomala. 11. Construir estructura Anlisis integrando toda la informacin anteriormente obtenida. Ver apartado 4.1.2.5: Anlisis. realizarAnalisisParticular(): Mtodo abstracto que debe ser sobrescrito por los comportamientos que hereden de BehaviourAnalizarAnomalias. Deber incorporar las reglas de clculo de la prioridad y compactacin del Anlisis de forma especializada para cada tipo de agente Analista que implemente el comportamiento hijo.
168
4.3.8. ANALIZAR ANOMALAS ATTEMPTED-ADMIN

Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.11: Analista Attempted-Admin). El comportamiento Analizar Anomalas Attempted-Admin es un comportamiento de Analizar Anomalas (hereda de
BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasAttemptedAdmin que tiene la estructura siguiente:
4.3.8.1. ATRIBUTOS
4.3.8.2. MTODOS
BehaviourAnalizarAnomaliasAttemptedAdmin son los siguientes:
169
realizarAnalisisParticular(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Realizar el clculo especializado de la compactacin eventual de la Anomala y segn el ratio de tiempo de ataques pasados como parmetros. Para ello se invoca el mtodo local reglasCompactacion(). 2. Realizar el clculo especializado de la prioridad de la Anomala pasada como parmetro. Para ello se invoca el mtodo local reglasPrioridad(). 3. Devolver el Anlisis pasado como parmetro
actualizados sus atributos con los nuevos valores de compactacin y prioridad.
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo attempted-admin del anexo 6: Signatures IDSAI (Snort).
reglasPrioridad(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la prioridad de la Anomala pasada como parmetro. Ver rbol de decisin Prioridad del
170
captulo attempted-admin del anexo 6: Signatures IDSAI (Snort).
171
4.3.9. ANALIZAR ANOMALAS ATTEMPTED-DOS

Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.12: Analista Attempted-Dos). El comportamiento de Analizar Analizar Anomalas Attempted-Dos (hereda es un de
comportamiento
Anomalas
BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasAttemptedDos que tiene la estructura siguiente:
4.3.9.1. ATRIBUTOS
4.3.9.2. MTODOS
BehaviourAnalizarAnomaliasAttemptedDos son los siguientes:
172
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo attempted-dos del anexo 6: Signatures IDSAI (Snort).
173
captulo attempted-dos del anexo 6: Signatures IDSAI (Snort).
174
4.3.10.
ANALIZAR ANOMALAS ATTEMPTED-RECON
Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.13: Analista Attempted-Recon). El comportamiento Analizar Anomalas Attempted-Recon es un comportamiento de Analizar Anomalas (hereda de
BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasAttemptedRecon que tiene la estructura siguiente:
4.3.10.1. ATRIBUTOS
4.3.10.2. MTODOS
BehaviourAnalizarAnomaliasAttemptedRecon son los siguientes:
175
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo attempted-recon del anexo 6: Signatures IDSAI (Snort).
176
captulo attempted-recon del anexo 6: Signatures IDSAI (Snort).
177
4.3.11.
ANALIZAR ANOMALAS BAD-UNKNOWN
Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.13: Analista Bad-Unknown). El comportamiento de Analizar Analizar Anomalas Bad-Unknown (hereda es un de
comportamiento
Anomalas
BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasBadUnknown que tiene la estructura siguiente:
4.3.11.1. ATRIBUTOS
4.3.11.2. MTODOS
BehaviourAnalizarAnomaliasBadUnknown son los siguientes:
178
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo bad-unknown del anexo 6: Signatures IDSAI (Snort).
reglasPrioridad(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la prioridad de la Anomala
179
pasada como parmetro. Ver rbol de decisin Prioridad del captulo bad-unknown del anexo 6: Signatures IDSAI (Snort).
180
4.3.12.
ANALIZAR ANOMALAS OTROS
Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.15: Analista Otros). El comportamiento Analizar Anomalas Otros es un comportamiento de Analizar Anomalas (hereda de BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasOtros que tiene la estructura siguiente:
4.3.12.1. ATRIBUTOS
4.3.12.2. MTODOS
BehaviourAnalizarAnomaliasOtros son los siguientes:
181
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo otros del anexo 6: Signatures IDSAI (Snort).
reglasPrioridad(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la prioridad de la Anomala
182
pasada como parmetro. Ver rbol de decisin Prioridad del captulo otros del anexo 6: Signatures IDSAI (Snort).
183
4.3.13.
ANALIZAR ANOMALAS UNKNOWN-CLASS
Comportamiento dedicado a extraer valores estadsticos del conjunto de Anomalas recibidas por el agente que lo implementa (Ver apartado 4.2.14: Analista Unknown-Class). El comportamiento de Analizar Analizar Anomalas Unknown-Class (hereda es un de
comportamiento
Anomalas
BehaviourAnalizarAnomalias) que se representa en el sistema con la clase BehaviourAnalizarAnomaliasUnknownClass que tiene la estructura siguiente:
4.3.13.1. ATRIBUTOS
4.3.13.2. MTODOS
BehaviourAnalizarAnomaliasUnknownClass son los siguientes:
184
reglasCompactacion(): Juego de reglas especfico para el tipo de signature en la que es experto el agente Analista que devuelve el valor numrico entero de la compactacin de la Anomala pasada como parmetro. Ver rbol de decisin Compactacin del captulo unknown-class del anexo 6: Signatures IDSAI (Snort).
185
captulo unknown-class del anexo 6: Signatures IDSAI (Snort).
186
4.3.14.
DIAGNOSTICAR RESMENES
Comportamiento dedicado a realizar el Diagnstico (ver apartado 4.1.2.8: Diagnstico) correspondiente a la ventana temporal actual en base a los Resmenes (ver apartado 4.1.2.7: Resumen) recibidos por el agente que lo implementa (Ver apartado 4.2.17: Agente Supervisor). De esta forma, este comportamiento introduce en el sistema el concepto Diagnstico (Ver apartado 4.1.2.8: Diagnstico). Debido a la gran importancia de la interfaz grfica del agente Supervisor, este comportamiento interviene directamente en la actualizacin de los elementos visuales de la Ventana Agente Supervisor (ver apartado 4.4.7: Ventana Agente Supervisor) a medida que se alteran los atributos del agente. Finalmente, este comportamiento permite a su vez la sincronizacin del agente Supervisor. El comportamiento Diagnosticar Resmenes es un comportamiento Cclico (hereda de CyclicBehaviour) que se representa en el sistema con la clase BehaviourDiagnosticarResumenes que tiene la estructura siguiente:
4.3.14.1. ATRIBUTOS
El atributo mantenido por la clase BehaviourDiagnosticarResumenes es el siguiente:
187
agente:
Referencia
al
agente
que
implementa
el
comportamiento. (Ver apartado 4.2.17: Agente Supervisor).
4.3.14.2. MTODOS
BehaviourDiagnosticarResumenes es el siguiente: action(): Sobrescribe el mtodo de la clase padre. El siguiente diagrama, representa su algoritmo bsico:
188
INICIO
mensaje recibido?
NO
SI SI mensaje de sincronizacin? NO (Resumen)
Seleccionar Resmenes actuales
Insertar Resumen en lista de resmenes del agente Supervisor
Realizar listas de atacantes y vctimas
Realizar Diagnstico cuantitativo
Actualizar tabla de Resmenes
Realizar Diagnstico cualitativo
Realizar Diagnstico comparativo
Crear Diagnstico
Actualizar tops
Limpiar Resmenes
Limpiar Diagnsticos
Pintar ltimo Diagnstico
FIN
189
Fig. 24: Mtodo action() del comportamiento Diagnosticar Resmenes.
Insertar Resumen en lista de resmenes
del
agente
Supervisor: Insertar el Resumen de la ventana actual en la lista de resmenes recibidos que es el atributo resumenes del agente Supervisor. En el caso de que en la ventana actual ya se haya registrado un Resumen de la misma clase de Signature que el recibido, se quedar en la lista aquel cuyo valor del atributo fiabilidad sea mayor, siendo rechazado el de fiabilidad menor. Actualizar tabla de Resmenes: Actualizar la interfaz grfica del agente Supervisor invocando el mtodo actualizarTabla2() de la Ventana Agente Supervisor. Ver apartado 4.4.7: Ventana Agente Supervisor. Seleccionar Resmenes actuales: Elaborar una lista de Resmenes de la ventana anterior seleccionando los correspondientes elementos de la lista resumenes del agente Supervisor. En base a estos Resmenes se realizar el Diagnstico de la ventana anterior. Realizar listas de atacantes y vctimas: Realizar listas de atacantes y vctimas recorriendo los Resmenes actuales. Confeccionar la matriz de acusaciones de los Resmenes actuales. Realizar Diagnstico cuantitativo: Obtener el valor numrico de la criticidad del sistema en base a los valores
190
borrosos de prioridad y criticidad de los Resmenes actuales. Para ello primeramente se obtienen las inferencias borrosas que son los diferentes conjuntos borrosos de criticidad que se obtienen al invocar el mtodo inferenciaBorrosa() de la clase ControlBorroso pasndole como parmetros los valores borrosos de prioridad y criticidad de cada uno de los Resmenes actuales. El valor continuo de la criticidad de la red se obtiene finalmente pasando el conjunto de inferencias a la funcin desborrosificarInferencias(). Realizar Diagnstico cualitativo: Determinar el atacante y vctima predominantes en el conjunto de los resmenes diagnosticados. Las diferentes situaciones que se
presentan en este caso determinan el estado del sistema. Tanto la descripcin textual del estado como los valores del atacante y vctima principales se muestran al usuario en el panel de texto de la interfaz grfica del agente Supervisor. El color en el que se plasman en el panel se determina mediante el valor borroso de la criticidad anteriormente calculada, invocando el mtodo
borrosificarCriticidad() de la clase ControlBorroso. Los colores se asocian al valor borroso de la criticidad segn las siguientes correspondencias: Criticidad ALTA Color ROJO Criticidad MEDIA Color NARANJA Criticidad BAJA Color VERDE
191
Los diferentes valores para el estado del sistema se indican en la siguiente tabla:
ESTADO 0 1 2 3 4 5 6 7
N AT. 0 1 1 1 varios varios varios varios
N VIC. 0 1 varias varias 1 1 varias varias
DETALLES no hay ataques vctima destacada repartido atacante destacado repartido pareja destacada repartido
Tabla 1: Estados del sistema.
Realizar Diagnstico comparativo: Obtener el Diagnstico anterior a la ventana que se est diagnosticando. Comparar la situacin de la ventana analizada y la de la anterior en base a los valores de los hosts atacante y vctima principales y estado de la red en los dos momentos. Esta comparacin se realiza pasando estos valores por la siguiente base de reglas:
192
SI estadoanterior = estadoactual ENTONCES "Mismo estado" SI estadoanterior <> estadoactual ENTONCES "Cambio de estado" SI atacanteanterior = atacanteactual ENTONCES "Mismo atacante" SI atacanteanterior <> atacanteactual ENTONCES "Cambio de atacante" SI victimaanterior = victimaactual ENTONCES "Misma vctima" SI victimaanterior <> victimaactual ENTONCES "Cambio de vctima" SI estadoanterior = 0 Y estadoactual > 0 ENTONCES "Aparecen nuevos ataques"
SI estadoanterior > 0 Y estadoactual = 0 ENTONCES "Desaparecen ataques" SI estadoanterior = 1 Y estadoactual = 2 ENTONCES 1a2
SI 1a2
193
Y atacanteanterior = atacanteactual ENTONCES "Atacante ampla su ataque a otras vctimas"
SI 1a2 Y atacanteanterior <> atacanteactual ENTONCES "Nuevo atacante"
SI 1a2 Y victimaanterior = victimaactual ENTONCES "Se mantiene el ataque a la misma vctima principal"
SI 1a2 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 1 Y estadoactual = 3 ENTONCES 1a3
SI 1a3 Y atacanteanterior = atacanteactual ENTONCES "Atacante ampla su ataque a otras vctimas"
194
SI 1a3 ENTONCES "Dispersin de vctima" SI estadoanterior = 1 Y estadoactual = 4 ENTONCES 1a4
SI 1a4 Y atacanteanterior = atacanteactual ENTONCES "Aparecen ms atacantes"
SI 1a4 Y atacanteanterior <> atacanteactual ENTONCES "Nuevo atacante principal"
SI 1a4 Y victimaanterior = victimaactual ENTONCES "Aumenta la presin sobre la vctima"
SI 1a4 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima" SI estadoanterior = 1 Y estadoactual = 5 ENTONCES 1a5
195
SI 1a5 ENTONCES "Dispersin de atacante"
SI 1a5 Y victimaanterior = victimaactual ENTONCES "Aumenta la presin sobre la vctima"
SI 1a6
196
Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 1 Y estadoactual = 7 ENTONCES "Dispersin de atacante y vctima" SI estadoanterior = 2 Y estadoactual = 1 ENTONCES 2a1
SI 2a1 Y atacanteanterior = atacanteactual ENTONCES "Atacante concreta su ataque sobre la vctima principal"
SI 2a1 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima"
197
SI estadoanterior = 2 Y estadoactual = 3 ENTONCES 2a3
SI 2a3 Y atacanteanterior = atacanteactual ENTONCES "Atacante ampla su ataque a otras vctimas"
SI 2a3 ENTONCES "Dispersin de vctima principal" SI estadoanterior = 2 Y estadoactual = 4 ENTONCES 2a4
SI 2a4
198
Y victimaanterior = victimaactual ENTONCES "Se concentra el ataque sobre la misma vctima"
SI 2a5 Y victimaanterior = victimaactual ENTONCES "Se concentra el ataque sobre la misma vctima"
SI 2a6
199
Y atacanteanterior = atacanteactual ENTONCES "Aparecen ms atacantes"
SI 2a6 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 2 Y estadoactual = 7 ENTONCES "Dispersin de atacante y vctima principal" SI estadoanterior = 3 Y estadoactual = 1 ENTONCES 3a1
SI 3a1 Y atacanteanterior = atacanteactual ENTONCES "Atacante concreta su ataque sobre una vctima"
200
SI 3a1 ENTONCES "Concrecin de vctima" SI estadoanterior = 3 Y estadoactual = 2 ENTONCES 3a2
SI 3a2 Y atacanteanterior = atacanteactual ENTONCES "Atacante concreta su ataque sobre una vctima principal"
SI 3a2 ENTONCES "Concrecin de vctima principal" SI estadoanterior = 3 Y estadoactual = 4 ENTONCES 3a4
SI 3a4
201
Y atacanteanterior = atacanteactual ENTONCES "Aparecen ms atacantes"
202
SI 3a6 ENTONCES "Concrecin de vctima principal" SI estadoanterior = 3 Y estadoactual = 7 ENTONCES "Dispersin de atacante" SI estadoanterior = 4 Y estadoactual = 1 ENTONCES 4a1
SI 4a1 Y atacanteanterior = atacanteactual ENTONCES "Desaparecen los dems atacantes"
SI 4a1 Y victimaanterior = victimaactual ENTONCES "Disminuye la presin sobre la vctima"
SI 4a1
203
Y victimaanterior <> victimaactual ENTONCES "Nueva vctima" SI estadoanterior = 4 Y estadoactual = 2 ENTONCES 4a2
SI 4a3
204
Y atacanteanterior = atacanteactual ENTONCES "Desaparecen los dems atacantes"
SI 4a5 ENTONCES "Dispersin de atacante principal"
SI 4a5 Y victimaanterior = victimaactual ENTONCES "Se mantiene el ataque a la misma vctima"
205
SI 4a6 Y atacanteanterior = atacanteactual ENTONCES "Se mantiene el ataque desde el atacante principal"
SI 4a6 Y victimaanterior = victimaactual ENTONCES "Disminuye la presin sobre la vctima principal"
SI 4a6 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 4 Y estadoactual = 7 ENTONCES "Dispersin de atacante principal y vctima" SI estadoanterior = 5 Y estadoactual = 1 ENTONCES 5a1
SI 5a1
206
ENTONCES "Concrecin de atacante"
SI 5a1 Y victimaanterior = victimaactual ENTONCES "Disminuye la presin sobre la vctima"
SI 5a2 ENTONCES "Concrecin de atacante"
207
SI 5a3 ENTONCES "Concrecin de atacante"
SI 5a4 ENTONCES "Concrecin de atacante principal"
SI 5a4 Y victimaanterior = victimaactual ENTONCES "Se mantiene el ataque a la misma vctima"
SI 5a6 ENTONCES "Concrecin de atacante principal"
208
SI 5a6 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 5 Y estadoactual = 7 ENTONCES "Dispersin de vctima" SI estadoanterior = 6 Y estadoactual = 1 ENTONCES 6a1
SI 6a1 Y victimaanterior = victimaactual
209
ENTONCES "Se mantiene el ataque a la misma vctima principal"
SI 6a2 Y victimaanterior = victimaactual ENTONCES "Se mantiene el ataque sobre la vctima principal"
SI 6a2 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima principal" SI estadoanterior = 6
210
Y estadoactual = 3 ENTONCES 6a3
SI 6a3 ENTONCES "Dispersin de vctima principal" SI estadoanterior = 6 Y estadoactual = 4 ENTONCES 6a4
SI 6a4 Y atacanteanterior = atacanteactual ENTONCES "Se mantiene el ataque desde el atacante principal"
SI 6a4 Y victimaanterior = victimaactual
211
ENTONCES "Se mantiene el ataque a la misma vctima principal"
SI 6a5 ENTONCES "Dispersin de atacante principal"
SI 6a5 Y victimaanterior <> victimaactual ENTONCES "Nueva vctima" SI estadoanterior = 6 Y estadoactual = 7 ENTONCES "Dispersin de atacante principal y vctima principal" SI estadoanterior = 7
212
Y estadoactual = 1 ENTONCES "Concrecin de atacante y vctima" SI estadoanterior = 7 Y estadoactual = 2 ENTONCES "Concrecin de atacante y vctima principal" SI estadoanterior = 7 Y estadoactual = 3 ENTONCES "Concrecin de atacante" SI estadoanterior = 7 Y estadoactual = 4 ENTONCES "Concrecin de atacante principal y vctima" SI estadoanterior = 7 Y estadoactual = 5 ENTONCES "Concrecin de vctima" SI estadoanterior = 7 Y estadoactual = 6 ENTONCES "Concrecin de atacante principal y vctima principal"
El comentario en texto que se genera en cada una de ellas se muestra en el panel de texto.
213
Crear Diagnstico: Integrar toda la informacin obtenida hasta el momento en la estructura Diagnstico e insertarla en la lista de diagnsticos realizados del agente Supervisor (atributo diagosticos). Actualizar con este mismo valor el atributo del agente Supervisor ultimodiagnostico.
Actualizar tops: Actualizar las listas de topatacantes y topvictimas, que son atributos del agente Supervisor, con el atacante y vctima principales anteriormente obtenidos. Actualizar la representacin grfica de estas listas.
Limpiar Resmenes: Eliminar de la lista de Resmenes recibidos por el agente Supervisor, representada en el sistema por el atributo resumenes, aquellos que lleven almacenados ms de 20 ventanas. Externalizar al fichero de log resumenes.txt la informacin eliminada y actualizar la interfaz grfica.
Limpiar Diagnsticos: Eliminar de la lista de Diagnsticos realizados por el agente Supervisor, representada en el sistema por el atributo diagnosticos, aquellos que lleven almacenados ms de 20 ventanas. Externalizar al fichero de log diagnosticos.txt la informacin eliminada y actualizar la interfaz grfica.
Pintar ltimo Diagnstico: Repintar el lienzo de la interfaz grfica del agente Supervisor con la nueva informacin almacenada en su atributo ultimodiagnostico. Ver
apartado 4.4.9: Lienzo Supervisor.
214
4.4.
CLASES DE LA INTERFAZ GRFICA
4.4.1. MODELO DE TABLA

Todas las tablas que aparecen en cada uno de los elementos de la interfaz grfica del sistema IDSAI son tablas no editables por el usuario. Por tanto, toda tabla grfica JTable incorporada al sistema, debe soportar un modelo de tabla que slo sea modificable por programacin. El modelo Modelo de Tabla es un Modelo de Tabla Estndar (hereda de DefaultTableModel) que se representa en el sistema con la clase MiTableModel que tiene la estructura siguiente:
4.4.1.1. ATRIBUTOS
4.4.1.2. MTODOS
El mtodo ms relevante implementado en la clase MiTableModel es el siguiente:
215
isCellEditable(): Mtodo que altera el estado de la celda de la tabla que incorpora el modelo, hacindola no editable por parte del usuario. Esta condicin se aplicar a todas las celdas de todas las tablas de la interfaz grfica del sistema IDSAI.
216
4.4.2. VENTANA RELOJ

Representacin de la interfaz grfica del Agente Reloj. Ver apartado 4.2.1: Agente Reloj. La interfaz Ventana Reloj es un Frame (hereda de JFrame) que se representa en el sistema con la clase FrameReloj que tiene la estructura siguiente.
El constructor de la clase FrameReloj dispone los elementos grficos necesarios para componer la ventana Agente Reloj:
Fig. 25: Ventana Agente Reloj
Entre los elementos grficos que podemos ver en la ventana destacan:
217
Etiqueta "Ventana actual": Muestra el valor de la ventana actual, almacenado en el atributo ventana del agente Reloj.
Tabla "Agente": Muestra la lista de agentes vivos en el momento actual en el sistema, almacenada en el atributo agentes del agente Reloj.
Botn "Detener": Al pulsarlo, se duerme el agente Reloj, detenindose todos sus comportamientos asociados. El botn "Arrancar" se habilita y el "Detener" se deshabilita.
Botn "Arrancar": Al pulsarlo, se despierta el agente Reloj, recuperndose todos sus comportamientos asociados. El botn "Detener" se habilita y el "Arrancar" se deshabilita.
4.4.2.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameReloj son los siguientes: agente: Referencia al agente que incorpora la interfaz. Ver apartado 4.2.1: Agente Reloj. modelo: Modelo de tabla no editable por parte del usuario. Ver apartado 4.4.1: Modelo de Tabla tabla: Tabla que presenta la lista de agentes vivos en el momento actual en el sistema IDSAI.
218
contadorventanas: Etiqueta que se actualiza con el valor actual de la ventana del sistema.
4.4.2.2. MTODOS
Los mtodos implementados en la clase FrameReloj son los siguientes:
actualizarTabla(): Actualiza el contenido de la tabla "Agente" con el contenido de la lista de agentes vivos en el momento actual en el sistema, almacenada en el atributo agentes del agente Reloj. actualizarContador(): Actualiza el valor de la etiqueta "Ventana Actual" con el valor del atributo ventana del agente Reloj.
219
4.4.3. VENTANA AGENTE

Representacin de la interfaz grfica bsica de los agentes del sistema IDSAI, y en particular de los agentes Intrpretes (Ver apartado 4.2.3: Agente Intrprete). La interfaz Ventana Agente es un Frame (hereda de JFrame) que se representa en el sistema con la clase FrameAgente que tiene la estructura siguiente:
El constructor de la clase FrameAgente dispone los elementos grficos necesarios para componer la ventana Agente Intrprete:
220
Fig. 26: Ventana Agente Intrprete
Entre los elementos grficos que podemos ver en la ventana destacan: Etiqueta "Nombre": Muestra el nombre global unvoco del agente en la plataforma multiagente. Panel de texto "Log": Muestra las incidencias ocurridas durante la vida del agente. Botn "Limpiar Log": Limpia el rea de texto "Log". Botn "Matar agente": Mata el agente Intrprete
correspondiente a esta interfaz. La ventana no se cierra, pero se deshabilitan todos sus controles. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.4.3.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameAgente son los siguientes: editor: Panel de texto "Log". panel: Panel grfico sobre el que se distribuyen los diferentes componentes de la interfaz grfica.
221
btnmataragente: Botn grfico "Matar Agente". btnlimpiarlog: Botn grfico "Limpiar Log". scrollpanetxtlog: Barra de desplazamiento asociada al panel de texto "Log".
4.4.3.2. MTODOS
Los mtodos implementados en la clase FrameReloj son los siguientes: escribirLinea(): Escribe una lnea de texto en el panel de texto "Log" pasada como primer argumento con los parmetros de formato pasados como los dems argumentos de la funcin.
222
4.4.4. VENTANA AGENTE AVANZADO

Representacin de la interfaz grfica bsica de los agentes avanzados del sistema IDSAI, y en particular de los agentes Analistas (Ver apartado 4.2.10: Agente Analista). La interfaz Ventana Agente Avanzado es una Ventana Agente (hereda de FrameAgente) que se representa en el sistema con la clase
FrameAgenteAvanzado que tiene la estructura siguiente:
El constructor de la clase FrameAgenteAvanzado dispone los elementos grficos necesarios para ampliar la ventana Agente Intrprete. Entre los nuevos elementos grficos que se incorporan a la ventana destacan dos tablas que segn el agente que implemente la interfaz grfica almacenarn informacin relevante sobre la que trabaje el agente: Tabla 1 (superior): Registra los productos del agente: Anlisis, en el caso de agentes Analistas, que se envan en forma de Resumen al agente Supervisor y Diagnsticos, en el caso del agente Supervisor, que se muestran por pantalla al usuario.
223
Tabla 2 (inferior): Registra las fuentes del agente: Anomalas, en el caso de agentes Analistas, que se procesan para elaborar Anlisis y Resmenes en el caso del agente Supervisor, que se procesan para elaborar Diagnsticos.
4.4.4.1. ATRIBUTOS
Los atributos ms relevantes mantenidos por la clase
FrameAgenteAvanzado son los siguientes: modelo1: Modelo de Tabla de la tabla superior. modelo2: Modelo de Tabla de la tabla inferior. tabla1: Tabla grfica superior. tabla2: Tabla grfica inferior
4.4.4.2. MTODOS
Los mtodos implementados en la clase FrameAgenteAvanzado son los siguientes: actualizarTabla1(): Mtodo abstracto que debe ser sobrescrito por las ventanas que hereden de FrameAgenteAvanzado. Deber incorporar las particularidades de los registros a
224
mostrar en la tabla1 segn sea el agente que implemente la interfaz. actualizarTabla2(): Mtodo abstracto que debe ser sobrescrito por las ventanas que hereden de FrameAgenteAvanzado. Deber incorporar las particularidades de los registros a mostrar en la tabla2 segn sea el agente que implemente la interfaz. mostrarDetallesTabla1(): Mtodo abstracto que debe ser sobrescrito por las ventanas Deber que hereden de las
FrameAgenteAvanzado.
incorporar
particularidades de los registros a mostrar en la tabla1 segn sea el agente que implemente la interfaz. mostrarDetallesTabla2(): Mtodo abstracto que debe ser sobrescrito por las ventanas Deber que hereden de las
FrameAgenteAvanzado.
incorporar
particularidades de los registros a mostrar en la tabla2 segn sea el agente que implemente la interfaz.
225
4.4.5. VENTANA AGENTE ANALISTA

Representacin de la interfaz grfica de los agentes Analistas del sistema IDSAI. Ver apartado 4.2.10: Agente Analista). La interfaz Ventana Agente Analista es una Ventana Agente Avanzado (hereda de FrameAgenteAvanzado) que se representa en el sistema con la clase FrameAgenteAnalista que tiene la estructura siguiente:
El constructor de la clase FrameAgenteAnalista dispone los elementos grficos necesarios para componer la ventana Agente Analista:
226
Fig. 27: Ventana Agente Analista
Entre los nuevos elementos grficos que se incorporan a la ventana Agente (ver apartado 4.4.3: Ventana Agente) destacan:
227
Tabla "Ultimos analisis": Se trata de la tabla1 que es atributo heredado de la clase padre. Muestra un registro por cada Anlisis existente en la lista de Anlisis realizados del agente que implementa la interfaz. Ver apartado 4.2.10: Agente Analista. Se ha configurado el evento mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre una Ventana Detalles (ver 5.6: Ventana Detalles) y se invoca el mtodo local mostrarDetallesTabla1(), de manera que se muestra grficamente la informacin detallada del Anlisis deseado. De igual manera se resalta grficamente el registro correspondiente a la Anomala asociada al Anlisis sobre cuyo registro se ha hecho clic, para que sea ms sencillo referirse a sta a la hora de analizar la traza del Anlisis.
Tabla "Anomalias recibidas": Se trata de la tabla2 que es atributo heredado de la clase padre. Muestra un registro por cada Anomala existente en la lista de Anlisis realizados del agente que implementa la interfaz. Ver apartado 4.2.10: Agente Analista. Se ha configurado el evento mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre una Ventana Detalles (ver : Ventana Detalles) y se invoca el mtodo local mostrarDetallesTabla2, de manera que se muestra grficamente la informacin detallada de la Anomala deseada.
228
4.4.5.1. ATRIBUTOS
El atributo mantenido por la clase FrameAgenteAnalista es el siguiente: agente: Referencia al agente que incorpora la interfaz. Ver apartado 4.2.10: Agente Analista.
4.4.5.2. MTODOS
Los mtodos implementados en la clase FrameAgenteAnalista son los siguientes: actualizarTabla1(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Limpiar la tabla1. 2. Introducir todos los elementos de la lista de Anlisis realizados (atributo analisis) del agente Analista que implementa la interfaz (ver apartado 4.2.10: Agente Analista) en la tabla1.
actualizarTabla2(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Limpiar la tabla2.
229
2. Introducir todos los elementos de la lista de Anomalas recibidas (atributo anomalias) del agente Analista que implementa la interfaz (ver apartado 4.2.10: Agente Analista) en la tabla2.
mostrarDetallesTabla1(): Sobrescribe el mtodo de la clase padre. Muestra por la Ventana Detalles que se le pasa como segundo parmetro toda la informacin, debidamente formateada, del Anlisis que se le pasa como primer parmetro.
mostrarDetallesTabla2(): Sobrescribe el mtodo de la clase padre. Muestra por la Ventana Detalles que se le pasa como segundo parmetro toda la informacin, debidamente formateada, de la Anomala que se le pasa como primer parmetro.
230
4.4.6. VENTANA DETALLES

Representacin de la interfaz grfica bsica de las ventanas de detalle del sistema IDSAI, y en particular de aquellas que se abren al hacer clic sobre algn registro de las tablas de las Ventanas Agente Analista (Ver apartado 4.4.5: Ventana Agente Analista). La interfaz Ventana Detalles es un Frame (hereda de JFrame) que se representa en el sistema con la clase FrameReloj que tiene la estructura siguiente:
El constructor de la clase FrameDetalles dispone los elementos grficos necesarios para componer la ventana Detalles:
231
Fig. 28: Ventana Detalles
Entre los elementos grficos que podemos ver en la ventana destacan: Etiqueta "label": Muestra el nombre de la estructura del sistema IDSAI a mostrar. Panel de texto "texto": Muestra la informacin contenida en la estructura mostrada.
232
4.4.6.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameDetalles son los siguientes: label: Etiqueta que muestra el nombre de la estructura cuya informacin se presenta en la caja de texto. texto: Caja de texto que muestra la informacin, debidamente formateada, de la estructura deseada.
4.4.6.2. MTODOS
El mtodo implementado en la clase FrameDetalles es el siguiente: escribirLinea(): Escribe una lnea de texto en el panel de texto "texto" pasada como primer argumento.
233
4.4.7. VENTANA AGENTE SUPERVISOR

Representacin de la interfaz grfica del agente Supervisor del sistema IDSAI. Ver apartado 4.2.17: Agente Supervisor. La interfaz Ventana Agente Supervisor es una Ventana Agente Avanzado (hereda de FrameAgenteAvanzado) que se representa en el sistema con la clase FrameAgenteSupervisor que tiene la estructura siguiente:
El constructor de la clase FrameAgenteSupervisor dispone los elementos grficos necesarios para componer la ventana Agente Supervisor:
234
Fig. 29: Ventana Supervisor
Entre los nuevos elementos grficos que se incorporan a la ventana Agente (ver apartado 4.4.3: Ventana Agente) destacan: Tabla "Ultimos diagnosticos": Se trata de la tabla1 que es atributo heredado de la clase padre. Muestra un registro por
235
cada Diagnstico existente en la lista de Diagnsticos realizados del agente que implementa la interfaz. Ver apartado 4.2.17: Agente Supervisor. Se ha configurado el evento mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre una Ventana Detalles con Grfico y Tabla (ver 5.10: Ventana Detalles con Grfico y Tabla) y se invoca el mtodo local mostrarDetallesTabla1(), de manera que se muestra grficamente la informacin detallada del Diagnstico deseado. De igual manera se resaltan grficamente los registros correspondientes a los Resmenes asociados al Diagnstico sobre cuyo registro se ha hecho clic, para que sea ms sencillo referirse a stos a la hora de analizar la traza del Diagnstico. Tabla "Resumenes recibidos": Se trata de la tabla2 que es atributo heredado de la clase padre. Muestra un registro por cada Resumen existente en la lista de Resmenes realizados del agente que implementa la interfaz. Ver apartado 4.2.17: Agente Supervisor. Se ha configurado el evento
mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre una Ventana Detalles con Tabla (ver 5.11: Ventana Detalles con Tabla) y se invoca el mtodo local mostrarDetallesTabla2, de manera que se muestra grficamente la informacin detallada del Resumen deseado. Lienzo "Lienzo": Panel de dibujo en el que se representa grficamente la informacin almacenada en el atributo ultimodiagnostico del agente Supervisor (ver apartado 4.2.17: Agente Supervisor). Ver apartado 4.4.9: Lienzo Supervisor.
236
4.4.7.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameAgenteSupervisor son los siguientes: agente: Referencia al agente que incorpora la interfaz. Ver apartado 4.2.17: Agente Supervisor. lienzosupervisor: Panel de dibujo que presenta grficamente la informacin del ltimo Diagnstico generado. Ver apartado 4.4.9: Lienzo Supervisor.
4.4.7.2. MTODOS
Los mtodos implementados en la clase FrameAgenteSupervisor son los siguientes: actualizarTabla1(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Limpiar la tabla1. 2. Introducir todos los elementos de la lista de Diagnsticos realizados (atributo diagnosticos) por el agente Supervisor que implementa la interfaz (ver apartado 4.2.17: Agente Supervisor) en la tabla1.
237
actualizarTabla2(): Sobrescribe el mtodo de la clase padre. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Limpiar la tabla2. 2. Introducir todos los elementos de la lista de Resumenes recibidos (atributo resumenes) del agente Supervisor que implementa la interfaz (ver apartado 4.2.17: Agente Supervisor) en la tabla2.
mostrarDetallesTabla1(): Sobrescribe el mtodo de la clase padre. Muestra por la Ventana Detalles que se le pasa como segundo parmetro toda la informacin, debidamente formateada, del Diagnstico que se le pasa como primer parmetro.
mostrarDetallesTabla2(): Sobrescribe el mtodo de la clase padre. Muestra por la Ventana Detalles que se le pasa como segundo parmetro toda la informacin, debidamente formateada, del Resumen que se le pasa como primer parmetro.
238
4.4.8. LEYENDA
Estructura de datos que representa un elemento de leyenda, asociando una clase de Signature a un color. El sistema IDSAI almacena la informacin relativa a valores borrosos en la siguiente estructura:
Donde: clase: Clase de Signature. Ver apartado 4.1.2.2: Signature. color: Color asociado.
239
4.4.9. LIENZO SUPERVISOR

Representacin del panel de dibujo de la interfaz grfica del agente Supervisor del sistema IDSAI. Ver apartado 4.4.7: Ventana Agente Supervisor). El Lienzo Supervisor es un Canvas (hereda de Canvas) que se representa en el sistema con la clase LienzoSupervisor que tiene la estructura siguiente:
En el Lienzo Supervisor se trata de representar la informacin relativa a las acusaciones que se dan entre las direcciones IP atacantes y vctimas en el sistema representadas por el atributo acusaciones del Diagnstico diag que es a su vez atributo de la clase LienzoSupervisor (ver apartado 4.1.2.8: Diagnstico). El atributo almacena el ltimo diagnstico realizado por el agente Supervisor, representado por el atributo ultimodiagnostico de este agente (ver apartado 4.2.17: Agente Supervisor).
240
Fig. 30: Lienzo Supervisor
En la parte central del mismo, se representan las direcciones IP de los atacantes y vctimas del ltimo diagnstico en torno a un crculo. Estas direcciones IP se unen con una lnea por cada acusacin registrada entre atacante y vctima registrados en el diagnstico. El color de las lneas viene determinado por la leyenda de colores que se indica a continuacin: Clase unknown-class Color AMARILLO Clase attempted-recon Color CYAN Clase bad-unknown Color ROJO
241
Clase attempted-dos Color VERDE Clase attempted-admin Color MAGENTA
El grosor de las lneas representa el nmero de signatures que se dan entre las IP atacante y vctima unidas. En el extremo de la lnea correspondiente a la vctima, se representa un cuadrado de mayor grosor a modo de extremo de flecha. En la parte superior izquierda del panel se muestra una leyenda que representa la correspondencia clase-color anteriormente descrita. En la parte inferior izquierda del panel se muestra en fuente roja la lista Top 5 atacantes, donde se listan ordenadamente las 5 direcciones IP que ms veces (indicadas entre parntesis) se han determinado como atacante principal de diagnstico durante la vida del agente Supervisor. Esta lista se corresponde con el atributo topatacantes del agente Supervisor (ver apartado 4.2.17: Agente Supervisor). De igual manera, en la parte inferior derecha del panel se muestra en fuente azul la lista Top 5 victimas, donde se listan ordenadamente las 5 direcciones IP que ms veces (indicadas entre parntesis) se han determinado como vctima principal de diagnstico durante la vida del agente Supervisor. Esta lista se corresponde con el atributo topvictimas del agente Supervisor (ver apartado 4.2.17: Agente Supervisor) Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.4.9.1. ATRIBUTOS
Los atributos mantenidos por la clase LienzoSupervisor son los siguientes:
242
agente: Referencia al agente que incorpora la interfaz. Ver apartado 4.2.17: Agente Supervisor. diag: Diagnstico (ver apartado 4.1.2.8: Diagnstico) cuya informacin se presenta grficamente. Se carga con el valor del atributo ultimodiagnostico del agente Supervisor del sistema. colores: Lista de elementos Leyenda (ver apartado 4.4.8: Leyenda) que representa la leyenda de correspondencias clase-color descritas anteriormente. diametro: Constante que almacena el tamao del crculo en torno al cual se disponen las direcciones IP del diagnstico.
4.4.9.2. MTODOS
El mtodo principal implementado en la clase LienzoSupervisor es el siguiente: paint(): Pinta sobre el panel de dibujo la informacin antes descrita. La disposicin correcta de los elementos se facilita con las funciones de mapping: mappingX() y mappingY() y ubicacin en 2 dimensiones: obtenerXs() y obtenerYs(), autoexplicativas.
243
4.4.10.
VENTANA DETALLES CON GRFICO Y TABLA
Representacin de la interfaz grfica de las ventanas de detalle del sistema IDSAI que se abren al hacer clic sobre algn registro de la tabla Ultimos Diagnosticos de la Ventana Agente Supervisor (Ver apartado 4.4.7: Ventana Agente Supervisor). La interfaz Ventana Detalles con Grfico y Tabla es una Ventana Detalles (hereda de FrameDetalles) que se representa en el sistema con la clase FrameDetallesGraficoTabla que tiene la estructura siguiente:
El constructor de la clase FrameDetallesGraficoTabla dispone los elementos grficos necesarios para componer la ventana Detalles:
244
Fig. 31: Ventana Detalles con Grfico y Tabla
Entre los nuevos elementos grficos que se incorporan a la ventana Detalles (ver apartado 4.4.6: Ventana Detalles) destacan: Tabla de acusaciones: Representa tabuladamente la lista de atacantes (como primer campo de los registros) y la de vctimas (como ttulo del resto de campos de la tabla). El contenido de la tabla representa el nmero de signatures diferentes de la Acusacin que protagonizan el atacante y vctima correspondientes a cada casilla (ver apartado 4.1.2.6: Acusacin). Se ha configurado el evento mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre
245
una Ventana Detalles (ver 5.6: Ventana Detalles) y se invoca el mtodo local mostrarDetallesTabla(), de manera que se muestra la informacin detallada de la Acusacin deseada. Lienzo detalles: Representa la informacin relativa al Diagnstico referenciado por el registro sobre el que se ha hecho clic en la Ventana Agente Supervisor. Muestra
grficamente las acusaciones que se dan entre las direcciones IP atacantes y vctimas en el sistema representadas por el Diagnstico recibido como parmetro. Ver apartado 4.4.12: Lienzo Detalles. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.4.10.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameDetallesGraficoTabla son los siguientes: modelo: Modelo de Tabla de la tabla de acusaciones. Ver apartado 4.4.1: Modelo de Tabla. tabla: Tabla grfica de acusaciones.
4.4.10.2. MTODOS
El mtodo implementado en la clase FrameDetalles es el siguiente:
246
mostrarDetallesTabla(): Muestra los detalles de la Acusacin que protagonizan las direcciones IP atacante y vctima pasados como primeros parmetros sobre el panel de texto que es el atributo texto de la Ventana Detalles pasada como cuarto parmetro. Ver apartado 4.4.6: Ventana Detalles.
247
4.4.11.
VENTANA DETALLES CON TABLA
Representacin de la interfaz grfica de las ventanas de detalle del sistema IDSAI que se abren al hacer clic sobre algn registro de la tabla Resumenes recibidos de la Ventana Agente Supervisor (Ver apartado 4.4.7: Ventana Agente Supervisor). La interfaz Ventana Detalles con Tabla es una Ventana Detalles (hereda de FrameDetalles) que se representa en el sistema con la clase
FrameDetallesTabla que tiene la estructura siguiente:
Esta clase dispone de dos constructores debido a que originalmente representaba tanto los detalles de Resmenes como los de Diagnsticos. Se ha prescindido del constructor dedicado a Diagnsticos en la implantacin definitiva del sistema. El constructor de la clase FrameDetallesTabla dispone los elementos grficos necesarios para componer la ventana Detalles:
248
Fig. 32: Ventana Detalles con Tabla
Entre los nuevos elementos grficos que se incorporan a la ventana Detalles (ver apartado 4.4.6: Ventana Detalles) destacan: Tabla de acusaciones: Representa tabuladamente la lista de atacantes (como primer campo de los registros) y la de vctimas (como ttulo del resto de campos de la tabla). El contenido de la tabla representa el nmero de signatures
249
diferentes de la Acusacin que protagonizan el atacante y vctima correspondientes a cada casilla (ver apartado 4.1.2.6: Acusacin). Se ha configurado el evento mouseClicked(), de forma que al hacer clic sobre un registro de esta tabla, se abre una Ventana Detalles (ver 5.6: Ventana Detalles) y se invoca el mtodo local mostrarDetallesTabla(), de manera que se muestra la informacin detallada de la Acusacin deseada. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.4.11.1. ATRIBUTOS
Los atributos mantenidos por la clase FrameDetallesGraficoTabla son los siguientes: modelo: Modelo de Tabla de la tabla de acusaciones. Ver apartado 4.4.1: Modelo de Tabla. tabla: Tabla grfica de acusaciones.
4.4.11.2. MTODOS
El mtodo implementado en la clase FrameDetalles es el siguiente: mostrarDetallesTabla(): Muestra los detalles de la Acusacin que protagonizan las direcciones IP atacante y vctima pasados como primeros parmetros sobre el panel de texto
250
que es el atributo texto de la Ventana Detalles pasada como cuarto parmetro. Ver apartado 4.4.6: Ventana Detalles.
251
4.4.12.
LIENZO DETALLES
Representacin del panel de dibujo de la interfaz grfica de la Ventana Detalles con Grfico y Tabla del sistema IDSAI. Ver apartado 4.4.10: Ventana Detalles con Grfico y Tabla. El Lienzo Detalles es un Canvas (hereda de Canvas) que se representa en el sistema con la clase LienzoDetalles que tiene la estructura siguiente:
En el Lienzo Detalles se trata de representar la informacin relativa a las acusaciones que se dan entre las direcciones IP atacantes y vctimas en el sistema representadas por el Diagnstico pasado como parmetro al constructor de la clase LienzoDetalles (ver apartado 4.1.2.8: Diagnstico).
252
Fig. 33: Lienzo Detalles
En la parte central del mismo, se representan las direcciones IP de los atacantes y vctimas del diagnstico en torno a un crculo. Estas direcciones IP se unen con una lnea por cada acusacin registrada entre atacante y vctima registrados en el diagnstico. El color de las lneas viene determinado por la leyenda de colores que se indica a continuacin: Clase unknown-class Color AMARILLO Clase attempted-recon Color CYAN Clase bad-unknown Color ROJO Clase attempted-dos Color VERDE
253
Clase attempted-admin Color MAGENTA
El grosor de las lneas representa el nmero de signatures que se dan entre las IP atacante y vctima unidas. En el extremo de la lnea correspondiente a la vctima, se representa un cuadrado de mayor grosor a modo de extremo de flecha. En la parte superior izquierda del panel se muestra una leyenda que representa la correspondencia clase-color anteriormente descrita. Los detalles de los diferentes aspectos de esta clase se definen a continuacin.
4.4.12.1. ATRIBUTOS
Los atributos mantenidos por la clase LienzoSupervisor son los siguientes: diag: Diagnstico (ver apartado 4.1.2.8: Diagnstico) cuya informacin se presenta grficamente. Se carga con el valor del Diagnstico pasado como parmetro al constructor de la clase. colores: Lista de elementos Leyenda (ver apartado 4.4.8: Leyenda) que representa la leyenda de correspondencias clase-color descritas anteriormente. diametro: Constante que almacena el tamao del crculo en torno al cual se disponen las direcciones IP del diagnstico.
254
4.4.12.2. MTODOS
El mtodo principal implementado en la clase LienzoSupervisor es el siguiente: paint(): Pinta sobre el panel de dibujo la informacin antes descrita. La disposicin correcta de los elementos se facilita con las funciones de mapping: mappingX() y mappingY() y ubicacin en 2 dimensiones: obtenerXs() y obtenerYs(), autoexplicativas.
255
4.5.
CLASES DE LA CAPA DE PERSISTENCIA
4.5.1. EVENTO DAO

Paquete de funciones de acceso a la base de datos snortdb a nivel de eventos. Este conjunto de funciones se agrupa en el sistema con la clase EventoDAO que tiene la estructura siguiente:
4.5.1.1. ATRIBUTOS
Los atributos mantenidos por la clase EventoDAO son las siguientes instrucciones SQL: DELETE_EVENTS: Instruccin SQL que elimina aquellos registros de la tabla event, cuyo valor de campo timestamp
256
sea tantos segundos anterior como se precise respecto al momento actual. DELETE_SIGNATURES: Instruccin SQL que elimina aquellos registros de la tabla signature no referenciados en la tabla event. DELETE_SIG_CLASS: Instruccin SQL que elimina
aquellos registros de la tabla sig_class no referenciados en la tabla signature. DELETE_IPHDR: Instruccin SQL que elimina aquellos registros de la tabla iphdr no referenciados en la tabla event. DELETE_DATA: Instruccin SQL que elimina aquellos registros de la tabla data no referenciados en la tabla iphdr. DELETE_OPT: Instruccin SQL que elimina aquellos registros de la tabla opt no referenciados en la tabla iphdr. DELETE_ICMPHDR: Instruccin SQL que elimina aquellos registros de la tabla icmphdr no referenciados en la tabla iphdr. DELETE_UDPHDR: Instruccin SQL que elimina aquellos registros de la tabla udphdr no referenciados en la tabla iphdr. DELETE_TCPHDR: Instruccin SQL que elimina aquellos registros de la tabla tcphdr no referenciados en la tabla iphdr.
257
4.5.1.2. MTODOS
El mtodo implementado en la clase BehaviourSincronizar es el siguiente: eliminarEventosAnterioresA(): Simula un borrado en cascada de la informacin ms voluminosa almacenada en la base de datos snortdb. Su algoritmo es completamente lineal y consiste en los siguientes pasos: 1. Establecer conexin con la base de datos snortdb. 2. Ejecutar instruccin DELETE_EVENTS con el nmero de segundos recibido como parmetro del mtodo. 3. Ejecutar instruccin DELETE_SIGNATURES. 4. Ejecutar instruccin DELETE_SIG_CLASS. 5. Ejecutar instruccin DELETE_IPHDR. 6. Ejecutar instruccin DELETE_DATA. 7. Ejecutar instruccin DELETE_OPT. 8. Ejecutar instruccin DELETE_ICMPHDR. 9. Ejecutar instruccin DELETE_UDPHDR. 10. Ejecutar instruccin DELETE_TCPHDR. 11. Cerrar la conexin con la base de datos snortdb.
258
4.5.2. ANOMALA DAO

Paquete de funciones de acceso a la base de datos snortdb a nivel de anomalas. Este conjunto de funciones se agrupa en el sistema con la clase AnomaliaDAO que tiene la estructura siguiente:
4.5.2.1. ATRIBUTOS
Los atributos mantenidos por la clase AnomaliaDAO son las siguientes instrucciones SQL: SELECT_SIG: Instruccin SQL que obtiene la informacin de las signatures cuya clase es igual al tipo de especialidad que se especifique.
259
SELECT_OTROS:
Instruccin
SQL
que
obtiene
la
informacin de las signatures cuya clase especificada es del tipo "otros". SELECT_EVENTS: Instruccin SQL que obtiene la
informacin de los eventos relacionados con la signature deseada, de la ltima ventana de tiempo. SELECT_PORTS_TCP: Instruccin SQL que obtiene los puertos tcp relacionados con el evento deseado. SELECT_PORTS_UDP: Instruccin SQL que obtiene los puertos udp relacionados con el evento deseado. ventana: Contador que almacena el valor de la ventana actual. tamaoventana: Entero que almacena el tamao de la ventana indicado por el agente Reloj.
4.5.2.2. MTODOS
El mtodo implementado en la clase AnomaliaDAO es el siguiente: obtenerAnomalias(): Obtiene la informacin de las signatures del tipo que se especifique como parmetro y eventos relacionados en la ltima ventana temporal. El siguiente diagrama, representa su algoritmo bsico:
260
INICIO
Establecer conexin con la base de datos snortdb
Obtener lista de signatures
for signature
Obtener lista de eventos relacionados con la signature
Obtener ataques de la anomala
Crear Anomala
NO
hay eventos?
SI Agregar Anomala
Cerrar conexin con la base de datos snortdb
FIN (devolver lista de Anomalas)
Fig. 34: Mtodo obtenerAnomalias() de la clase Anomala DAO.
261
Establecer conexin con la base de datos snortdb: Autoexplicativa.
Obtener lista de signatures: Obtener una relacin de las signatures registradas en la base de datos e informacin asociada. Creacin de estructura Signature (Ver apartado 4.1.2.2: Signature).
Obtener lista de eventos relacionados con la signature: Obtener una relacin de los eventos registrados en la base de datos cuya signature asociada es la considerada en el bucle actual (el bucle que recorre la lista de signatures anterior). Creacin de estructura Evento (Ver apartado 4.1.2.1: Evento). Se asocia a cada Evento la pareja de puertos origen y destino que caracteriza la alerta.
Obtener ataques de la anomala: Obtener datos estadsticos sobre la secuencia de eventos cuya signature asociada es la considerada en el bucle actual. Creacin de estructura Ataque (Ver apartado 4.1.2.3: Ataque).
Crear Anomala: Crear la estructura Anomala integrando las estructuras creadas en cada bucle de signature: Signature, lista de Eventos y lista de Ataques.(Ver apartado 4.1.2.4: Anomala).
Agregar Anomala: Aadir Anomala a lista de Anomalas a enviar al agente Analista correspondiente.
262
4.6.
CLASES DE FUNCIONES DE CLCULO
4.6.1. FUZZY
Estructura de datos que representa un elemento perteneciente a un conjunto borroso. El sistema IDSAI almacena la informacin relativa a valores borrosos en la siguiente estructura:
Donde: elemento: Etiqueta del conjunto borroso al que pertenece el elemento. pertenencia: Grado de pertenencia del elemento al conjunto borroso (valorada de 0 a 1).
263
4.6.2. CONTROL BORROSO

Paquete de funciones de manejo de conjuntos borrosos segn los controladores borrosos de Mandani representados grficamente en el anexo 1: Conjuntos borrosos IDSAI. Este conjunto de funciones se agrupa en el sistema con la clase ControlBorroso que tiene la estructura siguiente:
4.6.2.1. ATRIBUTOS
Ninguno.
4.6.2.2. MTODOS
Los mtodos implementados en la clase ControlBorroso son los siguientes:
264
borrosificarPrioridad(): Devuelve el valor o valores borrosos (ver apartado 4.6.1: Fuzzy) del valor continuo pasado como parmetro, en el conjunto borroso Prioridad (ver apartado Prioridad en el anexo 1: Conjuntos borrosos IDSAI). borrosificarCompactacion(): Devuelve el valor o valores borrosos (ver apartado 4.6.1: Fuzzy) del valor continuo pasado como parmetro, en el conjunto borroso
Compactacin (ver apartado Compactacin en el anexo 1: Conjuntos borrosos IDSAI). borrosificarCriticidad(): Devuelve el valor o valores borrosos (ver apartado 4.6.1: Fuzzy) del valor continuo pasado como parmetro, en el conjunto borroso Criticidad (ver apartado Criticidad en el anexo 1: Conjuntos borrosos IDSAI). desborrosificarCriticidad(): Devuelve el grado de pertenencia de un valor continuo pasado como segundo parmetro dentro de un intervalo definido por un conjunto borroso pasado como primer parmetro dentro del controlador borroso Criticidad (ver apartado Criticidad en el anexo 1: Conjuntos borrosos IDSAI). inferenciaBorrosa(): Invoca el mtodo local
reglasInferenciaBorrosa() segn sean el nmero de valores borrosos prioridad y compactacin pasados como parmetros. reglasInferenciaBorrosa(): Devuelve el valor borroso
criticidad resultante de evaluar los valores borrosos prioridad y compactacin pasados como parmetros segn el siguiente juego de reglas:
265
SI prioridad BAJA Y compactacin BAJA ENTONCES criticidad BAJA
SI prioridad BAJA Y compactacin MEDIA ENTONCES criticidad BAJA
SI prioridad BAJA Y compactacin ALTA ENTONCES criticidad MEDIA
SI prioridad MEDIA Y compactacin BAJA ENTONCES criticidad BAJA
SI prioridad MEDIA Y compactacin MEDIA ENTONCES criticidad MEDIA
SI prioridad MEDIA Y compactacin ALTA ENTONCES criticidad ALTA
SI prioridad ALTA Y compactacin BAJA ENTONCES criticidad MEDIA
266
SI prioridad ALTA Y compactacin MEDIA ENTONCES criticidad ALTA
SI prioridad ALTA Y compactacin ALTA ENTONCES criticidad ALTA
El grado de pertenencia del valor borroso se calcula mediante el criterio del mnimo grado de pertenencia de los valores participantes.
desborrosificarInferencias(): Devuelve el valor continuo que se obtiene al desborrosificar la lista de conjuntos borrosos del universo criticidad pasada como parmetro por el mtodo del centro de gravedad. Este proceso se realiza segn el siguiente algoritmo lineal: 1. Discretizar el intervalo de posibles valores de criticidad (de 0 a 10) en muestras separadas 0.5 unidades. 2. Obtener para cada muestra el mximo grado de pertenencia de los conjuntos borrosos pasados como parmetro. 3. Obtener la lista de grados de pertenencia asociados a cada muestra calculada anteriormente invocando la funcin local desborrosificarInferenciaBorrosa para
267
cada uno de los conjuntos borrosos pasados como parmetro. 4. Calcular el centro de gravedad de los grados de pertenencia mximos obtenidos en el paso anterior para cada muestra.
desborrosificarInferenciaBorrosa(): Devuelve la lista de grados de pertenencia asociados a la inferencia borrosa pasada como parmetro segn la discretizacin de los valores en muestras separadas 0.5 unidades.
A continuacin se muestra un ejemplo documentado de cmo a travs de las funciones de la clase ControlBorroso, se trabaja con la informacin borrosa prioridad y compactacin para inferir el valor de la criticidad de la red analizada:
268
4.6.2.3. EJEMPLO DE CLCULO BORROSO IDSAI
Fig. 35: Lista de anlisis y resmenes enviados
Fig. 36: Diagnstico realizado
269
4.6.2.4. DESCRIPCIN DEL PROCESO

PREMBULO: Los agentes analistas realizan los Analisis pertinentes de cada Anomalia recibida de los diferentes agentes interpretes. En la figura 35 se muestra, para cada Resumen realizado (por cada Analista, en este caso, dos) la valoracin cuantitativa de la prioridad y compactacin de los Analisis en que se basan. En la figura 36 se muestra la salida del agente Supervisor, sobre el diagnstico cuantitativo realizado. La situacin corresponde con la ventana 29 de una sesin de captura. 1.- Agente Analista: Elabora Resumen de Analisis. La compactacin y prioridad del Resumen se obtienen como media aritmtica de las compactaciones y prioridades de los Analisis. Este proceso se lleva a cabo en la llamada al mtodo resumir() de la clase BehaviourAnalizarAnomalias. Resumen 1: PRIO = media(4,4,4,4,3) = 3.8 COMP = media(11,11,12,12,1) = 9.4 Resumen 2: PRIO = media(1,2,2) = 1.666 COMP = media(1,11,11) = 7.666 Cada agente Analista enva su Resumen al agente Supervisor.
270
2.- Agente Supervisor: Borrosifica los valores cuantitativos de prioridad y compactacin de cada resumen segn los controladores borrosos de las figuras 20 y 21. Para este proceso se sirve de las funciones borrosificarPrioridad() y borrosificarCompactacion() respectivamente de la clase ControlBorroso.
Fig. 37: Prioridad
Fig. 38: Compactacin
Resumen 1: PRIO 3.8 -> MEDIA (1.0) COMP 9.4 -> MEDIA (0.2) BAJA (0.4) Resumen 2: PRIO 1.666 -> ALTA (1.0) COMP 7.666 -> MEDIA (0.8)
271
Como se puede observar la compactacin del Resumen 1 toma dos valores borrosos, MEDIA y BAJA con diferente grado de pertenencia.
3.- Agente Supervisor: Obtiene inferencias de la criticidad del sistema a partir de los valores borrosos de PRIO y COMP de cada resumen, haciendo pasar cada combinacin de valores por su base de inferencias. El grado de pertenencia de la criticidad resultante para cada par prioridadcompactacion es el mnimo de ambos. Estos clculos se llevan a cabo invocando la funcin inferenciaBorrosa() de la clase ControlBorroso.
Resumen 1: PRIO MEDIA (1.0) COMP MEDIA (0.2) INF1:CRIT MEDIA min(1.0,0.2) = (0.2)
PRIO MEDIA (1.0) COMP BAJA (0.4) INF2:CRIT BAJA min(1.0,0.4) = (0.4)
Resumen 2: PRIO ALTA (1.0)
272
COMP MEDIA (0.8) INF3:CRIT ALTA min(1.0,0.8) = (0.8)
Se pueden comparar estos valores con los devueltos por el sistema en la figura 36, para ver, en efecto que son los mismos valores.
4.- Agente Supervisor: Agrega las inferencias obtenidas (en esta ocasin, tres) para realizar una desborrosificacin del conjunto por el mtodo del centro de gravedad. Las inferencias son conjuntos borrosos de tipo criticidad, cuyo controlador borroso se representa en la figura 39. De forma grfica la agregacin de las inferencias obtenidas segn su controlador queda representada en la figura 23, como el conjunto borroso formado por la unin de los conjuntos borrosos a integrar con el mayor grado de pertenencia. Esta compleja operacin se lleva a cabo en la primera mitad del algoritmo correspondiente al mtodo desborrosificarInferencias() de la clase ControlBorroso.
Fig. 39: Criticidad
273
1 0.8
INF3 0.4 0.2
INF1
INF2
10
Fig. 40: Agregacin de inferencias
5.- Agente Supervisor: Desborrosifica la agregacin de inferencias aplicando el mtodo del centro de gravedad. Para ello se divide el conjunto continuo de valores de criticidad (1-10) en intervalos discretos de longitud 0.5, obteniendo una serie de 19 muestras C y de sus correspondientes imgenes que se operarn a travs de la frmula: i=1..19(i * Ci)/ i=1..19 i. Esta operacin se lleva a cabo en la segunda mitad del algoritmo correspondiente al mtodo desborrosificarInferencias() de la clase ControlBorroso.
274
1 0.8 INF3 0.4 0.2 INF1 INF2
C
1 2 3 4 5 6 7 8 9 10
Fig. 41: Clculo centro de gravedad
Valores obtenidos:
C 1.0 0.8 1.5 0.8 2.0 0.8 2.5 0.75 3.0 0.5 3.5 0.25 4.0 0.2 4.5 0.2 5.0 0.2 5.5 0.2 6.0 0.2 6.5 0.2 7.0 0.2 7.5 0.4 8.0 0.4 8.5 0.4 9 0.4 9.5 0.4 10 0.4
Operndolos segn la frmula anterior: 1.0*0.8+1.5*0.8+2.0*0.8+2.5*0.75+3.0*0.5+3.5*0.25+4.0*0.2+4.5*0.2+5.0*0.2+5.5* 0.2+ 6.0*0.2+6.5*0.2+7.0*0.2+7.5*0.4+8.0*0.4+8.5*0.4+9.0*0.4+9.5*0.4+10*0.4 7.7
275
36.55 / 7.7 4.7467 Se puede comparar este ltimo resultado con el devuelto por el sistema en la figura 36, para ver, en efecto que se trata del mismo valor (aproximadamente, por cuestiones de redondeo) y es subjetivamente correcto (desequilibrado hacia la parte de criticidad alta, por el mayor grado de pertenencia de INF3: ALTA, respecto a INF2 e INF3), como se puede ver en la figura 42:
1 0.8
4.7467
INF3 0.4 INF1 0.2
INF2
10
Fig. 42: Centro de gravedad
276
5. ARQUITECTURA DEL SISTEMA IDSAI

En este captulo se aborda la arquitectura del sistema IDSAI, y por tanto la implantacin de las clases y conceptos anteriormente descritos en una estructura global. En el diseo de la arquitectura en capas de agentes inteligentes JADE y del modelo de comportamientos en el sistema IDSAI, se aplican los conocimientos adquiridos sobre la configuracin e implantacin de los sensores Snort en la red y seguridad informtica necesarios para la realizacin del proyecto.
5.1.
ARQUITECTURA JAVA JADE MULTIAGENTE

Al abordar el proyecto IDSAI se plante un problema de base: la
inexperiencia del desarrollador en el diseo de sistemas distribuidos y el desconocimiento del paradigma de los agentes inteligentes, por lo que se opt por la tecnologa ms 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. El proyecto IDSAI pretende ser un Sistema de Deteccin de Intrusos distribuido, fiable, escalable y fcilmente adaptable a las nuevas amenazas que puedan surgir en redes de ordenadores. JADE permite componer un sistema distribuido a travs del desarrollo de entidades software autnomas y colaborativas en pos de alcanzar un objetivo comn, por lo que es la base ideal para alcanzar estos fines. JADE proporciona facilidades en cuanto a la coordinacin de agentes, seguridad, comunicacin, movilidad, redundancia, y muchos otros servicios bsicos en una arquitectura distribuida. Todo ello sobre un lenguaje cuyas virtudes son de
277
sobra conocidas como Java. Su carcter abierto (open-source) permite el desarrollo de aplicaciones sobre esta tecnologa sin coste alguno y la flexibilidad del cdigo lo hace verdaderamente atractivo. La potencia de JADE estimula a su vez la aparicin de nuevas ideas que permiten ampliar la funcionalidad de un sistema en las diferentes fases del desarrollo. Por otra parte, la tecnologa Java simplifica la extensin de funcionalidades y la incorporacin de nuevas caractersticas a anteriores versiones de un producto software. Al optar por estas tecnologas de desarrollo se garantiza que el resultado no ser un software esttico y caduco en el tiempo, sino que ser fcilmente actualizable y podr incorporar los avances y funcionalidades necesarias para mantenerse al da durante un largo periodo de mantenimiento.
278
5.2.
ARQUITECTURA DEL SISTEMA IDSAI

El sistema IDSAI es una distribucin del popular Sistema de Deteccin de
Intrusos Snort, basada en agentes inteligentes JADE. Como se ha descrito en el apartado 3.1: Sistemas de Deteccin de Intrusos, un IDS es un sistema muy delicado que no se puede permitir la prdida de paquetes en situaciones crticas y por tanto al tener que garantizarle un mnimo de recursos computacionales se recomienda instalar en mquinas dedicadas. Esto implica que en general, no se instalen en la misma mquina pesadas interfaces grficas u otros mdulos que puedan interferir con el Sistema de Deteccin de Intrusos. En estos casos, se suele disponer de mquinas de monitorizacin remotas donde mostrar los resultados. Los productos bsicos que devuelve un IDS al hombre encargado de su supervisin son las alertas. Por defecto, Snort presenta las alertas en ficheros de texto con el formato siguiente:
[**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] 04/29-20:11:29.545751 0:16:76:47:1B:AD -> 0:16:76:47:1B:6E type:0x800 len:0x3C 192.168.20.103:37670 -> 192.168.20.199:443 TCP TTL:54 TOS:0x0 ID:9541 IpLen:20 **U*P**F Seq: 0x447A2705 Ack: 0x0 Win: 0xC00 TcpLen: 20 UrgPtr: 0x0
[Xref => http://www.whitehats.com/info/IDS30]
El anlisis en tiempo real de cientos de alertas de este tipo por parte de un humano es prcticamente imposible y requerira de una dedicacin completa. El hombre encargado de supervisar las alertas de un IDS debera limitarse a atender en
279
tiempo real las situaciones verdaderamente crticas dejando para una posterior revisin offline el repaso de las alertas menos importantes. Pero, cundo se da una situacin crtica?, cmo un analista puede darse cuenta de la criticidad de una situacin y de lo que realmente est ocurriendo en la red si de lo nico que dispone es de lneas y lneas de alertas inconexas?. Evidentemente se hace necesario un anlisis asistido por ordenador sobre esa cantidad de informacin que aporte al administrador de red una visin general de la situacin de la red en cada momento y un sistema de navegacin ms exhaustivo que le aporte mayor detalle en los puntos en que estime necesario. Estas funcionalidades tan avanzadas restaran capacidad computacional si se ejecutaran en la misma mquina en la que corre un IDS lo cual no es deseable, como antes se ha descrito. El sistema IDSAI pretende dar una solucin a este problema. Mediante una arquitectura distribuida basada en agentes inteligentes se pueden repartir los mdulos de sensor IDS, anlisis computacional de los resultados y presentacin de los mismos de forma estructurada, escalable y funcional.
280
5.2.1. MODELO DE ARQUITECTURA EN CAPAS

La distribucin 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 ms general o especializada y devuelve sus resultados a la capa superior. Un tpico modelo IDS distribuido basado en capas se compone de 3 niveles bien diferenciados [KOZI03]:
supervisor presentacin Capas IDS distribuido SUPERVISOR anlisis ANALISTA alertas SENSOR paquetes red
Fig. 43: Modelo de capas general de un IDS
Donde se distinguen las siguientes capas:
281
o Capa Sensor: Encargada de la captura del trfico de red y generacin de alertas. o Capa Analista: Encargada del anlisis de las alertas. o Capa Supervisor: Encargada de la presentacin visual de los anlisis y la visin general del sistema al supervisor de la red. Esta sencilla divisin de responsabilidades en capas es la base de todas las arquitecturas distribuidas de IDS y en particular del sistema IDSAI.
282
5.2.2. MODELO DE ARQUITECTURA IDSAI

El modelo distribuido del sistema IDSAI 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 implantacin de los elementos que forman cada capa, es sin duda la escalabilidad del sistema y la capacidad de especializacin que permite aportar cada agente, sobre todo en la capa de anlisis. De esta manera, el modelo de capas del sistema IDSAI, cambia ligeramente respecto al esquema por defecto:
supervisor presentacin SUPERVISOR RELOJ anlisis ANALISTA anomalas INTRPRETE alertas SENSOR (Snort) paquetes red Capas IDSAI
Fig. 44: Modelo de capas del sistema IDSAI
283
En el sistema IDSAI se distinguen en detalle las siguientes capas y funciones: o Capa Sensor: Encargada de la captura del trfico de red y generacin de alertas. Esta capa est compuesta exclusivamente por agentes Sensor (ver apartado 4.2.2: Agente Sensor). En una implantacin del sistema IDSAI se pueden disponer cuantos agentes Sensor se precisen en los segmentos de red que se deseen supervisar. La instalacin de un agente Sensor va ntimamente relacionada con la configuracin del sistema Snort al cual va asociado y de la base de datos MySQL snortdb donde el IDS volcar sus resultados. Ver apartados 3.1.3: Implantacin de IDS y 3.5: Snort adems de toda la documentacin posible relacionada con Snort. o Capa Intrprete: Encargada de la primera manipulacin de las alertas registradas en la base de datos snortdb de cada sensor Snort. Esta capa est compuesta exclusivamente por agentes Intrprete (ver apartado 4.2.3: Agente Intrprete, y siguientes) de las diferentes especialidades. En una implantacin del sistema IDSAI se pueden disponer cuantos agentes Intrprete se precisen, de las diferentes clases de firmas, asociados a cada instancia de la base de datos snortdb cuyos datos se deseen analizar. Cada agente Intrprete se arranca pasndole como parmetro la fiabilidad de las Anomalas detectadas por su Sensor correspondiente. El trabajo principal de un agente Intrprete consiste en obtener, en cada ventana temporal, de todo el conjunto de alertas almacenadas en su base de datos snortdb asociada, aquellas que se corresponden con Signatures de su especialidad y crear estructuras Anomala (ver apartado 4.1.2.4: Anomala) cuyo principal atributo es dicha lista de
284
eventos. Los elementos de esta lista estn caracterizados por su valor de secuencia y fecha en que se registraron, por lo que grficamente se pueden representar de la siguiente manera:
tiempo de ventana
5 ms de 3 seg.
8 ms de 3 seg.
15
primer Evento de la Anomala
ltimo Evento de la Anomala
Fig. 45: Ejemplo grfico de Eventos de una Anomala
En la figura 45 se simboliza con una lnea gruesa horizontal el tiempo de ventana dentro del cual el agente Intrprete recoge los Eventos registrados, que se representan con valos numerados. El nmero de cada Evento indica su nmero de secuencia a la hora de ser detectado por el sensor Snort independientemente del tiempo, que queda representado en el dibujo como la posicin de los valos a lo largo de la lnea temporal horizontal. Tras construir la lista de Eventos que forman la Anomala el agente Intrprete realiza una agrupacin de los mismos en Ataques con un criterio fijo (ver apartado 4.1.2.3: Ataque). En el ejemplo representado grficamente en la figura 45, las discontinuidades en los nmeros de secuencia significaran que el
285
sensor Snort ha disparado alertas intermedias entre Eventos con la firma de esta Anomala, aunque temporalmente no estn
considerablemente separados. Por otra parte las grandes separaciones temporales entre Eventos consecutivos desde el punto de vista de su numeracin significan que en el intervalo de tiempo entre el registro de los dos Eventos el sensor Snort no ha disparado ninguna Alerta de ningn tipo. Segn el criterio de identificacin de Ataques explicado en el apartado 4.1.2.3: Ataque, la agrupacin de Eventos en Ataques sera de la siguiente manera:
tiempo de ventana
5 ms de 3 seg.
8 ms de 3 seg.
15
Ataque #1
Ataque #2
Ataque #3
Fig. 46: Anomala con agrupacin de Eventos en Ataques
o Capa Analista: Encargada del anlisis de las estructuras Anomala de la clase de firma de su especialidad recibidas de los agentes Intrpretes correspondientes, de la capa inferior. Esta capa est compuesta exclusivamente por agentes Analista (ver apartado 4.2.10: Agente Analista, y siguientes) de las diferentes
especialidades. En una implantacin del sistema IDSAI se debe disponer de un agente de este tipo, y slo uno, por cada especialidad
286
de agente Intrprete desplegado en el sistema, independientemente de su nmero. El agente Analista ser el destinatario de todos los Anlisis procedentes de los agentes Intrpretes de su clase por lo que debe tener un nombre fijo: analista<clase>. La misin del agente Analista es la elaboracin de estadsticas de las Anomalas recibidas y la aplicacin de heursticas de la clase de signature en la que est especializado para reducir la cantidad de informacin de forma que sea ms general y manejable a la hora de procesarla. Esta informacin se integrar en la estructura Anlisis (ver apartado 4.1.2.5: Anlisis), asociada a cada Anomala. A la hora de enviar sus resultados a la capa superior, el agente Analista realiza un nico Resumen (ver apartado 4.1.2.7: Resumen) de todos los Anlisis elaborados en la ventana actual, con una valoracin borrosa del estado de la red desde el punto de vista de su especialidad, que enviar al agente Supervisor. En un determinado momento, un agente Analista tiene conocimiento de todas las Anomalas recibidas en las ltimas 20 ventanas y de todos sus Anlisis correspondientes. o Capa Supervisor: Encargada de realizar el Diagnstico de la situacin de la ventana actual (ver apartado 4.1.2.8: Diagnstico) en base a los Resmenes recibidos de los Analistas de la capa inferior. Esta capa est compuesta exclusivamente por un slo agente Supervisor (ver apartado 4.2.17: Agente Supervisor) ya que al ser el elemento de ms alto nivel, es el que muestra la informacin ms general al usuario de forma centralizada. El agente Supervisor ser el destinatario de todos los Resmenes procedentes de los agentes Analistas, por lo que debe tener un nombre fijo: supervisor. En un determinado momento, un agente Supervisor tiene conocimiento de
287
todos los Resmenes recibidos en las ltimas 20 ventanas y de todos sus anlisis correspondientes. o Capa Reloj: Capa vertical (es decir, que da servicio a todas las capas horizontales) encargada de sincronizar los agentes Intrpretes, Analistas y Supervisor, marcndoles la ventana temporal. Esta capa est compuesta exclusivamente por un slo agente Reloj (ver apartado 4.2.1: Agente Reloj), y su presencia es indispensable para el funcionamiento de la plataforma. Los agentes con necesidad de ser sincronizados por el agente Reloj deben darse de alta en su lista de agentes vivos por lo que ste debe tener un nombre fijo: reloj. Debido a la naturaleza de agentes inteligentes JADE de los elementos que las forman, el intercambio de informacin entre las diferentes capas de la arquitectura se realiza a travs de mensajes ACL, excepto entre las Sensor e Intrprete, donde el intercambio de informacin se realiza mediante accesos directos a la base de datos snortdb. Los parmetros de los mensajes ACL que intercambian los agentes que componen la arquitectura tienen funciones muy concretas en el sistema IDSAI y permiten clasificarlos por sus valores: o language: Determina la intencin del mensaje para los agentes que necesitan distinguir entre mensajes de sincronizacin "sync" o mensajes que contienen datos "data". o performative: Valor numrico que permite pasar en el mensaje una informacin adicional al contenido del mismo. Es utilizado por los agentes Intrprete para propagar la fiabilidad de la informacin que transmiten y por el agente Reloj para indicar el valor de la ventana actual.
288
o content: Almacena la estructura de datos que el agente origen enva al destino. Puede ser un array de Anomalas para un agente Analista, una estructura Resumen para el agente Supervisor, el tamao de la ventana del sistema en los mensajes de sincronizacin o una simple instruccin de "ALTA" o "BAJA" para la lista de agentes vivos del Reloj. En funcin del valor del campo language y de la naturaleza del comportamiento que comprueba el buzn de correo, el agente destinatario sabr cmo interpretar el contenido del mensaje y actuar en consecuencia. El anexo 3: Diagrama de la arquitectura muestra un esquema ejemplo de implantacin del sistema IDSAI. La arquitectura propuesta est compuesta por 1 agente Reloj, 2 agentes Sensor (con sus correspondientes instancias de Snort y MySQL snortdb), 2 y 3 agentes Intrpretes de diferentes tipos asociados a los agentes Sensor (en total, 5), 3 agentes Analistas de los mismos tipos que los Intrpretes y 1 agente Supervisor. En el diagrama se indica, bajo los agentes, el esquema de los nombres que deben tener y sus parmetros de arranque ms caractersticos. Tambin se representa el flujo de la informacin a lo largo de las diferentes capas en forma de flechas, muchas de ellas representando el sentido de intercambio de mensajes ACL entre los agentes.
289
5.2.3. MODELO DE COMPORTAMIENTOS

El funcionamiento de la arquitectura del proyecto IDSAI est regido por los comportamientos que incorporan los agentes que componen cada una de las capas del sistema. Los agentes que forman el sistema IDSAI implementan, en su totalidad, comportamientos cclicos y peridicos que no terminan mientras los agentes estn vivos. Esto debe ser as porque mientras una instancia de Snort est arrancada, puede generar una alerta en cualquier momento y los agentes activos del sistema deben reaccionar inmediatamente segn una respuesta determinista y homognea para cualquier tipo de evento. Un ejemplo de stos, es el comportamiento LimpiarBD propio del agente Sensor (no incorporado en la versin final del sistema IDSAI por cuestiones de rendimiento). LimpiarBD ejecuta peridicamente, independientemente de la sincronizacin temporal del Reloj, instrucciones para limpiar la base de datos snortdb sobre la que trabaja la instancia de Snort que lanza el agente Sensor en su arranque. Puesto que el arranque de los agentes no tiene por qu ser simultneo (y de hecho es imposible que lo sea), la sincronizacin de sus comportamientos debe estar asistida por un agente comn que haga esta funcin. Esta tarea es llevada a cabo por el agente Reloj (ver apartado 4.2.1: Agente Reloj) con su comportamiento Sincronizar (ver apartado 4.3.4: Sincronizar), por el cual enva peridicamente, segn el tamao fijado de la ventana, un mensaje a todos los agentes vivos con el valor de la ventana actual. Para poder saber qu agentes estn vivos en el sistema en un determinado momento, el agente Reloj dispone del comportamiento RecibirNotificaciones a la espera de mensajes de "ALTA" y "BAJA", que le envan los agentes con necesidad de sincronizacin al arrancarse y morir, respectivamente.
290
En el momento en que un agente recibe un mensaje de sincronizacin con el nuevo valor de la ventana actual, comienza un nuevo ciclo de lo que podemos denominar ventana temporal. El comportamiento de cada agente es diferente en cada ventana temporal, pero siempre debe seguir el mismo ciclo y el mismo intercambio de mensajes entre agentes: Los agentes Intrpretes reaccionan ante un mensaje de sincronizacin (comienzo de nueva ventana temporal) ejecutando el mtodo
obtenerAnomalias() de la clase AnomaliaDAO para obtener la lista de Anomalas del tipo de firma en que estn especializados, correspondientes a la ltima ventana temporal. Una vez disponen de ella, la envan en un mensaje ACL de tipo "data" al agente Analista de su misma especialidad. El agente se queda de nuevo a la espera de una nueva ventana temporal. Los agentes Analistas reaccionan ante un mensaje de sincronizacin (comienzo de nueva ventana temporal) realizando una serie de operaciones de mantenimiento del registro de Anomalas y Anlisis que mantienen en memoria antes de ponerse a la espera de las nuevas Anomalas de la ventana actual que les deben enviar los agentes Intrpretes. Una vez las reciben, construyen los Anlisis correspondientes a las Anomalas recibidas y elaboran el Resumen, que acto seguido envan al agente Supervisor. Tras el envo del Resumen, se quedan a la espera de una nueva ventana temporal. Finalmente, el agente Supervisor reacciona ante un mensaje de sincronizacin (comienzo de nueva ventana temporal) realizando el Diagnstico de la ventana anterior, ya que slo al principio de esta ventana es cuando puede estar seguro de haber recibido todos los Resmenes procedentes de los agentes Analistas del ciclo anterior. En esta accin queda patente el hecho de que si el sensor Snort lanza una alerta en medio de una ventana temporal (ya que no funciona sincronizadamente), el agente Intrprete esperar hasta la siguiente
291
ventana para detectar la Anomala, y cuando el Resumen correspondiente llegue al agente Supervisor, ste no diagnosticar la situacin hasta una ventana temporal ms tarde. El retardo del agente Supervisor es inevitable si se pretende montar una arquitectura escalable donde no importe el nmero de agentes arrancados en las capas intermedias. Tras mostrar los resultados del Diagnstico al usuario a travs de la interfaz grfica, el agente Supervisor procede al mantenimiento del registro de Resmenes y Diagnsticos que mantiene en memoria antes de ponerse a las espera de nuevos Resmenes de la ventana actual que le deben enviar los agentes Analistas. Cada Resumen recibido es almacenado en el registro de Resmenes para ser procesados al comienzo de la prxima ventana temporal. El anexo 4: Diagrama de secuencia muestra un esquema ejemplo del comportamiento de una serie de agentes del sistema IDSAI en el espacio de una ventana temporal. La arquitectura propuesta est compuesta por 1 agente Reloj, 1 agente Sensor (con sus correspondientes instancias de Snort y MySQL snortdb), 2 agentes Intrpretes de diferentes tipos asociados al agente Sensor, 2 agentes Analistas de los mismos tipos que los Intrpretes y 1 agente Supervisor. En el diagrama se representan, bajo los agentes en lneas verticales, los comportamientos que implementan y las acciones que llevan a cabo antes descritas (envo de mensajes y procesos) en el tiempo que comprende la ventana temporal.
292
6. DISTRIBUCIN DEL PROYECTO IDSAI

El proyecto IDSAI se distribuye en soporte electrnico y consiste en dos partes: Carpeta de proyecto IDSAI con todos los archivos necesarios para el arranque de la plataforma de agentes inteligentes. Carpeta de instalables INSTALACION IDSAI con todos los recursos (programas externos y ficheros de configuracin) necesarios para la implantacin de una plataforma de agentes IDSAI.
6.1.
CARPETA DE PROYECTO IDSAI

La carpeta de proyecto IDSAI es el producto del equipo de desarrollo del
proyecto IDSAI, y dispone todos los archivos necesarios para el arranque de la plataforma de agentes inteligentes y su mantenimiento:
293
Fig. 47: Carpeta del proyecto IDSAI Donde los ficheros: o .classpath y .project: Ficheros generados por el entorno de desarrollo Eclipse. o MTPs-Main-Container.txt y APDescription.txt: Ficheros propios de la ejecucin del entorno de desarrollo JADE. o instalar.bat: Script ejecutable de instalacin de los contenidos de la carpeta de proyecto en C:\IDSAI, desde donde se debe arrancar el aplicativo. o IDSAISensor.bat: Script ejecutable ejemplo de arranque de los agentes JADE tpicos en un host Sensor: equipo dedicado sobre el que corre un agente Sensor y una serie de agentes Intrpretes,
294
correspondientes a las capas Sensor e Intrprete de la arquitectura IDSAI (ver apartado 5.2.2: Modelo de arquitectura IDSAI). o IDSAIAnalista.bat: Script ejecutable ejemplo de arranque del conjunto de agentes que forman la capa Analista (ver apartado 5.2.2: Modelo de arquitectura IDSAI). Por cuestiones de rendimiento, es recomendable arrancar todo el conjunto de agentes Analistas en un host dedicado, aunque no es necesario. o IDSAISupervisor.bat: Script ejecutable ejemplo de arranque del agente Supervisor y el agente Reloj del sistema IDSAI correspondientes a las capas Supervisor y Reloj de la arquitectura IDSAI (ver apartado 5.2.2: Modelo de arquitectura IDSAI). Por cuestiones de rendimiento, es recomendable arrancar estos agentes en un host dedicado a la gestin centralizada de la red, ya que no implican una alta carga computacional y la presentacin en tiempo real del estado de la red ayuda en gran medida a la toma de decisiones. o IDSAILocalTotal.bat: Script ejecutable ejemplo de arranque de una instancia de cada agente del sistema IDSAI en la mquina local. En este ejemplo se arranca 1 agente Sensor (con su correspondiente instancia de Snort y acceso a la base de datos MySQL snortdb), 6 agentes Intrpretes (uno de cada tipo), 6 agentes Analistas (uno de cada tipo), 1 agente Supervisor y 1 agente Reloj. La ejecucin de esta cantidad de agentes requiere de una carga computacional grande, y el sistema no demostrar un buen rendimiento. No obstante es un buen test de estrs que resulta interesante hacer para comprobar la puesta a punto del sistema. Esta prueba se realiza sobre la captura de red ataqueIDSAI.pcap que se proporciona con la distribucin y que debe
295
ubicarse all donde se especifique en el arranque del agente Sensor. El hecho de trabajar sobre una captura de red y pretenderlo hacer en tiempo real, requiere retrasar el reloj del sistema a la fecha en la que se hizo la captura. La ejecucin del script automatiza la actualizacin de la fecha del sistema al momento preciso por lo que se debe restablecer manualmente al terminar la sesin.
Donde las carpetas: o src: Contiene los paquetes Java correspondientes a los ficheros fuente .java programados que forman parte del proyecto. o bin: Contiene los paquetes Java correspondientes a los ficheros binarios .class interpretados que forman parte del proyecto. o etc: Contiene ficheros miscelneos del sistema IDSAI: Carpeta de imgenes e iconos de la interfaz del sistema. snortdb.sql: Script de construccin del esquema de la base de datos snortdb. IDSAI.conf: Fichero de configuracin de la instancia de Snort que lo vincule en su arranque. o lib: Contiene libreras de funciones que importan las diferentes clases del sistema: libreras JADE y driver de conexin con la base de datos MySQL.
296
o log: Contiene los archivos de bitcora donde los diferentes agentes del sistema IDSAI vuelcan la informacin que manipulan una vez deja de estar disponible a travs de la interfaz. o doc: Contiene la documentacin del proyecto: Portada PFC: Portada del proyecto y hoja de firmas, segn la Normativa de proyectos Fin de Carrera. Resumen PFC: Resumen del proyecto en castellano e ingls, segn la Normativa de proyectos Fin de Carrera. Proyecto Fin de Carrera: El grueso de la presente documentacin. Carpeta ANEXOS: Conjuntos borrosos IDSAI. Diagrama de clases. Diagrama de la arquitectura. Diagrama de secuencia. Esquema snortdb. Signatures IDSAI (Snort)
297
6.2.
CARPETA DE INSTALABLES INSTALACION IDSAI

La carpeta de instalables INSTALACION IDSAI contiene una recopilacin
de recursos (programas externos y ficheros de configuracin) necesarios para la implantacin de una plataforma de agentes IDSAI. Todos los productos que se proporcionan en esta compilacin son de libre distribucin o pueden obtenerse de forma gratuita por lo que no se viola ninguna ley de derechos de autor o similares:
298
Fig. 48: Carpeta de instalables INSTALACION IDSAI
Donde los ficheros: o ataqueIDSAI.pcap: Captura de red con presencia de ataques intrusos para la realizacin de pruebas del sistema IDSAI.
299
o IDSAI.conf: Fichero de configuracin bsico de los sensores Snort del sistema IDSAI, que habr que adaptar segn la arquitectura de red en la que se pretenda implantar. o JADE-all-3.4.zip: Fichero comprimido que contiene las libreras bsicas de la distribucin 3.4 de JADE. Estas libreras ya estn incorporadas en la carpeta de proyecto IDSAI en la subcarpeta lib. o jdk-1_5_0_10-windows-i586-p.exe: Instalable de la versin 5.0 del JDK de Java, necesario para el desarrollo e interpretacin del cdigo Java en que consiste el proyecto. o MySQL-5.0.27-win32-Setup.exe: Instalable de la versin 5.0 del Sistema Gestor de Bases de datos MySQL. o mysql-connector-java-5.0.4-bin.jar: Driver de conexin al SGBD MySQL para Java. o mysql-gui-tools-5.0-r8-win32.msi: Instalable de las herramientas de acceso al SGBD MySQL de forma grfica. o Snort_2_6_1_1_Installer.exe: Instalable de la versin 2.6.1.1 del IDS Snort. o snort_manual.pdf: Manual de instalacin, configuracin y uso del IDS Snort, necesario para sacarle el mximo partido a la herramienta. o snortdb.sql: Script SQL que crea la base de datos snortdb (si existe previamente, la elimina y la vuelve a crear desde cero), le da todos los permisos al usuario snort, y crea todas las tablas y columnas segn el esquema snortdb.
300
o WinPcap_3_0.exe: Instalable de la librera de captura de paquetes estndar para Windows, necesaria para la escucha del medio de red en modo promiscuo del interfaz Snort.
Donde las carpetas: o Snort rules: Contiene los ficheros de reglas .rules del motor de inferencias de Snort, que la distribucin original de Snort no incorpora por defecto y debe hacerse de forma manual. o Programas ataques: Contiene los instalables de los programas de intrusin Nessus y Nmap utilizados en las pruebas del sistema IDSAI durante su desarrollo.
301
7. MANUAL DE INSTALACIN DEL SISTEMA IDSAI

El sistema IDSAI ha sido desarrollado para ser desplegado en plataformas Windows, aunque en la red en que funcione pueden coexistir otros sistemas operativos. El sistema IDSAI engloba una serie de subsistemas que es necesario instalar de la forma adecuada para su correcto funcionamiento en conjunto. Estos subsistemas son los siguientes: Sistema de Deteccin de Intrusos: El IDS Snort 2.6.1.1 es la herramienta escogida para este subsistema. La configuracin de Snort no es trivial y se requieren amplios conocimientos sobre la aplicacin por lo que se recomienda leer la documentacin relacionada as como el apartado 3.5: Snort. Una instalacin del sistema IDSAI en un entorno real, requiere de varias instancias de Snort dispuestas en diferentes segmentos de red, en este aspecto tambin se recomienda leer la documentacin relacionada as como el apartado 3.1: Sistemas de Deteccin de Intrusos. Sistema Gestor de Bases de Datos: Cada una de las instancias de Snort dispuestas a lo largo de la red requieren de una instalacin asociada del SGBD MySQL 5.0.27, con un esquema de la base de datos snortdb ya instanciado donde volcar los resultados del IDS. Tambin es necesario que los agentes inteligentes tengan derecho de acceso a la base de datos por lo que habr que crear un usuario con los permisos adecuados dedicado a este fin. Plataforma de agentes inteligentes JADE: Para la ejecucin de los agentes diseados, ser necesario contar con las libreras Java JADE, ya incorporadas en la carpeta lib de la estructura del proyecto.
302
7.1.
INSTALACIN DE LA MQUINA VIRTUAL JAVA

El sistema IDSAI basa su despliegue en agentes Java JADE, por
lo que para su ejecucin en cada una de las mquinas que albergan entidades de este tipo es necesaria la presencia de una Mquina Virtual Java (JVM, en ingls, Java Virtual Machine). Si no se cuenta con una JVM instalada previamente en el sistema, la distribucin de la aplicacin proporciona una copia de la versin 5.0. Para su instalacin en cada mquina implicada en el sistema IDSAI se debe ejecutar el instalable jdk-1_5_0_10-windows-i586-p.exe, que se proporciona con la
distribucin de la aplicacin:
Los pasos a seguir durante la instalacin son los siguientes: 1. Aceptar los trminos de la licencia de Sun Microsystems. 2. Seleccionar los componentes de la JVM a instalar y la ruta, aunque es recomendable dejar los parmetros por defecto y no compromete al sistema. 3. Continuar con la instalacin de la JRE (Java Runtime Environment), componente bsico de la JVM por ser el elemento encargado de la interpretacin en tiempo real del cdigo Java. De nuevo, es recomendable dejar los parmetros de componentes y ruta de instalacin con los valores por defecto. 4. Continuar hasta el final de la instalacin.
303
7.2. INSTALACIN DEL IDS SNORT

La instalacin de un IDS, y en particular la del IDS Snort por ofrecer tantas opciones de configuracin, no es trivial y requiere una importante inversin de tiempo para aprender las diferentes formas de optimizar la herramienta y adaptarla al entorno en que se va a ejecutar. Como primera medida, es necesaria la instalacin del software Snort en al menos una mquina dedicada de la red (host Sensor). Para ello se debe ejecutar el instalable Snort_2_6_1_1_Installer.exe, que se proporciona con la distribucin de la aplicacin:
Los pasos a seguir durante la instalacin son los siguientes: 1. Aceptar los trminos de la licencia GNU. 2. Seleccionar un modo de logging a base de datos MySQL (opcin por defecto). 3. Seleccionar todos los componentes de Snort para la instalacin (seleccionados todos por defecto). 4. Determinar como la carpeta donde se instalar el software la carpeta por defecto: C:\Snort. 5. Continuar hasta el final de la instalacin. Como se ha explicado en el apartado 3.5: Snort, para que este IDS pueda capturar paquetes de red, es necesario que en el equipo en que se corra est
304
instalada la librera de captura estndar libpcap. Si no se cuenta con ella previamente (suele instalarse automticamente con otras aplicaciones de sniffing de red de libre distribucin como Ethereal o Wireshark), debe instalarse ahora. Para ello se debe ejecutar el instalable WinPcap_3_0, que se proporciona con la distribucin de la aplicacin:
Los pasos a seguir durante la instalacin son los siguientes: 1. Aceptar los trminos de la licencia de NetGroup 2. Continuar hasta el final de la instalacin. Llegados a este punto, el IDS Snort puede funcionar correctamente. Ahora es el momento de configurar el sensor Snort adecuadamente para sacarle el mximo rendimiento en la infraestructura de red en que se va a ejecutar y prepararlo para integrarlo en el sistema IDSAI. Para ello el primer paso es actualizar el juego de reglas del motor de inferencias de Snort. Con la distribucin de la aplicacin se proporciona la carpeta Snort rules, que contiene los ficheros bsicos de reglas que habr que importar manualmente a la carpeta C:\Snort\rules. Por supuesto, si el administrador del sistema IDSAI desea aadir algn fichero de reglas propio o modificar los ya existentes, puede hacerlo sin problema, pero debe tenerlo en cuenta para plasmarlo en el fichero de configuracin de arranque de Snort.
305
Fig. 49: Importacin manual de ficheros de reglas.
La ejecucin de Snort en modo NIDS requiere de un fichero de configuracin .conf que especifique detalladamente sus parmetros de arranque. La instalacin por defecto de Snort incluye en el fichero C:\Snort\etc un archivo snort.conf con un ejemplo de configuracin paso a paso que se puede aprovechar para adaptarlo a la configuracin de red a administrar. Se recomienda leer detenidamente el contenido del fichero para aprender los detalles de la configuracin de Snort antes de incorporar al directorio antes mencionado el fichero de configuracin del sistema IDSAI que proporciona la distribucin de la aplicacin. Este proceso se debe hacer manualmente, copiando el fichero IDSAI.conf en la carpeta C:\Snort\etc.
306
Fig. 50: Importacin manual del fichero de configuracin.
Este fichero tiene las siguientes particularidades, que se deben considerar y reeditar para el optimizar el funcionamiento de cada uno de los sensores del sistema IDSAI, dependiendo de las caractersticas de trfico en cada segmento de red: o Variable HOME_NET 192.168.20.0/24. Esta variable debe
modificarse con la direccin IP de la red en la que se ejecute el sensor Snort. El valor de esta variable es fundamental para el chequeo de reglas del motor de inferencias de Snort. o Variable EXTERNAL_NET any. Esta variable puede modificarse si se considera necesario. El valor de esta variable es fundamental para el chequeo de reglas del motor de inferencias de Snort.
307
o Dems variables de configuracin. Deben adaptarse a los valores apropiados para la implantacin apropiada del sistema. o Propiedades del Descodificador de Paquetes de Snort. Pueden habilitarse o deshabilitarse las propiedades que se consideren necesarias con las instrucciones config apropiadas. o Configuracin de Preprocesadores. La configuracin de los preprocesadores que se especifican en el fichero no tiene por qu ser la ms apropiada para la red en la que se implante el sistema. Es muy recomendable repasar los parmetros de los preprocesadores para optimizarlos segn las necesidades de la red, ya que en el ejemplo se inicializan con parmetros por defecto y de carcter general. o Configuracin de mdulos externos. Aparte de los que el usuario desee disponer, resulta fundamental para el sistema IDSAI habilitar la salida de Snort por la base de datos mysql snortdb, con un usuario y contrasea dedicados. o Inclusin de ficheros de reglas. La configuracin del juego de reglas de que dispone el Motor de Inferencias de Snort se realiza incluyendo los ficheros de reglas que se desee mediante instrucciones include. Se debe verificar que tanto los ficheros de reglas que se deseen habilitar como los nuevos que se deseen crear, estn en la carpeta C:\snort\rules. La base de datos MySQL snortdb no es el nico mdulo de salida habilitado para el registro de alertas de los sensores del sistema IDSAI. Para facilitar la interoperabilidad con otras aplicaciones y disponer de la referencia a las alertas en un formato de texto, se recomienda crear una nueva carpeta IDSAI en el directorio C:\Snort\log. En dicha carpeta IDSAI, ser donde, adems de en la base de datos
308
snortdb, los sensores Snort escriban sus alertas en un fichero alert.ids y las incidencias de cada captura en ficheros snort.log. La creacin de esta carpeta no ser necesaria si no se requiere esta salida en el comando de ejecucin de la instancia de Snort. Por ltimo, para que cada agente Sensor pueda arrancar su instancia de Snort correspondiente, es necesario incluir en la variable Path del sistema la ruta hacia el ejecutable snort.exe que segn nuestra instalacin es C:\Snort\bin:
309
Fig. 51: Actualizacin manual del Path del sistema con la ruta de Snort.
Antes de seguir adelante con la instalacin de los dems componentes de IDSAI se recomienda hacer una serie de pruebas arrancando Snort en las diferentes modalidades, y en particular, en modo NIDS, para comprobar que funciona correctamente.
310
7.3. INSTALACIN DEL SGBD MySQL

La instalacin de una instancia de MySQL para el registro de alertas de Snort y la interactuacin con los agentes del sistema IDSAI tiene una serie de particularidades de configuracin que se deben considerar para su correcto funcionamiento. Como primera medida, es necesaria la instalacin del software MySQL en cada uno de los host Sensor de la red (mquinas en las que se ha instalado un sensor Snort). Para ello se debe ejecutar el instalable MySQL-5.0.27-win32-Setup.exe, que se proporciona con la distribucin de la aplicacin:
Los pasos a seguir durante la instalacin son los siguientes: 1. Seleccionar el modo de instalacin por defecto (Typical) y proceder. 2. Registrarse on-line si se desea o saltarse este paso. 3. Continuar hasta el final de la instalacin y pasar al proceso de configuracin. 4. Seleccionar el modo de configuracin detallada (Detailed
Configuration). 5. Seleccionar el modo de servicio en mquina de desarrollo (Developer Machine). 6. Seleccionar el tipo de uso de las bases de datos como de propsito general (Multifunctional Database).
311
7. Seleccionar la ruta de ubicacin de las bases de datos (se recomienda la ruta de instalacin por defecto). 8. Seleccionar como nmero de conexiones concurrentes, tantas como agentes Intrpretes se deseen asociar a cada instancia de la base de datos, ms una, ya que hay que tener en cuenta el acceso continuo a la misma por parte del sensor Snort. Puesto que en la presente versin de IDSAI se han desarrollado 6 especialidades de agente Intrprete, y no tiene sentido asociar dos Intrpretes del mismo tipo a la misma base de datos (porque daran el mismo resultado), basta con permitir hasta 7 conexiones simultneas, aunque se recomienda alguna ms para posteriores ampliaciones. El valor por defecto (Decission Support) es de 20, por lo que resultan ms que suficientes para esta distribucin. 9. Seleccionar un modo de trabajo en red. Los agentes del sistema IDSAI que acceden a las bases de datos (agentes Sensor e Intrpretes) se deben arrancar en los host Sensor, por lo que no es necesario habilitar los accesos remotos a los SGBD (y no se recomienda, por razones de seguridad). No obstante, es necesario abrir un puerto para la conexin con la base de datos en local. Se recomienda cambiar el puerto por defecto y habilitar el modo estricto (Strict Mode) para agilizar los accesos. 10. Seleccionar el juego de caracteres estndar (Standard Character Set), ya que es el mismo con el que se ha desarrollado el resto del aplicativo IDSAI. 11. Instalar el servicio Windows MySQL y aadir el directorio donde se encuentra el arranque de MySQL en el PATH del sistema si se desea trabajar mediante la consola. Ms adelante se proceder a la
312
instalacin de una serie de herramientas de administracin y acceso al SGBD que permitan la manipulacin de las bases de datos desde una agradable interfaz grfica, por lo que deja de ser necesario el acceso a travs de la lnea de comandos. 12. Modificar las opciones de seguridad introduciendo una nueva contrasea raz y confirmndola. No ser necesario ni deseable crear una cuenta de usuario annimo, por cuestiones de seguridad. 13. Continuar hasta el final de la instalacin. La manipulacin y configuracin de una base de datos MySQL es un trabajo tedioso si se realiza desde la consola del sistema, por lo que resulta muy cmodo hacerlo desde una interfaz grfica. La distribucin de la aplicacin IDSAI proporciona una copia de la interfaz grfica oficial de MySQL en el instalable mysql-gui-tools-5.0-r8-win32.msi, de instalacin opcional:
Los pasos a seguir durante la instalacin son los siguientes: 1. Aceptar los trminos de la licencia MySQL. 2. Seleccionar la ruta de instalacin de las herramientas. (Se recomienda la ruta de instalacin por defecto). 3. Seleccionar el modo de instalacin completo que incluye todos los componentes grficos necesarios para la administracin de la base de datos 4. Continuar hasta el final de la instalacin.
313
El resultado de la instalacin es que disponemos de una serie de programas que nos facilitarn el acceso a la informacin de las bases de datos de forma directa y nos ayudarn en la configuracin de la base de datos snortdb:
Fig. 52: Programas MySQL instalados.
El siguiente punto es la configuracin de la base de datos snortdb, donde el sensor Snort vuelca los resultados y los agentes Intrpretes los recogen para su procesamiento. Para ello debemos abrir el programa recin instalado MySQL Administrator, con un acceso local (localhost) al puerto especificado para el servicio MySQL, introduciendo el nombre y contrasea del usuario raz. El men de la aplicacin nos permite navegar por los diferentes aspectos del Sistema Gestor de Bases de Datos y facilita muchas funcionalidades. Entre ellas la que habremos de considerar para la configuracin del acceso a la base de datos snortdb es la pestaa Administracin de Usuarios (User Administration). Entrando en este apartado, se debe crear un nuevo usuario de nombre "snort" y contrasea "snort", ya que es la autenticacin que posteriormente utilizarn los agentes Intrpretes para acceder a la base de datos snortdb:
314
Fig. 53: Creacin de usuario snort.
En el momento en que disponemos del usuario snort, el SGBD est preparado para crear el esquema snortdb. Para facilitar esta labor, la distribucin de la aplicacin proporciona un script SQL que crea la base de datos snortdb (si existe previamente, la elimina y la vuelve a crear desde cero), le da todos los permisos al usuario snort, y crea todas las tablas y columnas segn el esquema snortdb (ver anexo 5: Esquema snortdb). La ejecucin del script snortdb.sql se puede realizar cmodamente mediante la herramienta MySQL Query Browser. Para ello nos conectamos mediante un acceso local (localhost) al servicio MySQL, introduciendo el nombre y contrasea del usuario raz, como se hizo anteriormente. Una vez en el interfaz del programa, entrar en el men Archivo (File) Abrir Script (Open Script) y buscar el fichero snortdb.sql que proporciona la distribucin de la aplicacin.
315
Fig. 54: Carga del script snortdb.sql.
Una vez se ha cargado el script snortdb.sql se procede a su ejecucin en el botn Ejecutar (Execute) de la parte superior de la ventana. Tras unos segundos, la base de datos snortdb est limpia y lista para ser cargada con la informacin del sensor Snort.
316
7.4. INSTALACIN DE LA PLATAFORMA IDSAI

La instalacin de la plataforma de agentes inteligentes IDSAI es muy sencilla. Desde el soporte de la distribucin, en la carpeta del proyecto IDSAI, basta con ejecutar el script instalar.bat, para que todo el contenido de dicha carpeta sea copiado al directorio C:\IDSAI, desde donde los agentes IDSAI funcionarn adecuadamente. Copiar la carpeta entera y no de forma selectiva significar que en muchos casos habr instalados en una mquina ms tipos de agentes de los que se van a correr en ella. Por cuestin de flexibilidad, si se pretende introducir un cambio en el esquema de agentes planificado en un principio, resulta ms cmodo disponer de todas las posibilidades en todos los equipos. De esta manera se simplifica la instalacin de los agentes sin comprometer la capacidad del equipo, ya que el volumen de cdigo es muy pequeo. Llegados a este punto, la instalacin de los componentes bsicos sobre los que ejecutar el sistema IDSAI en las diferentes mquinas de la distribucin 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.
317
8. MANUAL DE USO DEL SISTEMA IDSAI

El sistema IDSAI, al ser un IDS basado en una arquitectura distribuida, requiere amplios conocimientos por parte de sus usuarios (tpicamente administradores de red y personal de seguridad informtica) tanto del tema de los Sistemas de Deteccin de Intrusos como de los sistemas distribuidos en entornos de red. Por las particularidades que puede presentar la red a supervisar con la instalacin del sistema IDSAI, la puesta a punto de los agentes forma parte del trabajo del administrador de la red desde el punto de vista del usuario: Configuracin de los sensores Snort. Diseo del plan de distribucin de los agentes de la plataforma. Sobre este punto se ha hecho hincapi en el apartado 3.1.3: Implantacin de IDS, por lo que no se volver a insistir en este punto. Edicin y ejecucin de los scripts de arranque de los agentes de la plataforma. Una vez estn corriendo los agentes en los diferentes equipos estratgicamente distribuidos por la red, el usuario debe conocer las particularidades de uso de la herramienta, para poder interpretar adecuadamente los resultados de la ejecucin y saber utilizar la interfaz de los agentes para navegar por los resultados y la informacin detallada de las anomalas detectadas en la red.
318
8.1.
CONFIGURACIN DE LOS SENSORES

La configuracin de los sensores Snort requiere de un gran dominio de la
herramienta a la hora de conocer todas sus particularidades. Aun siendo un experto en Snort, el encargado de su configuracin debe tener un amplio conocimiento sobre la red a supervisar, el tipo de trfico autorizado en la misma, su organizacin y mtodos de seguridad perimetral, etc. Esto resulta fundamental a la hora de hacer una distribucin de sensores en zonas estratgicas de la red tal y como se explica en el apartado 3.1.3: Implantacin de IDS. La configuracin de los sensores Snort para adaptarlos a las particularidades de la red en cuestin no es trivial. El administrador de red deber considerar cada uno de los parmetros de Snort presentes en el fichero de configuracin de cada sensor C:\Snort\etc\IDSAI.conf y ajustarlos adecuadamente segn las necesidades de inspeccin, segn se hace una breve introduccin en el apartado 3.5.2: Componentes de Snort. Puesto que ya se ha insistido en este tema en anteriores apartados de la presente documentacin, este punto no se desarrollar ms en detalle.
319
8.2. ARRANQUE DE LOS AGENTES

Una vez se dispone de las herramientas IDS definitivamente situadas en los diferentes hosts de la red y calibradas a tal efecto, se deben editar los scripts de arranque de los agentes que procedan en dichas mquinas. El arranque de agentes en la plataforma IDSAI se realiza mediante scripts de ejecucin de lneas de comando. Aunque el proceso de edicin de un script sea un trabajo tedioso e incmodo, en la distribucin original del aplicativo se ha dejado de esta manera por motivos de flexibilidad a la hora de arrancar los agentes de la plataforma con sus distintos parmetros de inicializacin por la consola. Evidentemente es necesario que el encargado de la manipulacin del sistema IDSAI tenga los conocimientos bsicos de arranque y gestin de agentes JADE, por lo que tambin es recomendable estar familiarizado con las herramientas que acompaan al middleware JADE, sobre todo con la interfaz de gestin de la plataforma RMA que se recomienda arrancar en algn host poco cargado de la plataforma para supervisar la actividad del sistema de forma centralizada. La distribucin original de IDSAI requiere que en las mquinas que incorporan una instancia del IDS Snort, el arranque de sta se haga mediante un agente Sensor (ver apartado 4.2.2: Agente Sensor) acompaado por sus agentes Intrpretes (ver apartado 4.2.3: Agente Intrprete, y siguientes) asociados arrancados igualmente en local. Por ello, en la carpeta de proyecto IDSAI se propone un script ejemplo de arranque de un host Sensor:
Ejecutando este fichero se arrancan los siguientes agentes en local con sus correspondientes parmetros de arranque:
320
sensor1 : AgenteSensor(0 C:\Snort\log\ATAQUEIDSAI\ataqueIDSAI.pcap) interpreteattempted-recon1 : AgenteInterpreteAttemptedRecon(10) interpreteunknown-class1 : AgenteInterpreteUnknownClass(9) interpreteattempted-admin1 : AgenteInterpreteAttemptedAdmin(10) interpreteattempted-dos1 : AgenteInterpreteAttemptedDos(9) interpretebad-unknown1 : AgenteInterpreteBadUnknown(9) interprete-otros1 : AgenteInterpreteOtros(10)
Donde la ruta especificada como segundo parmetro del Agente Sensor indica el fichero de captura de red que se proporciona con la distribucin del proyecto IDSAI. Evidentemente, este script puede ser editado arrancando otros agentes y modificando sus parmetros segn el plan de implantacin del sistema. La distribucin original de IDSAI sugiere que el arranque de los agentes Analistas (ver apartado 4.2.10: Agente Analista, y siguientes), encargados de procesar la informacin recogida por los agentes Intrpretes, se realice en mquinas dedicadas diferentes de los hosts Sensor. En la carpeta de proyecto IDSAI se propone un script ejemplo de arranque de un host Analista:
Ejecutando este fichero se arrancan los siguientes agentes en local:

analistaattempted-recon : AgenteAnalistaAttemptedRecon analistaunknown-class : AgenteAnalistaUnknownClass analistaattempted-admin : AgenteAnalistaAttemptedAdmin
321
analistaattempted-dos : AgenteAnalistaAttemptedDos analistabad-unknown : AgenteAnalistaBadUnknown analista-otros : AgenteAnalistaOtros
Evidentemente, este script puede ser editado arrancando otros agentes segn el plan de implantacin del sistema. Por ltimo, la distribucin original de IDSAI, sugiere que el arranque del agente Supervisor (ver apartado 4.2.17: Agente Supervisor), necesario para la monitorizacin del estado de la red, se realice en una mquina dedicada y de fcil acceso para el administrador de red. En la carpeta de proyecto IDSAI se propone un script ejemplo de arranque de un host Supervisor:
Ejecutando este fichero se arrancan los siguientes agentes en local con sus correspondientes parmetros de arranque:
supervisor : AgenteSupervisor reloj : AgenteReloj(20)
Donde el valor especificado como parmetro del Agente Reloj indica el periodo de la ventana temporal de sincronizacin de los agentes de la plataforma. La carga computacional que supone el arranque del agente Reloj es lo suficientemente pequea como para que pueda convivir con el Supervisor. Adems la interfaz del agente Reloj es muy interesante para el administrador del sistema a la hora de saber qu agentes se encuentran vivos en un determinado momento. Debido
322
a que este equipo ser supervisado de cerca por el encargado de la red, ser interesante que tambin se arranque en l el agente RMA, que facilite la gestin de la plataforma, y puesto que ser un equipo bien conocido de la red puede declararse contenedor principal (Main-Container) de la plataforma. Evidentemente, este script puede ser editado arrancando otros agentes y modificando sus parmetros segn el plan de implantacin del sistema. Estos tres scripts ejemplo permiten el arranque de una plataforma de agentes IDSAI funcional y se dejan abiertos a la edicin por parte del usuario para que realice la configuracin que ms le convenga. Por supuesto habr que modificar en los scripts correspondientes al host Sensor y al host Analista la opcin de -host XXX poniendo en su lugar el nombre del equipo Supervisor, que se identifica as como el contenedor principal de la plataforma. La ejecucin de los tres scripts ejemplo en los diferentes equipos de la red da lugar a una implantacin del sistema IDSAI como muestra la siguiente figura:
323
Contenedor(es)X (Host Sensor)

sensorx interpreteattempted-reconx interpreteunknown-classx interpreteattempted-adminx interpreteattempted-dosx interpretebad-unknownx interprete-otrosx
RED Contenedor1 (Host Analista)

analistaattempted-recon analistaunknown-class analistaattempted-admin analistaattempted-dos analistabad-unknown analista-otros
Contenedor Principal (Host Supervisor)

supervisor reloj
Fig. 55: Implantacin ejemplo del sistema IDSAI.
En la imagen se representa, como Contenedor(es)X, cada uno de los equipos Sensores de la red, donde se arrancarn las instancias de Snort y de los agentes Sensor e Intrpretes. El arranque de estos agentes es producto de la ejecucin del script IDSAISensor.bat. El host en el que se ubica el Contenedor1 es en el que se arranca el conjunto de agentes Analistas de la arquitectura y debe estar disponible para que el administrador de red pueda investigar a fondo las causas de las
324
anomalas de la red utilizando sus interfaces grficas. El equipo que aloja el Contenedor Principal es donde se ubican los agentes Reloj y Supervisor. La interfaz que proporciona este ltimo ser de gran ayuda para el administrador de red a la hora de tener conocimiento del estado de la red en todo momento.
325
8.3. EXPLOTACIN DEL SISTEMA

Una vez arrancados los agentes de la plataforma, los resultados sobre la situacin de la red no tardarn en aparecer en la interfaz grfica del agente Supervisor. Los informes en tiempo real del estado de la seguridad del sistema deben servir al administrador de red para tomar decisiones rpidas y precisas en una situacin de crisis, ya que en ellos se identifica inequvocamente a la vctima y/o al atacante junto al tipo de actividad presente que se debe intervenir e investigar. Este es el verdadero trabajo del hombre detrs del sistema IDSAI. Como cualquier otro Sistema de Deteccin de Intrusos, IDSAI se limita a informar del estado de la red al administrador de la misma para que ste tome las decisiones ms apropiadas, si bien el carcter distribuido de este sistema permite la integracin inteligente y especializada de la informacin proporcionada por mltiples sensores en vez de uno slo. Adems la interfaz de los agentes de la plataforma IDSAI permite la investigacin en detalle de las causas de una situacin anmala llegando a nivel de alertas, que clasificadas por tipos de patrn de ataque dan una visin ms veraz de la situacin sin prdida de informacin. Los siguientes apartados servirn para explicar al usuario la forma de acceder a toda la informacin que proporcionan los agentes mediante la navegacin por sus diferentes ventanas.
326
8.3.1. INTERFAZ DEL AGENTE SUPERVISOR

El agente Supervisor (ver apartado 4.2.17: Agente Supervisor) es el encargado de proporcionar al usuario la visin ms general de la situacin de la red, mostrando en cada ventana temporal la informacin que devuelve en la estructura Diagnstico (ver apartado 4.1.2.8: Diagnstico). Por ser el agente de ms alto nivel (ms cercano al usuario), proporciona la interfaz grfica ms completa de los agentes IDSAI y ser el lugar de partida para el descubrimiento de situaciones anmalas de la red por parte del administrador del sistema. La siguiente imagen representa la interfaz principal del agente Supervisor en un momento de la ejecucin:
327
1 3
5 6
Fig. 56: Interfaz del agente Supervisor.
La interfaz grfica del agente Supervisor consiste en una ventana en la que destacan los siguientes elementos: 1. Nombre unvoco del agente. Fundamental para su identificacin en el agente RMA o para el envo de mensajes ACL.
328
2. Log de registro de Diagnsticos. En l se imprime, en cada ventana temporal, la informacin ms relevante y general del Diagnstico actual. Los datos listados se muestran en la siguiente estructura:
VENTANA TEMPORAL (<n ventana>) en <fecha y hora> <listado de inferencias> Estado actual: <descripcin del estado> Diagnstico comparativo: <diagnstico comparativo>
Donde: listado de inferencias: es la lista de valores borrosos de la criticidad del sistema, que indica cada uno de los Resumenes recibidos en base a los cuales se realiza el Diagnstico. Hay que recordar que un Resumen puede propagar ms de una inferencia, por tratarse de valores borrosos compatibles y con grados de pertenencia bajos. En todo caso, las inferencias se presentan coloreadas por tipo de firma en que se especializa el agente Analista que propaga el Resumen, segn el color indicado en la leyenda del diagrama grfico. descripcin del estado: es el valor del atributo estado del Diagnstico actual. Le sigue el valor numrico de la criticidad final del sistema una vez se han integrado todas las
329
inferencias por el mtodo del centro de gravedad. En las dos siguientes lneas se especifican las direcciones IP del atacante y vctima principales de la ventana actual, esto es, los que mayor nmero de firmas protagonizan entre las acusaciones correspondientes a la ventana actual. Toda esta informacin se representa coloreada segn sea el valor borroso de la criticidad de la situacin: ALTArojo, MEDIAnaranja, BAJAverde. La descripcin del estado es la informacin ms importante que se muestra en cada ventana temporal y a la que el administrador del sistema deber dedicar mayor atencin para prever situaciones de alta criticidad y ser capaz de reaccionar rpida y eficazmente. diagnostico comparativo: es el resultado de comparar el estado actual del sistema y el indicado en el Diagnstico anterior. Se indica el cambio de situacin y de atacante y vctima principales, si procede. 3. Lienzo grfico de representacin de la situacin. Sobre un crculo negro se puede ver, en cada ventana temporal, el conjunto de hosts implicados en las anomalas detectadas en el sistema. Las lneas que unen las diferentes direcciones IP, representan: el tipo de firma correspondiente con los colores indicados en la leyenda de la parte superior izquierda, el sentido del ataque con la parte de la vctima destacada con un cuadrado de mayor grosor y la cantidad de firmas diferentes de dicho tipo detectadas entre el atacante y la vctima con el grosor de la lnea. En la parte inferior izquierda se muestra en fuente roja la lista de las 5 direcciones IP que se han declarado atacante principal desde el arranque del agente. De la misma forma, en la parte inferior derecha se muestra en fuente azul la lista de las 5 direcciones
330
IP que se han declarado vctima principal desde el arranque del agente. La informacin que se proporciona de forma grfica es fcil de interpretar y se corresponde fielmente con la descripcin del estado explicada anteriormente. 4. Tabla de ltimos Diagnsticos. En ella se listan los Diagnsticos realizados en las ltimas 20 ventanas indicando explcitamente la ventana y la fecha en la que se hicieron. Los Diagnsticos anteriores se pueden referenciar en el fichero diagnosticos.txt del directorio log en la carpeta de proyecto donde se haya instalado el aplicativo. Para acceder a los detalles de cada Diagnstico en particular, el usuario debe hacer clic sobre su registro, tras lo que se abre la siguiente ventana:
4.1 4.3 4.2
4.4
Fig. 57: Detalles de Diagnstico.
331
Los detalles del Diagnstico se muestran en la interfaz anterior, en la que destacan los siguientes elementos: 1.1. Identificador del detalle. Incluye una referencia a la ventana y la fecha y hora del momento en que se registra el Diagnstico. 1.2. Lista de atacantes y vctimas. Enumeracin de las direcciones IP de los hosts atacantes y vctimas presentes en la situacin de la red. Cada valor va acompaado de la proporcin de patrones detectados que protagonizan desde su posicin. 1.3. Lienzo grfico de representacin del Diagnstico. Se trata de un panel grfico idntico al que apareci en la interfaz principal del agente Supervisor cuando se registr el Diagnstico que se est referenciando. No se incluyen las listas de top 5 ataques y vctimas por carecer de inters en una situacin pasada. 1.4. Tabla de Acusaciones del Diagnstico. En ella se listan las Acusaciones (ver apartado 4.1.2.6: Acusacin) de las Anomalas detectadas en la ventana temporal del
Diagnstico en cuestin. Cada casilla de la tabla muestra el nmero de firmas diferentes detectadas en la ventana temporal en las que la direccin IP correspondiente a la cabecera de la fila es el atacante y la correspondiente a la cabecera de la columna es la vctima. Para acceder a los detalles de cada Acusacin en particular el usuario debe
332
hacer clic sobre su celda, tras lo que se abre la siguiente ventana:
4.4.1 4.4.2
Fig. 58: Detalles de Acusacin en Diagnstico.
Los detalles de la Acusacin en un Diagnstico se muestran enumerados en la interfaz anterior, en la que destacan los siguientes elementos: 1.4.1. Identificador del detalle. Incluye una referencia al par de hosts implicados en la Acusacin en el formato IP atacante -> IP vctima. A continuacin se
333
indica la Prioridad media de las Signatures (ver apartado 4.1.2.2: Signature) listadas a continuacin. 1.4.2. Puesto que el Diagnstico es la integracin de todos los Resmenes de los diferentes tipos de firma, los Anlisis (ver apartado 4.1.2.5: Anlisis) implicados en la Acusacin se listan organizados por su clase de Signature, acompaados del par de valores puerto atacante -> puerto vctima. 5. Tabla de Resmenes recibidos. En ella se listan los Resmenes recibidos en las ltimas 20 ventanas temporales indicando explcitamente la ventana y la fecha en la que se hicieron, la especialidad del mismo, la prioridad y compactacin de las alertas que representa y la fiabilidad de su fuente de datos. Los Resmenes anteriores a las ltimas 20 ventanas temporales se pueden referenciar en el fichero resumenes.txt del directorio log en la carpeta de proyecto donde se haya instalado el aplicativo. Para acceder a los detalles de cada Resumen en particular, el usuario debe hacer clic sobre su registro, tras lo que se abre la siguiente ventana:
334
5.1 5.2
5.3
Fig. 59: Detalles de Resumen.
Los detalles del Resumen se muestran en la interfaz anterior, en la que destacan los siguientes elementos: 5.1. Identificador del detalle. Se especifica la clase de Signature en la que est especializado el Resumen. 5.2. Listado de Anlisis (ver apartado 4.1.2.5: Anlisis). Listado de informacin estadstica sobre los anlisis relacionados con el Resumen en cuestin. De cada Anlisis se indica su
335
signature y los valores del presunto atacante (atributo iporigmaxratio), ipdestmaxratio), portorigmaxratio), portdestmaxratio), de del y del la presunta puerto puerto ellos vctima origen destino (atributo (atributo (atributo de su
todos
acompaados
proporcin respecto al total en el conjunto de Eventos (ver apartado 4.1.2.1: Evento), de su Anomala (ver apartado 4.1.2.4: Anomala) asociada. 5.3. Tabla de Acusaciones del Resumen. En ella se listan las Acusaciones (ver apartado 4.1.2.6: Acusacin) de las Anomalas cuyos Anlisis conforman el Resumen en cuestin. Cada casilla de la tabla muestra el nmero de signatures de la misma clase que se dan entre los Anlisis que componen el Resumen, en los que la direccin IP correspondiente a la cabecera de la fila es el atacante y la correspondiente a la cabecera de la columna es la vctima. Para acceder a los detalles de cada Acusacin en particular el usuario debe hacer clic sobre su celda, tras lo que se abre la siguiente ventana:
5.3.1 5.3.2
Fig. 60: Detalles de Acusacin en Resumen.
336
Los detalles de la Acusacin en un Resumen se muestran enumerados en la interfaz anterior, en la que destacan los siguientes elementos: 5.3.1. Identificador del detalle. Incluye una referencia a la clase del Resumen y al par de hosts implicados en la Acusacin en el formato IP atacante -> IP vctima. A continuacin se indica la Prioridad media de las Signatures (ver apartado 4.1.2.2: Signature)
listadas a continuacin. 5.3.2. Los Anlisis (ver apartado 4.1.2.5: Anlisis) que componen el Resumen, implicados en la Acusacin se listan organizados por su clase de Signature, acompaados del par de valores puerto atacante -> puerto vctima. 6. Botones de control del agente. Permiten llevar a cabo determinadas acciones sobre la interfaz y el agente Supervisor: Botn Limpiar Log: Al pulsarlo, el usuario deja el Log de registro de Diagnsticos de la interfaz grfica del agente Supervisor en blanco. El Log del programa en general es de tamao ilimitado, por lo que tras una ejecucin continua y prolongada es cmodo limpiarlo para eliminar del mismo la notificacin de Diagnsticos obsoletos. Botn Matar agente: Al pulsarlo, el agente Supervisor ejecuta su mtodo takedown(), y muere. No obstante la interfaz del mismo queda abierta y sus botones de control desactivados. Tambin se puede matar el agente cerrando la ventana de su interfaz grfica
337
pulsando en el aspa de la esquina superior derecha de la ventana. Al terminar la ejecucin de cualquiera de estas maneras, el nico agente que es notificado de su muerte es el agente Reloj del sistema, quien dejar de enviarle mensajes de sincronizacin. No es as para el resto de agentes de la plataforma, que seguirn envindole mensajes aunque el destinatario ya no exista.
Las imgenes correspondientes a la interfaz grfica del agente Supervisor que se han mostrado en este punto, corresponden a una ejecucin real del sistema IDSAI. En la pantalla principal de la interfaz del agente (figura 56) podemos ver que los ltimos contenidos de la ventana de log se refieren a la ventana temporal 4, en la que se han recibido 5 inferencias procedentes de 4 tipos diferentes de anlisis, segn reza el cdigo de colores: attempted-recon, otros, unknown-class y bad-unknown. La desborrosificacin de ese conjunto de inferencias (entre las que predomina el valor ALTA), da lugar a una criticidad ALTA, indicada numricamente y con las letras del estado actual en rojo. Se enuncia el atacante y vctima principales (192.168.20.103 y 192.168.20.199 respectivamente) y se explica textualmente que el estado "Muchos atacantes y muchas vctimas. Pareja destacada" es el mismo que en la ventana anterior con los mismos hosts protagonistas. Toda esta informacin se completa con el esquema grfico que representa el estado de la red en cuanto a ataques, ya que muestra a grandes rasgos las acusaciones detectadas en las comunicaciones. Fijndonos en el ejemplo, podemos comprobar que el atacante principal est participando en mltiples ataques contra el host vctima principal de tipo attempted-recon, badunknown y otros. Esto hace pensar al administrador de sistemas que el atacante est en una fase de reconocimiento pero no se puede determinar realmente qu
338
est ocurriendo, por lo que habr que investigar ms a fondo. Este vistazo al grfico permite tomar medidas reactivas concretas, interviniendo contra el atacante o protegiendo a la vctima contra los tipos de ataque que se estn produciendo. El grfico en este caso es un poco confuso, ya que se estn dando otros ataques menos intensos entre otros equipos de la red, posiblemente falsos positivos, pero que conviene verificar para evitar males mayores. Si el administrador de red est interesado en lo que realmente est ocurriendo en la ventana 4 de la ejecucin, puede investigarlo en cualquier momento haciendo clic sobre el registro correspondiente a esta ventana en la tabla de Diagnsticos, tras lo que se abrir la ventana representada en la figura 57. Esta ventana muestra la informacin del Diagnstico 4 haciendo hincapi en las acusaciones en que se basa. Para ello, la interfaz facilita una tabla donde poder ver estos detalles. A la vista del grfico la situacin ms agresiva en cuanto a ataques se da entre los hosts 192.168.20.103 y 192.168.20.199, por lo que, haciendo clic en la casilla de la tabla correspondiente a esta acusacin (atacantes, vctimas), se entra en los detalles, abrindose la ventana de la figura 58. La ventana de detalles del ejemplo 192.168.20.103 192.168.20.199 muestra, clasificadas por tipo, las signatures de los ataques que el primer host ejecuta sobre el segundo, destacando las alertas de reconocimiento mediante mltiples mtodos (UDP, TCP, ping, XMAS...) adems de un ataque XMAS scan detectado por el preprocesador stream4 que corrobora la situacin de reconocimiento que est sufriendo la vctima. Cada signature va acompaada de los puertos origen y destino predominantes que se estn utilizando en cada ataque, lo que permite la adecuada adaptacin de firewalls de red y de host para evitar futuras situaciones similares. No todas las alertas destacadas son peligrosas, en este caso no lo son las de tipo bad-traffic, ya que, si se investiga la causa por la que se disparan, resulta que se trata de trfico propio del hardware
339
de red y pueden ser ignoradas. Estas alertas han disparado una ms de tipo miscactivity, que tambin puede ser ignorada, por la misma razn. Estos resultados indican que tal vez el sensor Snort no est bien configurado y se necesiten modificar las reglas de la base de conocimientos que lanzan estos eventos ya que se trata de trfico legtimo de red. El administrador de red puede desde este momento tomar acciones reactivas precisas, ya que se le ha alertado de la criticidad del sistema, de los tipos de ataques que se estn dando, de los hosts implicados y de los puertos entre los que se estn produciendo las comunicaciones maliciosas. No obstante, los clculos que han dado lugar a estos resultados han sido redondeados y simplificados tantas veces desde el nivel de alertas, que se ha podido perder informacin en el proceso. En efecto, si el administrador investiga las causas del diagnstico y entra en el Resumen unknown-class correspondiente a esa ventana temporal haciendo clic en el registro correspondiente de la tabla resmenes de la interfaz principal del agente Supervisor, ver la informacin de la figura 59. En el log de la ventana se puede ver la informacin correspondiente a la anomala "STEALTH ACTIVITY (XMAS scan) detection" donde se especifica que tanto el atacante como la vctima son los mismos en todas las alertas detectadas de este tipo, pero los puertos del ataque no. En efecto, el puerto predominante origen de ataques (37669) se ha dado en un 50% de las ocasiones, lo que significa que el atacante est realizando el reconocimiento desde al menos 2 puertos diferentes de su mquina (posiblemente para evitar la deteccin de la situacin por parte de un IDS). Ms llamativo an es el porcentaje de alertas en que se ha detectado el puerto destino de ataques predominante. El valor 0% significa que el puerto considerado como predominante se ha repetido muy pocas veces, o lo que es lo mismo, que el conjunto de ataques de reconocimiento se ha realizado hacia mltiples puertos de la vctima y por tanto estamos ante un escaneo de puertos en toda regla.
340
Los detalles de esta acusacin se pueden ver haciendo clic sobre la casilla correspondiente de la tabla (atacantes, vctimas), pero como podemos ver en la figura 60, no aporta mucha ms informacin debido al nivel de abstraccin del agente Supervisor. En la actual distribucin del sistema IDSAI, el agente Supervisor rechaza los Resmenes cuyas Anomalas de origen han sido detectadas por Intrpretes poco fiables, por lo que no aparecern en la tabla de Resmenes recibidos y no podrn ser consultados de esta manera. No obstante estas Anomalas y Anlisis aparecen en los registros de los agentes de menor nivel, por lo que pueden consultarse all como si nunca se hubiera construido su Resumen.
341
8.3.2. INTERFAZ DEL AGENTE ANALISTA

Los agentes Analistas (ver apartado 4.2.10: Agente Analista, y siguientes) son los encargados de realizar un anlisis especializado de las Anomalas (ver apartado 4.1.2.4: Anomala) recibidas por parte de los agentes Intrpretes de su mismo tipo. Almacenan informacin sobre dichas Anomalas (estado de la red a nivel de alertas), y sus Anlisis estadsticos correspondientes (ver apartado 4.1.2.5: Anlisis) que resultan muy interesantes para inspeccionar las causas de un Diagnstico en detalle. La siguiente imagen representa la interfaz principal de un agente Analista en un momento de la ejecucin:
1 2
4 5
342
Fig. 61: Interfaz del agente Analista. La interfaz grfica del agente Analista consiste en una ventana en la que destacan los siguientes elementos 1. Nombre unvoco del agente. Fundamental para su identificacin en el agente RMA o para el envo de mensajes ACL. 2. Log del agente. En l se indican los eventos relativos a nuevas ventanas temporales, envo de Resmenes, etc. 3. Tabla de ltimos Anlisis. En ella se listan los Anlisis realizados en las ltimas 20 ventanas indicando explcitamente la ventana y la fecha en la que se hicieron, la firma de la Anomala correspondiente, y la prioridad en forma numrica. Los Anlisis anteriores se pueden referenciar en el fichero analisis.txt del directorio log en la carpeta de proyecto donde se haya instalado el aplicativo. Para acceder a los detalles de cada Anlisis en particular, el usuario debe hacer clic sobre su registro, tras lo que se abre la siguiente ventana:
3.1 3.2
Fig. 62: Detalles de Anlisis.
343
Los detalles del Anlisis se muestran en la interfaz anterior, en la que destacan los siguientes elementos: 3.1 Identificador del detalle. Hace referencia a la firma de la Anomala correspondiente al Anlisis. 3.2 Listado de la informacin de la estructura Anlisis.
4. Tabla de Anomalas recibidas. En ella se listan las Anomalas recibidas en las ltimas 20 ventanas indicando explcitamente la ventana y la fecha en la que se hicieron, la firma correspondiente, y el nmero de Eventos (ver apartado 4.1.2.1: Evento) registrados. Las Anomalas anteriores se pueden referenciar en el fichero anomalias.txt del directorio log en la carpeta de proyecto donde se haya instalado el aplicativo. Para acceder a los detalles de cada Anomala en particular, el usuario debe hacer clic sobre su registro, tras lo que se abre la siguiente ventana:
344
4.1
4.2
4.3 4.4
Fig. 63: Detalles de Anomala.
Los detalles de la Anomala se muestran en la interfaz anterior, en la que destacan los siguientes elementos: 4.1 Identificador del detalle. Hace referencia a la firma de la Anomala correspondiente. 4.2 Listado de Eventos. Listado de los Eventos detectados en la ventana actual, indicndose para cada uno de ellos su identificador CID, la fecha y hora en que fue registrado, la
345
direccin IP origen con puerto y la direccin destino con puerto. 4.3 Resumen de Eventos. Tres lneas de texto que indican el nmero de Eventos totales anteriormente enumerados, el tiempo transcurrido entre el primer Evento detectado y el ltimo en la ventana actual y el nmero de Ataques (ver apartado 4.1.2.3: Ataque) en que se agrupan los Eventos. 4.4 Listado de Ataques: Enumeracin de los Ataques
detectados, junto con su informacin caracterstica: nmero de Eventos, intervalo eventual, intervalo temporal,
compactacin eventual, atacante y vctima principales, puerto origen y destino predominantes y proporcin respecto al total de estos ltimos valores. 5. Botones de control del agente. Permiten llevar a cabo determinadas acciones sobre la interfaz y el agente Analista: Botn Limpiar Log: Al pulsarlo, el usuario deja el Log de registro de la interfaz grfica del agente Analista en blanco. El Log del programa en general es de tamao ilimitado, por lo que tras una ejecucin continua y prolongada es cmodo limpiarlo para eliminar del mismo notificaciones obsoletas. Botn Matar agente: Al pulsarlo, el agente Analista ejecuta su mtodo takedown(), y muere. No obstante la interfaz del mismo queda abierta y sus botones de control desactivados. Tambin se puede matar el agente cerrando la ventana de su interfaz grfica pulsando en el aspa de la esquina superior derecha de la ventana. Al terminar la ejecucin de cualquiera de estas maneras, el nico
346
agente que es notificado de su muerte es el agente Reloj del sistema, quien dejar de enviarle mensajes de sincronizacin. No es as para el resto de agentes de la plataforma, que seguirn envindole mensajes aunque el destinatario ya no exista.
La investigacin de anomalas al nivel de agentes Analistas slo se debe llevar a cabo cuando el usuario quiere verificar la verdadera naturaleza de los ataques, ya que en general, no ser necesario profundizar tanto para tomar decisiones reactivas rpidas. En el caso ejemplo de donde se han tomado las imgenes en este captulo, el administrador de red se interesa por el escaneo de puertos detectado por la signature XMAS scan, por lo que acude al agente Analista especialista en el tipo de ataques unknown-class que envi al agente Supervisor el Resumen donde se notificaba de este tipo de anomala. La interfaz del agente Analista unknown-class (figura 61) corrobora en su log, que el resumen de la ventana 4 fue enviado al agente Supervisor en su momento y dispone de un par de tablas cuyo contenido es de gran inters para comprobar los orgenes de los clculos que dan lugar al valor de la criticidad del sistema. Haciendo clic sobre el registro de la tabla de anlisis correspondiente al Anlisis "STEALTH ACTIVITY (XMAS scan)" de la ventana 4, se abren los detalles de ste Anlisis, que junto con otros de su mismo tipo, dieron lugar al Resumen en el que nos interesamos en el apartado anterior. En la figura 62 podemos ver estos detalles, que nos indican, aparte de la informacin a nivel de acusaciones como vimos en los detalles del Resumen, que la prioridad media de las alertas de este tipo es 1 y la compactacin de los ataques 5 (ambos valores relativamente altos segn la escala definida en los controladores borrosos del anexo 1: Conjuntos borrosos IDSAI). Tambin se puede ver informacin
347
estadstica sobre los ataques: 787 alertas detectadas por ataque y una media de 10 segundos cada ataque. El hecho de que las desviaciones respecto a la media de estos valores sean nulas, hace suponer que slo se ha detectado un ataque de esta firma, no obstante con un alto nmero de alertas disparadas. La informacin de los Anlisis debe ser lo suficientemente escueta como para formar los Resmenes, por lo que conviene que sea complementada con la informacin que aporta la estructura Anomala asociada a cada uno de estos Anlisis. En nuestro caso el administrador del sistema debe consultar los detalles de la anomala "STEALTH ACTIVITY (XMAS scan)" haciendo clic sobre la entrada de la tabla correspondiente de la ventana 4. La figura 63 muestra estos datos, empezando por la lista de alertas detectadas y terminando por el anlisis a nivel de ataques. La lista de eventos es incmoda de ver pero resulta indispensable en un anlisis en detalle, por ejemplo para comprobar uno a uno los puertos escaneados. Respecto a los ataques, en este caso se observa que las alertas de este tipo de escaneo detectadas en la ventana 4 se corresponden con un nico Ataque de una duracin de 10 segundos en el que la compactacin eventual es nula, lo que confirma el hecho de que se estn detectando muchos otros ataques simultneamente como se poda ver en el grfico de la interfaz del Supervisor.
348
8.3.3. INTERFAZ DEL AGENTE INTRPRETE

Los agentes Intrpretes (ver apartado 4.2.3: Agente Intrprete, y siguientes) son los encargados de recoger la informacin depositada por el sensor Snort en la base de datos snortdb de forma especializada, generando las Anomalas (ver apartado 4.1.2.4: Anomala) que enviarn a su agente Analista asociado para que ste las procese. Los agentes Intrpretes no almacenan informacin de ningn tipo, ya que el nivel de los datos que maneja es el ms bajo: alertas registradas en la base de datos. Esta informacin estar siempre disponible para ser consultada de forma manual desde las tablas de la base de datos aunque de una forma ms incmoda para el usuario. La siguiente imagen representa la interfaz principal de un agente Intrprete en un momento de la ejecucin:
1 2
3
Fig. 64: Interfaz del agente Intrprete.
La interfaz grfica del agente Intrprete consiste en una ventana en la que destacan los siguientes elementos:
349
1. Nombre unvoco del agente. Fundamental para su identificacin en el agente RMA o para el envo de mensajes ACL. 2. Log del agente. En l se indican los eventos relativos a nuevas ventanas temporales, envo de Anomalas, etc. 3. Botones de control del agente. Permiten llevar a cabo determinadas acciones sobre la interfaz y el agente Intrprete: Botn Limpiar Log: Al pulsarlo, el usuario deja el Log de registro de la interfaz grfica del agente Intrprete en blanco. El Log del programa en general es de tamao ilimitado, por lo que tras una ejecucin continua y prolongada es cmodo limpiarlo para eliminar del mismo notificaciones obsoletas. Botn Matar agente: Al pulsarlo, el agente Intrprete ejecuta su mtodo takedown(), y muere. No obstante la interfaz del mismo queda abierta y sus botones de control desactivados. Tambin se puede matar el agente cerrando la ventana de su interfaz grfica pulsando en el aspa de la esquina superior derecha de la ventana. Al terminar la ejecucin de cualquiera de estas maneras, el nico agente que es notificado de su muerte es el agente Reloj del sistema, quien dejar de enviarle mensajes de sincronizacin. Los dems agentes de la plataforma no se percatan de su ausencia, ni tienen por qu hacerlo.
La interfaz del agente Intrprete no sirve para investigar la situacin de la red, ya que sus resultados (las estructuras Anomala) ya se muestran en la interfaz del agente Analista que s que almacena el histrico. Resulta
350
tranquilizador echarle un vistazo a su log de vez en cuando para comprobar que est funcionando correctamente.
351
8.3.4. INTERFAZ DEL AGENTE RELOJ

El agente Reloj (ver apartado 4.2.1: Agente Reloj) es el encargado de la sincronizacin de los agentes del sistema IDSAI. Conoce en todo momento los identificadores de los agentes vivos en la plataforma y por eso es interesante que en su interfaz grfica se pueda ver el listado completo. La siguiente imagen representa la interfaz principal de el agente Reloj en un momento de la ejecucin:
1 2 1 3
Fig. 65: Interfaz del agente Reloj.
La interfaz grfica del agente Reloj consiste en una ventana en la que destacan los siguientes elementos: 1. Contador de la ventana actual. Indicador numrico que muestra el valor de la ventana temporal en cada momento. Este valor es propagado a los diferentes agentes del sistema mediante mensajes ACL para su sincronizacin. 2. Tabla de agentes vivos. En ella se listan los identificadores de los agentes vivos en la plataforma en el momento actual. Tiene mero
352
valor informativo, pero sirve para estar seguro de que los diferentes agentes estn corriendo en sus respectivos lugares, de forma centralizada. 3. Botones de control del agente. Permiten llevar a cabo determinadas acciones sobre el agente Reloj. Los dos botones conmutan entre s, esto es que cuando uno de ellos est habilitado el otro no lo est y viceversa, ya que ejecutan acciones opuestas: Botn Detener: Al pulsarlo, el usuario suspende la ejecucin de los comportamientos activos del agente. De esta manera se consigue detener la ejecucin de los agentes sincronizados, ya que no les llegar la notificacin de una nueva ventana mientras el Reloj est en este estado. Se debe tener en cuenta que la ejecucin del sensor Snort no se detiene nunca y por tanto, mientras los agentes del sistema IDSAI se encuentren a la espera del Reloj, perdern posibles alertas que se disparen en ese tiempo. Por otra parte, en este estado, al agente Reloj no le constar la entrada de nuevos agentes a la plataforma, por lo que se debe tener en cuenta que cuando se recupere la ejecucin del Reloj, estos agentes no dados de alta, no sern sincronizados. Pese a todo esto, en una situacin de verdadera crisis donde sea verdaderamente necesario hacer una inspeccin detallada de las causas de un diagnstico crtico, detener los agentes puede resultar interesante con el fin de facilitar la labor de anlisis y toma de decisiones por parte del humano tras la mquina. Botn Arrancar: Al pulsarlo, el usuario activa la ejecucin de los comportamientos suspendidos del agente. De esta manera se
353
consigue el rearranque del proceso de sincronizacin y de espera del alta de nuevos agentes en la plataforma.
La interfaz del agente Reloj no sirve para investigar la situacin de la red. Simplemente muestra los agentes vivos en el momento actual y resulta til para comprobar su estado.
354
9. PLANIFICACIN Y PRESUPUESTO DEL PROYECTO

En el presente captulo se hace referencia a la planificacin del proyecto: las etapas de su desarrollo y diferentes actividades llevadas a cabo en cada una de las mismas por los miembros de su organizacin.
9.1.
ORGANIZACIN DEL PROYECTO

El proyecto IDSAI es un Proyecto Fin de Carrera de carcter individual, por
lo que el equipo de trabajo est formado exclusivamente por una nica persona, autor del presente documento. De esta manera, la investigacin en temas de seguridad informtica, ataques a redes de computadores, Sistemas de Deteccin de Intrusos y la arquitectura de agentes inteligentes JADE, ha sido realizada por la misma persona encargada del diseo, programacin y documentacin del aplicativo. El siguiente diagrama muestra la estructura organizativa del proyecto indicndose las responsabilidades de cada uno de las personas que la integran: COORDINADOR Miguel ngel Sanz Bobi
DIRECTORES Miguel ngel Sanz Bobi (Director 1) Mario Castro Ponce (Director 2)
EQUIPO DE TRABAJO Javier Santos Ferreras
Fig. 66: Organizacin del proyecto.
355
Donde las tareas y responsabilidades principales de cada uno de los grupos que forman la organizacin del proyecto a lo largo de la realizacin del mismo se presentan a continuacin: o Coordinador: Explicar la Normativa de Proyectos Fin de carrera y facilitar la informacin pertinente a lo largo de su desarrollo. Concretar la definicin del proyecto y los objetivos. Controlar y supervisar el trabajo en sesiones de presentacin pblica de los avances realizados. Evaluar el producto final. Calificar al alumno en calidad de profesor de la asignatura Proyecto Fin de Carrera. o Directores: Proponer un proyecto de calidad y establecer las lneas y los criterios de verificacin de los resultados de forma prctica. Facilitar al alumno las orientaciones adecuadas ante los problemas que vayan surgiendo en el desarrollo del proyecto. Supervisar la realizacin del proyecto, la calidad de sus contenidos, y que se desarrolla de acuerdo con la Normativa de Proyectos Fin de carrera. Dar su opinin al Coordinador sobre el alumno y el trabajo realizado.
356
o Equipo de trabajo: Asistir a las sesiones de control del proyecto tanto a las propuestas por los Directores del proyecto como las programadas por el Coordinador. Determinar el alcance del proyecto y la planificacin del mismo, que deben ser validadas por los Directores del proyecto. Realizar la adquisicin de informacin para la realizacin del proyecto. Esto incluye tanto la investigacin y formacin autnoma sobre los temas que trata el proyecto, como la obtencin del conocimiento necesario para llevar a cabo los objetivos del mismo. Realizar el diseo del aplicativo. Esto implica la eleccin, diseo y documentacin de la arquitectura a montar. Realizar la programacin del software. Esto implica la codificacin del diseo sobre el lenguaje elegido y las pruebas pertinentes. Llevar a cabo la documentacin y presentacin del producto y de cada uno de los prototipos a los Directores y Coordinador del proyecto.
357
9.2.
METODOLOGA Y RECURSOS
El alcance del proyecto impone como software base sobre el que desarrollar
el aplicativo, el IDS Snort. Del mismo modo, se propone como solucin para la arquitectura distribuida sobre la que desplegar el sistema, la tecnologa 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 metodologa lineal, ya que a medida que se avanza en l se irn descubriendo nuevas funcionalidades y surgiendo nuevas ideas a incorporar al resultado. Por estas razones, el proyecto se realizar mediante una metodologa espiral, segn la cual, se publicarn peridicamente versiones del producto IDSAI, que tras ser valoradas por los Directores del proyecto, pasarn por nuevas etapas de desarrollo donde se les incorporarn funcionalidades ms avanzadas. En el apartado 9.3: Planificacin de tareas, se representar la metodologa del proyecto junto con las actividades a realizar en cada etapa.
El objetivo del proyecto, que impone la implantacin 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 ms 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 tecnologa. Al no presentarse especificaciones hardware concretas, se considerar la implantacin del producto en equipos PC ordinarios (CPU 1,5 GHz y Memoria 512 MB), por lo que el desarrollo se llevar a cabo tambin en mquinas de estas caractersticas. 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
358
distribucin, lo que condiciona en gran manera los recursos software de los que disponer: o Software base (para Windows): IDS Snort (Snort 2.6.1.1) SGBD MySQL (MySQL 5.0.27) Herramientas grficas MySQL (MySQL Gui Tools 5.0) Middleware JADE (JADE 3.4) Mquina Virtual Java (JVM 5.0) o Software de desarrollo (en mquina con Windows XP): Kit de Desarrollo Java (JDK 5.0) Entorno de desarrollo Java Eclipse (Eclipse SDK 3.2.1) Herramienta de diagramacin Dia (Dia 0.95-1) Herramienta de documentacin MS Word (MS Word 2002) o Software de pruebas (para Windows) Herramienta para auditorias de seguridad Nessus (Nessus 3.0) Herramienta para escaneos de puertos Nmap (Nmap 4.20) Los recursos hardware que se requieren para la realizacin del proyecto son los siguientes: o Hardware de desarrollo y pruebas:
359
PC sobremesa necesario para la distribucin del sistema IDSAI en varias mquinas (AMD Athlon 64 2.5 GHz, 768 MB RAM). Incluye Windows XP. PC porttil para desarrollo y pruebas (Pentium Centrino 1.7 GHz, 1 GB RAM). Incluye Windows XP. Hub y cableado de red para pruebas.
360
9.3.
PLANIFICACIN DE TAREAS
En este apartado se presenta la planificacin de las fases en que se divide el
desarrollo del sistema IDSAI. Debido a la metodologa en espiral en que se ha llevado a cabo el proyecto, cada una de las etapas del desarrollo consiste en la realizacin y presentacin de un prototipo del producto final, que es la acumulacin del resultado de los anteriores, al que se han incorporado las funcionalidades planificadas para dicha fase. El proyecto IDSAI dio comienzo en Octubre de 2006 y termina en Septiembre de 2007. Tras la revisin de la planificacin inicial de tareas, en la que se prevea el final del proyecto para Junio de 2007 y que mostraba una ejecucin lineal de actividades que result inviable en las fases de la programacin, se opta por la metodologa en espiral y posponer el final del proyecto. El siguiente esquema muestra las actividades de adquisicin de conocimiento planificadas en un principio (A1, A2, A3, A9 y A10) y las etapas iterativas de realizacin de prototipos (A4, A5, A6, A7, A8) cuyos contenidos se fueron planificando al comienzo de cada una respecto a los avances e ideas surgidas en la anterior: A1. Estudio de principios de seguridad en redes de computadores. A2.1. A2.2. Seguridad perimetral. Ataques a redes de computadores.
A2. Estudio de Sistemas de Deteccin de Intrusos. A2.3. A2.4. Principios de la deteccin de intrusos Sistemas de Deteccin de Intrusos: Clasificacin,
funcionamiento y estado del arte.
361
A2.5.
Snort. Configuracin e implantacin. Instalacin y configuracin de una instancia de la base de datos MySQL snortdb. Uso de herramientas de ataque de red para verificar su funcionamiento en un entorno de pruebas.
A3. Estudio de la arquitectura JADE multiagente. A3.1. A3.2. Estudio de la arquitectura de agentes inteligentes JADE. Diseo de aplicacin de prueba de comunicacin entre agentes. A4. Primer prototipo: Sistema local de clasificacin de alertas. A4.1. Primer diseo de agente Intrprete: Construccin de un agente JADE cuya mera funcionalidad es el acceso peridico a la base de datos snortdb para obtener alertas de un determinado tipo. Diseo de funciones de la capa de persistencia. Introduccin del concepto Anomala, que se plasma en una estructura de datos que se enva al agente Analista. A4.2. Primer diseo de agente Analista: Construccin de un agente JADE cuya nica funcionalidad es la presentacin por consola de los datos que el agente Intrprete le enva en forma de estructura Anomala. A4.3. Primer y definitivo diseo de agente Sensor: Construccin de un agente JADE cuyas funcionalidades son el arranque del sensor Snort y el mantenimiento de sus datos actualizados en la base de datos snortdb. (Esta ltima funcionalidad es desechada en fases posteriores del
362
desarrollo por cuestiones de rendimiento). Aunque el cdigo del agente Sensor se pueda retocar en posteriores fases del desarrollo del proyecto, sta ser su
funcionalidad definitiva. A4.4. Presentacin del prototipo (a Directores).
A5. Segundo prototipo: Sistema distribuido de anlisis de alertas. A5.1. Revisin definitiva del agente Intrprete: Especializacin de agentes Intrpretes por tipo de signature. Diseo del anlisis de anomalas a nivel de ataques e introduccin de los conceptos prioridad y compactacin eventual. Envo de mltiples Anomalas al agente Analista de su misma especialidad. Diseo de una interfaz grfica simple para los agentes Intrpretes. Aunque el cdigo del agente Intrprete se pueda retocar en posteriores fases del desarrollo del proyecto, sta ser su funcionalidad definitiva. A5.2. Revisin del agente Analista: Especializacin de agentes Analistas por tipo de signature. Introduccin del concepto anlisis asociado a cada tipo de Anomala y su representacin en la estructura de datos Anlisis. que se enva al agente Supervisor. Diseo de una interfaz grfica que muestre la informacin recibida del agente Intrprete asociado. A5.3. Primer diseo del agente Supervisor: Construccin de un agente JADE cuya nica funcionalidad es la presentacin
363
por una interfaz grfica de los datos que el agente Analista le enva en forma de estructura Anlisis. A5.4. Presentacin del prototipo (a Directores).
A6. Tercer prototipo: Sistema distribuido de diagnstico de la situacin. A6.1. Primer y definitivo diseo del agente Reloj: Construccin de un agente JADE cuyas funcionalidades son la recepcin de mensajes de alta y baja en la red por parte de los dems agentes de la plataforma para tener conocimiento de los agentes vivos en todo momento y la sincronizacin de los mismos marcando el periodo de captura-anlisis-
diagnstico. Diseo de una interfaz grfica que muestre los agentes vivos en la plataforma en tiempo real. La creacin de este agente requiere retocar los dems agentes hasta el momento. Aunque el cdigo del agente Reloj se pueda retocar en posteriores fases del desarrollo del proyecto, sta ser su funcionalidad definitiva. A6.2. Segunda revisin del agente Analista: Especializacin del anlisis de la prioridad y la compactacin de las anomalas por tipo de signature. Introduccin del concepto acusacin como forma de reducir la cantidad de informacin de bajo nivel a enviar al Supervisor. Introduccin del concepto resumen de anlisis, que se plasma en la estructura de datos Resumen que se enva al agente Supervisor. A6.3. Revisin del agente Supervisor: Introduccin del concepto diagnstico de la situacin que consiste en el tratamiento estadstico de la informacin de los Resmenes recibidos
364
para integrar los conceptos de prioridad y compactacin en uno slo: criticidad. Mejora de la interfaz de forma que adems de la informacin bsica de la estructura Diagnstico, muestre en un diagrama grfico las acusaciones recibidas en todos los Resmenes en tiempo real. A6.4. Presentacin del prototipo (a Directores).
A7. Cuarto y definitivo prototipo: Sistema distribuido inteligente de anlisis del estado de la situacin. A7.1. Revisin definitiva del agente Analista: Introduccin de procedimientos de borrosificacin para enviar los valores de prioridad y compactacin en el Resumen al agente Supervisor. Mejora de la interfaz grfica para que muestre, de forma tabulada y consultable, informacin histrica sobre la informacin con la que trabaja (Anomalas y Anlisis). Aunque el cdigo del agente Analista se pueda retocar en posteriores fases del desarrollo del proyecto, sta ser su funcionalidad definitiva. A7.2. Revisin definitiva del agente Supervisor: Introduccin de procedimientos de desborrosificacin para convertir los valores de prioridad y compactacin recibidos en cada Resumen en un nico valor de criticidad del sistema. Introduccin de base de reglas para definir el estado del sistema. Mejora de la interfaz grfica para mostrar la informacin histrica completa de Diagnsticos y
Resmenes recibidos, de forma tabulada y consultable, con ventanas de detalle avanzadas. Aunque el cdigo del
365
agente Supervisor se pueda retocar en posteriores fases del desarrollo del proyecto, sta ser su funcionalidad definitiva. A7.3. Presentacin del prototipo (a Directores).
A8. Implantacin del sistema distribuido IDSAI: Etapa reservada para el retoque de las funcionalidades del sistema de cara a la presentacin del sistema completo a los directores del proyecto. Presentacin de la versin definitiva del sistema IDSAI (a Directores). A9. Documentacin del proyecto. A10. Presentacin final del proyecto (a Coordinador). La ubicacin temporal de las actividades enumeradas anteriormente, no es estricta en el periodo de desarrollo del proyecto, por lo que la realizacin de stas se planifica aproximadamente segn el siguiente diagrama.
366
A1 A2 A3 A4 A5 A6 A7 A8 A9
SE A10 OCT NOV DIC ENE FEB MAR ABR MAY JUN JUL AGO SEP
2006
2007
Exmenes Exmenes
Fig. 67: Planificacin de tareas.
367
9.4.
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 distribucin, el coste del proyecto IDSAI es nulo en ese aspecto. No obstante en las fases de desarrollo e implantacin de entornos de pruebas del sistema IDSAI hay que tener en cuenta los siguientes gastos: Gastos fijos: Hardware de desarrollo y pruebas. o PC sobremesa necesario para la distribucin del sistema IDSAI en varias mquinas (AMD Athlon 64 2.5 GHz, 768 MB RAM). Incluye Windows XP: 1000 . o PC porttil para desarrollo y pruebas (Pentium Centrino 1.7 GHz, 1 GB RAM): 1000 . o Hub y cableado de red para pruebas: 50 . Gastos variables: Mano de obra y otros costes (incluidos en cuota laboral)
368
o Estimacin de esfuerzo (tiempo en horas).

Tareas A1 Personal COORDINA DOR DIRECTOR 1 DIRECTOR 2 EQUIPO TRABAJO TOTAL ETAPA A2 A3 A4 A5 A6 A7 A8 A9 A10 TOTAL HORAS
0 0 2 20
22
0 0 2 20 22
0 2 0 20 22
1 2 2 45 50
0 2 2 85 89
1 4 4 95 104
0 4 4 65 73
0 4 4 105 113
0 2 2 60 64
2 1 1 5 9
4 21 23 520 568 h
Tabla 2: Estimacin de esfuerzo. o Estimacin del coste (en euros).

Tareas / hora Personal COORDINA DOR DIRECTOR 1 DIRECTOR 2 EQUIPO TRABAJO TOTAL ETAPA A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 TOTAL
20 15 15 8
0 0 30 160 190
0 0 30 160 190
0 30 0 160 190
20 30 30 360 400
0 30 30 680 740
20 60 60 760 900
0 60 60 520 640
0 60 60 840 960
0 30 30 480 540
40 15 15 40 110
80 315 345 4160 4900
Tabla 3: Estimacin del coste. Coste total del desarrollo del proyecto: Costes fijos: 2050 Costes variables: 4900 TOTAL PROYECTO: 6950
369
10. CONCLUSIONES
Al trmino del proyecto, en Septiembre de 2007, se han llegado a las siguientes conclusiones referentes a las diferentes cuestiones que han ido surgiendo a lo largo del mismo. Respecto a la definicin 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 diseo inicial de la aplicacin no cumpla los requisitos de calidad exigidos por los Directores del proyecto, por lo que tuvo que ser rehecho a medida que se iba codificando. Esto signific tener que desechar la planificacin lineal realizada inicialmente para dar lugar a la planificacin en espiral basada en prototipos de la que se ha hablado en apartados anteriores. Como ya se ha explicado, la planificacin del proyecto fue alterada durante su desarrollo debido al cambio de metodologa. Por otra parte las tareas de investigacin y adquisicin de conocimientos A1, A2 y A3 se alargaron en el tiempo, ya que durante todo el proyecto hubo que apoyarse en la bibliografa para seguir ampliando las funcionalidades del proyecto y adquiriendo nuevos conocimientos para implantar las ideas que iban surgiendo. El cambio a la metodologa en espiral fue realizndose involuntariamente cuando a partir de la presentacin del primer prototipo a los directores del Proyecto (actividad A4), se fueron haciendo ms frecuentes las reuniones de supervisin en las que iban surgiendo y se iban proponiendo las nuevas funcionalidades que deban ir integrando los sucesivos entregables. El desarrollo en espiral ha dado al final un producto satisfactorio y ha permitido la introduccin de particularidades del diseo en los momentos apropiados que no estaban previstas en la planificacin inicial. Como una leccin aprendida a aplicar en futuros proyectos queda el hecho de que la metodologa en espiral es verdaderamente eficaz cuando no se
370
dispone de un diseo inicial estable, aunque se deben controlar mejor las fechas de entrega de los prototipos. Respecto al tema de la documentacin, aunque los diagramas de diseo y arquitectura se iban haciendo de forma concurrente con el desarrollo, la realizacin de la memoria final ha llevado ms horas de las previstas, debido a la propia metodologa, que obligaba a rehacer constantemente las especificaciones detalladas de los componentes del prototipo anterior, ya que se alteraban al trabajar sobre ellos. El resultado del proyecto es satisfactorio y 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, quedarn pendientes para futuras versiones del producto: El arranque de los agentes de la plataforma, que se hace en forma de script de lnea de comandos, podra realizarse mediante una interfaz grfica ms cmoda. Puesto que tanto el entorno de pruebas como la red en la que se implant el sistema eran redes pequeas, el sistema de manipulacin de scripts no era muy engorroso, pero en una gran distribucin del producto, sta no es la forma ms adecuada de hacerlo. Se sugiere una interfaz que permita ubicar las mquinas que alojan los agentes en el espacio y que permita gestionarlos de forma remota. Por la misma razn, en una gran distribucin de la aplicacin resultara interesante que los agentes Intrpretes propagaran su posicin en la red, de forma que esto permitiera hacer diagnsticos ms especializados y se tuviera en cuenta para la toma de decisiones. Se sugiere que la criticidad del sistema definida por el agente Supervisor, dependa tambin de la importancia de los segmentos de red en que se detecten los ataques y que las acusaciones se representen, adems de con las direcciones IP origen y destino, con la ubicacin fsica de las mquinas atacante y vctima.
371
La fiabilidad de los agentes Intrpretes tambin tiene que tenerse en cuenta para posteriores versiones del aplicativo. Actualmente, si el agente Supervisor recibe varios Resmenes de Anlisis del mismo tipo de firma, desecha aquellos cuyas anomalas han sido detectadas por Intrpretes de menor fiabilidad. El trabajo de esos Intrpretes rechazados no debera ser ignorado de esa manera, ya que podra aportar mayor informacin al conjunto, defendiendo o refutando un diagnstico que actualmente se est basando en una nica fuente. Se sugiere que el agente Supervisor aplique un sistema de votacin ponderada por fiabilidad entre los Resmenes del mismo tipo, para quedarse con las Anomalas ms significativas de cara a que sean las que se tengan en cuenta para el Diagnstico del estado de la red.
Una arquitectura distribuida es potencialmente insegura, ya que las comunicaciones entre agentes pueden ser intervenidas, lo que permitira a un hacker el acceso a importante informacin de negocio. El IDS distribuido IDSAI sera fcilmente inutilizable si se impidiera la llegada de mensajes de alertas detectadas a la capa de presentacin o si se manipulasen para ocultar un ataque. IDSAI utiliza comunicaciones sin cifrar y no incluye acuses de recibo en las comunicaciones entre agentes, por lo que es dbil frente a estos ataques. Afortunadamente, JADE proporciona en su API funcionalidades de seguridad que solucionaran estos problemas, pero que no se han aplicado por cuestin de tiempo.
Las bases heursticas en las que se fundamenta el anlisis de la prioridad y compactacin eventual de las anomalas que se realiza en los agentes Analistas son estticas. Si se desearan modificar habra que alterar el cdigo fuente y al crear nuevos agentes Analistas de otras especialidades habra que retocar los parmetros en tiempo de programacin. Lo mismo ocurre con los controladores borrosos que se han diseado en la clase de clculo borroso Control Borroso (ver apartado 4.6.2: Control Borroso), que estn
372
programados de forma esttica. Tambin es fija la base de reglas que infiere el estado de la red por parte del agente Supervisor. Se sugiere la carga de las bases de conocimiento heurstico en el arranque de los agentes a travs de ficheros externos que permitan su edicin sin tocar el cdigo, aunque haya que programar complejas funciones de parseo de esta informacin para integrarla a la lgica de la aplicacin. La funcionalidad de mantenimiento de la informacin actualizada en la base de datos snortdb, que inicialmente integraba el agente Sensor, no ha sido implementada en la versin definitiva del aplicativo. Esto se debe a que en la prctica, la informacin generada por el sensor Snort no es tan voluminosa como se esperaba en un principio y la limpieza de la base de datos snortdb se presenta como un proceso no crtico, por lo que puede dejarse en manos del administrador para que lo realice de forma manual. El limpiado de las bases de datos snortdb es un proceso que interfiere gravemente en el rendimiento de los agentes Intrprete que se alimentan de cada instancia por lo que el borrado de informacin obsoleta de los sensores, puede suponer la parada del sistema IDSAI, lo cual es indeseable. Se intent sin xito la configuracin del esquema snortdb para que admitiera borrados en cascada, pero no fue posible que sobre este nuevo esquema Snort insertara informacin en la base de datos sin errores. Se sugiere la detencin peridica (a nivel de das) del Reloj del sistema IDSAI para disparar el comportamiento de limpieza de las bases de datos de los sensores y evitar as el crecimiento incontrolado de informacin. Tambin se sugiere revisar y limpiar los ficheros de log del sistema para prevenir una situacin de falta de espacio en disco si se llenan con demasiada informacin.
373
11. BIBLIOGRAFA
[KOZI03]
Jack Koziol, "Intrusion Detection with Snort", Sams Publishing 2003, 1 Ed.
[NORT01]
Stephen Northcutt, Judy Novak, "Network Intrusion Detection", Sams Publishing 2001, 2 Ed.
[DIAZ05]
Luis Daz Vizcano, "Sistemas de Deteccin de Intrusos", Departamento de Ingeniera Telemtica, Universidad Carlos III de Madrid, 2005.
[ARAN06]
Gonzalo A. Aranda Corral, "Construccin de un sistema multiagente mediante JADE", Curso de Agentes Inteligentes, Universidad de Sevilla, 2006.
[CAIR03]
Giovanni Caire, "JADE Tutorial: Jade Programming for Beginners", TILAB, 2003.
[BELL05]
Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, Giovanni Rimassa, "JADE Programmer's Guide", TILAB, 2005.
[BELL06]
Fabio Bellifemine, Giovanni Caire, Tiziana Trucco, Giovanni Rimassa, Roland Mungenast, "JADE Administrator's Guide", TILAB, 2006.
[GARA04]
Juan Fco. Garamendi Bragado, "Agentes Inteligentes: JADE", Programa de Doctorado: Informtica y Modelizacin Matemtica, Universidad Rey Juan Carlos, 2004.
374
[BELL03]
F. Bellifemine, G. Caire, A. Poggi, G. Rimassa, "JADE A White Paper", TILAB, 2003. JADE Web Site, http://jade.tilab.com/ Snort Web Site, http://www.snort.org/
375
12. SIGLAS Y ACRNIMOS
ACL ARP CPU DoS FIPA FTP HIDS HTML HTTP IDS IDSAI
Agent Communication Language. Address Resolution Protocol Central Processing Unit. Denial of Service. Foundation for Intelligent Physical Agents. File Transfer Protocol. Host Intrusion Detection System. HyperText Markup Language. Hyper Text Transfer Protocol. Intrusion Detection System. (Sistema de Deteccin de Intrusos) IDS, Sistema de Deteccin de Intrusos, basado en Agentes Inteligentes.
JDK JVM ICMP IP
Java Development Kit. Java Virtual Machine. Internet Control Message Protocol. Internet Protocol.
376
JADE
Java Agents Development Environment (Entorno de Desarrollo de Agentes Java).
MAC MS NNIDS NIDS OSI P2P RPC SDK SGBD SNMP SPADE SQL SSH TCP TILAB UDP URI
Media Access Control. Microsoft. Network Node Intrusion Detection System. Network Intrusion Detection System. Open System Interconnection Peer to Peer. Remote Procedure Call. Standard Development Kit. Sistema Gestor de Bases de Datos. Simple Network Management Protocol. Statistical Packet Anomaly Detection Engine. Structured Query Language. Secure Socket Layer. Transmission Control Protocol. Telecom Italian LABoratories. User Datagram Protocol. Uniform Resource Identifier.
377
URL XSS XML
Uniform Resource Locator. Cross-Site Scripting. eXtensible Markup Language.
378
13. ANEXOS
ANEXO 1: Conjuntos borrosos IDSAI ANEXO 2: Diagrama de clases ANEXO 3: Diagrama de la arquitectura ANEXO 4: Diagrama de secuencia ANEXO 5: Esquema snortdb ANEXO 6: Signatures IDSAI (Snort)
379

Índice: Javier Santos Ferreras

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Índice: Javier Santos Ferreras

Diunggah oleh

Hak Cipta:

Format Tersedia

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

8.3.2. 8.3.3. 8.3.4. 9.

10. 11. 12. 13.

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

1. OBJETIVOS DEL PROYECTO

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

2. ALCANCE DEL PROYECTO

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

3. ESTADO DEL ARTE

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMAS DE DETECCIN DE INTRUSOS

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

3.1.1. SEGURIDAD PERIMETRAL

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

3.1.2. CLASIFICACIN DE IDS

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

3.1.3. IMPLANTACIN DE IDS

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

Red corporativa externa

Fig. 1: Ejemplo configuracin de red.

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

SISTEMA DISTRIBUIDO DE DETECCIN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras