cave canem -- an extensible plugin-based monitoring and intrusion detection system

PROYECTO FIN DE CARRERA

INGENIERIA EN INFORMATICA

Cave Canem

Plataforma extensible para la monitorizacion de sistemas yla deteccion de intrusiones con DDS

AutorFernando Garcıa Aranda

DirectoresJuan Manuel Lopez SolerJavier Sanchez Monedero

Departamento de Teorıa de la Senal, Telematica yComunicaciones

—Granada, diciembre de 2010

Cave Canem

Plataforma extensible para la monitorizacion de sistemas yla deteccion de intrusiones con DDS

AutorFernando Garcıa Aranda

DirectoresJuan Manuel Lopez SolerJavier Sanchez Monedero

Cave Canem: plataforma extensible para la monitorizacionde sistemas y la deteccion de intrusiones con DDS

Fernando Garcıa Aranda

Palabras clave: DDS, Data Distribution Service, monitorizacion de siste-mas, IDS, middleware.

Resumen

La sustitucion progresiva de los modelos de computacion centralizadospor entornos distribuidos, ha convertido la monitorizacion de aplicaciones,sistemas y desempeno de redes, en una tarea crucial en la gestion de serviciosen red. Actualmente, existen gran cantidad de herramientas que ofrecen unarespuesta parcial a este problema (por ejemplo, los sistemas para la deteccionde intrusos (IDS) o las herramientas para la monitorizacion de sistemas),sin embargo estas no proporcionan la solucion integral requerida para unacomprension global del entorno y una reaccion eficaz ante los posibles eventosy amenazas que puedan ocurrir.

En este contexto se propone Cave Canem, una plataforma integradorapara la gestion eficiente de la informacion generada por este tipo de herra-mientas. Esta proporciona, a traves de la utilizacion de un entorno informa-tivo unico y escalable, una vision de conjunto del estado de los sistemas yla red, facilitando en gran medida las labores de administracion.

Cave Canem apoya su modelo de comunicacion en el paradigma de pu-blicacion/suscripcion definido por el estandar de la OMG DDS (Data Dis-tribution Service). De esta forma, el proyecto muestra como el uso de lafuncionalidad proporcionada por este (desacoplo de entidades en tiempo/es-pacio, definicion de polıticas de QoS, etc.), simplifica el desarrollo de unsistema de monitorizacion, proporcionando un entorno flexible, eficiente yrobusto.

Cave Canem: an extensible DDS-based monitoring andintrusion detection system

Fernando Garcıa Aranda

Keywords: DDS, Data Distribution Service, system monitoring, IDS, middle-ware.

Abstract

As centralized computing models are being superseded by more distri-buted computer environments, supervising application, system and networkhealth has become a crucial task in network management. Currently, the-re are plenty of systems providing a partial solution to this problem (e.g.intrusion detection systems (IDS) and system monitoring tools), but eachseparately cannot provide the complete view required to understand andreact quickly.

In this context we propose Cave Canem, a framework for the develop-ment of a “complete” operational picture for the combination of multiplekinds of information (e.g. performance, system alerts, intrusion detection),remaining open so that new sensors and applications can be mixed in.

Our framework exploits the benefits of the data-centric publish-subscribe(DCPS) paradigm provided by the OMG Data Distribution Service (DDS)standard, which eases the deployment and maintainability of large moni-toring scenarios. It also takes advantage of some of the DDS features andQoS settings (reliability, transport priorities, etc.) which ensure that the en-tire system status can be efficiently distributed according to the subscriberinterests.

Yo, Fernando Garcıa Aranda, alumno de la titulacion Ingenierıa enInformatica de la Escuela Tecnica Superior de Ingenierıas Informati-ca y de Telecomunicacion de la Universidad de Granada, con DNI30985659J, autorizo la ubicacion de la siguiente copia de mi Proyecto Finde Carrera en la biblioteca del centro para que pueda ser consultada por laspersonas que lo deseen.

Fdo: Fernando Garcıa Aranda

Granada a 1 de diciembre de 2010.

D. Juan Manuel Lopez Soler, Profesor Titular del Area de IngenierıaTelematica del Departamento de Teorıa de la Senal, Telematica y Comuni-caciones de la Universidad de Granada.

D. Javier Sanchez Monedero, Becario FPDI del Departamento deInformatica y Analisis Numerico de la Universidad de Cordoba

Informan:

Que el presente proyecto, titulado Cave Canem. Plataforma exten-sible para la monitorizacion de sistemas y la deteccion de intrusio-nes con DDS, ha sido realizado bajo su supervision por Fernando GarcıaAranda, y autorizamos la defensa de dicho proyecto ante el tribunal quecorresponda.

Y para que conste, expiden y firman el presente informe en Granada a1 de diciembre de 2010.

Los directores:

D. Juan Manuel Lopez Soler D. Javier Sanchez Monedero

Agradecimientos

En primer lugar quiero agradecer a Jose Marıa y Manuela, mis padres, elapoyo, animo y la comprension que me han dado durante los anos de estudioen Cordoba y Granada, ası como a la hora de emprender viajes o cualquiertipo de proyecto.

En segundo lugar, agradecer los animos de mis amigos, Puri, que in-tento comprender lo que eran los punteros a funcion para ayudarme, Paco,Dani, Manolito, Anita, Antonio, Carmen y todos los que me dejo.

Gracias a los informaticos de Cordoba, Manolo, Ismael, Sergio y Nacho,con los que he compartido horas de estudio y programacion sin los que esteproyecto no habrıa sido posible. Gracias tambien a los de Granada, Juanpey Curro, de los que nunca me cansare de aprender.

Dar las gracias a mis tutores, Juanma y Javier, por el apoyo y tiempodedicado, ası como por su interes en mi trabajo presente y futuro.

Por ultimo, quiero agradecer los consejos de mi abuelo Alejandro, quedurante la realizacion de este proyecto cumplio 101 anos.

Sinceramente gracias.

Indice general

1. Introduccion 1

1.1. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Data Distribution Service (DDS) . . . . . . . . . . . . 2

1.1.2. Contextualizacion del proyecto . . . . . . . . . . . . . 2

1.2. Definicion del problema . . . . . . . . . . . . . . . . . . . . . 3

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Antecedentes y estado del arte . . . . . . . . . . . . . . . . . 5

1.4.1. Antecedentes en distribucion de datos . . . . . . . . . 5

1.4.2. Herramientas de monitorizacion y deteccion de intrusos 7

1.4.3. Aplicaciones integradoras de herramientas de monito-rizacion . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.1. Factores dato . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.2. Factores estrategicos . . . . . . . . . . . . . . . . . . . 12

1.6. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.6.1. Humanos . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.6.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.7. Fases de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 14

2. Especificacion de requisitos 17

2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 17

2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 18

3. Planificacion 19

4. Analisis del sistema 23

4.1. Analisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1. Casos de uso del sistema . . . . . . . . . . . . . . . . . 23

4.1.2. Subsistemas funcionales . . . . . . . . . . . . . . . . . 29

4.1.3. Operaciones del sistema . . . . . . . . . . . . . . . . . 30

4.2. Analisis de la arquitectura de monitorizacion . . . . . . . . . 34

4.3. Analisis del middleware . . . . . . . . . . . . . . . . . . . . . 35

i

ii INDICE GENERAL

4.3.1. Desacople en tiempo y espacio . . . . . . . . . . . . . 36

4.3.2. Filtros en la recepcion de topics . . . . . . . . . . . . 36

4.3.3. Monitorizacion de eventos a traves del uso de listeners 37

4.3.4. Algunos parametros de QoS . . . . . . . . . . . . . . . 37

4.4. Analisis del sistema de almacenamiento . . . . . . . . . . . . 38

4.4.1. Ficheros de log . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2. Ficheros estructurados: XML y CSV . . . . . . . . . . 39

4.4.3. Sistemas gestores de bases de datos . . . . . . . . . . . 41

4.4.4. Sistemas de almacenamiento Round-Robin . . . . . . . 42

4.5. Analisis del sistema de configuracion . . . . . . . . . . . . . . 43

4.5.1. YAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5.2. INI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.5.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6. Analisis de la interfaz . . . . . . . . . . . . . . . . . . . . . . 45

4.6.1. Requisitos de la interfaz . . . . . . . . . . . . . . . . . 45

4.6.2. Analisis de los requisitos de la interfaz . . . . . . . . . 46

5. Diseno 47

5.1. Arquitectura del sistema de monitorizacion . . . . . . . . . . 47

5.1.1. Monitorizacion a traves de un sistema de plugins . . . 48

5.1.2. Despliegue del un escenario de monitorizacion con DDS 50

5.2. Diseno de la aplicacion . . . . . . . . . . . . . . . . . . . . . . 56

5.2.1. Diagramas de clases . . . . . . . . . . . . . . . . . . . 57

5.2.2. Modelo de interaccion entre objetos . . . . . . . . . . 63

5.3. Diseno del sistema de configuracion . . . . . . . . . . . . . . . 68

5.3.1. El sistema de configuracion de CCPublisher . . . . . . 69

5.3.2. El sistema de configuracion de CCSubscriber . . . . . 69

5.4. Diseno del sistema de almacenamiento . . . . . . . . . . . . . 70

5.4.1. Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4.2. System Monitor . . . . . . . . . . . . . . . . . . . . . 72

5.4.3. Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.4.4. IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4.5. Net Load . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.5. Diseno de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 74

5.5.1. Bocetos de la aplicacion web . . . . . . . . . . . . . . 74

5.5.2. Diagramas de clases . . . . . . . . . . . . . . . . . . . 77

5.5.3. Modelo de interaccion de la interfaz . . . . . . . . . . 80

6. Implementacion 85

6.1. La aplicacion de monitorizacion . . . . . . . . . . . . . . . . . 85

6.1.1. Sistema de compilacion y organizacion del codigo . . . 86

6.1.2. Nucleo de los subsistemas . . . . . . . . . . . . . . . . 88

6.1.3. Plugins implementados . . . . . . . . . . . . . . . . . 93

INDICE GENERAL iii

6.1.4. Sistema de configuracion . . . . . . . . . . . . . . . . . 986.1.5. Sistema de almacenamiento . . . . . . . . . . . . . . . 101

6.2. Desarrollo de un plugin sencillo en Cave Canem . . . . . . . . 1036.2.1. Definicion del IDL . . . . . . . . . . . . . . . . . . . . 1036.2.2. Plugin para CCPublisher . . . . . . . . . . . . . . . . 1046.2.3. Plugin para CCSubscriber . . . . . . . . . . . . . . . . 105

6.3. La interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . 1076.3.1. Organizacion de ficheros de la interfaz de usuario . . . 1076.3.2. Resultados de la implementacion de los distintos esce-

narios . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7. Pruebas 1117.1. Pruebas de unidad . . . . . . . . . . . . . . . . . . . . . . . . 111

7.1.1. Diseno de los casos de prueba . . . . . . . . . . . . . . 1117.1.2. Resultados de la ejecucion de los casos de prueba . . . 113

7.2. Pruebas de integracion . . . . . . . . . . . . . . . . . . . . . . 114

8. Conclusiones y trabajo futuro 1178.1. Principales contribuciones . . . . . . . . . . . . . . . . . . . . 1178.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Bibliografıa 126

A. Manual de usuario 127A.1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

A.2.1. Requisitos de CCPublisher . . . . . . . . . . . . . . . 128A.2.2. Requisitos de CCSubscriber . . . . . . . . . . . . . . . 128A.2.3. Requisitos de la interfaz web . . . . . . . . . . . . . . 128

A.3. Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129A.3.1. Aplicaciones de monitorizacion . . . . . . . . . . . . . 129A.3.2. Instalacion de la interfaz de usuario . . . . . . . . . . 130

A.4. Guıa de uso de la aplicacion de monitorizacion . . . . . . . . 130A.4.1. CCPublisher . . . . . . . . . . . . . . . . . . . . . . . 130A.4.2. CCSubscriber . . . . . . . . . . . . . . . . . . . . . . . 132

A.5. Guıa de uso de la interfaz de usuario . . . . . . . . . . . . . . 133

B. Desarrollo de un sistema de plugins en C++ 137B.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137B.2. Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 138B.3. dlopen() y la carga dinamica de clases . . . . . . . . . . . . 139B.4. Autoregistro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142B.5. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

C. Glosario 151

Indice de figuras

3.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1. Digrama de casos de uso del sistema . . . . . . . . . . . . . . 24

4.2. Diagrama de paquetes del sistema . . . . . . . . . . . . . . . 30

4.3. Diagrama de secuencia: Publisher . . . . . . . . . . . . . . . . 31

4.4. Diagrama de secuencia: Subscriber . . . . . . . . . . . . . . . 33

4.5. Diagrama de secuencia: User Interface . . . . . . . . . . . . . 34

5.1. Escenario sencillo de monitorizacion con Cave Canem . . . . 49

5.2. Clase plugin en CCPublisher . . . . . . . . . . . . . . . . . . 50

5.3. Clase plugin en CCSubscriber . . . . . . . . . . . . . . . . . . 50

5.4. Entidades de DDS . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5. Revision de la clase base plugin en CCPublisher . . . . . . . . 54

5.6. Revision de la clase base plugin en CCSubscriber . . . . . . . 55

5.7. Diagrama de clases CCPublisher . . . . . . . . . . . . . . . . 58

5.8. Diagrama de clases CCSubscriber . . . . . . . . . . . . . . . . 61

5.9. Diagrama de secuencia del plugin Disk (CCPublisher) . . . . 64

5.10. Diagrama de secuencia del plugin Snort (CCPublisher) . . . . 66

5.11. Diagrama de secuencia del plugin Disk (CCSubscriber) . . . . 67

5.12. Diagrama de secuencia del plugin IDS (CCSubscriber) . . . . 68

5.13. Boceto del escenario “Listado de hosts” . . . . . . . . . . . . 75

5.14. Boceto del escenario “Estado actual de un host” . . . . . . . 76

5.15. Boceto del escenario “Listado completo de datos de monito-rizacion” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.16. Diagrama de clases de la interfaz de usuario . . . . . . . . . . 78

5.17. Diagrama de secuencia escenario “Listado de hosts” . . . . . 81

5.18. Diagrama de secuencia escenario “Estado actual de un host” 82

5.19. Diagrama de secuencia escenario “Listado completo de datosde monitorizacion” . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1. Extracto de cavecanem publisher/src/Makefile.am . . . . 91

6.2. Carga de plugins a traves de load single library() . . . . 92

6.3. Definicion del map de factorıas . . . . . . . . . . . . . . . . . 92

6.4. Instanciacion de plugins en CCSubscriber . . . . . . . . . . . 93

v

vi INDICE DE FIGURAS

6.5. Instanciacion de plugins en CCPublisher . . . . . . . . . . . . 936.6. Fichero de configuracion de CCPublisher . . . . . . . . . . . . 996.7. Fichero de configuracion de CCSubscriber . . . . . . . . . . . 1006.8. hello world dds.idl . . . . . . . . . . . . . . . . . . . . . . 1046.9. Implementacion del Plugin publicador de Hello World: fichero

de cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.10. Implementacion del Plugin suscriptor de Hello World: fichero

de cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.11. Implementacion del escenario “Listado de hosts” . . . . . . . 1086.12. Implementacion del escenario “Estado actual de un host” . . 1096.13. Implementacion del escenario “Listado completo de datos de

monitorizacion” . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A.1. Pantalla principal de la interfaz de usuario . . . . . . . . . . . 133A.2. Informacion actual de un host . . . . . . . . . . . . . . . . . . 134A.3. Informacion del estado de las interfaces de red de un host . . 135A.4. Alertas de IDS recolectadas por un host . . . . . . . . . . . . 135A.5. Informacion recolectada en relacion a datos de CPU de un host 136

Indice de cuadros

3.1. Planificacion del proyecto: tareas . . . . . . . . . . . . . . . . 20

4.1. Plantilla para la definicion de casos de uso . . . . . . . . . . . 25

6.1. Descripcion de la tabla hosts . . . . . . . . . . . . . . . . . . 1016.2. Descripcion de la tabla ids . . . . . . . . . . . . . . . . . . . 1016.3. Descripcion de la tabla system monitor . . . . . . . . . . . . 1026.4. Descripcion de la tabla net load . . . . . . . . . . . . . . . . 1026.5. Descripcion de la tabla disk . . . . . . . . . . . . . . . . . . . 103

vii

Capıtulo 1

Introduccion

1.1. Presentacion

La sustitucion progresiva de los modelos de computacion centralizadospor entornos distribuidos ha convertido la monitorizacion eficiente de siste-mas en un proceso crucial en la gestion de servicios en red y por tanto, en unaspecto clave en el desarrollo de la denominada sociedad de la informacion.

Hoy en dıa existen multitud de herramientas de amplia difusion que, ma-nejadas por los administradores de sistemas, se encargan de cubrir aspectoscomo la deteccion de intrusos, el analisis de vulnerabilidades, la monitoriza-cion de eventos, etc. Se presentan, de esta forma, una serie de aplicacionesaisladas que, en combinacion, ayudan a controlar el rendimiento adecuadode un sistema en red y de la misma red. Estas circunstancias implican laexistencia de multitud de sistemas de notificacion, administracion y visua-lizacion, complicando en gran manera la gestion eficiente de la informacionrecolectada.

En este contexto, se hace necesario el desarrollo de una plataforma in-tegradora capaz de normalizar y distribuir la informacion generada por estetipo de herramientas, ofreciendo un entorno informativo unico que permitaal administrador la interpretacion de esta, de forma conjunta, propiciandola deteccion temprana de anormalidades y el desempeno mas eficiente de sulabor.

La difusion normalizada de informacion por la red sera, por tanto, uno delos aspectos fundamentales en este proyecto. Existen diferentes tecnologıaspara dar soporte a la transmision de informacion en aplicaciones con re-querimientos muy distintos. Estas tecnologıas proporcionan funcionalidadesorientadas a solucionar problemas generales en el desarrollo de aplicacionesdistribuidas, liberando al programador de tareas comunes en este tipo desoftware, para que este pueda centrarse en lo especıfico del proyecto. Por lo

1

2 1.1. Presentacion

general, estas tecnologıas entran dentro del concepto de middleware.

1.1.1. Data Distribution Service (DDS)

La notificacion de alertas y mensajes de monitorizacion, ası como ladeteccion de intrusos requiere, en ocasiones, cumplir requisitos estrictos deeficiencia, determinismo, seguridad, fiabilidad y gestion de errores. Una delas soluciones disenadas para satisfacer tales restricciones es la tecnologıaDDS.

DDS son las siglas del estandar Data Distribution Service for Real-TimeSystems o servicio de distribucion de datos para sistemas de tiempo real[1], mantenido por la OMG (Object Management Group) [2]. DDS es elprimer estandar internacional abierto que especifica un modelo de publica-cion/subscripcion para sistemas de tiempo real y sistemas empotrados. Lasimplementaciones mas conocidas son RTI Data Distribution Sercice [3] deReal-Time Innovations [4], OpenSplice [5] de PrismTech [6] y OpenDDS [7]de la empresa Object Computing [8]. Puede consultarse informacion acer-ca de estas y otras implementaciones en el portal web sobre DDS [9] quemantiene la OMG.

El RTI Data Distribution Service es un middleware de red que imple-menta un modelo de comunicaciones en tiempo real basado en el paradigmapublicacion/suscripcion, permitiendo a un proceso en un entorno distribuidocompartir datos independientemente de la localizacion fısica o la arquitec-tura del resto de procesos. Esta adopcion pura del estandar de DDS [1] sedistingue del modelo seguido en otras implementaciones como OpenSplice,que realiza su comunicacion a traves del demonio ospl [5]. Ademas, el middle-ware proporciona soporte para comunicaciones deterministas (best-effort) ycomunicaciones fiables (reliable), incluyendo comunicaciones fiables basadasen multidifusion (multicast).

1.1.2. Contextualizacion del proyecto

Este proyecto ha sido desarrollado en el Departamento de Teorıa dela Senal, Telematica y Comunicaciones (TSTC) de la Universidad de Gra-nada. Este colabora, a traves de contratos de transferencia, con la empresaReal-Time Innovations, Inc (RTI)1, formando parte ademas de programa suprograma de universidades (Real-Time Innovations University Program)2.Por lo tanto, se dispone de licencias de desarrollo gratuitas del middlewareRTI Data Distribution Service.

1http://www.rti.com/2http://www.rti.com/corporate/university.html

http://www.rti.com/

http://www.rti.com/corporate/university.html

Introduccion 3

1.2. Definicion del problema

La utilizacion de distintas herramientas de monitorizacion y deteccionde intrusos en una red implica el manejo de un conglomerado heterogeneo desistemas de notificacion, interfaces de visualizacion y herramientas de con-figuracion. Esta circunstancia complica en gran manera la gestion eficientede la informacion.

Partiendo de este problema, el presente proyecto se enfoca en el disenoe implementacion de un sistema escalable capaz de procesar y difundir, deforma conjunta, las alertas generadas por una serie de herramientas distri-buidas en red. Por tanto, como objetivo se plantean dos cuestiones funda-mentales: la escalabilidad del sistema y las circunstancias de difusion de lainformacion.

La escalabilidad del sistema esta relacionada con la necesidad de pro-porcionar una arquitectura extensible, que garantice la incorporacionsucesiva de modulos que interpreten la informacion de nuevas herra-mientas, proporcionando un entorno flexible tanto al programador co-mo al administrador.

Las circunstancias de difusion de la informacion hacen referencia a lasnecesidades de transmision eficiente y normalizada de la misma. Sebusca garantizar una difusion flexible, dependiendo de las exigenciasdel tipo de mensaje, tanto en la propia estructura del mismo como enlas caracterısticas de su transmision.

Ademas de estas cuestiones fundamentales, el proyecto debera dar so-lucion, a lo largo del desarrollo del mismo, a dos aspectos que van de lamano de lo mencionado anteriormente. El primero hace referencia a las ca-pacidades de configuracion del sistema y el segundo a la visualizacion de lainformacion difundida.

El administrador del sistema necesitara realizar un ajuste de los distin-tos parametros de la aplicacion, para adaptar esta a sus necesidades.La solucion debera proporcionar, por lo tanto, la mayor flexibilidad aeste para la realizacion de una monitorizacion de servicios eficiente.

El ultimo problema fundamental a tratar sera la visualizacion de lainformacion difundida. Como se comento anteriormente, se presentaun sistema que necesita unificar informacion de diverso tipo y proce-dencia. Esta circunstancia demanda el diseno e implementacion de unainterfaz flexible que, de forma sencilla, proporcione al administradorla informacion que necesita.

4 1.3. Objetivos

1.3. Objetivos

Una vez realizada una primera definicion del problema, en este apartadose detallan los objetivos perseguidos a traves de la realizacion del proyecto.

Estudio de diferentes herramientas de monitorizacion y de-teccion de intrusos.

Se pretende realizar un estudio que cubra la funcionalidad basica deeste tipo de herramientas, su administracion y el modo en el que tratanla informacion generada. Este estudio pretende seleccionar un conjuntoidoneo de herramientas, utilizadas de forma comun por administrado-res de sistemas, de forma que a traves de la plataforma de gestion de lainformacion, se centralice el tratamiento de todos los eventos y alertasque estas generen, garantizando ası un acceso sencillo e intuitivo a lamisma.

Construccion de un sistema escalable para el tratamiento ydifusion de mensajes y eventos basado en una arquitecturade plugins.

La aplicacion a desarrollar debera basarse en un diseno extensible, queproporcione interfaces de programacion sencillas para la incorporacionprogresiva de funcionalidad. De esta forma, se busca la definicion deuna arquitectura de plugins, modulos que trabajaran directamente conlos eventos generados por las diferentes aplicaciones o sistemas.

Integracion progresiva de herramientas de monitorizacion yde deteccion de intrusos a traves del sistema de plugins.

Se deberan desarrollar una serie de plugins para cubrir la funcionalidadaportada por las herramientas seleccionadas en el estudio del primerobjetivo. Este desarrollo debera partir de una buena definicion de laarquitectura, siendo esta la base de la implementacion de un sistemasencillo y escalable.

Establecimiento de un sistema intuitivo de configuracion.

La aplicacion debera incorporar un sistema de configuracion intuitivoque permita adaptar la plataforma a distintas circunstancias. Se de-beran poder establecer parametros propios a cada plugin, ademas deuna serie de criterios genericos de la aplicacion.

Desarrollo de una interfaz para la visualizacion actualizadade informacion y el analisis de la misma.

Ademas de los objetivos relacionados con las caracterısticas intrınsecasde funcionamiento, estructura y configuracion del sistema, habra que

Introduccion 5

tener en cuenta el modo en el que se presenta la informacion recolecta-da. Se debera proporcionar al administrador una herramienta para lavisualizacion y el analisis de la informacion generada por los sensoresde monitorizacion y de deteccion de intrusos. El objetivo fundamentales que el administrador pueda acceder de forma sencilla a esta, permi-tiendo el conocimiento general del estado de las maquinas en la red,para su actuacion frente a posibles problemas que pudieran surgir a lolargo del tiempo.

1.4. Antecedentes y estado del arte

Como se ha mencionado en la definicion del problema, se plantea eldesarrollo de una herramienta para la integracion de la distribucion y visua-lizacion de alertas generadas por distintas aplicaciones de monitorizacion desistemas y de deteccion de intrusos.

De este modo, la evaluacion de antecedentes y del estado del arte de-bera fijar su foco en dos tematicas fundamentales: la eleccion de un sistemade distribucion y tratamiento de informacion, con el objetivo de gestionar ydistribuir los datos generados por los distintos sensores; y la valoracion de lasdistintas herramientas susceptibles de integrarse en el sistema. Por ultimo,se incluiran algunos ejemplos de aplicaciones que han basado su funciona-miento en la integracion de sistemas de monitorizacion y de deteccion deintrusos de terceros.

1.4.1. Antecedentes en distribucion de datos

Paradigma cliente/servidor

El desarrollo de aplicaciones distribuidas ha merecido grandes esfuerzosde investigacion en las ultimas decadas. Entre las herramientas desarrolladasen este contexto, es de especial interes la API3 Berkeley Socket Distribution[10]. A partir de la implementacion de esta, se han propuesto numerososmiddleware especificados con el objetivo de simplificar los costes de desarro-llo, optimizar las prestaciones y utilizacion de los recursos de la red, ofrecermayor escalabilidad, fiabilidad y disponibilidad, ası como potenciar la inter-operatividad entre diferentes plataformas.

La biblioteca RPC (Remote Procedure Call) [11], desarrollada para fa-cilitar la ejecucion de procedimientos remotos, merce una mencion especial.

3Siglas de Application programming interface, Interfaz de programacion de aplicacio-nes. Se trata de un conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a serviciosdesde los procesos y representa un metodo para conseguir abstraccion en la programacion.

6 1.4. Antecedentes y estado del arte

En los ultimos tiempos, RPC ha evolucionado para aprovechar la extensibi-lidad de XML, dando lugar a XML-RPC, middleware que tıpicamente haceuso del protocolo HTTP para el transporte de transacciones.

El intercambio de mensajes basados en XML sobre HTTP [12] ha dadolugar al protocolo SOAP (Simple Object Access Protocol) [13], parte fun-damental de la pila de protocolos que da soporte a los ası denominadosWeb Services [14], definidos por el consorcio W3C. En esta aproximacion,se utiliza WSDL (Web Services Description Language) [15] para describir lainterfaz a los objetos remotos. Es tambien destacable la API RMI (RemoteMethod Invocation) [16] para Java, la cual proporciona una funcionalidadparecida a la de RPC.

Finalmente, no puede faltar una mencion a la arquitectura CORBA(Common Object Request Broker Architecture) [17] definida por el consorcioOMG. CORBA proporciona una aproximacion basada en objetos, accesiblesde forma remota a traves de la interfaz IDL (Interface Definition Language)[18].

El paradigma publicador/suscriptor

Todas las tecnologıas anteriormente citadas tienen en comun la adop-cion del ası denominado paradigma cliente/servidor. Alternativamente, yespecialmente disenado para su utilizacion en aplicaciones con requisitos detiempo real, se ha propuesto un middleware que adopta un paradigma dis-tinto al anterior basado en una metodologıa de publicacion/suscripcion. Estemodelo se fundamenta en el intercambio asıncrono de mensajes. Aquı, lasentidades generadoras declaran una serie de topics4 que estan dispuestas apublicar y las consumidoras se suscriben a distintos topics de su interes. Deeste modo, cuando un productor publica un dato con una tematica concreta,todos los suscriptores de esta lo reciben de forma transparente a la aplica-cion. El paradigma adopta una aproximacion denominada data centric, yaque desacopla (en el tiempo y el espacio) la interaccion entre los partici-pantes (consumidores o generadores de informacion), y enfoca su esfuerzoen la distribucion de los datos, con independencia de la localizacion y elinstante de origen o destino de los mismos. Para la distribucion de infor-macion de acuerdo con el paradigma publicacion/suscripcion, la OMG haespecificado recientemente el estandar DDS [1] lo que, dada la solvencia yreconocimiento de esta institucion, ha venido a consolidar definitivamenteeste nuevo paradigma como modelo de interaccion alternativo.

De los modelos comentados anteriormente, el que mejor se adapta a laplataforma a implementar es el paradigma de publicacion/suscripcion. De

4Se utiliza el termino ingles topic al tratarse del nombre de la entidad DDS. Dichotermino podrıa traducirse como tema o tematica.

Introduccion 7

acuerdo con este modelo, las aplicaciones de monitorizacion y de deteccionpodrıan publicar sus diferentes alarmas de acuerdo a una serie de topics, so-bre los que se suscribirıan distintas entidades de red interesadas. La elecciondel estandar DDS de la OMG para el desarrollo del proyecto garantiza lassiguientes ventajas de acuerdo con [19]:

1. Este proporciona un paradigma conceptualmente sencillo como es pu-blicacion/suscripcion.

2. Es escalable dinamicamente.

3. Soporta comunicaciones de uno a uno, de uno a muchos o de muchosa muchos.

4. Facilita al desarrollador enormemente la tarea de implementacion deaplicaciones para la distribucion de datos.

1.4.2. Herramientas de monitorizacion y deteccion de intru-sos

Una vez definido el sistema de distribucion de datos para el desarrollode la plataforma es necesario seleccionar una serie de herramientas de mo-nitorizacion y de deteccion de intrusos susceptibles de ser integradas en elproyecto. Estas se clasificaran de acuerdo con las categorıas establecidas enPardo-Castellote et al. [20].

Sistemas de deteccion de intrusos

Snort. Es un sistema de deteccion y prevencion de intrusos (IDS)5 ca-paz de realizar analisis en tiempo real sobre redes IP [21]. Este incluyeun sistema de reglas flexible, que permite disenar filtros o accionesante determinados eventos. La instalacion de Snort proporciona reglaspara ataques web, backdoor, Nmap, finger, CGI, etc.

La base de datos de ataques de Snort se actualiza de forma constante,admitiendose la inclusion de reglas por parte de usuarios a traves dela lista de correo de firmas de Snort. Ademas, existen extensiones quepermiten la utilizacion de este con preprocesadores capaces de detectaranomalıas en el trafico, como es el caso de SPADE.

5Se pueden clasificar los detectores de intrusos en tres tipos: (1) Host IDS (HIDS),donde los sensores se encuentra en cada maquina, y por lo tanto vigilan unicamente dichamaquina, caso de OSSEC; (2) Network IDS (NIDS), donde los sensores se encuentran ensegmentos de red, vigilando el trafico de la misma, caso de Snort; y (3) Distributed IDS(DIDS), donde una serie de NIDS se comunican mediante un sensor central.


OSSEC. Se trata de un detector de intrusos en host (HIDS). Propor-ciona, entre otras, las funcionalidades de analisis de logs, verificacionde integridad de ficheros, monitorizacion del registro de Windows o ladeteccion de rootkits6 en tiempo real, permitiendo configurar respues-tas activas [22].

Escaneo de vulnerabilidades

Nessus. Se trata de una aplicacion para la deteccion de vulnerabilida-des. Esta compuesta por un demonio, nessusd, que realiza el escaneode un sistema objetivo; y un cliente, nessus, que muestra el avancey las conclusiones del proceso. Sus resultados pueden almacenarse enmultitud de formatos, permitiendose la toma en consideracion de estosen futuros analisis de vulnerabilidades [23].

Nmap. Es una aplicacion para la exploracion de la red y la auditorıade seguridad. Permite el descubrimiento de maquinas activas en lared, el escaneo de puertos de una maquina objetivo, los servicios quese estan ejecutando en la misma o el sistema operativo que utiliza [24].

Saint Scanner. Es una herramienta para la identificacion de vulne-rabilidades de, entre otros, dispositivos de red, sistemas operativos,aplicaciones web, de escritorio y bases de datos. Puede detectar y so-lucionar posibles debilidades en la seguridad de una red, anticipandosea posibles intrusos [25].

Sniffers

Wireshark. Es un analizador de protocolos, se trata de una herra-mienta muy utilizada para el analisis y resolucion de problemas enredes de comunicaciones. Anade numerosas opciones de organizaciony filtrado de informacion, permitiendo la visualizacion de todo el trafi-co que pasa a traves de la red una vez establecida la configuracion dela interfaz en modo promiscuo [26].

