Proyecto Fin de Carrera - IIT Comillas · 2007-09-11 · (profundizando en el escaneo de puertos) y...

SISTEMA DISTRIBUIDO DE DETECCIÓN DE INTRUSOS BASADO EN AGENTES INTELIGENTES (IDSAI)

Javier Santos Ferreras

1

ÍNDICE

ÍNDICE......................................................................................................................................... 1

1. OBJETIVOS DEL PROYECTO...................................................................................... 5

2. ALCANCE DEL PROYECTO ......................................................................................... 7

3. ESTADO DEL ARTE...................................................................................................... 10

3.1. SISTEMAS DE DETECCIÓN DE INTRUSOS....................................................... 11

3.1.1. SEGURIDAD PERIMETRAL .............................................................................. 13

3.1.2. CLASIFICACIÓN DE IDS................................................................................... 18

3.1.3. IMPLANTACIÓN DE IDS ................................................................................... 20

3.2. ATAQUES INFORMÁTICOS E INTRUSIÓN EN REDES.................................... 26

3.2.1. FASES DE UN ATAQUE..................................................................................... 26

3.2.2. ATAQUES CONOCIDOS .................................................................................... 35

3.3. MODELOS DISTRIBUIDOS .................................................................................. 49

3.3.1. MODELO CLIENTE-SERVIDOR........................................................................ 49

MODELO PEER-TO-PEER (P2P) .................................................................................... 52

3.3.2. MODELO DE AGENTES INTELIGENTES......................................................... 55

3.3.3. MIDDLEWARE ................................................................................................... 58

3.4. TECNOLOGÍA JAVA JADE................................................................................... 59

3.4.1. MODELO DE ARQUITECTURA ........................................................................ 61

3.4.2. MODELO FUNCIONAL ..................................................................................... 63

3.5. SNORT..................................................................................................................... 72

3.5.1. MODOS DE FUNCIONAMIENTO ..................................................................... 73

3.5.2. COMPONENTES DE SNORT ............................................................................. 74

4. DESCRIPCIÓN FUNCIONAL....................................................................................... 85

4.1. DOMINIO DEL SISTEMA...................................................................................... 87

4.1.1. DIAGRAMA DE DOMINIO................................................................................. 87

4.1.2. DEFINICIÓN DE CONCEPTOS......................................................................... 88

4.2. AGENTES DEL SISTEMA ................................................................................... 106

4.2.1. Agente RELOJ ................................................................................................... 107

4.2.2. Agente SENSOR................................................................................................. 109

4.2.3. Agente INTÉRPRETE ........................................................................................ 113



2

4.2.4. Agente INTÉRPRETE ATTEMPTED-ADMIN................................................... 115

4.2.5. Agente INTÉRPRETE ATTEMPTED-DOS........................................................ 117

4.2.6. Agente INTÉRPRETE ATTEMPTED-RECON .................................................. 119

4.2.7. Agente INTÉRPRETE BAD-UNKNOWN .......................................................... 121

4.2.8. Agente INTÉRPRETE OTROS........................................................................... 123

4.2.9. Agente INTÉRPRETE UNKNOWN-CLASS....................................................... 125

4.2.10. Agente ANALISTA ............................................................................................ 127

4.2.11. Agente ANALISTA ATTEMPTED-ADMIN....................................................... 130

4.2.12. Agente ANALISTA ATTEMPTED-DOS............................................................ 132

4.2.13. Agente ANALISTA ATTEMPTED-RECON ...................................................... 134

4.2.14. Agente ANALISTA BAD-UNKNOWN............................................................... 136

4.2.15. Agente ANALISTA OTROS............................................................................... 138

4.2.16. Agente ANALISTA UNKNOWN-CLASS ........................................................... 140

4.2.17. Agente SUPERVISOR....................................................................................... 142

4.3. COMPORTAMIENTOS ........................................................................................ 146

4.3.1. PERIÓDICO...................................................................................................... 147

4.3.2. CÍCLICO ........................................................................................................... 148

4.3.3. RECIBIR NOTIFICACIONES ........................................................................... 149

4.3.4. SINCRONIZAR .................................................................................................. 152

4.3.5. LIMPIAR BD ..................................................................................................... 154

4.3.6. OBTENER ANOMALÍAS ................................................................................... 156

4.3.7. ANALIZAR ANOMALÍAS .................................................................................. 160

4.3.8. ANALIZAR ANOMALÍAS ATTEMPTED-ADMIN ............................................. 169

4.3.9. ANALIZAR ANOMALÍAS ATTEMPTED-DOS.................................................. 172

4.3.10. ANALIZAR ANOMALÍAS ATTEMPTED-RECON ........................................... 175

4.3.11. ANALIZAR ANOMALÍAS BAD-UNKNOWN.................................................... 178

4.3.12. ANALIZAR ANOMALÍAS OTROS.................................................................... 181

4.3.13. ANALIZAR ANOMALÍAS UNKNOWN-CLASS ................................................ 184

4.3.14. DIAGNOSTICAR RESÚMENES ...................................................................... 187

4.4. CLASES DE LA INTERFAZ GRÁFICA............................................................... 215

4.4.1. MODELO DE TABLA........................................................................................ 215

4.4.2. VENTANA RELOJ ............................................................................................. 217

4.4.3. VENTANA AGENTE.......................................................................................... 220

4.4.4. VENTANA AGENTE AVANZADO..................................................................... 223

4.4.5. VENTANA AGENTE ANALISTA ....................................................................... 226



3

4.4.6. VENTANA DETALLES ...................................................................................... 231

4.4.7. VENTANA AGENTE SUPERVISOR.................................................................. 234

4.4.8. LEYENDA.......................................................................................................... 239

4.4.9. LIENZO SUPERVISOR ..................................................................................... 240

4.4.10. VENTANA DETALLES CON GRÁFICO Y TABLA.......................................... 244

4.4.11. VENTANA DETALLES CON TABLA ............................................................... 248

4.4.12. LIENZO DETALLES ........................................................................................ 252

4.5. CLASES DE LA CAPA DE PERSISTENCIA ....................................................... 256

4.5.1. EVENTO DAO................................................................................................... 256

4.5.2. ANOMALÍA DAO .............................................................................................. 259

4.6. CLASES DE FUNCIONES DE CÁLCULO .......................................................... 263

4.6.1. FUZZY ............................................................................................................... 263

4.6.2. CONTROL BORROSO ...................................................................................... 264

5. ARQUITECTURA DEL SISTEMA IDSAI................................................................. 277

5.1. ARQUITECTURA JAVA JADE MULTIAGENTE .............................................. 277

5.2. ARQUITECTURA DEL SISTEMA IDSAI ........................................................... 279

5.2.1. MODELO DE ARQUITECTURA EN CAPAS .................................................. 281

5.2.2. MODELO DE ARQUITECTURA IDSAI ........................................................... 283

5.2.3. MODELO DE COMPORTAMIENTOS ............................................................. 290

6. DISTRIBUCIÓN DEL PROYECTO IDSAI ............................................................... 293

6.1. CARPETA DE PROYECTO IDSAI....................................................................... 293

6.2. CARPETA DE INSTALABLES INSTALACION IDSAI ..................................... 298

7. MANUAL DE INSTALACIÓN DEL SISTEMA IDSAI............................................ 302

7.1. INSTALACIÓN DE LA MÁQUINA VIRTUAL JAVA........................................ 303

7.2. INSTALACIÓN DEL IDS SNORT........................................................................ 304

7.3. INSTALACIÓN DEL SGBD MYSQL ................................................................... 311

7.4. INSTALACIÓN DE LA PLATAFORMA IDSAI .................................................. 317

8. MANUAL DE USO DEL SISTEMA IDSAI................................................................ 318

8.1. CONFIGURACIÓN DE LOS SENSORES............................................................ 319

8.2. ARRANQUE DE LOS AGENTES......................................................................... 320

8.3. EXPLOTACIÓN DEL SISTEMA.......................................................................... 326

8.3.1. INTERFAZ DEL AGENTE SUPERVISOR ........................................................ 327



4

8.3.2. INTERFAZ DEL AGENTE ANALISTA.............................................................. 342

8.3.3. INTERFAZ DEL AGENTE INTÉRPRETE......................................................... 349

8.3.4. INTERFAZ DEL AGENTE RELOJ.................................................................... 352

9. PLANIFICACIÓN Y PRESUPUESTO DEL PROYECTO....................................... 355

9.1. ORGANIZACIÓN DEL PROYECTO ................................................................... 355

9.2. METODOLOGÍA Y RECURSOS.......................................................................... 358

9.3. PLANIFICACIÓN DE TAREAS ........................................................................... 361

9.4. PRESUPUESTO .................................................................................................... 368

10. CONCLUSIONES.......................................................................................................... 370

11. BIBLIOGRAFÍA............................................................................................................ 374

12. SIGLAS Y ACRÓNIMOS............................................................................................. 376

13. ANEXOS......................................................................................................................... 379



5

1. OBJETIVOS DEL PROYECTO

El proyecto IDSAI (IDS, Sistema de Detección de Intrusos, basado en Agentes

Inteligentes) aborda el tema de la detección de intrusiones en redes de ordenadores, y en

particular, los Sistemas de Detección de Intrusos como solución a esta problemática.

Hoy en día, la protección 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 Detección 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 Detección de

Intrusos que permita la introducción de nuevos métodos heurísticos de

detección y conocimiento de diagnóstico de una forma sencilla y sin cambiar

la estructura de la distribución.

- Diseñar una interfaz gráfica de usuario sencilla y funcional que facilite al

usuario el manejo del sistema.

- Optimizar los resultados del Sistema de Detección 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 informática en redes con la

utilización de un producto barato y eficaz.

- Aportar nuevas técnicas y conocimientos que contribuyan a mejorar el

desarrollo tecnológico de la sociedad.



6

- Incrementar la confianza de los administradores de redes en los Sistemas de

Detección de Intrusos, como herramienta útil en la seguridad informática.

- Concienciar a la sociedad informática de los problemas que pueden

plantearse si no se utilizan sistemas adecuados de seguridad.



7

2. ALCANCE DEL PROYECTO

La consecución de los objetivos planteados en el proyecto IDSAI, se llevará a

cabo a través de distintos procedimientos:

- Se parte de un Sistema de Detección 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 características del proyecto y es de libre

distribución.

- Se toma como modelo de arquitectura distribuida el paradigma de agentes

inteligentes. Para ello se toma el middleware JADE como base de su

desarrollo por ser una tecnología estable, bien documentada y de libre

distribución.

- Para el diseño de la interfaz gráfica 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 información necesaria

para la adecuada distribución de sensores en la red y su configuración

individual.

- La primera distribución del sistema incluirá los parámetros heurísticos y

clases necesarias para la evaluación de la criticidad del sistema en base a

ataques de tipo escalada de privilegios, negación de servicio, reconocimiento

(profundizando en el escaneo de puertos) y situaciones anormales en general.



8

- Se aportan heurísticas en forma de árbol de decisión y controladores

borrosos para la reducción de falsos positivos y falsos negativos disparados

por el Sistema de Detección de Intrusos.

- Se utiliza un entorno de pruebas para la verificación del correcto

funcionamiento del sistema en cada una de las versiones del aplicativo.

- La implantación y uso del sistema se facilita mediante manuales que se

proporcionan con la distribución del proyecto.

- Tanto el software base del proyecto (IDS, Gestor de bases de datos,

middleware...) como las herramientas de desarrollo utilizadas (lenguaje y

entorno de programación, herramientas de diagramación, herramientas de

documentación...) son gratuitos y de libre distribución.

- La investigación realizada sobre los temas de seguridad informática,

Sistemas de Detección de Intrusos y arquitecturas software distribuidas

aporta nuevos conocimientos cuya aplicación mejora el rendimiento de los

elementos de partida.

- Los Sistemas de Detección de Intrusos, que en un principio tuvieron una

gran aceptación, no gozan actualmente de una gran confianza por parte de

sus usuarios. El presente proyecto intenta que los IDS recuperen la

credibilidad perdida, proponiendo una solución eficaz.

- Los administradores de red deben concienciarse de la utilidad de los

Sistemas de Detección de Intrusos para la seguridad informática. Su mayor

eficacia se alcanza combinándolos adecuadamente con otros componentes de

seguridad, como los Firewall.



9

- Los métodos de seguridad serán eficaces siempre y cuando los usuarios

conozcan los peligros a los que están expuestos los sistemas informáticos a

acciones malintencionadas llevadas a cabo por agentes externos a la red o

debido al uso inadecuado de los recursos. En el proyecto se describen los

ataques y errores más frecuentes que pueden llegar a comprometer la

seguridad de una red de computadores.



10

3. ESTADO DEL ARTE

Hoy en día son conocidos los constantes ataques que sufren los servidores y

redes de computadores de las compañías más importantes del mundo. El robo y/o

manipulación de la información almacenada en un servidor corporativo puede provocar

graves pérdidas a una empresa y grandes beneficios a quien se lucre de ello. ¿Qué

ventaja de negocio supondría para una organización ver los equipos informáticos de sus

competidoras completamente colapsados e inservibles durante horas? ¿Qué precio tiene

la confidencialidad de las comunicaciones de una importante compañía? Lo que

comúnmente conocemos como ataques informáticos supone una gran preocupación para

los administradores de red de cualquier organización que disponga de nuevas

tecnologías de la información.

Actualmente la comunicación entre computadores ha cobrado una importancia

vital en el mundo de la informática y el volumen de redes conectadas entre sí a lo largo

del mundo supera cualquier expectativa inicial. El valor de los datos corporativos que

una empresa mueve a lo largo de sus canales de información es incalculable y por ello

las compañías invierten gran cantidad de recursos económicos y humanos en preservar

su seguridad.

En los siguientes apartados se hará referencia a diversos temas de seguridad

informática: Sistemas de Detección de Intrusos y seguridad perimetral, vulnerabilidades

de los sistemas informáticos y tipos de ataques que una entidad maliciosa puede

perpetrar contra ellos. Más adelante se hará una introducción a los modelos distribuidos

que hoy en día se implantan en las aplicaciones multiplataforma y en particular el

modelo JADE multiagente inteligente. Para terminar se hablará del IDS concreto

utilizado como base del proyecto IDSAI: Snort.



11

3.1. SISTEMAS DE DETECCIÓN DE INTRUSOS

Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es

un hardware, software o combinación de ambos que monitoriza la red de un sistema

informático en busca de actividad maliciosa [KOZI03]. Un IDS dispara alarmas a

tener en cuenta por el administrador de la red advirtiendo la presencia de actividad

intrusa, inusual, no autorizada o potencialmente dañina en el momento en que se

está produciendo, lo que permite percatarse de una situación en la que la seguridad

aparente de la red no es tal. Hay que destacar que un IDS se limita a notificar de

situaciones anómalas y/o peligrosas en la red, y por tanto no interviene activamente

en su prevención (lo que deberá llevar a cabo el supervisor de la red aplicando las

medidas correspondientes).

Existen gran cantidad de productos IDS, ajustables a las necesidades

específicas de cualquier infraestructura, ya sea a nivel de rendimiento (más rápido,

con capacidades de gestión centralizada, etc.) o a nivel de configuración y

mantenimiento (más o menos configurable, más o menos simple de usar, etc.).

Entre el software de libre distribución podemos encontrar múltiples

herramientas de este tipo, herramientas que presumen de ser fiables y

frecuentemente actualizables dada la masiva colaboración de la comunidad de

usuarios que libremente aportan su conocimiento a la causa. Constantemente hay

gente programando nuevos plugins y funcionalidades a estas aplicaciones que son

supervisadas por un organismo dedicado para garantizar su calidad.

Algunos de los IDS de libre distribución más conocidos son [DIAZ05]:

o Snort: Este es el IDS más famoso y potente de cuantos hay en el

mercado. Está basado en análisis de patrones, aunque poco a poco

empieza a implementar otras funcionalidades como el análisis

estadístico (SPADE). Puede ser implantado tanto como NIDS como



12

NNIDS. Requiere conocimientos avanzados de seguridad y sobre

ataques e intrusión en redes, ya que su configuración en detalle es

muy compleja. Este IDS se tratará en detalle más adelante, ya que es

el sistema de detección de intrusos en el que se basa el proyecto

IDSAI.

o Shadow: Menos extendido que el anterior, representa otra filosofía de

IDS. Está basado en análisis de tráfico, 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 página html donde se puede

ver el resultado de forma simple y resumida. Permite comparar

capturas para buscar diferencias significativas. Este tipo de IDS

requiere más 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 información de

ambos en una misma interfaz. Tiene un alto grado de automatización

y es sencillo de configurar.

Existen numerosos desarrollos comerciales de IDS. La imagen de confianza

que aporta una marca conocida en aplicaciones de seguridad informática hace que

muchos usuarios se decanten por estos productos. En el proyecto IDSAI no se han

investigado herramientas IDS comerciales y el autor del presente documento se

abstiene de citar ejemplos.



13

3.1.1. SEGURIDAD PERIMETRAL

La teoría de la seguridad perimetral trata de solucionar el problema de la

seguridad de las redes corporativas. Esta teoría propone la disposición

estratégica de los equipos en subredes debidamente protegidas de accesos

externos no autorizados mediante 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 tráfico en una red de

computadores, pero no es suficiente para garantizar la seguridad del sistema. Un

Firewall representa una puerta que prohíbe el paso a todas aquellas

comunicaciones no permitidas, pero que deja pasar aquellas necesarias para el

usuario al otro lado del dispositivo. Aunque sólo se permitan los servicios

básicos y teóricamente seguros, existen debilidades y agujeros de seguridad ante

los que un Firewall no puede hacer nada, ya que es incapaz de evitar que un

atacante utilice un servicio autorizado para perpetrar una acción maliciosa. Si la

seguridad que proporciona un Firewall se ve comprometida es necesario

disponer de algún sistema que permita al administrador de red ser capaz de

detectar esta situación [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 podría 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 más eficiente y

tomar acciones reactivas eficaces en una situación en que se haya producido un

daño en la red. Otra situación que alarmantemente es de las más frecuentes en

temas de seguridad informática es el ataque desde dentro de la red, por parte de

los propios usuarios autorizados, que bien por ignorancia o por malicia, ponen

en peligro los recursos de la empresa (según los estudios alrededor de un 80%



14

del total de ataques proceden del interior). Frente a estas circunstancias, un

Firewall que controle el tráfico hacia fuera de la red es inútil, por lo que el único

recurso en el que confiar es el IDS que alerte de esta situación de modo que un

supervisor pueda tomar medidas internas en la compañía.

Un IDS no impide la consecución de un ataque, pero permite alertar de

su presencia. Las capacidades de un IDS permiten realizar múltiples actividades

relacionadas con la seguridad informática como son las siguientes [DIAZ05]:

o Monitorización y análisis de las actividades de los usuarios. Como se

ha descrito anteriormente, una gran proporción de los ataques

informáticos son perpetrados por parte de los propios usuarios

autorizados de la red. Un control de sus actividades (respetando la

intimidad de las personas) permite saber los servicios que utilizan y

el uso que hacen de ellos.

o Auditoria de configuraciones y vulnerabilidades de sistemas. La

detección de tráfico permite descubrir sistemas con servicios

habilitados innecesarios o no autorizados, que de otra manera

pasarían inadvertidos. El descubrimiento de una vulnerabilidad del

sistema permite tomar medidas al respecto, eliminándola o si no es

posible, poniendo especial atención en ella.

o Asegurar la integridad de los sistemas críticos. El análisis de tráfico

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 están libres

de ataques, ya que nunca se puede garantizar al 100% la eficacia del

Firewall.



15

o Análisis estadístico de ataques. Dado que la comparación de ataques

contra una base de datos es algo limitado, existen herramientas

heurísticas de búsqueda de patrones de ataques (como hacen los

sistemas Antivirus con el código malicioso). Sistemas basados en

redes neuronales y demás métodos de inteligencia artificial se aplican

cada vez con más frecuencia para este tipo de fines.

o Análisis de tráfico anormal. El tráfico autorizado que podemos

considerar normal en nuestras funciones de negocio, puede dejar de

serlo en determinadas circunstancias (conexiones fuera de las horas

de trabajo, tráfico en segmentos de backup en estado de normalidad,

accesos frecuentes a equipos de uso excepcional...). Un análisis

detallado del tráfico puede revelar una máquina comprometida o la

situación 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 través 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

también 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 actualización de la base de

reglas de reconocimiento de patrones de un IDS es una importante

actividad rutinaria de su mantenimiento.



16

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 autenticación débiles. 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 investigación de los incidentes. Es

necesaria la intervención humana (de un analista cualificado) para

descubrir la naturaleza real del ataque, limpiar sus efectos, descubrir

al atacante y protegerse para el futuro.

o Un IDS mal configurado puede dar lugar a errores y confusiones

típicas de este tipo de sistemas [KOZI03]:

� Falsos positivos: Alertas disparadas en condiciones normales.

Este tipo de situación es indeseable, debido a que hace que el

administrador de red se alarme innecesariamente y termine

por ignorar alertas reales pensando que se trata de este tipo de

errores. Esta situación se da en IDS configurados con

excesivo nivel de detalle y propensos a alertar de la más

mínima variación respecto a la normalidad.

� Falsos negativos: Ausencia de alertas en condiciones de

ataque y tráfico no autorizado. Este tipo de error es peor que

el anterior, ya que el IDS no realiza su función de avisar de la

situación, lo que implica que el ataque pase desapercibido y

por tanto, no se tomen medidas adecuadas y eficaces a tiempo

de evitar males mayores. Esta situación se da en IDS no

actualizados o configurados con bajo nivel de detalle y



17

propensos a alertar solamente situaciones muy claras, que los

hackers más experimentados suelen saber prevenir.

o El párrafo anterior deja constancia de lo importante que es la

adecuada configuración de un IDS, cosa que no es trivial y requiere

de un gran conocimiento al respecto y experiencia en el campo de la

seguridad informática. Puesto que no está al alcance de cualquiera, se

recomienda no confiar en un sistema de este tipo si no se puede

garantizar su correcto funcionamiento.

o El software de un IDS es muy pesado. Hacer pasar todo el tráfico 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 ningún paquete. Instalar un sistema IDS en un punto de paso

del tráfico de red (por ejemplo en un router o en un Firewall) es la

mejor manera para garantizar que no se deja de analizar ningún

paquete de red. En la práctica se desaconseja colocar un IDS en un

lugar propenso a convertirse en cuello de botella debido a que

analizar en detalle cada uno de los paquetes antes de dejarlos pasar

introduce un retardo indeseable en cualquier red de computadores. En

futuros capítulos se abordará la cuestión de cómo y dónde colocar

sistemas IDS en redes de diferentes tipos.



18

3.1.2. CLASIFICACIÓN DE IDS

Existen tres tipos básicos de IDS según el fin para el cual están diseñados

[KOZI03]:

o Network Intrusion Detection System (NIDS): Son instalados en un

segmento de red en concreto, del cual pueden absorber todo el tráfico

(escuchan en modo promiscuo) y analizarlo en tiempo real para

disparar las alertas correspondientes. Cuanto más transparente sea su

funcionamiento y menos interfiera en el tráfico de red, mejor.

o Network Node Intrusion Detection System (NNIDS): Son instalados

en un host en concreto, analizando todo el tráfico destinado a dicho

equipo. Se suelen utilizar sobre equipos críticos de la compañía

propensos a ser objetivo de ataques o en un HoneyPot (host

débilmente protegido que sirve de trampa para hackers desviando su

atención de los equipos más importantes).

o Host Intrusion Detection System (HIDS): Son instalados en un host

en concreto y permiten tomar una instantánea del sistema, para

comprobar mas adelante la integridad de la máquina. 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.



19

Los IDS también se pueden clasificar en las siguientes categorías según

su forma de detectar las intrusiones [KOZI03]:

o Búsqueda de patrones (Signature detection): Los IDS de este tipo

disponen de una base de datos que contiene patrones o firmas de

ataques conocidos, y cada paquete que se analiza se contrasta con esa

base de conocimiento. Cuanto mayor sea la lista de firmas conocidas,

más tipos de ataques se podrán detectar, pero más costoso

computacionalmente será para cada paquete, pudiéndose perder

alguno si el ritmo de análisis no soporta el del flujo de información.

o Análisis de tráfico (Anomaly detection): Los IDS de este tipo están

configurados para conocer la situación "normal" de la red. Recolectan

todo el tráfico y crean estadísticas en tiempo real del estado de la red.

Si en un momento determinado, la estadística se sale de la

normalidad, se genera la alerta para que el analista lo investigue.

o Verificación de integridad: Es el sistema que utilizan los HIDS. Se

comprueban determinados aspectos de un equipo (checksum de

ficheros críticos, registro del sistema, logs...). Permite saber a

posteriori, que tipos de ataques se han perpetrado en un sistema y los

daños que han producido.



20

3.1.3. IMPLANTACIÓN DE IDS

Hasta aquí se ha pretendido dar una visión general de los IDS: sus

funcionalidades, utilidad, ventajas e inconvenientes. Un IDS es un dispositivo

que complementa las medidas de seguridad de la red, muy útil para tomar

medidas concretas frente a una situación de crisis, e incluso para poder preverla.

Este punto hace hincapié en la dificultad que conlleva el uso de este tipo

de dispositivos, desde la necesidad de conocimientos avanzados de seguridad

para configurarlos correctamente y saber interpretar sus alertas hasta la

experiencia necesaria en seguridad perimetral para saber ubicarlos en la red de

forma que den un resultado eficaz.

La implantación de un IDS requiere una serie de pasos a seguir para

hacerlo de forma eficiente [KOZI03]:

1. Identificación de necesidades: Se debe determinar la importancia de

la información. Cuantificar en términos económicos y subjetivos

(confianza pública en la compañía, respeto por parte de otras

empresas...) las pérdidas en que se incurriría si los datos se perdieran

y/o fueran robados. Esta cuantificación permitirá valorar si resulta

rentable implantar el sistema o no y determinar la probabilidad de

sufrir un ataque por parte de un hacker interesado en obtener

beneficio. Si la red ya ha estado bajo ataque anteriormente, se

conocen sus vulnerabilidades y ha mostrado signos de debilidad es

probable que pueda volver a sufrir un ataque. Determinar el nivel de

seguridad a implantar en la red es necesario para establecer un plan

de seguridad concreto.

2. Obtener conocimientos sobre la detección de intrusos: Es necesario

tener unas nociones básicas de lo que puede hacer un IDS y para qué



21

sirve, o de lo contrario se tendría una falsa ilusión de seguridad. El

conocimiento sobre ataques informáticos y sobre el estado del arte en

temas de seguridad es fundamental para poder interpretar

adecuadamente los resultados del IDS.

3. Obtener conocimientos sobre la infraestructura de red: Una red

debidamente estructurada en diferentes segmentos protegidos con

Firewalls es más segura que una mal administrada. La distribución de

sensores en las diferentes subredes dará lugar a una variedad más rica

y precisa de análisis.

4. Escoger el IDS más adecuado: Se debe elegir el sistema IDS que

mejor se ajuste a las necesidades de protección de la red,

condicionado su complejidad al nivel de conocimiento por parte del

administrador/analista. Evaluar varios IDS simulando baterías de

ataques en un entorno de pruebas similar a la red sobre la que

implantar definitivamente el producto requiere trabajo y una gran

pericia, pero es el mejor método para decantarse por un IDS en

particular.

5. Especificar una política de seguridad: Es fundamental contar con un

protocolo de actuación concreto frente a una situación de alerta por

parte del IDS, ya que de nada sirve ser capaz de detectar ataques si

luego no se sabe que hacer en respuesta. Debe contarse con una

documentación completa sobre lo que hacer en cada situación, de

forma que no surjan dudas sobre el plan de acción. Esta

documentación es específica de cada organización y no es trivial

realizarla, por lo que debe ser creada por expertos en seguridad y

planes de emergencia. El administrador de red encargado de seguir

esta política también deberá tener conocimientos avanzados de este



22

tipo para poder intervenir rápida y eficazmente sin dudar en ninguna

situación.

La implantación física del IDS en la red es muy importante. De ella

dependerán las características que deberá tener y el rendimiento que se puede

esperar. En la figura 1 se muestra un ejemplo tipo de red bien estructurada

destacando los lugares estratégicos más comunes donde disponer de sistemas

IDS [DIAZ05]:

Fig. 1: Ejemplo configuración de red.

Aunque dependiendo del entorno se pueden encontrar otras ubicaciones

posibles, los puntos más típicos donde colocar un IDS (puntos rojos en la

imagen) son:

Red corporativa

Subred servidores

Subred usuarios

Internet

Red corporativa externa

DMZ

4

5

3 2 1



23

1. Entre la Extranet e Internet: Para controlar el tráfico que sale/entra de

la red externa de la compañía es imprescindible contar con un sensor

IDS en el enlace VPN por el que se accede a través de Internet a la

red corporativa.

2. En la DMZ: La zona desmilitarizada es el segmento de red entre el

firewall de la red corporativa e Internet. En él se suelen ubicar los

servidores de acceso público que no albergan información importante

y no requieren unas medidas de protección y seguridad exhaustivas

(servidores web, por ejemplo). Por esta razón suelen ser objetivo de

una primera aproximación a la red por parte de hackers y por tanto su

vigilancia debería considerarse en todo momento.

3. Tras el Firewall: Esta suele ser la ubicación característica de un IDS,

puesto que permite analizar todo el tráfico que entra en la red (ya

filtrado por el Firewall). De la misma forma, permite comprobar que

el Firewall funciona incorrectamente, si este ha dejado pasar tráfico

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 información estratégica del negocio se

encuentra almacenada en los servidores de la empresa. La vigilancia

en este punto es algo fundamental.

5. En el acceso a usuarios: Este sensor sirve para detectar ataques a

máquinas de usuario, que pueden almacenar información de negocio

y suelen tener acceso privilegiado a los servidores de la compañía.

Los ataques que se inicien en el interior de la organización también se

detectarán más rápidamente si consideramos la instalación de este

IDS.



24

Como se puede ver, disponer de varios sensores IDS en distintos lugares

estratégicos de la red es fundamental para completar el sistema de capas de

seguridad que componen las subredes y Firewalls de la empresa. Tomar

decisiones en respuesta a alertas generadas por IDS concretos será más rápido y

eficaz que hacerlo si sólo contamos con un sensor para toda la red. Además cada

IDS se puede configurar en detalle según el tipo de tráfico de su segmento de red

en particular, para así reducir el tamaño de su base de reglas y evitar la búsqueda

de patrones superfluos.

En entornos con múltiples IDS es muy útil tener centralizada la gestión.

De esta forma se pueden recoger los registros y las alarmas en un único lugar.

Esto facilitará el trabajo del personal de seguridad que según hemos explicado es

indispensable que esté tras la máquina interpretando los resultados e

interviniendo en caso de ataque. Los logs deben ser revisados diariamente y la

actualización del IDS debe ser constante, añadiendo las nuevas firmas

conocidas. Además, el personal de seguridad es responsable de mantener los

sistemas de recuperación ante emergencias.

Por todo lo que se ha comentado hasta el momento, parece obvio que un

IDS, más que cualquier otro producto de seguridad, necesita ser optimizado. Su

uso de ancho de banda es intensivo y las operaciones que tiene que realizar son

muy complejas, consumiendo gran cantidad de recursos computacionales. El

resultado predecible de un IDS no optimizado es una perdida potencial de

paquetes y por tanto una perdida potencial de ataques o incluso un elevado

número de falsos positivos (si al perder paquetes, el IDS detecta

discontinuidades en las secuencias TCP). En una situación de congestión de red

debido a una inundación masiva de paquetes, el IDS empezará a fallar, por eso

es importante que la carga de CPU en un IDS sea generalmente baja, para poder

estar disponible en situaciones de emergencia. Las acciones que un

administrador de red puede llevar a cabo para ajustar un IDS son [DIAZ05]:



25

o Optimizar la base de datos de firmas: En general, la configuración

por defecto de los IDS busca todos los ataques conocidos posibles.

Debido a las características de la red, muchos de ellos aunque se

produjesen no tendrían efecto. Es importante conocer bien la red que

se pretende administrar para no perder tiempo de CPU chequeando

firmas de ataques que nunca tendrían éxito en nuestra configuración.

Ejemplos: Ataques de tipo RPC en entornos totalmente Microsoft o

análisis de exploits de sistemas FTP en redes sin este tipo de servicio.

o Filtrar tráfico no deseado: Por defecto, el IDS analiza todo el tráfico

que es capaz de capturar en su segmento de red. Como se ha

explicado anteriormente, un IDS es incapaz de identificar firmas en

tráfico cifrado, por lo que el sensor se puede configurar para que

ignore el tráfico de este tipo, por ejemplo el SSH.

o Balanceo de carga: Al ser un IDS un dispositivo computacionalmente

pesado, si el volumen de tráfico a analizar es muy importante (porque

esté situado en una zona crítica como detrás del Firewall), es

recomendable la instalación de varios sensores balanceados por tipo

de tráfico. Reduciendo el número de reglas que se comparan en cada

sensor se obtiene un mejor rendimiento por cada uno, pero hay que

cuidarse de no dejar reglas relevantes sin supervisar.

o Optimización de la configuración: Además del juego de reglas, cada

IDS tiene varias opciones de configuración que influyen en su

rendimiento. Es muy importante adaptar cada sensor a la situación

más adecuada.



26

3.2. ATAQUES INFORMÁTICOS E INTRUSIÓN EN REDES

En los siguientes puntos se presentan unas breves reseñas sobre ataques

informáticos e intrusión en redes que ayudarán a comprender mejor a qué se

enfrentan los administradores de red y los motivos de la instalación de Sistemas de

Detección de Intrusos.

3.2.1. FASES DE UN ATAQUE

La intrusión de redes y los ataques a recursos críticos de una compañía

por parte de hackers y usuarios con malas intenciones es algo que los

administradores de red tienen muy presente y tratan de prevenir dentro de sus

posibilidades. Los Sistemas de Detección de Intrusos y los procedimientos de

registro de incidencias han evolucionado de forma paralela a la pericia de los

hackers.

La estrategia de un hacker que pretende realizar un ataque preciso a una

red de computadores es impredecible. Si un atacante siguiera un protocolo de

acción concreto, sería muy sencillo prever sus ataques. No obstante la

intervención de un hacker suele diferenciarse en 4 fases, que deben conocerse en

detalle [KOZI03]:

3.2.1.1. PLANTEAMIENTO

Los buenos hackers generalmente se detienen a planear en detalle

sus ataques antes de realizar ninguna acción sospechosa. Un hacker

inteligente tratará de buscar por medios indirectos (los medios directos los

aplicará en la fase de reconocimiento) información sobre la estructura de la



27

red que pretende atacar y sobre sus vulnerabilidades (agujeros en

aplicaciones de negocio, equipos desprotegidos...). Esta información se

puede obtener de múltiples maneras: por medio de los propios empleados de

la empresa, accediendo a documentación que descuidadamente publican los

administradores del sistema, etc.

En esta fase, si el hacker no tiene un objetivo concreto, lo

determinará. La motivación y la información de la que parta el atacante le

hará decantarse por uno o más ataques de entre los siguientes tipos:

� Negación de servicio (DoS, Denial of Service): Este tipo de

ataque consiste en inutilizar un recurso del sistema, de forma

que no pueda realizar su trabajo. La negación de servicio de

una aplicación ubicada en un servidor consiste generalmente

en el envío masivo de peticiones remotas con el objetivo de

colapsar la aplicación de forma que no pueda atender a las

peticiones ordinarias de los usuarios. Cualquier procedimiento

que implique una reducción de los recursos computacionales

del servidor de forma que no pueda atender adecuadamente

las peticiones también puede considerarse una negación de

servicio (por ejemplo un troyano pesado que agote la

memoria de la máquina).

Una negación de servicio puede extenderse a varios equipos

si se consigue inundar de tráfico anormal un segmento de red

entero. Un ataque de este tipo bien planeado, puede inutilizar

una red entera forzando a resetear cada una de las máquinas

si se realiza con éxito.

� Escalada de privilegios: Este tipo de ataque consiste en

obtener los permisos legítimos necesarios para acceder a un



28

determinado recurso del sistema. De esta manera, un hacker

puede acceder a cualquier recurso del sistema como si de un

usuario autorizado se tratara.

En la práctica, la escalada de privilegios consiste en obtener

un usuario y contraseña válidos para el acceso al recurso

deseado. Esto es relativamente sencillo en métodos de

autenticación débiles (transmisión de contraseñas sin cifrar,

passwords de diccionario...) si se consigue capturar el tráfico

de un segmento de red.

Instalar un troyano de tipo keylogger (registro de teclas)

puede ser un sencillo método para obtener passwords de

usuario si no se dispone de un antivirus que lo detecte. De

hecho, cualquier troyano tiene como objetivo la escalada de

privilegios, ya que al ser instalado en una sesión de usuario

autorizado permite el acceso con esos permisos al atacante

remoto.

Un administrador de red descuidado que publique cuentas de

usuario raíz y no realice una gestión adecuada de contraseñas,

actualizándolas frecuentemente, puede encontrarse con serios

problemas de escalada de privilegios por parte de usuarios no

autorizados.

El acceso a un recurso utilizando una autenticación válida

aunque el usuario no haya sido autorizado a ello es un hecho

ante el que un IDS es inútil al no poderlo identificar como un

ataque.



29

� Acceso no autorizado: Este tipo de ataque consiste en el

acceso a un determinado recurso del sistema aprovechando

las vulnerabilidades del hardware de soporte y del software

que lo gestiona y en particular de sus agujeros de seguridad y

errores de programación. Los métodos que explotan estas

vulnerabilidades son comúnmente llamados exploits y son

bien conocidos en general por comunidades de hackers y

publicados abiertamente en páginas web y foros.

Primeramente se debe saber de qué versión del software se

trata, pero esto no es trivial y el atacante debe llevar a cabo

una labor de investigación si no lo conoce de antemano. Más

adelante, en la fase de reconocimiento, podrá poner en

práctica métodos directos de obtención de esta información,

aunque sean típicamente detectables por sistemas IDS.

Un sistema operativo desactualizado al que no se le han

instalado los parches de seguridad recomendados es una

fuente enorme de vulnerabilidades conocidas por la mayoría

de hackers (y publicadas en Internet) y lo mismo ocurre con

software de servicio remoto de uso común (servicios FTP, de

páginas web, etc.).

Según el tipo de ataque que se realice se atentará contra la propiedad

de seguridad que se desee violar del recurso. Un ataque de tipo negación de

servicio atenta exclusivamente contra la disponibilidad del recurso. Un

ataque de los otros dos tipos permite el acceso a la información al hacker y

por tanto viola la integridad de esos datos, ya que tras la intrusión no se

puede garantizar la validez ni la fiabilidad ni la confidencialidad de la

información manipulada.



30

3.2.1.2. RECONOCIMIENTO

En esta fase, el atacante lleva a cabo acciones directas para la

obtención de información sobre la red y soporte hardware y software de los

datos a los que desea acceder para llevar a cabo un ataque de tipo acceso no

autorizado. Este tipo de acciones son en general identificables por IDS,

debido a que al no tratarse de accesos ordinarios al servicio, contienen

particularidades que determinan patrones bien conocidos.

Después de que un atacante haya recopilado información pública

sobre la organización objetivo, tratará de descubrir vulnerabilidades

concretas a explotar. Existen una gran variedad de técnicas de

reconocimiento para obtener información detallada de este tipo.

La primera acción que tendrá que llevar a cabo el atacante es

comprobar si la víctima del ataque está arrancada en el instante actual, lo

que llevará a cabo haciendo ping a la dirección víctima en concreto. Si el

administrador de la red es cuidadoso habrá configurado los hosts del sistema

para que no respondan a las peticiones de eco ICMP. En ese caso, una

conexión TCP o un intento de comunicación UDP serán suficientes para

comprobar si la dirección IP víctima está activa.

En el momento en que se está seguro de que la máquina objetivo está

viva el atacante debe buscar puertos abiertos con la intención de saber qué

aplicaciones se están corriendo en el equipo y sus versiones, de forma que

pueda explotar sus vulnerabilidades. Esto se lleva a cabo a través de un

escaneo de puertos, tipo de ataque de reconocimiento que se torna inevitable

si se pretende saber para qué se utiliza realmente una máquina y que es

fácilmente detectable por un IDS.



31

Hosts seguros suelen estar configurados para no responder a intentos

de conexión sospechosa y sus servicios corren en puertos no standard. Esto

supondrá un esfuerzo extra al atacante a la hora de averiguar qué servicio

está corriendo en un puerto en particular con lo que tendrá que arriesgarse a

comunicarse con la aplicación (mediante Telnet, por ejemplo) para

averiguar su verdadera naturaleza, mostrando abiertamente sus intenciones,

lo que no pasará desapercibido al administrador de red.

Muchos exploits remotos están dedicados a determinados sistemas

operativos. El reconocimiento del sistema operativo que corre en una

máquina se realiza mediante la respuesta que este da a un determinado

estímulo (en general, paquetes de red no válidos a los que cada versión de

sistema operativo reacciona de forma diferente, lo que se conoce como

fingerprint).

Se verán más detalles y ejemplos de ataques de estos tipos en el

apartado 3.2.2: Ataques conocidos.



32

3.2.1.3. ATAQUE

Tras la planificación del ataque y el reconocimiento de la víctima, el

siguiente paso es hacer uso de la información obtenida para atacar el sistema

objetivo. Según la naturaleza del ataque que se desea realizar y las

vulnerabilidades del sistema escogido como víctima se llevarán a cabo las

acciones que el hacker considere más apropiadas y menos llamativas en pos

de impedir ser detectado por un IDS.

Esta fase es muy delicada por esta razón, y es muy frecuente en

hackers experimentados el servirse de triquiñuelas que impidan al encargado

de seguridad la localización del origen del ataque.

El primer paso en estas operaciones suele ser la negación de servicio

del sistema IDS que pueda dar la alarma del ataque, bien tratando de ocultar

el ataque entre otros más descarados a otras máquinas en paralelo o

inundando el segmento de red del IDS con tráfico anómalo para generar una

respuesta confusa por su parte. Es deseable a su vez para el atacante, el

realizar el ataque desde varios hosts zombies (es decir, controlados de forma

remota de forma transparente a su usuario autorizado) a la vez, lo que

generalmente se consigue mediante la instalación de virus troyanos en las

máquinas controladas. Un ataque distribuido bien coordinado, es más eficaz

que uno perpetrado desde una sola máquina y permite a la vez que la pista

del atacante se pierda entre equipos irrelacionables con su persona.

En la presentación de los tipos de ataques a realizar en la fase de

planificación ya se hizo una breve introducción a ejemplos de ataque que no

se repetirán en este punto, pero que se desarrollarán en detalle en el apartado

3.2.2: Ataques conocidos.



33

3.2.1.4. POST-ATAQUE

Después de que el atacante haya penetrado satisfactoriamente en un

host de una red, las acciones que lleve a cabo pueden ser de lo más

variopinto. En esta fase el atacante demostrará su verdadera motivación y

pericia, llevando a cabo una o mas de las siguientes acciones:

� Borrar huellas: Es una buena práctica de hackers

experimentados el borrar todos los indicios de su presencia en

la red objetivo. Eliminar ficheros de log o registros del

sistema en los que haya quedado constancia de la presencia y

acción de una entidad no autorizada, confirmará al

administrador de red o al sistema HIDS la situación del

ataque, pero no podrán investigarlo. Existen scripts que

automatizan este procedimiento para ocultar la actividad

maliciosa tanto procedente del exterior (por la vía de las

comunicaciones) como del interior (virus y troyanos). Estas

aplicaciones que se denominan rootkits son una herramienta

fundamental para los hackers.

� Profundizar en la infraestructura de red: La información

importante para una compañía raramente es accesible desde

hosts con acceso al exterior. Los servidores de negocio suelen

ubicarse en subredes internas protegidas por 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 máquinas en la capa menos segura de la red,

suele ser la única manera de ejecutar ataques distribuidos de

forma remota sobre equipos más protegidos de la red. Una



34

escalada de privilegios en varias fases es tediosa y supone el

riesgo de ser detectado en una de las etapas, pero es la forma

más segura de tener éxito en el ataque.

� Robar, manipular o destruir datos: El acceso a la información

de la empresa es el móvil básico de un hacker, que le sacará el

máximo beneficio a la misma. Un cracker no se conformará

sólo con la lectura y modificación de la información a su

parecer, sino que además la destruirá haciendo perder a la

empresa víctima tiempo y dinero.

� Notificar al administrador y abandonar: No todos los hackers

pretenden lucrarse con sus actividades. Muchos de ellos

practican lo que se denomina hacking ético, afición que

consiste en perpetrar ataques a una red, con el único fin de

demostrar sus habilidades sin la intención de causar ningún

daño. Los hackers éticos suelen ponerse en contacto con el

administrador de la red atacada disculpándose por su acción y

detallándole las vulnerabilidades de su sistema por lo que

aunque la acción realizada es ilegal, no suelen ser

denunciados.



35

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 intrusión 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 detección de

equipos vivos en la red y de los servicios que se corren en ellos en cada uno

de sus puertos [KOZI03].

Como anteriormente se ha dicho, el primer movimiento que hace un

atacante para averiguar si un host está activo o no es ejecutar un comando

ICMP Ping (ECHO Request) contra la dirección IP objetivo. La máquina

contestará al origen con un mensaje ICMP ECHO Reply si está encendida y

no lo hará en caso contrario.

Fig. 2: ICMP Ping

También se ha comentado anteriormente otra manera de detectar un

host vivo: establecer una conexión TCP con él. Según el protocolo TCP, un

host activo contesta a un paquete TCP connect con un paquete ACK.

ECHO Request

ECHO Reply



36

Fig. 3: Conexión TCP

El escaneo de puertos es la forma directa de reconocimiento de las

aplicaciones que corren en una máquina. Si en un equipo remoto el puerto

estándar de una determinada aplicación está abierto significa que hay un

servicio escuchando por él y que se corresponde con una determinada

aplicación. Si el escaneo del puerto estándar de una aplicación conocida

resulta satisfactorio en una máquina se puede asegurar que en dicho servidor

está corriendo ese programa. Un escaneo TCP se realiza mediante una

conexión TCP al equipo objetivo por el puerto deseado. Dependiendo del

tipo de mensaje de contestación se puede determinar si el puerto está abierto

o cerrado y por tanto si su aplicación asociada está corriendo en el sistema y

se puede establecer comunicación con ella o no.

Fig. 4: Escaneo de puerto TCP

SYN

SYN/ACK

Puerto TCP abierto

SYN

RST/ACK

Puerto TCP cerrado

TCP

ACK



37

De una manera parecida, se puede realizar un escaneo UDP. La

comprobación de que una aplicación está a la escucha de un puerto UDP se

realiza mediante el envío de un paquete UDP. Al ser el protocolo UDP un

protocolo de red sin conexión, no se tiene por qué esperar una respuesta al

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í.

Fig. 5: Escaneo de puerto UDP

Si se desean explotar las vulnerabilidades del sistema operativo, se

recomienda conocer la versión del mismo, para saber con qué parches

cuenta y cuándo fue la última actualización de seguridad. Como se describió

en el apartado 3.2.1.2: Reconocimiento, la forma de identificar la versión

del sistema operativo de una máquina objetivo es analizando su fingerprint.

El ejemplo típico de ataque de reconocimiento de sistema operativo es el

ataque FIN. El envío de un paquete de cierre de una conexión TCP no

<UDP>

Puerto UDP abierto

<UDP>

ICMP Port Unreachable

Puerto UDP cerrado



38

abierta es una situación anómala frente a la cual, cada versión de sistema

operativo suele dar una respuesta diferente. Conociendo las posibles

respuestas se puede deducir con relativa exactitud el sistema operativo de la

victima y su versión.

Fig. 6: Ataque FIN

El escaneo de muchos puertos consecutivos con la intención de dar

con alguno por el que comunicarse con una máquina objetivo (horizontal

scan) consiste en iterar los escaneos anteriormente descritos para encontrar

un puerto abierto en la víctima. El proceso contrario, el escaneo de un

puerto concreto en varias víctimas (vertical scan) consiste en ir probando la

existencia del puerto objetivo en múltiples máquinas en busca de una

potencial víctima de un exploit conocido. Existen herramientas y scripts que

automatizan estos procesos, pero no dejan de generar un tráfico anormal y

tremendamente sospechoso que no se le suele escapar a ningún IDS. A

medida que los Sistemas de Detección de Intrusos han incorporado más

tipos de patrones de escaneos de puertos, los hackers han ido a su vez

descubriendo nuevos métodos para evitar ser detectados.

Un ejemplo es el ataque Xmas scan. Un paquete TCP enviado a una

víctima con todos los flags TCP/IP activados no se corresponde con ninguna

configuración válida de este protocolo y por tanto la máquina destinataria

devuelve una respuesta característica, es decir un fingerprint. Cuando se

descubrió este agujero del protocolo TCP/IP, este escaneo pasó

FIN

fingerprint



39

desapercibido para todos los IDS hasta que tiempo más tarde se les añadió

su firma.

Un IDS detecta un escaneo de puertos cuando en un breve espacio de

tiempo registra múltiples intentos de conexión a puertos o hosts

consecutivos desde una misma IP. Una forma de solucionar esto es ser

paciente y realizar el escaneo lentamente, durante horas o días para no

sobrepasar el umbral de tiempo que marca el IDS por defecto. Otra manera

de evitar que el atacante sea identificado como el origen de un escaneo es

realizarlo de forma distribuida, desde múltiples orígenes, cosa que no es

difícil si el hacker se ha hecho con el control de varias máquinas de la red.



40

3.2.2.2. ATAQUES DE NEGACIÓN DE SERVICIO (DOS)

Se denomina ataque de negación de servicio (Denial of Service,

DoS) a cualquier ataque que afecte al funcionamiento de un sistema de

forma que no puede dar servicio normal a sus usuarios legítimos. Los

ataques de negación de servicio pueden darse sobre la mayoría del

equipamiento de red, incluidos routers, servidores, firewalls, máquinas de

acceso remoto e incluso el propio medio. Un ataque de negación de servicio

puede tener como objetivo una aplicación específica (como la negación de

un servicio FTP) o una máquina entera (colapsando sus comunicaciones o

consumiéndole todos sus recursos).

Los ataques de negación de servicio tienen diversas naturalezas, pero

en general se pueden separar en dos categorías: Ataques de paquetes

maliciosos (malicious packet attacks) o Ataques de agotamiento de recursos

(resource depletion) [NORT01].

� Ataques de paquetes maliciosos: Consisten en el envío de

tráfico anormal de forma masiva hacia un host para provocar

un fallo en el propio equipo o en un servicio concreto

ejecutándose en el mismo. Este tipo de ataques se aprovechan

de que tanto el software de aplicación como el de los sistemas

operativos no está diseñado para esperar situaciones

extraordinarias, por lo que el sistema se no sabe como

reaccionar y colapsa. Para llevar a cabo con éxito un ataque

de este tipo, el atacante debe tener un conocimiento

exhaustivo sobre el servicio que pretende atacar, casi a nivel

de programador.

Un ejemplo de ataque de este tipo fue el Microsoft FTP

DoS. En las primeras versiones del servidor FTP de



41

Microsoft, se incluía la búsqueda de ficheros con caracteres

comodín (* y ?). Esta funcionalidad daba buenos resultados

en búsquedas con uno o dos símbolos de este tipo, pero el

sistema fallaba (por una cuestión de reserva insuficiente de

memoria) cuando el comando de búsqueda incluía múltiples

caracteres comodín intercalados (por ejemplo, *a*?*??*). La

aplicación FTP se quedaba colgada y se producía la negación

del servicio.

La negación de servicio del sistema IDS instalado en la red es

una de las acciones que los hackers suelen llevar a cabo para

evitar que éste dispare las alarmas que generan sus ataques.

En la versión 1.8.3 de Snort, la evaluación del tamaño de

paquetes ICMP tenía un error, y era que cuando éste tenía

valor 1, el sistema quedaba bloqueado en ese punto. La

inyección de paquetes ICMP manipulados con esta

característica, negaba el servicio del IDS, y el ataque

posterior podía llevarse a cabo sin vigilante que alertara la

situación.

� Ataques de agotamiento de recursos: Consisten en la

inundación de las capacidades de un servicio o máquina con

gran cantidad de tráfico autorizado, de forma que no puede

cumplir su función con respecto a los usuarios legítimos con

normalidad. El objetivo del atacante es ocupar todo el ancho

de banda de la conexión al servidor, o consumir sus recursos

computacionales básicos: CPU y memoria.

Un ejemplo de consumo del ancho de banda de la conexión a

la red de un host objetivo es el Ataque Smurf DoS. Este



42

ataque está basado en la técnica de suplantación de IP (IP

Spoofing), que consiste en enviar paquetes de red

manipulando las cabeceras IP de manera que la dirección de

origen no sea la propia. El envío de paquetes de red con una

dirección ajena significa que las respuestas a dichos paquetes

por parte de la estación destino se realizarán hacia esa

dirección. El ataque Smurf consiste en el envío de paquetes

ICMP ECHO Request a la dirección de broadcast, es decir, a

todos los equipos de la red objetivo a la vez, poniendo como

origen de los paquetes la dirección IP del host víctima. Cada

una de las máquinas de la red contestarán a la víctima con los

correspondientes paquetes ICMP ECHO Reply, consumiendo

una fracción del ancho de banda de su enlace de red, y el

conjunto de todos colapsará las comunicaciones de la víctima

durante unos segundos.



43

Fig. 7: Ataque Smurf DoS

Los ataques de negación de servicio generalmente utilizan la

técnica de suplantación de IP, ya que el ataque no requiere

una contestación por parte de la víctima para tener éxito y

además mediante el cambio de la dirección IP de origen, hará

más complicada la identificación del origen del ataque por

parte del administrador de red.

ATACANTE

VÍCTIMA

ECHO Request

ECHO Reply

ECHO Reply

ECHO Reply

ECHO Reply

ECHO Reply



44

3.2.2.3. EXPLOITS REMOTOS

Los exploits o vulnerabilidades remotas son el método más común

para obtener acceso no autorizado a un sistema. Estas técnicas están

diseñadas para tomar ventaja de código software mal diseñado para

comprometer y tomar control de un host vulnerable. Estas vulnerabilidades

suelen ser ampliamente conocidas y los desarrolladores del software habrán

publicado parches para resolverlas, por lo que es responsabilidad de los

administradores de red tener actualizadas sus aplicaciones. Si no es así,

significa que el hacker tiene un conocimiento profundo del aplicativo cuya

vulnerabilidad ha descubierto y pretende explotar, por lo que el ataque será

difícilmente predecible y sólo se podrán tomar medidas reactivas una vez se

lleve a cabo.

Los ataques de exploit remoto se asemejan a los ataques DoS de

paquetes maliciosos en que se aprovechan de la debilidad del software que

en situaciones inesperadas no es capaz de evaluar la entrada de datos,

haciendo que el sistema no sepa cómo reaccionar y colapse [NORT01].

Una vulnerabilidad típica ante la que todo software es propenso a

fallar es la del desbordamiento de búfer (buffer overflow). Los

desbordamientos de búfer se producen cuando un atacante introduce más

datos de los que un búfer o array puede manejar y esta condición no está

adecuadamente evaluada en el código del programa. Al salirse de la zona

reservada, los datos introducidos se sitúan por tanto en posiciones contiguas

de memoria y esto no sólo provoca que el programa aborte sino que si se ha

realizado de forma adecuada, se puede forzar al sistema a ejecutar la

información fuera de rango sin restricciones de permisos. El Apache

chunked encoding exploit es un ejemplo de desbordamiento remoto de

búfer. Apache fallaba al calcular los tamaños dinámicos de búfer debido a la



45

malinterpretación de un entero sin signo definido en su código de programa.

Peticiones codificadas de determinada manera permitían incluir comandos

del sistema en las posiciones que quedaban fuera del búfer, lo que permitía a

los hackers arrancar consolas remotas con permisos de administrador o crear

cuentas de usuario raíz en la máquina comprometida.

Los hackers más expertos pueden encontrar la forma de que una

aplicación ejecute comandos o código binario en un sistema sin necesidad

de provocar un desbordamiento de búfer, evitando así que la aplicación

aborte para llevar a cabo un ataque más silencioso. Estos ataques requieren

también de amplios conocimientos sobre el código fuente del software a

explotar. Un ejemplo es el Unicode exploit for Microsoft's IIS, que

permitía la navegación libre por la estructura de directorios de las máquinas

que incorporaban las primeras versiones de este servidor Web. La

vulnerabilidad consistía en que el módulo intérprete de las direcciones que

se solicitan desde el navegador, traducía la representación Unicode del

símbolo delimitador de directorio ( / ), permitiendo al hacker acceder a

cualquier fichero en el sistema.

La lógica de las aplicaciones Web dinámicas es muy propensa a fallo

frente a usuarios malintencionados. La comprobación de la entrada de datos

por parte de un programa para evitar la explotación de vulnerabilidades es

fundamental, y un ejemplo de esto es el popular ataque de inyección de

SQL. Este método consiste en la inserción de sentencias SQL en los campos

de entrada de un formulario Web. Las queries debidamente introducidas

pueden modificar la lógica del acceso a datos del programa, por ejemplo,

permitiendo al atacante saltarse la fase de registro o lanzar comandos al

sistema.



46

3.2.2.4. ACCESOS AUTORIZADOS

En la mayoría de los casos, la intención de un ataque es el control de

la máquina objetivo, el acceso a la información almacenada en ella, la

explotación de sus recursos computacionales, etc. El uso de permisos

legítimos de usuario es la forma más cómoda y fiable de llevar a cabo

ataques con éxito, pero con las debidas medidas de control, la identificación

de un usuario que realice alguna acción maliciosa de esta manera es

inmediata. Los propios empleados de una empresa, son en muchas

ocasiones la persona que está detrás del ataque a un recurso de la misma, ya

que disponen de una posición más ventajosa que la de un hacker externo de

cara a que de alguna manera "ya están dentro". Por otra parte, los empleados

que disfrutan de un acceso privilegiado a determinados recursos son en

ocasiones los culpables de la publicación de contraseñas o de la

desprotección de los sistemas bajo su responsabilidad, lo que suele ser

aprovechado por terceros malintencionados para perpetrar ataques pudiendo

inculpar al encargado.

La adquisición de los permisos de un usuario autorizado para

acceder a un recurso clave de la organización puede ser tan sencillo como

obtener su contraseña de autenticación en el sistema. Una acción llevada a

cabo utilizando los credenciales de la víctima exime al que se hace pasar por

ella de cualquier acusación. El robo de contraseñas y certificados

digitales se da con mucha frecuencia en entornos de confianza y exceso de

ingenuidad por parte de los hombres que están detrás de las máquinas. Los

sistemas de autenticación débiles son una fuente de problemas de este tipo;

si es sencillo obtener permiso de acceso a un recurso por parte de una

persona autorizada, también lo será para una que no lo es, por lo que una

buena gestión de contraseñas es fundamental. Se recomienda a los

administradores de red establecer contraseñas de usuario alfanuméricas, no



47

estándar y no de diccionario que cambien periódicamente en todos los

sistemas de una organización. El espionaje de las comunicaciones en una

red mediante herramientas sniffers es una sencilla manera de hacerse con

contraseñas de usuario aprovechando procesos no cifrados de autenticación

remota. El control de las aplicaciones que los empleados tienen instaladas

en sus terminales y la adecuada configuración de red que impide estas

actividades es fundamental para evitar una situación comprometida.

Las aplicaciones Web dinámicas generalmente usan cookies para

mantener el estado de una comunicación entre el cliente y el servidor. Las

cookies son ficheros ligeros que se instalan en la máquina del cliente, con su

permiso, y que almacenan, entre otras cosas, información de autenticación

de usuario. Aprovechando esto, existe una forma de escalada de privilegios

que los hackers llevan a cabo mediante una sencilla técnica de engaño

denominada cross-site scripting (XSS) [NORT01]. Consiste en presentar al

usuario una ventana que le anime a hacer clic en un enlace malicioso

haciéndole creer que se trata de una navegación normal y corriente. El

objetivo de que el usuario haga esto es el de obtener su "permiso" para

transferir sus cookies al atacante, que una vez las tenga en su poder podrá

utilizar para acceder a otros sistemas y servicios con los mismos

credenciales de la víctima. Debido a la inmadurez de muchos usuarios de

Internet y a la navegación por sitios poco fiables, estos ataques tienen una

alarmante tasa de éxito y se presentan con mucha frecuencia.

La ingenuidad y el exceso de confianza por parte de los usuarios es

lo que permite, según la misma filosofía de los ataques XSS, la proliferación

de virus y troyanos y su entrada en el sistema con facilidad. Un usuario que

permite la instalación de un programa malicioso en su máquina (tanto

porque haya sido engañado como de forma inconsciente) está dando

automáticamente a éste todos sus permisos. La actividad de un virus o un



48

troyano suele ser detectada por un NIDS si genera tráfico anormal de red o

por un NNIDS si se ejecuta en local. Los programas de este tipo que son

más interesantes a la hora de acceder a los recursos de una máquina son los

troyanos de control remoto, que instalados en un host objetivo, mantienen

abierto un puerto de comunicaciones directo con el hacker. Estos troyanos

pueden ser usados para llevar a cabo innumerables tipos de ataques, desde

escaneos de puertos y negaciones de servicio hasta el envío de información

local al exterior. Un ejemplo popular es el troyano Back Orifice, que

encripta la comunicación con el atacante remoto y por ello en un principio

fue indetectable por los IDS del momento. Otro ejemplo clásico de troyano

es el Loki Trojan [KOZI03], que basa su interactuación con el host remoto

del hacker en comunicaciones sobre el protocolo ICMP, que generalmente

no se considera sospechoso y los administradores de red suelen permitir que

pase a través del Firewall. Este es un típico caso de acceso autorizado, tanto

por parte del usuario, que acepta la instalación del troyano (generalmente de

forma inconsciente), como por parte del administrador, que está autorizando

el tráfico ICMP sin considerar esta situación.



49

3.3. MODELOS DISTRIBUIDOS

A continuación, se dedicarán unos cuantos apartados a la introducción 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 día el modelo de referencia y más

difundido de comunicación entre aplicaciones software distribuidas. Este modelo

está basado en una distinción rígida de roles entre nodos cliente (solicitantes de

recursos) y nodos servidor (proveedores de recursos). Los nodos servidor

proveen los servicios, es decir, las capacidades del sistema distribuido, pero no

son capaces de tomar ninguna iniciativa (son de carácter reactivo). Los nodos

cliente, por el contrario, representan la iniciativa del sistema: acceden y usan los

servicios según las necesidades del cliente aunque no proporcionan ninguna

funcionalidad compleja.

Los clientes pueden aparecer y desaparecer en cualquier momento,

disponiendo de direcciones dinámicas mientras que los servidores al tener que

garantizar un mínimo de estabilidad, suelen utilizar una dirección estática bien

conocida.

Los clientes se comunican con los servidores, pero no pueden ni

necesitan comunicarse con otros clientes. Del otro lado, un servidor no puede

comunicarse con sus clientes hasta que ellos tomen la iniciativa y decidan

establecer una sesión de comunicación con el servidor.

Internet es el típico ejemplo de aplicación basada en el modelo cliente-

servidor. Los servidores son los sitios o portales que proporcionan la lógica de



50

aplicación y recursos de información. 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 información

solicitada.

Las aplicaciones distribuidas existentes no siempre se adaptan a este

modelo. Por ejemplo, una simple aplicación de "chat", un sistema distribuido de

compartición de archivos o un juego multijugador, requiere que los nodos

activos en los terminales de usuario sean capaces de comunicarse unos con otros.

Aunque estos ejemplos puedan implementarse en una arquitectura cliente-

servidor pura (cosa que en muchas ocasiones se hace así), se perdería la

flexibilidad y escalabilidad que aportan los nodos cliente autónomos. En el

momento en que los nodos cliente se comunican directamente entre sí,

responden a peticiones de recursos e incorporan lógica de negocio, un servidor

físico deja de ser necesario ya que su funcionalidad se ha repartido entre los

demás elementos de la arquitectura.

Las redes de ordenadores con funciones cliente-servidor se disponen en

una topología en estrella de servicios centralizados como se puede observar en la

figura 8 [DIAZ05]:



51

Fig. 8: Arquitectura Cliente-Servidor.



52

MODELO PEER-TO-PEER (P2P)

El modelo peer-to-peer se caracteriza por no hacer distinción de roles

entre cada nodo del sistema. Cada uno de los elementos que componen el

modelo puede iniciar una comunicación, siendo origen o destinatario de una

petición y pesentando o devolviendo la información solicitada. La lógica de la

aplicación no está concentrada en un sólo sitio sino que se encuentra distribuida

entre los diferentes nodos de la red; cada nodo es capaz de descubrir a los demás

(no tienen por qué disponer de direcciones bien conocidas) y pueden ingresar o

abandonar la red en cualquier momento.

La diferencia fundamental entre el modelo cliente-servidor y el peer-to-

peer está en la forma en que los nodos se conocen entre sí. En un sistema cliente-

servidor, los clientes deben limitarse a conocer las direcciones estáticas de los

servidores, ya que no necesitan comunicarse con los otros clientes ni tener

conocimiento de su estado. En un sistema P2P, se debe contar con servicios que

permitan a los diferentes participantes entrar o salir de la red en cualquier

momento así como incluir procedimientos de búsqueda de recursos y

descubrimiento de nodos. Estos mecanismos son generalmente conocidos como

servicios de páginas blancas (descubrimiento de participantes) y páginas

amarillas (búsqueda de recursos y servicios provistos por un participante

desconocido).

Una red P2P pura está absolutamente descentralizada y los participantes

son completamente autónomos. La ausencia de un nodo de referencia hace muy

difícil mantener la coherencia del sistema y el descubrimiento de participantes.

Los beneficios de la escalabilidad y la flexibilidad de la red tienen como coste

un mayor ancho de banda requerido y una complejidad de arquitectura de

comunicaciones que crece exponencialmente con el número de nodos

conectados. Del mismo modo, la autonomía de cada nodo a la hora de conectarse



53

y desconectarse de la red implica un sistema de seguridad y autenticación no

centralizado y por tanto potencialmente inseguro.

Las redes de ordenadores con funciones peer-to-peer puras se disponen

en una topología punto a punto entre todos los nodos como se puede observar en

la figura 9 [DIAZ05]:

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 híbrido. Las arquitecturas P2P

híbridas están basadas en un nodo especial que proporciona los servicios de

búsqueda de recursos y descubrimiento de participantes de forma centralizada.

Este participante está exclusivamente dedicado al control del estado de la red,

manteniendo un índice actualizado en todo momento de nodos activos (páginas

blancas) y servicios disponibles (páginas amarillas) que puede ser consultado

centralizadamente por los demás participantes. Este tipo de redes generan menos



54

tráfico y son más seguras, ya que la entrada a formar parte de la red por parte de

un nodo requiere su registro y autenticación en el nodo central. Por otra parte el

funcionamiento correcto del sistema requiere la disponibilidad del nodo central,

convirtiéndose éste en un punto crítico de fallo y ataques.

Las redes de ordenadores con funciones peer-to-peer híbridas se disponen

en una topología punto a punto entre todos los nodos y en estrella respecto al

nodo central, como se puede observar en la figura 10 [DIAZ09]:

Fig. 10: Arquitectura P2P híbrida.

El modelo peer-to-peer es el más adecuado para implantar un sistema de

agentes inteligentes .



55

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 abstracción

de la entidad agente: componente software autónomo, proactivo y social

[GARA04]:

o autónomo: un agente tiene control de sus propias acciones; desde el

punto de vista del sistema local en que se ejecutan tienen su propio

hilo de ejecución y dentro de su nivel de conocimiento es capaz de

tomar decisiones inteligentes según su estado.

o proactivo: un agente no sólo responde a eventos externos (acciones

de usuario o llamadas remotas); un agente posee un comportamiento

propio orientado a un objetivo, siendo capaz de tomar iniciativas.

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á

diseñado.

Un sistema distribuido basado en agentes inteligentes es intrínsecamente

peer-to-peer: cada agente es un participante que necesita comunicarse con otros

agentes al tiempo que es capaz de proveer de información y servicios al resto de

participantes. El modelo de comunicación es muy importante en un sistema

basado en agentes y está basado en las siguientes premisas [BELL03]:

o los agentes son entidades activas y desacopladas: la comunicación

entre agentes es de tipo asíncrono, es decir, el agente que envía el

mensaje y el destinatario del mismo no tienen porqué estar

disponibles al mismo tiempo. Una vez un participante envía un

mensaje a otro, el primero no se queda a la espera de la respuesta del



56

segundo, sino que sigue funcionando para evaluar la contestación en

el momento en que llegue. Esto permite al receptor seleccionar los

mensajes a servir según sus propias prioridades y evita que el emisor

se quede bloqueado a la espera del procesado de la petición y

respuesta por parte del otro participante. De esta manera se evita la

dependencia funcional entre el emisor y el receptor, propensa a dar

problemas cuando uno de los dos extremos falla en mitad de una

comunicación.

o los agentes realizan acciones: la comunicación con otros agentes es

una más de las acciones que realizan los agentes inteligentes y por

tanto es tratada al mismo nivel. De esta manera las acciones lógicas y

las acciones de comunicación no interfieren entre sí y pueden ser

planificables sobre el mismo hilo de ejecución.

o la comunicación tiene significado semántico: un agente debe ser

capaz de comprender el mensaje de una comunicación y el

significado de aquello que el emisor solicita. En un sistema de

agentes inteligentes las comunicaciones no se limitan a llamadas

remotas a servicios del destinatario, sino que un mensaje puede

indicar a aquel que lo recibe desde un cambio de estado hasta la

petición de una operación compleja en la que se puedan ver

involucrados otros agentes. Todo esto significa la necesidad de

implantar un protocolo semántico de comunicación estandarizado.

En 1996, TILAB (Telecom Italian LABoratories) propuso la creación de

la FIPA (Foundation for Intelligent Physical Agents), organización de empresas

y grupos sin ánimo de lucro cuyo objetivo era el desarrollo de especificaciones

estándar para la tecnología de agentes. TILAB y en particular el equipo JADE,



57

lideraron esta iniciativa editando las primeras especificaciones del que más tarde

sería el estándar FIPA (2002). Este estándar se centra en la interoperabilidad del

sistema de agentes inteligentes definiendo bien el comportamiento externo de los

componentes del sistema y dejando abiertos los detalles de la implementación

interna de la lógica de negocio. El estándar FIPA es fiel al paradigma de agentes

inteligentes y define el modelo de referencia de la plataforma básica de agentes y

los servicios básicos que debe garantizar. El conjunto de servicios básicos y sus

interfaces estándar son todo lo que una sociedad de agentes necesita para existir,

colaborar y ser administrada. Los servicios que el estándar FIPA determina

como necesarios son [GARA04]:

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 páginas blancas: Se debe disponer de un procedimiento

común para todos los agentes de la plataforma que permita

referenciar un agente remoto inequívocamente.

o Servicio de páginas amarillas: Se debe disponer de un procedimiento

común para todos los agentes de la plataforma que permita

referenciar un servicio remoto inequívocamente sea cual sea el agente

que lo proporcione.

o Sistema de mensajería: La comunicación asíncrona entre agentes

debe realizarse mediante un sistema de mensajería estándar, flexible

y adaptable a cualquier lógica de negocio.

Debido al interés en el aspecto social de los agentes y sus necesidades de

comunicación con otros agentes, el capítulo Agent Comunication Language

(ACL) es uno de los más importantes del estándar FIPA.



58

3.3.3. MIDDLEWARE

Se denomina middleware al conjunto de librerías de medio-alto nivel que

proveen de servicios genéricos para los diferentes tipos de aplicaciones

distribuidas que las implementan haciendo su desarrollo más sencillo, y el

producto software resultante más eficiente, escalable y mantenible. Aunque no

se trata propiamente de un modelo de arquitectura distribuida, forma parte de

cualquier diseño de una aplicación de este tipo de arquitecturas.

Servicios como comunicación, acceso a datos, cifrado o control de

recursos son ejemplos típicos que aporta un Sistema Operativo local.

Independizando estos servicios del entorno local e integrándolos en un paquete

reutilizable, se confecciona una capa horizontal que permite dar soporte a las

aplicaciones distribuidas que necesiten estos servicios comunes.

Fig. 11: Capas horizontales y verticales en sistema local.

middleware

SO local + HW

Aplicaciones

locales

Aplicaciones

distribuidas



59

3.4. TECNOLOGÍA JAVA JADE

Llegados a ese punto, se profundizará en el modelo de agentes inteligentes

JADE, presentando las particularidades de esta tecnología, que ha sido preciso

aprender a manejar para el desarrollo del aplicativo IDSAI.

JADE (Java Agent DEvelopment Framework) es el middleware diseñado

por TILAB que proporciona tanto un entorno de desarrollo como un entorno de

ejecución para la realización y mantenimiento de de aplicaciones distribuidas

multiagente basadas en la arquitectura de comunicación peer-to-peer. La

inteligencia, la iniciativa, la información, los recursos y el control pueden

distribuirse completamente entre los terminales móviles o los equipos informáticos

que conformen la red. El entorno evoluciona dinámicamente con los participantes o

agentes, que aparecen y desaparecen del sistema de acuerdo con las necesidades y

requisitos de la aplicación. La comunicación entre los participantes, ya sea en una

red cableada o inalámbrica es completamente simétrica asumiendo cada par de

implicados el rol de origen y destinatario según sea la situación [BELL03].

JADE está completamente desarrollado en tecnología Java y proporciona

una serie de herramientas que permiten al desarrollador controlar y depurar a los

agentes en tiempo real. Está basado en los siguientes principios [BELL03]:

o Interoperabilidad: JADE cumple con las especificaciones FIPA. Esto

garantiza que los agentes JADE pueden interactuar con otros agentes

que asuman el mismo estándar aunque no estén desarrollados

necesariamente con JADE.

o Uniformidad y portabilidad: JADE provee un juego de APIs

independientes de la infraestructura de red y de la versión de la máquina

virtual Java sobre la que se ejecuten.



60

o Intuitivo: La complejidad del middleware se encuentra encapsulada tras

un simple e intuitivo interfaz de APIs.

En los siguientes apartados se detallan más aspectos de la tecnología JADE,

dentro de los modelos de arquitectura y funcional.



61

3.4.1. MODELO DE ARQUITECTURA

JADE incluye tanto las librerías necesarias para desarrollar aplicaciones

multiagente como el entorno de ejecución que provee los servicios básicos sobre

el que arrancar los agentes. Cada instancia del entorno de ejecución JADE se

denomina contenedor y se alberga en un host de la red concreto. El conjunto de

todos los contenedores activos en un sistema multiagente se denomina

plataforma y proporciona una capa homogénea que oculta a los agentes y al

desarrollador la complejidad de las capas inferiores (Hardware,

Comunicaciones, Sistema Operativo y versión de la JVM).

En cada plataforma debe existir un contenedor particular denominado

contenedor principal. Este contenedor alberga dos agentes especiales, además de

los que se quieran arrancar en él [ARAN06]:

o AMS (Agent Management System): Proporciona el servicio de

páginas blancas. Gracias a ello permite la búsqueda y reconocimiento

entre agentes. En él se registra y se da de baja cada agente que se

incorpora o que abandona la plataforma. El agente AMS garantiza

que cada agente activo disponga de un nombre único dentro de la

plataforma y proporciona la interfaz para arrancar y matar agentes en

contenedores remotos. Representa la autoridad de la plataforma.

o DF (Directory Facilitator): Proporciona el servicio de páginas

amarillas. Gracias a ello permite la búsqueda de agentes que provean

de determinados servicios para lograr sus objetivos. No es necesario

que los agentes de la plataforma registren sus funcionalidades en este

agente, pero en ese caso el servicio de páginas amarillas no

funcionará adecuadamente.



62

El contenedor principal se arranca, como cualquier otro contenedor, en

un host en particular. Por las funcionalidades avanzadas que incorporan los

agentes especiales antes descritos, el host que alberga el contenedor principal

resulta ser un nodo clave de la plataforma, al que los demás nodos acuden para

buscar otros nodos o servicios. Es por esta razón por la que podemos hablar de

una arquitectura peer-to-peer híbrida cuando describimos la arquitectura de red

de un sistema multiagente JADE.

Fig. 12: Esquema de distribución de agentes en contenedores de una plataforma JADE.

RED

Plataforma 1

Contenedor Principal Contenedor1 Contenedor2

A1 AMS DF A2 A3 A4



63

3.4.2. MODELO FUNCIONAL

Desde el punto de vista funcional, JADE proporciona los servicios

básicos necesarios para dar soporte a aplicaciones distribuidas peer-to-peer tanto

en entornos fijos como en móviles.

JADE permite a cada agente el descubrimiento dinámico de otros

agentes y de sus funcionalidades, gracias a los servicios de páginas blancas y

páginas amarillas incorporados en los agentes dedicados a tal efecto (AMS y

DF) [GARA04].

La comunicación entre agentes se realiza exclusivamente a través de

mensajes asíncronos por ser el sistema más adecuado para los sistemas

distribuidos con bajo acoplamiento. La estructura de los mensajes cumple con el

lenguaje estándar ACL definido por la FIPA [GARA04]:

o sender: Identificador del agente remitente del mensaje.

o receivers: Lista de identificadores de agentes destinatarios del

mensaje.

o performative: Intención de la comunicación. El estándar ACL fija

hasta 22 tipos de performative predefinidos: INFORM (comunicar un

suceso), REQUEST (solicitar un recurso o acción), QUERY-IF

(preguntar por una condición), PROPOSE (establecer una

comunicación compleja o negociación)...

o content: Contenido del mensaje.

o language: Tipo de sintaxis utilizada en el content.

o ontology: Diccionario de símbolos utilizados en el content.



64

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 envío y recepción de mensajes.

Cada agente es responsable del control de su ciclo de vida estandarizado

por la FIPA [BELL05]:

Fig. 13: Ciclo de vida de agente definido por la FIPA.

Initiated

Active

Transit Waiting

Suspended

Create

Destroy Invoke

Move

Execute

Suspend

Wait

Resume

Wake Up



65

Los diferentes estados del ciclo de vida de un agente JADE son los

siguientes:

o INITIATED: El agente se ha creado pero aún 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 unívoco y puede acceder a toda la funcionalidad que

proporciona la infraestructura JADE.

o SUSPENDED: El agente está detenido. Su hilo de ejecución está

suspendido y no ejecuta ningún comportamiento.

o WAITING: El agente está bloqueado esperando algún evento

concreto. Su hilo de ejecución está dormido y despertará en cuanto se

de el evento.

o TRANSIT: El agente móvil está migrando a una nueva ubicación (a

otro contenedor en el mismo u otro host). Los mensajes que lleguen a

su dirección se redireccionarán a su nueva localización.

Los cambios de estado se deben a la invocación de las funciones del

agente que llevan a cabo explícitamente los cambios de estado o a condiciones

extraordinarias y excepciones que pueden implicar un cambio de estado

inesperado.

La orientación de los agentes JADE a la consecución de objetivos

concretos se implementa a través de los denominados comportamientos. Varios

comportamientos arrancados por un agente se ejecutan de forma concurrente

aunque lo hacen sobre el mismo hilo de ejecución. Esto evita problemas de

sincronización entre comportamientos que acceden a recursos comunes. Un



66

comportamiento puede interrumpirse en cualquier momento y reanudar su

ejecución en el punto en que se dejó. Esto favorece la movilidad de agentes entre

contenedores remotos.

Algunos de los comportamientos básicos propuestos por la distribución

básica de JADE son los siguientes [BELL05]:

o OneShotBehaviour: Comportamiento cuyo algoritmo se ejecuta una

sola vez.

o CyclicBehaviour: Comportamiento cuyo algoritmo se ejecuta de

forma cíclica; una vez que termina, vuelve a comenzar.

o CompositeBehaviour: Comportamiento que se compone de diferentes

sub-comportamientos que se pueden ejecutar siguiendo diferentes

políticas de planificación: 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

periódicamente según un tiempo especificado desde su arranque.

Como se detalló en el apartado 3.3.2: Modelo peer-to-peer, la propiedad

de los participantes de una red de este tipo de poder ingresar y abandonar el

sistema de forma autónoma y sin un control centralizado, es potencialmente

peligrosa. En JADE, la existencia de un nodo central (agente AMS) que

mantiene un registro de los agentes vivos en el sistema y garantiza el carácter

unívoco de sus identificadores permite la incorporación de funciones de

seguridad de gran interés. JADE proporciona mecanismos de autenticación y

verificación de permisos asignados a participantes que entren a formar parte de



67

una arquitectura multiagente. El sistema de intercambio de mensajes entre

agentes JADE implementa sistemas de verificación y autenticación del remitente

si se estima necesario en el lado del destinatario.

Un agente JADE puede implementar tantos comportamientos como sean

necesarios para llevar a cabo las tareas para las cuales ha sido diseñado. Esto es

muy cómodo a la hora de ampliar la funcionalidad de un participante

permitiéndole añadir tareas en paralelo sin incrementar excesivamente su

consumo de recursos. La sencillez del proceso de incorporación de nuevos

agentes a la plataforma en contenedores remotos hace de cualquier proyecto

desarrollado sobre JADE un sistema escalable y fiable, ya que se simplifica

considerablemente el arranque inmediato de agentes de backup o incluso

contenedores enteros en caso de fallo de los principales [BELL03].

En entornos móviles, JADE asegura su eficacia con sus servicios de

migración y movilidad. Un agente JADE puede suspender su ejecución en

cualquier momento, migrar a un contenedor ubicado en un host diferente sin

necesidad de instalar el código del agente en el sitio remoto y recuperar su

ejecución en el punto en el que fue interrumpida. Esta funcionalidad permite

realizar un balanceo de carga entre los equipos que soportan el sistema

multiagente en tiempo de ejecución sin significar el más mínimo impacto en la

aplicación [BELL03].

Por último, JADE proporciona un juego de herramientas gráficas de

soporte de gran interés que permiten la monitorización en tiempo de ejecución

del estado de la plataforma en todo momento. Con estas herramientas, es posible

el control remoto de los agentes, la emulación de conversaciones, la

visualización de las comunicaciones entre agentes en vivo y la comprobación del

estado de los agentes y su ciclo de vida. La herramienta más interesante en este



68

aspecto es el agente RMA (Remote Management Agent), cuya interfaz gráfica se

muestra a continuación [ARAN06]:

Fig. 14: Interfaz gráfica del agente RMA.

Sólo puede existir un agente RMA por contenedor aunque puede haber

varios por plataforma. La interfaz gráfica del agente RMA permite las siguientes

acciones de monitorización y control de los agentes del sistema:

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 ejecución de un agente (incluido él mismo).



69

o Terminar la ejecución de todos los agentes de un contenedor.

o Terminar la ejecución de la plataforma en la que se encuentra.

o Arrancar un nuevo agente.

o Detener la ejecución de un agente (suspenderlo).

o Recuperar la ejecución de agentes suspendidos, devolviéndolos al

estado activo.

o Enviar un mensaje ACL a los agentes seleccionados. Una interfaz

gráfica 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 fácilmente interactuar con otros agentes y

proporciona un interfaz gráfico que permite construir mensajes ACL, enviarlos,

almacenarlos y verlos en detalle. Este agente puede arrancarse desde el interfaz

RMA.

La visualización en tiempo real de las comunicaciones que se dan entre

agentes de la plataforma es posible gracias a otro de los agentes de

monitorización que proporciona JADE. El agente Sniffer proporciona una

interfaz gráfica intuitiva que permite ver el estado de las comunicaciones de los

agentes deseados [ARAN06]:



70

Fig. 15: Interfaz gráfica del agente Sniffer.

Los mensajes esquematizados en la interfaz se pueden consultar haciendo

clic sobre ellos para ver su contenido en detalle:



71

Fig. 16: Detalles de la captura de un mensaje ACL.



72

3.5. SNORT

El proyecto IDSAI se construye alrededor de Snort, el Sistema de Detección

de Intrusos más extendido en la actualidad. Este NIDS, de libre distribución ha ido

ganando adeptos con el paso del tiempo gracias a su capacidad de crecimiento y

optimización, que lo convierten en uno de los IDS's más rápidos 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 detección de intrusos que es en la actualidad [KOZI03].

Snort utiliza una interfaz de captura basada en libpcap, librería estándar de

libre distribución disponible para multitud de plataformas, y mantiene su condición

de software libre gracias a la colaboración de la comunidad de usuarios que día a

día incorporan nuevas funcionalidades y juegos de reglas que ponen a disposición

del público sin afán de lucro. La extensa documentación sobre este producto y la

sencillez del diseño y distribución de reglas hacen que la comunidad de usuarios de

Snort pueda tener su IDS actualizado en todo momento, teniendo a su disposición la

mayor colección de patrones de ataques conocidos de todos los IDS.

Snort presume de un diseño óptimo, tanto en tamaño, ya que apenas ocupa

unos pocos megabytes de espacio en disco, como en consumo de recursos, lo que le

permite instalarse en máquinas viejas sin problema. Snort es capaz de monitorizar

la información almacenada en todos los paquetes de una conexión saturada de hasta

100 Mbps con una configuración estándar y empieza a perder eficacia a partir de

los 200 Mbps hasta niveles de tráfico superiores a 500 Mbps, que no los soporta.



73

3.5.1. MODOS DE FUNCIONAMIENTO

Snort puede funcionar de tres formas distintas, todas basadas en la

captura del tráfico de red mediante una interfaz promíscua [DIAZ05]:

o Modo Sniffer: Es el modo original y más básico de funcionamiento.

Basado en tcpdump, lee los paquetes de red y los muestra por

pantalla o los vuelca en un fichero.

o Modo Logging: Más interesante que el modo Sniffer a la hora de

analizar los resultados, guarda la información 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 función más importante de Snort es el modo de

funcionamiento como Sistema de Detección de Intrusos. El comando

de arranque de este modo incluye una referencia al fichero de

configuración de Snort, pieza clave de la optimización del IDS donde

se definen, entre otras cosas, las listas de reglas a incorporar en el

proceso de inferencia de los ataques. La construcción 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 instalación de

sensores en zonas estratégicas de la red es fundamental a la hora de

obtener el máximo rendimiento en esta modalidad, que es en la que

se basa el proyecto IDSAI para la capa de sensores.



74

3.5.2. COMPONENTES DE SNORT

La configuración de Snort para maximizar su rendimiento en una

instalación requiere de amplios conocimientos sobre su estructura interna y

componentes básicos. El siguiente esquema muestra el flujo de información por

cada una de las partes del programa, desde la captura de datos hasta la

presentación de las alertas [KOZI03]:

Fig. 17: Flujo de datos entre los módulos de Snort

En los siguientes apartados se comentará cada uno de los módulos

representados en la imagen.

Tráfico de red

Decodificador de paquetes

(Packet Decoder)

libpcap

Preprocesadores

(Preprocessors)

Motor de inferencias

(Detection Engine)

Módulos externos

(Output Plugins)

alertas



75

3.5.2.1. DESCODIFICADOR DE PAQUETES

Tan pronto como los paquetes son capturados por la librería libpcap,

Snort descodifica los paquetes según cada uno de los principales niveles de

comunicación: enlace, red y transporte. A medida que Snort va

almacenando en estructuras internas la información 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 tamaño 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 organización, por lo que se pueden

deshabilitar estas funciones en el propio fichero de configuración de Snort.



76

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 análisis 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 información recogida de

los paquetes de red en busca de detalles sospechosos y por tanto para

detectar los ataques que no tienen un patrón 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 detección de patrones.

Muchos ataques requieren del trabajo de más de un preprocesador

para ser detectados, por lo que la información de un paquete de red pasa por

todos ellos aunque ya se haya disparado una alerta relacionada con un tipo

de anomalía.

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 módulo de seguimiento de flujo (flow tracking

module) es el encargado de almacenar el estado de las

diferentes comunicaciones cuyos paquetes se han

interceptado. Las anomalías en la secuencia de paquetes y

demás irregularidades en el orden e interpretación de los

mensajes intercambiados por los equipos de la red son

detectadas por este preprocesador que disparará las alertas

correspondientes.



77

� frag2: El módulo de fragmentación es el arma de Snort frente

a los ataques basados en fragmentación. La fragmentación es

una característica 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 más pequeños. Esta acción propia de la capa de red

y llevada a cabo por routers y hosts intermedios, es la que

permite la comunicación entre diferentes tipos de redes y

protocolos, cada uno con su propia unidad máxima de

transmisión (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 petición de reenvío. La

fragmentación, que es una actividad automática y predecible

ha sido utilizada típicamente 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, llegarán a

su destino sin problemas y causarán el daño 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

técnica por lo que siempre se recomienda que este

preprocesador esté habilitado, ya que de lo contrario, Snort no

llevaría un control de los fragmentos de red, y no alertaría de

muchas intrusiones.



78

� stream4: El módulo 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 métodos de reconocimiento basados en

explotar las vulnerabilidades del protocolo TCP. Stream4

almacena el flujo de información de todas las comunicaciones

TCP establecidas en la red, y los evalúa en su conjunto para

alertar de la realización de ataques repartidos entre varios

paquetes, en los que individualmente es imposible reconocer

un patrón.

� stream4_reassemble: Este módulo 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 fragmentación en ataques

repartidos entre varios ataques con mayor precisión que

stream4.

� http_inspect: El módulo de inspección de tráfico HTTP es el

responsable de detectar irregularidades en el tráfico HTTP, y

de normalizarlo para que el motor de inferencias pueda

interpretarlo adecuadamente. La normalización consiste en

traducir el contenido extraño 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 tráfico de este tipo que requiere

descodificación. La codificación u ofuscación de tráfico

HTTP es un método que utilizan los hackers para evitar ser



79

descubiertos por un IDS en ataques a servidores Web

aprovechando alguno de sus exploits, que no se citan aquí por

ser muy específicos para cada versión de servidor.

� rpc_decode: Este módulo 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 análisis exhaustivo de

toda instrucción 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

módulo propio en este IDS ya que su idea original ha sido

adoptada por muchos otros troyanos más avanzados. BO

detecta el tráfico encriptado que intercambian las

instalaciones de este troyano

� telnet_decode, ftp_telnet, smtp...: Son otros módulos de

detección de contenidos maliciosos en los paquetes de tráfico

de estos protocolos. Normalizan el contenido de los paquetes

para evitar la ofuscación del código y alertan de las

irregularidades detectadas.

� sfportscan: Este módulo es el encargado de reconocer los

ataques de tipo escaneo de puertos analizando la frecuencia

con que se envían paquetes a diferentes puertos de los hosts

de la red. Es muy importante ajustar los parámetros de este



80

preprocesador para evitar el disparo de falsos positivos por

parte del IDS.

� arpspoof: Este módulo está diseñado para detectar tráfico

malicioso ARP. El protocolo ARP presente en las redes IP

para asociar la dirección MAC del interfaz de red con la

dirección 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

autenticación, por lo que si un atacante malicioso publica a

los demás hosts de su red una correspondencia MAC-IP falsa,

los demás lo tomarán como válido y se producirá una

suplantación de dirección 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 tráfico. La suplantación 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 negación de servicio, pero en

vez de a nivel de red, a nivel enlace.

� SPADE: Statistical Packet Anomaly Detection Engine. Este

módulo permite la detección de patrones de tráfico anómalos.

Básicamente implementa un tipo de inspección, basado en

análisis estadístico en vez de en comparación de patrones.

Para ello será necesario el entrenamiento del módulo en

condiciones "normales" de red para que en la práctica sea

capaz de detectar las diferencias. Este módulo no se ha



81

estudiado a fondo por salirse del alcance del proyecto y por

tanto no se ha implementado en la versión final de IDSAI.



82

3.5.2.3. MOTOR DE INFERENCIAS

El motor de inferencias de Snort es el componente encargado de

hacer pasar la información recogida de los paquetes capturados de la red tras

su normalización 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 incluyéndolas en el fichero de configuración de Snort.

Hay que ser muy selectivos a la hora de añadir reglas al motor de

inferencias, porque cuantas más patrones haya que comparar para cada

paquete, más retardo acumularán en el motor y si no se es capaz de atender

a todos los paquetes entrantes, se perderá información y podrán colarse

ataques.

Las reglas de Snort tienen dos partes: cabecera y opciones. En la

cabecera se especifican la acción, el protocolo, el origen y el destino

(IP/Máscara) y los puertos. En la parte de opciones, entre paréntesis, 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 líneas corresponden a un ejemplo de regla que

dispararía 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 paréntesis:

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:attempted-

user; sid:308; rev:8;)



83

3.5.2.4. MÓDULOS EXTERNOS

El código abierto de Snort proporciona una excelente base para

añadirle multitud de interfaces de salida por las que presentar los resultados

de su trabajo. Estos módulos se habilitan en el fichero de configuración de

Snort en su arranque. Entre los módulos de salida de Snort se encuentran los

siguientes [DIAZ05]:

� Alert syslog: Este módulo manda las alarmas al registro del

sistema. Este módulo permite que el usuario especifique la

prioridad de las alarmas y su categoría 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: Envía alarmas a través 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

estándar que permite la integración de Snort con otras

aplicaciones de forma universal. Tcpdump es la forma de

exportar información que optimiza la velocidad de Snort y se

puede combinar con los anteriores modos de alerta. CVS es

una forma de fichero fácilmente importable a cualquier base

de datos donde se pueden escoger los campos a registrar.

� Unified: Es el modo estándar de almacenamiento de Snort.

Separa los eventos en archivos de alerta, que almacenan los



84

datos de alto nivel y archivos de log, que almacenan el

paquete asociado a cada evento.

� SNMP: Este módulo permite a Snort interoperar con agentes

SNMP mediante el envío de traps. De este modo se integra

este servicio de gestión de redes con el IDS.

� Base de Datos: Este módulo permite exportar los datos de

Snort a una base de datos MySQL, PostgreSQL, Oracle o

UnixODBC. Es el módulo habilitado en el sistema IDSAI,

que vuelca su información en la base de datos estándar

MySQL snortdb. Ver diagrama del diseño de la base de datos

en el anexo 5: Esquema snortdb.



85

4. DESCRIPCIÓN FUNCIONAL

En este capítulo se aborda la descripción funcional del proyecto IDSAI, con la

enumeración y detalle de cada una de las clases que componen la aplicación, sus

dependencias y la forma en que interactúan entre sí.

La representación de las clases se ha realizado según el estándar UML 2.0,

obviándose los siguientes conceptos, en pos de la simplificación de la representación

(debido a su redundancia y funcionamiento autoexplicativo):

- Métodos constructores: Métodos propios de la clase cuya misión es la

instanciación de objetos de la clase. Su lógica de programación se basa en

inicializar los atributos básicos de la clase según los parámetros de llamada

del método. No hay un número fijo de constructores y difieren entre sí en la

forma de inicializar los atributos y en los parámetros con que se invocan.

- Métodos "getters": Métodos públicos de la clase (y por tanto invocables

desde otras clases) que permiten leer el valor de sus atributos privados. Cada

método "getter" está asociado a un único atributo". No tienen parámetros y

devuelven una variable del mismo tipo que el atributo asociado.

- Métodos "setters": Métodos públicos de la clase (y por tanto invocables

desde otras clases) que permiten escribir el valor de sus atributos privados.

Cada método "setter" está asociado a un único atributo. Tienen como único

parámetro una variable del mismo tipo que el atributo asociado.

En los siguientes apartados se describirán por este orden, las clases que forman

parte de cada uno de los paquetes en que se estructura el proyecto: dominio, agentes,

comportamientos, interfaz de usuario y clases de acceso a datos y de cálculo. Para una

visión global del diseño del sistema desde el punto de vista de la programación, ver el



86

anexo 2: Diagrama de clases, donde en gran formato se representan cada una de las

clases que se van a comentar.



87

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 información.

4.1.1. DIAGRAMA DE DOMINIO

El siguiente diagrama muestra la relación cardinal entre los conceptos de

seguridad que maneja el sistema y que se detallarán en el siguiente apartado:

Fig. 18: Diagrama de dominio.



88

4.1.2. DEFINICIÓN DE CONCEPTOS

4.1.2.1. EVENTO (ALERTA)

Unidad de resultado básica del IDS. Es el resultado de pasar un

paquete sospechoso de red por los preprocesadores y motor de inferencias

del Snort aplicándole la base de reglas del mismo.

La alerta básica de Snort aporta la siguiente información:

� CID (Component ID): Identificador unívoco de la instancia

de Snort que detectó la alerta.

� SID (Signature ID): Identificador unívoco de la firma

característica de la alerta detectada.

� RID (Revision ID): Revisión del juego de reglas que han

inferido la firma.

� Breve descripción de la firma característica 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.



89

� Demás datos del paquete: número de secuencia, flags, tamaño

de cabeceras TCP/IP/UDP...

� URL de referencia para consulta vía 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 -> 192.168.20.199:10005 TCP TTL:52 TOS:0x0

ID:28064 IpLen:20 DgmLen:40 **U*P**F Seq: 0x30710427 Ack: 0x0 Win:

0x400 TcpLen: 20 UrgPtr: 0x0

[Xref => http://www.whitehats.com/info/IDS30]

El análisis de las numerosas alertas que Snort genera en cortos

periodos de tiempo sobre redes comprometidas no requiere de toda la

información indicada anteriormente ya que en la mayoría 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 información básica de las alertas), representada en el

sistema como sigue:



90

Donde:

� sid: Identificador unívoco de la instancia de Snort que detectó

la alerta.

� cid: Identificador unívoco 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



91

4.1.2.2. SIGNATURE (FIRMA)

Tipo de comportamiento malicioso y conocido que se asocia a una

alerta. Cada firma se corresponde con un patrón 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 patrón, se contrasta con un

conjunto de paquetes de red semejantes delimitado por el tamaño del búfer

que Snort es capaz de almacenar para este fin.

Las signatures se clasifican en clases en base a la intención que el

evento que genera la alerta puede tener en el sistema. En función 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: Descripción breve de la firma

� prioridad: Valor de prioridad de la firma asignado por Snort.

Valorada de 1 (mín) a 3 (máx).

� clase: Tipo de firma según la intención del ataque.



92

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 (mínima separación

temporal entre eventos menor de 3 segundos). De esta forma se pretenden

agrupar los eventos que, compartiendo una misma intención (clase de

signature), corresponden a una acción común del atacante.

Clasificando de esta manera los eventos, se puede introducir el

concepto de compactación eventual, valor porcentual de gran interés que

indica la proporción de eventos con cid consecutivo del ataque respecto al

número total de eventos que lo componen. Este parámetro permite medir

fácilmente la exhaustividad del ataque. Si el valor es muy alto significaría

que Snort solamente detecta este tipo de actividad y por tanto está

experimentando una presencia clave en la red. Si por el contrario la

compactación 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 compactación alta, destaca la agresividad del

ataque y por tanto una mayor exposición de las vulnerabilidades del sistema.

El sistema IDSAI almacena la información relativa a ataques en la

siguiente estructura:



93

Donde:

� n_eventos: Número 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 más 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 dirección IP de

origen más 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 dirección IP de

destino más frecuente en el ataque y el valor porcentual de la


En futuros procesos será considerada la víctima en este

ataque.

� portorigmaxratio: Par de valores que indican el puerto de

origen más frecuente en el ataque y el valor porcentual de la



94


Pretende dar una pista sobre la aplicación utilizada para la

realización del ataque por parte del atacante.

� portdestmaxratio: Par de valores que indican el puerto de

destino más frecuente en el ataque y el valor porcentual de la


Pretende dar una pista sobre la vulnerabilidad del sistema

explotada para la realización del ataque por parte del atacante.



95

4.1.2.4. ANOMALíA

En este proyecto, el término de anomalía cobra una importancia

clave, al ser la estructura de información básica que integra los conceptos

descritos hasta el momento. Una anomalía es, por tanto, el conjunto de

ataques y eventos (agrupados en ataques) con firma común registrados en un

intervalo de tiempo concreto, al que llamaremos ventana.

El sistema IDSAI generará periódicamente, según el tamaño de

ventana fijado, tantas anomalías 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 aplicación, ya que con

valores muy pequeños (pocos segundos) apenas se detectan cambios entre

ventanas y la gran cantidad de información 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 rápido de toda la

información. La distribución inicial de la aplicación 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 más adecuado para la realización

de pruebas de carga y rendimiento del sistema.

El sistema maneja las anomalías utilizando la clase Anomalia, que se

describe como sigue:

Donde:



96

� ventana: Identificador de la ventana en la que se registra la

anomalía.

� tiempo: Fecha y hora de registro de la anomalía.

� signature: Firma (Signature) común de los eventos que

conforman la anomalía.

� eventos: Lista de eventos (Evento) que conforman la

anomalía.

� ataques: Lista de ataques (Ataque) en que se agrupan los

eventos de la anomalía.



97

4.1.2.5. ANÁLISIS

Los agentes del sistema IDSAI con una visión más general del

estado de la red no pueden trabajar a nivel de anomalías, ya que tendrían

que trabajar con una cantidad de información inmanejable. Resulta por tanto

necesario simplificar las listas contenidas en la estructura Anomalia a datos

estadísticos que permitan tener una visión más general de la situación.

Un análisis está asociado a una única anomalía y se representa en el

sistema mediante la clase Analisis:

Donde:

� ventana: Identificador de la ventana en la que se realiza el

análisis.

� tiempo: Fecha y hora de registro de la anomalía analizada.

� signature: Firma (Signature) de la anomalía analizada.

� prioridad: Prioridad de la anomalía analizada. Se obtiene en

función de la prioridad de la firma de la anomalía y el número



98

de eventos que la forman según un juego de reglas fijas

adaptadas a cada tipo de analista. Valorada de 1 (máx) a 6

(mín).

� compactacion: Compactación de la anomalía analizada. Se

obtiene en función del número y compactación eventual de

los ataques que forman la anomalía y de la diferencia entre la

desviación de tiempos en ataques y la media de éstos, según

un juego de reglas fijas adaptadas a cada tipo de analista.

Valorada de 1 (máx) a 12 (mín).

� media_eventosataques: Media estadística del número de

eventos en los ataques que forman la anomalía.

� stdev_eventosataques: Desviación típica del número de

eventos en los ataques que forman la anomalía.

� media_tiempoataques: Media estadística del tiempo de los

ataques que forman la anomalía.

� stdev_tiempoataques: Desviación típica del tiempo de los

ataques que forman la anomalía.

� iporigmaxratio: Par de valores que indican la dirección IP de

origen más frecuente en los ataques de la anomalía y el valor

porcentual de la cantidad de veces que se da en el conjunto.

Esta dirección IP será considerada en adelante como el

atacante de la anomalía.

� ipdestmaxratio: Par de valores que indican el puerto de

destino más frecuente en los ataques de la anomalía y el valor




99

Esta dirección IP será considerada en adelante como la

víctima de la anomalía.

� portorigmaxratio: Par de valores que indican el puerto de

origen más frecuente en los ataques de la anomalía y el valor


Este puerto dará en adelante pistas sobre la posible aplicación

utilizada para la realización de los ataques por parte del

atacante.

� portdestmaxratio: Par de valores que indican el puerto de

destino más frecuente en los ataques de la anomalía y el valor


Este puerto dará en adelante pistas sobre la vulnerabilidad

explotada del sistema de la víctima para la realización del

ataque.



100

4.1.2.6. ACUSACIÓN

Este concepto es necesario a la hora de relacionar todas las

anomalías con misma clase de firma detectadas en una ventana. Representa

simplemente la lista de firmas de las anomalías detectadas en la ventana

actual con clase, y dirección IP de origen y destino comunes.

Este concepto se modeliza en el proyecto IDSAI mediante la clase

Acusación como sigue:

Donde:

� prioridad: Prioridad de la anomalía correspondiente.

Equivalente a la del análisis.

� compactacion: Compactación de la anomalía analizada.

� signatures: Lista de estructuras (ParSig) que almacenan cada

una de las firmas (Signature) de la acusación y el par de

puertos origen y destino.

Como se puede observar, la información almacenada en la estructura

Acusación se encuentra incompleta al no indicarse dentro de ella las

direcciones IP origen y destino de cada anomalía. Por ello, Acusación es

una clase auxiliar fundamental en la clase Resumen, en la que sí que caben

conceptualmente los detalles no plasmados en esta clase.



101

4.1.2.7. RESUMEN

El carácter distribuido del sistema IDSAI requiere de una clase que

contenga la información suficiente y necesaria para que a partir de ella se

pueda tener una visión 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 anomalías relacionadas con ella. El resumen no solo se basa en los

análisis de la ventana actual para reflejar el estado de la red, sino que utiliza

para ello un histórico de los análisis de las últimas 4 ventanas y la actual. De

esta manera, las variaciones entre la situación de ventanas consecutivas no

varían bruscamente, evitándose situaciones confusas al tiempo que se

destaca la presencia de alertas críticas, que suelen darse aisladamente y de

esta forma se pueden comparar con la situación de la red en momentos

cercanos.

La clase Resumen queda representada por tanto de la siguiente

manera:

Donde:



102

� ventana: Identificador de la ventana en la que se realiza el

análisis.

� tiempo: Fecha y hora de registro de la anomalía analizada.

� fiabilidad: Fiabilidad o confianza en el agente que ha

registrado el conjunto de anomalías analizadas (valorada de 1

(mín) a 10 (máx)) determinada en el arranque de éste.

� analisisactuales: Lista de análisis (Analisis) de las anomalías

registradas en la ventana actual.

� clase: Tipo de firma según la intención del ataque, común a

todas las anomalías analizadas.

� prioridad: Borrosificación del valor medio de la prioridad de

los análisis resumidos según un controlador borroso fijo.

� compactación: Borrosificación del valor medio de la

compactación de los análisis resumidos según un controlador

borroso fijo.

� atacantes: Lista de direcciones IP de los atacantes de las

anomalías analizadas.

� victimas: Lista de direcciones IP de las víctimas de las

anomalías 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-víctima la lista de firmas (del mismo tipo de

clase) de las anomalías detectadas entre dichos hosts



103

especificando los puertos origen y destino correspondientes

para cada caso.

Un conjunto de resúmenes que engloben todas las clases de firma

que el sistema sea capaz de procesar, debería dar una visión completa del

estado de seguridad de la red a un agente de alto nivel.



104

4.1.2.8. DIAGNÓSTICO

Concepto típico de sistema experto que trata de englobar la

información recibida, y determinar la causa de los problemas detectados. En

el sistema IDSAI representa una descripción del estado de la red en la

ventana actual y una valoración de su situación en base al parámetro

criticidad.

La codificación de este concepto se hace mediante la clase

Diagnostico. Por cuestiones de coherencia y dado que es la estructura de

más alto nivel manejada por el sistema, además de los datos anteriores

también necesita almacenar información relevante sobre los resúmenes

(Resumen) que sirven de base para su elaboración:

Donde:

� ventana: Identificador de la ventana en la que se realizaron los

resúmenes que sirven de base para la elaboración del

diagnóstico (no se corresponde con el tiempo en que se

realiza el diagnóstico)

� tiempo: Fecha y hora de realización del diagnóstico.



105

� atacantes: Unión sin repetición de las listas de direcciones IP

de los atacantes de todos los resúmenes.

� victimas: Unión sin repetición de las listas de direcciones IP

de las victimas de todos los resúmenes.

� acusaciones: Unión acumulativa de las matrices de

acusaciones de todos los resúmenes.

� estado: Valor numérico que codifica la situación de la red

según el número de atacantes y víctimas en la ventana actual.

� atacanteprincipal: Dirección IP del atacante con más

presencia en la red en la ventana actual. En caso de ser un

estado con múltiples atacantes, esta variable almacenará aquel

que protagonice el mayor número de firmas entre las

acusaciones correspondientes a la ventana actual.

� victimaprincipal: Dirección IP de la víctima con más

presencia en la red en la ventana actual. En caso de ser un

estado con múltiples víctimas, esta variable almacenará

aquella que protagonice el mayor número 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 compactación de cada

resumen generado en la ventana actual según un conjunto de

reglas de inferencia borrosas fijas. Las inferencias borrosas

devueltas se desborrosifican por el método del centro de

gravedad. Valorada de 1 (máx) a 10 (mín).



106

4.2. AGENTES DEL SISTEMA

A continuación 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 omisión

en sus apartados correspondientes, heredan de la clase Agent cuyo esquema es el

siguiente:

Donde:

o setup(): Método que se dispara al arrancar el agente.

o takedown(): Método que se dispara al matar el agente.

Estos métodos son generalmente sobrescritos por los agentes hijos para

introducir su propia funcionalidad a los mismos (en la implementación de la clase

Agent, no hacen nada).



107

4.2.1. Agente RELOJ

4.2.1.1. DESCRIPCIÓN

El agente Reloj es el encargado de llevar la cuenta de ventanas de

análisis 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 instalación 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 parámetro:

� parámetro 1: número entero que indica el periodo de

sincronización de los agentes del sistema y por tanto el

tamaño de la ventana temporal en segundos.

Los detalles de los diferentes aspectos de esta clase se definen a

continuación.



108

4.2.1.2. ATRIBUTOS

Los atributos mantenidos por la clase AgenteReloj son los

siguientes:

� frame: Referencia a la interfaz gráfica 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. MÉTODOS

El método implementado en la clase AgenteReloj es el siguiente:

� setup(): Sobrescribe el método de la clase padre. Su algoritmo

es completamente lineal y consiste en los siguientes pasos:

1. Arrancar la interfaz gráfica 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 parámetro 1. Ver

apartado 4.3.4: Sincronizar.



109

4.2.2. Agente SENSOR


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

periódicamente. La repercusión en el rendimiento del sistema que implica

esta funcionalidad, ha supuesto que no se implante este proceso en la

versión final del sistema. En una instalación del sistema IDSAI, el número

de agentes Sensores que se pueden arrancar (de nombre libre) es ilimitado.

De hecho, es deseable arrancar más de una instancia de Snort en diferentes

lugares de la red, para poder recolectar información 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 Intérpretes 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 parámetros:



110

� parámetro 1: número que indica la interfaz de red del host que

aloja el agente de donde Snort recibirá la información de la

red. Si se desea que Snort trabaje sobre un fichero de captura

de red .pcap, el valor de este parámetro debe ser 0.

� parámetro 2: Sólo es necesario introducirlo si el valor del

primer parámetro es 0. Indica la ruta del fichero de captura de

red .pcap sobre el que trabajará Snort.


continuación.

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 configuración de Snort

C:\Snort\etc\IDSAI.conf previamente adaptado a la red en

cuestión.

� proceso: Referencia al proceso snort.exe arrancado por el

agente.



111

4.2.2.3. MÉTODOS

Los métodos implementados en la clase AgenteSensor son los

siguientes:

� setup(): Sobrescribe el método de la clase padre. El siguiente

diagrama, representa su algoritmo básico:

Fig. 19: Método setup() del agente Sensor.

INICIO

FIN

parámetro1 = 0 NO SI

Actualizar cmd con ruta de

fichero .pcap

Actualizar cmd con interfaz

de red

Arrancar proceso con

llamada cmd

Arrancar comportamiento

Limpiar BD



112

- Actualizar cmd con ruta del fichero .pcap: Actualizar

atributo cmd con la ruta del fichero .pcap pasada como

parámetro 2 en el arranque del agente.

- Actualizar cmd con interfaz de red: Actualizar atributo

cmd con la interfaz de red pasada como parámetro 1 en el

arranque del agente.

- Arrancar proceso con llamada cmd: Arrancar el proceso

snort.exe mediante una llamada en tiempo real al sistema

según lo establecido en el atributo cmd.

- Arrancar comportamiento Limpiar BD (no implantado por

cuestión de rendimiento): Arrancar el comportamiento

Limpiar BD. Ver apartado 4.3.5: Limpiar BD.

� takedown(): Sobrescribe el método 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.



113

4.2.3. Agente INTÉRPRETE


El agente Intérprete es el encargado de acceder periódicamente a la

base de datos en busca de Anomalías (Ver apartado 4.1.2.4: Anomalía) de

la clase de signature sobre la cual está especializado. Esta especialización se

consigue en el sistema a través de herencia, ya que todas las especialidades

de Intérprete tienen conceptos en común y conceptos que los diferencian. En

una instalación del sistema IDSAI, el número de agentes Intérpretes que se

pueden arrancar (de nombre libre) por cada Sensor es ilimitado. No

obstante, dos agentes Intérpretes del mismo tipo accediendo a los datos

recogidos por el mismo Sensor, son redundantes.

El agente Intérprete se representa en el sistema con la clase

AgenteInterprete que tiene la estructura siguiente:


continuación.

4.2.3.2. ATRIBUTOS

Los atributos mantenidos por la clase AgenteInterprete son los

siguientes:



114


apartado 4.4.3: Ventana Agente.


4.2.3.3. MÉTODOS

Los métodos implementados en la clase AgenteInterprete son los

siguientes:



pasos:

1. Deshabilitar la interfaz gráfica 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"



115

4.2.4. Agente INTÉRPRETE ATTEMPTED-ADMIN


El agente Intérprete Attempted-Admin es el Intérprete especializado

en la busca de anomalías (Ver apartado 4.1.2.4: Anomalía) de la clase de

signature attempted-admin.

El agente Intérprete 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 Intérprete Attempted-Admin debe arrancarse con el

siguiente parámetro:

� parámetro 1: número que indica la fiabilidad de la

información recogida en el host que aloja el agente de donde

Snort recibirá la información de la red.


continuación.

4.2.4.2. ATRIBUTOS

Ninguno relevante aparte de los heredados.



116

4.2.4.3. MÉTODOS

El método implementado en la clase

AgenteInterpreteAttemptedAdmin es el siguiente:




4.4.3: Ventana Agente.

2. Dar de alta el agente en el sistema, enviando un


siguiente forma:


- Content = "ALTA"

3. Arrancar el comportamiento Obtener Anomalías con

la especialidad "attempted-admin" y la fiabilidad

según el parámetro 1. Ver apartado 4.3.6: Obtener

Anomalías.



117

4.2.5. Agente INTÉRPRETE ATTEMPTED-DOS


El agente Intérprete Attempted-Dos es el Intérprete especializado en

la busca de anomalías (Ver apartado 4.1.2.4: Anomalía) de la clase de

signature attempted-dos.

El agente Intérprete Attempted-Dos es un agente Intérprete (hereda


AgenteInterpreteAttemptedDos que tiene la estructura siguiente:

El agente Intérprete Attempted-Dos debe arrancarse con el siguiente

parámetro:





continuación.

4.2.5.2. ATRIBUTOS




118

4.2.5.3. MÉTODOS

El método implementado en la clase AgenteInterpreteAttemptedDos

es el siguiente:







siguiente forma:


- Content = "ALTA"


la especialidad "attempted-dos" y la fiabilidad según

el parámetro 1. Ver apartado 4.3.6: Obtener

Anomalías.



119

4.2.6. Agente INTÉRPRETE ATTEMPTED-RECON


El agente Intérprete Attempted-Recon es el Intérprete especializado

en la busca de anomalías (Ver apartado 4.1.2.4: Anomalía) de la clase de

signature attempted-recon.

El agente Intérprete Attempted-Recon es un agente Intérprete

(hereda de AgenteInterprete) que se representa en el sistema con la clase

AgenteInterpreteAttemptedRecon que tiene la estructura siguiente:

El agente Intérprete Attempted-Recon debe arrancarse con el

siguiente parámetro:





continuación.

4.2.6.2. ATRIBUTOS




120

4.2.6.3. MÉTODOS


AgenteInterpreteAttemptedRecon es el siguiente:







siguiente forma:


- Content = "ALTA"


la especialidad "attempted-recon" y la fiabilidad según


Anomalías.



121

4.2.7. Agente INTÉRPRETE BAD-UNKNOWN


El agente Intérprete Bad-Unknown es el Intérprete especializado en


signature bad-unknown.

El agente Intérprete Bad-Unknown es un agente Intérprete (hereda


AgenteInterpreteBadUnknown que tiene la estructura siguiente:

El agente Intérprete Bad-Unknown debe arrancarse con el siguiente

parámetro:





continuación.

4.2.7.2. ATRIBUTOS




122

4.2.7.3. MÉTODOS

El método implementado en la clase AgenteInterpreteBadUnknown

es el siguiente:







siguiente forma:


- Content = "ALTA"


la especialidad "bad-unknown" y la fiabilidad según el

parámetro 1. Ver apartado 4.3.6: Obtener Anomalías.



123

4.2.8. Agente INTÉRPRETE OTROS


El agente Intérprete Otros es el Intérprete especializado en la busca

de anomalías (Ver apartado 4.1.2.4: Anomalía) de la clase de signatures en

las que no está especializado en particular ningún otro Intérprete en el

sistema IDSAI.

El agente Intérprete Otros es un agente Intérprete (hereda de

AgenteInterprete) que se representa en el sistema con la clase

AgenteInterpreteOtros que tiene la estructura siguiente:

El agente Intérprete Otros debe arrancarse con el siguiente

parámetro:





continuación.

4.2.8.2. ATRIBUTOS




124

4.2.8.3. MÉTODOS

El método implementado en la clase AgenteInterpreteOtros es el

siguiente:







siguiente forma:


- Content = "ALTA"


la especialidad "otros" y la fiabilidad según el

parámetro 1. Ver apartado 4.3.6: Obtener Anomalías.



125

4.2.9. Agente INTÉRPRETE UNKNOWN-CLASS


El agente Intérprete Unknown-Class es el Intérprete especializado en


signature Unknown-Class.

El agente Intérprete Unknown-Class es un agente Intérprete (hereda


AgenteInterpreteUnknownClass que tiene la estructura siguiente:

El agente Intérprete Unknown-Class debe arrancarse con el siguiente

parámetro:





continuación.

4.2.9.2. ATRIBUTOS




126

4.2.9.3. MÉTODOS

El método implementado en la clase AgenteInterpreteUnknownClass

es el siguiente:







siguiente forma:


- Content = "ALTA"


la especialidad "unknown-class" y la fiabilidad según


Anomalías.



127

4.2.10. Agente ANALISTA


El agente Analista es el encargado de extraer valores estadísticos del

conjunto de Anomalías recibidas del correspondiente agente Intérprete.

Estos datos permiten tener una visión más general acerca de la situación de

la red desde el punto de vista de la clase de signature sobre la cual está

especializado el agente. Esta especialización se representa en el sistema a

través de herencia tal y como se describirá en las siguientes subsecciones, ya

que todas las especialidades de Analista tienen conceptos en común y

conceptos que los diferencian. Se debe arrancar un agente Analista por cada

clase de Signature que se desee analizar en la instalación del sistema IDSAI

(de nombre "analista"+tipo).

El agente Analista se representa en el sistema con la clase

AgenteAnalista que tiene la estructura siguiente:


continuación.



128

4.2.10.2. ATRIBUTOS

Los atributos mantenidos por la clase AgenteAnalista son los

siguientes:


apartado 4.4.5: Ventana Agente Analista.

� analisis: Lista de Análisis realizados. Ver apartado 4.1.2.5:

Análisis.

� anomalias: Lista de Anomalías recibidas. Ver apartado

4.1.2.4: Anomalía.


4.2.10.3. MÉTODOS

Los métodos implementados en la clase AgenteAnalista son los

siguientes:



pasos:




siguiente forma:




129

- Content = "BAJA"



130

4.2.11. Agente ANALISTA ATTEMPTED-ADMIN


El agente Analista Attempted-Admin es el Analista especializado en

la realización de Análisis (Ver apartado 4.1.2.5: Análisis) de las Anomalías

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:


continuación.

4.2.11.2. ATRIBUTOS


4.2.11.3. MÉTODOS


AgenteAnalistaAttemptedAdmin es el siguiente:



131




4.4.5: Ventana Agente Analista.



siguiente forma:


- Content = "ALTA"

3. Arrancar el comportamiento Analizar Anomalías

Attempted-Admin. Ver apartado 4.3.8: Analizar

Anomalías Attempted-Admin.



132

4.2.12. Agente ANALISTA ATTEMPTED-DOS


El agente Analista Attempted-Dos es el Analista especializado en la

realización de Análisis (Ver apartado 4.1.2.5: Análisis) de las Anomalías 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:


continuación.

4.2.12.2. ATRIBUTOS


4.2.12.3. MÉTODOS

El método implementado en la clase AgenteAnalistaAttemptedDos

es el siguiente:



133







siguiente forma:


- Content = "ALTA"


Attempted-Dos. Ver apartado 4.3.9: Analizar

Anomalías Attempted-Dos.



134

4.2.13. Agente ANALISTA ATTEMPTED-RECON


El agente Analista Attempted-Recon es el Analista especializado en

la realización de Análisis (Ver apartado 4.1.2.5: Análisis) de las Anomalías

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:


continuación.

4.2.13.2. ATRIBUTOS


4.2.13.3. MÉTODOS


AgenteAnalistaAttemptedRecon es el siguiente:



135







siguiente forma:


- Content = "ALTA"


Attempted-Recon. Ver apartado 4.3.10: Analizar

Anomalías Attempted-Recon.



136

4.2.14. Agente ANALISTA BAD-UNKNOWN


El agente Analista Bad-Unknown es el Analista especializado en la


clase bad-unknown.

El agente Analista Bad-Unknown es un agente Analista (hereda de


AgenteAnalistaBadUnknown que tiene la estructura siguiente:


continuación.

4.2.14.2. ATRIBUTOS


4.2.14.3. MÉTODOS

El método implementado en la clase AgenteAnalistaBadUnknown es

el siguiente:



137




4.4.5: Ventana Agente Analista



siguiente forma:


- Content = "ALTA"

3. Arrancar el comportamiento Analizar Anomalías Bad-

Unknown. Ver apartado 4.3.11: Analizar Anomalías

Bad-Unknown.



138

4.2.15. Agente ANALISTA OTROS


El agente Analista Otros es el Analista especializado en la


la clase de signatures en las que no está especializado en particular ningún

otro Analista en el sistema IDSAI.

El agente Analista Otros es un agente Analista (hereda de


AgenteAnalistaOtros que tiene la estructura siguiente:


continuación.

4.2.15.2. ATRIBUTOS


4.2.15.3. MÉTODOS

El método implementado en la clase AgenteAnalistaOtros es el

siguiente:



139







siguiente forma:


- Content = "ALTA"


Otros. Ver apartado 4.3.12: Analizar Anomalías

Otros.



140

4.2.16. Agente ANALISTA UNKNOWN-CLASS


El agente Analista Unknown-Class es el Analista especializado en la


clase unknown-class.

El agente Analista Unknown-Class es un agente Analista (hereda de


AgenteAnalistaUnknownClass que tiene la estructura siguiente:


continuación.

4.2.16.2. ATRIBUTOS


4.2.16.3. MÉTODOS

El método implementado en la clase AgenteAnalistaUnknownClass

es el siguiente:



141







siguiente forma:


- Content = "ALTA"


Unknown-Class. Ver apartado 4.3.13: Analizar

Anomalías Unknown-Class.



142

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 gráfica, encapsulando el

nivel de detalle con el que trabajan los agentes Analistas e Intérpretes, por

debajo de él en la arquitectura multiagente. Partiendo del conjunto de

Resúmenes recibidos de los agentes Analistas del sistema, devuelve un

Diagnóstico, único para cada ventana temporal, que refleja la situación

actual del sistema. Asimismo, a la hora de presentar los resultados al usuario

compara el Diagnóstico de la ventana actual con el de la anterior para dar

una explicación textual de los cambios acontecidos. La interfaz gráfica que

incorpora este agente, junto con las de los agentes que le sirven de fuente,

permite la navegación hacia atrás de forma que el usuario que desee

profundizar en el detalle de la situación mostrada por el Diagnóstico, puede

hacerlo siguiendo la traza del mismo. Solamente debe arrancarse un agente

Supervisor (de nombre "supervisor") en una instalación del sistema IDSAI.

El agente Supervisor se representa en el sistema con la clase

AgenteSupervisor que tiene la estructura siguiente:



143


continuación.

4.2.17.2. ATRIBUTOS

Los atributos mantenidos por la clase AgenteSupervisor son los

siguientes:


apartado 4.4.7: Ventana Agente Supervisor.

� ultimodiagnostico: Almacena el último Diagnóstico realizado

por el agente en el tiempo, es decir, el correspondiente a la

ventana actual del sistema. Ver apartado 4.1.2.8:

Diagnóstico.

� diagnosticos: Lista de Diagnósticos realizados. Ver apartado

4.1.2.8: Diagnóstico.

� resumenes: Lista de Resúmenes recibidos. Ver apartado

4.1.2.7: Resumen.



144


� topatacantes: Lista de los 5 atacantes principales en la red.

� topvictimas: Lista de las 5 víctimas principales en la red.

4.2.17.3. MÉTODOS

Los métodos implementados en la clase AgenteAnalista son los

siguientes:




4.4.7: Ventana Agente Supervisor



siguiente forma:


- Content = "ALTA"

3. Arrancar el comportamiento Diagnosticar Resúmenes.

Ver apartado 4.3.14: Diagnosticar Resúmenes.



145



pasos:




siguiente forma:


- Content = "BAJA"



146

4.3. COMPORTAMIENTOS

A continuación 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, más concretamente de los comportamientos Periódico y

Cíclico que se pasan a detallar a continuación junto con los demás comportamientos

desarrollados en el sistema.



147

4.3.1. PERIÓDICO

Comportamiento JADE que ejecuta periódicamente su método principal

según el periodo introducido como parámetro de su constructor.

El comportamiento Periódico se representa en el sistema con la clase

TickerBehaviour, que tiene la estructura resumida siguiente:


continuación.

4.3.1.1. ATRIBUTOS

Ninguno relevante en el proyecto IDSAI.

4.3.1.2. MÉTODOS

El método más relevante implementado en la clase TickerBehaviour

es el siguiente:

� onTick(): Método principal que se ejecuta periódicamente

según el periodo especificado en el constructor de la clase.

Este método es sobrescrito por los agentes hijos para introducir su

propia funcionalidad (en la implementación de la clase TickerBehaviour, no

hace nada).



148

4.3.2. CÍCLICO

Comportamiento JADE que ejecuta cíclicamente su método principal.

El comportamiento Cíclico se representa en el sistema con la clase

CyclicBehaviour, que tiene la estructura resumida siguiente:


continuación.

4.3.2.1. ATRIBUTOS


4.3.2.2. MÉTODOS

El método más relevante implementado en la clase TickerBehaviour

es el siguiente:

� action(): Método principal que se ejecuta de forma continua,

desde el arranque del comportamiento.

Este método es sobrescrito por los agentes hijos para introducir su

propia funcionalidad (en la implementación de la clase CyclicBehaviour, no

hace nada).



149

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 Cíclico

(hereda de CyclicBehaviour) que se representa en el sistema con la clase

BehaviourRecibirNotificaciones que tiene la estructura siguiente:


continuación.

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. MÉTODOS

El método implementado en la clase BehaviourRecibirNotificaciones

es el siguiente:



150

� action(): Sobrescribe el método de la clase padre. El siguiente


Fig. 20: Método 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 posición. La búsqueda es

lineal, de principio a fin del array hasta que se encuentre el

elemento. El elemento siempre debería encontrarse salvo

caso de error extraordinario, en cuyo caso no se hace nada,

INICIO

FIN

nuevo ciclo

¿mensaje

recibido?

NO

SI

¿contenido =

"ALTA"?

SI

Eliminar remitente de la

lista de agentes vivos

Añadir remitente a la lista

de agentes vivos

NO



151

porque el elemento a borrar ya no estaría en la lista.

Finalmente, se actualiza la interfaz gráfica del agente

Reloj invocando la función actualizarTabla() de la clase

FrameReloj. Ver apartado 4.4.2: Ventana Reloj.

- Añadir remitente a la lista de agentes vivos: Añadir

remitente del mensaje al final del ArrayList "agentes" que

es atributo del agente que implementa el comportamiento

(agente Reloj). Finalmente, se actualiza la interfaz gráfica

del agente Reloj invocando la función actualizarTabla() de

la clase FrameReloj. Ver apartado 4.4.2: Ventana Reloj.



152

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 Periódico (hereda

de TickerBehaviour) que se representa en el sistema con la clase

BehaviourSincronizar que tiene la estructura siguiente:


continuación.

4.3.4.1. ATRIBUTOS

Los atributos mantenidos por la clase BehaviourSincronizar son los

siguientes:


comportamiento. Ver apartado 4.2.1: Agente Reloj.

� contadorventana: Entero que mantiene el valor de la ventana

actual del sistema.



153

4.3.4.2. MÉTODOS

El método implementado en la clase BehaviourSincronizar es el

siguiente:

� onTick(): Sobrescribe el método de la clase padre. Su


pasos:

1. Incrementar el valor del atributo contadorventana.

2. Actualizar la interfaz gráfica del agente Reloj

invocando la función 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 = tamaño de la ventana con la que se ha

arrancado el comportamiento (parámetro periodo).

Dado el carácter periódico de este método, 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.



154

4.3.5. LIMPIAR BD

Comportamiento dedicado a mantener la base de datos "snortdb" con un

volumen de datos aceptable, eliminando los registros antiguos periódicamente.

Esta funcionalidad es muy costosa para el sistema gestor de bases de datos e

influye considerablemente en el acceso a la información de los agentes

arrancados en paralelo. Por esta razón se ha optado por no implantar este

proceso en la versión final del sistema, aunque queda pendiente para futuras

revisiones.

El comportamiento Limpiar BD es un comportamiento Periódico (hereda

de TickerBehaviour) que se representa en el sistema con la clase

BehaviourLimpiarBD que tiene la estructura siguiente:


continuación.

4.3.5.1. ATRIBUTOS

Los atributos mantenidos por la clase BehaviourLimpiarBD son los

siguientes:

� ret: Código de retorno de las llamadas al sistema gestor de

bases de datos a través de las llamadas a las funciones de la

capa de persistencia.



155

� 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. MÉTODOS

El método implementado en la clase BehaviourLimpiarBD es el

siguiente:

� onTick(): Sobrescribe el método de la clase padre. Su


pasos:

1. Llama a la función de la capa de persistencia

eliminarEventosAnterioresA() con el número de

segundos que es atributo de esta clase. Ver apartado

4.6.1: Evento DAO.



156

4.3.6. OBTENER ANOMALÍAS

Comportamiento dedicado a buscar periódicamente anomalías (Ver

apartado 4.1.2.4: Anomalía) del tipo especificado en el arranque, en la base de

datos snortdb alojada en el host donde Snort vuelca la información obtenida de

la red.

El comportamiento Obtener Anomalías es un comportamiento Cíclico


BehaviourObtenerAnomalías que tiene la estructura siguiente:


continuación.

4.3.6.1. ATRIBUTOS

Los atributos mantenidos por la clase BehaviourObtenerAnomalias

son los siguientes:


comportamiento. (Ver apartado 4.2.3: Agente Intérprete).

� tipo: Especialidad del agente Intérprete que implementa el

comportamiento.



157

� fiabilidad: valoración numérica de la fiabilidad de la

información recogida por este comportamiento que es

indicada en la construcción del agente Intérprete que lo

implementa.

4.3.6.2. MÉTODOS

El método implementado en la clase BehaviourObtenerAnomalias es

el siguiente:





158

Fig. 21: Método action() del comportamiento Obtener Anomalías.

- Actualizar ventana del agente Intérprete: Actualizar el

valor del atributo ventana del agente Intérprete que

implementa el comportamiento. Ver apartado 4.2.3:

Agente Intérprete.

- Obtener Anomalías: Obtener la lista de anomalías de la

clase de la que es especialista el agente Intérprete que

INICIO

FIN

¿mensaje

recibido?

NO

SI

Obtener Anomalías

Actualizar ventana del

agente Intérprete

¿anomalías

recibidas?

NO

Enviar Anomalías

SI

nuevo

ciclo



159

implementa el comportamiento. Para ello se invoca la

función de la capa de persistencia obtenerAnomalias() con

el tipo de clase especificada por el atributo tipo de este

comportamiento. Ver apartado 4.5.2: Anomalía DAO.

- Enviar Anomalías: Enviar un mensaje ACL al agente

Analista, especializado en la clase de signature en que está

especializado el agente Intérprete 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



160

4.3.7. ANALIZAR ANOMALÍAS

Comportamiento dedicado a extraer valores estadísticos del conjunto de

Anomalías 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 Análisis (Ver apartado 4.1.2.5: Análisis). El manejo de un Análisis por

cada Anomalía 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 sincronización del agente

Analista que lo implementa.

El comportamiento Analizar Anomalías es un comportamiento Cíclico


BehaviourAnalizarAnomalías que tiene la estructura siguiente:


continuación.

4.3.7.1. ATRIBUTOS

Los atributos mantenidos por la clase BehaviourObtenerAnomalias

son los siguientes:



161


comportamiento. (Ver apartado 4.2.10: Agente Analista).

� tipo: Especialidad del agente Analista que implementa el

comportamiento.

4.3.7.2. MÉTODOS

Los métodos implementados en la clase

BehaviourAnalizarAnomalias son los siguientes:





162

Fig. 22: Método action() del comportamiento Analizar Anomalías.

INICIO

FIN

¿mensaje

recibido?

NO

SI

Actualizar ventana del

agente Analista

¿mensaje de

sincronización?

SI NO

(lista de Anomalías)

Limpiar anomalías del

agente Analista

Limpiar análisis del agente

Analista

for Anomalía

Actualizar anomalías del

agente Analista

Realizar Análisis de la

Anomalía actual

Realizar Resumen de los

Análisis actuales

Enviar Resumen



163

- 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 anomalías del agente Analista: Eliminar de la lista

de anomalías recibidas del agente Analista, representada

en el sistema por el atributo anomalias, aquellas que lleven

almacenadas más de 20 ventanas. Externalizar al fichero

de log anomalias.txt la información eliminada y actualizar

la interfaz gráfica.

- Limpiar análisis del agente Analista: Eliminar de la lista

de análisis realizados por el agente Analista, representada

en el sistema por el atributo analisis, aquellos que lleven

almacenados más de 20 ventanas. Externalizar al fichero

de log analisis.txt la información eliminada y actualizar la

interfaz gráfica.

- Actualizar anomalías del agente Analista: Introducir la

Anomalía considerada en el bucle actual en la lista de

anomalías recibidas del agente Analista, representada en el

sistema por el atributo anomalias. Actualizar la interfaz

gráfica.

- Realizar Análisis de la Anomalía actual: Invocar el

método local realizarAnalisis() sobre la anomalía

considerada en el bucle actual. Introducir el Análisis

obtenido en la lista de análisis realizados por el agente



164

Analista, representada en el sistema por el atributo

analisis. Actualizar la interfaz gráfica.

- Realizar Resumen de los Análisis actuales: Invocar el

método local resumir() sobre la lista de análisis realizados

en el bucle anterior y pasándole la fiabilidad del agente

Intérprete de quien se recibieron las correspondientes

Anomalías.

- 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 Análisis pasados como parámetro. El siguiente diagrama,

representa su algoritmo básico:



165

Fig. 23: Método resumir() del comportamiento Analizar Anomalías.

INICIO

FIN

(devolver Resumen)

for Análisis

Obtener lista de atacantes

Obtener lista de víctimas

Obtener prioridad media

Obtener compactación media

Borrosificar prioridad media

Borrosificar compactación media

Obtener matriz de Acusaciones

Construir Resumen



166

- Obtener lista de atacantes: Obtener lista de los atacantes

que han participado en los Análisis a resumir.

- Obtener lista de víctimas: Obtener lista de las víctimas que

han participado en los Análisis a resumir.

- Obtener prioridad media: Obtener prioridad media de los

Análisis a resumir.

- Obtener compactación media: Obtener compactación

media de los Análisis a resumir.

- Borrosificar prioridad media: Obtener el valor borroso de

la prioridad media de los Análisis a resumir, invocando la

función de control borroso borrosificarprioridad(). Ver

apartado 4.6.2: Control Borroso.

- Borrosificar compactación media: Obtener el valor

borroso de la compactación media de los Análisis a

resumir, invocando la función de control borroso

borrosificarcompactación(). Ver apartado 4.6.2: Control

Borroso.

- Obtener matriz de Acusaciones: Recorrer las listas de

atacantes y víctimas junto con la lista de Análisis para

obtener la matriz de Acusaciones característica del

Resumen para el conjunto de Anomalías analizadas. Ver

apartado 4.1.2.6: Acusación.

- Construir Resumen: Construir estructura Resumen

integrando la información anteriormente obtenida: listas



167

de atacantes y víctimas, prioridad y compactación

borrosas y matriz de acusaciones.

� realizarAnalisis(): Extrae valores estadísticos de la Anomalía

que se le pasa como parámetro introduciendo la estructura

Análisis en el sistema. Ver apartado 4.1.2.5: Análisis. Su


pasos:

1. Obtener media del número de eventos por Ataque.

2. Obtener desviación típica del número de eventos por

Ataque.

3. Obtener media de la duración de los Ataques de la

Anomalía.

4. Obtener desviación típica de la duración de los

Ataques de la Anomalía.

5. Obtener el ratio de tiempo en que se dan Ataques

compactos respecto al total del tiempo de la Anomalía.

6. Realizar el cálculo heurístico de la prioridad y

compactación del Análisis en base a la Anomalía

analizada y el ratio obtenido anteriormente. Para ello

se invoca el método local realizarAnalisisParticular().

7. Obtener la dirección IP de origen predominante entre

los eventos de la Anomalía.



168

8. Obtener la dirección IP de destino predominante entre

los eventos de la Anomalía.

9. Obtener el puerto origen predominante entre los

eventos de la Anomalía.

10. Obtener el puerto destino predominante entre los

eventos de la Anomalía.

11. Construir estructura Análisis integrando toda la

información anteriormente obtenida. Ver apartado

4.1.2.5: Análisis.

� realizarAnalisisParticular(): Método abstracto que debe ser

sobrescrito por los comportamientos que hereden de

BehaviourAnalizarAnomalias. Deberá incorporar las reglas de

cálculo de la prioridad y compactación del Análisis de forma

especializada para cada tipo de agente Analista que

implemente el comportamiento hijo.



169

4.3.8. ANALIZAR ANOMALÍAS ATTEMPTED-ADMIN



Analista Attempted-Admin).

El comportamiento Analizar Anomalías Attempted-Admin es un

comportamiento de Analizar Anomalías (hereda de

BehaviourAnalizarAnomalias) que se representa en el sistema con la clase

BehaviourAnalizarAnomaliasAttemptedAdmin que tiene la estructura siguiente:


continuación.

4.3.8.1. ATRIBUTOS


4.3.8.2. MÉTODOS


BehaviourAnalizarAnomaliasAttemptedAdmin son los siguientes:



170

� realizarAnalisisParticular(): Sobrescribe el método de la clase

padre. Su algoritmo es completamente lineal y consiste en los

siguientes pasos:

1. Realizar el cálculo especializado de la compactación

eventual de la Anomalía y según el ratio de tiempo de

ataques pasados como parámetros. Para ello se invoca

el método local reglasCompactacion().

2. Realizar el cálculo especializado de la prioridad de la

Anomalía pasada como parámetro. Para ello se invoca

el método local reglasPrioridad().

3. Devolver el Análisis pasado como parámetro

actualizados sus atributos con los nuevos valores de

compactación y prioridad.

� reglasCompactacion(): Juego de reglas específico para el tipo

de signature en la que es experto el agente Analista que

devuelve el valor numérico entero de la compactación de la

Anomalía pasada como parámetro. Ver árbol de decisión

Compactación del capítulo attempted-admin del anexo 6:

Signatures IDSAI (Snort).

� reglasPrioridad(): Juego de reglas específico para el tipo de

signature en la que es experto el agente Analista que devuelve

el valor numérico entero de la prioridad de la Anomalía

pasada como parámetro. Ver árbol de decisión Prioridad del



171

capítulo attempted-admin del anexo 6: Signatures IDSAI

(Snort).



172

4.3.9. ANALIZAR ANOMALÍAS ATTEMPTED-DOS



Analista Attempted-Dos).

El comportamiento Analizar Anomalías Attempted-Dos es un



BehaviourAnalizarAnomaliasAttemptedDos que tiene la estructura siguiente:


continuación.

4.3.9.1. ATRIBUTOS


4.3.9.2. MÉTODOS


BehaviourAnalizarAnomaliasAttemptedDos son los siguientes:



173



siguientes pasos:















Compactación del capítulo attempted-dos del anexo 6:








174

capítulo attempted-dos del anexo 6: Signatures IDSAI

(Snort).



175

4.3.10. ANALIZAR ANOMALÍAS ATTEMPTED-RECON



Analista Attempted-Recon).

El comportamiento Analizar Anomalías Attempted-Recon es un



BehaviourAnalizarAnomaliasAttemptedRecon que tiene la estructura siguiente:


continuación.

4.3.10.1. ATRIBUTOS


4.3.10.2. MÉTODOS


BehaviourAnalizarAnomaliasAttemptedRecon son los siguientes:



176



siguientes pasos:















Compactación del capítulo attempted-recon del anexo 6:








177

capítulo attempted-recon del anexo 6: Signatures IDSAI

(Snort).



178

4.3.11. ANALIZAR ANOMALÍAS BAD-UNKNOWN



Analista Bad-Unknown).

El comportamiento Analizar Anomalías Bad-Unknown es un



BehaviourAnalizarAnomaliasBadUnknown que tiene la estructura siguiente:


continuación.

4.3.11.1. ATRIBUTOS


4.3.11.2. MÉTODOS


BehaviourAnalizarAnomaliasBadUnknown son los siguientes:



179



siguientes pasos:















Compactación del capítulo bad-unknown del anexo 6:







180


capítulo bad-unknown del anexo 6: Signatures IDSAI (Snort).



181

4.3.12. ANALIZAR ANOMALÍAS OTROS



Analista Otros).

El comportamiento Analizar Anomalías Otros es un comportamiento de

Analizar Anomalías (hereda de BehaviourAnalizarAnomalias) que se representa

en el sistema con la clase BehaviourAnalizarAnomaliasOtros que tiene la

estructura siguiente:


continuación.

4.3.12.1. ATRIBUTOS


4.3.12.2. MÉTODOS


BehaviourAnalizarAnomaliasOtros son los siguientes:



182



siguientes pasos:















Compactación del capítulo otros del anexo 6: Signatures

IDSAI (Snort).






183


capítulo otros del anexo 6: Signatures IDSAI (Snort).



184

4.3.13. ANALIZAR ANOMALÍAS UNKNOWN-CLASS



Analista Unknown-Class).

El comportamiento Analizar Anomalías Unknown-Class es un



BehaviourAnalizarAnomaliasUnknownClass que tiene la estructura siguiente:


continuación.

4.3.13.1. ATRIBUTOS


4.3.13.2. MÉTODOS


BehaviourAnalizarAnomaliasUnknownClass son los siguientes:



185



siguientes pasos:















Compactación del capítulo unknown-class del anexo 6:








186

capítulo unknown-class del anexo 6: Signatures IDSAI

(Snort).



187

4.3.14. DIAGNOSTICAR RESÚMENES

Comportamiento dedicado a realizar el Diagnóstico (ver apartado

4.1.2.8: Diagnóstico) correspondiente a la ventana temporal actual en base a los

Resúmenes (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 Diagnóstico (Ver apartado

4.1.2.8: Diagnóstico). Debido a la gran importancia de la interfaz gráfica del

agente Supervisor, este comportamiento interviene directamente en la

actualización 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

sincronización del agente Supervisor.

El comportamiento Diagnosticar Resúmenes es un comportamiento

Cíclico (hereda de CyclicBehaviour) que se representa en el sistema con la clase

BehaviourDiagnosticarResumenes que tiene la estructura siguiente:


continuación.

4.3.14.1. ATRIBUTOS

El atributo mantenido por la clase BehaviourDiagnosticarResumenes

es el siguiente:



188


comportamiento. (Ver apartado 4.2.17: Agente Supervisor).

4.3.14.2. MÉTODOS


BehaviourDiagnosticarResumenes es el siguiente:





189

INICIO

FIN

¿mensaje recibido?

NO

SI

Seleccionar Resúmenes actuales

¿mensaje de sincronización?

SI NO

(Resumen)

Insertar Resumen en lista de resúmenes del agente

Supervisor

Actualizar tabla de Resúmenes

Realizar listas de atacantes y víctimas

Realizar Diagnóstico cuantitativo

Realizar Diagnóstico cualitativo

Realizar Diagnóstico comparativo

Crear Diagnóstico

Actualizar tops

Limpiar Resúmenes

Limpiar Diagnósticos

Pintar último Diagnóstico



190

Fig. 24: Método action() del comportamiento Diagnosticar Resúmenes.

- Insertar Resumen en lista de resúmenes del agente

Supervisor: Insertar el Resumen de la ventana actual en la

lista de resúmenes 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 Resúmenes: Actualizar la interfaz

gráfica del agente Supervisor invocando el método

actualizarTabla2() de la Ventana Agente Supervisor. Ver

apartado 4.4.7: Ventana Agente Supervisor.

- Seleccionar Resúmenes actuales: Elaborar una lista de

Resúmenes de la ventana anterior seleccionando los

correspondientes elementos de la lista resumenes del

agente Supervisor. En base a estos Resúmenes se realizará

el Diagnóstico de la ventana anterior.

- Realizar listas de atacantes y víctimas: Realizar listas de

atacantes y víctimas recorriendo los Resúmenes actuales.

Confeccionar la matriz de acusaciones de los Resúmenes

actuales.

- Realizar Diagnóstico cuantitativo: Obtener el valor

numérico de la criticidad del sistema en base a los valores



191

borrosos de prioridad y criticidad de los Resúmenes

actuales. Para ello primeramente se obtienen las

inferencias borrosas que son los diferentes conjuntos

borrosos de criticidad que se obtienen al invocar el

método inferenciaBorrosa() de la clase ControlBorroso

pasándole como parámetros los valores borrosos de

prioridad y criticidad de cada uno de los Resúmenes

actuales. El valor continuo de la criticidad de la red se

obtiene finalmente pasando el conjunto de inferencias a la

función desborrosificarInferencias().

- Realizar Diagnóstico cualitativo: Determinar el atacante y

víctima predominantes en el conjunto de los resúmenes

diagnosticados. Las diferentes situaciones que se

presentan en este caso determinan el estado del sistema.

Tanto la descripción textual del estado como los valores

del atacante y víctima principales se muestran al usuario

en el panel de texto de la interfaz gráfica 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 método

borrosificarCriticidad() de la clase ControlBorroso. Los

colores se asocian al valor borroso de la criticidad según

las siguientes correspondencias:

• Criticidad ALTA → Color ROJO

• Criticidad MEDIA → Color NARANJA

• Criticidad BAJA → Color VERDE



192

Los diferentes valores para el estado del sistema se indican

en la siguiente tabla:

Tabla 1: Estados del sistema.

- Realizar Diagnóstico comparativo: Obtener el Diagnóstico

anterior a la ventana que se está diagnosticando. Comparar

la situación de la ventana analizada y la de la anterior en

base a los valores de los hosts atacante y víctima

principales y estado de la red en los dos momentos. Esta

comparación se realiza pasando estos valores por la

siguiente base de reglas:

ESTADO Nº AT. Nº VIC. DETALLES

0 0 0 no hay ataques

1 1 1 -

2 1 varias víctima destacada

3 1 varias repartido

4 varios 1 atacante destacado

5 varios 1 repartido

6 varios varias pareja destacada

7 varios varias repartido



193

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 víctima"

SI victimaanterior <> victimaactual

ENTONCES "Cambio de víctima"

• • • • • • • • • • • • • • • • • • • •

SI estadoanterior = 0

Y estadoactual > 0

ENTONCES "Aparecen nuevos ataques"

SI estadoanterior > 0

Y estadoactual = 0

ENTONCES "Desaparecen ataques"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES 1a2

SI 1a2



194

Y atacanteanterior = atacanteactual

ENTONCES "Atacante amplía su ataque a otras

víctimas"

SI 1a2

Y atacanteanterior <> atacanteactual

ENTONCES "Nuevo atacante"

SI 1a2

Y victimaanterior = victimaactual

ENTONCES "Se mantiene el ataque a la misma víctima

principal"

SI 1a2

Y victimaanterior <> victimaactual

ENTONCES "Nueva víctima principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 3

ENTONCES 1a3

SI 1a3



víctimas"

SI 1a3





195

SI 1a3

ENTONCES "Dispersión de víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES 1a4

SI 1a4


ENTONCES "Aparecen más atacantes"

SI 1a4


ENTONCES "Nuevo atacante principal"

SI 1a4


ENTONCES "Aumenta la presión sobre la víctima"

SI 1a4


ENTONCES "Nueva víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5

ENTONCES 1a5



196

SI 1a5

ENTONCES "Dispersión de atacante"

SI 1a5


ENTONCES "Aumenta la presión sobre la víctima"

SI 1a5



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES 1a6

SI 1a6



SI 1a6



SI 1a6



principal"

SI 1a6



197



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7

ENTONCES "Dispersión de atacante y víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 1

ENTONCES 2a1

SI 2a1


ENTONCES "Atacante concreta su ataque sobre la

víctima principal"

SI 2a1



SI 2a1



principal"

SI 2a1



• • • • • • • • • • • • • • • • • • • •



198


Y estadoactual = 3

ENTONCES 2a3

SI 2a3



víctimas"

SI 2a3



SI 2a3

ENTONCES "Dispersión de víctima principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES 2a4

SI 2a4



SI 2a4



SI 2a4



199


ENTONCES "Se concentra el ataque sobre la misma

víctima"

SI 2a4



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5

ENTONCES 2a5

SI 2a5


SI 2a5


ENTONCES "Se concentra el ataque sobre la misma

víctima"

SI 2a5



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES 2a6

SI 2a6



200



SI 2a6



SI 2a6



principal"

SI 2a6



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7

ENTONCES "Dispersión de atacante y víctima

principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 1

ENTONCES 3a1

SI 3a1


ENTONCES "Atacante concreta su ataque sobre una

víctima"



201

SI 3a1



SI 3a1

ENTONCES "Concreción de víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES 3a2

SI 3a2


ENTONCES "Atacante concreta su ataque sobre una

víctima principal"

SI 3a2



SI 3a2

ENTONCES "Concreción de víctima principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES 3a4

SI 3a4



202



SI 3a4



SI 3a4


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5

ENTONCES 3a5

SI 3a5


SI 3a5


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES 3a6

SI 3a6





203

SI 3a6



SI 3a6

ENTONCES "Concreción de víctima principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 1

ENTONCES 4a1

SI 4a1


ENTONCES "Desaparecen los demás atacantes"

SI 4a1



SI 4a1


ENTONCES "Disminuye la presión sobre la víctima"

SI 4a1



204



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES 4a2

SI 4a2



SI 4a2



SI 4a2



principal"

SI 4a2



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 3

ENTONCES 4a3

SI 4a3



205



SI 4a3



SI 4a3


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5

ENTONCES 4a5

SI 4a5

ENTONCES "Dispersión de atacante principal"

SI 4a5


ENTONCES "Se mantiene el ataque a la misma víctima"

SI 4a5



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES 4a6



206

SI 4a6


ENTONCES "Se mantiene el ataque desde el atacante

principal"

SI 4a6



SI 4a6


ENTONCES "Disminuye la presión sobre la víctima

principal"

SI 4a6



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7

ENTONCES "Dispersión de atacante principal y

víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 1

ENTONCES 5a1

SI 5a1



207

ENTONCES "Concreción de atacante"

SI 5a1


ENTONCES "Disminuye la presión sobre la víctima"

SI 5a1



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES 5a2

SI 5a2


SI 5a2



principal"

SI 5a2



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 3

ENTONCES 5a3



208

SI 5a3


SI 5a3


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES 5a4

SI 5a4

ENTONCES "Concreción de atacante principal"

SI 5a4


ENTONCES "Se mantiene el ataque a la misma víctima"

SI 5a4



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES 5a6

SI 5a6

ENTONCES "Concreción de atacante principal"



209

SI 5a6



principal"

SI 5a6



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 1

ENTONCES 6a1

SI 6a1



SI 6a1



SI 6a1




210


principal"

SI 6a1



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES 6a2

SI 6a2



SI 6a2



SI 6a2


ENTONCES "Se mantiene el ataque sobre la víctima

principal"

SI 6a2



• • • • • • • • • • • • • • • • • • • •




211

Y estadoactual = 3

ENTONCES 6a3

SI 6a3



SI 6a3



SI 6a3

ENTONCES "Dispersión de víctima principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES 6a4

SI 6a4


ENTONCES "Se mantiene el ataque desde el atacante

principal"

SI 6a4



SI 6a4




212


principal"

SI 6a4



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5

ENTONCES 6a5

SI 6a5

ENTONCES "Dispersión de atacante principal"

SI 6a5



principal"

SI 6a5



• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 7

ENTONCES "Dispersión de atacante principal y víctima

principal"

• • • • • • • • • • • • • • • • • • • •




213

Y estadoactual = 1

ENTONCES "Concreción de atacante y víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 2

ENTONCES "Concreción de atacante y víctima

principal"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 3


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 4

ENTONCES "Concreción de atacante principal y

víctima"

• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 5


• • • • • • • • • • • • • • • • • • • •


Y estadoactual = 6

ENTONCES "Concreción de atacante principal y víctima

principal"

El comentario en texto que se genera en cada una de ellas

se muestra en el panel de texto.



214

- Crear Diagnóstico: Integrar toda la información obtenida

hasta el momento en la estructura Diagnóstico e insertarla

en la lista de diagnósticos 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 víctima principales anteriormente obtenidos.

Actualizar la representación gráfica de estas listas.

- Limpiar Resúmenes: Eliminar de la lista de Resúmenes

recibidos por el agente Supervisor, representada en el

sistema por el atributo resumenes, aquellos que lleven


de log resumenes.txt la información eliminada y actualizar

la interfaz gráfica.

- Limpiar Diagnósticos: Eliminar de la lista de Diagnósticos

realizados por el agente Supervisor, representada en el

sistema por el atributo diagnosticos, aquellos que lleven


de log diagnosticos.txt la información eliminada y

actualizar la interfaz gráfica.

- Pintar último Diagnóstico: Repintar el lienzo de la interfaz

gráfica del agente Supervisor con la nueva información

almacenada en su atributo ultimodiagnostico. Ver

apartado 4.4.9: Lienzo Supervisor.



215

4.4. CLASES DE LA INTERFAZ GRÁFICA

4.4.1. MODELO DE TABLA

Todas las tablas que aparecen en cada uno de los elementos de la interfaz

gráfica del sistema IDSAI son tablas no editables por el usuario. Por tanto, toda

tabla gráfica JTable incorporada al sistema, debe soportar un modelo de tabla

que sólo sea modificable por programación.

El modelo Modelo de Tabla es un Modelo de Tabla Estándar (hereda de

DefaultTableModel) que se representa en el sistema con la clase MiTableModel

que tiene la estructura siguiente:


continuación.

4.4.1.1. ATRIBUTOS


4.4.1.2. MÉTODOS

El método más relevante implementado en la clase MiTableModel es

el siguiente:



216

� isCellEditable(): Método que altera el estado de la celda de la

tabla que incorpora el modelo, haciéndola no editable por

parte del usuario. Esta condición se aplicará a todas las celdas

de todas las tablas de la interfaz gráfica del sistema IDSAI.



217

4.4.2. VENTANA RELOJ

Representación de la interfaz gráfica 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 gráficos

necesarios para componer la ventana Agente Reloj:

Fig. 25: Ventana Agente Reloj

Entre los elementos gráficos que podemos ver en la ventana destacan:



218

• 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.

• Botón "Detener": Al pulsarlo, se duerme el agente Reloj,

deteniéndose todos sus comportamientos asociados. El botón

"Arrancar" se habilita y el "Detener" se deshabilita.

• Botón "Arrancar": Al pulsarlo, se despierta el agente Reloj,

recuperándose todos sus comportamientos asociados. El botón

"Detener" se habilita y el "Arrancar" se deshabilita.


continuación.

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.



219

� contadorventanas: Etiqueta que se actualiza con el valor

actual de la ventana del sistema.

4.4.2.2. MÉTODOS

Los métodos 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.



220

4.4.3. VENTANA AGENTE

Representación de la interfaz gráfica básica de los agentes del sistema

IDSAI, y en particular de los agentes Intérpretes (Ver apartado 4.2.3: Agente

Intérprete).

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 gráficos

necesarios para componer la ventana Agente Intérprete:



221

Fig. 26: Ventana Agente Intérprete


• Etiqueta "Nombre": Muestra el nombre global unívoco del

agente en la plataforma multiagente.

• Panel de texto "Log": Muestra las incidencias ocurridas

durante la vida del agente.

• Botón "Limpiar Log": Limpia el área de texto "Log".

• Botón "Matar agente": Mata el agente Intérprete

correspondiente a esta interfaz. La ventana no se cierra, pero

se deshabilitan todos sus controles.


continuación.

4.4.3.1. ATRIBUTOS

Los atributos mantenidos por la clase FrameAgente son los

siguientes:

� editor: Panel de texto "Log".

� panel: Panel gráfico sobre el que se distribuyen los diferentes

componentes de la interfaz gráfica.



222

� btnmataragente: Botón gráfico "Matar Agente".

� btnlimpiarlog: Botón gráfico "Limpiar Log".

� scrollpanetxtlog: Barra de desplazamiento asociada al panel

de texto "Log".

4.4.3.2. MÉTODOS

Los métodos implementados en la clase FrameReloj son los

siguientes:

� escribirLinea(): Escribe una línea de texto en el panel de texto

"Log" pasada como primer argumento con los parámetros de

formato pasados como los demás argumentos de la función.



223

4.4.4. VENTANA AGENTE AVANZADO

Representación de la interfaz gráfica básica 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

gráficos necesarios para ampliar la ventana Agente Intérprete.

Entre los nuevos elementos gráficos que se incorporan a la ventana

destacan dos tablas que según el agente que implemente la interfaz gráfica

almacenarán información relevante sobre la que trabaje el agente:

• Tabla 1 (superior): Registra los productos del agente:

Análisis, en el caso de agentes Analistas, que se envían en

forma de Resumen al agente Supervisor y Diagnósticos, en el

caso del agente Supervisor, que se muestran por pantalla al

usuario.



224

• Tabla 2 (inferior): Registra las fuentes del agente: Anomalías,

en el caso de agentes Analistas, que se procesan para elaborar

Análisis y Resúmenes en el caso del agente Supervisor, que se

procesan para elaborar Diagnósticos.


continuación.

4.4.4.1. ATRIBUTOS

Los atributos más 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 gráfica superior.

� tabla2: Tabla gráfica inferior

4.4.4.2. MÉTODOS

Los métodos implementados en la clase FrameAgenteAvanzado son

los siguientes:

� actualizarTabla1(): Método abstracto que debe ser sobrescrito

por las ventanas que hereden de FrameAgenteAvanzado.

Deberá incorporar las particularidades de los registros a



225

mostrar en la tabla1 según sea el agente que implemente la

interfaz.

� actualizarTabla2(): Método abstracto que debe ser sobrescrito

por las ventanas que hereden de FrameAgenteAvanzado.

Deberá incorporar las particularidades de los registros a

mostrar en la tabla2 según sea el agente que implemente la

interfaz.

� mostrarDetallesTabla1(): Método abstracto que debe ser

sobrescrito por las ventanas que hereden de

FrameAgenteAvanzado. Deberá incorporar las

particularidades de los registros a mostrar en la tabla1 según

sea el agente que implemente la interfaz.

� mostrarDetallesTabla2(): Método abstracto que debe ser

sobrescrito por las ventanas que hereden de

FrameAgenteAvanzado. Deberá incorporar las

particularidades de los registros a mostrar en la tabla2 según

sea el agente que implemente la interfaz.



226

4.4.5. VENTANA AGENTE ANALISTA

Representación de la interfaz gráfica 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

gráficos necesarios para componer la ventana Agente Analista:



227

Fig. 27: Ventana Agente Analista


Agente (ver apartado 4.4.3: Ventana Agente) destacan:



228

• Tabla "Ultimos analisis": Se trata de la tabla1 que es atributo

heredado de la clase padre. Muestra un registro por cada

Análisis existente en la lista de Análisis 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 método local mostrarDetallesTabla1(), de manera que se

muestra gráficamente la información detallada del Análisis

deseado. De igual manera se resalta gráficamente el registro

correspondiente a la Anomalía asociada al Análisis sobre

cuyo registro se ha hecho clic, para que sea más sencillo

referirse a ésta a la hora de analizar la traza del Análisis.

• Tabla "Anomalias recibidas": Se trata de la tabla2 que es

atributo heredado de la clase padre. Muestra un registro por

cada Anomalía existente en la lista de Análisis 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 método local mostrarDetallesTabla2, de manera que

se muestra gráficamente la información detallada de la

Anomalía deseada.


continuación.



229

4.4.5.1. ATRIBUTOS

El atributo mantenido por la clase FrameAgenteAnalista es el

siguiente:


apartado 4.2.10: Agente Analista.

4.4.5.2. MÉTODOS

Los métodos implementados en la clase FrameAgenteAnalista son

los siguientes:

� actualizarTabla1(): Sobrescribe el método 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 Análisis

realizados (atributo analisis) del agente Analista que

implementa la interfaz (ver apartado 4.2.10: Agente

Analista) en la tabla1.



siguientes pasos:




230

2. Introducir todos los elementos de la lista de

Anomalías recibidas (atributo anomalias) del agente

Analista que implementa la interfaz (ver apartado

4.2.10: Agente Analista) en la tabla2.

� mostrarDetallesTabla1(): Sobrescribe el método de la clase

padre. Muestra por la Ventana Detalles que se le pasa como

segundo parámetro toda la información, debidamente

formateada, del Análisis que se le pasa como primer

parámetro.




formateada, de la Anomalía que se le pasa como primer

parámetro.



231

4.4.6. VENTANA DETALLES

Representación de la interfaz gráfica básica de las ventanas de detalle del

sistema IDSAI, y en particular de aquellas que se abren al hacer clic sobre algún

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 gráficos

necesarios para componer la ventana Detalles:



232

Fig. 28: Ventana Detalles


• Etiqueta "label": Muestra el nombre de la estructura del

sistema IDSAI a mostrar.

• Panel de texto "texto": Muestra la información contenida en la

estructura mostrada.



233


continuación.

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

información se presenta en la caja de texto.

� texto: Caja de texto que muestra la información, debidamente

formateada, de la estructura deseada.

4.4.6.2. MÉTODOS

El método implementado en la clase FrameDetalles es el siguiente:

� escribirLinea(): Escribe una línea de texto en el panel de texto

"texto" pasada como primer argumento.



234

4.4.7. VENTANA AGENTE SUPERVISOR

Representación de la interfaz gráfica 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

gráficos necesarios para componer la ventana Agente Supervisor:



235

Fig. 29: Ventana Supervisor


Agente (ver apartado 4.4.3: Ventana Agente) destacan:

• Tabla "Ultimos diagnosticos": Se trata de la tabla1 que es




236

cada Diagnóstico existente en la lista de Diagnósticos

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

Gráfico y Tabla (ver 5.10: Ventana Detalles con Gráfico y

Tabla) y se invoca el método local mostrarDetallesTabla1(),

de manera que se muestra gráficamente la información

detallada del Diagnóstico deseado. De igual manera se

resaltan gráficamente los registros correspondientes a los

Resúmenes asociados al Diagnóstico sobre cuyo registro se ha

hecho clic, para que sea más sencillo referirse a éstos a la hora

de analizar la traza del Diagnóstico.

• Tabla "Resumenes recibidos": Se trata de la tabla2 que es


cada Resumen existente en la lista de Resúmenes 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 método

local mostrarDetallesTabla2, de manera que se muestra

gráficamente la información detallada del Resumen deseado.

• Lienzo "Lienzo": Panel de dibujo en el que se representa

gráficamente la información almacenada en el atributo

ultimodiagnostico del agente Supervisor (ver apartado

4.2.17: Agente Supervisor). Ver apartado 4.4.9: Lienzo

Supervisor.



237


continuación.

4.4.7.1. ATRIBUTOS

Los atributos mantenidos por la clase FrameAgenteSupervisor son

los siguientes:


apartado 4.2.17: Agente Supervisor.

� lienzosupervisor: Panel de dibujo que presenta gráficamente

la información del último Diagnóstico generado. Ver

apartado 4.4.9: Lienzo Supervisor.

4.4.7.2. MÉTODOS

Los métodos implementados en la clase FrameAgenteSupervisor son

los siguientes:



siguientes pasos:



Diagnósticos realizados (atributo diagnosticos) por el

agente Supervisor que implementa la interfaz (ver

apartado 4.2.17: Agente Supervisor) en la tabla1.



238



siguientes pasos:



Resumenes recibidos (atributo resumenes) del agente

Supervisor que implementa la interfaz (ver apartado

4.2.17: Agente Supervisor) en la tabla2.




formateada, del Diagnóstico que se le pasa como primer

parámetro.




formateada, del Resumen que se le pasa como primer

parámetro.



239

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 información relativa a valores borrosos en

la siguiente estructura:

Donde:

� clase: Clase de Signature. Ver apartado 4.1.2.2: Signature.

� color: Color asociado.



240

4.4.9. LIENZO SUPERVISOR

Representación del panel de dibujo de la interfaz gráfica 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 información relativa a

las acusaciones que se dan entre las direcciones IP atacantes y víctimas en el

sistema representadas por el atributo acusaciones del Diagnóstico diag que es a

su vez atributo de la clase LienzoSupervisor (ver apartado 4.1.2.8:

Diagnóstico). El atributo almacena el último diagnóstico realizado por el agente

Supervisor, representado por el atributo ultimodiagnostico de este agente (ver

apartado 4.2.17: Agente Supervisor).



241

Fig. 30: Lienzo Supervisor

En la parte central del mismo, se representan las direcciones IP de los

atacantes y víctimas del último diagnóstico en torno a un círculo. Estas

direcciones IP se unen con una línea por cada acusación registrada entre atacante

y víctima registrados en el diagnóstico. El color de las líneas viene determinado

por la leyenda de colores que se indica a continuación:

• Clase unknown-class → Color AMARILLO

• Clase attempted-recon → Color CYAN

• Clase bad-unknown → Color ROJO



242

• Clase attempted-dos → Color VERDE

• Clase attempted-admin → Color MAGENTA

El grosor de las líneas representa el número de signatures que se dan

entre las IP atacante y víctima unidas. En el extremo de la línea correspondiente

a la víctima, 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 más veces (indicadas

entre paréntesis) se han determinado como atacante principal de diagnóstico

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 más

veces (indicadas entre paréntesis) se han determinado como víctima principal de

diagnóstico durante la vida del agente Supervisor. Esta lista se corresponde con

el atributo topvictimas del agente Supervisor (ver apartado 4.2.17: Agente

Supervisor)


continuación.

4.4.9.1. ATRIBUTOS

Los atributos mantenidos por la clase LienzoSupervisor son los

siguientes:



243


apartado 4.2.17: Agente Supervisor.

� diag: Diagnóstico (ver apartado 4.1.2.8: Diagnóstico) cuya

información se presenta gráficamente. 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 tamaño del círculo en

torno al cual se disponen las direcciones IP del diagnóstico.

4.4.9.2. MÉTODOS

El método principal implementado en la clase LienzoSupervisor es el

siguiente:

� paint(): Pinta sobre el panel de dibujo la información antes

descrita. La disposición correcta de los elementos se facilita

con las funciones de mapping: mappingX() y mappingY() y

ubicación en 2 dimensiones: obtenerXs() y obtenerYs(),

autoexplicativas.



244

4.4.10. VENTANA DETALLES CON GRÁFICO Y TABLA

Representación de la interfaz gráfica de las ventanas de detalle del

sistema IDSAI que se abren al hacer clic sobre algún registro de la tabla Ultimos

Diagnosticos de la Ventana Agente Supervisor (Ver apartado 4.4.7: Ventana

Agente Supervisor).

La interfaz Ventana Detalles con Gráfico 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 gráficos necesarios para componer la ventana Detalles:



245

Fig. 31: Ventana Detalles con Gráfico y Tabla


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

víctimas (como título del resto de campos de la tabla). El

contenido de la tabla representa el número de signatures

diferentes de la Acusación que protagonizan el atacante y

víctima correspondientes a cada casilla (ver apartado 4.1.2.6:

Acusación). Se ha configurado el evento mouseClicked(), de




246


el método local mostrarDetallesTabla(), de manera que se

muestra la información detallada de la Acusación deseada.

• Lienzo detalles: Representa la información relativa al

Diagnóstico referenciado por el registro sobre el que se ha

hecho clic en la Ventana Agente Supervisor. Muestra

gráficamente las acusaciones que se dan entre las direcciones

IP atacantes y víctimas en el sistema representadas por el

Diagnóstico recibido como parámetro. Ver apartado 4.4.12:

Lienzo Detalles.


continuación.

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 gráfica de acusaciones.

4.4.10.2. MÉTODOS




247

� mostrarDetallesTabla(): Muestra los detalles de la Acusación

que protagonizan las direcciones IP atacante y víctima

pasados como primeros parámetros sobre el panel de texto

que es el atributo texto de la Ventana Detalles pasada como

cuarto parámetro. Ver apartado 4.4.6: Ventana Detalles.



248

4.4.11. VENTANA DETALLES CON TABLA

Representación de la interfaz gráfica de las ventanas de detalle del

sistema IDSAI que se abren al hacer clic sobre algún 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 Resúmenes como los de Diagnósticos. Se ha

prescindido del constructor dedicado a Diagnósticos en la implantación

definitiva del sistema.

El constructor de la clase FrameDetallesTabla dispone los elementos

gráficos necesarios para componer la ventana Detalles:



249

Fig. 32: Ventana Detalles con Tabla


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

víctimas (como título del resto de campos de la tabla). El

contenido de la tabla representa el número de signatures



250

diferentes de la Acusación que protagonizan el atacante y

víctima correspondientes a cada casilla (ver apartado 4.1.2.6:

Acusación). Se ha configurado el evento mouseClicked(), de



el método local mostrarDetallesTabla(), de manera que se

muestra la información detallada de la Acusación deseada.


continuación.

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 gráfica de acusaciones.

4.4.11.2. MÉTODOS


� mostrarDetallesTabla(): Muestra los detalles de la Acusación

que protagonizan las direcciones IP atacante y víctima

pasados como primeros parámetros sobre el panel de texto



251

que es el atributo texto de la Ventana Detalles pasada como

cuarto parámetro. Ver apartado 4.4.6: Ventana Detalles.



252

4.4.12. LIENZO DETALLES

Representación del panel de dibujo de la interfaz gráfica de la Ventana

Detalles con Gráfico y Tabla del sistema IDSAI. Ver apartado 4.4.10: Ventana

Detalles con Gráfico 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 información relativa a las

acusaciones que se dan entre las direcciones IP atacantes y víctimas en el

sistema representadas por el Diagnóstico pasado como parámetro al constructor

de la clase LienzoDetalles (ver apartado 4.1.2.8: Diagnóstico).



253

Fig. 33: Lienzo Detalles

En la parte central del mismo, se representan las direcciones IP de los

atacantes y víctimas del diagnóstico en torno a un círculo. Estas direcciones IP

se unen con una línea por cada acusación registrada entre atacante y víctima

registrados en el diagnóstico. El color de las líneas viene determinado por la

leyenda de colores que se indica a continuación:

• Clase unknown-class → Color AMARILLO

• Clase attempted-recon → Color CYAN

• Clase bad-unknown → Color ROJO

• Clase attempted-dos → Color VERDE



254

• Clase attempted-admin → Color MAGENTA

El grosor de las líneas representa el número de signatures que se dan

entre las IP atacante y víctima unidas. En el extremo de la línea correspondiente

a la víctima, 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.


continuación.

4.4.12.1. ATRIBUTOS

Los atributos mantenidos por la clase LienzoSupervisor son los

siguientes:

� diag: Diagnóstico (ver apartado 4.1.2.8: Diagnóstico) cuya

información se presenta gráficamente. Se carga con el valor

del Diagnóstico pasado como parámetro 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 tamaño del círculo en

torno al cual se disponen las direcciones IP del diagnóstico.



255

4.4.12.2. MÉTODOS

El método principal implementado en la clase LienzoSupervisor es el

siguiente:

� paint(): Pinta sobre el panel de dibujo la información antes

descrita. La disposición correcta de los elementos se facilita

con las funciones de mapping: mappingX() y mappingY() y

ubicación en 2 dimensiones: obtenerXs() y obtenerYs(),

autoexplicativas.



256

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:


continuación.

4.5.1.1. ATRIBUTOS

Los atributos mantenidos por la clase EventoDAO son las siguientes

instrucciones SQL:

� DELETE_EVENTS: Instrucción SQL que elimina aquellos

registros de la tabla event, cuyo valor de campo timestamp



257

sea tantos segundos anterior como se precise respecto al

momento actual.

� DELETE_SIGNATURES: Instrucción SQL que elimina

aquellos registros de la tabla signature no referenciados en la

tabla event.

� DELETE_SIG_CLASS: Instrucción SQL que elimina

aquellos registros de la tabla sig_class no referenciados en la

tabla signature.

� DELETE_IPHDR: Instrucción SQL que elimina aquellos

registros de la tabla iphdr no referenciados en la tabla event.

� DELETE_DATA: Instrucción SQL que elimina aquellos

registros de la tabla data no referenciados en la tabla iphdr.

� DELETE_OPT: Instrucción SQL que elimina aquellos

registros de la tabla opt no referenciados en la tabla iphdr.

� DELETE_ICMPHDR: Instrucción SQL que elimina aquellos

registros de la tabla icmphdr no referenciados en la tabla

iphdr.

� DELETE_UDPHDR: Instrucción SQL que elimina aquellos

registros de la tabla udphdr no referenciados en la tabla iphdr.

� DELETE_TCPHDR: Instrucción SQL que elimina aquellos

registros de la tabla tcphdr no referenciados en la tabla iphdr.



258

4.5.1.2. MÉTODOS

El método implementado en la clase BehaviourSincronizar es el

siguiente:

� eliminarEventosAnterioresA(): Simula un borrado en cascada

de la información más voluminosa almacenada en la base de

datos snortdb. Su algoritmo es completamente lineal y

consiste en los siguientes pasos:

1. Establecer conexión con la base de datos snortdb.

2. Ejecutar instrucción DELETE_EVENTS con el

número de segundos recibido como parámetro del

método.

3. Ejecutar instrucción DELETE_SIGNATURES.

4. Ejecutar instrucción DELETE_SIG_CLASS.

5. Ejecutar instrucción DELETE_IPHDR.

6. Ejecutar instrucción DELETE_DATA.

7. Ejecutar instrucción DELETE_OPT.

8. Ejecutar instrucción DELETE_ICMPHDR.

9. Ejecutar instrucción DELETE_UDPHDR.

10. Ejecutar instrucción DELETE_TCPHDR.

11. Cerrar la conexión con la base de datos snortdb.



259

4.5.2. ANOMALÍA DAO

Paquete de funciones de acceso a la base de datos snortdb a nivel de

anomalías.


AnomaliaDAO que tiene la estructura siguiente:


continuación.

4.5.2.1. ATRIBUTOS

Los atributos mantenidos por la clase AnomaliaDAO son las

siguientes instrucciones SQL:

� SELECT_SIG: Instrucción SQL que obtiene la información

de las signatures cuya clase es igual al tipo de especialidad

que se especifique.



260

� SELECT_OTROS: Instrucción SQL que obtiene la

información de las signatures cuya clase especificada es del

tipo "otros".

� SELECT_EVENTS: Instrucción SQL que obtiene la

información de los eventos relacionados con la signature

deseada, de la última ventana de tiempo.

� SELECT_PORTS_TCP: Instrucción SQL que obtiene los

puertos tcp relacionados con el evento deseado.

� SELECT_PORTS_UDP: Instrucción SQL que obtiene los

puertos udp relacionados con el evento deseado.


� tamañoventana: Entero que almacena el tamaño de la ventana

indicado por el agente Reloj.

4.5.2.2. MÉTODOS

El método implementado en la clase AnomaliaDAO es el siguiente:

� obtenerAnomalias(): Obtiene la información de las signatures

del tipo que se especifique como parámetro y eventos

relacionados en la última ventana temporal. El siguiente




261

Fig. 34: Método obtenerAnomalias() de la clase Anomalía DAO.

INICIO

FIN

(devolver lista de

Anomalías)

Obtener ataques de la

anomalía

Obtener lista de signatures

¿hay eventos? NO

Agregar Anomalía

SI

Establecer conexión con la

base de datos snortdb

for signature

Obtener lista de eventos

relacionados con la signature

Crear Anomalía

Cerrar conexión con la base

de datos snortdb



262

- Establecer conexión con la base de datos snortdb:

Autoexplicativa.

- Obtener lista de signatures: Obtener una relación de las

signatures registradas en la base de datos e información

asociada. Creación de estructura Signature (Ver apartado

4.1.2.2: Signature).

- Obtener lista de eventos relacionados con la signature:

Obtener una relación 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). Creación 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 anomalía: Obtener datos estadísticos

sobre la secuencia de eventos cuya signature asociada es

la considerada en el bucle actual. Creación de estructura

Ataque (Ver apartado 4.1.2.3: Ataque).

- Crear Anomalía: Crear la estructura Anomalía integrando

las estructuras creadas en cada bucle de signature:

Signature, lista de Eventos y lista de Ataques.(Ver

apartado 4.1.2.4: Anomalía).

- Agregar Anomalía: Añadir Anomalía a lista de Anomalías

a enviar al agente Analista correspondiente.



263

4.6. CLASES DE FUNCIONES DE CÁLCULO

4.6.1. FUZZY

Estructura de datos que representa un elemento perteneciente a un

conjunto borroso.

El sistema IDSAI almacena la información 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).