Kismet. Es un detector de redes, husmeador de paquetes (sniffer)y detector de intrusos para redes LAN inalambricas 802.11. Realizaun funcionamiento pasivo, es decir, permite la deteccion de puntos deacceso, clientes inalambricos y su asociacion, sin el envıo de paquetesdetectables. Funciona en cualquier tarjeta que soporte el modo monitorraw [27].

6Un rootkit es una herramienta, o grupo de herramientas, que tiene la finalidad deesconder programas, procesos, archivos, directorios, claves de registro o puertos que per-miten a un intruso acceder a un sistema de forma remota.

Introduccion 9

OS fingerprinting e identificacion de servicios

P0f. Se trata de una herramienta de identificacion pasiva de sistemaoperativo. Permite detectar el sistema y la version de las maquinasconectadas a un equipo, con las que se establece una conexion, o sobrelas que se puede examinar el trafico.

P0f permite ademas detectar la distancia fısica a un sistema remoto,detectar la existencia de balanceadores de carga o de firewalls. Estaaplicacion no genera trafico en la red, lo que permite identificar elsistema de equipos detras de un cortafuegos [28].

Monitorizacion de sistemas

Ganglia. Es una herramienta escalable de monitorizacion de sistemasde altas prestaciones como clusters o grids. Permite al usuario exami-nar estadısticas como, por ejemplo, la carga de CPU o la utilizacionde la red en una serie de maquinas.

Utiliza dos demonios, gmond, que se ejecuta en cada uno de los nodosdel cluster que se desea monitorizar; y gmetad, que obtiene informacionvıa XML a intervalos regulares de tiempo desde los nodos, almacenan-do la informacion en una base de datos Round-Robin7 [29].

LibGTop. Es una biblioteca para la monitorizacion de sistemas queforma parte del proyecto GNOME. Esta permite, a traves de una seriede funciones definidas en la misma, acceder a datos de un host como lacarga de CPU, la ocupacion del disco duro, memoria principal y swap,ademas de informacion relativa al uso de las distintas interfaces de reddel mismo [30].

1.4.3. Aplicaciones integradoras de herramientas de monito-rizacion

Nagios

Nagios es un sistema de monitorizacion de redes ampliamente utilizado[31]. Proporciona informacion acerca de una serie de recursos de diferentesmaquinas como la carga del procesador, la utilizacion del disco o la ocupa-cion de la memoria principal; ası como de servicios de red, entre los que se

7En concreto utiliza RRDtool, una herramienta que trabaja con una base de datoscon planificacion Round-Robin. Se trata de una aplicacion utilizada en otros sistemas demonitorizacion como Munin. Se tratara este tipo de almacenamiento con un mayor nivelde detalle en el apartado 4.4.4.


encuentran SMTP, POP3, HTTP o PING. No obstante, su verdadero poten-cial recae en la escalabilidad de la plataforma. Esta implementa un sistemade plugins que le permite recolectar informacion de cualquier tipo a travesde la utilizacion del complemento adecuado.

El sistema permite dos tipos de comunicaciones: modo cliente, estable-ciendose conexiones SSL entre Nagios y sistemas de monitorizacion remotos;y modo servidor, recibiendo de forma pasiva los resultados de los diferentesnodos de monitorizacion.

AlienVault OSSIM

OSSIM (Open Source Security Information Management) [32] es una co-leccion de herramientas disenadas para la gestion de la seguridad en sistemasa traves de la deteccion y la prevencion de intrusos. Por tanto, a diferenciadel caso anterior, esta plataforma esta enfocada en la seguridad de redesen lugar de en la monitorizacion de sistemas. OSSIM incluye herramientascomo Snort o Nessus para la deteccion de intrusiones, P0f para el anali-sis de los sistemas de la red o Ntop para la deteccion de comportamientosanomalos. No obstante, la coleccion de herramientas incluye la capacidad derecoleccion de informacion de sistemas de monitorizacion como Nagios.

La estructura de OSSIM integra una base de datos para el almacena-miento de informacion, diferentes agentes para la recoleccion de datos y unservidor para procesar la informacion recolectada. Ademas, esta incorporaun motor de correlacion que permite la actuacion de OSSIM como sistemade prevencion de intrusos.

MonAMI

MonAMI es un framework para la recopilacion y difusion de informacionprocedente de distintos sensores y sistemas [33]. Su implementacion se basaen el establecimiento de un demonio de monitorizacion para la recoleccionde datos procedentes de distintos objetivos a traves de una arquitectura deplugins, permitiendo la inclusion de funcionalidad de forma progresiva. En-tre los plugins de monitorizacion se implementa el control de aplicacionescomo Apache HTTP, MySQL, Torque, Apache Tomcat o Disk Pool Manager(DPM). Ademas, el sistema ofrece diferentes alternativas para la difusion dela informacion de monitorizacion recogida, entre estas se encuentra la utili-zacion de ficheros de log, bases de datos MySQL o el sistema de visualizacionde Ganglia y GridView.

Introduccion 11

Pandora FMS

Pandora FMS (Flexible Monitoring System) es una aplicacion para lamonitorizacion de todo tipo de sistemas y aplicaciones [34]. Permite cono-cer el estado de cualquier elemento hardware, de aplicaciones o del sistemaoperativo, recolectando informacion incluso a traves del protocolo SNMP(Simple Network Monitoring Protocol), lo que le permite recibir informa-cion de cualquier dispositivo que utilice este.

La aplicacion utiliza el paradigma cliente/servidor, examinando la infor-macion a traves del uso de agentes de monitorizacion. Este sistema es muyflexible e incluye agentes incluso para el acceso a datos procedente de Na-gios. La informacion recolectada por estos es almacenada, finalmente, porservidor de Pandora FMS en una base de datos.

1.5. Restricciones

A continuacion se exponen una serie de restricciones, o factores limita-tivos, existentes en el ambito del diseno e implementacion de la aplicacion,que condicionan la seleccion de las diferentes alternativas.

1.5.1. Factores dato

Los factores dato hacen referencia a limitaciones impuestas que no pue-den ser modificadas a lo largo del desarrollo del proyecto. En este se tendranen cuenta los siguientes:

Aspectos Economicos En relacion al apartado economico, el proyecto de-be reducir su coste tanto en aspectos hardware como en el software.

Aspectos Temporales En este sentido, se ha de tener en cuenta que elproyecto debe estar finalizado antes de diciembre de 2010.

Hardware Para el desarrollo y simulacion del sistema se contara con:

Dos ordenadores personales pertenecientes al autor del proyecto.

Una red LAN gestionada a traves de la conexion de dispositivosa un router WIFI de 4 puertos 10/100 Mbit/s.

Software Dentro de los aspectos software se deberan considerar algunascircunstancias relacionadas con la plataforma de desarrollo. El pro-yecto debera tener en cuenta las arquitecturas, sistemas operativos

12 1.6. Recursos

y compiladores soportados por el RTI Data Distribution Service. Te-niendo en cuenta estos y el software y hardware del que se dispo-ne, se trabajara con las plataformas soportadas por el middlewarei64Linux2.6gcc4.3.2 e i86Linux2.6gcc4.1.2.tar.gz, para arquitecturasx86 y x86 64 sobre GNU/Linux, respectivamente.

Humanos En el desarrollo del proyecto participaran un alumno y los dosdirectores del proyecto.

1.5.2. Factores estrategicos

Los factores estrategicos son factores que no dependen de la naturalezadel problema, permitiendo tomar decisiones entre diversas alternativas con lamejora de aspectos como los costes, la calidad o la escalabilidad del proyectoen mente. Para este proyecto, se consideran como decisiones estrategicas:

Plataforma de desarrollo Se escoge GNU/Linux como plataforma parael desarrollo debido a la libertad que ofrece al programador y la grancantidad de herramientas que se proporcionan para este. El RTI DataDistribution Service soporta este sistema, por lo que se podran utilizarlas herramientas y bibliotecas del mismo sin ningun problema.

Entorno de programacion Se ha elegido el entorno de desarrollo librepara C/C++, Eclipse C/C++ Development Tooling - CDT. Eclipsees un entorno de desarrollo que proporciona, ademas de herramien-tas para la edicion y gestion de codigo, una buena integracion conel depurador libre GDB, la herramienta GNU Make y el compiladorGCC.

Depuracion de errores y rendimiento Se incluiran opciones de compi-lacion condicional para activar mensajes de depuracion en el codigocon el objetivo de detectar y corregir errores tanto en la etapa dedesarrollo, como en la de mantenimiento del software. Ademas, se uti-lizara la herramienta Valgrind para examinar la correcta liberacion derecursos, comprobando ası el uso eficiente de la memoria por parte dela aplicacion.

1.6. Recursos

A continuacion se describiran los recursos necesarios para el desarrollodel proyecto. Se diferenciaran estos en funcion de su condicion, es decir,recursos humanos, hardware y software.

Introduccion 13

1.6.1. Humanos

Prof Dr. Juan Manuel Lopez Soler. Profesor del Departamento deTeorıa de Senal, Telematica y Comunicaciones de la Universidad deGranada, como tutor del proyecto.

D. Javier Sanchez Monedero. Becario FPDI del Departamento de In-formatica y Analisis Numerico de la Universidad de Cordoba, comoco-tutor del proyecto.

D. Fernando Garcıa Aranda. Alumno de Ingenierıa de Informatica dela Escuela Tecnica Superior de Ingenierıas Informatica y de Teleco-municacion de la Universidad de Granada, que sera el encargado derealizar el proyecto siguiendo las directrices definidas por los tutoresdel mismo.

1.6.2. Hardware

Para el desarrollo se dispone de los siguientes recursos hardware:

Ordenador PC poratil, con procesador Intel Core 2 Duo (T7200), 2GHz, 4 MB de memoria cache, 2 GB de memoria RAM y 120 GB dedisco duro.

Ordenador PC sobremesa, con procesador Intel Core I3, 2.8 GHz, 4MBde memoria cache, 4 GB de memoria RAM y 1 TB de disco duro.

Router WIFI Xavi 7868r.

1.6.3. Software

Los recursos software seran:

Ubuntu Linux 10.04 y 10.10, distribucion de GNU/Linux bajo la querealizara el desarrollo principal de la solucion. Ademas, se probara elcorrecto funcionamiento de la aplicacion en Fedora y CentOS.

Entorno de desarrollo integrado para C/C++ Eclipse C/C++ Deve-lopment Tooling - CDT.

Planner, herramienta para la gestion y seguimiento de proyectos.

Coleccion de Compiladores de GNU (GCC), que incluye los compila-dores de C y C++ que utilizaremos.

14 1.7. Fases de desarrollo

GNU build system o Autotools, herramienta muy utilizada en proyectosde software libre para la generacion automatica de ficheros Makefileadaptados a cada sistema, generacion y mantenimiento de traduccionescon Gettext, analisis de dependencias, etc.

Depurador GDB.

Valgrind como herramienta de depuracion de problemas de memoriay de rendimiento de programas.

Doxygen, generador multilenguaje para la documentacion del codigofuente de la aplicacion.

VirtualBox, software de virtualizacion para la realizacion de pruebascon diferentes maquinas en una red.

Biblioteca de distribucion de datos RTI Data Distribution Service 4.5c,ası como las aplicaciones rtiddsgen y rtiddsspy incluidas en ella.

Paquete procesador de textos LATEXy plugin del mismo para el editorde textos GEdit.

1.7. Fases de desarrollo

Para el desarrollo de este proyecto se han considerado una serie de fasesbien diferenciadas

Definicion del proyecto En esta fase se realizara una primera aproxima-cion a la problematica a la que se quiere dar solucion. De esta forma,se valorara el contexto actual y se establecera una primera definicionformal del proyecto.

Especificacion de requisitos Se trata de delimitar la definicion del pro-yecto realizada anteriormente. Para ello, se identificaran los objetivosy se capturaran los requerimientos funcionales y no funcionales delsistema.

Revision del estado del arte En esta fase se realizara un estudio de laspartes fundamentales en el desarrollo de la aplicacion final:

Se debera realizar una revision de las tecnologıas relacionadascon DDS, ası como las diferentes implementaciones disponiblesdel estandar.

Introduccion 15

Se examinaran soluciones previas que se acerquen a la definiciondel problema desarrollada anteriormente, observandose solucio-nes disponibles para la monitorizacion de eventos y la deteccionde intrusos en sistemas en red.

Con objeto de analizar la implementacion un sistema que inte-gre herramientas de forma escalable, se estudiaran bibliotecas ytecnicas de implementacion de sistemas de plugins.

Por ultimo, se examinaran diferentes soluciones para la notifica-cion de eventos a usuarios.

Analisis del sistema En esta fase se analizaran los requerimientos parasentar las bases de una solucion al problema, incluyendose la identifi-cacion a alto nivel de las necesidades del sistema.

Diseno del sistema Esta etapa incluira el diseno arquitectonico del siste-ma, la especificacion de operaciones, el diagrama de clases del mismo,etc.

Implementacion Se implementaran los modelos descritos en las fases an-teriores.

Pruebas Durante esta fase se evaluaran las prestaciones de las herramientasdesarrolladas a traves de su ejecucion en entornos reales, valorandoespecialmente su flexibilidad.

Revision del trabajo Se realizara una revision del trabajo documentalgenerado a lo largo de las fases anteriores, de la que resultara un ma-nual tecnico final. Ademas, se obtendran una serie de conclusiones yse estableceran las bases y vıas para futuros trabajos.

Capıtulo 2

Especificacion de requisitos

El objetivo de este capıtulo es identificar el conjunto de requerimientosque el sistema debe cumplir.

2.1. Requisitos funcionales

Son aquellos que se encuentran orientados a la funcionalidad que debedesempenar la aplicacion de cara al usuario final. Entre estos se identifican:

Construccion de un entorno extensible Implementacion de una arqui-tectura de plugins que proporcione una interfaz sencilla para la incor-poracion progresiva de funcionalidad a la aplicacion.

Implementacion de plugins Inclusion sucesiva de plugins para el tra-tamiento de la informacion generada por diferentes herramientas demonitorizacion y de deteccion de intrusos.

Definicion de polıticas de Calidad de Servicio (QoS) Se debera in-corporar a la aplicacion la posibilidad de establecer una serie de polıti-cas de QoS para la transmision de la informacion generada por losdiferentes sensores.

Definicion de una interfaz para la administracion Se debera imple-mentar una interfaz para el establecimiento de las diferentes polıticasde emision de informacion. De forma complementaria, se debera cons-truir un entorno que muestre la informacion recogida por los suscrip-tores de los diferentes sensores de la red.

Definicion de un sistema de configuracion La aplicacion debera incluirun sistema de configuracion intuitivo para la adaptacion del funciona-miento de la aplicacion a las necesidades del administrador.

17

18 2.2. Requisitos no funcionales

2.2. Requisitos no funcionales

Se orientan al funcionamiento final de la aplicacion. Se trata de requi-sitos que no tienen que ver con la funcionalidad de esta, sino que, como seobservara mas adelante, estan orientados a caracterısticas que debe cumplirel funcionamiento de la misma. Entre estos se incluyen:

Portabilidad Se debera adoptar una solucion lo suficientemente portablepara permitir su uso en sistemas GNU/Linux, compilando tanto paraarquitecturas x86 como para x86 64.

Rendimiento y consumo de recursos La creacion de entidades DDS,hebras, etc. conllevara la asignacion y liberacion constante de recur-sos. Esta debera realizarse de forma eficiente, para no degradar lasprestaciones de la maquina donde se ejecuta el proceso.

Facilidad de instalacion El proceso de instalacion del sistema debera sersencillo, siendo equivalente al de otras aplicaciones en GNU/Linux.

Transparencia y abstraccion Debera abstraerse al maximo al usuarioadministrador de tareas de programacion, creacion de entidades DDS,etc.

Capıtulo 3

Planificacion

A partir de las fases del proyecto definidas en el capıtulo de introduccion,se presenta una estimacion inicial de las tareas en las que se descompondra eldesarrollo del mismo.

La planificacion del proyecto se gestiona con ayuda de la aplicacion librePlanner [35]. Esta proporciona un entorno de gestion de tareas sencillo quepermite:

Gestionar calendarios.

Gestionar recursos.

Seguir el desarrollo del proyecto.

Enlazar tareas.

Exportar los datos a diferentes formatos.

En el Cuadro 3.1 se muestra la asignacion temporal a las tareas defini-das en el apartado 1.7. En la Figura 3.1 se muestra el diagrama de Ganttcorrespondiente a dicha asignacion.

19

20

Tarea Inicio Fin Dıas

1. Definicion del proyecto 1 dic 11 dic 9 dıas1.1 Descripcion del problema 1 dic 4 dic 4 dıas1.2 Definicion de objetivos y restricciones 7 dic 11 dic 5 dıas

2. Especificacion de requisitos 14 dic 18 dic 5 dıas2.1 Elaboracion del documento 14 dic 18 dic 5 dıas

3. Revision del estado del arte 21 dic 15 ene 39 dıas3.1 Investigacion de soluciones previas 21 dic 1 ene 10 dıas3.2 Investigacion de componentes software 4 ene 15 ene 29 dıas

3.2.1 Bibliotecas y tecnicas de plugins 4 ene 15 ene 10 dıas3.2.2 Bibliotecas de monitorizacion 4 ene 15 ene 10 dıas3.2.3 Bibliotecas de notificacion 4 ene 15 ene 9 dıas

4. Analisis del sistema 25 feb 18 mar 16 dıas4.1 Modelado estatico 15 feb 5 mar 7 dıas4.2 Modelado dinamico 8 mar 16 mar 2 dıas4.3 Revision del documento 17 mar 18 mar 2 dıas

5. Diseno 19 mar 16 abr 21 dıas5.1 Modelado estatico 15 feb 5 mar 7 dıas5.2 Modelo de interaccion 30 mar 6 abr 6 dıas5.3 Diagrama de clases 7 abr 14 abr 6 dıas5.4 Revision del documento 15 abr 16 abr 2 dıas

6. Implementacion 1 jul 13 oct 75 dıas6.1 Demonio (CCPublisher) 1 jul 25 ago 40 dıas

6.1.1. Sistema de plugins 1 jul 12 jul 8 dıas6.1.2. Integracion de DDS 13 jul 19 jul 5 dıas6.1.3. Desarrollo de plugins 20 jul 16 ago 20 dıas6.1.4. Ficheros de configuracion 17 ago 25 ago 7 dıas

6.2 Programa cliente (CCSubscriber) 26 ago oct 7 31 dıas6.2.1. Sistema de plugins 26 ago 2 sep 6 dıas6.2.2. Integracion de DDS 3 sep 9 sep 5 dıas6.2.3. Desarrollo de plugins 10 sep 23 sep 10 dias6.2.4. Interfaz 24 sep 7 oct 10 dıas

6.3. Empaquetado de los programas 8 oct 13 oct 4 dıas7. Pruebas 14 oct 27 oct 10 dıas

7.1. Realizacion de pruebas 14 oct 20 oct 5 dıas7.2. Revision de errores 21 oct 27 oct 5 dıas

8. Revision del trabajo 28 oct 8 nov 8 dıas8.1. Revision de la documentacion 28 oct 3 nov 5 dıas8.2. Obtencion de conclusiones 4 nov 8 nov 3 dıas

Cuadro 3.1: Planificacion del proyecto: tareas

Planificacion 21

Figura 3.1: Diagrama de Gantt

Capıtulo 4

Analisis del sistema

Una vez descrito el problema a traves de la identificacion de requisitos,el siguiente paso sera la realizacion de un analisis detallado de los mismos.De este modo, utilizando el Lenguaje Unificado de Modelado (UML), seidentificaran y describiran de forma grafica y textual los distintos casosde uso del sistema, se examinaran los subsistemas funcionales a traves dediagramas de paquetes y se analizara la interaccion entre los distintos objetosdel sistema mediante el uso de diagramas de secuencia.

Ademas, se realizara un analisis de los distintos elementos que com-pondran el sistema: la arquitectura de monitorizacion, el middleware, lossistemas de almacenamiento y configuracion y la interfaz de usuario.

4.1. Analisis de requisitos

4.1.1. Casos de uso del sistema

Los casos de uso proporcionan escenarios para describir, a grandes rasgos,la interaccion entre el sistema a implementar y distintos usuarios o sistemasajenos. En este apartado se identificaran los actores involucrados en el sis-tema que se pretende desarrollar, definiendo el diagrama de casos de usoque genera la interaccion de estos con el sistema, ası como una descripciondetallada de cada uno los casos identificados.

Identificacion de los actores

Usuario Se identifica con el administrador de sistemas que utiliza la he-rramienta de monitorizacion y deteccion de intrusos para examinar yanalizar el estado actual y el desempeno de los distintos hosts de unared.

23

24 4.1. Analisis de requisitos

Objeto de Monitorizacion Es el elemento, o elementos, que se desea ana-lizar periodicamente a traves del uso de la aplicacion a desarrollar.

DDS Middleware Se trata del software encargado de gestionar la funcio-nalidad relacionada con la distribucion de datos, siguiendo el paradig-ma de publicacion/suscripcion descrito en el apartado 1.4.1.

Sistema de Almacenamiento Proporciona soporte para el almacenamien-to de informacion recolectada en los procesos de analisis de los distintosObjetos de Monitorizacion.

Diagrama de casos de uso

La Figura 4.1 presenta el diagrama de casos de uso de la aplicacion.Este expone, con gran nivel de abstraccion, la interaccion del sistema conlos distintos actores definidos en el apartado anterior.

Figura 4.1: Digrama de casos de uso del sistema

Especificacion de los casos de uso

El estandar UML [36] no especifica ningun formato de plantilla para ladescripcion de los diferentes casos de uso definidos para un sistema. Por lotanto, en la practica se utilizan multitud de especificaciones disenadas pordiferentes autores, companıas, etc.

En la descripcion de los casos de uso del presente proyecto, identificadosen la Figura 4.1, se utilizara la plantilla que se define en el Cuadro 4.1.

Analisis del sistema 25

No obstante, en la bibliografıa se incluyen plantillas alternativas como la deAlistair Cockburn [37] o Dan North [38].

CU#id: Nombre del Caso de Uso

Descripcion breve del caso de uso y sus objetivos.DependenciasSi el caso de uso depende de otros (o los incluye).ActoresActores que interaccionan con un caso de uso especıfico.PrecondicionesConjunto de condiciones que han de ser ciertas al comenzar la secuenciade interacciones que se definen en un caso de uso.PostcondicionesCondicion siempre cierta al final del curso normal.Curso normalNarracion de la secuencia de pasos mas habitual en el caso de uso.Curso alternativoDescripcion de las ramas alternativas o situaciones excepcionales fueradel curso normal.

Cuadro 4.1: Plantilla para la definicion de casos de uso

Una vez definida la plantilla, se describe cada uno de casos identificadosen la Figura 4.1.

CU#1: Difundir datos de monitorizacion

El Usuario desea difundir a la red el estado actual de una serie parametrosdel Objeto de Monitorizacion.DependenciasSe necesitan, a traves de su inclusion, los casos de uso CU4 y CU5.ActoresUsuario, Objeto de Monitorizacion y DDS Middleware.PrecondicionesNo existen precondiciones para este caso de uso.PostcondicionesLa informacion recolectada del Objeto de Monitorizacion, en relacion ala serie de parametros previamente indicada, es transmitida a la red porDDS Middleware.Curso normal1. El Usuario inicia el procedimiento de difusion de la informacion demonitorizacion.


2. A traves de la inclusion del caso de uso CU4 se realiza la carga dela configuracion. Esta manejara tanto el proceso de difusion, como losparametros que se examinan del Objeto de Monitorizacion en el pasosiguiente.3. Mediante la inclusion del caso de uso CU5, de acuerdo con los parame-tros recogidos en el paso anterior, se realiza la extraccion de la informacionrequerida acerca del Objeto de Monitorizacion.4. Una vez recogidos estos datos, DDS Middleware se encarga de difun-dirlos a la red.Curso alternativoNo existen cursos alternativos para este caso de uso.

CU#2: Recibir datos de monitorizacion

El Usuario desea recibir datos de monitorizacion procedentes de elementosde la red de acuerdo a una serie de parametros especificados previamente.DependenciasSe necesita, a traves de su inclusion, el caso de uso CU4.ActoresUsuario, DDS Middleware y Sistema de Almacenamiento.PrecondicionesNo existen precondiciones para este caso de uso.PostcondicionesEl Usuario recibe informacion relativa a una serie de parametros quediferentes entidades han difundido en la red.Curso normal1. El Usuario inicia el procedimiento de recepcion de la informacion.2. Mediante la inclusion del caso de uso CU4, se carga la configuracionde la recepcion de la informacion, incluyendo los parametros de monito-rizacion que el Usuario desea recibir.3. Se reciben periodicamente, de forma asıncrona, los parametros de mo-nitorizacion definidos en el paso anterior.Curso alternativoDependiendo de si ası se indica en la configuracion recogida en el segun-do paso, se debera realizar el siguiente procedimiento cada vez que seproduzca la recepcion de informacion:4. Se almacena la informacion recolectada a traves del caso de uso CU6.

CU#3: Visualizar datos de monitorizacion

El usuario desea visualizar de forma unificada los datos de monitorizacionque han sido, y estan siendo, recolectados.DependenciasEste caso de uso no tiene dependencias.


ActoresUsuario y Sistema de Almacenamiento.PrecondicionesNo existen precondiciones para este caso de uso.PostcondicionesSe muestran al Usuario, de forma normalizada, los eventos recibidos yacumulados en el Sistema de Almacenamiento.Curso normal1. El usuario solicita la visualizacion de datos de monitorizacion.2. Se realiza una peticion al Sistema de Almacenamiento para la lecturade los datos de monitorizacion que en el se registran.3. Se muestra la informacion de forma normalizada al Usuario.Curso alternativoNo existe un curso alternativo en este caso de uso.

CU#4: Cargar configuracion

CU1 y CU2 necesitan la carga de una serie de caracterısticas que influyenen diversos aspectos de la difusion y recepcion de informacion. CU4 realizaesta labor, lo que le convierte en un caso de uso de inclusion para estos.DependenciasEl caso de uso es utilizado, a traves de su inclusion, tanto por CU1 comopor CU2.ActoresUsuario.PrecondicionesEl Usuario debe haber iniciado el caso de uso CU1 o CU2.PostcondicionesSe extraen las caracterısticas de configuracion necesarias para las tareasposteriores de CU1 o CU2.Curso normal1. El caso de uso base solicita, a raız de una peticion del Usuario, la cargade configuracion para la difusion o recepcion de informacion.2. Se extrae, a partir de una serie de ficheros de configuracion, la infor-macion requerida para el desarrollo del caso de uso que incluye a este:parametros a examinar en el Objeto de Monitorizacion, frecuencia deenvıo de informacion, polıticas de QoS, opciones de recepcion, etc.3. Se proporciona la informacion adecuada al caso de uso base.Curso alternativoNo existe un curso alternativo en este caso de uso.


CU#5: Obtener datos de monitorizacion

Una vez obtenidos los parametros de configuracion necesarios, a travesde la inclusion de CU4, el caso de uso CU1 requiere la obtencion de unaserie de datos procedentes del Objeto de Monitorizacion para la difusionde informacion. El presente caso de uso realiza dicha labor.DependenciasEl caso de uso es utilizado (a traves de su inclusion) por CU1.ActoresUsuario y Objeto de Monitorizacion.PrecondicionesEl Usuario debe haber iniciado el caso de uso CU1 y deben haberse car-gado los parametros de configuracion (CU4).PostcondicionesSe obtiene informacion acerca del estado actual de una serie de parametrosrelativos al Objeto de Monitorizacion.Curso normal1. El caso de uso CU1 solicita el estado actual del Objeto de Monitoriza-cion de acuerdo a una serie de parametros.2. Se examina el estado actual de dichos parametros en el Objeto deMonitorizacion y se extraen en un formato normalizado para su difusionen CU1.Curso alternativoNo existe un curso alternativo en este caso de uso.

CU#6: Almacenar datos de monitorizacion

El CU2 permite, como uno de sus posibles flujos de ejecucion, la acu-mulacion de la informacion de monitorizacion recolectada en un Sistemade Almacenamiento. Este procedimiento se realiza en el presente caso deuso.DependenciasEl caso de uso es utilizado, extiende funcionalidad, en CU2.ActoresUsuario y Sistema de Almacenamiento.PrecondicionesEl Usuario debe haber iniciado el caso de uso CU2. Ademas, se debehaber realizado previamente la carga de la configuracion de la recepcion(CU4).PostcondicionesLa informacion de monitorizacion recolectada queda guardada en el Sis-tema de Almacenamiento.Curso normal1. El caso de uso CU2 solicita el almacenamiento de una serie de datosde monitorizacion en el Sistema de Almacenamiento.


2. Se realiza una conexion con el Sistema de Almacenamiento y se intro-ducen los datos de acuerdo con las caracterısticas indicadas en la confi-guracion cargada en CU4 y en funcion de la naturaleza de los mismos.Curso alternativoNo existe un curso alternativo en este caso de uso.

4.1.2. Subsistemas funcionales

Una vez identificados los casos de uso del sistema, el siguiente paso sera laclasificacion de estos de acuerdo con su funcionalidad. Este procedimiento,que se realizara a traves de la elaboracion del diagrama de paquetes UMLdel mismo, permitira establecer una division del problema en distintos sub-sistemas funcionales.

Un diagrama de paquetes puede ser utilizado para organizar cualquiertipo de clasificador UML: clases, entidades, casos de uso, etc. Para la ela-boracion del diagrama, se toma como ejemplo el modelo presentado en [39]:se establecen los principales subsistemas de funcionamiento como paquetesy se relacionan estos con los actores involucrados en los casos de uso quecontiene cada subsistema. El resultado se muestra en la Figura 4.2.

Como puede observarse, se han identificado tres subsistemas funcionalessobre los que debera organizarse la solucion final: Publisher, Subscriber yUser Interface.

Publisher Dentro del subsistema Publisher se incluyen los diferentes casosde uso relacionados con el proceso de difusion de informacion proce-dente de los distintos Objetos de Monitorizacion. Se incluyen en el,por lo tanto, los siguientes casos de uso:

Difundir datos de monitorizacion (CU1).

Cargar configuracion (CU4).

Obtener datos de monitorizacion (CU5).

De esta forma, el subsistema Publisher debera ser capaz de recolectarinformacion de diferentes parametros procedentes de Objetos de Mo-nitorizacion, de acuerdo a una serie de caracterısticas de configuracion,difundiendo los datos obtenidos en un dominio DDS.

Subscriber El subsistema Subscriber contiene los casos de uso relacionadoscon la recepcion de informacion de monitorizacion difundida por elsubsistema Publisher. Los casos de uso incluidos son:

Recibir datos de monitorizacion (CU2).

Cargar configuracion (CU4).


Figura 4.2: Diagrama de paquetes del sistema

Almacenar datos de monitorizacion (CU6).

Por lo tanto, el subsistema Subscriber se encargara de obtener la infor-macion difundida por Publisher en un dominio DDS. La recepcion serealizara de acuerdo a una serie de caracterısticas de configuracion, pu-diendose almacenar dicha informacion para su visualizacion y analisisposterior.

User Interface El ultimo subsistema que compone el proyecto es la inter-faz de visualizacion. Esta esta compuesta unicamente por el caso deuso “Visualizar datos de monitorizacion” (CU3), encargandose ası deproporcionar al administrador un sistema de visualizacion normalizadode los eventos recolectados y almacenados por Subscriber.

4.1.3. Operaciones del sistema

En apartados anteriores se identificaron los distintos componentes y ac-tores involucrados en el funcionamiento del sistema a desarrollar. En esta


seccion se analizaran, a grandes rasgos, los procesos de interaccion que si-guen los principales subsistemas identificados en el diagrama de paquetes dela Figura 4.2.

Los diagramas de secuencia describen la colaboracion entre los diferen-tes objetos que componen el sistema. Se trata, por tanto, de una serie dediagramas de interaccion que detallan las operaciones que se llevan a cabo,que mensajes son enviados y cuando.

La descripcion de las distintas operaciones, presentadas a continuacion,sera refinada en el siguiente capıtulo, una vez sean definidas las clases yobjetos sobre los que se basara directamente la implementacion del sistema.

Publisher

La Figura 4.3 muestra el diagrama de secuencia que representa las ope-raciones de Publisher con el resto de actores involucrados en el desarrollode los casos de uso que este alberga: Usuario, Objeto de la Monitorizaciony DDS Middleware.

Figura 4.3: Diagrama de secuencia: Publisher

A continuacion se realiza una descripcion paso a paso del diagrama:

1. El usuario envıa el mensaje iniciar monitorizacion() a Publishercon objeto de que este inicie todo el proceso de recoleccion de datos yla difusion de la informacion de monitorizacion.

2. Una vez recibido el mensaje de iniciacion, Publisher debe cargar laconfiguracion que definira tanto las caracterısticas de extraccion de la


informacion, como las polıticas que debera seguir a la hora de trans-mitir esta a traves del middleware.

3. Una vez cargada la informacion, se inicia un bucle de monitorizacion-difusion, que solo podra ser interrumpido por un mensaje de finaliza-cion de la monitorizacion. El primer paso en este bucle sera la peticion,desde Publisher al Objeto de la Monitorizacion, del estado actual delos parametros deseados a traves del mensaje obtener datos().

4. El Objeto de la Monitorizacion devuelve la informacion requerida aPublisher.

5. Una vez obtenidos los datos actuales del objeto de monitorizacion,Publisher transmite estos al middleware para la realizacion del envıo.

6. Los datos son enviados por el middleware y se vuelve al paso 3.

7. Si Publisher recibe en algun momento, por parte del Usuario, el men-saje finalizar monitorizacion(), se detiene el bucle de monitori-zacion-difusion y, por tanto, todo el proceso descrito anteriormente.

Subscriber

La Figura 4.4 muestra el diagrama de secuencia de las operaciones rea-lizadas en torno a Subscriber. Este subsistema esta relacionado tanto con elUsuario como con DDS Middleware, ademas, en caso de ser requerido porla configuracion, este se relacionara tambien con el Sistema de Almacena-miento.

A continuacion se describe la interaccion que realiza este subsistema atraves de la siguiente serie de pasos:

1. Al igual que en Publisher, el Usuario inicia el proceso de recepcionde informacion a traves del mensaje iniciar recepcion(), que reci-bira Subscriber.

2. Una vez recibido este mensaje, Subscriber inicia el proceso de recepcioncargando primero la configuracion que fijara tanto las caracterısticasdel proceso de recepcion, como la posibilidad de almacenar la infor-macion recibida en el proceso.

3. Se inicia el bucle de recepcion-almacenamiento esperando la llegada delos datos de monitorizacion a los que Subscriber esta suscrito. De estemodo, en cuanto el middleware recibe datos, los comunica a Subscribera traves del mensaje datos recibidos().


Figura 4.4: Diagrama de secuencia: Subscriber

4. El procedimiento que se sigue una vez recibidos los datos dependede las caracterısticas de configuracion que se cargaron en el paso 2.Si se ha seleccionado el almacenamiento en algun tipo de Sistema deAlmacenamiento, se envıa el mensaje almacenar datos() a este paraque incluya los datos recibidos en su registro.

5. Subscriber sigue a la espera de la recepcion asıncrona de un nuevomensaje por parte del middleware, proceso que solo se interrumpe encaso de recibirse el mensaje finalizar recepcion() por parte delUsuario.

User Interface

El ultimo escenario presentado es el que relaciona el subsistema de vi-sualizacion, User Interface, tanto con el Usuario que solicita esta, como conel Sistema de Almacenamiento que alberga los datos de monitorizacion. Eldiagrama de secuencia de User Interface se muestra en la Figura 4.5.

A continuacion se describen los pasos de este:

1. El Usuario solicita a User Interface la visualizacion de los datos demonitorizacion actuales e historicos a traves del paso del mensajemostrar datos monitorizacion().

2. Ante la peticion que realiza el usuario, User Interface debe recuperar

34 4.2. Analisis de la arquitectura de monitorizacion

Figura 4.5: Diagrama de secuencia: User Interface

los datos de monitorizacion registrados en el Sistema de Almacena-miento. Para ello, envıa el mensaje obtener datos monitorizacion()

a este.

3. El Sistema de Almacenamiento proporciona los datos solicitados a UserInterface.

4. Con los datos obtenidos del Sistema de Almacenamiento, User Inter-face muestra al usuario la informacion solicitada.

4.2. Analisis de la arquitectura de monitorizacion

Los subsistemas funcionales definidos hacen frente a un proceso de mo-nitorizacion y de deteccion de intrusos a traves de la difusion de eventosutilizando el middleware DDS.

En Millar et al. [33] se muestra un estudio de la arquitectura de MonAMI,un framework para la monitorizacion de servicios a traves de un sistema deplugins. MonAMI parte de un modelo sencillo de interaccion, al que denomi-na three-component model, que presenta un intercambio interactivo de flujosde informacion entre tres componentes: monitoring target (objeto de la mo-nitorizacion), monitoring agent (agente de monitorizacion) e informationstorage (almacenamiento de informacion).

El sistema de monitorizacion y de deteccion de intrusiones que se deseadesarrollar, al que se denominara de ahora en adelante Cave Canem, tomacomo referencia este modelo sencillo de monitorizacion, englobando los trescomponentes de este en de los subsistemas identificados anteriormente. Acontinuacion se describe cada uno de los elementos que lo componen:

Monitoring target Se trata del sistema sobre el que se desea mantener in-formacion. Esta puede estar relacionada tanto con componentes hard-


ware (como la frecuencia o temperatura de un procesador), como conservicios software (por ejemplo, las alertas generadas por un IDS).

A partir del analisis de casos de uso realizado en el apartado 4.1.1, sepodrıa identificar al monitoring target con el actor Objeto de Moni-torizacion con el que el Publisher de Cave Canem, al que se denomi-nara de ahora en adelante Cave Canem Publisher o CCPublisher,mantiene contacto periodico para actualizar el estado de una serie deparametros.

Monitoring agent Este segundo componente representa al software quetraslada el flujo de informacion desde el monitoring target al sistemade almacenamiento. El medio de interaccion con los diferentes objetosde la monitorizacion difiere en funcion de la naturaleza del mismo. Portanto, el diseno debe contemplar un sistema de interaccion especıficopara cada objetivo. En Cave Canem, los agentes de monitorizacionestaran integrados en CCPublisher.

Information storage Este ultimo componente utiliza metodos de almace-namiento, normalmente no volatiles, para registrar de forma periodicala informacion recibida. Entre los sistemas de almacenamiento masusados en sistemas de monitorizacion se encuentran, entre otros, losficheros de log, las bases de datos relacionales (como MySQL) o lasbases de datos Round-Robin (como es el caso de RRDtool en Ganglia[29]).

Como pudo observarse en la identificacion de los actores involucradosen los casos de uso de la aplicacion, el sistema de almacenamiento serepresenta en estos como un actor con el que el Subscriber de Cave Ca-nem, al que se denominara de ahora en adelante Cave Canem Subscri-ber o CCSubscriber, realiza un proceso de comunicacion asıncrono,almacenando la informacion recibida en cuanto esta se encuentra dis-ponible, si ası se indica en la configuracion.

4.3. Analisis del middleware

Otro de los aspectos a tener en cuenta en este analisis son las carac-terısticas que el middleware elegido ofrece al sistema a implementar. Eneste apartado, se realizara una descripcion de las principales particularida-des de DDS que permiten la mejora del rendimiento de la distribucion de lainformacion de monitorizacion en Cave Canem. Una descripcion mas ampliade estas caracterısticas puede obtenerse en Farabaugh et al. [19].

36 4.3. Analisis del middleware

4.3.1. Desacople en tiempo y espacio

Como se comento en el apartado 1.4.1, DDS proporciona un modelode distribucion de publicacion/suscripcion que desacopla a publicadores ysuscriptores en tiempo y en espacio.

El desacople en tiempo se basa en la utilizacion del parametro Durabi-lity en la definicion de las polıticas de QoS de la aplicacion. Este parametrocontrola el comportamiento del middleware respecto al almacenamiento delas muestras de informacion distribuidas, poniendo en cuestion si estas de-ben almacenarse para el consumo por parte de suscriptores que se unan aldominio DDS despues de la publicacion de estas. El comportamiento puedeser, de este modo:

Volatile Bajo esta configuracion, el middleware no almacenara muestraspasadas de los datos transmitidos.

Transient El middleware almacenara un cierto numero de muestras de losdatos transmitidos para su procesamiento por consumidores que sesuscriban en un determinado momento.

Persistent Implica el almacenamiento de todas las muestras transmitidas,de modo que cualquier suscriptor pueda recibir el historico de trans-misiones de un determinado dominio DDS.

El desacople en espacio viene manejado implıcitamente por el modelo decomunicacion de DDS. Esta caracterıstica permite situar a los publicadoresy suscriptores de Cave Canem en cualquier nodo de la red sin la necesidadde realizar, en principio, ninguna configuracion extra. Por lo tanto, se pue-den establecer puntos redundantes de procesamiento y visualizacion de lainformacion de forma sencilla.

4.3.2. Filtros en la recepcion de topics

DDS se basa en el uso de topics para la comunicacion publicador/sus-criptor. Una de las funcionalidades que aporta el middleware, en relacion a larecepcion de informacion, es el filtrado de topics en funcion a su contenido.

Los Content Filtered Topics permiten definir expresiones de filtrado pa-ra la recepcion de informacion. Es decir, solo las muestras que cumplan ladefinicion de un filtro seran recibidas por las partes suscriptoras que lo defi-nan y se notificaran, por lo tanto, a la aplicacion. En unicast, el filtrado deinformacion se implementa en el origen, en lugar de en la parte suscriptora,lo que reduce en gran medida el consumo de ancho de banda.


4.3.3. Monitorizacion de eventos a traves del uso de listeners

El uso de listeners es uno de los mecanismos que permite a una apli-cacion DDS detectar cambios en el estatus de la comunicacion data-centricpublish-subscribe (DCPS)1. El uso de estos permite al programador delegardicha funcion en el middleware. Ademas, a la hora de realizar la recepcion(como reaccion al evento on data available), el listener crea una hebrade ejecucion, de forma transparente al programador, para la realizacion detareas de recepcion como, por ejemplo, el registro de la informacion reci-bida en un sistema de almacenamiento. Este hecho permite a la aplicacionsuscriptora seguir trabajando sin que se produzcan bloqueos.

4.3.4. Algunos parametros de QoS

Como ya se ha mencionado, a traves del uso de los diferentes parame-tros de QoS proporcionados por DDS, los procesos de comunicacion puedenadaptarse a las necesidades del sistema, mejorando ası el rendimiento deeste. DDS realiza la configuracion de QoS por entidad. Por lo tanto, se pue-den definir diferentes polıticas en topics, DataReaders o DataWriters. Entreestos parametros son resaltables, por la ayuda que pueden prestar para lamejora del rendimiento de la aplicacion, los siguientes:

Reliability Especifica si un DataReader recibe informacion de forma con-fiable desde un DataWriter. Basicamente, puede seleccionarse una co-municacion Best Effort, que suprima el control de retransmision de in-formacion para incrementar el rendimiento; o una comunicacion fiable,que asegure la recepcion de todos lo datos emitidos. De esta manera,el escenario de la monitorizacion podrıa configurarse de forma distintapara la transmision de informacion de diversa ındole. Ası, se podrıaescoger una polıtica Best Effort para la transmision de temperaturas,por ejemplo, donde cualquier muestra de informacion puede ser sus-tituida por una mas reciente; y fiable para la publicacion de alertasgeneradas por un IDS, donde toda la informacion debe ser tenida encuenta.

Time-based Filter Este parametro define la separacion mınima, en tiem-po, que puede existir entre los mensajes recibidos por un DataReader.De esta forma, se puede definir una tasa de recepcion menor que latasa de envıo. Esta configuracion puede ser util en aquellos casos enlos que no se necesite registrar toda la informacion que es enviada porlos DataWriters, sino valores puntuales en el tiempo.

1Tambien existen conditions y wait-sets [1].

38 4.4. Analisis del sistema de almacenamiento

History Especifica el numero de muestras de informacion almacenadas pa-ra envıos posteriores en DDS. Puede escogerse el almacenamiento detodas estas muestras, KEEP ALL, o guardar un numero N de muestras,KEEP LAST N.

4.4. Analisis del sistema de almacenamiento

Como se comento anteriormente, uno de los requisitos de la solucionplanteada es la presencia de un sistema de almacenamiento que permita elregistro de la informacion recolectada por el sistema de monitorizacion. Dadala importancia de este elemento, en el presente apartado se realizara un anali-sis de las posibles soluciones a implementar en Cave Canem. Mas adelante,en el capıtulo de diseno, se concretara la adaptacion del sistema escogidopara su posterior implementacion.

En el apartado 4.2 se enumeraron algunos de los sistemas de almacena-miento mas utilizados por herramientas de monitorizacion. A continuacionse realiza un analisis detallado de los mismos.

4.4.1. Ficheros de log

Los ficheros de log son un tipo de archivos para el registro de accionesocurridas en el funcionamiento de un sistema. Por ejemplo, los servidoresweb mantienen ficheros log que registran las diferentes peticiones realizadasal mismo. De este modo, a traves del analisis de estos, los administradoresde sistemas pueden obtener informacion acerca del uso que se ha dado alservidor, examinar problemas que han ocurrido o predecir problemas quepuedan suceder.

Syslog es un estandar para el envıo y almacenamiento de mensajes de logdefinido en el RFC 5424 [40]. Los logs generados se utilizan en la adminis-tracion de sistemas, en la realizacion de auditorıas de seguridad, ası comoen el analisis y depuracion de programas. La informacion recolectada puedeser difundida a traves de mensajes enviados a dispositivos locales, como unaterminal; puede almacenarse en ficheros, como es el caso de /var/log enUnix; o puede ser utilizada por demonios Syslog remotos.

La concepcion del sistema descrita en apartados anteriores establece co-mo requerimiento el almacenamiento continuo de datos referentes a distintosparametros de diferentes objetos de monitorizacion. Estos datos, deberan serprocesados posteriormente por una interfaz de usuario, que necesitara rapi-dez en la recuperacion de la informacion.

El almacenamiento de datos de monitorizacion en ficheros de log incre-mentales ofrece como ventaja un acceso rapido para la escritura de infor-


macion, en contraposicion a los sistemas gestores de bases de datos. Sinembargo, la recuperacion y gestion relacional de informacion en este tipode ficheros supone un coste poco asumible para su utilizacion junto a lainterfaz de usuario. Se trata, por tanto, de un sistema de almacenamientoa tener en cuenta en la generacion de mensajes de depuracion a la hora deimplementar la aplicacion, pero inadecuado para el almacenamiento de losdatos generados en el proceso de monitorizacion.

4.4.2. Ficheros estructurados: XML y CSV

Dentro de este apartado se realiza un analisis de dos formatos de ficherosestructurados ampliamente utilizados en sistemas de almacenamiento, comoson XML y CSV.

XML, siglas de eXtensible Markup Language o lenguaje extensible demarcas, es un metalenguaje extensible de etiquetas desarrollado por el WorldWide Web Consortium (W3C) [41]. XML permite definir la gramatica delenguajes especıficos, por lo que no se trata de un lenguaje en particular,sino que representa una herramienta para la definicion de lenguajes paradiferentes necesidades.

Entre las principales ventajas de XML son destacables las siguientes:

Se basa en estandares internacionales y como tal es un estandar abier-to.

Puede representar estructuras de datos comunes en el campo de lainformatica como registros, listas y arboles.

Los algoritmos de analisis sintactico para XML son simples, eficientesy consistentes dadas sus restricciones de sintaxis y analisis.

Puede utilizase para el almacenamiento y procesamiento de documen-tos.

La adopcion de XML en la industria y campos de investigacion esalta, por lo tanto existe una gran cantidad de herramientas para lageneracion de documentos y procesado de informacion almacenada enXML.

Un lenguaje basado en XML puede ser facilmente modificado de formaincremental sin perder compatibilidad hacia atras.

No obstante, XML tambien presenta una serie de desventajas, en especialen relacion a algunas circunstancias que se detallan ampliamente en [42].Algunas de estas son:


La sintaxis de XML es redundante y grande, en terminos de tamano, encomparacion a representaciones de datos alternativas, especialmente sise utiliza para representar datos tabulares. Esta redundancia afecta alrendimiento de las aplicaciones al aumentar el tamano de almacena-miento y transferencia, ası como el coste de procesamiento.

La sintaxis presenta sobrecarga de informacion para un lector humanoen comparacion con otros formatos de transferencia de datos.

Su modelo jerarquico de representacion del conocimiento es limitado encomparacion con otras alternativas, como por ejemplo, las orientadasa grafos.

Promueve el uso de estructuras de datos no relacionales (datos nonormalizados).

XML introduce un fuerte acoplo entre la representacion elegida y elprocesamiento de la informacion a diferencia de alternativas de alma-cenamiento relacional con SQL.

Como se puede observar, la mayor parte de las desventajas estan rela-cionadas con la validez de XML para la representacion de datos complejosy las relaciones entre estos. Especialmente, a la hora de representar grandescantidades de datos que deben procesarse o transmitirse, XML presenta unasobrecarga en el tamano que ocupa la informacion serializada. En el caso deCave Canem, el almacenamiento de la informacion de monitorizacion reco-lectada necesitara, para su analisis y visualizacion por parte de la interfaz deusuario, un metodo de recuperacion eficiente con la posibilidad de realizarbusquedas en un tiempo asumible, algo para lo que XML no esta disenado.No obstante, teniendo en cuenta las caracterısticas y ventajas identificadas,se puede considerar XML como un candidato a tener en cuenta para suadopcion por parte del sistema de configuracion de Cave Canem, tal comose analizara en el apartado 4.5.

Por otro lado, los ficheros CSV (Comma-Separated Values) son un tipode documento sencillo para la representacion de datos en forma de tabla[43]. En estos, las diferentes columnas se separan mediante el uso de comas(o punto y coma, dependiendo del caracter de separacion definido), mientrasque las filas se identifican mediante saltos de lınea (por lo que los camposque contengan este tipo de caracteres deberan ser encerrados entre comillasdobles). El formato CSV no indica ningun juego de caracteres concretos, nicomo van situados los bytes, ni el formato para el salto de lınea2. Estas es-

2No existe una especificacion formal para los ficheros CSV. Las unicas directrices sedefinen en el documento RFC 4180 [43], que describe un formato comun y establece eltipo MIME “text/csv”, registrado por el IANA; y en la especificacion del estandar Fielded


pecificaciones deben indicarse, normalmente, al abrir el fichero, por ejemplomediante un programa de hojas de calculo.

La principal ventaja de CSV, ademas de la especificacion sencilla y lafacilidad de lectura para cualquier lenguaje de programacion, es que los prin-cipales sistemas de hojas de calculo del mercado son capaces de leer y operarcon dicho formato (por ejemplo OpenOffice.org Calc o Excel de MicrosoftOffice). Esto permite la visualizacion sencilla de los valores almacenadosa traves de estas aplicaciones, facilitando la labor de documentacion y laevaluacion de los datos obtenidos. No obstante, CSV presenta las mismasdesventajas que XML en relacion a la velocidad de recuperacion de datosde cara a su uso en una interfaz de usuario, mas aun tratandose de un for-mato sin etiquetado. Por tanto, en este caso las bases de datos tradicionalestambien suponen una solucion mucho mas eficiente.

4.4.3. Sistemas gestores de bases de datos

Las bases de datos son agrupaciones de informacion, pertenecientes a uncontexto determinado, que se almacenan sistematicamente para su posterioruso. Los sistemas gestores de bases de datos (SGBD) permiten el almace-namiento y recuperacion de informacion de forma rapida y estructurada deuna base de datos, siendo el modelo relacional el mas utilizado en la imple-mentacion de dichos sistemas. Las bases de datos relacionales se organizanen tablas, distribuidas a su vez en registros (filas y columnas). Estos regis-tros pueden estar relacionados con otros registros de la misma u otra tablaa traves del uso de claves primarias y foraneas. La organizacion que propor-ciona este tipo de almacenamiento presenta una serie de ventajas para elregistro de informacion de monitorizacion:

Los SGBD proporcionan lenguajes de consulta o generadores de infor-mes que permiten la consulta y recuperacion sencilla de datos, elimi-nando la necesidad implementar un sistema que realice dichas tareas.

Las bases de datos relacionales permiten definir vınculos de dependen-cia entre registros de forma sencilla. Esto simplifica en gran manera eldiseno del esquema de almacenamiento, facilitando a su vez la recupe-racion y comparacion de la informacion recogida en estas.

La mayorıa de SGBD gestionan el acceso concurrente a la informacion,garantizando la ausencia de problemas derivados del acceso simultaneopor parte de distintas entidades a la informacion almacenada.

Text [44], que cubre en uno de sus apartados el formato CSV. Se pueden encontrar masreferencias a especificaciones de este formato en [45] y [46].


Entre los inconvenientes del uso de bases de datos en sistemas de moni-torizacion encontramos:

Los SGBD son programas complejos y requieren una cantidad de espa-cio en disco y memoria mucho mayor al de sistemas de almacenamientomas sencillos como los ficheros de log, XML o CSV.

El acceso y la escritura de informacion en una base de datos es unproceso costoso. Por ejemplo, el IDS Snort recomienda la utilizacionde sistemas de almacenamiento alternativos en redes con un nivel altode trafico, debido a su imposibilidad para analizar paquetes duranteel proceso de acceso y escritura de datos [47].

4.4.4. Sistemas de almacenamiento Round-Robin

Los sistemas de almacenamiento Round-Robin son herramientas para elalmacenamiento circular de informacion. En estos se almacena una cantidadde informacion fija, definida al de crear la base de datos, sustituyendoseprogresivamente las entradas mas antiguas por los ultimos valores recibidos.Se trata de un esquema ideal para el almacenamiento de informacion demonitorizacion numerica como temperaturas, cargas del procesador, tasasde transferencia en redes, etc.

Entre las ventajas de la utilizacion de este esquema de almacenamientocabe resaltar:

La rapidez y facilidad de escritura y recuperacion de la informacionque proporciona este tipo de herramientas, permitiendo incluso la rea-lizacion de consultas sobre la base de datos.

La capacidad para limitar el consumo de espacio de la base de datos,almacenando unicamente la informacion mas reciente.

El sistema de almacenamiento Round-Robin mas conocido es RRDtool(Round Robin Database tool) [48]. Este suma a las ventajas anteriormentedescritas la capacidad de generar graficas para representar la evolucion devariables de la base de datos en el tiempo. RRDtool se utiliza en aplicacionestan conocidas como Ganglia, Cacti, JFFNMS, Lighttpd, MRTG, Munin,Smokeping o Zenoss [49].

La principal desventaja de RRDtool es, en relacion al sistema que sepretende implementar, la imposibilidad de realizar almacenamiento de in-formacion no numerica, hecho que impide, por ejemplo, el tratamiento dedatos como las alertas generadas por un IDS.


La solucion a este inconveniente viene dada por la adopcion de un esque-ma de almacenamiento hıbrido, basado en la utilizacion de una base de datosrelacional con almacenamiento Round-Robin. Se describira este esquema conmas detalle en el Capıtulo 5.

4.5. Analisis del sistema de configuracion

En este apartado se revisaran algunos de los formatos mas utilizadospara la especificacion de ficheros de configuracion. A partir de este analisis sedefinira el formato a utilizar en el sistema de configuracion de Cave Canem.

4.5.1. YAML

YAML (YAML Ain’t Another Markup Language) [50] es un formato deserializacion de datos que define un lenguaje realmente legible, pudiendoser utilizado para la especificacion de ficheros de configuracion. YAML tomaconceptos de lenguajes C, Perl o Python, ası como ideas de XML y el formatopara correos electronicos definido por el RFC 2822 [51].

La principal ventaja que presenta YAML es su legibilidad y facilidadde uso, que le ha convertido en el formato de configuracion escogido porframeworks tan utilizados como Symfony. A continuacion se muestra unejemplo de fichero YAML extraıdo de [52]:

--- # Peliculas favoritas , formato de bloque

- Casablanca

- Viridiana

- Psicosis

--- # Lista de la compra , formato en linea

[leche , pan , huevos]

4.5.2. INI

INI (Windows INItialization file) [53] es un formato para la definicionde ficheros de configuracion. Se asocia a productos de Microsoft aunque esmuy utilizado tambien en otras plataformas, por ejemplo en los ficheros deconfiguracion de PHP.

Los ficheros INI pueden ser editados manualmente de forma sencilla. Sinembargo, pueden encontrarse algunos problemas en funcion de la definicionde los saltos de lınea utilizada por el sistema operativo donde se ejecute laaplicacion. A continuacion se muestra un fichero de ejemplo que se extraede [53].

44 4.5. Analisis del sistema de configuracion

[Red]

; Poner UsarProxy =0 si no hay cortafuegos

UsarProxy =1

Proxy =129.129.129.129

[Preferencias]

PaginaInicio=http :// wikipedia.org

Maximizar =1

4.5.3. JSON

JSON (JavaScript Object Notation) [54] es un formato ligero para elintercambio de datos. JSON es un subconjunto de la notacion literal deobjetos de JavaScript. Dada la simplicidad del formato, suele utilizarse estecomo alternativa a XML en AJAX, siendo mucho mas sencilla la realizacionde un analizador semantico de JSON que uno de XML.

JSON se aplica en entornos donde el tamano del flujo de datos entrecliente y servidor es de vital importancia, siendo utilizado en algunos servi-cios proporcionados por companıas como Yahoo o Google. A continuacionse muestra un ejemplo de fichero JSON extraıdo de [55]:

{"menu": {

"id": "file",

"value": "File",

"popup": {

"menuitem ": [

{"value ": "New", "onclick ": "CreateNewDoc ()"},

{"value ": "Open", "onclick ": "OpenDoc ()"},

{"value ": "Close", "onclick ": "CloseDoc ()"}

]

}

}}

4.5.4. XML

Como se menciono en el apartado 4.4.2, XML es un lenguaje ideal para eldesarrollo de ficheros de configuracion: permite representar distintas estruc-turas de datos, se basa en estandares abiertos y es utilizado ampliamenteen entornos industriales y de investigacion. A continuacion se muestra unejemplo de fichero XML:

<reliability >

<kind >RELIABLE_RELIABILITY_QOS </kind >

<max_blocking_time >

<sec >5</sec >

</max_blocking_time >

</reliability >


XML es, ademas, el formato que adopta RTI para la configuracion de laspolıticas de QoS de su implementacion de DDS (el ejemplo anterior formaparte de esta configuracion [56]). De este modo, a pesar de tener quiza unasintaxis menos legible que los ejemplos anteriormente mencionados, con elproposito de normalizar bajo un mismo formato la configuracion generaly la de QoS, la solucion a implementar adoptara XML en su sistema deconfiguracion.

4.6. Analisis de la interfaz

Por ultimo, se realizara un analisis de la interfaz de visualizacion deinformacion de monitorizacion. El objetivo de este apartado es la evaluacionde los requisitos de esta, identificando el tipo de interfaz mas adecuado parala implementacion de la solucion.

4.6.1. Requisitos de la interfaz

En base a la definicion del problema y a la de la propia interfaz (apartado4.1.3), se pueden extraer los siguientes requisitos:

La interfaz debe ser portable, es decir, el administrador podra instalarel visualizador en cualquier maquina con independencia del sistemaoperativo que esta utilice, su entorno de escritorio (o su ausencia), etc.Ademas, la interfaz debe ser accesible desde otras maquinas de la red,permitiendo la visualizacion de informacion sin necesidad de instalarla aplicacion en todas las maquinas de esta.

La interfaz debe proporcionar un entorno de trabajo adecuado para eladministrador de sistemas. Este debe ser capaz de acceder a la infor-macion de la forma mas sencilla y rapida posible. Asimismo, deberanpresentarse graficas que representen la evolucion de los valores regis-trados a lo largo del tiempo, permitiendo al administrador analizar latendencia de estos.

Los resultados de la monitorizacion deben proporcionarse de formanormalizada para facilitar su interpretacion. Por tanto, debera permi-tirse la visualizacion de eventos de muy diverso tipo, proporcionandoseal mismo tiempo escalabilidad para la adicion de nuevos elementos demonitorizacion a lo largo del tiempo.

46 4.6. Analisis de la interfaz

4.6.2. Analisis de los requisitos de la interfaz

A partir del analisis de los requisitos definidos en el apartado anterior,se alcanzaron una serie de conclusiones que deberan llevarse a la practica enel diseno de la aplicacion.

Sin duda, el tipo de interfaz que mejor se adapta a las exigencias anterior-mente descritas es una interfaz web. El desarrollo de este tipo de interfacesofrece, en primer lugar, garantıas de portabilidad, gracias a la existencia demultitud de servidores web para diferentes sistemas operativos. Por otro la-do, la utilizacion de interfaces web posibilita la visualizacion de informaciondesde diferentes maquinas a traves del uso de navegadores, sin necesidad derealizar la instalacion ninguna biblioteca.

En relacion al entorno de trabajo que las interfaces web proporcionanal administrador, debe destacarse el hecho de que la mayorıa de herramien-tas de monitorizacion y de deteccion de intrusos analizadas en el apartado1.4 utilizan este tipo de interfaces para la visualizacion de informacion. Deesta forma, se proporcionara un entorno similar al que los administradoresutilizan en la actualidad.

Por ultimo, los lenguajes de programacion web incluyen gran cantidadde herramientas y bibliotecas tanto para el desarrollo de un sistema com-pletamente escalable, como para la utilizacion de elementos graficos en lavisualizacion de informacion. Por tanto, la implementacion de esta partira deunas condiciones muy adecuadas para el desarrollo final de la solucion.

Capıtulo 5

Diseno

Tras la fase de analisis, en la que se identifica que se quiere hacer, elsiguiente paso es especificar como se debe hacer. En este capıtulo se propor-cionaran los detalles mas relevantes del diseno de la plataforma que se deseadesarrollar.

En primer lugar se realizara una breve descripcion de la arquitectura delsistema de monitorizacion que se propone, haciendo especial enfasis en losaspectos relativos a la adquisicion de informacion de monitorizacion y a ladifusion de esta a traves del middleware. Despues, tomando como referenciaestas definiciones, se especificara el diseno de la aplicacion de monitorizacionidentificando las clases que la compondran y la interaccion entre ellas. Apartir de ahı, se describiran los sistemas de configuracion y almacenamientode la misma, dejando para el final el diseno de la interfaz de usuario. Setratan de sentar, por tanto, las bases para la implementacion de la solucional problema, que seran descritas en el Capıtulo 6.

5.1. Arquitectura del sistema de monitorizacion

Al definir el problema, se identifico como objetivo principal del proyectoel desarrollo de un sistema escalable capaz de procesar y difundir las alertasgeneradas por una serie de herramientas distribuidas en una red. Para elcumplimiento de este, en el capıtulo anterior se realizo un analisis de losdistintos elementos involucrados en el proceso de monitorizacion, definiendoun sistema capaz de extraer y difundir informacion acerca del estado actualde estas herramientas y de otros dispositivos de una red a traves de unaserie de subsistemas funcionales.

El objetivo de este apartado es la definicion de los diferentes elementos decohesion entre estos subsistemas, esto es, la arquitectura que garantizara laadquisicion de informacion de los distintos objetos de monitorizacion y su

47

48 5.1. Arquitectura del sistema de monitorizacion

almacenamiento en diferentes sistemas, y los aspectos relativos a la difusiony recepcion de informacion a traves de la red.

5.1.1. Monitorizacion a traves de un sistema de plugins

En el analisis de la arquitectura de monitorizacion realizado en el apar-tado 4.2 se definieron una serie de objetos sobre los que la aplicacion debıaexaminar periodicamente un conjunto de parametros (informacion acerca delestado de componentes hardware, aplicaciones de monitorizacion o alertasgeneradas por un IDS). Esta labor se englobo en el subsistema CCPubli-sher, encargado ademas de difundir dicha informacion a posibles suscrip-tores a traves de DDS. Por otro lado, en el otro extremo del proceso demonitorizacion, se definio un sistema de almacenamiento para el registro deinformacion recolectada de los objetos de monitorizacion a traves de unaserie de agentes localizados en CCPublisher. Las tareas de recuperacion deinformacion y gestion de su almacenamiento se asignaron entonces a unsubsistema denominado CCSubscriber.

El diseno de CCPublisher y CCSubscriber plantea una serie de proble-mas relacionados con los requisitos de escalabilidad del sistema. De estaforma, el diseno de CCPublisher debera proporcionar un metodo sencillo lainclusion de nuevos parametros de monitorizacion, incrementando la capa-cidad de la aplicacion para explorar vulnerabilidades y aspectos necesariospara el conocimiento del entorno por parte del administrador. Del mismomodo, el diseno de CCSubscriber debera permitir la suscripcion a informa-cion procedente de distintas fuentes en relacion a diferentes parametros demonitorizacion, permitiendo a su vez el registro de esta en distintos sistemasde almacenamiento.

La solucion propuesta a estos problemas viene dada por la utilizacionde una arquitectura de plugins para la recoleccion y almacenamiento de in-formacion de monitorizacion. La Figura 5.1 presenta un escenario sencillode utilizacion de Cave Canem con un unico objeto de monitorizacion. Co-mo puede observarse, cada subsistema carga un unico plugin a traves desu aplicacion principal o nucleo (core). El cometido de ambos nucleos in-cluira, ademas de las labores propias de carga y gestion de plugins, algunascuestiones relativas a la configuracion del subsistema y a la comunicacion deinformacion a traves de DDS. Los plugins, por su parte, actuaran como agen-tes de monitorizacion en el caso de CCPublisher y como gestores del sistemade almacenamiento en CCSubscriber, comportandose, a su vez, como actoresprincipales de la difusion y recepcion de informacion, respectivamente.

Para comprender el proceso de carga de plugins y la comunicacion entreestos y el nucleo del subsistema ha de partirse de la definicion del conceptode polimorfismo. En programacion orientada a objetos, polimorfismo es la

Diseno 49

Figura 5.1: Escenario sencillo de monitorizacion con Cave Canem