264

4.6.2. CONTROL BORROSO

Paquete de funciones de manejo de conjuntos borrosos según los

controladores borrosos de Mandani representados gráficamente en el anexo 1:

Conjuntos borrosos IDSAI.


ControlBorroso que tiene la estructura siguiente:


continuación.

4.6.2.1. ATRIBUTOS

Ninguno.

4.6.2.2. MÉTODOS

Los métodos implementados en la clase ControlBorroso son los

siguientes:



265

� borrosificarPrioridad(): Devuelve el valor o valores borrosos

(ver apartado 4.6.1: Fuzzy) del valor continuo pasado como

parámetro, 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 parámetro, en el conjunto borroso

Compactación (ver apartado Compactación 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

parámetro, 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 parámetro dentro

de un intervalo definido por un conjunto borroso pasado como

primer parámetro dentro del controlador borroso Criticidad

(ver apartado Criticidad en el anexo 1: Conjuntos borrosos

IDSAI).

� inferenciaBorrosa(): Invoca el método local

reglasInferenciaBorrosa() según sean el número de valores

borrosos prioridad y compactación pasados como parámetros.

� reglasInferenciaBorrosa(): Devuelve el valor borroso

criticidad resultante de evaluar los valores borrosos prioridad

y compactación pasados como parámetros según el siguiente

juego de reglas:



266

SI prioridad BAJA

Y compactación BAJA

ENTONCES criticidad BAJA

SI prioridad BAJA

Y compactación MEDIA


SI prioridad BAJA

Y compactación ALTA

ENTONCES criticidad MEDIA

SI prioridad MEDIA



SI prioridad MEDIA



SI prioridad MEDIA


ENTONCES criticidad ALTA

SI prioridad ALTA





267

SI prioridad ALTA



SI prioridad ALTA



El grado de pertenencia del valor borroso se calcula mediante el

criterio del mínimo 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 parámetro por el método del

centro de gravedad. Este proceso se realiza según 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 máximo grado de

pertenencia de los conjuntos borrosos pasados como

parámetro.

3. Obtener la lista de grados de pertenencia asociados a

cada muestra calculada anteriormente invocando la

función local desborrosificarInferenciaBorrosa para



268

cada uno de los conjuntos borrosos pasados como

parámetro.

4. Calcular el centro de gravedad de los grados de

pertenencia máximos obtenidos en el paso anterior

para cada muestra.

� desborrosificarInferenciaBorrosa(): Devuelve la lista de

grados de pertenencia asociados a la inferencia borrosa

pasada como parámetro según la discretización de los valores

en muestras separadas 0.5 unidades.

A continuación se muestra un ejemplo documentado de cómo a

través de las funciones de la clase ControlBorroso, se trabaja con la

información borrosa prioridad y compactación para inferir el valor de la

criticidad de la red analizada:



269

4.6.2.3. EJEMPLO DE CÁLCULO BORROSO IDSAI

Fig. 35: Lista de análisis y resúmenes enviados

Fig. 36: Diagnóstico realizado



270

4.6.2.4. DESCRIPCIÓN DEL PROCESO

PREÁMBULO: 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 valoración cuantitativa de la prioridad y

compactación de los Analisis en que se basan.

En la figura 36 se muestra la salida del agente Supervisor, sobre el

diagnóstico cuantitativo realizado.

La situación corresponde con la ventana 29 de una sesión de captura.

1.- Agente Analista: Elabora Resumen de Analisis. La compactación

y prioridad del Resumen se obtienen como media aritmética de las

compactaciones y prioridades de los Analisis. Este proceso se lleva a cabo

en la llamada al método 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 envía su Resumen al agente Supervisor.



271

2.- Agente Supervisor: Borrosifica los valores cuantitativos de

prioridad y compactación de cada resumen según 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: Compactación

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)