capacidad de una clase derivada de comportarse como un objeto de la clasebase de la que hereda. Es decir, si se define una clase plugin de la que here-dan las clases ids plugin y temperature plugin, instancias de estas clases(objetos de tipo ids plugin y temperature plugin) podran comportarsecomo objetos de la clase plugin. Esta caracterıstica permite declarar unaclase base desde el nucleo del subsistema, definiendo una serie de metodosrelativos a los procesos de monitorizacion, a partir de la cual se podran desa-rrollar distintos plugins que implementen dichos metodos de acuerdo a susnecesidades. El nucleo, gracias al polimorfismo, podra tratar de esta maneraa los distintos plugins como objetos de la misma clase, consiguiendo ejecu-tar la funcionalidad que estos ofrecen sin la necesidad de realizar ningunamodificacion a la aplicacion.

La interfaz que se ofrece a los plugins desde el nucleo depende de lanaturaleza del subsistema. En CCPublisher esta deberıa incluir un metodopara la publicacion de informacion, encargado de comprobar periodicamenteel estado actual de un parametro de monitorizacion y de publicarlo en undominio DDS. Por su lado, CCSubscriber necesitarıa la definicion de unmetodo de suscripcion que implementara tanto la recepcion de informacion,como el almacenamiento de esta de acuerdo a la tematica a la que el plugineste suscrito. Los plugins de CCSubscriber cubriran, cada uno, una unicatematica a traves de su suscripcion a topics. No obstante, podran existiral mismo tiempo plugins dedicados a la misma tematica implementandodistintos sistemas de almacenamiento.

De acuerdo a estas directrices, se definen las clases base sobre las que se


construiran los plugins de CCPublisher y CCSubscriber en las Figuras 5.2y 5.3, respectivamente.

class plugin {public:

plugin(void) {}virtual void publish information(void) {}}

Figura 5.2: Clase plugin en CCPublisher


plugin(void) {}virtual void receive information(void) {}}

Figura 5.3: Clase plugin en CCSubscriber

Como puede observarse, ambas definiciones declaran dos metodos deacuerdo a la naturaleza de las tareas realizadas por el subsistema. El meto-do plugin() representa el constructor de la clase y podra ser sobrecar-gado por las clases derivadas. Por su parte, la definicion de los metodospublish information() y receive information() como virtual implicala definicion de un metodo polimorfico, de modo que los plugins que here-den de cada clase podran realizar su propia implementacion del metodo1.

Mas adelante, en el apartado 5.2, se observara la herencia que realizanlos diferentes plugins que seran implementados como prueba de concepto delsistema.

5.1.2. Despliegue del un escenario de monitorizacion con DDS

En el apartado anterior se diseno un metodo para la adicion de funcio-nalidad a los diferentes subsistemas a traves de una arquitectura de plugins.Dentro de la labor de estos plugins se incluıa la publicacion y recepcionde informacion a traves del dominio de DDS. En este apartado se definencon mayor nivel de detalle las implicaciones del despliegue de un escena-rio de monitorizacion con DDS, ası como los elementos que deben incluirsubsistemas y plugins para afrontar la comunicacion.

1El constructor de una clase en C++ no permite su definicion como metodo virtual.

Diseno 51

Entidades de una aplicacion DDS

Una aplicacion DDS esta compuesta por un conjunto de entidades DDS,tal y como se muestra en la Figura 5.4. Estas son:

Figura 5.4: Entidades de DDS

Domain Participant En DDS, las entidades se agrupan en torno a do-minios. Cada entidad se situa y opera en un dominio a traves de losDomain Participants o participantes de dominio. Estos se encargan dedescubrir e interaccionar con otras aplicaciones remotas situadas en elmismo dominio de comunicacion. Este mecanismo permite aumentarla escalabilidad y aislar el trafico generado por las entidades DDS.

Topic Se definen como cada uno de los distintos tipos de dato que sonpublicados en DDS. Estos senalan, por tanto, la tematica de la publi-cacion/suscripcion.

Subscriber Es el punto de comunicacion entre los DataReaders y la aplica-cion. Se encarga de gestionar las suscripciones (relativas a topics sobrelos que se ha declarado un interes).

Publisher Es el encargado de publicar topics en un dominio. Estos seranrecogidos por los suscriptores situados en el mismo dominio que elDomain Participant que inicializo la entidad.

DataWriter Es el punto de acceso de una aplicacion al espacio global dedatos DDS para la publicacion de informacion procedente de un pu-blisher.


DataReader Se trata del punto de acceso de una aplicacion al espacioglobal de DDS para la recepcion de informacion recogida por un subs-criber.

Las entidades anteriormente descritas se crean mediante llamadas al APIde DDS ofrecido por el middleware. En este caso se utilizara el API propor-cionado por la implementacion de DDS que sera usada en el desarrollo delsistema: RTI Data Distribution Service. En este API, salvo algunos parame-tros de calidad de servicio, los parametros son estaticos, es decir, una vezque se crea una entidad con unos parametros, estos no pueden modificarsea no ser que esta se destruya y se cree de nuevo. La configuracion y crea-cion de entidades DDS constituye la preparacion de la infraestructura decomunicacion entre las aplicaciones que se van a utilizar.

La publicacion o suscripcion de informacion a traves del RTI Data Dis-tribution Service requiere la realizacion de una serie de pasos, tal y como seilustra en [57]:

1. Seleccionar un tipo de dato para la descripcion de la informacion quese desea manejar. Esta tarea puede realizarse de diversas formas (pu-diendo utilizarse estas en combinacion):

Utilizando un tipo de dato built-in de entre los que provee elmiddleware.

Utilizando el generador de codigo de RTI, rtiddsgen, para la defi-nicion de tipos de datos en tiempo de compilacion utilizando unadescripcion independiente del lenguaje. Esta opcion ofrece dosventajas sobre la definicion dinamica de tipos de dato: (1) permi-te compartir la definicion de estos entre aplicaciones con distintoslenguajes de programacion y (2) el hecho de conocer la estructurade este en tiempo de compilacion proporciona las condiciones deseguridad rigurosas de los tipos de datos estaticos.

El generador de codigo acepta varios formatos para la definicionde tipos de dato permitiendo la integracion en el middleware deformatos altamente extendidos como:

• OMG IDL Formato estandar de la especificacion tanto deDDS como de CORBA.

• XML schema (XSD) Ya sea de forma independiente o in-tegrado en un fichero WSDL, este deberıa ser el formato parala utilizacion del RTI DDS en la conexion con infraestructu-ras de web services.

• XML en el formato especıfico de DDS La definicion deeste formato XML es muy concisa y, por tanto, mas sencilla

Diseno 53

de especificar a mano que una definicion XSD. Proporcionacomo ventajas la escalabilidad de las definiciones en XML ysu facil integracion.

Aparte de estos formatos, tambien se podra realizar una defini-cion en el codigo del programa de los tipos de dato en tiempode ejecucion.

2. Registrar el tipo de dato con un nombre logico (excepto en la definicionde tipos de dato built-in).

3. Crear un topic usando el tipo de dato anteriormente registrado.

4. Crear uno o mas DataWriters para la publicacion de la informacion,o uno o mas DataReaders para la suscripcion a esta.

El diseno escogido para la definicion de tipos de dato en el sistema se basaen la utilizacion de ficheros IDL. Como se explicara en el capıtulo siguiente,los distintos plugins deberan utilizar las entidades generadas por rtiddsgena raız de la definicion de estos ficheros.

La utilizacion de tipos de datos comunes en distintos plugins, a traves dela definicion de topics tambien comunes, posibilita un escenario de interope-ratividad muy atractivo para la monitorizacion de informacion. Un ejemplode esto puede encontrarse en la definicion de un tipo de dato ids alert parala descripcion de alertas generadas por distintos IDS. La implementacion deplugins publicadores capaces de recolectar informacion de IDS como Snortu OSSEC, normalizando las alertas generadas por estos bajo el mismo tipode dato ids alert, permitirıa a suscriptores de topics asociados a este elprocesamiento de informacion procedente de ambos IDS indistintamente, sinla necesidad de realizar ningun cambio en la estructura del plugin suscrip-tor. Se utilizara esta caracterıstica para la elaboracion del prototipo comopodra observarse mas adelante.

Una vez se han definido los distintos aspectos involucrados en el procesocomunicativo de DDS y de la implementacion del middleware que seranutilizados, en los siguientes apartados se especificara el reparto de estoselementos en los subsistemas CCPublisher y CCSubscriber.

Arquitectura del subsistema publicador

Tal y como se describio en el apartado 5.1.1, el subsitema CCPublisheresta compuesto de un nucleo en torno al cual se organiza una infraestructurade agentes de monitorizacion implementada a traves de una serie de plugins.Se comento entonces que entre las labores del nucleo se encontraban, ademasde la carga y manejo de plugins, algunas cuestiones relativas a la comunica-cion de informacion a traves de DDS. En este apartado se delimitaran estas


cuestiones y cual sera el cometido de los diferentes plugins en relacion a lapublicacion de informacion.

Como ya se ha mencionado, el primer paso para incorporar una apli-cacion DDS a un dominio de comunicacion del middleware es la definicionde un participante de dominio o Domain Participant. En este diseno, todoslos plugins compartiran un unico participante de dominio declarado por elnucleo del subsistema. Esto implica que todos los plugins que se adhieran aeste publicaran informacion en el mismo dominio. Para cumplir estas pre-misas, el constructor de la clase del plugin debera recibir como parametroun puntero al participante de dominio declarado por el nucleo del subsiste-ma. De esta forma, se debera revisar la definicion de la clase base plugin deCCPublisher tal y como se muestra en la Figura 5.5.


plugin(DDSDomainParticipant ∗participant) {}virtual void publish information(void) {}}

Figura 5.5: Revision de la clase base plugin en CCPublisher

De acuerdo con esta definicion, a continuacion se especificara el repartode entidades DDS entre nucleo y plugins:

Nucleo

• DDSDomainParticipant El participante de dominio declarado porel nucleo de CCPublisher sera el encargado de crear los publica-dores de los distintos plugins. Tambien servira para controlar laeliminacion de todas las entidades declaradas al cerrar la aplica-cion.

Plugin

• DDSPublisher A traves del puntero a participante de dominiorecibido por el constructor de la clase que define al plugin, estedebera declarar una entidad publicadora para la transmision deinformacion.

• DDSTopic Tambien, a traves del participante de dominio, indi-cando el tipo de dato y nombre del topic, los diferentes pluginsdeberan definir la tematica de la publicacion que realizara este.

• DDSDataWriter A partir de la entidad publicadora declarada, sedebera crear un DataWriter asociado al topic anterior. Este Da-taWriter se encargara de formar las diferentes instancias de losdatos de monitorizacion que se publicaran en el dominio DDS.

Diseno 55

Arquitectura del subsistema suscriptor

La arquitectura del subsistema suscriptor sera muy similar a la descritaen el apartado anterior, por lo que se establecera de nuevo un nucleo sobre elque se adhiere funcionalidad a traves de la definicion de una serie de plugins.

1 class plugin {2 public:3 plugin(DDSDomainParticipant ∗participant) {}4 virtual void receive information(void) {}5 }

Figura 5.6: Revision de la clase base plugin en CCSubscriber

No obstante, aparte de la coincidencia en la definicion de un mismo par-ticipante de dominio para todos los plugins, con similares consecuencias queen el apartado anterior (ver la redefinicion de la clase base plugin en la Fi-gura 5.6), se establecen unas circunstancias distintas que requieren el usode otra serie de entidades. Una de las principales diferencias de enfoque queofrece la parte suscriptora de una aplicacion DDS es el uso de listeners parala recepcion de informacion, tal y como se destaco en el analisis del middle-ware (apartado 4.3.3). El uso de estos, como se comentara a continuacion,obligara a utilizar una clase mas en el diseno de los plugins.

El reparto de entidades entre nucleo y plugins sera el siguiente:

Nucleo

• DDSDomainParticipant Al igual que en el caso del subsistemapublicador, el nucleo de este declarara un unico participante dedominio que sera utilizado por todos los plugins que cargue.

Plugin

• DDSSubscriber A traves del puntero a participante de dominio,desde el constructor de la clase del plugin se debera crear unaentidad suscriptora que guıe la recepcion de informacion relacio-nada con un topic determinado.

• DDSTopic En el constructor, y tambien a partir del participantede dominio, se debera crear una entidad topic asociada a un tipode dato.

• DDSDataReaderListener Para habilitar la recepcion de informa-cion, desde el DataReader se debera definir previamente una claselistener que herede de DDSDataReaderListener. La utilizacionde esta permitira la definicion de acciones a eventos que surjan

56 5.2. Diseno de la aplicacion

en los procesos de suscripcion a informacion como la recepcionde un mensaje valido, la perdida de un dato, etc.

• DDSDataReader Por ultimo, la definicion de un DataReader apartir del suscriptor declarado, asociando este a un determina-do topic y a su listener, permitira la recepcion continuada de lainformacion de monitorizacion a la que se asocie el plugin.

5.2. Diseno de la aplicacion

En el apartado anterior se analizaron los aspectos principales del disenode la arquitectura de CCPublisher y CCSubscriber. Estos incluyen el siste-ma de plugins de ambos subsistemas y las necesidades de implementacionderivadas de la utilizacion del middleware. Una vez hecho esto, el objetivo dela presente seccion sera el diseno de un prototipo completamente funcionalde Cave Canem, que cubra las tanto las consideraciones descritas en el apar-tado anterior, como los aspectos relatados en la definicion del problema, laespecificacion de requisitos y el analisis. Esta se centrara en los procesos deextraccion, transmision y recepcion de informacion, dejando el diseno de lainterfaz, del sistema de configuracion y el sistema de almacenamiento paraapartados posteriores.

El diseno de un prototipo de Cave Canem requerira la definicion de unaserie de plugins que controlen la monitorizacion de parametros fundamenta-les del estado de las maquinas en una nuestra red, incluyendo la gestion delas alertas generadas por un IDS para la deteccion de posibles intrusionesen el entorno. En concreto, los plugins elegidos para el diseno del prototipoa implementar son los siguientes:

System monitor Tratara informacion basica acerca del estado del siste-ma sobre el que se instala CCPublisher, incluyendo datos de carga,utilizacion y temperatura de la CPU, ası como informacion acerca delestado de la memoria principal y la memoria swap.

Disk Este plugin extraera, publicara y almacenara informacion en relaciona los diferentes sistemas de ficheros utilizados por la maquina en la quese instale: tamano del sistema de ficheros, utilizacion de este, espaciolibre, etc.

Net Load Su objetivo sera procesar informacion relativa al trafico que atra-viesa cada una de las interfaces de red de los distintos hosts.

IDS (Snort) Este ultimo plugin estara dedicado a la recoleccion y difusionde alertas procedentes de un IDS. En el apartado 5.1.2 se senalo laventaja que supondrıa, en relacion a la interoperatividad, la definicion

Diseno 57

de un tipo de dato normalizado para la difusion de este tipo de alertas.Teniendo en cuenta esto, el prototipo debera implementar un pluginpublicador que recolecte informacion de un IDS, en concreto Snort, deacuerdo a unos parametros normalizados de alerta. CCSubscriber, porsu parte, implementara un plugin generico para la recoleccion y alma-cenamiento de alertas de distintos IDS, de modo que la incorporacional prototipo de plugins publicadores de alertas generadas por otros IDSpueda realizarse sin modificacion alguna del subsistema suscriptor.

5.2.1. Diagramas de clases

A continuacion se presentan los diagramas de clases correspondientes alprototipo de Cave Canem cuya implementacion se describira en el capıtulosiguiente.

CCPublisher

La Figura 5.7 presenta el diagrama de clases de CCPublisher. Este mues-tra como los diferentes plugins heredan de la clase base definida en la Figura5.5 para, a partir de esta, definir una serie de metodos para la recoleccion ypublicacion de la informacion relativa a su objetivo.

A continuacion se define cada una de las clases identificadas, ası comolos metodos que deberan incluir para la realizacion de su cometido.

Clase disk Es la clase encargada de la implementacion del pluginDisk.

• disk(DDSDomainParticipant*) Se trata del constructor de laclase. Debera definir, a partir del puntero al participante de do-minio recibido como parametro, la entidad publicadora, el topicsobre el que publicara informacion del plugin, ası como el Data-Writer a traves del que se comunicara el publicador.

• publish information() Dentro de este metodo se deberan im-plementar las labores de recoleccion de informacion relativa a losdistintos sistemas de ficheros de la maquina. Una vez recolectadasestas, se debera crear una instancia de data sample que el metodopublicara a traves del DataWriter.

Clase net load Se encarga de la implementacion del plugin Net Load.

• net load(DDSDomainParticipant*) Constructor de la clase, de-bera definir la entidad publicadora, el topic y el DataWriter a par-tir del puntero a participante de dominio recibido como parame-tro.


Figura 5.7: Diagrama de clases CCPublisher

• publish information() El metodo debera implementar la reco-leccion de informacion relativa al trafico de las distintas interfacesde red de la maquina. Tras la recoleccion de estos, se debera crearuna instancia de data sample para su publicacion en el dominiode DDS.

Clase system monitor Se encargara de la implementacion del pluginSystem Monitor.

• system monitor(DDSDomainParticipant*) Constructor de la cla-se, realizara, a partir del puntero a participante de dominio, ladefinicion de la entidad publicadora, el topic sobre el que se pu-blicara informacion, ası como el DataWriter a traves del que secomunicara el publicador.

• publish information() Se encargara de la recoleccion de in-formacion de los distintos parametros relativos al estado del sis-tema en el que se instala la aplicacion. Uno de estos aspectossera la temperatura del procesador, recolectada a traves del usodel metodo get temperpetature(), definido bajo estas lıneas.Una vez recolectada la informacion de todos los parametros re-

Diseno 59

queridos, el metodo debera realizar la publicacion de un datasample que la incluya.

• get temperature() La temperatura de un procesador suele re-gistrarse en una serie de ficheros, que en sistemas Unix se alma-cenan en los directorios /proc y /sys. De este modo, es posiblerealizar la extraccion de informacion relativa a la temperaturasimplemente a traves de la lectura de un fichero. Dadas las di-ferencias presentadas en la localizacion de esta informacion enfuncion a la maquina, se debera realizar una busqueda por am-bas carpetas, por lo que se recurrira a algunos metodos de la clasefile management que se definen a continuacion.

Clase file management Se trata de una clase dedicada al manejo deficheros, permitiendo la realizacion de tareas recurrentes en el desarro-llo de aplicaciones.

• get realpath(string) Recibiendo como parametro la localiza-cion, nombre y extension de un fichero, el metodo devolvera lalocalizacion absoluta de este.

• has extension(string,string) El metodo comprueba, dadosun fichero y una extension, si la extension del fichero se corres-ponde con la extension del parametro.

• ls r by extension(string,string) En este metodo realiza unabusqueda recursiva a partir de un directorio dado. De esta for-ma, devolvera todos los ficheros encontrados que contengan laextension dada por parametro.

• mkdir(string) Crea un directorio con la denominacion propor-cionada por parametro.

• rmmdir(string) Elimina el directorio dado por parametro.

• dir get(string) Extrae el nombre del directorio en el que sealmacena un fichero.

• ls(string) Muestra los ficheros incluidos en un directorio.

• exists(string) Comprueba si un fichero, dado por parametro,existe o no.

Clase snort Esta ultima clase es la encargada de implementar elplugin Snort definido anteriormente.

• snort(DDSDomainParticipant*) Del mismo modo que el restode constructores, este metodo afrontara la definicion de la entidadpublicadora a partir del puntero a participante de dominio dadopor parametro, ademas del topic correspondiente y el DataWriter.


• publish information() Este metodo publicara alertas que nohayan sido enviadas anteriormente, de este modo, ejecutara elmetodo update alertsmap() para obtener nuevas alertas del logde Snort, publicando aquellas que sean nuevas para el dominioDDS. La publicacion se hara de forma similar a la descrita enel resto de plugins, es decir, a traves de la instanciacion de datasamples del tipo de dato de las alertas de IDS.

• update alertsmap() Su labor sera la comprobacion de la exis-tencia o no, de nuevas alertas registradas en el log de Snort. Paraello hara uso de los metodos descritos mas adelante.

• get values() Este metodo estara dedicado a la extraccion sepa-rada de los diferentes parametros que componen una alerta dellog de Snort.

• is newer(timestamp) A traves de la extraccion del timestamp deuna alerta, se comprobara si esta es mas reciente que la ultimaalerta procesada y, por lo tanto, sera susceptible de ser enviada.

• get date from timestamp(string) Este metodo permitira la ex-traccion de los diferentes campos que componen el timestamp deuna alerta.

CCSubscriber

Una vez definidos todos los componentes del subsistema publicador, seprocedera al diseno de CCSubscriber. La Figura 5.8 presenta el diagrama declases de este, mostrando la forma en la que los diferentes plugins heredan dela clase base definida en la Figura 5.6. De esta forma, los diferentes pluginsdel prototipo declaran una serie de metodos (propios) para la suscripciony almacenamiento de la informacion relativa los distintos parametros demonitorizacion.

A continuacion se define el cometido de las clases y metodos identificadosen el diagrama.

Clase disk Se encarga de implementar el plugin Disk en CCSubscri-ber.

• disk(DDSDomainParticipant*) Se trata del constructor de laclase. Este debera definir la entidad suscriptora a partir del punte-ro a participante de dominio recibido como parametro. De acuer-do al tipo de dato que registrara la informacion relativa al sistemade ficheros publicado, filesystem, a partir del puntero a partici-pante de dominio se creara tambien el topic al que se suscribira elplugin.

Diseno 61

Figura 5.8: Diagrama de clases CCSubscriber

• receive information() El metodo de recepcion declarara unlistener para el procesamiento de la informacion publicada enreferencia al topic definido en el constructor. Este listener sera unobjeto de la clase filesystemListener, que se describira masadelante, y sera utilizado en la definicion del DataReader.

Clase filesystemListener Se trata de la clase que define el listenerasociado al tipo de dato que procesara el plugin suscriptor Disk.

• filesystemListener() Este metodo preparara el acceso al sis-tema de almacenamiento que se implemente en el plugin. Deeste modo, debera comunicarse con el sistema de configuracionpara recopilar los datos necesarios. Si, por ejemplo, el pluginrealiza almacenamiento sobre una base de datos, el construc-tor debera comprobar que las tablas donde debe escribir existen,creandolas en caso contrario.

• on data available() Este metodo se disparara en caso de queexistan datos disponibles para su procesamiento por parte delplugin. Normalmente, realizara tareas de almacenamiento de losdatos recopilados de acuerdo a la configuracion cargada en elconstructor.

Clase net load Es la clase que implementa el plugin suscriptor NetLoad.

• net load(DDSDomainParticipant*) El constructor de la claserealizara las tareas de creacion de la entidad suscriptora y la defi-


nicion del topic relativo al tipo de dato netload, que contendra lainformacion sobre la que se desea realizar suscripcion.

• receive information() El metodo definira el listener utilizadopor el DataReader de acuerdo a la clase netloadListener. Unavez declarado el DataReader, el plugin estara preparado para larecepcion de informacion cuando esta se encuentre disponible.

Clase netloadListener Define listeners asociados al tipo de datonetload, requerido por el plugin definido anteriormente.

• netloadListener() Realiza las labores de recoleccion de infor-macion de configuracion e iniciacion del sistema de almacena-miento utilizado por el plugin para el registro de los datos demonitorizacion relativos a la carga de diferentes interfaces de red.

• on data available() Disparandose en caso de recepcion de in-formacion de monitorizacion, este metodo almacenara los datosrecolectados en el sistema de almacenamiento adecuado.

Clase system monitor Debera implementar las labores suscriptorasdel plugin System Monitor.

• system monitor(DDSDomainParticipant*) El constructor de laclase debera declarar, a partir del puntero a participante de do-minio recibido como parametro, la entidad suscriptora y el topicasociado al tipo de dato sysmon status, que contiene informacionrelativa al estado general de la maquina que publico la informa-cion.

• receive information() Este metodo declarara un objeto de laclase sysmon statusListener, necesario para la creacion del Da-taReader que llevara el procedimiento de suscripcion. Una vezdeclarado este ultimo, el plugin comenzara a procesar los datosque vayan llegando.

Clase sysmon statusListener Se utiliza para la definicion de liste-ners asociados al tipo de dato sysmon status.

• sysmon statusListener() Debera preparar las condiciones ne-cesarias para el registro de la informacion recibida en el sistemade almacenamiento adecuado.

• on data available() Este metodo se disparara en caso de queexistan datos disponibles en el dominio de DDS. Debera registrarla informacion recibida en el sistema de almacenamiento indicadoen el constructor de clase.

Diseno 63

Clase ids Define el plugin de suscripcion a alertas procedentes dedistintos IDS. Tal y como se comento anteriormente, la utilizacionde un tipo de dato normalizado para la transmision de este tipo dealertas permite el procesamiento de estas sin importar su procedencia,logrando ası una implementacion propicia para la interoperatividad deaplicaciones.

• ids(DDSDomainParticipant*) El constructor de la clase realizala creacion, a partir del puntero a participante de dominio que re-cibe como parametro, de la entidad suscriptora y el topic asociadoal tipo de dato que definen las alertas de distintos IDS.

• receive information() Este metodo declara un listener de tipoids alertListener que permitira al DataReader que se declaraa raız de este la recepcion de alertas publicadas de acuerdo altipo de dato ids alert.

Clase ids alertListener Permitira la declaracion de listeners aso-ciados a alertas de IDS emitidas por distintos plugins publicadores.

• idsListener() El constructor de la clase se encargara de prepa-rar el almacenamiento de las alertas en el sistema de almacena-miento para el que se implemente el plugin.

• on data available() Cada vez que existan alertas de IDS en eldominio DDS se disparara este metodo, que debera implementarel almacenamiento de dichas alertas en el sistema que se definio enel constructor de la clase.

Una vez definidas las distintas clases y metodos que compondran el sis-tema, en el apartado siguiente se mostrara el modelo de interaccion de estos,ofreciendo ası una vision detallada del comportamiento de los objetos en unescenario real.

5.2.2. Modelo de interaccion entre objetos

En el apartado 4.1.3 se definieron, a grandes rasgos, los procesos deinteraccion que seguıan los principales subsistemas identificados en la fasede analisis. Ahora, en la fase de diseno, se realizara un refinamiento deesta definicion adaptandola a las distintas clases y metodos identificadosen el apartado anterior, cuya implementacion se describira en el siguientecapıtulo.

Dada la similitud que presentan los modelos de interaccion de los dis-tintos plugins y las clases involucradas en los procesos de monitorizacion,difusion y almacenamiento, se utilizaran unicamente dos ejemplos para la


descripcion de estos modelos en CCPublisher y CCSubscriber: Disk e IDS(Snort).

CCPublisher

A continuacion se evaluara el modelo de interaccion en la carga y utiliza-cion de los dos plugins anteriormente mencionados a traves de la elaboracionde su diagrama de secuencia UML.

La Figura 5.9 muestra el diagrama de secuencia del funcionamiento delplugin Disk. Se ha escogido este modelo dada la sencillez tanto del procesode obtencion de informacion, como de la publicacion de la misma.

Figura 5.9: Diagrama de secuencia del plugin Disk (CCPublisher)

La descripcion del modelo es la siguiente:

1. El nucleo del subsistema CCPublisher carga el plugin disk a traves deuna llamada al constructor de la clase2. Esta llamada incluira comoparametro un puntero al participante de dominio definido previamente.

2. A partir del puntero al participante de dominio, la clase disk de-clara un publicador utilizando el metodo de la API del middlewarecreate publisher().

2Realmente, como se comento en el apartado 5.1.1, el nucleo tratara al plugin comoun objeto de la clase plugin, accediendo a este a traves de la interfaz definida por estaclase base.

Diseno 65

3. Como paso previo a la creacion del topic, se registra el tipo al que seva a asociar este a traves del metodo register type().

4. Una vez registrado el tipo de dato, se crea el topic a partir del punteroa participante de dominio, realizando una asociacion de este al tipo dedato a traves de la llamada a create topic().

5. El ultimo paso que realizara el constructor sera la creacion del Da-taWriter a partir del publicador declarado anteriormente, asociandoeste al topic a traves de la funcion create datawriter().

6. De nuevo, el nucleo del subsistema se comunica con el plugin, es-ta vez requiriendo la recoleccion y publicacion del estado actual delos distintos sistemas de ficheros a traves de una llamada al metodopublish information().

7. A raız de la llamada recibida al metodo publish information(), elplugin creara un data sample para su posterior publicacion en DDS.

8. El plugin obtiene la informacion actual de los distintos sistemas deficheros y prepara estos datos para su difusion rellenando los camposdel data sample creado en el paso anterior.

9. Por ultimo, el DataWriter publica el data sample en el dominio deDDS a traves de la llamada a la funcion write().

De la misma forma, la Figura 5.10 muestra el diagrama de secuencia delfuncionamiento del plugin de Snort.

Como se puede observar, hasta la creacion del data sample que poste-riormente sera publicado a traves del middleware, el proceso es equivalenteal seguido en el plugin Disk. Esta descripcion comenzara, por tanto, despuesdel paso 7.

8. El plugin actualizara su registro de alertas a traves de la utilizacion delmetodo update alertsmap(). Este metodo, se encargara de localizaren el log de Snort las ultimas alertas registradas desde la anteriorcomprobacion.

9. Se recoge la ultima alerta registrada en el log de Snort, extrayendo losdatos de esta para rellenar el contenido del data sample declarado enel paso 7.

10. Por ultimo, el DataWriter publica dicho data sample el dominio deDDS a traves de una llamada a la funcion write(). Si el paso 8 obtienevarias alertas nuevas, no publicadas previamente en el dominio DDS,se volveran a realizar los pasos 9 y 10 para cada una de ellas.


Figura 5.10: Diagrama de secuencia del plugin Snort (CCPublisher)

CCSubscriber

En este apartado se describe el modelo de interaccion de la carga yutilizacion de plugins en CCSubscriber con otros dos ejemplos: el caso deDisk e IDS.

La Figura 5.11 muestra el diagrama de secuencia del funcionamientodel plugin Disk en CCSubscriber. A continuacion se describen los pasosidentificados en este:

1. El nucleo de CCSubscriber carga el plugin a traves de una llamadaal constructor de la clase, pasando como parametro un puntero alparticipante de dominio previamente declarado.

2. El plugin crea una entidad suscriptora a partir del puntero a partici-pante de dominio utilizando la funcion create subscriber().

3. Como paso previo a la creacion del topic, se registra el tipo al que vaa asociarse este a traves de la funcion register type().

4. Una vez registrado el tipo de dato, a partir del puntero a participantede dominio, se crea el topic asociado a dicho tipo utilizando la funcioncreate topic() que proporciona el API de DDS.

5. El nucleo de CCSubscriber inicia la recepcion de informacion del plugina traves de la llamada al metodo receive information().

Diseno 67

Figura 5.11: Diagrama de secuencia del plugin Disk (CCSubscriber)

6. Recibida la orden de iniciacion del proceso de recepcion, el plugin creael listener asociado al tipo de dato que desea recibir a traves de unallamada al constructor de la clase.

7. Una vez creado el listener, el plugin podra declarar su DataReader atraves de la asociacion de este al listener usando create datareader().

8. Senalados estos pasos, los siguientes se centraran en las labores pro-pias de la clase del listener. La primera tarea que debera realizar elconstructor de esta sera iniciar la conexion con el sistema de almace-namiento utilizado, comprobando a su vez el estado del mismo.

9. El listener queda a la espera de la aparicion de datos disponibles pu-blicados en el dominio DDS. Tan pronto como existan, el middlewaredisparara el evento on data available() indicando al listener la pre-sencia de nueva informacion.

10. Al dispararse dicho evento, el listener solicitara los nuevos datos atraves del metodo take().

11. Por ultimo, el listener registrara la informacion recibida en el sistemade almacenamiento aprovechando la conexion iniciada por el construc-tor de la clase. Una vez hecho esto, se volvera al paso 9 a la esperanuevos datos de monitorizacion que puedan publicarse en cualquiermomento en el dominio DDS. Cabe destacar que en el middleware seencarga internamente de la creacion de hebras para asegurar que elproceso de recepcion no sea bloqueante.

68 5.3. Diseno del sistema de configuracion

Como segundo ejemplo, la Figura 5.12 muestra el diagrama de secuenciadel funcionamiento del plugin de IDS.

Figura 5.12: Diagrama de secuencia del plugin IDS (CCSubscriber)

Se puede observar que la secuencia sigue exactamente los mismos pasosque en el caso del plugin Disk, por lo que no es necesaria mayor explicacionde esta. Esta conclusion es extrapolable al resto de plugins del prototipo.

5.3. Diseno del sistema de configuracion

En el apartado 4.5 se realizo el analisis de diferentes formatos de ficheropara la confeccion del sistema configuracion de la aplicacion. La conclusionde dicho analisis fue la utilizacion de XML para la configuracion tanto decaracterısticas genericas de los subsistemas CCPublisher y CCSubscriber,como de las polıticas de QoS de las diferentes entidades del middleware.Dado que la configuracion de estas ultimas debera cenirse a la definicion yla gramatica especificadas por la implementacion de DDS utilizada3, estediseno se centrara en la especificacion de las caracterısticas propias de laconfiguracion de los subsistemas, sobre las que sı sera necesaria una confec-cion de la gramatica y la definicion de los parametros que se desea controlaren la aplicacion a implementar.

3El RTI Data Distribution Service ofrece un sistema de configuracion basado en XMLpara la definicion de los distintos parametros de calidad de servicio disponibles para ca-da una de las entidades involucradas en el proceso de comunicacion. Puede consultarseinformacion acerca de estas en [57].

Diseno 69

5.3.1. El sistema de configuracion de CCPublisher

En primer lugar se especificaran los elementos que formaran parte del sis-tema de configuracion de CCPublisher. Estos, en funcion del componente delsubsistema al que afectan, pueden dividir las necesidades de configuracionen dos grupos: caracterısticas generales del sistema de publicacion, relativasfundamentalmente al nucleo del subsistema; y caracterısticas propias de losplugins publicadores.

A continuacion se evaluan los parametros relacionados con cada uno delos grupos.

Caracterısticas generales de publicacion Seran utilizadas en eldesarrollo de las funciones del nucleo del subsistema.

• <domain id> Se trata del entero que identifica el dominio en elque se realizara la publicacion de los distintos plugins que com-ponen el subsistema.

• <publishing period> Definira, en segundos, la frecuencia con laque el nucleo del subsistema debera realizar una llamada al meto-do publish information() de los distintos plugins cargados poreste.

• <qos file> Indicara la localizacion del fichero que define la cali-dad de servicio de las diferentes entidades DDS del publicador.

Caracterısticas propias de los plugins publicadores La aplica-cion debera cargar unicamente los plugins indicados en el fichero deconfiguracion utilizando los datos que aquı se definen. Podran definir-se, no obstante, parametros extra en funcion de las necesidades delplugin.

• <name> Nombre que identificara al plugin.

• <lib name> Se trata del nombre de la biblioteca dinamica que al-macena los distintos metodos del plugin, servira para que el nucleode la aplicacion pueda localizar esta y cargarla correctamente.

5.3.2. El sistema de configuracion de CCSubscriber

El caso de CCSubscriber anade un nuevo aspecto a los detalles de confi-guracion identificados anteriormente, el tratamiento del sistema de almace-namiento de la informacion de monitorizacion que reciben los suscriptores.De esta forma, se anade un nuevo grupo relacionado con estas caracterısticasa la definicion. El resultado es el siguiente:

70 5.4. Diseno del sistema de almacenamiento

Caracterısticas generales de publicacion Se elimina el campo<publishing period> ya que no es idoneo para este caso:

• <domain id> Identifica el dominio al que se suscribiran los dis-tintos plugins que componen el subsistema.

• <qos file> Indicara la localizacion del fichero que define la cali-dad de servicio de las diferentes entidades DDS del suscriptor.

Definicion de sistemas de almacenamiento Para identificar a losdistintos sistemas de almacenamiento se debera asignar una etiqueta aestos de modo que, a traves de una mencion a la etiqueta, los distintosplugins que lo utilicen puedan tener acceso a el. La definicion de unabase de datos, por ejemplo, deberıa incluir ademas de dicha etiquetalos siguientes campos:

• <host> Localizacion de la base de datos que se desea utilizar.

• <database> Nombre de la base de datos.

• <user> Nombre de un usuario con permisos de lectura y escrituraen la base de datos.

• <password> Contrasena de acceso a la misma por parte del usua-rio.

Caracterısticas propias de los plugins publicadores De la mismaforma que en CCPublisher, la aplicacion debera cargar unicamente losplugins indicados en el fichero de configuracion utilizando los datosque aquı se definen. Podran definirse, no obstante, parametros extraen funcion de las necesidades del plugin.

• <name> Nombre que identificara al plugin.

• <lib name> Se trata del nombre de la biblioteca dinamica que al-macena los distintos metodos del plugin, servira para que el nucleode la aplicacion pueda localizar esta y cargarla correctamente.

5.4. Diseno del sistema de almacenamiento

A pesar de que, como ya se ha comentado, el sistema permite la definicionde distintos sistemas para el almacenamiento de informacion por parte de losplugins suscriptores, el prototipo disenado para la validacion del proyectoregistrara todos los eventos en una unico sistema.

En el apartado 4.4 se realizo un analisis de distintos sistemas de almace-namiento, identificando como uno de los mas adecuados la implementacionde una base de datos relacional. En esta seccion se realizara un analisisde las distintas necesidades de almacenamiento de los plugins que define el

Diseno 71

prototipo y las implicaciones que estas deberan tener en la implementacionfinal del mismo. No obstante, detalles concretos como los campos definitivosde todas las tablas que definiran los distintos plugins seran descritos en elcapıtulo 6.

5.4.1. Hosts

El almacenamiento de informacion en una base de datos relacional re-quiere, en ocasiones, la definicion de nexos de union entre campos y tablascon el objetivo de facilitar la realizacion de consultas sencillas para la extrac-cion eficiente de informacion. En Cave Canem, el nexo de union fundamentales el origen de la informacion de monitorizacion, cuya identificacion permi-te observar la evolucion en el tiempo de un host determinado en funcion amultitud de parametros controlados por los distintos plugins.

El diseno del sistema de almacenamiento se basa en la asociacion de lainformacion recopilada por cada plugin con una tabla de la base de datos.Cada tabla registrara, por tanto, la evolucion de una serie de parametrosde monitorizacion controlados por un plugin a lo largo del tiempo. Con elobjetivo de mantener la cohesion entre los datos de las distintas tablas seanadira un campo extra a la declaracion de cada una, el campo hostname.De esta forma, se garantizara la posibilidad de relacionar datos relativos adistintos objetos de monitorizacion.

Ademas del campo hostname mencionado, el diseno incluye una tablaextra para el almacenamiento de informacion relativa a los propios hostsque publican informacion en el dominio DDS. Los campos de esta tabla,denominada hosts, seran:

hostname Se trata de la primary key de la tabla. De este modo, iden-tifica el nombre un host que publico, al menos una vez, informacionregistrada por el conjunto de plugins suscriptores.

sysname Almacena el nombre del sistema operativo de la maquina.

release name Hace referencia a la version del sistema operativo delhost.

machine Registra la arquitectura de la maquina.

Como consecuencia de la inclusion de esta tabla, el campo hostname

de las tablas asociadas con los distintos plugins debera ser declarado comoforeing key, relacionando este con la primary key de hosts.

72 5.4. Diseno del sistema de almacenamiento

5.4.2. System Monitor

El plugin System Monitor se encarga de registrar informacion acerca deaspectos basicos de distintas maquinas en la red como la carga de CPU,memoria RAM disponible, etc. La principal utilidad de este registro es laextraccion del valor actual de los distintos parametros, dando una idea delestado actual de cada host. No obstante, el almacenamiento de un historialde mediciones permite observar la evolucion de estos en el tiempo.

Partiendo de estas premisas, el diseno mas adecuado para el almacena-miento de este plugin sera la adopcion de una polıtica de insercion Round-Robin. Tal y como se describio en el apartado de analisis, en estos esquemasla informacion mas antigua es sustituida constantemente por los valores masrecientes, fijando ası un lımite en la informacion que la tabla puede alma-cenar. En el diseno que se propone, el lımite de informacion dependera delnumero de hosts que se registren, asignandose un numero maximo de filas enfuncion del campo hostname de la maquina publicadora. Se anadira para ellouna nueva etiqueta en la definicion del plugin, en el fichero de configuracionde CCSubscriber, que se denominara <max rows>.

Existen varias alternativas para la implementacion del esquema de re-emplazo Round-Robin, por ejemplo mediante el uso de triggers en la basede datos. No obstante, para potenciar la portabilidad de la solucion se op-tara por la implementacion de esta polıtica dentro del plugin a traves deluso de dos claves primarias: rrd sm seq id y hostname. El funcionamientode este diseno es sencillo, la primera de estas claves primarias se corres-pondera con el numero de secuencia de un host determinado, es decir, elorden de aparicion de una entrada con un determinado hostname (segundaclave primaria). De esta forma, la implementacion del plugin debera llevarla cuenta de un numero de secuencia por host, comprobando si se alcanzael lımite especificado por el campo <max rows>. En caso de alcanzarse este,el plugin debera reiniciar la secuencia a cero y proceder a la sustitucion delcontenido de la primera fila con un determinado hostname por el ultimovalor recibido, manteniendo por tanto los valores mas recientes en la basede datos.

5.4.3. Disk

Disk es el plugin encargado de registrar informacion relativa a los dis-tintos sistemas de ficheros de los hosts de la red. El almacenamiento de lainformacion relativa a estos tendra las mismas prioridades que el almacena-miento de informacion del sistema, de forma que solo interesara el registrode una serie de valores recientes para la observacion de la tendencia de estos.

No obstante, a pesar de la similitud en el almacenamiento con System

Diseno 73

Monitor, el diseno de la implementacion de Disk entrana la toma en con-sideracion de un elemento mas, la existencia de varios sistemas de ficherosdentro de cada host. Para el tratamiento de esta singularidad, se propone lautilizacion de tres claves primarias en la organizacion de la informacion den-tro de la tabla: rrd fs seq id, hostname y filesystem. Este diseno implicaque en esta ocasion, el numero de secuencia indique el numero de entradasrelativas a la informacion de un determinado sistema de ficheros correspon-diente a un host, por lo que su parametro <max rows> se correspondera conel maximo numero de entradas que puede albergar cada sistema de ficheros.A pesar de esto, la implementacion del plugin sera muy similar a la del casoanterior.

5.4.4. IDS

IDS se encarga del almacenamiento de alertas emitidas por distintossistemas de deteccion de intrusos en la red. A diferencia de los plugins an-teriormente citados, este no realizara unicamente el registro de informacionnumerica sobre la que interesara conocer principalmente el valor actual, sinotodo lo contrario. El plugin debera mantener almacenamiento de todas y ca-da una de las alertas generadas para permitir el estudio posterior de estasy la metodologıa utilizada por los intrusos.

De esta forma, la organizacion de la tabla ids sera mucho mas sen-cilla: aparte del almacenamiento de los distintos parametros del formatonormalizado de alerta de IDS, solamente debera incluirse una unica claveprimaria, denominada ids key, con un valor autoincremental. Ademas, sedeclarara hostname, campo referente al host de procedencia del IDS, comoforeing key para establecer su relacion con la tabla que almacena el conjuntode publicadores involucrados en el proceso de monitorizacion.

5.4.5. Net Load

Por ultimo, el plugin Net Load sera el encargado del registro de informa-cion relativa al uso de las diferentes interfaces de red de los hosts del entorno.El diseno de este sera equivalente al de Disk, donde se identifico la necesidadde mantener informacion de secuencia relativa a los distintos parametros delsistema de ficheros de diferentes hosts, cambiando la referencia a estos porla referencia a interfaces de red.

De este modo, su diseno contara con tres claves primarias para la orga-nizacion de la informacion en la tabla: rrd nl seq id, hostname y device.La primera indica el numero de secuencia que debera establecerse para nu-merar de la coincidencia de la segunda y la tercera. La implementacion delalmacenamiento Round-Robin sobre este diseno sera la misma que en el caso

74 5.5. Diseno de la interfaz

de Disk, indicando el valor <max rows>, en este caso, el numero maximo demuestras que se podran almacenar de una interfaz de red.

5.5. Diseno de la interfaz

En el apartado 4.6 se describieron algunos aspectos a tener en cuenta enel diseno de la interfaz de monitorizacion. Se definıa entonces la necesidad decrear una interfaz web que mostrara, de forma clara, los datos recogidos porlos distintos plugins de la aplicacion, proporcionando un entorno unico parala monitorizacion de varios sistemas y aplicaciones. Tambien se comento laposibilidad de utilizar elementos graficos para ilustrar estos datos y su evo-lucion en el tiempo. En esta seccion se tomaran en consideracion todas estasindicaciones para disenar, tanto a nivel grafico como a nivel de objetos, lainterfaz de usuario. Se partira de una serie de bocetos que mostraran los dis-tintos escenarios de la aplicacion para, una vez definidos y descritos estos,identificar las clases y metodos de la interfaz a traves de la elaboracion desu diagrama de clases. Por ultimo, se realizara un analisis del modelo deinteraccion de los distintos objetos involucrados en cada escenario.

5.5.1. Bocetos de la aplicacion web

El primer paso que se realizara en el diseno de la interfaz de usuariosera la elaboracion de una serie de bocetos para representar los diferentesescenarios que incluira la aplicacion web, de modo que partiendo de estos,puedan observarse las necesidades de esta a nivel de clases y objetos. Acontinuacion se describen estos escenarios.

Listado de hosts

Se trata de la pantalla principal de la interfaz, mostrara un listado delos hosts sobre los que se alberga informacion en los distintos campos de labase de datos, tal y como se muestra en la Figura 5.13.

En la parte superior se muestra el logotipo de Cave Canem, bajo elcual se colocara un “camino de hormigas”4 que ayudara a navegar entrelos diferentes escenarios de la interfaz. Se tratan estos de elementos que semantendran presentes en los diferentes escenarios de la misma. Debajo, sesituara una tabla con la informacion relativa a los host, basandose simple-mente en la inclusion del contenido de la tabla hosts de la base de datos

4En el diseno de interfaces de usuario se denomina “camino de hormigas”, “hilo deAriadna” o breadcrumb a elementos que simplifican la navegacion dentro de las aplica-ciones, mostrando el camino seguido hasta la pantalla actual para dar una idea de lalocalizacion de esta.

Diseno 75

descrita en el diseno del sistema de almacenamiento. Las entradas de cadafila deberan enlazarse con el escenario correspondiente al apartado siguiente,de modo que, al pulsar en la informacion relativa a un host, la interfaz webmuestre los principales datos actuales de monitorizacion de los diferentesparametros relacionados con este.

Figura 5.13: Boceto del escenario “Listado de hosts”

Estado actual de un host

Como se acaba de mencionar, al pulsar en cualquiera de los hosts pre-sentados en el escenario inicial, la aplicacion mostrara una pantalla con elestado actual del host seleccionado. El boceto de esta se ilustra en la Figura5.14.

Este escenario presenta la informacion actual de monitorizacion de lasdistintas tematicas sobre las que la base de datos mantiene informacionrelacionada con el host, en este caso laptop 1. De todos los parametros seescogera, por tanto, el valor mas reciente registrado. Bajo cada una de estastematicas se mostrara una grafica con la evolucion en el tiempo de uno de losparametros de la misma, cambiando su contenido dinamicamente al pulsarsobre ellos.

Ademas, el escenario ofrecera la oportunidad de consultar el historialcompleto de los datos correspondientes a las distintas tematicas, para ello


Figura 5.14: Boceto del escenario “Estado actual de un host”

existira un enlace activo en el encabezamiento de la tabla de cada plugin,dando paso al escenario que sera descrito a continuacion.

Listado completo de datos de monitorizacion

Al seleccionar en el escenario anterior el encabezamiento de cualquierade las tablas que muestran la informacion actual de las diferentes temati-cas de monitorizacion, inmediatamente aparecera una nueva pantalla con elhistorial completo que la base de datos mantiene acerca de los diferentesparametros de la tematica.

En la Figura 5.15 se muestra un ejemplo de este escenario para el plu-gin System Monitor. La tabla mostrada se correspondera exactamente conel contenido de la tabla del plugin en la base de datos, restringiendo losregistros de esta al host actual, laptop 1, a traves de una consulta.

Diseno 77

Figura 5.15: Boceto del escenario “Listado completo de datos de monitori-zacion”

5.5.2. Diagramas de clases

Una vez definidos los escenarios y los elementos que se desea mostraren la interfaz de monitorizacion del sistema, deben especificarse las clases ymetodos a implementar para la obtencion de esta.

La Figura 5.16 muestra el diagrama de clases de la interfaz de usuario.Este presenta, de la misma forma que en CCPublisher y CCSubscriber,una serie de plugins para el tratamiento y muestra de la informacion demonitorizacion. A continuacion se define cada una de las clases identificadas,ası como los metodos que deberan incluir para la realizacion de su cometido:

db manager Se trata de la clase que gestiona el manejo del sistemagestor de la base de datos.


Figura 5.16: Diagrama de clases de la interfaz de usuario

• connect db() Abre una conexion a la base de datos de acuerdoa los parametros con los que ha sido configurada la interfaz.

• query db(string) Realiza una consulta a la base de datos uti-lizando el contenido recibido a traves de un parametro de tipostring.

• close db() Cierra la conexion con la base de datos.

ui Esta clase se utiliza para mostrar por pantalla ciertos elementos dela pagina web.

• print header() Muestra la cabecera de la web con el logotipode Cave Canem.

• print pathway() Imprime el “camino de hormigas” relativo alescenario actual.

• print bottom() Cierra la pagina web tras la impresion de loscontenidos necesarios.

hosts Maneja y visualiza datos extraıdos de la tabla hosts de la basede datos.

• get host data(string) Muestra la informacion relativa a unhost utilizando el hostname recibido como parametro.

• print all hosts() Imprime por pantalla la informacion relativaa todos los hosts almacenados en la base de datos.

• print single host(string) Muestra por pantalla la informa-cion relativa a una maquina cuyo hostname se recibe por parame-tro.

Diseno 79

disk Se encarga de mostrar informacion en relacion a los distintossistemas de ficheros de los hosts almacenados en la base de datos.

• get last data(string) Obtiene de la base de datos el ultimovalor recolectado de los distintos sistemas de ficheros de un hostdado su hostname.

• get all data(string) Se obtienen de la base de datos todas lasentradas registradas en relacion a los distintos sistemas de ficherosde una maquina, cuyo hostname se recibe como parametro.

• print single data(string) Se imprime por pantalla la infor-macion recolectada a traves del metodo get last data().

• print all data(string) Se imprime la informacion recolectadaa raız de una llamada al metodo get all data().

• add charts data(string) Construye las graficas relativas a losdistintos parametros de disk.

net load Esta clase muestra y maneja informacion relativa a las dis-tintas interfaces de red de los hosts almacenados en la base de datos.

• get last data(string) Obtiene de la base de datos el ultimovalor recolectado de las distintas interfaces de red de un hostdado su hostname.

• get all data(string) Se obtienen de la base de datos todas lasentradas registradas en relacion a las distintas interfaces de redde una maquina, cuyo hostname se recibe como parametro.



• add charts data(string) Construye las graficas relativas a losdistintos parametros de net load.

system monitor Se encarga de manejar y mostrar informacion de losdistintos hosts almacenadas en la tabla system monitor de la base dedatos.

• get last data(string) Obtiene de la base de datos el ultimovalor recolectado de la tabla system monitor en relacion a unhost dado su hostname.

• get all data(string) Se obtienen de la base de datos todas lasentradas registradas en relacion a una maquina, cuyo hostname

se recibe como parametro.




• add charts data(string) Construye las graficas relativas a losdistintos parametros de system monitor.

ids Esta ultima clase manejara y ofrecera la posibilidad de visualizarlas diferentes alertas de IDS almacenadas en la base de datos.

• get last data(string) Obtendra las ultimas cinco alertas al-macenadas en la base de datos procedentes de una maquina, dadosu hostname.

• get all data(string) Se obtienen todas las alertas registra-das en la base de datos procedentes de una maquina, dado suhostname.



5.5.3. Modelo de interaccion de la interfaz

El ultimo paso en el diseno de la interfaz implicara la realizacion de unanalisis del modelo de interaccion de los distintos objetos pertenecientes alas clases identificadas en el apartado anterior, observandose ası su compor-tamiento en cada uno de los escenarios definidos en la seccion 5.5.1. Esteanalisis sera de gran ayuda para clarificar la implementacion de la aplicacionweb que se desea desarrollar.

Listado de hosts

En la Figura 5.17 se muestra el diagrama de secuencia del primer escena-rio: “Listado de hosts”. A continuacion se describen los pasos identificadosen el diagrama:

1. El usuario realiza una peticion web sobre el programa principal de laaplicacion web, que identificamos como index.

2. El programa principal inicia entonces el proceso de formacion de lapagina web a traves de la interaccion con distintos objetos. En primerlugar realizara una llamada a la clase ui para construir la cabecera dela pagina a traves del metodo print header().

Diseno 81

Figura 5.17: Diagrama de secuencia escenario “Listado de hosts”

3. Despues, imprime el “camino de hormigas” a traves de una llamada almetodo print pathway() de ui.

4. El siguiente paso sera mostrar la tabla con los distintos hosts almace-nados en la base de datos. Para ello, el programa principal invoca elmetodo print all hosts() de la clase hosts.

5. Para obtener la informacion requerida, hosts invoca a un metodo in-terno, denominado get host data()5, que iniciara una conexion a labase de datos a traves del metodo connect db() de la clase db manager.

6. Una vez realizada la conexion, se realiza una consulta sobre la base dedatos utilizando el metodo query db().

7. Al obtener la respuesta a la consulta, se cierra la conexion a la basede datos a traves de close db().

8. Una vez obtenida la informacion de los hosts, el programa princi-pal completa el codigo de la pagina web realizando una llamada aprint bottom().


El modelo de interaccion de este segundo escenario se muestra en laFigura 5.18. En la elaboracion del diagrama se ha omitido la conexion de lasdistintas clases con el gestor de la base de datos (db manager) para clarificarel mismo. No obstante, en la descripcion que se realizara bajo estas lıneas

5No se mostrara esta llamada para simplificar el diagrama.


se comentaran todos los pasos que deberan seguir las distintas clases parala obtencion de la informacion que se mostrara finalmente por pantalla.

Figura 5.18: Diagrama de secuencia escenario “Estado actual de un host”

1. El usuario realiza una peticion al programa principal para la visuali-zacion de la informacion mas reciente que se tiene sobre un host.

2. El programa principal comienza la formacion de la pagina web ob-teniendo las cabeceras de esta a traves de una llamada al metodoprint header() de la clase ui.

3. Despues, obtiene el “camino de hormigas” de la pagina mediante lautilizacion del metodo print pathway() de la misma clase.

4. Una vez aquı, el programa principal ira recopilando la informacionactual de las distintas tablas que mantienen informacion relativa alhost sobre el que se realiza la consulta. Primero, pedira la informaciona system monitor() a traves de su metodo print single data().

5. Al recibir esta llamada, system monitor abrira una conexion a la basede datos que guiara su metodo get last data(). El proceso de recu-peracion de informacion es equivalente al que se describio en el primerescenario.

6. Una vez hecho esto, se repetira el proceso con disk,

7. net load,

Diseno 83

8. e ids.

9. En este momento se acaba de obtener la informacion actual de lasdiferentes tematicas sobre las que mantiene informacion la base dedatos. El siguiente paso sera la preparacion las graficas con la infor-macion relativa a los distintos parametros que se muestran. Para ello,se realizara una llamada al metodo add charts data() de la clasesystem monitor,

10. disk,

11. y net load.

12. Finalmente, se cerrara la el contenido de la pagina web a traves de lallamada al metodo print bottom() de la clase ui.


El modelo de interaccion del ultimo escenario, “Listado completo dedatos de monitorizacion” se muestra en la Figura 5.19.

Figura 5.19: Diagrama de secuencia escenario “Listado completo de datosde monitorizacion”

A continuacion se realizara la descripcion del mismo.

1. El usuario solicita el historial completo almacenado en una tabla dela base de datos en relacion a un determinado host. Se tomara comoejemplo una peticion sobre los diferentes parametros de la tabla disk.

2. El programa principal pide a la clase ui la confeccion de la cabecerade la pagina web a traves del metodo print header().


3. Del mismo modo, se obtiene el “camino de hormigas” de la pagina atraves de una llamada al metodo print pathway() de la misma clase.

4. Una vez aquı, el programa principal solicita a la clase disk que muestretoda la informacion que se encuentre almacenada en la tabla asociadaa esta en relacion a un determinado host.

5. Este proceso estara guiado por el metodo get all data(), aunqueno se mostro este paso en el diagrama para simplificar el escenario.Este metodo se encargara de la comunicacion con la base de datos:iniciara una conexion a esta mediante el metodo connect db() de laclase db manager,

6. realizara la consulta apropiada a traves del metodo query db() de lamisma,

7. y cerrara la conexion utilizando el metodo close db().

8. Una vez obtenida toda la informacion requerida, el programa principalcerrara la pagina web mediante una llamada al metodo print bottom()

de la clase ui.

Capıtulo 6

Implementacion

En este capıtulo se realizara una descripcion de la implementacion delprototipo de Cave Canem definido en el capıtulo anterior. De este modo, seincluiran detalles del desarrollo de algunos de los aspectos fundamentales dela aplicacion de monitorizacion, como su sistema de plugins o sus sistemasde configuracion y almacenamiento. Ademas, se documentara el proceso deconstruccion de un plugin sencillo para esta aplicacion y se analizara laimplementacion realizada de la interfaz de usuario.

6.1. La aplicacion de monitorizacion

En el capıtulo de analisis se establecio una division logica de la aplicacionde monitorizacion en dos subsistemas funcionales: CCPublisher y CCSubs-criber. A partir de este analisis, en la fase de diseno quedaron organizadosinternamente estos subsistemas, definiendose un nucleo y un conjunto deplugins para la adicion de funcionalidad. La implementacion de un sistemaacorde con este diseno exigıa el desarrollo de una solucion flexible, dondeel establecimiento de distintos sensores de monitorizacion en una maquinano implicara necesariamente la instalacion de un sistema de suscripcion yalmacenamiento en esta.

La solucion implementada presenta un sistema completo de monitoriza-cion y deteccion de intrusos compuesto por dos aplicaciones independientes:CCPublisher y CCSubscriber. En primer lugar se describira la organizaciondel codigo y el sistema de compilacion de la solucion, y se especificara lafuncionalidad de los nucleos de las aplicaciones de publicacion/suscripcion,profundizando en algunos detalles de implementacion de plugins del prototi-po. Finalmente, se concretaran los elementos que componen tanto el sistemade configuracion, como el sistema de almacenamiento, proporcionando unavision de conjunto del sistema desarrollado.

85

86 6.1. La aplicacion de monitorizacion

6.1.1. Sistema de compilacion y organizacion del codigo

El sistema de monitorizacion de Cave Canem, compuesto por las aplica-ciones CCPublisher y CCSubscriber, ha sido desarrollado en el lenguaje deprogramacion C++, utilizando una serie de bibliotecas externas que se des-cribiran a lo largo del analisis de la implementacion. El proceso de desarrollode una aplicacion en un lenguaje de estas caracterısticas requiere la utiliza-cion de sistemas de compilacion y empaquetado de codigo para favorecer ladistribucion e instalacion sencilla y portable del programa.

La solucion escogida para el desarrollo del sistema de monitorizacionde Cave Canen fue la utilizacion del denominado GNU build system [58],tambien conocido como Autotools, un conjunto de herramientas producidaspor el proyecto GNU para la creacion de paquetes de codigo fuente portablea distintos sistemas Unix. Se trata de una solucion ampliamente adoptada enproyectos de software libre, licenciada bajo la GNU General Public License[59], pero sin restricciones para su adopcion en cualquier tipo de proyecto.

Autotools se compone de los siguientes elementos:

GNU Autoconf Procesa los ficheros configure.in y configure.ac parala generacion de un script de configuracion al que denomina configure.El objetivo de este script es examinar la existencia de bibliotecas yotras dependencias requeridas por aplicacion, preparando al programapara su compilacion e instalacion de acuerdo con las particularidadesde un sistema Unix concreto.

GNU Automake Es una herramienta utilizada por GNU Autoconf parala generacion de ficheros Makefile portables a partir de una serie deficheros (Makefile.am y Makefile.in) que contienen la informacionde compilacion necesaria para esta.

GNU Libtool Ayuda a la creacion de bibliotecas estaticas y dinamicaspara diferentes sistemas Unix, abstrayendo al programador de esteproceso y las implicaciones que tendrıa la compilacion portable de lasmismas. Se utilizara esta herramienta para la creacion de los diferentesplugins de CCPublisher y CCSubscriber.

Una vez descritas las diferentes herramientas utilizadas para la distri-bucion portable del sistema, se realizara un analisis de la organizacion delcodigo fuente de CCPublisher y CCSubscriber. A traves de este se mostraranalgunos de los aspectos mas importantes de la implementacion sobre los queprofundizaran los siguientes apartados.

Implementacion 87

CCPublisher

Los ficheros y directorios que componen la aplicacion CCPublisher sonlos siguientes:

autogen.sh Este script prepara el sistema y ejecuta las aplicacionesnecesarias para construir el arbol del proyecto con las herramientasdel GNU build system.

configure.ac Contiene las principales indicaciones de configuraciondel sistema, los ficheros fuente del mismo, las bibliotecas necesariaspara su compilacion, etc.

etc/ Esta carpeta incluye los ficheros XML de configuracion de laaplicacion.

m4/ Contiene ficheros de macro para la configuracion de las distin-tas bibliotecas utilizadas por la aplicacion, comprobando ademas lapresencia de estas en el sistema.

Makefile.am Permite la configuracion de los distintos ficheros necesa-rios para la compilacion. A partir de estas indicaciones se generara elMakefile definitivo.

src/ Contiene el codigo fuente y las bibliotecas que necesita CCPu-blisher para su instalacion.

• boost/ Esta carpeta incluye algunos ficheros de cabecera necesa-rios para la utilizacion de la biblioteca Boost C++.

• cavecanem publisher.cpp Contiene el codigo fuente correspon-diente al nucleo de la aplicacion.

• Makefile.am Anade las opciones de configuracion relativas a losficheros de esta carpeta.

• plugins/ Este directorio contiene todos los ficheros que formanlos plugins de la aplicacion.

◦ disk/ La descripcion de esta carpeta permitira observar laorganizacion de los diferentes plugins, sirviendo de descrip-cion para el resto de ellos.

� disk.cpp Contiene el codigo fuente del plugin.

� disk.idl Se trata del fichero de definicion del tipo dedato filesystem con el que trabajaran las entidades pu-blicadoras y suscriptoras.

� disk.hpp Fichero de cabecera del plugin.


� Makefile.am Incluye diferentes opciones de compilacionpara formar la biblioteca dinamica que contendra el plu-gin.

◦ net load/ Contiene los ficheros relativos al plugin Net Load.

◦ plugin.hpp Este fichero define la interfaz de programacionque los diferentes plugins necesitaran en su comunicacion conel nucleo, es decir, la clase plugin.

◦ snort/ Incluye los ficheros relativos al plugin Snort.

◦ system monitor/ Contiene los ficheros correspondientes alplugin System Monitor.

CCSubscriber

La organizacion del arbol de directorios de CCSubscriber es muy similara la de CCPublisher, a pesar de que el contenido de los ficheros que locomponen sea diferente. A continuacion se muestran los principales cambiosen la disposicion del codigo fuente de la aplicacion:

Tanto el fichero configure.ac como el directorio m4/ contendran in-formacion relativa a las bibliotecas relacionadas con CCSubscriber quedifieren de las de CCPublisher. Fundamentalmente, estas estaran rela-cionadas con la gestion del almacenamiento de informacion en la basede datos.

El directorio etc/ incluira los ficheros de configuracion XML de CC-Subscriber.

El directorio src/ contendra el fichero cavecanem subscriber.cpp,que implementa el nucleo de la aplicacion suscriptora.

La carpeta plugins/, ademas de incluir la interfaz y la implementacioncorrespondiente a los plugins suscriptores, cambiara el plugin snort/

por ids/, sustituyendo la implementacion publicadora especıfica porel plugin suscriptor generico.

6.1.2. Nucleo de los subsistemas

En el apartado 5.1.1 se definio la necesidad de utilizar una arquitecturade plugins en los distintos subsistemas, que dotara de funcionalidad a estosde forma escalable, organizada en torno al nucleo del mismo. De esta forma,se identificaron como tareas del nucleo el tratamiento de informacion rela-cionada con la configuracion del subsistema, algunos aspectos del manejo delmiddleware y la carga y manejo de los distintos plugins. En este apartado se

Implementacion 89

describira la implementacion seguida en CCPublisher y CCSubscriber parala concrecion de estas labores, haciendo un especial enfasis en la carga ygestion de los distintos plugins.

Como fue comentado en el apartado anterior, la funcionalidad de losnucleos de CCPublisher y CCSubscriber se implementa en dos ficheros fuen-te, denominados cavecanem publisher.cpp y cavecanem subscriber.cpp.La estructura de estos es muy similar, dado que en esencia realizan las mis-mas funciones. Para la realizacion de las labores anteriormente enumeradas,en el nucleo de estas aplicaciones se utilizan las siguientes bibliotecas exter-nas:

Boost Extension Esta biblioteca facilita el desarrollo de plugins y ele-mentos similares de extension de funcionalidad en aplicaciones [60].De este modo, permite la carga de clases y funciones en una aplica-cion, a traves del uso de bibliotecas dinamicas. Boost Extension seencuentra en desarrollo y preparacion para su inclusion en el conjuntode bibliotecas Boost C++.

Boost Property Tree Es una biblioteca para el acceso y gestion de in-formacion procedente de ficheros estructurados en diversos formatos[61], incluyendo entre otros, los comentados en el apartado 4.5. De es-ta forma, la biblioteca permite el acceso al arbol XML del sistema deconfiguracion de Cave Canem, extrayendo la informacion almacenadaen este.

A continuacion se describe paso a paso la funcionalidad implementadaen los nucleos de CCPublisher y CCSubscriber.

Puesta en marcha del demonio de monitorizacion

CCPublisher y CCSubscriber se implementan como demonios de publica-cion y suscripcion de informacion, respectivamente, permitiendo la ejecucionde ambas tareas en segundo plano.