272

Como se puede observar la compactación 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 combinación de valores por su base de inferencias. El

grado de pertenencia de la criticidad resultante para cada par prioridad-

compactacion es el mínimo de ambos. Estos cálculos se llevan a cabo

invocando la función 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)



273

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

ocasión, tres) para realizar una desborrosificación del conjunto por el

método del centro de gravedad. Las inferencias son conjuntos borrosos de

tipo criticidad, cuyo controlador borroso se representa en la figura 39. De

forma gráfica la agregación de las inferencias obtenidas según su

controlador queda representada en la figura 23, como el conjunto borroso

formado por la unión de los conjuntos borrosos a integrar con el mayor

grado de pertenencia. Esta compleja operación se lleva a cabo en la primera

mitad del algoritmo correspondiente al método desborrosificarInferencias()

de la clase ControlBorroso.

Fig. 39: Criticidad



274

Fig. 40: Agregación de inferencias

5.- Agente Supervisor: Desborrosifica la agregación de inferencias

aplicando el método 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

imágenes α que se operarán a través de la fórmula: Σi=1..19(αi * Ci)/ Σi=1..19 αi.

Esta operación se lleva a cabo en la segunda mitad del algoritmo

correspondiente al método desborrosificarInferencias() de la clase

ControlBorroso.