La conversion de una aplicacion en un demonio en sistemas Unix es sen-cilla. Para ello, el programa principal debera realizar una llamada a fork(),obteniendo un pid de proceso nuevo, que adoptara en la ejecucion perdien-do la dependencia con el proceso padre que ejecuto la aplicacion en primerainstancia. Una vez hecho esto, se debera cambiar el directorio de trabajo ala raız del sistema (/), permitiendo el acceso a todos los sistemas de ficherosde la maquina; y la umask1 a 0, para facilitar la creacion de mascaras en

1umask es una funcion y comando en sistemas POSIX que define la mascara de creacionde ficheros en un proceso.


el manejo de ficheros sin depender de la configuracion fijada por el procesopadre. Por ultimo, se deberan desactivar las salidas estandar stdin, stdout ystderr, que seran sustituidas por la utilizacion del log del sistema.

Carga de la configuracion de la aplicacion

Una vez establecida la aplicacion como demonio de publicacion o sus-cripcion, el siguiente paso a realizar sera la carga de la configuracion delsistema. Esta tarea se realizara a traves de la utilizacion de la bibliotecaBoost Property Tree, como se indico anteriormente.

El nucleo de CCPublisher extraera, de esta forma, informacion acercadel dominio DDS para la publicacion de informacion, la frecuencia de ex-traccion y publicacion de esta, ası como el fichero donde se encuentran laspolıticas de calidad de servicio utilizadas por la aplicacion publicadora. Porsu lado, CCSubscriber obtendra tambien el dominio DDS sobre el que rea-lizara suscripcion, ademas de los datos de acceso a la base de datos.

Por ultimo, ambos nucleos registraran la informacion relativa a los plu-gins que deberan cargar en su ejecucion. Esta incluye el nombre de cada uno,ası como la denominacion de la biblioteca dinamica, como se concretara enel apartado de analisis de la implementacion del sistema de configuracion.

Preparacion del acceso al middleware

De acuerdo con el diseno realizado en el apartado 5.1.2, el nucleo delsubsistema sera el encargado de la creacion del participante de dominio.Entre las tareas encomendadas a este, ademas del paso de un puntero aparticipante de dominio a los distintos plugins, se incluyo la necesidad deeliminar las entidades creadas al cerrar la aplicacion.

La creacion de un demonio requiere el control de las distintas senalesprocedentes del sistema operativo que el proceso que este constituye pue-da recibir. Por tanto, para asegurar la liberacion correcta de recursos, enla implementacion se asocian las senales SIGHUP, SIGTERM, SIGQUIT a unmetodo, denominado exit program(), que al dispararse se encargara de laeliminacion de todas las entidades contenidas en el participante de dominioy del propio Domain Participant.

Localizacion de las bibliotecas dinamicas a ejecutar

Una vez configurada la aplicacion y definidos los aspectos mas impor-tantes de la ejecucion de la misma, se debera proceder a la carga de losplugins que dotaran de funcionalidad a la aplicacion. El primer paso para

Implementacion 91

realizar esta tarea sera la localizacion de las diferentes bibliotecas dinamicasque contienen a estos.

La instalacion de la aplicacion, a traves de las herramientas proporcio-nadas por Autotools, requiere la ejecucion de tres comandos:

$ ./ configure

$ make

# make install

El primero de estos, configure, permite establecer una serie de opcionesde configuracion entre las cuales se incluye la especificacion de los directoriosde instalacion de la aplicacion. La generacion de los Makefile a partir de laejecucion de este script permite, a traves de una serie de especificaciones enlos ficheros Makefile.am (Figura 6.1), recoger en tiempo de compilacion losdirectorios de instalacion en distintas constantes2.

49 cavecanem_publisher_CPPFLAGS = $(INCLUDES) $(CFLAGS) $(NDDS_INCLUDES)

-DSYSCONFDIR =\"$(sysconfdir)/cavecanem /\" -DLIBDIR =\"$(libdir)/\"

Figura 6.1: Extracto de cavecanem publisher/src/Makefile.am

Aprovechando las circunstancias descritas, CCPublisher y CCSubscriberutilizan la constante LIBDIR para obtener la localizacion en la que se instalanlas bibliotecas de la aplicacion y ası obtener la ruta completa de los pluginsa cargar en el siguiente paso.

Carga y manejo de plugins

Con la localizacion de las distintas bibliotecas dinamicas que contienenlos plugins almacenada en una variable, es el momento de utilizar la biblio-teca Boost Extension para la carga y ejecucion de estos.

El primer paso en la adicion de funcionalidad a la aplicacion sera la rea-lizacion de una llamada al metodo load single library(), proporcionadopor la biblioteca, para cada uno de los plugins. A traves de este, se indexanlas diferentes bibliotecas que los contienen en un contenedor generico de tipotype map (ver Figura 6.2). Este tipo de contenedores permiten el indexadode elementos a partir de su tipo, almacenando ası un plugin por clase.

La instanciacion de plugins en el subsistema se basa en la adopciondel patron de diseno Factory [62]. Este define un modelo centralizado para

2En este caso se recoge la localizacion del las bibliotecas en LIBDIR y de los ficheros deconfiguracion en la constante SYSCONFDIR. Esta ultima permite, como se comentara pos-teriormente, la localizacion de los ficheros que componen el sistema de configuracion deambas aplicaciones.


157 type map types;158 for(lst it = lst.begin(); lst it != lst.end(); ++lst it) {159 if(!load single library(types,∗lst it))160 syslog(LOG ERR, "Error loading plugin");161 }

Figura 6.2: Carga de plugins a traves de load single library()

la creacion de objetos a partir una serie de clases factorıa, recibiendo losparametros correspondientes al constructor de la clase que abstrae y devol-viendo instancias de esta.

Siguiendo este modelo, una vez cargadas las bibliotecas dinamicas enel type map, se realiza la definicion de las distintas factorıas de las clasesque este contiene y que permiten la instanciacion de los plugins requeridospor la aplicacion. Estas factorıas se almacenan en un contenedor map3 parafacilitar su manejo a traves de su indexacion por nombre de plugin, Figura6.3.

166 map<string, factory<plugin, DDSDomainParticipant ∗> >& factories(types.get());

167 if (factories.empty()) {168 syslog(LOG ERR, "No plugins found!");169 }

Figura 6.3: Definicion del map de factorıas

La Figura 6.4 muestra la instanciacion de los diferentes plugins en elcaso de CCSubscriber. Esta se realiza a traves de la iteracion sobre el mapde factorıas declarado anteriormente, definiendo un shared pointer que per-mite el manejo del plugin instanciado y al que se pasa, como parametro, lafactorıa con el puntero al participante de dominio del nucleo, necesario parasu creacion. Ademas, en la misma iteracion del bucle, se realiza una llama-da al metodo receive information() del plugin para iniciar su recepcionasıncrona de informacion.

En CCPublisher la publicacion de informacion se desarrolla bajo circuns-tancias diferentes. Estas se traducen en la necesidad de realizar una llamadaperiodica al metodo publish information() de cada plugin, existiendo untiempo de espera entre ellas definido en la configuracion de la aplicacion.

3Contenedor proporcionado por la biblioteca estandar de C++ que almacena cualquiertipo de dato en funcion de un ındice, de la misma forma que se almacenan las definicionesen un diccionario asociandose estas a palabras.

Implementacion 93

172 for (map<string, factory<plugin, DDSDomainParticipant ∗> >::iterator it =factories.begin(); it != factories.end(); ++it) {

173 boost::shared ptr<plugin> current sensor(it−>second.create(participant));

174 current sensor−>receive information();175 }

Figura 6.4: Instanciacion de plugins en CCSubscriber

La solucion implementada se muestra en la Figura 6.5 y se basa en elalmacenamiento de los plugins instanciados en otro contenedor map, sobre elque se iterara para la publicacion sucesiva de la informacion de monitoriza-cion recolectada por los plugins. Al terminar estas iteraciones, se esperara untiempo, especificado en la variable publishing period, y se volvera a iniciarel proceso de publicacion.

172 map<string,boost::shared ptr<plugin> > map plugins;173 for(map<string, factory<plugin, DDSDomainParticipant ∗> >::iterator it =

factories.begin(); it != factories.end(); ++it) {174 map plugins[it−>first].reset(it−>second.create(participant));175 }176

177 while(true) {178 for(map<string,boost::shared ptr<plugin> >::iterator it = map plugins.

begin(); it != map plugins.end() ;++it)179 map plugins[it−>first]−>publish information();180

181 NDDSUtility::sleep(publishing period);182 }

Figura 6.5: Instanciacion de plugins en CCPublisher

6.1.3. Plugins implementados

En el apartado 5.2 se definieron una serie de plugins para su implemen-tacion en el prototipo de Cave Canem descrito en este capıtulo. En estaseccion se realizara un repaso de algunos detalles de la implementacion deestos, describiendo la informacion que manejan y los procedimientos seguidospara su extraccion. Los detalles mas concretos de implementacion se revi-saran a traves del desarrollo de un plugin sencillo en la seccion 6.2, mientrasque el modelo almacenamiento de informacion sera descrito en el apartado6.1.5.


System Monitor

System Monitor proporciona, publica y almacena informacion generaldel estado del sistema en el que se instala CCPublisher. Al igual que en elcaso de otros plugins implementados, la informacion de Sytem Monitor seextrae a traves de la utilizacion de LibGTop [30]. Esta biblioteca forma partedel entorno de escritorio GNOME, aunque su interfaz de programacion esindependiente de este, y proporciona acceso a informacion del sistema comola carga de CPU, el estado de la memoria, el listado de los diferentes sistemasde ficheros o interfaces de red, el desempeno de los procesos en ejecucion,etc.

A continuacion se describen los distintos parametros manejados por elplugin. Estos se incluyen en el fichero system monitor.idl, utilizado parala generacion de los tipos de dato a transmitir tanto en la parte publicadoracomo en la suscriptora.

cpu temp Indica la temperatura en grados centıgrados del procesadorde la maquina. En caso de existir mas de un procesador en esta, serealiza unicamente la publicacion de informacion acerca de uno deellos.

load average Representa la carga media del sistema en un periodo detiempo. Se trata de una estructura compuesta por los parametros:

• load one Carga media en el ultimo minuto.

• load five Carga media en los ultimos cinco minutos.

• load fifteen Carga media en los ultimos quince minutos.

cpu user Porcentaje de utilizacion de CPU por procesos de usuario.

cpu system Porcentaje de utilizacion de CPU por parte del kernel ysus procesos.

cpu idle Porcentaje de CPU no utilizado.

mem total Tamano total de la memoria principal de la maquina (enbytes).

mem used Tamano de la memoria principal utilizado en el momento dela toma de informacion (en bytes).

mem free Espacio libre en la memoria principal (en bytes).

swap total Tamano total de la memoria swap definida en el sistema(en bytes).

Implementacion 95

swap used Tamano de la memoria swap utilizado (en bytes).

swap free Espacio libre en la memoria swap definida en el sistema (enbytes).

Disk

Disk proporciona, publica y almacena informacion relativa a los distintossistemas de ficheros de la maquina en la que se ejecuta CCPublisher. Al igualque en el caso de System Monitor, esta se extrae a traves de la utilizacionde LibGTop.

A continuacion se describen los distintos parametros que definen la in-formacion relativa a los distintos sistemas de ficheros de una maquina deacuerdo con la definicion realizada en el fichero disk.idl.

name Nombre del sistema de ficheros (/dev/sdx).

mountdir Directorio de montaje del sistema de ficheros.

total Espacio total del sistema de ficheros (en kbytes).

used Espacio utilizado del sistema de ficheros (en kbytes).

free Espacio libre en el sistema de ficheros (en kbytes).

used per Porcentaje de utilizacion del sistema de ficheros.

free per Porcentaje de espacio libre en el sistema de ficheros.

write Numero total de bloques escritos.

read Numero total de bloques leıdos.

En caso de existir varios sistemas de ficheros en una misma maqui-na, Disk publicara un topic para cada uno de ellos dentro del metodopublish information(). De este modo, su implementacion difiere ligera-mente de la de System Monitor, que realiza unicamente la publicacion deun topic por cada llamada al metodo.

Snort e IDS

El plugin Snort extrae y publica alertas procedentes de los ficheros de logdel IDS Snort de acuerdo a un formato de alerta normalizado para este tipode aplicaciones. Este es interpretado por el plugin suscriptor IDS (encargadodel almacenamiento de los datos).


La utilizacion de Snort permite identificar ataques en la red a traves deun sistema de reglas actualizable. Esta aplicacion cuenta con una gran va-riedad de metodos para registrar la informacion y alertas generadas a travesde los denominados output plugins. Entre estos se encuentra la posibilidadde generar ficheros XML o CSV, la utilizacion del syslog, el almacenamientoen varios sistemas gestores de bases de datos o la utilizacion de un ficherobinario sencillo, a traves del unified output plugin.

Uno de los problemas fundamentales de Snort a la hora de registrar lasalertas generadas viene dado por la implementacion de la aplicacion en basea una unica hebra de ejecucion [47]. Este hecho implica que el programa nopermita realizar al mismo tiempo analisis de trafico y registro de eventos,por lo que la utilizacion, por ejemplo, de un metodo de almacenamientolento como una base de datos para registrar estos podrıa causar, en redes dealto trafico, la perdida (por falta de analisis) de informacion crıtica duranteel acceso y escritura de la informacion a almacenar.

De este modo, y buscando un compromiso entre la rapidez de registrode Snort y la sencillez en el tratamiento de la informacion, se ha escogido lautilizacion del output plugin CSV. Especificando su utilizacion en el fichero/etc/snort/snort.conf, las alertas de Snort se registraran en el archivodefinido en el sistema de configuracion de CCPublisher.

Snort registra en el fichero CSV una alerta por lınea, separando los cam-pos de esta por comas. Cada alerta se compone de 27 campos, de los que seextrae la siguiente informacion, formando la alerta normalizada de IDSque interpretara el plugin suscriptor.

source Se trata de una estructura que contiene informacion acerca dela fuente de la alerta que se dispara.

• prt Puerto fuente de la alerta disparada.

• network addr Direccion de red fuente de la alerta disparada.

• hwaddr Direccion fısica fuente de la alerta disparada.

target Se trata de una estructura que contiene informacion acerca delobjetivo de la alerta que se dispara.

• prt Puerto objetivo de la alerta que se dispara.

• network addr Direccion de red objetivo de la alerta que se dis-para.

• hwaddr Direccion fısica objetivo de la alerta que se dispara.

ts Timestamp del momento de disparo de la alerta.

msg Mensaje descriptivo de la alerta que se dispara.

Implementacion 97

Net Load

Net Load proporciona, publica y almacena informacion relativa a lasdistintas interfaces de red de la maquina en la que se ejecuta CCSubscriber.El enfoque de este plugin es similar al de System Monitor y Disk, utilizandoLibGTop para la extraccion de la informacion relativa a este.

A continuacion se describen los distintos parametros incluidos en el fi-chero net load.idl, a partir de los cuales se generaran los tipos de datomanejados por el plugin publicador y el suscriptor.

device Nombre de dispositivo de la interfaz de red.

mtu Indica la unidad maxima de transferencia de la interfaz de red.

subnet addr Muestra la mascara de red.

net addr Contiene la direccion IP asignada a la interfaz de red.

hwaddress Es la “direccion fısica” para la identificacion del dispositivode red.

packets in Numero de paquetes recibidos por la interfaz.

packets out Numero de paquetes enviados por la interfaz.

bytes in Numero de bytes recibidos por la interfaz.

bytes out Numero de bytes enviados por la interfaz.

bytes total Suma de los dos parametros anteriores.

errors in Numero de errores en la recepcion de datos.

errors out Numero de errores en el envıo de datos.

errors total Numero total de errores en la recepcion y el envıo dedatos.

collisions Numero de colisiones registradas por la interfaz de red.


Del mismo modo que en Disk, Net Load publica en cada llamada apublish information() un topic por cada interfaz de red del sistema.

6.1.4. Sistema de configuracion

Otro de los aspectos fundamentales de la aplicacion de monitorizaciones su sistema de configuracion para el establecimiento de los parametrosprincipales en los procesos de recoleccion, transmision y almacenamiento dela informacion. De este modo, a partir del diseno descrito en el apartado5.3, en esta seccion se mostrara la definicion de los ficheros XML para laconfiguracion de CCPublisher y CCSubscriber, ası como las bases en las quese sustenta la configuracion de QoS en el proceso de transmision.

Configuracion en CCPublisher

La Figura 6.6 muestra la implementacion definitiva del fichero de confi-guracion de CCPublisher. Este fichero se instalara en el sistema del usuarioen funcion al parametro --sysconfdir, que se anade a la hora de ejecu-tar el script configure. De esta forma, si se especifica en la ejecucion deeste el deseo de instalar los ficheros de configuracion en el directorio /etc,--sysconfdir=/etc, CCPublisher creara una carpeta dentro del mismo pa-ra la inclusion tanto el generico cavecanem publisher.xml descrito en lafigura, como los ficheros con las polıticas de QoS.

Configuracion en CCSubscriber

En la Figura 6.7 se muestra el fichero de configuracion XML de CCSubs-criber. La instalacion de este se realiza de forma similar a la de CCPublisher,especificando el parametro idoneo a la hora de ejecutar el script de configu-racion de la compilacion. En este caso, el fichero configuracion de la figurase denominara cavecanem publisher.xml.

Configuracion de la QoS

Como puede observarse en las Figuras 6.6 y 6.7, los ficheros de configura-cion de CCPublisher y CCSubscriber especifican el nombre de un fichero deconfiguracion para la QoS para cada aplicacion. El RTI Data DistributionService proporciona, como ya se ha mencionado en apartados anteriores, unmecanismo para la configuracion de polıticas de QoS a traves de ficherosXML, por lo que no requiere la recompilacion de las distintas aplicacionespara la modificacion de estas. En dichos ficheros se pueden especificar distin-tos perfiles para la agrupacion de polıticas, permitiendo incluso la herencia

Implementacion 99

1 <general>2 <domain id>0</domain id>3 <publishing period>6</publishing period>4 <qos file>cavecanem publisher qos.xml</qos file>5 </general>6

7

8 <plugins>9 <snort plugin>

10 <name>snort</name>11 <lib name>libcavecanem publisher snort.so</lib name>12 <log file>/var/log/snort/alert.csv</log file>13 </snort plugin>14 <system monitor plugin>15 <name>system monitor</name>16 <lib name>libcavecanem publisher system monitor.so</

lib name>17 </system monitor plugin>18 <disk plugin>19 <name>disk</name>20 <lib name>libcavecanem publisher disk.so</lib name>21 </disk plugin>22 <net load plugin>23 <name>net load</name>24 <lib name>libcavecanem publisher net load.so</lib name>25 </net load plugin>26 </plugins>

Figura 6.6: Fichero de configuracion de CCPublisher

de caracterısticas entre estos [57].

Los ficheros de configuracion de QoS de CCPublisher y CCSubscriberse basan en esta funcionalidad para realizar la configuracion de calidad deservicio de los plugins. De esta forma, se establece un perfil de polıticas deservicio para cada plugin en funcion de las necesidades que este requiere.En concreto, en el desarrollo del prototipo se ha trabajado en base a dosperfiles indicados en [57]:

High Throughput Se trata del perfil de QoS definido, en principio, paralos plugins System Monitor, Disk y Net Load. Este esta disenado parasistemas que producen una gran cantidad de pequenos mensajes deforma continuada. En estos casos, es mas eficiente manejar los samplesde forma conjunta en un mismo paquete, lo que permite al middlewareminimizar la sobrecarga que implica la construccion de un datagramay su transmision.


1 <general>2 <domain id>0</domain id>3 <qos file>cavecanem subscriber qos.xml</qos file>4 </general>5

6 <database>7 <server>localhost</server>8 <name>cavecanem</name>9 <user>cavecanem</user>

10 <password>cavecanem</password>11 </database>12

13 <plugins>14 <ids plugin>15 <name>ids</name>16 <lib name>libcavecanem subscriber ids.so</lib name>17 </ids plugin>18 <system monitor plugin>19 <name>system monitor</name>20 <lib name>libcavecanem subscriber system monitor.so</

lib name>21 <max rows>10</max rows>22 </system monitor plugin>23 <disk plugin>24 <name>disk</name>25 <lib name>libcavecanem subscriber disk.so</lib name>26 <max rows>10</max rows>27 </disk plugin>28 <net load plugin>29 <name>net load</name>30 <lib name>libcavecanem subscriber net load.so</libname>31 <max rows>100</max rows>32 </net load plugin>33 </plugins>

Figura 6.7: Fichero de configuracion de CCSubscriber

Reliable Es el perfil definido para los plugins Snort e IDS. Los paquetesenviados por el middleware pueden perderse en su transporte por lared, su procesamiento en routers y switches o, incluso, en el sistemaoperativo de las aplicaciones suscriptoras al llenarse los buffers. Parapaliar esta situacion, las polıticas que define el perfil permiten conocersi los datos enviados son recibidos por la aplicacion suscriptora reen-viando estos en caso de perdidas en la transmision. Este perfil se ajustaa los plugins relacionados con la transmision de alertas generadas pordistintos IDS debido a la importancia de la evaluacion posterior de la

Implementacion 101

informacion que recoge cada una de estas.

6.1.5. Sistema de almacenamiento

El ultimo punto en la descripcion de la implementacion realizada de laaplicacion de monitorizacion es el analisis del sistema de almacenamientode esta. En el apartado 5.4 se describio la organizacion en tablas de la basede datos para el almacenamiento de la informacion del prototipo. En esteapartado se concretaran los distintos campos que manejara esta.

El sistema de almacenamiento del prototipo de Cave Canem se basa enla utilizacion de una base de datos MySQL para el registro continuo de lainformacion recolectada por los distintos plugins suscriptores de CCSubscri-ber. A continuacion, en los cuadros 6.1, 6.2, 6.3, 6.4 y 6.5 se muestra cadauna de las tablas que la componen.

Campo Tipo Clave

hostname varchar(30) Primariasysname varchar(30) –release name varchar(30) –machine varchar(30) –

Cuadro 6.1: Descripcion de la tabla hosts

Campo Tipo Clave

ids key int(10) unsigned Primariahostname varchar(30) Primaria y Foraneaids ts timestamp –msg varchar(100) Primariasource network addr varchar(30) –source port int(10) unsigned –source mac varchar(30) –target network addr varchar(30) –target port int(10) unsigned –target mac varchar(30) –

Cuadro 6.2: Descripcion de la tabla ids


Campo Tipo Clave

rrd sm seq id int(10) unsigned Primariahostname varchar(30) Primaria y Foraneats timestamp –cpu temp double –load one double –load five double –load fifteen double –cpu user double –cpu system double –cpu idle double –mem total double –mem used double –mem free double –swap total double –swap used double –swap free double –

Cuadro 6.3: Descripcion de la tabla system monitor

Campo Tipo Clave

rrd nl seq id int(10) unsigned Primariahostname varchar(30) Primaria y Foraneats timestamp –device varchar(20) Primariamtu int(10) unsigned –net addr varchar(30) –subnet addr varchar(30) –hwaddress varchar(30) –packets in int(10) unsigned –packets out int(10) unsigned –bytes in int(10) unsigned –bytes out int(10) unsigned –errors in int(10) unsigned –errors out int(10) unsigned –errors total int(10) unsigned –collisions int(10) unsigned –

Cuadro 6.4: Descripcion de la tabla net load

Implementacion 103

Campo Tipo Clave

rrd fs seq id int(10) unsigned Primariahostname varchar(30) Primaria y Foraneats timestamp –filesystem varchar(30) Primariamountpoint varchar(30) –b total int(10) unsigned –b used int(10) unsigned –b free int(10) unsigned –used per double –free per double –blocks read int(10) unsigned –blocks written int(10) unsigned –

Cuadro 6.5: Descripcion de la tabla disk

6.2. Desarrollo de un plugin sencillo en Cave Ca-nem

Para ilustrar con mayor nivel de detalle el desarrollo de plugins a travesdel framework que ofrece Cave Canem, tanto para CCPublisher como paraCCSubscriber, el capıtulo incluye un ejemplo sencillo. El objetivo de estees clarificar los pasos a seguir por los desarrolladores interesados en anadirfuncionalidad al sistema, mostrando cuales son los elementos necesarios paraello y las entidades involucradas en los procesos de publicacion/suscripcion.

El plugin desarrollado a continuacion se denomina Hello World y se in-cluye en la distribucion de codigo de Cave Canem. La funcionalidad de estees simplemente la publicacion de una cadena con el texto “hello world” des-de CCPublisher y la suscripcion a informacion de este tipo por parte deCCSubscriber.

Se comenzara definiendo el IDL de la estructura de datos que mane-jaran publicaciones y suscriptores, para seguir con la definicion los pluginscorrespondientes a cada aplicacion.

6.2.1. Definicion del IDL

El primer paso para la construccion del plugin sera el diseno del ficheroIDL que define la estructura de datos que manejaran los publicadores ysuscriptores. Este debera incluir unicamente, por tanto, la cadena de textoque contendra el mensaje “hello world”. Se muestra esta definicion en laFigura 6.8.

104 6.2. Desarrollo de un plugin sencillo en Cave Canem

1 struct helloworld message {2 string message;3 };

Figura 6.8: hello world dds.idl

Una vez definido este, se deberan generar las estructuras necesarias en elmanejo de la informacion tanto en el lado publicador, como en el suscriptor.Para realizar este proceso se utiliza la herramienta rtiddsgen, que proporcio-na el RTI Data Distribution Service. En este caso, los parametros utilizadosen esta seran los siguientes, generando los ficheros que se listan:

$ rtiddsgen -ppDisable -language C++ hello_world.idl

$ ls

helloworld_dds.cxx helloworld_ddsPlugin.cxx helloworld_ddsSupport.cxx

helloworld_dds.h helloworld_ddsPlugin.h helloworld_ddsSupport.h

A partir de la ejecucion de este comando en los directorios de implemen-tacion de ambos plugins comienza el desarrollo de estos.

6.2.2. Plugin para CCPublisher

El primer paso en la creacion del plugin publicador sera la especificacionde la clase que hereda de la interfaz base plugin. En esta definicion seincluye la declaracion de las diferentes entidades que se utilizaran en losmetodos de la clase posteriormente, haciendo uso de los ficheros generadospor rtiddsgen. La Figura 6.9 muestra esta definicion.

El segundo y ultimo paso consistira en, a partir de esta definicion, im-plementar cada uno de los metodos definidos en la clase:

El constructor de la clase iniciara las diferentes entidades involucra-das en el tratamiento de la informacion, estas son, tal y como se de-finen en la parte privada de la clase: publisher , topic , writer ,helloworld message writer y la instancia de los datos a transmitir:intance handle .

Por su parte, publish information() utilizara el DataWriter defini-do para la estructura, helloworld message writer , para escribir lainformacion en el dominio de DDS a traves de una llamada al metodowrite() de la clase.

Implementacion 105

16 #include <ndds/ndds cpp.h>17 #include "helloworld_dds.h"

18 #include "helloworld_ddsSupport.h"

19

20 class helloworld : public plugin {21 public:22 helloworld(DDSDomainParticipant ∗participant);23 void publish information(void);24 private:25 std::string get value(void);26 DDSDomainParticipant ∗participant ;27 DDSPublisher ∗publisher ;28 DDSTopic ∗topic ;29 DDSDataWriter ∗writer ;30 helloworld messageDataWriter ∗ helloworld message writer ;31 helloworld message ∗instance ;32 DDS ReturnCode t retcode ;33 DDS InstanceHandle t instance handle ;34 const char ∗type name ;35 };

Figura 6.9: Implementacion del Plugin publicador de Hello World: ficherode cabecera

6.2.3. Plugin para CCSubscriber

El proceso de desarrollo del plugin suscriptor es similar al del caso ante-rior. No obstante, existe una particularidad fundamental en el desarrollo deeste, la que supone, como ya se ha mencionado en otros apartados, la utiliza-cion de listeners para la recepcion de informacion. La Figura 6.10 presentala implementacion del fichero de cabecera que define tanto la clase listener,como la clase que desarrolla la interfaz definida por plugin.

La implementacion de los metodos que definen estas clases se basara enlos siguientes pasos:

El constructor de la clase helloworld iniciara algunas de las entidadesinvolucradas en el tratamiento de la informacion. Estas son, tal y comose define en la parte privada de la clase, subscriber y topic .

El resto de entidades se definen en el metodo receive information(),que tendra como cometido la instanciacion de un objeto de la clasehelloworld messageListener, definiendo a partir de el el DataReaderasociado a este: reader .

En relacion a la definicion del listener se implementara simplemente

106 6.2. Desarrollo de un plugin sencillo en Cave Canem

13 #include <ndds/ndds cpp.h>14 #include "helloworld_dds.h"

15 #include "helloworld_ddsSupport.h"

16

17

18 class helloworld messageListener : public DDSDataReaderListener {19 public:20 helloworld messageListener(void);21 virtual void on data available(DDSDataReader∗ reader);22 private:23 helloworld messageDataReader ∗helloworld message reader ;24 helloworld messageSeq data seq;25 DDS SampleInfoSeq info seq ;26 DDS ReturnCode t retcode ;27 };28

29

30 class helloworld : public plugin {31 public:32 helloworld(DDSDomainParticipant ∗participant);33 virtual void receive information(void);34 private:35 DDSDomainParticipant ∗participant ;36 DDSSubscriber ∗subscriber ;37 DDSTopic ∗topic ;38 helloworld messageListener ∗reader listener ;39 DDSDataReader ∗reader ;40 DDS ReturnCode t retcode ;41 const char ∗type name ;42 int count ;43 int status ;44 int sample count ;45 };

Figura 6.10: Implementacion del Plugin suscriptor de Hello World: ficherode cabecera

el metodo on data available(), que este disparara con la existenciade topics de tipo “Hello World” en el dominio DDS. De este modo, elplugin debera iniciar el DataReader recibido como parametro y obtenerla informacion existente a traves de la llamada al metodo take() delmismo. La informacion recolectada se imprimira en el log del sistema,al contrario que en el resto de plugins del prototipo, que utilizan unatabla asignada en la base de datos MySQL.

Implementacion 107

6.3. La interfaz de usuario

El ultimo elemento a analizar en la descripcion de la implementacion delprototipo de Cave Canem sera la interfaz de usuario. De este modo, la pre-sente seccion muestra el desarrollo de esta a traves del analisis de los ficherosfuente que la componen y los escenarios resultantes de la especificacion delapartado 5.5.

6.3.1. Organizacion de ficheros de la interfaz de usuario

La interfaz de usuario ha sido desarrollada en los lenguajes de progra-macion PHP y JavaScript utilizando la base de datos MySQL definida enel apartado 6.1.5 para obtener los datos de monitorizacion requeridos. Enconsecuencia, la utilizacion de esta necesitara la configuracion de un servidorweb y la instalacion de la maquina virtual de PHP.

A continuacion se describen los distintos ficheros que componen la apli-cacion web:

css/ Este directorio incluye las hojas de estilo CSS utilizadas por laaplicacion web.

db/ Contiene ficheros relacionados con el tratamiento de la base dedatos donde se almacena la informacion de monitorizacion.

• config.php En este fichero se configuran los datos de acceso a labase de datos (nombre, servidor, usuario y contrasena).

• db manager.php Incluye la clase db manager para el acceso a labase de datos.

images/ Este directorio contiene las imagenes que se muestran en lainterfaz.

index.php Se trata del programa principal de la aplicacion, este ficherose ejecutara cada vez que se reciba una peticion web en la interfaz deCave Canem.

js/ Contiene los ficheros JavaScript para la confeccion de las graficasque muestran la tendencia en el tiempo de los datos de monitorizacion.

plugins/ Este directorio incluye los distintos ficheros con los pluginspara la obtencion y muestra de la informacion almacenada en la basede datos.

• disk.php Contiene la clase disk para el manejo de los datosalmacenados en dicha tabla.

108 6.3. La interfaz de usuario

Figura 6.11: Implementacion del escenario “Listado de hosts”

• hosts.php Implementa la clase hosts para el manejo de los datosalmacenados en su tabla.

• ids.php Incluye la clase ids para el manejo de los datos alma-cenados en dicha tabla.

• net load.php Contiene la clase net load.php para el manejo delos datos almacenados en su tabla.

• system monitor.php Contiene la clase system monitor para elmanejo de los datos almacenados en dicha tabla.

ui/ Incluye el fichero ui.php que contiene diferentes metodos paradibujar la cabecera y otra serie de elementos de la aplicacion web.

6.3.2. Resultados de la implementacion de los distintos es-cenarios

En el apartado 5.5 se elaboraron una serie de bocetos para el diseno dela interfaz de usuario, presentando un conjunto de escenarios en representa-cion de las diferentes funcionalidades ofrecidas por la aplicacion web. Esteapartado mostrara el resultado del desarrollo de estos, permitiendo observarel grado de similitud entre diseno e implementacion.

Listado de hosts

El primer escenario de la aplicacion web, Figura 6.11, proporciona unalista con los distintos hosts sobre los que la base de datos mantiene infor-

Implementacion 109

Figura 6.12: Implementacion del escenario “Estado actual de un host”

macion. La Figura muestra un ejemplo de monitorizacion sobre el que sebasara la explicacion del resto de la seccion. En dicho ejemplo, la aplicacionsuscriptora ha recibido datos relativos a tres hosts: vm-1, vm-2 y aspire, demodo que en la figura se muestra informacion generica relativa a estos comosu nombre de host, su sistema operativo o su arquitectura.

La aplicacion web aisla la informacion de monitorizacion en funcion alhost de procedencia de esta. Por tanto, la navegacion realizada a travesde la interfaz debera partir de la seleccion de uno de los hosts de la lista.Para permitir esto, cada fila mantiene un enlace hacia el siguiente escenario:“Estado actual de un host”.


Este segundo escenario proporciona, dado un host, los ultimos datos re-colectados por CCSubscriber correspondientes al mismo. En la Figura 6.12se incluye parte del estado actual de uno de los hosts mostrados en el primerescenario: aspire. En concreto, pueden observarse distintos datos relaciona-

110 6.3. La interfaz de usuario

dos con su CPU, incluyendo una grafica con la evolucion de la carga en losultimos cinco minutos (load five) en distintas muestras.

Cada uno de los apartados de monitorizacion sobre los que se muestrael ultimo dato recolectado por CCSubscriber proporciona un enlace con elobjetivo de presentar al usuario toda la informacion almacenada en la basede datos en relacion a este. Dicho enlace conduce a la definicion del tercery ultimo escenario: “Listado completo de datos de monitorizacion”.


Este ultimo escenario incluye toda la informacion relativa un aspecto dela monitorizacion almacenada en la base de datos en relacion a un host. Enconcreto, la Figura 6.13 muestra como ejemplo la informacion registrada enrelacion a la CPU de aspire.

Figura 6.13: Implementacion del escenario “Listado completo de datos demonitorizacion”

Como ha quedado comprobado con este repaso a la implementacion dela interfaz, el resultado final de esta cumple los diferentes aspectos senala-dos en el diseno, proporcionando un entorno sencillo para el analisis de lainformacion publicada acerca de los diferentes objetos de monitorizacion.

Capıtulo 7

Pruebas

A lo largo del siguiente capıtulo se mostraran y comentaran los resultadosobtenidos a partir de las pruebas realizadas sobre el sistema implementado.Estas pruebas tienen una doble finalidad:

Poner de manifiesto posibles errores o incongruencias de la aplicacioncon el objetivo de corregirlas antes de la puesta en marcha del sistema.

Demostrar que la aplicacion cumple con los requerimientos detalladosen la especificacion de requisitos y el analisis.

7.1. Pruebas de unidad

Las pruebas de unidad tienen como objetivo la comprobacion del fun-cionamiento correcto de los modulos de codigo del sistema, asegurando quecada uno de estos funciona correctamente por separado. Para realizar es-tas comprobaciones se disenaron una serie de casos de prueba, que fueronverificados posteriormente.

7.1.1. Diseno de los casos de prueba

En esta seccion se describe el diseno de una serie de pruebas para los prin-cipales casos de uso identificados en el apartado 4.1.1. El objetivo de estases la verificacion del resultado de la interaccion entre actores y aplicacion.Los resultados de la ejecucion de las mismas se mostraran en el siguienteapartado.

111

112 7.1. Pruebas de unidad

Caso de prueba: difundir datos de monitorizacion

Este caso de prueba permite comprobar el funcionamiento correcto delos casos de uso CU1, CU4 y CU5.

Entrada CCPublisher se configura para la extraccion de informacion demonitorizacion y la publicacion de esta a traves de la edicion de losdistintos ficheros de configuracion. Una vez finalizado el procedimientose inicia el demonio publicador.

Salida Utilizando la herramienta que provee el RTI Data Distribution Ser-vice, rtiddsspy, se observan los topics publicados en el dominio de DDSindicado en la configuracion. Al parar el demonio publicador, se obser-vara del mismo modo la liberacion correcta de los recursos utilizados.

Condiciones La configuracion proporcionada a CCPublisher debe ser co-rrecta.

Caso de prueba: recibir datos de monitorizacion

Este caso de prueba permite comprobar el funcionamiento correcto delos casos de uso CU2, CU4 y CU6.

Entrada CCSubscriber se configura para la suscripcion a informacion demonitorizacion en relacion a una serie de tematicas. Una vez realizadoeste proceso, se iniciara la publicacion con CCPublisher en el dominode escucha la aplicacion suscriptora.

Salida La realizacion de consultas sobre la base de datos debe demostrarla recepcion correcta de los datos de monitorizacion publicados, deacuerdo a las caracterısticas de QoS con las que fue configurada latransmision. Se comprobara tambien la liberacion correcta de recursos.

Condiciones La configuracion proporcionada a CCSubscriber en los fiche-ros XML debe ser correcta. Es necesaria tambien la existencia previade la base de datos donde se almacena la informacion recibida.

Caso de prueba: visualizar datos de monitorizacion

Este caso de prueba permite comprobar el funcionamiento correcto delcaso de uso CU3.

Entrada Tras la ejecucion del caso de prueba descrito en el apartado ante-rior, se ejecuta la interfaz de usuario para la visualizacion de los datosde publicacion almacenados en la base de datos.

Pruebas 113

Salida La interfaz de usuario debera mostrar la informacion procedente dela base de datos y las graficas de la evolucion en el tiempo de algunosparametros numericos.

Condiciones La aplicacion web debe estar configurada de forma correctapara acceder a la base de datos y el caso de prueba “recibir datos demonitorizacion” debe haberse realizado de forma satisfactoria.

7.1.2. Resultados de la ejecucion de los casos de prueba

A partir del diseno de los casos de prueba descritos en el apartado ante-rior se realizaron una serie de evaluaciones que arrojaron los resultados quese detallan a continuacion.

Difusion de los datos de monitorizacion

Se configuro la ejecucion del demonio suscriptor para la publicacion delos datos que proveen los plugins System Monitor, Disk, Net Load y Snortcon las polıticas de QoS definidas en el apartado 6.1.4.

Al comenzar la ejecucion de este, rtiddsspy empezo a mostrar los topicscorrespondientes a los datos de monitorizacion previstos con la periodicidadmarcada en el fichero de configuracion de CCPublisher. Al finalizar la eje-cucion, se comprobo igualmente la liberacion de los recursos reservados y laeliminacion de las distintas entidades DDS, quedando probada de este modola validez de la implementacion realizada para este caso de prueba.

Recepcion de los datos de monitorizacion

En la evaluacion del sistema para este caso de prueba se configuro eldemonio suscriptor para la recepcion de informacion de monitorizacion atraves de los plugins System Monitor, Disk, Net Load e IDS con las polıticasde QoS anteriormente mencionadas.

De este modo, a partir de la iniciacion del demonio publicador con laconfiguracion del caso de prueba anterior, la base de datos comenzo a regis-trar la informacion de monitorizacion publicada por este. Para completar laprueba, se anadieron varios demonios publicadores mas, utilizando la mis-ma configuracion y siendo ejecutados en maquinas conectadas a la mismasubred que el demonio suscriptor. El resultado de esta adicion fue el registrode los nuevos eventos publicados a la base de datos. Al igual que en el casoanterior, al parar los demonios involucrados en este, se realizo una libera-cion correcta de recursos y la eliminacion de entidades DDS, comprobandose

114 7.2. Pruebas de integracion

ası el correcto funcionamiento de la implementacion realizada para este casode prueba.

Visualizacion de los datos de monitorizacion

La evaluacion de este ultimo caso de prueba partio del uso de los datosrecolectados en la ejecucion descrita en el apartado anterior. Ası, se con-figuro la interfaz de usuario para el acceso a la base de datos asociada aCCSubscriber y se procedio a la visualizacion de esta a traves de distin-tos navegadores web. Los resultados mostrados confirmaron la validez de laimplementacion realizada para este caso de prueba.

7.2. Pruebas de integracion

Las pruebas de integracion se realizan una vez constatada la validez delos distintos componentes del sistema a traves de las pruebas unitarias. Elobjetivo de estas es comprobar el funcionamiento correcto de la aplicacional poner en conjunto todos los modulos evaluados.

En este caso, la realizacion de las pruebas de integracion se baso en laejecucion de todas las funcionalidades del sistema en varias maquinas. Lospasos seguidos para esta ejecucion fueron los siguientes:

Se inicio el demonio publicador CCPublisher en el host aspire aso-ciando su ejecucion al dominio 3 a traves de la edicion del fichero deconfiguracion. Se activaron, unicamente, los plugins Snort y SystemMonitor.

Se ejecuto el programa de supervision rtiddsspy para controlar lostopics publicados en todos los dominios.

Se inicio el demonio de suscripcion CCSubscriber en aspire, asociandosu escucha al dominio 3 con los plugins IDS y Net Load activos.

Se comprobo mediante la interfaz de usuario la informacion recolectadapor CCSubscriber.

Se realizo un escaneado con nmap sobre aspire para provocar la gene-racion de alertas por parte de Snort en este.

Se comprobo en la interfaz de usuario la recepcion de las alertas gene-radas.

Se inicio el demonio publicador en el host vm-1, asociando la publi-cacion de este en al dominio 4. Se activaron los plugins Net Load ySystem Monitor.

Pruebas 115

Se reinicio el demonio suscriptor en aspire y se asocio este al dominio4. Se configuro la utilizacion de todos los plugins disponibles.

Se comprobo la recepcion de la informacion en la interfaz de usuario,ası como la generacion correcta de las distintas graficas con la evolucionen el tiempo de los parametros recolectados.

Se inicio un demonio publicador en el host vm-2 asociado al dominio4, con los plugins System Monitor, Disk y Net Load activos.

Se comprobo la recepcion de la informacion publicada por vm-2 en lainterfaz de usuario.

Se paro la ejecucion de todos los demonios publicadores y suscriptores,comprobandose la liberacion correcta de los recursos y la eliminacionde entidades DDS.

La ejecucion de estos pasos resulto satisfactoria, obteniendose en cadacambio realizado en los sistemas de publicacion y suscripcion los resulta-dos de monitorizacion esperados. Este hecho permite constatar el correctofuncionamiento del sistema bajo las premisas sobre las que fue disenado.

Capıtulo 8

Conclusiones y trabajofuturo

8.1. Principales contribuciones

Los resultados del desarrollo de este proyecto seran presentados, bajoel tıtulo “An extensible DDS-based monitoring and intrusion detection sys-tem”, en el Workshop on Real-time, Embedded and Enterprise-Scale Time-Critical Systems que se celebrara en Washington (DC, USA) en marzo de2011. Este encuentro, organizado por la OMG, constituye un foro para inge-nieros de software e investigadores en el campo de los sistemas distribuidosy de tiempo real.

El trabajo actual ha conseguido cumplir los objetivos propuestos con lassiguientes conclusiones:

Se ha implementado un sistema extensible, basado en una arquitectu-ra de plugins, que realiza la recoleccion, difusion y almacenamiento dedatos de monitorizacion en relacion a diferentes tematicas. Su disenoes fruto del estudio de diversas alternativas y proporciona una solucionenfocada en la satisfaccion de las necesidades del proyecto, maximizan-do la flexibilidad del mismo a la hora de integrar herramientas.

Como prueba de concepto se han desarrollado diferentes plugins quemuestran la potencia y escalabilidad de Cave Canem. En este sentido,se puede destacar lo siguiente:

• Se ha integrado el IDS Snort en el sistema, proporcionando unmetodo para la difusion de las alertas generadas por este, deacuerdo a un mensaje normalizado que permite combinar su uti-lizacion con otros IDS.

117

118 8.2. Trabajo futuro

• Se han desarrollado dos complementos para la monitorizacion desistemas, cubriendo el analisis de la carga del procesador, ası comoel uso de la memoria y de los sistemas de ficheros.

• Se ha implementado un plugin para la monitorizacion del trafi-co de las distintas interfaces de red de un host, proporcionandoinformacion acerca de los paquetes enviados y recibidos, errores,colisiones, etc.

Se ha realizado la seleccion y el analisis de las funcionalidades de DDSque pueden utilizarse estrategicamente para mejorar la flexibilidad,rendimiento y fiabilidad del sistema.

Se ha establecido un sistema de configuracion en la plataforma quepermite la modificacion de parametros relativos a la extraccion deinformacion y a la difusion de la misma, de acuerdo a una serie depolıticas de QoS.

El sistema dispone de una interfaz web para el analisis de la informa-cion de monitorizacion recolectada, permitiendo observar graficamentela evolucion de los parametros correspondientes a la misma en el tiem-po.

Las aplicaciones que componen Cave Canem han sido probadas satis-factoriamente en sistemas GNU/Linux de arquitecturas x86 y x86 64,gracias al sistema portable de compilacion que implementan.

8.2. Trabajo futuro

A continuacion se presentan una serie de mejoras que se pretenden, y enlas que se esta trabajando, para la extension de la funcionalidad del sistemadesarrollado.

Posibilitar la integracion de plugins que publiquen y se suscriban ainformacion en diferentes dominios de DDS desde la misma aplica-cion. Esta mejora esta siendo implementada actualmente y requiere elestablecimiento de un participante de dominio para cada plugin.

Se esta trabajando en la integracion de los Content Filtered Topics deDDS en el sistema. La utilizacion de estos permite una suscripcion mu-cho mas eficiente a la informacion, de modo que los suscriptores recibanunicamente la informacion coincidente con una serie de parametros de-clarados en la definicion del topic. Por ejemplo, se podrıa optar porrealizar una suscripcion a topics procedentes unicamente de una seriede hosts, a alertas de IDS descritas con un mensaje determinado o ainformaciones del sistema en circunstancias de alta carga de CPU.

Conclusiones y trabajo futuro 119

Integracion de un mayor numero de aplicaciones conocidas de moni-torizacion y deteccion de intrusos en Cave Canem. Especialmente, seesta realizando el estudio de otros IDS para comprobar la validez dela interoperabilidad que ofrece la interfaz normalizada implementada,en la difusion de las alertas generadas por este tipo de sistemas.

Aislar al desarrollador de plugins de la configuracion de las distintasentidades DDS, separando completamente la implementacion del mo-delo de gestion de la informacion, de la del modelo de transmision dela misma.

Ademas, se esta preparando el sistema para su despliegue en la platafor-ma PASITO [63]. Este laboratorio de pruebas distribuido, construido sobrela red academica espanola RedIRIS, permite probar gran variedad de servi-cios de telecomunicaciones, por lo que servira de base para la validacion delproyecto en el desarrollo de futuras investigaciones.

Bibliografıa

[1] Object Management Group. Data Distribution Service forReal-time Systems specification, version 1.2, 2007. Disponi-ble en: http://www.omg.org/technology/documents/formal/data_

distribution.htm [Ultima consulta 1 diciembre 2010].

[2] Object Management Group (OMG). The Object Management Group(OMG), 2008. Disponible en: http://www.omg.org/ [Ultima consulta1 diciembre 2010].

[3] Real-Time Innovations Inc. RTI Data Distribution Service. Disponi-ble en: http://www.rti.com/products/data_distribution/index.

html [Ultima consulta 1 diciembre 2010].

[4] Real-Time Innovations Inc. Disponible en: http://www.rti.com [Ulti-ma consulta 1 diciembre 2010].

[5] PrismTech Ltd. OpenSplice DDS. Disponible en: http://www.

prismtech.com/opensplice-dds [Ultima consulta 1 diciembre 2010].

[6] PrismTech Ltd. PrismTech Ltd. Disponible en: http://www.

prismtech.com [Ultima consulta 1 diciembre 2010].

[7] Inc. Object Computing. OpenDDS. Disponible en: http://www.

opendds.org [Ultima consulta 1 diciembre 2010].

[8] Object Computing Inc. Object Computing Inc. Disponible en: http://www.ociweb.com [Ultima consulta 1 diciembre 2010].

[9] Object Management Group (OMG). DDS Vendors Page. Disponi-ble en: http://portals.omg.org/dds/VendorsPage [Ultima consulta1 diciembre 2010].

[10] IEEE. IEEE Std 1003.1-2001 Standard for Information Technology —Portable Operating System Interface (POSIX) System Interfaces, Issue6. 2001. Revision of IEEE Std 1003.1-1996 and IEEE Std 1003.2-1992)Open Group Technical Standard Base Specifications, Issue 6.

121

http://www.omg.org/technology/documents/formal/data_distribution.htm

http://www.omg.org/technology/documents/formal/data_distribution.htm

http://www.omg.org/

http://www.rti.com/products/data_distribution/index.html

http://www.rti.com/products/data_distribution/index.html

http://www.rti.com

http://www.prismtech.com/opensplice-dds

http://www.prismtech.com/opensplice-dds

http://www.prismtech.com

http://www.prismtech.com

http://www.opendds.org

http://www.opendds.org

http://www.ociweb.com

http://www.ociweb.com

http://portals.omg.org/dds/VendorsPage

122 BIBLIOGRAFIA

[11] Sun Microsystems. RPC: Remote Procedure Call Protocol specification:Version 2. RFC 1057 (Informational), 1988. Disponible en: http://www.ietf.org/rfc/rfc1057.txt [Ultima consulta 1 diciembre 2010].

[12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC2616 (Draft Standard), 1999. Updated by RFCs 2817, 5785. Dispo-nible en: http://www.ietf.org/rfc/rfc2616.txt [Ultima consulta 1diciembre 2010].

[13] Nilo Mitra. SOAP Version 1.2 Part 0: Primer. W3C working draft,World Wide Web Consortium (W3C), 2001. Disponible en: http://www.w3.org/TR/soap12-part0/ [Ultima consulta 1 diciembre 2010].

[14] W3C. Web Services Architecture, W3C Working Group Note, 2004.Disponible en: http://www.w3.org/TR/wsdl [Ultima consulta 1 di-ciembre 2010].

[15] Erik Christensen et al. Web Services Description Language (WSDL)1.1, W3C Note, 2001. Disponible en: http://www.w3.org/TR/wsdl

[Ultima consulta 1 diciembre 2010].

[16] Sun Developer Network. RMI Remote Method Invocation. Dispo-nible en: http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp [Ultima consulta 1 diciembre 2010].

[17] Object Management Group. Common Object Request Broker Archi-tecture (CORBA/IIOP), version 3.0.3, 2004. Disponible en: http:

//www.omg.org/docs/formal/04-03-12.pdf [Ultima consulta 1 di-ciembre 2010].

[18] Object Management Group. OMG IDL Syntax and Semantics - Com-mon Object Request Broker Architecture (CORBA), v3.0. Techni-cal report, 2002. Disponible en: http://www.omg.org/cgi-bin/doc?formal/02-06-39 [Ultima consulta 1 diciembre 2010].

[19] Bert Farabaugh, Gerardo Pardo-Casellote, and Rick Warren. Intro-duction to DDS and Data Centric Communications, 2005. Disponibleen: http://www.omg.org/news/whitepapers/#DDS [Ultima consulta 1diciembre 2010].

[20] Gerardo Pardo-Castellote and Joe Schlesselman. System Monitoringand Network Intrusion Detection Using DDS and CEP. In Works-hop on Distributed Object Computing for Real-time and EmbeddedSystems, 2008. Disponible en: http://www.omg.org/news/meetings/realtime2008/Program.htm [Ultima consulta 1 diciembre 2010].

http://www.ietf.org/rfc/rfc1057.txt



http://www.w3.org/TR/soap12-part0/

http://www.w3.org/TR/soap12-part0/

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp

http://www.omg.org/docs/formal/04-03-12.pdf

http://www.omg.org/docs/formal/04-03-12.pdf

http://www.omg.org/cgi-bin/doc?formal/02-06-39

http://www.omg.org/cgi-bin/doc?formal/02-06-39

http://www.omg.org/news/whitepapers/#DDS

http://www.omg.org/news/meetings/realtime2008/Program.htm

http://www.omg.org/news/meetings/realtime2008/Program.htm

BIBLIOGRAFIA 123

[21] Snort. The Open Source Network Intrusion Detection System. Dispo-nible en: http://www.snort.org [Ultima consulta 1 diciembre 2010].

[22] Trend Micro. Open Source Host-based Intrusion Detection System.Disponible en: http://www.ossec.net/ [Ultima consulta 1 diciembre2010].

[23] Tenable Network Security. The Network Vulnerability Scanner. Dispo-nible en: http://www.nessus.org/ [Ultima consulta 1 diciembre 2010].

[24] Gordon Fyodor Lyon. Nmap Network Scanning: The Official NmapProject Guide to Network Discovery and Security Scanning. Insecure,USA, 2009.

[25] Saint Corporation. Integrated Vulnerability Assessment and Pene-tration Testing. Disponible en: http://www.saintcorporation.com/[Ultima consulta 1 diciembre 2010].

[26] Ulf Lamping, Richard Sharpe, and Ed Warnicke. Wireshark User’sGuide, 2010. Disponible en: http://www.wireshark.org/docs/wsug_html_chunked/ [Ultima consulta 1 diciembre 2010].

[27] Mike Kershaw. Kismet Readme. Disponible en: http://www.

kismetwireless.net/ [Ultima consulta 1 diciembre 2010].

[28] Michal Zalewski. The new p0f. Disponible en: http://lcamtuf.

coredump.cx/p0f.shtml [Ultima consulta 1 diciembre 2010].

[29] Matthew L. Massie, Brent N. Chun, and David E. Culler. The gangliadistributed monitoring system: design, implementation, and experience.Parallel Computing, 30(7):817 – 840, 2004.

[30] Martin Baulig and German Poo-Caama no. Libgtop Reference Manual,2010. Disponible en: http://library.gnome.org/devel/libgtop/

stable/ [Ultima consulta 1 diciembre 2010].

[31] Nagios. Nagios - The Industry Standard In Open Source Monitoring,2010. Disponible en: http://www.nagios [Ultima consulta 1 diciembre2010].

[32] AlienVault. AlienVault Open Source SIEM. Disponible en: http://www.alienvault.com/ [Ultima consulta 1 diciembre 2010].

[33] A.P. Millar, G.A. Stewart, and G.A. Cowan. Monitoring with monami:a case study. Journal of Physics: Conference Series, 119(6):062037,2008.

http://www.snort.org

http://www.ossec.net/

http://www.nessus.org/

http://www.saintcorporation.com/

http://www.wireshark.org/docs/wsug_html_chunked/

http://www.wireshark.org/docs/wsug_html_chunked/

http://www.kismetwireless.net/

http://www.kismetwireless.net/

http://lcamtuf.coredump.cx/p0f.shtml

http://lcamtuf.coredump.cx/p0f.shtml

http://library.gnome.org/devel/libgtop/stable/

http://library.gnome.org/devel/libgtop/stable/

http://www.nagios

http://www.alienvault.com/

http://www.alienvault.com/

124 BIBLIOGRAFIA

[34] Sancho Lerena-Urrea et al. Pandora FMS 3.0 Administrator guide,2009. Disponible en: http://www.openideas.info/wiki [Ultima con-sulta 1 diciembre 2010].

[35] The GNOME Project. Planner. Disponible en: http://live.gnome.org/Planner [Ultima consulta 1 diciembre 2010].

[36] Object Management Group. OMG Unified Modeling Language (OMGUML), Superstructure, V2.1.2, 2007. Disponible en: http://www.omg.org/spec/UML/2.1.2 [Ultima consulta 1 diciembre 2010].

[37] Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley, 2001.

[38] Dan North. What’s in a Story?, 2006. Disponible en: http://

blog.dannorth.net/whats-in-a-story/ [Ultima consulta 1 diciem-bre 2010].

[39] Elizabeth Woodward, Steffan Surdek, and Matthew Ganis. A PracticalGuide to Distributed Scrum. IBM Press, 2010.

[40] R. Gerhards. The Syslog Protocol. RFC 5424 (Proposed Standard),2009. Disponible en: http://www.ietf.org/rfc/rfc5424.txt [Ultimaconsulta 1 diciembre 2010].

[41] Tim Bray, Jean Paoli, C. Michael Sperberg-McQueen, Eve Maler, andFrancois Yergeau. Extensible Markup Language (XML) 1.0 (FifthEdition). World Wide Web Consortium, Recommendation REC-xml-20081126, 2008.

[42] XML (Extensible Markup Language). Wikimedia Foundation,Inc., 2008. Disponible en: http://en.wikipedia.org/wiki/XML#

Critique_of_XML [Ultima consulta 1 diciembre 2010].

[43] Y. Shafranovich. Common Format and MIME Type for Comma-Separated Values (CSV) Files. RFC 4180 (Informational), 2005. Dispo-nible en: http://www.ietf.org/rfc/rfc4180.txt [Ultima consulta 1diciembre 2010].

[44] Paul Klink. Fielded Text Standard Reference. Disponible en: http://www.fieldedtext.org/Standard/FTRef0.6.pdf [Ultima consulta 1diciembre 2010].

[45] Dominic J. Repici. The Comma Separated Value (CSV) File For-mat. Disponible en: http://www.creativyst.com/Doc/Articles/

CSV/CSV01.htm [Ultima consulta 1 diciembre 2010].

[46] Kasper B. Graversen. The CSV format specification. Disponible en:http://supercsv.sourceforge.net/csvSpecification.html [Ulti-ma consulta 1 diciembre 2010].

http://www.openideas.info/wiki

http://live.gnome.org/Planner

http://live.gnome.org/Planner

http://www.omg.org/spec/UML/2.1.2

http://www.omg.org/spec/UML/2.1.2

http://blog.dannorth.net/whats-in-a-story/

http://blog.dannorth.net/whats-in-a-story/


http://en.wikipedia.org/wiki/XML#Critique_of_XML

http://en.wikipedia.org/wiki/XML#Critique_of_XML


http://www.fieldedtext.org/Standard/FTRef0.6.pdf

http://www.fieldedtext.org/Standard/FTRef0.6.pdf

http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm

http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm

http://supercsv.sourceforge.net/csvSpecification.html

BIBLIOGRAFIA 125

[47] Andrew R. Baker and Joel Esler. Snort Intrusion Detection and Pre-vention Toolkit. Syngress Publishing, 2007.

[48] Tobias Oetiker. About RRDtool. Disponible en: http://www.mrtg.org/rrdtool/index.en.html [Ultima consulta 1 diciembre 2010].

[49] Tobias Oetiker. RRD World: projects using RRDtool. Disponibleen: http://www.mrtg.org/rrdtool/rrdworld/index.en.html [Ulti-ma consulta 1 diciembre 2010].

[50] Oren Ben-Kiki, Clark Evans, and Brian Ingerson. YAML ain’t markuplanguage (YAML) (tm) version 1.2. Technical report, YAML.org, 2009.Disponible en: http://www.yaml.org/spec/1.2/spec.html [Ultimaconsulta 1 diciembre 2010].

[51] P. Resnick. Internet Message Format. RFC 2822 (Proposed Standard),2001. Obsoleted by RFC 5322, updated by RFCs 5335, 5336. Dispo-nible en: http://www.ietf.org/rfc/rfc2822.txt [Ultima consulta 1diciembre 2010].

[52] YAML. Wikimedia Foundation, Inc., 2008. Disponible en: http://es.wikipedia.org/wiki/YAML [Ultima consulta 1 diciembre 2010].

[53] Wikipedia. Ini file. Disponible en: http://en.wikipedia.org/wiki/INI_file [Ultima consulta 1 diciembre 2010].

[54] D. Crockford. The application/json Media Type for JavaScript ObjectNotation (JSON). RFC 4627 (Informational), 2006. Disponible en:http://www.ietf.org/rfc/rfc4627.txt [Ultima consulta 1 diciem-bre 2010].

[55] JSON. Wikimedia Foundation, Inc., 2008. Disponible en: http://es.wikipedia.org/wiki/JSON [Ultima consulta 1 diciembre 2010].

[56] Real-Time Innovations Inc. The Real-Time Publish-Subscribe Middle-ware. Getting Started Guide (version 4.5c), 2010.

[57] Real-Time Innovations Inc. RTI Data Distribution Service. User’s Ma-nual (version 4.5c), 2010.

[58] Gary V. Vaughn, Ben Ellison, Tom Tromey, and Ian Lance Taylor.GNU Autoconf, Automake, and Libtool. Sams Publishing, 2000.

[59] Free Software Foundation Inc. GNU General Public License v2, 1991.Disponible en: http://www.gnu.org/licenses/gpl-2.0.html [Ulti-ma consulta 1 diciembre 2010].

http://www.mrtg.org/rrdtool/index.en.html

http://www.mrtg.org/rrdtool/index.en.html

http://www.mrtg.org/rrdtool/rrdworld/index.en.html

http://www.yaml.org/spec/1.2/spec.html


http://es.wikipedia.org/wiki/YAML

http://es.wikipedia.org/wiki/YAML

http://en.wikipedia.org/wiki/INI_file

http://en.wikipedia.org/wiki/INI_file


http://es.wikipedia.org/wiki/JSON

http://es.wikipedia.org/wiki/JSON

http://www.gnu.org/licenses/gpl-2.0.html

126 BIBLIOGRAFIA

[60] Jeremy Pack. Boost Extension Library, 2008. Disponible en: http://boost-extension.redshoelace.com/ [Ultima consulta 1 diciembre2010].

[61] Marcin Kalicinski. Boost Property Tree Library, 2008. Disponibleen: http://www.boost.org/doc/libs/1_41_0/doc/html/property_

tree.html [Ultima consulta 1 diciembre 2010].

[62] Michael Feathers. Working Effectively with Legacy Code. Prentice Hall,2004.

[63] RedIris. Plataforma de analisis de servicios de telecomunicaciones (PA-SITO), Version 7.0. Technical report, 2008.

[64] James Norton. Dynamic Class Loading for C++ on Linux. LinuxJournal, 2000(73), 2000.

[65] Jim Beveridge. Self-Registering Objects in C++. Dr. Dobb’s Journal,23(8):38–41, 1998.

http://boost-extension.redshoelace.com/

http://boost-extension.redshoelace.com/

http://www.boost.org/doc/libs/1_41_0/doc/html/property_tree.html

http://www.boost.org/doc/libs/1_41_0/doc/html/property_tree.html

Apendice A

Manual de usuario

A.1. Introducion

El presente documento incluye las instrucciones necesarias para la uti-lizacion de Cave Canem, una plataforma extensible para la monitorizacionde sistemas y la deteccion de intrusiones.

Esta aplicacion proporciona un entorno de trabajo distribuido, basado enel paradigma de publicacion/suscripcion que proporciona el RTI Data Dis-tribution Service, para la monitorizacion de diferentes eventos relacionadoscon el desempeno de un entorno en red y los elementos que la componen. Ca-ve Canem incluye una interfaz de visualizacion para el control y analisis deinformacion, ası como un sistema configuracion sencillo que permite adaptardiferentes detalles relativos a la extraccion y transmision de la misma.

La solucion presenta tres aplicaciones interdependientes para la gestionde las distintas necesidades que implica la monitorizacion de sistemas:

CCPublisher Este demonio publicador se encarga de la recoleccion de in-formacion de monitorizacion de distintos objetos y su publicacion, demodo que sea posible el procesamiento y almacenamiento de la mismapor parte de otras entidades.

CCSubscriber Se trata del demonio suscriptor que recibe informacion demonitorizacion procedente de diferentes demonios CCPublisher, alma-cenando esta en una base de datos.

Interfaz web A partir de esta aplicacion web se pueden controlar los da-tos de monitorizacion recolectados por CCSubscriber. Muestra grafi-camente la informacion, permitiendo analizar la evolucion de la mismaa lo largo del tiempo.

127

128 A.2. Requisitos

A.2. Requisitos

A continuacion se identifican los requisitos de los diferentes elementosque componen Cave Canem.

A.2.1. Requisitos de CCPublisher

Sistema operativo GNU/Linux para arquitecturas x86 o x86 64.

GNU Autoconf

GNU Automake

GNU Libtool

GNU Make y GCC

Biblioteca Boost C++ 1.38 o superior.

LibGTop 2.26 o superior.

10 MB de espacio libre en el disco duro.

A.2.2. Requisitos de CCSubscriber

Sistema operativo GNU/Linux para arquitecturas x86 o x86 64.

GNU Autoconf

GNU Automake

GNU Libtool

GNU Make y GCC

Biblioteca Boost C++ 1.38 o superior.

LibMYSQL y LibMYSQL++.

50 MB de espacio libre en el disco duro.

A.2.3. Requisitos de la interfaz web

Servidor web con soporte para PHP.

PHP 5.

MySQL 5.

5MB de espacio libre en el disco duro.

Manual de usuario 129

A.3. Instalacion

A.3.1. Aplicaciones de monitorizacion

La instalacion de CCPublisher y CCSubscriber se realiza, de forma simi-lar, a traves de las herramientas proporcionadas por el GNU build system.

Estas aplicaciones de monitorizacion se distribuyen, junto con su codigofuente, en paquetes tar comprimidos mediante la aplicacion gzip. Para des-comprimir estos paquetes se puede utilizar la propia herramienta tar con lossiguientes parametros.

$ tar xvzf cavecanem_publisher -0.0.2. tar.gz

$ tar xvzf cavecanem_publisher -0.0.2. tar.gz

$ ls

cavecanem_publisher cavecanem_publisher -0.0.2. tar.gz

cavecanem_subscriber cavecanem_subscriber -0.0.2. tar.gz

Una vez descomprimidas las aplicaciones, se deberan configurar las dis-tintas opciones de instalacion a traves de la ejecucion del script configure.Se realizara este procedimiento para CCPublisher en primer lugar:

$ cd cavecanem_publisher

$ ./ configure --sysconfdir =/etc --prefix =/usr

Los parametros anadidos a la ejecucion del script senalan los directoriodonde se desean instalar los ficheros de configuracion y las bibliotecas yejecutables, respectivamente. Si no se anaden dichos parametros a esta, todala informacion se almacenara a partir del directorio /usr/local1. Del mismomodo, la configuracion de CCSubscriber se realizara como se muestra acontinuacion:

$ cd cavecanem_subscriber

$ ./ configure --sysconfdir =/etc --prefix =/usr

Los scripts de configuracion comprueban la existencia de los requisitosnecesarios para la instalacion y el correcto funcionamiento de las aplicacionesde monitorizacion. Por tanto, en caso de incumplimiento de alguna de estos,se notificara al usuario con los pasos a realizar.

Una vez configuradas ambas aplicaciones para su instalacion, debera com-pilarse el codigo fuente a traves del siguiente comando en los directorioscorrespondientes a CCPublisher y CCSubscriber.

1En concreto se instalarıan los ficheros de configuracion en /usr/local/etc, las bi-bliotecas en /usr/local/lib y los ejecutables en /usr/local/bin

130 A.4. Guıa de uso de la aplicacion de monitorizacion

$ make

Por ultimo, en caso de realizarse la instalacion en directorios sobre losque el usuario no posee permisos de escritura, como es el caso del ejemploseguido, se necesitara la ejecucion de esta operacion como administrador delsistema. Se supondra aquı que el usuario esta en el grupo de sudoers, porlo que la instalacion se realizara a traves del siguiente comando desde losdirectorios de CCPublisher y CCSubscriber:

$ sudo make install

En caso de requerirse la desinstalacion de estas aplicaciones, esta serealizara de la misma forma y con los mismos permisos que la instalacionde CCPublisher y CCSubscriber, utilizando el siguiente comando desde eldirectorio en el que se encuentra su codigo fuente:

$ sudo make uninstall

A.3.2. Instalacion de la interfaz de usuario

El proceso de instalacion de la interfaz de usuario depende del servidorweb con soporte PHP elegido para la gestion de la aplicacion. Por tanto, seremite a la documentacion que este proporcione para la puesta en marchadel sistema a partir del codigo fuente que se provee.

A.4. Guıa de uso de la aplicacion de monitoriza-cion

En este apartado se realizara un analisis de los principales casos de usode CCPublisher y CCSubscriber, ası como la metodologıa a seguir para laobtencion de unos resultados satisfactorios en la ejecucion de estos.

A.4.1. CCPublisher

Como se menciono en el apartado A.1, CCPublisher es un demonio publi-cador para la recoleccion y difusion de datos de monitorizacion procedentesde diversas fuentes. Para gestionar la ejecucion del mismo, el sistema pro-porciona un script de tipo initd denominado cavecanem publisher. Estese instala en el directorio init.d, a partir de la raız del destino de configu-


racion elegido. De este modo, en el ejemplo de instalacion seguido en el elapartado A.3.1, dicho script se situarıa en /etc/init.d.

Para iniciar la recoleccion y publicacion de informacion de monitoriza-cion, se debera ejecutar el siguiente comando:

# /etc/init.d/cavecanem_publisher start

Para parar este procedimiento se debera ejecutar, al contrario,

# /etc/init.d/cavecanem_publisher stop

Por ultimo, tambien se ofrece la posibilidad de reiniciar directamente eldemonio a partir de la adicion parametro restart.

CCPublisher permite la modificacion de una serie de parametros paraseleccionar aspectos relacionados con la recoleccion de informacion, la cargade los plugins que la realizan, ası como de las caracterısticas de transportede esta.

Los parametros de configuracion mas genericos se incluyen en el ficherocavecanem publisher.xml, que en la instalacion realizada en el ejemplo seencontrarıa en el directorio /etc/cavecanem. Estos son:

<general> Datos generales relacionados con la publicacion.

• <domain id> Dominio DDS donde se realizara la publicacion dela informacion.

• <publishing period> Frecuencia (en segundos) con la que serecolectara y enviara la informacion de monitorizacion.

• <qos file> Fichero donde se almacenaran los perfiles de QoS dela publicacion de informacion.

<plugins> Incluye los plugins que deben ser iniciados en la ejecuciondel demonio publicador.

• <name> Nombre con el que se identifica el plugin.

• <lib name> Nombre de la biblioteca dinamica que contiene al plu-gin y que se aloja en el directorio de instalacion de las bibliotecasde Cave Canem.

Por su parte, la configuracion de las polıticas de QoS seguidas por la apli-cacion publicadora y sus plugins se incluye en un fichero, situado en el direc-torio /etc/cavecanem/qos/, denominado cavecanem publisher qos.xml.No obstante, se ofrece la posibilidad de realizar la carga de otros ficheros atraves de la edicion del parametro mencionado en la configuracion general.

132 A.4. Guıa de uso de la aplicacion de monitorizacion

El fichero que proporciona la aplicacion viene preparado para asegurarel desempeno idoneo de la misma, de acuerdo a las necesidades de los plu-gins que se proveen. No obstante, el usuario es libre de realizar cambios eneste consultando el manual de usuario del RTI Data Distribution Service,distribuido junto al middleware, que proporciona informacion suficiente enrelacion a este procedimiento.

A.4.2. CCSubscriber

Como se menciono en el apartado de introduccion, CCSubscriber es undemonio de suscripcion que realiza tareas de obtencion y almacenamientode informacion de monitorizacion. Al igual que en el caso de CCPublisher,se proporciona al usuario un script para la gestion de la ejecucion de laaplicacion. Este se denomina cavecanem subscriber y se agrega al la raızdel directorio de configuracion partiendo de la carpeta init.d.

Las opciones de ejecucion del script son las mismas que en el caso publi-cador, permitiendo la iniciacion, a traves del parametro start; la detenciondel demonio, mediante stop; y el reinicio del mismo, usando restart.

# /etc/init.d/cavecanem_publisher {start|stop|restart}

Los parametros de configuracion genericos de CCSubscriber se incluyenen el fichero cavecanem subscriber.xml, que en la instalacion de ejemplose situarıa en el directorio /etc/cavecanem. Este fichero permite la modifi-cacion de los siguientes parametros:

<general> Datos generales relacionados con la suscripcion.

• <domain id> Dominio DDS en el que se realizara la suscripciona la informacion.

• <qos file> Fichero donde se almacenaran los perfiles de QoS dela suscripcion a la informacion de monitorizacion.

<database> Informacion de acceso a la base de datos donde se alma-cenara la informacion de monitorizacion.

• <server> Localizacion de la base de datos.

• <name> Nombre de la base de datos.

• <user> Usuario con permisos de lectura y escritura sobre la basede datos.

• <password> Contrasena del usuario.

<plugins> Incluye los plugins que deben ser iniciados en la ejecuciondel demonio suscriptor.


• <name> Nombre con el que se identifica el plugin.

• <lib name> Nombre de la biblioteca dinamica que contiene al plu-gin y que se aloja en el directorio de instalacion de las bibliotecasde Cave Canem.

En relacion a la configuracion de las polıticas de QoS, la aplicacion inclu-ye el fichero cavecanem subscriber qos.xml, que en el ejemplo utilizadose instalarıa en el directorio /etc/cavecanem/qos. Este esta preparado conla configuracion idonea para la suscripcion a la informacion de monitoriza-cion. No obstante, como se indico en el apartado anterior, el usuario puedemodificar esta de acuerdo a sus preferencias.

A.5. Guıa de uso de la interfaz de usuario

Cave Canem proporciona una aplicacion web para el analisis de la infor-macion de monitorizacion recolectada por CCSubscriber. A traves de estase puede observar la evolucion en el tiempo de los diferentes parametrosmanejados por los demonios publicadores. En este apartado se realizara unanalisis de la utilizacion de la interfaz de usuario a traves de los tres posiblesescenarios que esta contempla.

Figura A.1: Pantalla principal de la interfaz de usuario

En la Figura A.1 se muestra la pantalla principal de la interfaz de usuario.En esta se recogen una serie de datos de los hosts sobre los que CCSubscri-ber ha registrado informacion de monitorizacion. En concreto, estos son su

134 A.5. Guıa de uso de la interfaz de usuario

nombre o hostname, el sistema operativo y su version, ası como la arquitec-tura del mismo. Cada una de estas entradas mantiene un enlace al siguienteescenario, que muestra la informacion actual de cada host. De este modo, sise pulsa sobre el enlace de uno de ellos, se observara una pantalla similar ala de la Figura A.2.

Figura A.2: Informacion actual de un host

En dicha pantalla se muestran datos en relacion a diferentes tematicassobre las que se recogen una serie de parametros. Por ejemplo, en el ejemplode la Figura A.2, se presenta informacion relacionada con la CPU como sutemperatura, la carga en los ultimos minutos o la utilizacion de esta porel sistema y el usuario. Algunos de los parametros proporcionan un enlacepara visualizar la grafica correspondiente a su evolucion en el tiempo. Deesta forma, si se pulsa por ejemplo en cpu system, se podra observar si lautilizacion de la CPU por parte del sistema y sus procesos ha crecido en losultimos minutos.

En la Figura A.3 se muestra otra de las tematicas analizables desdela interfaz web, la evolucion en el tiempo de los paquetes que entran enlas distintas interfaces de red de una maquina. Asimismo, la Figura A.4proporciona informacion acerca de las ultimas alertas registradas por un


IDS que ha recogido CCSubscriber.

Figura A.3: Informacion del estado de las interfaces de red de un host

Figura A.4: Alertas de IDS recolectadas por un host

136 A.5. Guıa de uso de la interfaz de usuario

Las distintas tematicas de informacion de monitorizacion proporcionanun enlace en el cuadro superior que incluye su nombre. Al accionar este, elusuario podra observar todas las entradas registradas en la base de datos enrelacion a dicha tematica. Se trata este del tercer y ultimo escenario. En laFigura A.5 se muestran todos los valores con informacion relativa a la CPUde un host para ejemplificar el mismo.

Figura A.5: Informacion recolectada en relacion a datos de CPU de un host

Apendice B

Desarrollo de un sistema deplugins en C++

El presente documento pretende servir de introduccion al desarrollo desistemas extensibles de plugins utilizando C++ sobre GNU/Linux. Las ideasdesarrolladas en este parten del artıculo “Dynamic Class Loading for C++on Linux” [64] de James Norton, publicado por la revista Linux Journal, Ası,a traves del mismo, se pretende facilitar la comprension de la arquitecturaextensible sobre la que se basa Cave Canem y que le proporciona, a la postre,su flexibilidad para incorporar nuevas herramientas y funcionalidades.

B.1. Introduccion

El sistema operativo GNU/Linux tiene mucho que ofrecer como plata-forma de desarrollo, se trata de un entorno robusto con herramientas masque probadas, que proporciona implementaciones de practicamente todos loslenguajes de programacion existentes. Sin embargo, el lenguaje de progra-macion elegido por la mayorıa de desarrolladores en este es C, por lo que laevaluacion de lenguajes alternativos como C++ queda relegada en multitudde ocasiones.

La tecnica de carga dinamica de clases proporciona a los desarrollado-res una gran flexibilidad a la hora de realizar sus disenos, proporcionandoescalabilidad sin sacrificar la robustez.

En este artıculo, se disenara una aplicacion a partir de la definicionde una clase sencilla, la clase shape, que formara la base de un paquetede dibujo. Como se observara mas adelante, la carga dinamica de clasespermitira la realizacion de un programa extensible, al que los usuarios de laaplicacion podran anadir nuevos tipos o formas sin la necesidad de modificar

137

138 B.2. Polimorfismo

su codigo original.

B.2. Polimorfismo

La idea basica detras de la carga dinamica de clases es el concepto depolimorfismo. En pocas palabras, el polimorfismo es la habilidad de un obje-to que hereda de una clase para actuar como un objeto de dicha clase. Estarelacion se define como “es un” en terminos de programacion orientada aobjetos. Por ejemplo, en el siguiente fragmento de codigo, la clase circle

hereda de la clase base shape, por lo que el objeto my circle podra actuarcomo un objeto shape invocando su funcion miembro draw().

class shape {public:

void draw();};class circle : public shape { };int main(int argc, char ∗∗argv){

circle my circle;my circle.draw();

}

Ademas de ventajas propias como la reutilizacion de codigo, el verdade-ro poder del polimorfismo entra en juego cuando draw() se declara comovirtual o pure virtual, tal y como se muestra en el siguiente fragmentode codigo:

class shape{public:

virtual void draw()=0;};class circle : public shape { public:

void draw();}

Aquı, circle ha declarado su propia funcion draw(), que define el com-portamiento apropiado de esta para un cırculo. De forma similar, se puedendeclarar otras clases que deriven de shape y que incluyan su propia versionde draw(). Por tanto, dado que todas las clases implementan la interfazde shape, pueden crearse colecciones de objetos que proporcionen un com-portamiento diferente siendo invocadas de la misma forma (llamando a lafuncion miembro draw()). Un ejemplo de esto se muestra a continuacion.

Desarrollo de un sistema de plugins en C++ 139

shape ∗shape list[3]; // the array that will// pointer to our shape objects

shape[0] = new circle; // three types of shapesshape[1] = new square; // we have definedshape[2] = new triangle;for(int i = 0; i < 3; i++){

shape list[i].draw();}