1 3

INF3 INF1 INF2

2 10 9 8 7 6 5 4

1

0.8

0.2

0.4



275

Fig. 41: Cálculo centro de gravedad

Valores obtenidos:

C 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 9 9.5 10

α 0.8 0.8 0.8 0.75 0.5 0.25 0.2 0.2 0.2 0.2 0.2 0.2 0.2 0.4 0.4 0.4 0.4 0.4 0.4

Operándolos según la fórmula 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

1 3

INF3

INF1

INF2

2 10 9 8 7 6 5 4

1

0.8

0.2

0.4

α

C



276

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:

Fig. 42: Centro de gravedad

1 3

INF3

INF1

INF2

2 10 9 8 7 6 5 4

1

0.8

0.2

0.4

4.7467



277

5. ARQUITECTURA DEL SISTEMA IDSAI

En este capítulo se aborda la arquitectura del sistema IDSAI, y por tanto la

implantación de las clases y conceptos anteriormente descritos en una estructura global.

En el diseño de la arquitectura en capas de agentes inteligentes JADE y del

modelo de comportamientos en el sistema IDSAI, se aplican los conocimientos

adquiridos sobre la configuración e implantación de los sensores Snort en la red y

seguridad informática necesarios para la realización 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 diseño de sistemas distribuidos y el