Cuando se invoca la funcion draw() para cada objeto de la lista, no esnecesario conocer nada sobre cada uno de estos. Al contrario, C++ se ocupadel manejo interno para invocar la version correcta de draw(). Se trata, portanto, de una tecnica muy poderosa que permite implementar cualquierdiseno de forma extensible. La clave en este proceso es la separacion entrela interfaz (el prototipo de shape) y la implementacion.

A pesar de las ventajas que ofrece la adopcion de esta tecnica, existe elinconveniente de la necesidad de recompilar (o al menos reenlazar) el codigo ala hora de anadir una clase derivada. En este sentido, supondrıa una mayorventaja la posibilidad de cargar nuevas clases en tiempo de ejecucion, deforma que cualquier usuario de la biblioteca de codigo pudiera implementarnuevas clases shape, sin la necesidad de poseer ni siquiera el codigo original.

B.3. dlopen() y la carga dinamica de clases

C++ no tiene una forma directa, bajo Linux, para cargar clases en tiem-po de ejecucion. Sin embargo, existe un mecanismo que permite la cargade bibliotecas en C en estas circunstancias: la compuesta por las funcionesdlopen(), dlsym(), dlerror() y dlclose(), que proporcionan acceso alenlazado dinamico ld.

Los prototipos de las funciones son los siguientes:

void ∗dlopen(const char ∗file, int mode);void ∗dlsym(void ∗handle, char ∗symbol);const char ∗dlerror();int dlclose(void ∗handle);

La funcion dlopen() realiza la apertura del fichero dado por parametrode forma que permite el acceso, a traves de la funcion dlsym(), a los diferen-tes sımbolos contenidos en este. El parametro mode puede tomar dos valores:RTLD LAZY o RTLD NOW. Si se selecciona RTLD LAZY, dlopen() devolvera sinintentar resolver ningun sımbolo en caso de fallo. Al contrario, si se selec-ciona RTLD NOW, dlopen() intentara resolver cualquier sımbolo indefinido en

140 B.3. dlopen() y la carga dinamica de clases

el fichero. Un fallo en la resolucion de cualquier sımbolo causara un erroren la llamada, devolviendose NULL. La funcion dlerror() se utilizara paraexplicar el porque del fallo. La funcion dlsym() se utiliza para obtener unpuntero a las funciones (u otros sımbolos) que se encuentran en la biblioteca,siendo handle el puntero de referencia y symbol el nombre de la cadena quedescribe al ıtem sobre el que se esta haciendo referencia y que se encuentraalmacenado en el fichero.

El problema es como utilizar estas funciones para acceder a clases deC++. Para afrontar este hecho se debe dar respuesta a varias cuestiones.Primero, deben localizarse los sımbolos necesitados por la biblioteca, sımbo-los que se almacenan de forma diferente en C y C++. Segundo, debe co-nocerse un metodo para la creacion de objetos que pertenezcan a las clasescargadas y, finalmente, debe existir la forma de acceder a dichos objetos.

Partiendo de la inexistencia de prototipos de las clases que se desea car-gar dinamicamente, ¿como serıa posible acceder a ellas desde el codigo de laaplicacion? La respuesta a esta pregunta se basa en la aplicacion del concep-to de polimorfismo. Se definiran objetos que hereden de la clase base shape,actuando como objetos de esta. De esta forma, a traves de la adaptacionde los metodos virtuales que la clase base propone, se definira el metodo deacceso desde la aplicacion.

Como ya se sabe, no es posible utilizar punteros a la clase base paraacceder a objetos de clases derivadas, ¿como se podrıan crear entonces losobjetos? No se conoce nada acerca de las clases que pueden ser cargadas,solo que se adecuan a la interfaz de shape. Por ejemplo, suponiendo quefuera posible cargar dinamicamente una biblioteca que proporcione una clasellamada hexapod, no serıa posible escribir

shape ∗my shape = new hexapod;

sin conocer el nombre de la clase de antemano.

La solucion a este problema se basa en que el programa principal no creelos objetos, al menos no de forma directa. De este modo, la misma bibliotecaque proporciona la clase derivada de shape debera incluir una manera decrear objetos de la nueva clase. Esto puede hacerse usando una clase factorıa,como en el patron de diseno Factory, o de forma mas directa utilizando unafuncion sencilla. Para simplificar, se utilizara una funcion, cuyo prototiposera el mismo para todos los tipos shape:

shape ∗maker();

maker no toma argumentos y devuelve un puntero al objeto construido.


shape ∗maker(){return new hexapod;

}

No obstante, la utilizacion de new para crear el objeto no es adecuada,ya que maker() se ha definido en el mismo fichero que hexapod. Al utilizardlopen() para cargar la biblioteca es posible usar dlsym() para obtener unpuntero a la funcion maker() para esta clase. Por lo tanto, puede utilizarseeste puntero para construir objetos pertenecientes a la misma. En el siguienteejemplo se enlaza dinamicamente una biblioteca llamada libnewshapes.so,que proporciona la clase hexapod:

void ∗hndl = dlopen("libnewshapes.so", RTLD NOW);if(hndl == NULL){

cerr << dlerror() << endl;exit(−1);

}void ∗mkr = dlsym(hndl, "maker");

El puntero a maker() debe ser de tipo void * ya que este es el tipode dato devuelto por dlsym(). Ahora, sera posible crear objetos de la clasehexapod invocando (mkr)(), tal y como se indica a continuacion:.

shape ∗my shape = static cast<shape ∗()>(mkr)();

Sera obligatorio hacer un cast al puntero a funcion que realiza la devolu-cion de shape*() cuando este es invocado. No obstante, este codigo podrıaprovocar un error: la llamada a dlsym() fallara en caso de no poder resol-ver maker(). El problema es que, en C++, los nombres de las funcionesestan implementados para soportar la sobrecarga de las mismas, por lo quela funcion maker() puede tener un nombre diferente en la biblioteca. Serıanecesario, en ese caso, buscar este sımbolo. No obstante, existe una solucionmas simple, que se basa en la inclusion de una indicacion al compiladorpara la utilizacion de un enlazado “tipo C”. Esto se realizara a traves delcalificador extern ‘‘C’’, como se muestra a continuacion:

#ifndef CIRCLE H#define CIRCLE H#include "shape.hh"

class circle : public shape {public:

void draw();};#endif // CIRCLE H

142 B.4. Autoregistro

#include <iostream>#include "circle.hh"

void circle::draw(){// simple ascii circle<\n>cout << "\n";cout << " ****\n";cout << " * *\n";cout << " * *\n";cout << " * *\n";cout << " * *\n";cout << " * *\n";cout << " ****\n";cout << "\n";

}extern "C" {shape ∗maker(){

return new circle;}class proxy {public:

proxy(){// register the maker with the factoryfactory["circle"] = maker;

}};// our one instance of the proxyproxy p;}

B.4. Autoregistro

Para el manejo de los makers, podrıan cargarse las distintas funcionesmaker() en un vector, asociandose cada posicion en el array con una deestas. Esto puede ser util en algunos casos, pero es posible obtener una ma-yor flexibilidad utilizando arrays asociativos para el almacenamiento de losmakers. La clase map de la biblioteca estandar de C++ (Standard TemplateLibrary o STL) sera la adecuada para esta funcion ya que, con ella se haceposible la asignacion de valores clave a los makers y el acceso a los mismosa traves de estas. Por ejemplo, serıa posible asignar un valor string con elnombre de cada clase y usar dichos valores como clave para invocar el makeradecuado. En este caso, podrıa crearse un map de la siguiente manera:

typedef shape ∗maker ptr();map <string, maker ptr> factory;


Ahora, cuando se necesite la creacion de un objeto derivado de shape,sera posible invocar el maker adecuado utilizando el nombre particular decada shape:

shape ∗my shape = factory[""];

Esta tecnica puede ser extendida de una forma todavıa mas flexible.En lugar de cargar los makers y asignar un valor clave a cada uno, podrıacederse esta tarea a los disenadores de la clase. De esta manera, serıa posiblehacer que los makers se registraran solos con la factory automaticamenteusando la clave que el disenador haya elegido.

Una manera de cumplir este objetivo serıa la inclusion de una funcionen cada shape que registrara el maker, realizandose una llamada a estacada vez que se abra la biblioteca. De acuerdo con la documentacion dela funcion dlopen(), si la biblioteca exporta una funcion llamada init(),esta se ejecutara cada vez que la biblioteca sea llamada. Esta aproximacionse conoce como self-registering objects y fue introducida por Jim Beveridge[65].

Se puede crear una clase proxy utilizada exclusivamente para registrarel maker. El registro ocurre en el constructor de la clase, por tanto, se de-bera crear solo una instancia de la clase proxy para registrar el maker. Elprototipo de la clase serıa el siguiente:

class proxy {public:

proxy(){factory["shape name"] = maker;

}};

Aquı, se asume factory como un map global exportado por el progra-ma principal. En caso de utilizar el compilador GCC se deberıa realizar elenlazado usando la opcion -rdynamic para forzar al programa principal laexportacion de sus sımbolos para las bibliotecas cargadas con dlopen().

Una vez hecho esto, se declara una instancia de proxy:

proxy p;

Ahora, al abrir la biblioteca se pasa la bandera RTLD NOW a dlopen(),causando que p sea instanciado, registrandose ası el maker. Para crear uncircle sera necesaria la invocacion del maker del mismo de la siguienteforma:

144 B.5. Ejemplo

shape ∗my circle = factory["circle"];

El proceso de autoregistro es muy poderoso, ya que permite disenar elprograma principal sin conocer de forma explıcita de las clases soportadas.Por ejemplo, despues de que el programa principal cargue dinamicamentecualquier biblioteca de shape, sera posible crear un menu de seleccion deshapes utilizando las claves registradas en factory. Hecho esto, el usuariopodra seleccionar circle de un menu y el programa asociara la seleccion conel maker adecuado. El programa principal no necesita ninguna informacionsobre la clase circle aparte de que soporta la API de shape y que su makerse encuentra definido correctamente.

B.5. Ejemplo

A continuacion se presenta el codigo completo del ejemplo presentado.En el Listing B.1 se puede observar la definicion de la clase base shape.

Listing B.1: shape.hh

1 //Header File for Base Class Shape2

3 #ifndef SHAPE H4 #define SHAPE H5 #include <map>6 #include <string>7 // base class for all shapes8 class shape {9 public:

10 virtual void draw()=0;11 };12 // typedef to make it easier to set up our factory13 typedef shape ∗maker t();14 // our global factory15 extern std::map<std::string, maker t ∗, std::less<std::string> > factory;16 #endif // SHAPE H

En el Listing B.2 se define la clase derivada circle:

Listing B.2: circle.cpp

1 #ifndef CIRCLE H2 #define CIRCLE H3 #include "shape.hh"

4

5


6 using namespace std;7 class circle : public shape {8 public:9 void draw();

10 };11 #endif // CIRCLE H12 #include <iostream> #include "circle.hh"

13 void circle::draw(){14 // simple ascii circle15 cout << "\n";16 cout << " ****\n";17 cout << " *******\n";18 cout << " *********\n";19 cout << " **********\n";20 cout << " **********\n";21 cout << " ********\n";22 cout << " ****\n";23 cout << "\n";24 }25 extern "C" {26 shape ∗maker(){27 return new circle;28 }29 class proxy {30 public:31 proxy(){32 // register the maker with the factory33 factory["circle"] = maker;34 }35 };36 // our one instance of the proxy37 proxy p;38 }

El Listing B.3 muestra la implementacion de la biblioteca square, quepermite cargar la misma dinamicamente.

Listing B.3: square.cpp

1 #ifndef SQUARE H2 #define SQUARE H3 #include "shape.hh"

4

5 using namespace std;6

7 class square : public shape {8 public:9 void draw();

10 };

146 B.5. Ejemplo

11 #endif // SQUARE H12 #include <iostream>13 //#include ”square.hh”14 void square::draw(){15 // simple ascii square16 cout << "\n";17 cout << " *********\n";18 cout << " *********\n";19 cout << " *********\n";20 cout << " *********\n";21 cout << " *********\n";22 cout << " *********\n";23 cout << "\n";24 }25 extern "C" {26 shape ∗maker(){27 return new square;28 }29 class proxy { public:30 proxy(){31 // register the maker with the factory32 factory["square"] = maker;33 }34 };35 // our one instance of the proxy36 proxy p;37 }

El Listing B.4 es el programa principal que se ampliara con la cargadinamica de plugins. Este busca en el directorio actual ficheros con exten-sion .so (bibliotecas) y los abre. La biblioteca registra entonces sus makersen la factorıa global que se incluye en el programa principal. Entonces, esteconstruye un menu dinamicamente con los nombres de las bibliotecas regis-tradas. Utilizando el menu, el usuario podra construir shapes, invocar a lafuncion draw() para dibujar las formas construidas o salir del programa.

Listing B.4: testdcl.cpp

1 //Source for Main Program Invoking Dynamically Loaded Classes2 //Circle and Square3

4 #include <iostream>5 #include <map>6 #include <list>7 #include <vector>8 #include <string>9 #include <dlfcn.h>

10 #include <stdio.h>


11 #include <unistd.h>12 #include <stdlib.h>13 #include <cstring>14 #include "shape.hh"

15

16 using namespace std;17

18 // size of buffer for reading in directory entries19 static unsigned int BUF SIZE = 1024;20 // our global factory for making shapes21 map<string, maker t ∗, less<string> > factory;22 int main(int argc, char ∗∗argv){23 FILE ∗dl; // handle to read directory24 char ∗command str = "ls *.so"; // command25 // string to get dynamic lib names26 char in buf[BUF SIZE]; // input buffer for lib27 // names28 list<void ∗> dl list; // list to hold handles29 // for dynamic libs30 list<void ∗>::iterator itr;31 vector<string> shape names; // vector of shape32 // types used to build menu33 list<shape ∗> shape list; // list of shape34 // objects we create35 list<shape ∗>::iterator sitr;36 map<string, maker t ∗, less<string> >::iterator fitr;37 // get the names of all the dynamic libs (.so38 // files) in the current dir39 dl = popen(command str, "r");40 if(!dl){41 perror("popen");42 exit(−1);43 }44 void ∗dlib;45 char name[1024];46 while(fgets(in buf, BUF SIZE, dl)){47 // trim off the whitespace48 char ∗ws = strpbrk(in buf, " \t\n");49 if(ws) ∗ws = ’\0’;50 // append ./ to the front of the lib name51 sprintf(name, "./ %s", in buf);52 dlib = dlopen(name, RTLD NOW);53 if(dlib == NULL){54 cerr << dlerror() << endl;55 exit(−1);56 }57 // add the handle to our list58 dl list.insert(dl list.end(), dlib);59 }

148 B.5. Ejemplo

60 int i = 0;61 // create an array of the shape names62 for(fitr=factory.begin(); fitr!=factory.end();63 fitr++){64 shape names.insert(shape names.end(),65 fitr−>first);66 i++;67 }68 int choice;69 // create a menu of possible shapes to create and let the user make some70 while(1){71 int i = 1;72 for(fitr=factory.begin();73 fitr!=factory.end(); fitr++){74 cout << i << " - Create " << fitr−>first75 << endl;76 i++;77 }78 cout << i << " - Draw created shapes\n";79 i++;80 cout << i << " - Exit\n";81 cout << "> ";82 cin >> choice;83 if(choice == i){84 // destroy any shapes we created85 for(sitr=shape list.begin();86 sitr!=shape list.end();sitr++){87 delete ∗sitr;88 }89 // close all the dynamic libs we opened90 for(itr=dl list.begin(); itr!=dl list.end(); itr++){91 dlclose(∗itr);92 }93 exit(1);94 }95 if(choice == i − 1){96 // draw the shapes97 for(sitr=shape list.begin();98 sitr!=shape list.end();sitr++){99 (∗sitr)−>draw();

100 }101 }102 if(choice > 0 && choice < i − 1){103 // add the appropriate shape to the shape list104 shape list.insert(shape list.end(),105 factory[shape names[choice−1]]());106 }107 }108 }


Por ultimo, el Listing B.5 es el Makefile utilizado para construir el pro-yecto:

Listing B.5: circle.cpp

1 CC = g++2 LIBS = −ldl3 .cc.o:4 $(CC) −ggdb −c $<5 default:6 make testdcl7 OBJS = testdcl.o8 testdcl: testdcl.o9 $(CC) −rdynamic −o testdcl testdcl.o $(LIBS)

10 libcircle.so: circle.o11 g++ −shared −Wl,−soname,libcircle.so −o libcircle.so circle.o12 libsquare.so: square.o13 g++ −shared −Wl,−soname,libsquare.so −o libsquare.so square.o14 all: testdcl libcircle.so libsquare.so15 clean:16 rm −f ∗.so ∗.o testdcl

Apendice C

Glosario

CPU Central Processing Unit o Unidad Central de Procesamiento. Se aso-cia con el componente de ordenadores y otros dispositivos programa-bles que interpreta las instrucciones contenidas en los programas yprocesa los datos.

CSV Comma-Separated Values, es un formato de documento sencillo parala representacion de datos en forma de tabla.

CU Caso de uso.

DCPS Data-Centric Publish-Subscribe, modelo de comunicacion estandarpara la difusion de informacion segun el paradigma publicador/sus-criptor, tal y como implementa DDS.

DDS Data Distribution Service o Servicio de distribucion de datos. Se tra-ta de un estandar de la OMG para la distribucion de informacionsiguiendo el paradigma de publicacion/suscripcion.

DIDS Distributed IDS, sistemas de deteccion de intrusos en red que secomunican a traves de un servidor central.

DPM Disk Pool Manager, es una solucion ligera para la gestion del alma-cenamiento en disco.

HIDS Host IDS, sistemas de deteccion de intrusos centrados en el analisisde un host.

HTTP Hypertext Transfer Protocol, es un protocolo para la transferenciade hipertexto.

IANA Internet Assigned Numbers Authority, agencia para la asignacionde numeros de Internet. Fue sustituida en 1998 por ICANN (InternetCorporation for Assigned Names and Numbers).

151

152

IDS Intrusion Detection System o Sistema de Deteccion de Intrusos.

INI Windows INItialization file, es un formato para la definicion de ficherosde configuracion.

JSON JavaScript Object Notation, es formato ligero para el intercambio dedatos.

LAN Local area network o Red de Area Local.

Middleware Software encargado de abstraer a la aplicacion de la existenciade un entorno distribuido.

NIDS Network IDS, sistemas de deteccion de intrusos en segmentos de red.

OMG Object Management Group, es un consorcio dedicado al cuidado yel establecimiento de diversos estandares de tecnologıas orientadas aobjetos.

POP3 Post Office Protocol, es un protocolo para la obtencion de mensajesde correo electronico en un servidor remoto.

QoS Quality-of-Service o Calidad de Servicio para garantizar la transmisionde informacion de acuerdo a unas caracterısticas dadas.

RFC Request for Comments, es un memorandum publicado por el Inter-net Engineering Task Force (IETF) para la definicion de protocolosy comportamientos en relacion a Internet y a sistemas conectados almismo.

RTI Real-Time Innovations, Inc. Se trata de una empresa norteamericanacentrada en el diseno de middleware para la distribucion de informa-cion en aplicaciones con necesidades crıticas.

SGBD Sistemas Gestores de Bases de Datos.

SMTP Simple Mail Transfer Protocol, protocolo de la capa de aplicacionpara la transferencia de correo electronico.

SNMP Simple Network Management Protocol o Protocolo Simple para laAdministracion de Red, es un protocolo de la capa de aplicacion quefacilita el intercambio de informacion de administracion entre disposi-tivos de red.

SSL Secure Sockets Layer, protocolo que proporciona comunicaciones segu-ras en una red.

STL Standard Template Library, biblioteca estandar de C++.

Glosario 153

UML Unified Modeling Language, es un lenguaje de modelado de sistemassoftware.

W3C World Wide Web Consortium, es un consorcio internacional que pro-duce recomendaciones para la World Wide Web.

XML eXtensible Markup Language, lenguaje de marcas extensible para ladefinicion de gramaticas de lenguajes especıficos.

YAML YAML Ain’t Another Markup Language, formato de serializacionde datos.

cave canem -- an extensible plugin-based monitoring and intrusion detection system

Documents