desconocimiento del paradigma de los agentes inteligentes, por lo que se optó por la

tecnología más en boga en estos momentos sobre el tema: JADE. El middleware

JADE proporciona una capa estable sobre la que desarrollar aplicaciones

distribuidas que oculta al desarrollador la complejidad de las capas inferiores.

El proyecto IDSAI pretende ser un Sistema de Detección de Intrusos

distribuido, fiable, escalable y fácilmente adaptable a las nuevas amenazas que

puedan surgir en redes de ordenadores. JADE permite componer un sistema

distribuido a través del desarrollo de entidades software autónomas y colaborativas

en pos de alcanzar un objetivo común, por lo que es la base ideal para alcanzar

estos fines.

JADE proporciona facilidades en cuanto a la coordinación de agentes,

seguridad, comunicación, movilidad, redundancia, y muchos otros servicios básicos

en una arquitectura distribuida. Todo ello sobre un lenguaje cuyas virtudes son de



278

sobra conocidas como Java. Su carácter abierto (open-source) permite el desarrollo

de aplicaciones sobre esta tecnología sin coste alguno y la flexibilidad del código lo

hace verdaderamente atractivo.

La potencia de JADE estimula a su vez la aparición de nuevas ideas que

permiten ampliar la funcionalidad de un sistema en las diferentes fases del

desarrollo. Por otra parte, la tecnología Java simplifica la extensión de

funcionalidades y la incorporación de nuevas características a anteriores versiones

de un producto software. Al optar por estas tecnologías de desarrollo se garantiza

que el resultado no será un software estático y caduco en el tiempo, sino que será

fácilmente actualizable y podrá incorporar los avances y funcionalidades necesarias

para mantenerse al día durante un largo periodo de mantenimiento.



279

5.2. ARQUITECTURA DEL SISTEMA IDSAI

El sistema IDSAI es una distribución del popular Sistema de Detección de

Intrusos Snort, basada en agentes inteligentes JADE.

Como se ha descrito en el apartado 3.1: Sistemas de Detección de Intrusos,

un IDS es un sistema muy delicado que no se puede permitir la pérdida de paquetes

en situaciones críticas y por tanto al tener que garantizarle un mínimo de recursos

computacionales se recomienda instalar en máquinas dedicadas. Esto implica que

en general, no se instalen en la misma máquina pesadas interfaces gráficas u otros

módulos que puedan interferir con el Sistema de Detección de Intrusos. En estos

casos, se suele disponer de máquinas de monitorización remotas donde mostrar los

resultados.

Los productos básicos que devuelve un IDS al hombre encargado de su

supervisión 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 análisis en tiempo real de cientos de alertas de este tipo por parte de un

humano es prácticamente imposible y requeriría de una dedicación completa. El

hombre encargado de supervisar las alertas de un IDS debería limitarse a atender en



280

tiempo real las situaciones verdaderamente críticas dejando para una posterior

revisión offline el repaso de las alertas menos importantes. Pero, ¿cuándo se da una

situación crítica?, ¿cómo un analista puede darse cuenta de la criticidad de una

situación y de lo que realmente está ocurriendo en la red si de lo único que dispone

es de líneas y líneas de alertas inconexas?. Evidentemente se hace necesario un

análisis asistido por ordenador sobre esa cantidad de información que aporte al

administrador de red una visión general de la situación de la red en cada momento y

un sistema de navegación más exhaustivo que le aporte mayor detalle en los puntos

en que estime necesario. Estas funcionalidades tan avanzadas restarían capacidad

computacional si se ejecutaran en la misma máquina en la que corre un IDS lo cual

no es deseable, como antes se ha descrito.

El sistema IDSAI pretende dar una solución a este problema. Mediante una

arquitectura distribuida basada en agentes inteligentes se pueden repartir los

módulos de sensor IDS, análisis computacional de los resultados y presentación de

los mismos de forma estructurada, escalable y funcional.



281

5.2.1. MODELO DE ARQUITECTURA EN CAPAS

La distribución de las funcionalidades de un IDS se realiza generalmente

en una arquitectura distribuida basada en capas con diferentes funcionalidades a

distinto nivel. En los modelos basados en capas (como por ejemplo el conocido

modelo de red OSI), cada capa se alimenta de los productos de la capa inferior,

aportar una funcionalidad más general o especializada y devuelve sus resultados

a la capa superior.

Un típico modelo IDS distribuido basado en capas se compone de 3

niveles bien diferenciados [KOZI03]:

Fig. 43: Modelo de capas general de un IDS

Donde se distinguen las siguientes capas:

SUPERVISOR

ANALISTA

SENSOR

Capas IDS

distribuido

supervisor

red

paquetes

alertas

análisis

presentación



282

o Capa Sensor: Encargada de la captura del tráfico de red y generación

de alertas.

o Capa Analista: Encargada del análisis de las alertas.

o Capa Supervisor: Encargada de la presentación visual de los análisis

y la visión general del sistema al supervisor de la red.

Esta sencilla división de responsabilidades en capas es la base de todas

las arquitecturas distribuidas de IDS y en particular del sistema IDSAI.



283

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 implantación de los

elementos que forman cada capa, es sin duda la escalabilidad del sistema y la

capacidad de especialización que permite aportar cada agente, sobre todo en la

capa de análisis. De esta manera, el modelo de capas del sistema IDSAI, cambia

ligeramente respecto al esquema por defecto:

Fig. 44: Modelo de capas del sistema IDSAI

SUPERVISOR

ANALISTA

SENSOR (Snort)

supervisor

red

paquetes

alertas

análisis

presentación

INTÉRPRETE anomalías

RELOJ

Capas

IDSAI



284

En el sistema IDSAI se distinguen en detalle las siguientes capas y

funciones:

o Capa Sensor: Encargada de la captura del tráfico de red y generación

de alertas. Esta capa está compuesta exclusivamente por agentes

Sensor (ver apartado 4.2.2: Agente Sensor). En una implantación del

sistema IDSAI se pueden disponer cuantos agentes Sensor se

precisen en los segmentos de red que se deseen supervisar. La

instalación de un agente Sensor va íntimamente relacionada con la

configuración 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: Implantación de IDS y 3.5: Snort además de toda la

documentación posible relacionada con Snort.

o Capa Intérprete: Encargada de la primera manipulación de las alertas

registradas en la base de datos snortdb de cada sensor Snort. Esta

capa está compuesta exclusivamente por agentes Intérprete (ver

apartado 4.2.3: Agente Intérprete, y siguientes) de las diferentes

especialidades. En una implantación del sistema IDSAI se pueden

disponer cuantos agentes Intérprete 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 Intérprete se

arranca pasándole como parámetro la fiabilidad de las Anomalías

detectadas por su Sensor correspondiente.

El trabajo principal de un agente Intérprete 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 Anomalía (ver

apartado 4.1.2.4: Anomalía) cuyo principal atributo es dicha lista de



285

eventos. Los elementos de esta lista están caracterizados por su valor

de secuencia y fecha en que se registraron, por lo que gráficamente

se pueden representar de la siguiente manera:

Fig. 45: Ejemplo gráfico de Eventos de una Anomalía

En la figura 45 se simboliza con una línea gruesa horizontal el

tiempo de ventana dentro del cual el agente Intérprete recoge los

Eventos registrados, que se representan con óvalos numerados. El

número de cada Evento indica su número de secuencia a la hora de

ser detectado por el sensor Snort independientemente del tiempo,

que queda representado en el dibujo como la posición de los óvalos a

lo largo de la línea temporal horizontal.

Tras construir la lista de Eventos que forman la Anomalía el agente

Intérprete realiza una agrupación de los mismos en Ataques con un

criterio fijo (ver apartado 4.1.2.3: Ataque).

En el ejemplo representado gráficamente en la figura 45, las

discontinuidades en los números de secuencia significarían que el

tiempo de ventana

primer Evento

de la Anomalía

último Evento

de la Anomalía

1 2 6 7 8 5 15

más de 3 seg. más de 3 seg.



286

sensor Snort ha disparado alertas intermedias entre Eventos con la

firma de esta Anomalía, aunque temporalmente no estén

considerablemente separados. Por otra parte las grandes separaciones

temporales entre Eventos consecutivos desde el punto de vista de su

numeración significan que en el intervalo de tiempo entre el registro

de los dos Eventos el sensor Snort no ha disparado ninguna Alerta de

ningún tipo. Según el criterio de identificación de Ataques explicado

en el apartado 4.1.2.3: Ataque, la agrupación de Eventos en Ataques

sería de la siguiente manera:

Fig. 46: Anomalía con agrupación de Eventos en Ataques

o Capa Analista: Encargada del análisis de las estructuras Anomalía de

la clase de firma de su especialidad recibidas de los agentes

Intérpretes 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 implantación del sistema IDSAI se debe

disponer de un agente de este tipo, y sólo uno, por cada especialidad

más de 3 seg.

1 2

tiempo de ventana

6 7 8 5 15

más de 3 seg.

Ataque #1 Ataque #2 Ataque #3



287

de agente Intérprete desplegado en el sistema, independientemente de

su número. El agente Analista será el destinatario de todos los

Análisis procedentes de los agentes Intérpretes de su clase por lo que

debe tener un nombre fijo: analista<clase>.

La misión del agente Analista es la elaboración de estadísticas de las

Anomalías recibidas y la aplicación de heurísticas de la clase de

signature en la que está especializado para reducir la cantidad de

información de forma que sea más general y manejable a la hora de

procesarla. Esta información se integrará en la estructura Análisis

(ver apartado 4.1.2.5: Análisis), asociada a cada Anomalía. 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 Análisis elaborados en la ventana actual, con una valoración

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

Anomalías recibidas en las últimas 20 ventanas y de todos sus

Análisis correspondientes.

o Capa Supervisor: Encargada de realizar el Diagnóstico de la

situación de la ventana actual (ver apartado 4.1.2.8: Diagnóstico) en

base a los Resúmenes recibidos de los Analistas de la capa inferior.

Esta capa está compuesta exclusivamente por un sólo agente

Supervisor (ver apartado 4.2.17: Agente Supervisor) ya que al ser el

elemento de más alto nivel, es el que muestra la información más

general al usuario de forma centralizada. El agente Supervisor será el

destinatario de todos los Resúmenes procedentes de los agentes

Analistas, por lo que debe tener un nombre fijo: supervisor. En un

determinado momento, un agente Supervisor tiene conocimiento de



288

todos los Resúmenes recibidos en las últimas 20 ventanas y de todos

sus análisis correspondientes.

o Capa Reloj: Capa vertical (es decir, que da servicio a todas las capas

horizontales) encargada de sincronizar los agentes Intérpretes,

Analistas y Supervisor, marcándoles la ventana temporal. Esta capa

está compuesta exclusivamente por un sólo 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 información entre las diferentes capas de la

arquitectura se realiza a través de mensajes ACL, excepto entre las Sensor e

Intérprete, donde el intercambio de información se realiza mediante accesos

directos a la base de datos snortdb.

Los parámetros 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 intención del mensaje para los agentes que

necesitan distinguir entre mensajes de sincronización "sync" o

mensajes que contienen datos "data".

o performative: Valor numérico que permite pasar en el mensaje una

información adicional al contenido del mismo. Es utilizado por los

agentes Intérprete para propagar la fiabilidad de la información que

transmiten y por el agente Reloj para indicar el valor de la ventana

actual.



289

o content: Almacena la estructura de datos que el agente origen envía

al destino. Puede ser un array de Anomalías para un agente Analista,

una estructura Resumen para el agente Supervisor, el tamaño de la

ventana del sistema en los mensajes de sincronización o una simple

instrucción de "ALTA" o "BAJA" para la lista de agentes vivos del

Reloj. En función del valor del campo language y de la naturaleza del

comportamiento que comprueba el buzón de correo, el agente

destinatario sabrá cómo interpretar el contenido del mensaje y actuar

en consecuencia.

El anexo 3: Diagrama de la arquitectura muestra un esquema ejemplo de

implantación 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 Intérpretes de diferentes tipos asociados a los

agentes Sensor (en total, 5), 3 agentes Analistas de los mismos tipos que los

Intérpretes y 1 agente Supervisor.

En el diagrama se indica, bajo los agentes, el esquema de los nombres

que deben tener y sus parámetros de arranque más característicos. También se

representa el flujo de la información 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.



290

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 cíclicos y periódicos que no terminan mientras los agentes

estén 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 según una respuesta determinista y

homogénea para cualquier tipo de evento. Un ejemplo de éstos, es el

comportamiento LimpiarBD propio del agente Sensor (no incorporado en la

versión final del sistema IDSAI por cuestiones de rendimiento). LimpiarBD

ejecuta periódicamente, independientemente de la sincronización 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 simultáneo (y

de hecho es imposible que lo sea), la sincronización de sus comportamientos

debe estar asistida por un agente común que haga esta función. 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 envía

periódicamente, según el tamaño fijado de la ventana, un mensaje a todos los

agentes vivos con el valor de la ventana actual. Para poder saber qué agentes

están 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 envían los agentes con necesidad de sincronización al arrancarse

y morir, respectivamente.



291

En el momento en que un agente recibe un mensaje de sincronización

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 Intérpretes reaccionan ante un mensaje de sincronización

(comienzo de nueva ventana temporal) ejecutando el método

obtenerAnomalias() de la clase AnomaliaDAO para obtener la lista de

Anomalías del tipo de firma en que están especializados, correspondientes a la

última ventana temporal. Una vez disponen de ella, la envían 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 sincronización

(comienzo de nueva ventana temporal) realizando una serie de operaciones de

mantenimiento del registro de Anomalías y Análisis que mantienen en memoria

antes de ponerse a la espera de las nuevas Anomalías de la ventana actual que les

deben enviar los agentes Intérpretes. Una vez las reciben, construyen los

Análisis correspondientes a las Anomalías recibidas y elaboran el Resumen, que

acto seguido envían al agente Supervisor. Tras el envío del Resumen, se quedan

a la espera de una nueva ventana temporal.

Finalmente, el agente Supervisor reacciona ante un mensaje de

sincronización (comienzo de nueva ventana temporal) realizando el Diagnóstico

de la ventana anterior, ya que sólo al principio de esta ventana es cuando puede

estar seguro de haber recibido todos los Resúmenes procedentes de los agentes

Analistas del ciclo anterior. En esta acción 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 Intérprete esperará hasta la siguiente



292

ventana para detectar la Anomalía, y cuando el Resumen correspondiente llegue

al agente Supervisor, éste no diagnosticará la situación hasta una ventana

temporal más tarde. El retardo del agente Supervisor es inevitable si se pretende

montar una arquitectura escalable donde no importe el número de agentes

arrancados en las capas intermedias. Tras mostrar los resultados del Diagnóstico

al usuario a través de la interfaz gráfica, el agente Supervisor procede al

mantenimiento del registro de Resúmenes y Diagnósticos que mantiene en

memoria antes de ponerse a las espera de nuevos Resúmenes de la ventana

actual que le deben enviar los agentes Analistas. Cada Resumen recibido es

almacenado en el registro de Resúmenes para ser procesados al comienzo de la

próxima 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 Intérpretes de diferentes tipos asociados al agente Sensor, 2

agentes Analistas de los mismos tipos que los Intérpretes y 1 agente Supervisor.

En el diagrama se representan, bajo los agentes en líneas verticales, los

comportamientos que implementan y las acciones que llevan a cabo antes

descritas (envío de mensajes y procesos) en el tiempo que comprende la ventana

temporal.



293

6. DISTRIBUCIÓN DEL PROYECTO IDSAI

El proyecto IDSAI se distribuye en soporte electrónico 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 configuración) necesarios para la

implantación 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:



294

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 ejecución del entorno de desarrollo JADE.

o instalar.bat: Script ejecutable de instalación 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 típicos en un host Sensor: equipo dedicado sobre el

que corre un agente Sensor y una serie de agentes Intérpretes,



295

correspondientes a las capas Sensor e Intérprete 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 gestión centralizada de la red, ya que no

implican una alta carga computacional y la presentación 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 máquina 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 Intérpretes (uno de cada tipo), 6 agentes Analistas (uno de

cada tipo), 1 agente Supervisor y 1 agente Reloj. La ejecución 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 estrés 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 distribución y que debe



296

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 ejecución del script automatiza la actualización

de la fecha del sistema al momento preciso por lo que se debe

restablecer manualmente al terminar la sesión.

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 misceláneos del sistema IDSAI:

� Carpeta de imágenes e iconos de la interfaz del sistema.

� snortdb.sql: Script de construcción del esquema de la base de

datos snortdb.

� IDSAI.conf: Fichero de configuración de la instancia de Snort

que lo vincule en su arranque.

o lib: Contiene librerías de funciones que importan las diferentes clases

del sistema: librerías JADE y driver de conexión con la base de datos

MySQL.



297

o log: Contiene los archivos de bitácora donde los diferentes agentes

del sistema IDSAI vuelcan la información que manipulan una vez

deja de estar disponible a través de la interfaz.

o doc: Contiene la documentación del proyecto:

� Portada PFC: Portada del proyecto y hoja de firmas, según la

Normativa de proyectos Fin de Carrera.

� Resumen PFC: Resumen del proyecto en castellano e inglés,

según la Normativa de proyectos Fin de Carrera.

� Proyecto Fin de Carrera: El grueso de la presente

documentación.

� Carpeta ANEXOS:

• Conjuntos borrosos IDSAI.

• Diagrama de clases.

• Diagrama de la arquitectura.

• Diagrama de secuencia.

• Esquema snortdb.

• Signatures IDSAI (Snort)



298

6.2. CARPETA DE INSTALABLES INSTALACION IDSAI

La carpeta de instalables INSTALACION IDSAI contiene una recopilación

de recursos (programas externos y ficheros de configuración) necesarios para la

implantación de una plataforma de agentes IDSAI.

Todos los productos que se proporcionan en esta compilación son de libre

distribución o pueden obtenerse de forma gratuita por lo que no se viola ninguna

ley de derechos de autor o similares:



299

Fig. 48: Carpeta de instalables INSTALACION IDSAI

Donde los ficheros:

o ataqueIDSAI.pcap: Captura de red con presencia de ataques intrusos

para la realización de pruebas del sistema IDSAI.



300

o IDSAI.conf: Fichero de configuración básico de los sensores Snort

del sistema IDSAI, que habrá que adaptar según la arquitectura de

red en la que se pretenda implantar.

o JADE-all-3.4.zip: Fichero comprimido que contiene las librerías

básicas de la distribución 3.4 de JADE. Estas librerías ya están

incorporadas en la carpeta de proyecto IDSAI en la subcarpeta lib.

o jdk-1_5_0_10-windows-i586-p.exe: Instalable de la versión 5.0 del

JDK de Java, necesario para el desarrollo e interpretación del código

Java en que consiste el proyecto.

o MySQL-5.0.27-win32-Setup.exe: Instalable de la versión 5.0 del

Sistema Gestor de Bases de datos MySQL.

o mysql-connector-java-5.0.4-bin.jar: Driver de conexión 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 gráfica.

o Snort_2_6_1_1_Installer.exe: Instalable de la versión 2.6.1.1 del IDS

Snort.

o snort_manual.pdf: Manual de instalación, configuración y uso del

IDS Snort, necesario para sacarle el máximo 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

según el esquema snortdb.



301

o WinPcap_3_0.exe: Instalable de la librería de captura de paquetes

estándar 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 distribución original de Snort no

incorpora por defecto y debe hacerse de forma manual.

o Programas ataques: Contiene los instalables de los programas de

intrusión Nessus y Nmap utilizados en las pruebas del sistema IDSAI

durante su desarrollo.



302

7. MANUAL DE INSTALACIÓN 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 Detección de Intrusos: El IDS Snort 2.6.1.1 es la herramienta

escogida para este subsistema. La configuración de Snort no es trivial y se

requieren amplios conocimientos sobre la aplicación por lo que se

recomienda leer la documentación relacionada así como el apartado 3.5:

Snort. Una instalación del sistema IDSAI en un entorno real, requiere de

varias instancias de Snort dispuestas en diferentes segmentos de red, en este

aspecto también se recomienda leer la documentación relacionada así como

el apartado 3.1: Sistemas de Detección 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 instalación asociada del

SGBD MySQL 5.0.27, con un esquema de la base de datos snortdb ya

instanciado donde volcar los resultados del IDS. También 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 ejecución de los agentes

diseñados, será necesario contar con las librerías Java JADE, ya

incorporadas en la carpeta lib de la estructura del proyecto.



303

7.1. INSTALACIÓN DE LA MÁQUINA VIRTUAL JAVA

El sistema IDSAI basa su despliegue en agentes Java JADE, por

lo que para su ejecución en cada una de las máquinas que albergan

entidades de este tipo es necesaria la presencia de una Máquina Virtual

Java (JVM, en inglés, Java Virtual Machine).

Si no se cuenta con una JVM instalada previamente en el sistema, la

distribución de la aplicación proporciona una copia de la versión 5.0. Para su

instalación en cada máquina implicada en el sistema IDSAI se debe ejecutar el

instalable jdk-1_5_0_10-windows-i586-p.exe, que se proporciona con la

distribución de la aplicación:

Los pasos a seguir durante la instalación son los siguientes:

1. Aceptar los términos de la licencia de Sun Microsystems.

2. Seleccionar los componentes de la JVM a instalar y la ruta, aunque es

recomendable dejar los parámetros por defecto y no compromete al

sistema.

3. Continuar con la instalación de la JRE (Java Runtime Environment),

componente básico de la JVM por ser el elemento encargado de la

interpretación en tiempo real del código Java. De nuevo, es

recomendable dejar los parámetros de componentes y ruta de

instalación con los valores por defecto.

4. Continuar hasta el final de la instalación.



304

7.2. INSTALACIÓN DEL IDS SNORT

La instalación de un IDS, y en particular la

del IDS Snort por ofrecer tantas opciones de

configuración, no es trivial y requiere una importante inversión 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 instalación del software Snort en al

menos una máquina 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 distribución de la

aplicación:


1. Aceptar los términos de la licencia GNU.

2. Seleccionar un modo de logging a base de datos MySQL (opción por

defecto).

3. Seleccionar todos los componentes de Snort para la instalación

(seleccionados todos por defecto).

4. Determinar como la carpeta donde se instalará el software la carpeta

por defecto: C:\Snort.


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é



305

instalada la librería de captura estándar libpcap. Si no se cuenta con ella

previamente (suele instalarse automáticamente con otras aplicaciones de sniffing de

red de libre distribución como Ethereal o Wireshark), debe instalarse ahora. Para

ello se debe ejecutar el instalable WinPcap_3_0, que se proporciona con la

distribución de la aplicación:


1. Aceptar los términos de la licencia de NetGroup


Llegados a este punto, el IDS Snort puede funcionar correctamente. Ahora

es el momento de configurar el sensor Snort adecuadamente para sacarle el máximo

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 distribución de la aplicación se

proporciona la carpeta Snort rules, que contiene los ficheros básicos de reglas que

habrá que importar manualmente a la carpeta C:\Snort\rules. Por supuesto, si el

administrador del sistema IDSAI desea añadir algún fichero de reglas propio o

modificar los ya existentes, puede hacerlo sin problema, pero debe tenerlo en

cuenta para plasmarlo en el fichero de configuración de arranque de Snort.



306

Fig. 49: Importación manual de ficheros de reglas.

La ejecución de Snort en modo NIDS requiere de un fichero de

configuración .conf que especifique detalladamente sus parámetros de arranque. La

instalación por defecto de Snort incluye en el fichero C:\Snort\etc un archivo

snort.conf con un ejemplo de configuración paso a paso que se puede aprovechar

para adaptarlo a la configuración de red a administrar. Se recomienda leer

detenidamente el contenido del fichero para aprender los detalles de la

configuración de Snort antes de incorporar al directorio antes mencionado el

fichero de configuración del sistema IDSAI que proporciona la distribución de la

aplicación. Este proceso se debe hacer manualmente, copiando el fichero

IDSAI.conf en la carpeta C:\Snort\etc.



307

Fig. 50: Importación manual del fichero de configuración.

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 características de tráfico en cada segmento de red:

o Variable HOME_NET 192.168.20.0/24. Esta variable debe

modificarse con la dirección 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.



308

o Demás variables de configuración. Deben adaptarse a los valores

apropiados para la implantación 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 Configuración de Preprocesadores. La configuración de los

preprocesadores que se especifican en el fichero no tiene por qué ser

la más apropiada para la red en la que se implante el sistema. Es muy

recomendable repasar los parámetros de los preprocesadores para

optimizarlos según las necesidades de la red, ya que en el ejemplo se

inicializan con parámetros por defecto y de carácter general.

o Configuración de módulos 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 contraseña dedicados.

o Inclusión de ficheros de reglas. La configuración 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, están en la carpeta

C:\snort\rules.

La base de datos MySQL snortdb no es el único módulo 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, además de en la base de datos



309

snortdb, los sensores Snort escriban sus alertas en un fichero alert.ids y las

incidencias de cada captura en ficheros snort.log. La creación de esta carpeta no

será necesaria si no se requiere esta salida en el comando de ejecución 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 según nuestra instalación es C:\Snort\bin:



310

Fig. 51: Actualización manual del Path del sistema con la ruta de Snort.

Antes de seguir adelante con la instalación de los demás 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.



311

7.3. INSTALACIÓN DEL SGBD MySQL

La instalación de una instancia de MySQL para el

registro de alertas de Snort y la interactuación con los agentes del sistema IDSAI

tiene una serie de particularidades de configuración que se deben considerar para su

correcto funcionamiento.

Como primera medida, es necesaria la instalación del software MySQL en

cada uno de los host Sensor de la red (máquinas 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 distribución de la aplicación:


1. Seleccionar el modo de instalación por defecto (Typical) y proceder.

2. Registrarse on-line si se desea o saltarse este paso.

3. Continuar hasta el final de la instalación y pasar al proceso de

configuración.

4. Seleccionar el modo de configuración detallada (Detailed

Configuration).

5. Seleccionar el modo de servicio en máquina de desarrollo (Developer

Machine).

6. Seleccionar el tipo de uso de las bases de datos como de propósito

general (Multifunctional Database).



312

7. Seleccionar la ruta de ubicación de las bases de datos (se recomienda

la ruta de instalación por defecto).

8. Seleccionar como número de conexiones concurrentes, tantas como

agentes Intérpretes se deseen asociar a cada instancia de la base de

datos, más una, ya que hay que tener en cuenta el acceso continuo a

la misma por parte del sensor Snort. Puesto que en la presente versión

de IDSAI se han desarrollado 6 especialidades de agente Intérprete, y

no tiene sentido asociar dos Intérpretes del mismo tipo a la misma

base de datos (porque darían el mismo resultado), basta con permitir

hasta 7 conexiones simultáneas, aunque se recomienda alguna más

para posteriores ampliaciones. El valor por defecto (Decission

Support) es de 20, por lo que resultan más que suficientes para esta

distribución.

9. Seleccionar un modo de trabajo en red. Los agentes del sistema

IDSAI que acceden a las bases de datos (agentes Sensor e Intérpretes)

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 conexión 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 estándar (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 añadir el directorio donde se

encuentra el arranque de MySQL en el PATH del sistema si se desea

trabajar mediante la consola. Más adelante se procederá a la



313

instalación de una serie de herramientas de administración y acceso al

SGBD que permitan la manipulación de las bases de datos desde una

agradable interfaz gráfica, por lo que deja de ser necesario el acceso a

través de la línea de comandos.

12. Modificar las opciones de seguridad introduciendo una nueva

contraseña raíz y confirmándola. No será necesario ni deseable crear

una cuenta de usuario anónimo, por cuestiones de seguridad.


La manipulación y configuración de una base de datos MySQL es un trabajo

tedioso si se realiza desde la consola del sistema, por lo que resulta muy cómodo

hacerlo desde una interfaz gráfica. La distribución de la aplicación IDSAI

proporciona una copia de la interfaz gráfica oficial de MySQL en el instalable

mysql-gui-tools-5.0-r8-win32.msi, de instalación opcional:


1. Aceptar los términos de la licencia MySQL.

2. Seleccionar la ruta de instalación de las herramientas. (Se recomienda

la ruta de instalación por defecto).

3. Seleccionar el modo de instalación completo que incluye todos los

componentes gráficos necesarios para la administración de la base de

datos




314

El resultado de la instalación es que disponemos de una serie de programas

que nos facilitarán el acceso a la información de las bases de datos de forma directa

y nos ayudarán en la configuración de la base de datos snortdb:

Fig. 52: Programas MySQL instalados.

El siguiente punto es la configuración de la base de datos snortdb, donde el

sensor Snort vuelca los resultados y los agentes Intérpretes los recogen para su

procesamiento. Para ello debemos abrir el programa recién instalado MySQL

Administrator, con un acceso local (localhost) al puerto especificado para el

servicio MySQL, introduciendo el nombre y contraseña del usuario raíz.

El menú de la aplicación 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 configuración del acceso a la base de datos

snortdb es la pestaña Administración de Usuarios (User Administration). Entrando

en este apartado, se debe crear un nuevo usuario de nombre "snort" y contraseña

"snort", ya que es la autenticación que posteriormente utilizarán los agentes

Intérpretes para acceder a la base de datos snortdb:



315

Fig. 53: Creación 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 distribución de

la aplicación 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 según el esquema snortdb (ver

anexo 5: Esquema snortdb).

La ejecución del script snortdb.sql se puede realizar cómodamente mediante

la herramienta MySQL Query Browser. Para ello nos conectamos mediante un

acceso local (localhost) al servicio MySQL, introduciendo el nombre y contraseña

del usuario raíz, 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 distribución de la aplicación.



316

Fig. 54: Carga del script snortdb.sql.

Una vez se ha cargado el script snortdb.sql se procede a su ejecución en el

botón 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 información del

sensor Snort.



317

7.4. INSTALACIÓN DE LA PLATAFORMA IDSAI

La instalación de la plataforma de agentes inteligentes IDSAI es muy

sencilla. Desde el soporte de la distribución, 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 funcionarán

adecuadamente. Copiar la carpeta entera y no de forma selectiva significará que en

muchos casos habrá instalados en una máquina más tipos de agentes de los que se

van a correr en ella. Por cuestión de flexibilidad, si se pretende introducir un

cambio en el esquema de agentes planificado en un principio, resulta más cómodo

disponer de todas las posibilidades en todos los equipos. De esta manera se

simplifica la instalación de los agentes sin comprometer la capacidad del equipo, ya

que el volumen de código es muy pequeño.

Llegados a este punto, la instalación de los componentes básicos sobre los

que ejecutar el sistema IDSAI en las diferentes máquinas de la distribución está

completa por lo que el arranque y uso de los diferentes agentes que lo conforman

será tarea exclusiva del administrador del sistema desde el punto de vista del

usuario.



318

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 (típicamente administradores de red y

personal de seguridad informática) tanto del tema de los Sistemas de Detección de

Intrusos como de los sistemas distribuidos en entornos de red.

Por las particularidades que puede presentar la red a supervisar con la instalación

del sistema IDSAI, la puesta a punto de los agentes forma parte del trabajo del

administrador de la red desde el punto de vista del usuario:

- Configuración de los sensores Snort.

- Diseño del plan de distribución de los agentes de la plataforma. Sobre este

punto se ha hecho hincapié en el apartado 3.1.3: Implantación de IDS, por lo

que no se volverá a insistir en este punto.

- Edición y ejecución de los scripts de arranque de los agentes de la

plataforma.

Una vez estén corriendo los agentes en los diferentes equipos estratégicamente

distribuidos por la red, el usuario debe conocer las particularidades de uso de la

herramienta, para poder interpretar adecuadamente los resultados de la ejecución y saber

utilizar la interfaz de los agentes para navegar por los resultados y la información

detallada de las anomalías detectadas en la red.



319

8.1. CONFIGURACIÓN DE LOS SENSORES

La configuración 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 configuración debe tener un amplio conocimiento

sobre la red a supervisar, el tipo de tráfico autorizado en la misma, su organización

y métodos de seguridad perimetral, etc. Esto resulta fundamental a la hora de hacer

una distribución de sensores en zonas estratégicas de la red tal y como se explica en

el apartado 3.1.3: Implantación de IDS.

La configuración de los sensores Snort para adaptarlos a las particularidades

de la red en cuestión no es trivial. El administrador de red deberá considerar cada

uno de los parámetros de Snort presentes en el fichero de configuración de cada

sensor C:\Snort\etc\IDSAI.conf y ajustarlos adecuadamente según las necesidades

de inspección, según se hace una breve introducción en el apartado 3.5.2:

Componentes de Snort.

Puesto que ya se ha insistido en este tema en anteriores apartados de la

presente documentación, este punto no se desarrollará más en detalle.



320

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 máquinas.

El arranque de agentes en la plataforma IDSAI se realiza mediante scripts

de ejecución de líneas de comando. Aunque el proceso de edición de un script sea

un trabajo tedioso e incómodo, en la distribución 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 parámetros de inicialización por la consola.

Evidentemente es necesario que el encargado de la manipulación del sistema IDSAI

tenga los conocimientos básicos de arranque y gestión de agentes JADE, por lo que

también es recomendable estar familiarizado con las herramientas que acompañan

al middleware JADE, sobre todo con la interfaz de gestión de la plataforma RMA

que se recomienda arrancar en algún host poco cargado de la plataforma para

supervisar la actividad del sistema de forma centralizada.

La distribución original de IDSAI requiere que en las máquinas que

incorporan una instancia del IDS Snort, el arranque de ésta se haga mediante un

agente Sensor (ver apartado 4.2.2: Agente Sensor) acompañado por sus agentes

Intérpretes (ver apartado 4.2.3: Agente Intérprete, 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 parámetros de arranque:



321

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 parámetro del Agente Sensor

indica el fichero de captura de red que se proporciona con la distribución del

proyecto IDSAI. Evidentemente, este script puede ser editado arrancando otros

agentes y modificando sus parámetros según el plan de implantación del sistema.

La distribución original de IDSAI sugiere que el arranque de los agentes

Analistas (ver apartado 4.2.10: Agente Analista, y siguientes), encargados de

procesar la información recogida por los agentes Intérpretes, se realice en máquinas

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



322

analistaattempted-dos : AgenteAnalistaAttemptedDos

analistabad-unknown : AgenteAnalistaBadUnknown

analista-otros : AgenteAnalistaOtros

Evidentemente, este script puede ser editado arrancando otros agentes según

el plan de implantación del sistema.

Por último, la distribución original de IDSAI, sugiere que el arranque del

agente Supervisor (ver apartado 4.2.17: Agente Supervisor), necesario para la

monitorización del estado de la red, se realice en una máquina dedicada y de fácil

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 parámetros de arranque:

supervisor : AgenteSupervisor

reloj : AgenteReloj(20)

Donde el valor especificado como parámetro del Agente Reloj indica el

periodo de la ventana temporal de sincronización de los agentes de la plataforma.

La carga computacional que supone el arranque del agente Reloj es lo

suficientemente pequeña como para que pueda convivir con el Supervisor. Además

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



323

a que este equipo será supervisado de cerca por el encargado de la red, será

interesante que también se arranque en él el agente RMA, que facilite la gestión 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 parámetros según el

plan de implantación del sistema.

Estos tres scripts ejemplo permiten el arranque de una plataforma de agentes

IDSAI funcional y se dejan abiertos a la edición por parte del usuario para que

realice la configuración que más le convenga. Por supuesto habrá que modificar en

los scripts correspondientes al host Sensor y al host Analista la opción de -host XXX

poniendo en su lugar el nombre del equipo Supervisor, que se identifica así como el

contenedor principal de la plataforma. La ejecución de los tres scripts ejemplo en

los diferentes equipos de la red da lugar a una implantación del sistema IDSAI

como muestra la siguiente figura:



324

Fig. 55: Implantación ejemplo del sistema IDSAI.

En la imagen se representa, como Contenedor(es)X, cada uno de los equipos

Sensores de la red, donde se arrancarán las instancias de Snort y de los agentes

Sensor e Intérpretes. El arranque de estos agentes es producto de la ejecución 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

RED

Contenedor(es)X (Host Sensor)

- sensorx

- interpreteattempted-reconx

- interpreteunknown-classx

- interpreteattempted-adminx

- interpreteattempted-dosx

- interpretebad-unknownx

- interprete-otrosx

Contenedor Principal (Host Supervisor)

- supervisor

- reloj

Contenedor1 (Host Analista)

- analistaattempted-recon

- analistaunknown-class

- analistaattempted-admin

- analistaattempted-dos

- analistabad-unknown

- analista-otros



325

anomalías de la red utilizando sus interfaces gráficas. 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.



326

8.3. EXPLOTACIÓN DEL SISTEMA

Una vez arrancados los agentes de la plataforma, los resultados sobre la

situación de la red no tardarán en aparecer en la interfaz gráfica del agente

Supervisor. Los informes en tiempo real del estado de la seguridad del sistema

deben servir al administrador de red para tomar decisiones rápidas y precisas en una

situación de crisis, ya que en ellos se identifica inequívocamente a la víctima y/o al

atacante junto al tipo de actividad presente que se debe intervenir e investigar.

Este es el verdadero trabajo del hombre detrás del sistema IDSAI. Como

cualquier otro Sistema de Detección de Intrusos, IDSAI se limita a informar del

estado de la red al administrador de la misma para que éste tome las decisiones más

apropiadas, si bien el carácter distribuido de este sistema permite la integración

inteligente y especializada de la información proporcionada por múltiples sensores

en vez de uno sólo. Además la interfaz de los agentes de la plataforma IDSAI

permite la investigación en detalle de las causas de una situación anómala llegando

a nivel de alertas, que clasificadas por tipos de patrón de ataque dan una visión más

veraz de la situación sin pérdida de información. Los siguientes apartados servirán

para explicar al usuario la forma de acceder a toda la información que proporcionan

los agentes mediante la navegación por sus diferentes ventanas.



327

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 visión más general de la situación de la

red, mostrando en cada ventana temporal la información que devuelve en la

estructura Diagnóstico (ver apartado 4.1.2.8: Diagnóstico). Por ser el agente de

más alto nivel (más cercano al usuario), proporciona la interfaz gráfica más

completa de los agentes IDSAI y será el lugar de partida para el descubrimiento

de situaciones anómalas de la red por parte del administrador del sistema.

La siguiente imagen representa la interfaz principal del agente Supervisor

en un momento de la ejecución:



328

Fig. 56: Interfaz del agente Supervisor.

La interfaz gráfica del agente Supervisor consiste en una ventana en la

que destacan los siguientes elementos:

1. Nombre unívoco del agente. Fundamental para su identificación en el

agente RMA o para el envío de mensajes ACL.

1

2

3

4

5

6



329

2. Log de registro de Diagnósticos. En él se imprime, en cada ventana

temporal, la información más relevante y general del Diagnóstico

actual. Los datos listados se muestran en la siguiente estructura:

VENTANA TEMPORAL (<nº ventana>) en <fecha y hora>

<listado de inferencias>

Estado actual:

<descripción del estado>

Diagnóstico comparativo:

<diagnóstico 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 Diagnóstico. Hay

que recordar que un Resumen puede propagar más 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, según el color

indicado en la leyenda del diagrama gráfico.

� descripción del estado: es el valor del atributo estado del

Diagnóstico actual. Le sigue el valor numérico de la criticidad

final del sistema una vez se han integrado todas las



330

inferencias por el método del centro de gravedad. En las dos

siguientes líneas se especifican las direcciones IP del atacante

y víctima principales de la ventana actual, esto es, los que

mayor número de firmas protagonizan entre las acusaciones

correspondientes a la ventana actual. Toda esta información

se representa coloreada según sea el valor borroso de la

criticidad de la situación: ALTA→rojo, MEDIA→naranja,

BAJA→verde. La descripción del estado es la información

más importante que se muestra en cada ventana temporal y a

la que el administrador del sistema deberá dedicar mayor

atención para prever situaciones de alta criticidad y ser capaz

de reaccionar rápida y eficazmente.

� diagnostico comparativo: es el resultado de comparar el

estado actual del sistema y el indicado en el Diagnóstico

anterior. Se indica el cambio de situación y de atacante y

víctima principales, si procede.

3. Lienzo gráfico de representación de la situación. Sobre un círculo

negro se puede ver, en cada ventana temporal, el conjunto de hosts

implicados en las anomalías detectadas en el sistema. Las líneas 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 víctima

destacada con un cuadrado de mayor grosor y la cantidad de firmas

diferentes de dicho tipo detectadas entre el atacante y la víctima con el

grosor de la línea. 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



331

IP que se han declarado víctima principal desde el arranque del

agente. La información que se proporciona de forma gráfica es fácil de

interpretar y se corresponde fielmente con la descripción del estado

explicada anteriormente.

4. Tabla de últimos Diagnósticos. En ella se listan los Diagnósticos

realizados en las últimas 20 ventanas indicando explícitamente la

ventana y la fecha en la que se hicieron. Los Diagnósticos 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 Diagnóstico en particular, el usuario

debe hacer clic sobre su registro, tras lo que se abre la siguiente

ventana:

Fig. 57: Detalles de Diagnóstico.

4.1

4.2

4.3

4.4



332

Los detalles del Diagnóstico se muestran en la interfaz anterior, en la


1.1. Identificador del detalle. Incluye una referencia a la ventana

y la fecha y hora del momento en que se registra el

Diagnóstico.

1.2. Lista de atacantes y víctimas. Enumeración de las

direcciones IP de los hosts atacantes y víctimas presentes en

la situación de la red. Cada valor va acompañado de la

proporción de patrones detectados que protagonizan desde

su posición.

1.3. Lienzo gráfico de representación del Diagnóstico. Se trata

de un panel gráfico idéntico al que apareció en la interfaz

principal del agente Supervisor cuando se registró el

Diagnóstico que se está referenciando. No se incluyen las

listas de top 5 ataques y víctimas por carecer de interés en

una situación pasada.

1.4. Tabla de Acusaciones del Diagnóstico. En ella se listan las

Acusaciones (ver apartado 4.1.2.6: Acusación) de las

Anomalías detectadas en la ventana temporal del

Diagnóstico en cuestión. Cada casilla de la tabla muestra el

número de firmas diferentes detectadas en la ventana

temporal en las que la dirección IP correspondiente a la

cabecera de la fila es el atacante y la correspondiente a la

cabecera de la columna es la víctima. Para acceder a los

detalles de cada Acusación en particular el usuario debe



333

hacer clic sobre su celda, tras lo que se abre la siguiente

ventana:

Fig. 58: Detalles de Acusación en Diagnóstico.

Los detalles de la Acusación en un Diagnóstico 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 Acusación en el

formato IP atacante -> IP víctima. A continuación se

4.4.1

4.4.2



334

indica la Prioridad media de las Signatures (ver

apartado 4.1.2.2: Signature) listadas a continuación.

1.4.2. Puesto que el Diagnóstico es la integración de todos

los Resúmenes de los diferentes tipos de firma, los

Análisis (ver apartado 4.1.2.5: Análisis) implicados

en la Acusación se listan organizados por su clase de

Signature, acompañados del par de valores puerto

atacante -> puerto víctima.

5. Tabla de Resúmenes recibidos. En ella se listan los Resúmenes

recibidos en las últimas 20 ventanas temporales indicando

explícitamente la ventana y la fecha en la que se hicieron, la

especialidad del mismo, la prioridad y compactación de las alertas que

representa y la fiabilidad de su fuente de datos. Los Resúmenes

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:



335

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 Análisis (ver apartado 4.1.2.5: Análisis). Listado

de información estadística sobre los análisis relacionados

con el Resumen en cuestión. De cada Análisis se indica su

5.1

5.2

5.3



336

signature y los valores del presunto atacante (atributo

iporigmaxratio), de la presunta víctima (atributo

ipdestmaxratio), del puerto origen (atributo

portorigmaxratio), y del puerto destino (atributo

portdestmaxratio), todos ellos acompañados de su

proporción respecto al total en el conjunto de Eventos (ver

apartado 4.1.2.1: Evento), de su Anomalía (ver apartado

4.1.2.4: Anomalía) asociada.

5.3. Tabla de Acusaciones del Resumen. En ella se listan las

Acusaciones (ver apartado 4.1.2.6: Acusación) de las

Anomalías cuyos Análisis conforman el Resumen en

cuestión. Cada casilla de la tabla muestra el número de

signatures de la misma clase que se dan entre los Análisis

que componen el Resumen, en los que la dirección IP

correspondiente a la cabecera de la fila es el atacante y la

correspondiente a la cabecera de la columna es la víctima.

Para acceder a los detalles de cada Acusación en particular

el usuario debe hacer clic sobre su celda, tras lo que se abre

la siguiente ventana:

Fig. 60: Detalles de Acusación en Resumen.

5.3.1

5.3.2



337

Los detalles de la Acusación 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

Acusación en el formato IP atacante -> IP víctima. A

continuación se indica la Prioridad media de las

Signatures (ver apartado 4.1.2.2: Signature)

listadas a continuación.

5.3.2. Los Análisis (ver apartado 4.1.2.5: Análisis) que

componen el Resumen, implicados en la Acusación

se listan organizados por su clase de Signature,

acompañados del par de valores puerto atacante ->

puerto víctima.

6. Botones de control del agente. Permiten llevar a cabo determinadas

acciones sobre la interfaz y el agente Supervisor:

• Botón Limpiar Log: Al pulsarlo, el usuario deja el Log de registro

de Diagnósticos de la interfaz gráfica del agente Supervisor en

blanco. El Log del programa en general es de tamaño ilimitado,

por lo que tras una ejecución continua y prolongada es cómodo

limpiarlo para eliminar del mismo la notificación de Diagnósticos

obsoletos.

• Botón Matar agente: Al pulsarlo, el agente Supervisor ejecuta su

método takedown(), y muere. No obstante la interfaz del mismo

queda abierta y sus botones de control desactivados. También se

puede matar el agente cerrando la ventana de su interfaz gráfica



338

pulsando en el aspa de la esquina superior derecha de la ventana.

Al terminar la ejecución 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 sincronización. No

es así para el resto de agentes de la plataforma, que seguirán

enviándole mensajes aunque el destinatario ya no exista.

Las imágenes correspondientes a la interfaz gráfica del agente Supervisor

que se han mostrado en este punto, corresponden a una ejecución 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 análisis, según reza el código de colores: attempted-recon,

otros, unknown-class y bad-unknown. La desborrosificación de ese conjunto de

inferencias (entre las que predomina el valor ALTA), da lugar a una criticidad

ALTA, indicada numéricamente y con las letras del estado actual en rojo. Se

enuncia el atacante y víctima principales (192.168.20.103 y 192.168.20.199

respectivamente) y se explica textualmente que el estado "Muchos atacantes y

muchas víctimas. Pareja destacada" es el mismo que en la ventana anterior con

los mismos hosts protagonistas.

Toda esta información se completa con el esquema gráfico que

representa el estado de la red en cuanto a ataques, ya que muestra a grandes

rasgos las acusaciones detectadas en las comunicaciones. Fijándonos en el

ejemplo, podemos comprobar que el atacante principal está participando en

múltiples ataques contra el host víctima principal de tipo attempted-recon, bad-

unknown 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é



339

está ocurriendo, por lo que habrá que investigar más a fondo. Este vistazo al

gráfico permite tomar medidas reactivas concretas, interviniendo contra el

atacante o protegiendo a la víctima contra los tipos de ataque que se están

produciendo. El gráfico en este caso es un poco confuso, ya que se están 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 ejecución, puede investigarlo en cualquier

momento haciendo clic sobre el registro correspondiente a esta ventana en la

tabla de Diagnósticos, tras lo que se abrirá la ventana representada en la figura

57. Esta ventana muestra la información del Diagnóstico 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 gráfico la situación más 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 acusación

(atacantes→, víctimas↓), se entra en los detalles, abriéndose 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

múltiples métodos (UDP, TCP, ping, XMAS...) además de un ataque XMAS

scan detectado por el preprocesador stream4 que corrobora la situación de

reconocimiento que está sufriendo la víctima. Cada signature va acompañada de

los puertos origen y destino predominantes que se están utilizando en cada

ataque, lo que permite la adecuada adaptación 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 tráfico propio del hardware



340

de red y pueden ser ignoradas. Estas alertas han disparado una más de tipo misc-

activity, que también puede ser ignorada, por la misma razón. 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 tráfico legítimo 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 están dando, de los hosts implicados y de los puertos

entre los que se están produciendo las comunicaciones maliciosas. No obstante,

los cálculos que han dado lugar a estos resultados han sido redondeados y

simplificados tantas veces desde el nivel de alertas, que se ha podido perder

información en el proceso. En efecto, si el administrador investiga las causas del

diagnóstico y entra en el Resumen unknown-class correspondiente a esa ventana

temporal haciendo clic en el registro correspondiente de la tabla resúmenes de la

interfaz principal del agente Supervisor, verá la información de la figura 59. En

el log de la ventana se puede ver la información correspondiente a la anomalía

"STEALTH ACTIVITY (XMAS scan) detection" donde se especifica que tanto

el atacante como la víctima 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 máquina (posiblemente para evitar la detección de la

situación por parte de un IDS). Más llamativo aún 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 múltiples puertos de la víctima y por tanto estamos ante un

escaneo de puertos en toda regla.



341

Los detalles de esta acusación se pueden ver haciendo clic sobre la casilla

correspondiente de la tabla (atacantes→, víctimas↓), pero como podemos ver en

la figura 60, no aporta mucha más información debido al nivel de abstracción del

agente Supervisor.

En la actual distribución del sistema IDSAI, el agente Supervisor rechaza

los Resúmenes cuyas Anomalías de origen han sido detectadas por Intérpretes

poco fiables, por lo que no aparecerán en la tabla de Resúmenes recibidos y no

podrán ser consultados de esta manera. No obstante estas Anomalías y Análisis

aparecen en los registros de los agentes de menor nivel, por lo que pueden

consultarse allí como si nunca se hubiera construido su Resumen.



342

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 análisis especializado de las

Anomalías (ver apartado 4.1.2.4: Anomalía) recibidas por parte de los agentes

Intérpretes de su mismo tipo. Almacenan información sobre dichas Anomalías

(estado de la red a nivel de alertas), y sus Análisis estadísticos correspondientes

(ver apartado 4.1.2.5: Análisis) que resultan muy interesantes para inspeccionar

las causas de un Diagnóstico en detalle.

La siguiente imagen representa la interfaz principal de un agente Analista

en un momento de la ejecución:

1

2

3

4

5



343

Fig. 61: Interfaz del agente Analista.

La interfaz gráfica del agente Analista consiste en una ventana en la que

destacan los siguientes elementos



2. Log del agente. En él se indican los eventos relativos a nuevas

ventanas temporales, envío de Resúmenes, etc.

3. Tabla de últimos Análisis. En ella se listan los Análisis realizados en

las últimas 20 ventanas indicando explícitamente la ventana y la fecha

en la que se hicieron, la firma de la Anomalía correspondiente, y la

prioridad en forma numérica. Los Análisis 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 Análisis en particular, el usuario debe hacer clic sobre

su registro, tras lo que se abre la siguiente ventana:

Fig. 62: Detalles de Análisis.

3.1 3.2



344

Los detalles del Análisis se muestran en la interfaz anterior, en la que


3.1 Identificador del detalle. Hace referencia a la firma de la

Anomalía correspondiente al Análisis.

3.2 Listado de la información de la estructura Análisis.

4. Tabla de Anomalías recibidas. En ella se listan las Anomalías

recibidas en las últimas 20 ventanas indicando explícitamente la

ventana y la fecha en la que se hicieron, la firma correspondiente, y el

número de Eventos (ver apartado 4.1.2.1: Evento) registrados. Las

Anomalías 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 Anomalía en particular,

el usuario debe hacer clic sobre su registro, tras lo que se abre la

siguiente ventana:



345

Fig. 63: Detalles de Anomalía.

Los detalles de la Anomalía se muestran en la interfaz anterior, en la


4.1 Identificador del detalle. Hace referencia a la firma de la

Anomalía correspondiente.

4.2 Listado de Eventos. Listado de los Eventos detectados en la

ventana actual, indicándose para cada uno de ellos su

identificador CID, la fecha y hora en que fue registrado, la

4.2

4.1

4.3

4.4



346

dirección IP origen con puerto y la dirección destino con

puerto.

4.3 Resumen de Eventos. Tres líneas de texto que indican el

número de Eventos totales anteriormente enumerados, el

tiempo transcurrido entre el primer Evento detectado y el

último en la ventana actual y el número de Ataques (ver

apartado 4.1.2.3: Ataque) en que se agrupan los Eventos.

4.4 Listado de Ataques: Enumeración de los Ataques

detectados, junto con su información característica: número

de Eventos, intervalo eventual, intervalo temporal,

compactación eventual, atacante y víctima principales,

puerto origen y destino predominantes y proporción

respecto al total de estos últimos valores.


acciones sobre la interfaz y el agente Analista:


de la interfaz gráfica del agente Analista en blanco. El Log del

programa en general es de tamaño ilimitado, por lo que tras una

ejecución continua y prolongada es cómodo limpiarlo para

eliminar del mismo notificaciones obsoletas.

• Botón Matar agente: Al pulsarlo, el agente Analista ejecuta su








347


sistema, quien dejará de enviarle mensajes de sincronización. No

es así para el resto de agentes de la plataforma, que seguirán

enviándole mensajes aunque el destinatario ya no exista.

La investigación de anomalías al nivel de agentes Analistas sólo 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 rápidas. En el caso ejemplo de donde se han tomado las

imágenes en este capítulo, 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 anomalía.

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 interés para

comprobar los orígenes de los cálculos que dan lugar al valor de la criticidad del

sistema.

Haciendo clic sobre el registro de la tabla de análisis correspondiente al

Análisis "STEALTH ACTIVITY (XMAS scan)" de la ventana 4, se abren los

detalles de éste Análisis, 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 información 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 compactación de los ataques 5 (ambos valores

relativamente altos según la escala definida en los controladores borrosos del

anexo 1: Conjuntos borrosos IDSAI). También se puede ver información



348

estadística 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 sólo se ha detectado un ataque de

esta firma, no obstante con un alto número de alertas disparadas.

La información de los Análisis debe ser lo suficientemente escueta como

para formar los Resúmenes, por lo que conviene que sea complementada con la

información que aporta la estructura Anomalía asociada a cada uno de estos

Análisis. En nuestro caso el administrador del sistema debe consultar los detalles

de la anomalía "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 análisis a

nivel de ataques. La lista de eventos es incómoda de ver pero resulta

indispensable en un análisis 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 duración de 10 segundos en el que la compactación

eventual es nula, lo que confirma el hecho de que se están detectando muchos

otros ataques simultáneamente como se podía ver en el gráfico de la interfaz del

Supervisor.



349

8.3.3. INTERFAZ DEL AGENTE INTÉRPRETE

Los agentes Intérpretes (ver apartado 4.2.3: Agente Intérprete, y

siguientes) son los encargados de recoger la información depositada por el

sensor Snort en la base de datos snortdb de forma especializada, generando las

Anomalías (ver apartado 4.1.2.4: Anomalía) que enviarán a su agente Analista

asociado para que éste las procese. Los agentes Intérpretes no almacenan

información de ningún tipo, ya que el nivel de los datos que maneja es el más

bajo: alertas registradas en la base de datos. Esta información estará siempre

disponible para ser consultada de forma manual desde las tablas de la base de

datos aunque de una forma más incómoda para el usuario.

La siguiente imagen representa la interfaz principal de un agente

Intérprete en un momento de la ejecución:

Fig. 64: Interfaz del agente Intérprete.

La interfaz gráfica del agente Intérprete consiste en una ventana en la que


1

2

3



350



2. Log del agente. En él se indican los eventos relativos a nuevas

ventanas temporales, envío de Anomalías, etc.


acciones sobre la interfaz y el agente Intérprete:


de la interfaz gráfica del agente Intérprete en blanco. El Log del

programa en general es de tamaño ilimitado, por lo que tras una

ejecución continua y prolongada es cómodo limpiarlo para

eliminar del mismo notificaciones obsoletas.

• Botón Matar agente: Al pulsarlo, el agente Intérprete ejecuta su







sistema, quien dejará de enviarle mensajes de sincronización. Los

demás agentes de la plataforma no se percatan de su ausencia, ni

tienen por qué hacerlo.

La interfaz del agente Intérprete no sirve para investigar la situación de la

red, ya que sus resultados (las estructuras Anomalía) ya se muestran en la

interfaz del agente Analista que sí que almacena el histórico. Resulta



351

tranquilizador echarle un vistazo a su log de vez en cuando para comprobar que

está funcionando correctamente.



352

8.3.4. INTERFAZ DEL AGENTE RELOJ

El agente Reloj (ver apartado 4.2.1: Agente Reloj) es el encargado de la

sincronización 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 gráfica se pueda ver el listado completo.

La siguiente imagen representa la interfaz principal de el agente Reloj en

un momento de la ejecución:

Fig. 65: Interfaz del agente Reloj.

La interfaz gráfica del agente Reloj consiste en una ventana en la que


1. Contador de la ventana actual. Indicador numérico 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 sincronización.

2. Tabla de agentes vivos. En ella se listan los identificadores de los

agentes vivos en la plataforma en el momento actual. Tiene mero

1

21

3



353

valor informativo, pero sirve para estar seguro de que los diferentes

agentes están corriendo en sus respectivos lugares, de forma

centralizada.


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:

• Botón Detener: Al pulsarlo, el usuario suspende la ejecución de

los comportamientos activos del agente. De esta manera se

consigue detener la ejecución de los agentes sincronizados, ya que

no les llegará la notificación de una nueva ventana mientras el

Reloj esté en este estado. Se debe tener en cuenta que la ejecución

del sensor Snort no se detiene nunca y por tanto, mientras los

agentes del sistema IDSAI se encuentren a la espera del Reloj,

perderán 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 ejecución del Reloj, estos agentes no

dados de alta, no serán sincronizados. Pese a todo esto, en una

situación de verdadera crisis donde sea verdaderamente necesario

hacer una inspección detallada de las causas de un diagnóstico

crítico, detener los agentes puede resultar interesante con el fin de

facilitar la labor de análisis y toma de decisiones por parte del

humano tras la máquina.

• Botón Arrancar: Al pulsarlo, el usuario activa la ejecución de los

comportamientos suspendidos del agente. De esta manera se



354

consigue el rearranque del proceso de sincronización y de espera

del alta de nuevos agentes en la plataforma.

La interfaz del agente Reloj no sirve para investigar la situación de la red.

Simplemente muestra los agentes vivos en el momento actual y resulta útil para

comprobar su estado.



355

9. PLANIFICACIÓN Y PRESUPUESTO DEL PROYECTO

En el presente capítulo se hace referencia a la planificación del proyecto: las

etapas de su desarrollo y diferentes actividades llevadas a cabo en cada una de las

mismas por los miembros de su organización.

9.1. ORGANIZACIÓN DEL PROYECTO

El proyecto IDSAI es un Proyecto Fin de Carrera de carácter individual, por

lo que el equipo de trabajo está formado exclusivamente por una única persona,

autor del presente documento. De esta manera, la investigación en temas de

seguridad informática, ataques a redes de computadores, Sistemas de Detección de

Intrusos y la arquitectura de agentes inteligentes JADE, ha sido realizada por la

misma persona encargada del diseño, programación y documentación del

aplicativo. El siguiente diagrama muestra la estructura organizativa del proyecto

indicándose las responsabilidades de cada uno de las personas que la integran:

Fig. 66: Organización del proyecto.

COORDINADOR

Miguel Ángel Sanz Bobi

DIRECTORES

Miguel Ángel Sanz Bobi (Director 1)

Mario Castro Ponce (Director 2)

EQUIPO DE TRABAJO




356

Donde las tareas y responsabilidades principales de cada uno de los grupos

que forman la organización del proyecto a lo largo de la realización del mismo se

presentan a continuación:

o Coordinador:

� Explicar la Normativa de Proyectos Fin de carrera y facilitar

la información pertinente a lo largo de su desarrollo.

� Concretar la definición del proyecto y los objetivos.

� Controlar y supervisar el trabajo en sesiones de presentación

pública 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 líneas y los

criterios de verificación de los resultados de forma práctica.

� Facilitar al alumno las orientaciones adecuadas ante los

problemas que vayan surgiendo en el desarrollo del proyecto.

� Supervisar la realización del proyecto, la calidad de sus

contenidos, y que se desarrolla de acuerdo con la Normativa

de Proyectos Fin de carrera.

� Dar su opinión al Coordinador sobre el alumno y el trabajo

realizado.



357

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 planificación del

mismo, que deben ser validadas por los Directores del

proyecto.

� Realizar la adquisición de información para la realización del

proyecto. Esto incluye tanto la investigación y formación

autónoma sobre los temas que trata el proyecto, como la

obtención del conocimiento necesario para llevar a cabo los

objetivos del mismo.

� Realizar el diseño del aplicativo. Esto implica la elección,

diseño y documentación de la arquitectura a montar.

� Realizar la programación del software. Esto implica la

codificación del diseño sobre el lenguaje elegido y las pruebas

pertinentes.

� Llevar a cabo la documentación y presentación del producto y

de cada uno de los prototipos a los Directores y Coordinador

del proyecto.



358

9.2. METODOLOGÍA 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 solución para la

arquitectura distribuida sobre la que desplegar el sistema, la tecnología de agentes

inteligentes JADE. El desconocimiento sobre estos temas por parte del equipo de

trabajo al comenzar el proyecto impide que su desarrollo se realice mediante una

metodología lineal, ya que a medida que se avanza en él se irán descubriendo

nuevas funcionalidades y surgiendo nuevas ideas a incorporar al resultado. Por

estas razones, el proyecto se realizará mediante una metodología espiral, según la

cual, se publicarán periódicamente versiones del producto IDSAI, que tras ser

valoradas por los Directores del proyecto, pasarán por nuevas etapas de desarrollo

donde se les incorporarán funcionalidades más avanzadas.

En el apartado 9.3: Planificación de tareas, se representará la metodología

del proyecto junto con las actividades a realizar en cada etapa.

El objetivo del proyecto, que impone la implantación del mismo en una red

real, hace escoger como sistema operativo el entorno Windows, tanto para el

desarrollo como para la puesta en marcha del aplicativo, por ser el más utilizado en

la actualidad. El software base del proyecto implica que el desarrollo se realice en

lenguaje Java, ya que el middleware JADE está construido sobre esta tecnología. Al

no presentarse especificaciones hardware concretas, se considerará la implantación

del producto en equipos PC ordinarios (CPU ∼1,5 GHz y Memoria ∼512 MB), por

lo que el desarrollo se llevará a cabo también en máquinas de estas características.

Tal y como se especifica en el alcance del proyecto, tanto el software de desarrollo

como el base sobre el que se implantará el sistema debe ser gratuito y de libre



359

distribución, 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 gráficas MySQL (MySQL Gui Tools 5.0)

� Middleware JADE (JADE 3.4)

� Máquina Virtual Java (JVM 5.0)

o Software de desarrollo (en máquina con Windows XP):

� Kit de Desarrollo Java (JDK 5.0)

� Entorno de desarrollo Java Eclipse (Eclipse SDK 3.2.1)

� Herramienta de diagramación Dia (Dia 0.95-1)

� Herramienta de documentación 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 realización del proyecto son

los siguientes:

o Hardware de desarrollo y pruebas:



360

� PC sobremesa necesario para la distribución del sistema

IDSAI en varias máquinas (AMD Athlon 64 2.5 GHz, 768

MB RAM). Incluye Windows XP.

� PC portátil para desarrollo y pruebas (Pentium Centrino 1.7

GHz, 1 GB RAM). Incluye Windows XP.

� Hub y cableado de red para pruebas.



361

9.3. PLANIFICACIÓN DE TAREAS

En este apartado se presenta la planificación de las fases en que se divide el

desarrollo del sistema IDSAI. Debido a la metodología en espiral en que se ha

llevado a cabo el proyecto, cada una de las etapas del desarrollo consiste en la

realización y presentación de un prototipo del producto final, que es la acumulación

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 revisión de la planificación inicial de tareas, en la que

se preveía el final del proyecto para Junio de 2007 y que mostraba una ejecución

lineal de actividades que resultó inviable en las fases de la programación, se opta

por la metodología en espiral y posponer el final del proyecto. El siguiente esquema

muestra las actividades de adquisición de conocimiento planificadas en un principio

(A1, A2, A3, A9 y A10) y las etapas iterativas de realización 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. Seguridad perimetral.

A2.2. Ataques a redes de computadores.

A2. Estudio de Sistemas de Detección de Intrusos.

A2.3. Principios de la detección de intrusos

A2.4. Sistemas de Detección de Intrusos: Clasificación,

funcionamiento y estado del arte.



362

A2.5. Snort. Configuración e implantación. Instalación y

configuración 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. Estudio de la arquitectura de agentes inteligentes JADE.

A3.2. Diseño de aplicación de prueba de comunicación entre

agentes.

A4. Primer prototipo: Sistema local de clasificación de alertas.

A4.1. Primer diseño de agente Intérprete: Construcción de un

agente JADE cuya mera funcionalidad es el acceso

periódico a la base de datos snortdb para obtener alertas de

un determinado tipo. Diseño de funciones de la capa de

persistencia. Introducción del concepto Anomalía, que se

plasma en una estructura de datos que se envía al agente

Analista.

A4.2. Primer diseño de agente Analista: Construcción de un

agente JADE cuya única funcionalidad es la presentación

por consola de los datos que el agente Intérprete le envía

en forma de estructura Anomalía.

A4.3. Primer y definitivo diseño de agente Sensor: Construcción

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



363

desarrollo por cuestiones de rendimiento). Aunque el

código del agente Sensor se pueda retocar en posteriores

fases del desarrollo del proyecto, ésta será su

funcionalidad definitiva.

A4.4. Presentación del prototipo (a Directores).

A5. Segundo prototipo: Sistema distribuido de análisis de alertas.

A5.1. Revisión definitiva del agente Intérprete: Especialización

de agentes Intérpretes por tipo de signature. Diseño del

análisis de anomalías a nivel de ataques e introducción de

los conceptos prioridad y compactación eventual. Envío de

múltiples Anomalías al agente Analista de su misma

especialidad. Diseño de una interfaz gráfica simple para

los agentes Intérpretes. Aunque el código del agente

Intérprete se pueda retocar en posteriores fases del

desarrollo del proyecto, ésta será su funcionalidad

definitiva.

A5.2. Revisión del agente Analista: Especialización de agentes

Analistas por tipo de signature. Introducción del concepto

análisis asociado a cada tipo de Anomalía y su

representación en la estructura de datos Análisis. que se

envía al agente Supervisor. Diseño de una interfaz gráfica

que muestre la información recibida del agente Intérprete

asociado.

A5.3. Primer diseño del agente Supervisor: Construcción de un

agente JADE cuya única funcionalidad es la presentación



364

por una interfaz gráfica de los datos que el agente Analista

le envía en forma de estructura Análisis.


A6. Tercer prototipo: Sistema distribuido de diagnóstico de la situación.

A6.1. Primer y definitivo diseño del agente Reloj: Construcción

de un agente JADE cuyas funcionalidades son la recepción

de mensajes de alta y baja en la red por parte de los demás

agentes de la plataforma para tener conocimiento de los

agentes vivos en todo momento y la sincronización de los

mismos marcando el periodo de captura-análisis-

diagnóstico. Diseño de una interfaz gráfica que muestre

los agentes vivos en la plataforma en tiempo real. La

creación de este agente requiere retocar los demás agentes

hasta el momento. Aunque el código del agente Reloj se

pueda retocar en posteriores fases del desarrollo del

proyecto, ésta será su funcionalidad definitiva.

A6.2. Segunda revisión del agente Analista: Especialización del

análisis de la prioridad y la compactación de las anomalías

por tipo de signature. Introducción del concepto acusación

como forma de reducir la cantidad de información de bajo

nivel a enviar al Supervisor. Introducción del concepto

resumen de análisis, que se plasma en la estructura de

datos Resumen que se envía al agente Supervisor.

A6.3. Revisión del agente Supervisor: Introducción del concepto

diagnóstico de la situación que consiste en el tratamiento

estadístico de la información de los Resúmenes recibidos



365

para integrar los conceptos de prioridad y compactación en

uno sólo: criticidad. Mejora de la interfaz de forma que

además de la información básica de la estructura

Diagnóstico, muestre en un diagrama gráfico las

acusaciones recibidas en todos los Resúmenes en tiempo

real.


A7. Cuarto y definitivo prototipo: Sistema distribuido inteligente de

análisis del estado de la situación.

A7.1. Revisión definitiva del agente Analista: Introducción de

procedimientos de borrosificación para enviar los valores

de prioridad y compactación en el Resumen al agente

Supervisor. Mejora de la interfaz gráfica para que muestre,

de forma tabulada y consultable, información histórica

sobre la información con la que trabaja (Anomalías y

Análisis). Aunque el código del agente Analista se pueda

retocar en posteriores fases del desarrollo del proyecto,

ésta será su funcionalidad definitiva.

A7.2. Revisión definitiva del agente Supervisor: Introducción de

procedimientos de desborrosificación para convertir los

valores de prioridad y compactación recibidos en cada

Resumen en un único valor de criticidad del sistema.

Introducción de base de reglas para definir el estado del

sistema. Mejora de la interfaz gráfica para mostrar la

información histórica completa de Diagnósticos y

Resúmenes recibidos, de forma tabulada y consultable,

con ventanas de detalle avanzadas. Aunque el código del



366

agente Supervisor se pueda retocar en posteriores fases del

desarrollo del proyecto, ésta será su funcionalidad

definitiva.


A8. Implantación del sistema distribuido IDSAI: Etapa reservada para el

retoque de las funcionalidades del sistema de cara a la presentación

del sistema completo a los directores del proyecto. Presentación de

la versión definitiva del sistema IDSAI (a Directores).

A9. Documentación del proyecto.

A10. Presentación final del proyecto (a Coordinador).

La ubicación temporal de las actividades enumeradas anteriormente, no es

estricta en el periodo de desarrollo del proyecto, por lo que la realización de éstas se

planifica aproximadamente según el siguiente diagrama.



367

Fig. 67: Planificación de tareas.

A1

A2

A6

A8

A9

A3

A7

A5

Exámenes

Exámenes

OCT NOV DIC ENE FEB MAR ABR MAY JUN JUL AGO

SE

2006 2007

A4

A10

SEP



368

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 distribución, el coste del proyecto IDSAI es nulo en ese

aspecto. No obstante en las fases de desarrollo e implantación 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 distribución del sistema IDSAI en

varias máquinas (AMD Athlon 64 2.5 GHz, 768 MB RAM). Incluye

Windows XP: 1000 €.

o PC portátil 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)



369

o Estimación de esfuerzo (tiempo en horas).

Tabla 2: Estimación de esfuerzo.

o Estimación del coste (en euros).

Tabla 3: Estimación del coste.

Coste total del desarrollo del proyecto:

Costes fijos: 2050 €

Costes variables: 4900 €

TOTAL PROYECTO: 6950 €

Tareas Personal

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 TOTAL HORAS

COORDINADOR 0 0 0 1 0 1 0 0 0 2 4

DIRECTOR 1 0 0 2 2 2 4 4 4 2 1 21

DIRECTOR 2 2 2 0 2 2 4 4 4 2 1 23

EQUIPO TRABAJO 20 20 20 45 85 95 65 105 60 5 520

TOTAL ETAPA 22 22 22 50 89 104 73 113 64 9 568 h

Tareas Personal

€/ hora

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 TOTAL €

COORDINADOR 20 0 0 0 20 0 20 0 0 0 40 80

DIRECTOR 1 15 0 0 30 30 30 60 60 60 30 15 315

DIRECTOR 2 15 30 30 0 30 30 60 60 60 30 15 345

EQUIPO TRABAJO 8 160 160 160 360 680 760 520 840 480 40 4160

TOTAL ETAPA 190 190 190 400 740 900 640 960 540 110 4900 €



370

10. CONCLUSIONES

Al término 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 definición del proyecto, los objetivos del mismo estuvieron claros

desde el principio, pero el modo de llevarlos a cabo y el alcance no quedaron

determinados hasta bien entrado el proceso de desarrollo. Por otra parte, el diseño

inicial de la aplicación no cumplía 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 planificación lineal realizada inicialmente para dar lugar

a la planificación en espiral basada en prototipos de la que se ha hablado en apartados

anteriores.

Como ya se ha explicado, la planificación del proyecto fue alterada durante su

desarrollo debido al cambio de metodología. Por otra parte las tareas de investigación y

adquisición de conocimientos A1, A2 y A3 se alargaron en el tiempo, ya que durante

todo el proyecto hubo que apoyarse en la bibliografía para seguir ampliando las

funcionalidades del proyecto y adquiriendo nuevos conocimientos para implantar las

ideas que iban surgiendo. El cambio a la metodología en espiral fue realizándose

involuntariamente cuando a partir de la presentación del primer prototipo a los

directores del Proyecto (actividad A4), se fueron haciendo más frecuentes las reuniones

de supervisión en las que iban surgiendo y se iban proponiendo las nuevas

funcionalidades que debían ir integrando los sucesivos entregables. El desarrollo en

espiral ha dado al final un producto satisfactorio y ha permitido la introducción de

particularidades del diseño en los momentos apropiados que no estaban previstas en la

planificación inicial. Como una lección aprendida a aplicar en futuros proyectos queda

el hecho de que la metodología en espiral es verdaderamente eficaz cuando no se



371

dispone de un diseño inicial estable, aunque se deben controlar mejor las fechas de

entrega de los prototipos.

Respecto al tema de la documentación, aunque los diagramas de diseño y

arquitectura se iban haciendo de forma concurrente con el desarrollo, la realización de la

memoria final ha llevado más horas de las previstas, debido a la propia metodología,

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, quedarán

pendientes para futuras versiones del producto:

- El arranque de los agentes de la plataforma, que se hace en forma de script

de línea de comandos, podría realizarse mediante una interfaz gráfica más

cómoda. Puesto que tanto el entorno de pruebas como la red en la que se

implantó el sistema eran redes pequeñas, el sistema de manipulación de

scripts no era muy engorroso, pero en una gran distribución del producto,

ésta no es la forma más adecuada de hacerlo. Se sugiere una interfaz que

permita ubicar las máquinas que alojan los agentes en el espacio y que

permita gestionarlos de forma remota.

- Por la misma razón, en una gran distribución de la aplicación resultaría

interesante que los agentes Intérpretes propagaran su posición en la red, de

forma que esto permitiera hacer diagnósticos más especializados y se tuviera

en cuenta para la toma de decisiones. Se sugiere que la criticidad del sistema

definida por el agente Supervisor, dependa también de la importancia de los

segmentos de red en que se detecten los ataques y que las acusaciones se

representen, además de con las direcciones IP origen y destino, con la

ubicación física de las máquinas atacante y víctima.



372

- La fiabilidad de los agentes Intérpretes también tiene que tenerse en cuenta

para posteriores versiones del aplicativo. Actualmente, si el agente

Supervisor recibe varios Resúmenes de Análisis del mismo tipo de firma,

desecha aquellos cuyas anomalías han sido detectadas por Intérpretes de

menor fiabilidad. El trabajo de esos Intérpretes rechazados no debería ser

ignorado de esa manera, ya que podría aportar mayor información al

conjunto, defendiendo o refutando un diagnóstico que actualmente se está

basando en una única fuente. Se sugiere que el agente Supervisor aplique un

sistema de votación ponderada por fiabilidad entre los Resúmenes del mismo

tipo, para quedarse con las Anomalías más significativas de cara a que sean

las que se tengan en cuenta para el Diagnóstico del estado de la red.

- Una arquitectura distribuida es potencialmente insegura, ya que las

comunicaciones entre agentes pueden ser intervenidas, lo que permitiría a un

hacker el acceso a importante información de negocio. El IDS distribuido

IDSAI sería fácilmente inutilizable si se impidiera la llegada de mensajes de

alertas detectadas a la capa de presentación 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 débil frente a estos

ataques. Afortunadamente, JADE proporciona en su API funcionalidades de

seguridad que solucionarían estos problemas, pero que no se han aplicado

por cuestión de tiempo.

- Las bases heurísticas en las que se fundamenta el análisis de la prioridad y

compactación eventual de las anomalías que se realiza en los agentes

Analistas son estáticas. Si se desearan modificar habría que alterar el código

fuente y al crear nuevos agentes Analistas de otras especialidades habría que

retocar los parámetros en tiempo de programación. Lo mismo ocurre con los

controladores borrosos que se han diseñado en la clase de cálculo borroso

Control Borroso (ver apartado 4.6.2: Control Borroso), que están



373

programados de forma estática. También 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 heurístico en el arranque de los agentes a través de

ficheros externos que permitan su edición sin tocar el código, aunque haya

que programar complejas funciones de parseo de esta información para

integrarla a la lógica de la aplicación.

- La funcionalidad de mantenimiento de la información actualizada en la base

de datos snortdb, que inicialmente integraba el agente Sensor, no ha sido

implementada en la versión definitiva del aplicativo. Esto se debe a que en la

práctica, la información 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 crítico, 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 Intérprete que se alimentan de cada instancia por lo que el

borrado de información obsoleta de los sensores, puede suponer la parada del

sistema IDSAI, lo cual es indeseable. Se intentó sin éxito la configuración

del esquema snortdb para que admitiera borrados en cascada, pero no fue

posible que sobre este nuevo esquema Snort insertara información en la base

de datos sin errores. Se sugiere la detención periódica (a nivel de días) 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

información. También se sugiere revisar y limpiar los ficheros de log del

sistema para prevenir una situación de falta de espacio en disco si se llenan

con demasiada información.



374

11. BIBLIOGRAFÍA

[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 Díaz Vizcaíno, "Sistemas de Detección de Intrusos",

Departamento de Ingeniería Telemática, Universidad Carlos III de

Madrid, 2005.

[ARAN06] Gonzalo A. Aranda Corral, "Construcción 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: Informática y Modelización Matemática,

Universidad Rey Juan Carlos, 2004.



375

[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/



376

12. SIGLAS Y ACRÓNIMOS

ACL Agent Communication Language.

ARP Address Resolution Protocol

CPU Central Processing Unit.

DoS Denial of Service.

FIPA Foundation for Intelligent Physical Agents.

FTP File Transfer Protocol.

HIDS Host Intrusion Detection System.

HTML HyperText Markup Language.

HTTP Hyper Text Transfer Protocol.

IDS Intrusion Detection System. (Sistema de Detección de Intrusos)

IDSAI IDS, Sistema de Detección de Intrusos, basado en Agentes

Inteligentes.

JDK Java Development Kit.

JVM Java Virtual Machine.

ICMP Internet Control Message Protocol.

IP Internet Protocol.



377

JADE Java Agents Development Environment (Entorno de Desarrollo de

Agentes Java).

MAC Media Access Control.

MS Microsoft.

NNIDS Network Node Intrusion Detection System.

NIDS Network Intrusion Detection System.

OSI Open System Interconnection

P2P Peer to Peer.

RPC Remote Procedure Call.

SDK Standard Development Kit.

SGBD Sistema Gestor de Bases de Datos.

SNMP Simple Network Management Protocol.

SPADE Statistical Packet Anomaly Detection Engine.

SQL Structured Query Language.

SSH Secure Socket Layer.

TCP Transmission Control Protocol.

TILAB Telecom Italian LABoratories.

UDP User Datagram Protocol.

URI Uniform Resource Identifier.



378

URL Uniform Resource Locator.

XSS Cross-Site Scripting.

XML eXtensible Markup Language.



379

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)

Proyecto Fin de Carrera - IIT Comillas · 2007-09-11 · (profundizando en el escaneo de puertos) y...

Documents

Transcript of Proyecto Fin de Carrera - IIT Comillas · 2007-09-11 · (profundizando en el escaneo de puertos) y...