PROYECTO FIN DE CARRERA
INGENIER´IA EN INFORM´ATICA
Cave Canem
Plataforma extensible para la monitorizaci´on de sistemas y...
Cave Canem
Plataforma extensible para la monitorizaci´on de sistemas y
la detecci´on de intrusiones con DDS
Autor
Fernando...
Cave Canem: plataforma extensible para la monitorizaci´on
de sistemas y la detecci´on de intrusiones con DDS
Fernando Garc...
Cave Canem: an extensible DDS-based monitoring and
intrusion detection system
Fernando Garc´ıa Aranda
Keywords: DDS, Data ...
Yo, Fernando Garc´ıa Aranda, alumno de la titulaci´on Ingenier´ıa en
Inform´atica de la Escuela T´ecnica Superior de Ingen...
D. Juan Manuel L´opez Soler, Profesor Titular del ´Area de Ingenier´ıa
Telem´atica del Departamento de Teor´ıa de la Se˜na...
Agradecimientos
En primer lugar quiero agradecer a Jos´e Mar´ıa y Manuela, mis padres, el
apoyo, ´animo y la comprensi´on ...
´Indice general
1. Introducci´on 1
1.1. Presentaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Data ...
ii ´INDICE GENERAL
4.3.1. Desacople en tiempo y espacio . . . . . . . . . . . . . 36
4.3.2. Filtros en la recepci´on de to...
´INDICE GENERAL iii
6.1.4. Sistema de configuraci´on . . . . . . . . . . . . . . . . . 98
6.1.5. Sistema de almacenamiento ...
´Indice de figuras
3.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Digrama de casos de uso d...
vi ´INDICE DE FIGURAS
6.5. Instanciaci´on de plugins en CCPublisher . . . . . . . . . . . . 93
6.6. Fichero de configuraci´...
´Indice de cuadros
3.1. Planificaci´on del proyecto: tareas . . . . . . . . . . . . . . . . 20
4.1. Plantilla para la defini...
Cap´ıtulo 1
Introducci´on
1.1. Presentaci´on
La sustituci´on progresiva de los modelos de computaci´on centralizados
por e...
2 1.1. Presentaci´on
general, estas tecnolog´ıas entran dentro del concepto de middleware.
1.1.1. Data Distribution Servic...
Introducci´on 3
1.2. Definici´on del problema
La utilizaci´on de distintas herramientas de monitorizaci´on y detecci´on
de ...
4 1.3. Objetivos
1.3. Objetivos
Una vez realizada una primera definici´on del problema, en este apartado
se detallan los ob...
Introducci´on 5
tener en cuenta el modo en el que se presenta la informaci´on recolecta-
da. Se deber´a proporcionar al ad...
6 1.4. Antecedentes y estado del arte
En los ´ultimos tiempos, RPC ha evolucionado para aprovechar la extensibi-
lidad de ...
Introducci´on 7
acuerdo con este modelo, las aplicaciones de monitorizaci´on y de detecci´on
podr´ıan publicar sus diferen...
8 1.4. Antecedentes y estado del arte
OSSEC. Se trata de un detector de intrusos en host (HIDS). Propor-
ciona, entre otra...
Introducci´on 9
OS fingerprinting e identificaci´on de servicios
P0f. Se trata de una herramienta de identificaci´on pasiva d...
10 1.4. Antecedentes y estado del arte
encuentran SMTP, POP3, HTTP o PING. No obstante, su verdadero poten-
cial recae en ...
Introducci´on 11
Pandora FMS
Pandora FMS (Flexible Monitoring System) es una aplicaci´on para la
monitorizaci´on de todo t...
12 1.6. Recursos
y compiladores soportados por el RTI Data Distribution Service. Te-
niendo en cuenta ´estos y el software...
Introducci´on 13
1.6.1. Humanos
Prof Dr. Juan Manuel L´opez Soler. Profesor del Departamento de
Teor´ıa de Se˜nal, Telem´a...
14 1.7. Fases de desarrollo
GNU build system o Autotools, herramienta muy utilizada en proyectos
de software libre para la...
Introducci´on 15
Se examinar´an soluciones previas que se acerquen a la definici´on
del problema desarrollada anteriormente...
Cap´ıtulo 2
Especificaci´on de requisitos
El objetivo de este cap´ıtulo es identificar el conjunto de requerimientos
que el ...
18 2.2. Requisitos no funcionales
2.2. Requisitos no funcionales
Se orientan al funcionamiento final de la aplicaci´on. Se ...
Cap´ıtulo 3
Planificaci´on
A partir de las fases del proyecto definidas en el cap´ıtulo de introducci´on,
se presenta una es...
20
Tarea Inicio Fin D´ıas
1. Definici´on del proyecto 1 dic 11 dic 9 d´ıas
1.1 Descripci´on del problema 1 dic 4 dic 4 d´ıa...
Planificaci´on 21
Figura 3.1: Diagrama de Gantt
Cap´ıtulo 4
An´alisis del sistema
Una vez descrito el problema a trav´es de la identificaci´on de requisitos,
el siguiente ...
24 4.1. An´alisis de requisitos
Objeto de Monitorizaci´on Es el elemento, o elementos, que se desea ana-
lizar peri´odicam...
An´alisis del sistema 25
No obstante, en la bibliograf´ıa se incluyen plantillas alternativas como la de
Alistair Cockburn...
26 4.1. An´alisis de requisitos
2. A trav´es de la inclusi´on del caso de uso CU4 se realiza la carga de
la configuraci´on....
An´alisis del sistema 27
Actores
Usuario y Sistema de Almacenamiento.
Precondiciones
No existen precondiciones para este c...
28 4.1. An´alisis de requisitos
CU#5: Obtener datos de monitorizaci´on
Una vez obtenidos los par´ametros de configuraci´on ...
An´alisis del sistema 29
2. Se realiza una conexi´on con el Sistema de Almacenamiento y se intro-
ducen los datos de acuer...
30 4.1. An´alisis de requisitos
Figura 4.2: Diagrama de paquetes del sistema
Almacenar datos de monitorizaci´on (CU6).
Por...
An´alisis del sistema 31
secci´on se analizar´an, a grandes rasgos, los procesos de interacci´on que si-
guen los principa...
32 4.1. An´alisis de requisitos
informaci´on, como las pol´ıticas que deber´a seguir a la hora de trans-
mitir ´esta a tra...
An´alisis del sistema 33
Figura 4.4: Diagrama de secuencia: Subscriber
4. El procedimiento que se sigue una vez recibidos ...
34 4.2. An´alisis de la arquitectura de monitorizaci´on
Figura 4.5: Diagrama de secuencia: User Interface
los datos de mon...
An´alisis del sistema 35
ware (como la frecuencia o temperatura de un procesador), como con
servicios software (por ejempl...
36 4.3. An´alisis del middleware
4.3.1. Desacople en tiempo y espacio
Como se coment´o en el apartado 1.4.1, DDS proporcio...
An´alisis del sistema 37
4.3.3. Monitorizaci´on de eventos a trav´es del uso de listeners
El uso de listeners es uno de lo...
38 4.4. An´alisis del sistema de almacenamiento
History Especifica el n´umero de muestras de informaci´on almacenadas pa-
r...
An´alisis del sistema 39
maci´on, en contraposici´on a los sistemas gestores de bases de datos. Sin
embargo, la recuperaci...
40 4.4. An´alisis del sistema de almacenamiento
La sintaxis de XML es redundante y grande, en t´erminos de tama˜no, en
com...
An´alisis del sistema 41
pecificaciones deben indicarse, normalmente, al abrir el fichero, por ejemplo
mediante un programa ...
42 4.4. An´alisis del sistema de almacenamiento
Entre los inconvenientes del uso de bases de datos en sistemas de moni-
to...
An´alisis del sistema 43
La soluci´on a este inconveniente viene dada por la adopci´on de un esque-
ma de almacenamiento h...
44 4.5. An´alisis del sistema de configuraci´on
[Red]
; Poner UsarProxy =0 si no hay cortafuegos
UsarProxy =1
Proxy =129.12...
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Cave Canem -- An extensible plugin-based monitoring and intrusion detection system
Upcoming SlideShare
Loading in …5
×

Cave Canem -- An extensible plugin-based monitoring and intrusion detection system

4,674 views

Published on

Cave Canem is an extensible plugin-based monitoring and intrusion detection system. It exploits the benefits of the RTI Connext DDS middleware to disseminate monitoring information. Cave Canem can be integrated with relational databases and provides a web user interface for data visualization.

It is free software under the GNU LGPL v3 license.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,674
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cave Canem -- An extensible plugin-based monitoring and intrusion detection system

  1. 1. PROYECTO FIN DE CARRERA INGENIER´IA EN INFORM´ATICA Cave Canem Plataforma extensible para la monitorizaci´on de sistemas y la detecci´on de intrusiones con DDS Autor Fernando Garc´ıa Aranda Directores Juan Manuel L´opez Soler Javier S´anchez Monedero Departamento de Teor´ıa de la Se˜nal, Telem´atica y Comunicaciones — Granada, diciembre de 2010
  2. 2. Cave Canem Plataforma extensible para la monitorizaci´on de sistemas y la detecci´on de intrusiones con DDS Autor Fernando Garc´ıa Aranda Directores Juan Manuel L´opez Soler Javier S´anchez Monedero
  3. 3. Cave Canem: plataforma extensible para la monitorizaci´on de sistemas y la detecci´on de intrusiones con DDS Fernando Garc´ıa Aranda Palabras clave: DDS, Data Distribution Service, monitorizaci´on de siste- mas, IDS, middleware. Resumen La sustituci´on progresiva de los modelos de computaci´on centralizados por entornos distribuidos, ha convertido la monitorizaci´on de aplicaciones, sistemas y desempe˜no de redes, en una tarea crucial en la gesti´on de servicios en red. Actualmente, existen gran cantidad de herramientas que ofrecen una respuesta parcial a este problema (por ejemplo, los sistemas para la detecci´on de intrusos (IDS) o las herramientas para la monitorizaci´on de sistemas), sin embargo ´estas no proporcionan la soluci´on integral requerida para una comprensi´on global del entorno y una reacci´on eficaz ante los posibles eventos y amenazas que puedan ocurrir. En este contexto se propone Cave Canem, una plataforma integradora para la gesti´on eficiente de la informaci´on generada por este tipo de herra- mientas. ´Esta proporciona, a trav´es de la utilizaci´on de un entorno informa- tivo ´unico y escalable, una visi´on de conjunto del estado de los sistemas y la red, facilitando en gran medida las labores de administraci´on. Cave Canem apoya su modelo de comunicaci´on en el paradigma de pu- blicaci´on/suscripci´on definido por el est´andar de la OMG DDS (Data Dis- tribution Service). De esta forma, el proyecto muestra c´omo el uso de la funcionalidad proporcionada por ´este (desacoplo de entidades en tiempo/es- pacio, definici´on de pol´ıticas de QoS, etc.), simplifica el desarrollo de un sistema de monitorizaci´on, proporcionando un entorno flexible, eficiente y robusto.
  4. 4. Cave Canem: an extensible DDS-based monitoring and intrusion 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 network health 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 each separately cannot provide the complete view required to understand and react quickly. In this context we propose Cave Canem, a framework for the develop- ment of a “complete” operational picture for the combination of multiple kinds 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 and QoS settings (reliability, transport priorities, etc.) which ensure that the en- tire system status can be efficiently distributed according to the subscriber interests.
  5. 5. Yo, Fernando Garc´ıa Aranda, alumno de la titulaci´on Ingenier´ıa en Inform´atica de la Escuela T´ecnica Superior de Ingenier´ıas Inform´ati- ca y de Telecomunicaci´on de la Universidad de Granada, con DNI 30985659J, autorizo la ubicaci´on de la siguiente copia de mi Proyecto Fin de Carrera en la biblioteca del centro para que pueda ser consultada por las personas que lo deseen. Fdo: Fernando Garc´ıa Aranda Granada a 1 de diciembre de 2010.
  6. 6. D. Juan Manuel L´opez Soler, Profesor Titular del ´Area de Ingenier´ıa Telem´atica del Departamento de Teor´ıa de la Se˜nal, Telem´atica y Comuni- caciones de la Universidad de Granada. D. Javier S´anchez Monedero, Becario FPDI del Departamento de Inform´atica y An´alisis Num´erico de la Universidad de C´ordoba Informan: Que el presente proyecto, titulado Cave Canem. Plataforma exten- sible para la monitorizaci´on de sistemas y la detecci´on de intrusio- nes con DDS, ha sido realizado bajo su supervisi´on por Fernando Garc´ıa Aranda, y autorizamos la defensa de dicho proyecto ante el tribunal que corresponda. Y para que conste, expiden y firman el presente informe en Granada a 1 de diciembre de 2010. Los directores: D. Juan Manuel L´opez Soler D. Javier S´anchez Monedero
  7. 7. Agradecimientos En primer lugar quiero agradecer a Jos´e Mar´ıa y Manuela, mis padres, el apoyo, ´animo y la comprensi´on que me han dado durante los a˜nos de estudio en C´ordoba y Granada, as´ı como a la hora de emprender viajes o cualquier tipo de proyecto. En segundo lugar, agradecer los ´animos de mis amigos, Puri, que in- tent´o comprender lo que eran los punteros a funci´on para ayudarme, Paco, Dani, Manolito, Anita, Antonio, Carmen y todos los que me dejo. Gracias a los inform´aticos de C´ordoba, Manolo, Ismael, Sergio y Nacho, con los que he compartido horas de estudio y programaci´on sin los que este proyecto no habr´ıa sido posible. Gracias tambi´en a los de Granada, Juanpe y Curro, de los que nunca me cansar´e de aprender. Dar las gracias a mis tutores, Juanma y Javier, por el apoyo y tiempo dedicado, as´ı como por su inter´es en mi trabajo presente y futuro. Por ´ultimo, quiero agradecer los consejos de mi abuelo Alejandro, que durante la realizaci´on de este proyecto cumpli´o 101 a˜nos. Sinceramente gracias.
  8. 8. ´Indice general 1. Introducci´on 1 1.1. Presentaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1. Data Distribution Service (DDS) . . . . . . . . . . . . 2 1.1.2. Contextualizaci´on del proyecto . . . . . . . . . . . . . 2 1.2. Definici´on del problema . . . . . . . . . . . . . . . . . . . . . 3 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Antecedentes y estado del arte . . . . . . . . . . . . . . . . . 5 1.4.1. Antecedentes en distribuci´on de datos . . . . . . . . . 5 1.4.2. Herramientas de monitorizaci´on y detecci´on de intrusos 7 1.4.3. Aplicaciones integradoras de herramientas de monito- rizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.1. Factores dato . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.2. Factores estrat´egicos . . . . . . . . . . . . . . . . . . . 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. Especificaci´on de requisitos 17 2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 17 2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 18 3. Planificaci´on 19 4. An´alisis del sistema 23 4.1. An´alisis 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. An´alisis de la arquitectura de monitorizaci´on . . . . . . . . . 34 4.3. An´alisis del middleware . . . . . . . . . . . . . . . . . . . . . 35 i
  9. 9. ii ´INDICE GENERAL 4.3.1. Desacople en tiempo y espacio . . . . . . . . . . . . . 36 4.3.2. Filtros en la recepci´on de topics . . . . . . . . . . . . 36 4.3.3. Monitorizaci´on de eventos a trav´es del uso de listeners 37 4.3.4. Algunos par´ametros de QoS . . . . . . . . . . . . . . . 37 4.4. An´alisis 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. An´alisis del sistema de configuraci´on . . . . . . . . . . . . . . 43 4.5.1. YAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5.2. INI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.5.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.6. An´alisis de la interfaz . . . . . . . . . . . . . . . . . . . . . . 45 4.6.1. Requisitos de la interfaz . . . . . . . . . . . . . . . . . 45 4.6.2. An´alisis de los requisitos de la interfaz . . . . . . . . . 46 5. Dise˜no 47 5.1. Arquitectura del sistema de monitorizaci´on . . . . . . . . . . 47 5.1.1. Monitorizaci´on a trav´es de un sistema de plugins . . . 48 5.1.2. Despliegue del un escenario de monitorizaci´on con DDS 50 5.2. Dise˜no de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . 56 5.2.1. Diagramas de clases . . . . . . . . . . . . . . . . . . . 57 5.2.2. Modelo de interacci´on entre objetos . . . . . . . . . . 63 5.3. Dise˜no del sistema de configuraci´on . . . . . . . . . . . . . . . 68 5.3.1. El sistema de configuraci´on de CCPublisher . . . . . . 69 5.3.2. El sistema de configuraci´on de CCSubscriber . . . . . 69 5.4. Dise˜no 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. Dise˜no de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 74 5.5.1. Bocetos de la aplicaci´on web . . . . . . . . . . . . . . 74 5.5.2. Diagramas de clases . . . . . . . . . . . . . . . . . . . 77 5.5.3. Modelo de interacci´on de la interfaz . . . . . . . . . . 80 6. Implementaci´on 85 6.1. La aplicaci´on de monitorizaci´on . . . . . . . . . . . . . . . . . 85 6.1.1. Sistema de compilaci´on y organizaci´on del c´odigo . . . 86 6.1.2. N´ucleo de los subsistemas . . . . . . . . . . . . . . . . 88 6.1.3. Plugins implementados . . . . . . . . . . . . . . . . . 93
  10. 10. ´INDICE GENERAL iii 6.1.4. Sistema de configuraci´on . . . . . . . . . . . . . . . . . 98 6.1.5. Sistema de almacenamiento . . . . . . . . . . . . . . . 101 6.2. Desarrollo de un plugin sencillo en Cave Canem . . . . . . . . 103 6.2.1. Definici´on del IDL . . . . . . . . . . . . . . . . . . . . 103 6.2.2. Plugin para CCPublisher . . . . . . . . . . . . . . . . 104 6.2.3. Plugin para CCSubscriber . . . . . . . . . . . . . . . . 105 6.3. La interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . 107 6.3.1. Organizaci´on de ficheros de la interfaz de usuario . . . 107 6.3.2. Resultados de la implementaci´on de los distintos esce- narios . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7. Pruebas 111 7.1. Pruebas de unidad . . . . . . . . . . . . . . . . . . . . . . . . 111 7.1.1. Dise˜no de los casos de prueba . . . . . . . . . . . . . . 111 7.1.2. Resultados de la ejecuci´on de los casos de prueba . . . 113 7.2. Pruebas de integraci´on . . . . . . . . . . . . . . . . . . . . . . 114 8. Conclusiones y trabajo futuro 117 8.1. Principales contribuciones . . . . . . . . . . . . . . . . . . . . 117 8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Bibliograf´ıa 126 A. Manual de usuario 127 A.1. Introduci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A.2.1. Requisitos de CCPublisher . . . . . . . . . . . . . . . 128 A.2.2. Requisitos de CCSubscriber . . . . . . . . . . . . . . . 128 A.2.3. Requisitos de la interfaz web . . . . . . . . . . . . . . 128 A.3. Instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.3.1. Aplicaciones de monitorizaci´on . . . . . . . . . . . . . 129 A.3.2. Instalaci´on de la interfaz de usuario . . . . . . . . . . 130 A.4. Gu´ıa de uso de la aplicaci´on de monitorizaci´on . . . . . . . . 130 A.4.1. CCPublisher . . . . . . . . . . . . . . . . . . . . . . . 130 A.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++ 137 B.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 B.2. Polimorfismo . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B.3. dlopen() y la carga din´amica de clases . . . . . . . . . . . . 139 B.4. Autoregistro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 B.5. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 C. Glosario 151
  11. 11. ´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 monitorizaci´on 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. Revisi´on de la clase base plugin en CCPublisher . . . . . . . . 54 5.6. Revisi´on 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- rizaci´on” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 datos de monitorizaci´on” . . . . . . . . . . . . . . . . . . . . . . . . 83 6.1. Extracto de cavecanem publisher/src/Makefile.am . . . . 91 6.2. Carga de plugins a trav´es de load single library() . . . . 92 6.3. Definici´on del map de factor´ıas . . . . . . . . . . . . . . . . . 92 6.4. Instanciaci´on de plugins en CCSubscriber . . . . . . . . . . . 93 v
  12. 12. vi ´INDICE DE FIGURAS 6.5. Instanciaci´on de plugins en CCPublisher . . . . . . . . . . . . 93 6.6. Fichero de configuraci´on de CCPublisher . . . . . . . . . . . . 99 6.7. Fichero de configuraci´on de CCSubscriber . . . . . . . . . . . 100 6.8. hello world dds.idl . . . . . . . . . . . . . . . . . . . . . . 104 6.9. Implementaci´on del Plugin publicador de Hello World: fichero de cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.10. Implementaci´on del Plugin suscriptor de Hello World: fichero de cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.11. Implementaci´on del escenario “Listado de hosts” . . . . . . . 108 6.12. Implementaci´on del escenario “Estado actual de un host” . . 109 6.13. Implementaci´on del escenario “Listado completo de datos de monitorizaci´on” . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.1. Pantalla principal de la interfaz de usuario . . . . . . . . . . . 133 A.2. Informaci´on actual de un host . . . . . . . . . . . . . . . . . . 134 A.3. Informaci´on del estado de las interfaces de red de un host . . 135 A.4. Alertas de IDS recolectadas por un host . . . . . . . . . . . . 135 A.5. Informacio´n recolectada en relaci´on a datos de CPU de un host136
  13. 13. ´Indice de cuadros 3.1. Planificaci´on del proyecto: tareas . . . . . . . . . . . . . . . . 20 4.1. Plantilla para la definici´on de casos de uso . . . . . . . . . . . 25 6.1. Descripci´on de la tabla hosts . . . . . . . . . . . . . . . . . . 101 6.2. Descripci´on de la tabla ids . . . . . . . . . . . . . . . . . . . 101 6.3. Descripci´on de la tabla system monitor . . . . . . . . . . . . 102 6.4. Descripci´on de la tabla net load . . . . . . . . . . . . . . . . 102 6.5. Descripci´on de la tabla disk . . . . . . . . . . . . . . . . . . . 103 vii
  14. 14. Cap´ıtulo 1 Introducci´on 1.1. Presentaci´on La sustituci´on progresiva de los modelos de computaci´on centralizados por entornos distribuidos ha convertido la monitorizaci´on eficiente de siste- mas en un proceso crucial en la gesti´on de servicios en red y por tanto, en un aspecto clave en el desarrollo de la denominada sociedad de la informaci´on. Hoy en d´ıa existen multitud de herramientas de amplia difusi´on que, ma- nejadas por los administradores de sistemas, se encargan de cubrir aspectos como la detecci´on de intrusos, el an´alisis de vulnerabilidades, la monitoriza- ci´on de eventos, etc. Se presentan, de esta forma, una serie de aplicaciones aisladas que, en combinaci´on, ayudan a controlar el rendimiento adecuado de un sistema en red y de la misma red. Estas circunstancias implican la existencia de multitud de sistemas de notificaci´on, administraci´on y visua- lizaci´on, complicando en gran manera la gesti´on eficiente de la informaci´on recolectada. En este contexto, se hace necesario el desarrollo de una plataforma in- tegradora capaz de normalizar y distribuir la informaci´on generada por este tipo de herramientas, ofreciendo un entorno informativo ´unico que permita al administrador la interpretaci´on de ´esta, de forma conjunta, propiciando la detecci´on temprana de anormalidades y el desempe˜no m´as eficiente de su labor. La difusi´on normalizada de informaci´on por la red ser´a, por tanto, uno de los aspectos fundamentales en este proyecto. Existen diferentes tecnolog´ıas para dar soporte a la transmisi´on de informaci´on en aplicaciones con re- querimientos muy distintos. Estas tecnolog´ıas proporcionan funcionalidades orientadas a solucionar problemas generales en el desarrollo de aplicaciones distribuidas, liberando al programador de tareas comunes en este tipo de software, para que ´este pueda centrarse en lo espec´ıfico del proyecto. Por lo 1
  15. 15. 2 1.1. Presentaci´on general, estas tecnolog´ıas entran dentro del concepto de middleware. 1.1.1. Data Distribution Service (DDS) La notificaci´on de alertas y mensajes de monitorizaci´on, as´ı como la detecci´on de intrusos requiere, en ocasiones, cumplir requisitos estrictos de eficiencia, determinismo, seguridad, fiabilidad y gesti´on de errores. Una de las soluciones dise˜nadas para satisfacer tales restricciones es la tecnolog´ıa DDS. DDS son las siglas del est´andar Data Distribution Service for Real-Time Systems o servicio de distribuci´on de datos para sistemas de tiempo real [1], mantenido por la OMG (Object Management Group) [2]. DDS es el primer est´andar internacional abierto que especifica un modelo de publica- ci´on/subscripci´on para sistemas de tiempo real y sistemas empotrados. Las implementaciones m´as conocidas son RTI Data Distribution Sercice [3] de Real-Time Innovations [4], OpenSplice [5] de PrismTech [6] y OpenDDS [7] de la empresa Object Computing [8]. Puede consultarse informaci´on acer- ca de ´estas y otras implementaciones en el portal web sobre DDS [9] que mantiene 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 paradigma publicaci´on/suscripci´on, permitiendo a un proceso en un entorno distribuido compartir datos independientemente de la localizaci´on f´ısica o la arquitec- tura del resto de procesos. Esta adopci´on pura del est´andar de DDS [1] se distingue del modelo seguido en otras implementaciones como OpenSplice, que realiza su comunicaci´on a trav´es del demonio ospl [5]. Adem´as, el middle- ware proporciona soporte para comunicaciones deterministas (best-effort) y comunicaciones fiables (reliable), incluyendo comunicaciones fiables basadas en multidifusi´on (multicast). 1.1.2. Contextualizaci´on del proyecto Este proyecto ha sido desarrollado en el Departamento de Teor´ıa de la Se˜nal, Telem´atica y Comunicaciones (TSTC) de la Universidad de Gra- nada. ´Este colabora, a trav´es de contratos de transferencia, con la empresa Real-Time Innovations, Inc (RTI)1, formando parte adem´as de programa su programa de universidades (Real-Time Innovations University Program)2. Por lo tanto, se dispone de licencias de desarrollo gratuitas del middleware RTI Data Distribution Service. 1 http://www.rti.com/ 2 http://www.rti.com/corporate/university.html
  16. 16. Introducci´on 3 1.2. Definici´on del problema La utilizaci´on de distintas herramientas de monitorizaci´on y detecci´on de intrusos en una red implica el manejo de un conglomerado heterog´eneo de sistemas de notificaci´on, interfaces de visualizaci´on y herramientas de con- figuraci´on. Esta circunstancia complica en gran manera la gesti´on eficiente de la informaci´on. Partiendo de este problema, el presente proyecto se enfoca en el dise˜no e implementaci´on de un sistema escalable capaz de procesar y difundir, de forma 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 difusi´on de la informaci´on. La escalabilidad del sistema est´a relacionada con la necesidad de pro- porcionar una arquitectura extensible, que garantice la incorporaci´on sucesiva de m´odulos que interpreten la informaci´on de nuevas herra- mientas, proporcionando un entorno flexible tanto al programador co- mo al administrador. Las circunstancias de difusi´on de la informaci´on hacen referencia a las necesidades de transmisi´on eficiente y normalizada de la misma. Se busca garantizar una difusi´on flexible, dependiendo de las exigencias del tipo de mensaje, tanto en la propia estructura del mismo como en las caracter´ısticas de su transmisi´on. Adem´as de estas cuestiones fundamentales, el proyecto deber´a dar so- luci´on, a lo largo del desarrollo del mismo, a dos aspectos que van de la mano de lo mencionado anteriormente. El primero hace referencia a las ca- pacidades de configuraci´on del sistema y el segundo a la visualizaci´on de la informaci´on difundida. El administrador del sistema necesitar´a realizar un ajuste de los distin- tos par´ametros de la aplicaci´on, para adaptar ´esta a sus necesidades. La soluci´on deber´a proporcionar, por lo tanto, la mayor flexibilidad a ´este para la realizaci´on de una monitorizaci´on de servicios eficiente. El ´ultimo problema fundamental a tratar ser´a la visualizaci´on de la informaci´on difundida. Como se coment´o anteriormente, se presenta un sistema que necesita unificar informaci´on de diverso tipo y proce- dencia. Esta circunstancia demanda el dise˜no e implementaci´on de una interfaz flexible que, de forma sencilla, proporcione al administrador la informaci´on que necesita.
  17. 17. 4 1.3. Objetivos 1.3. Objetivos Una vez realizada una primera definici´on del problema, en este apartado se detallan los objetivos perseguidos a trav´es de la realizaci´on del proyecto. Estudio de diferentes herramientas de monitorizaci´on y de- tecci´on de intrusos. Se pretende realizar un estudio que cubra la funcionalidad b´asica de este tipo de herramientas, su administraci´on y el modo en el que tratan la informaci´on generada. Este estudio pretende seleccionar un conjunto id´oneo de herramientas, utilizadas de forma com´un por administrado- res de sistemas, de forma que a trav´es de la plataforma de gesti´on de la informaci´on, se centralice el tratamiento de todos los eventos y alertas que ´estas generen, garantizando as´ı un acceso sencillo e intuitivo a la misma. Construcci´on de un sistema escalable para el tratamiento y difusi´on de mensajes y eventos basado en una arquitectura de plugins. La aplicaci´on a desarrollar deber´a basarse en un dise˜no extensible, que proporcione interfaces de programaci´on sencillas para la incorporaci´on progresiva de funcionalidad. De esta forma, se busca la definici´on de una arquitectura de plugins, m´odulos que trabajar´an directamente con los eventos generados por las diferentes aplicaciones o sistemas. Integraci´on progresiva de herramientas de monitorizaci´on y de detecci´on de intrusos a trav´es del sistema de plugins. Se deber´an desarrollar una serie de plugins para cubrir la funcionalidad aportada por las herramientas seleccionadas en el estudio del primer objetivo. Este desarrollo deber´a partir de una buena definici´on de la arquitectura, siendo ´esta la base de la implementaci´on de un sistema sencillo y escalable. Establecimiento de un sistema intuitivo de configuraci´on. La aplicaci´on deber´a incorporar un sistema de configuraci´on intuitivo que permita adaptar la plataforma a distintas circunstancias. Se de- ber´an poder establecer par´ametros propios a cada plugin, adem´as de una serie de criterios gen´ericos de la aplicaci´on. Desarrollo de una interfaz para la visualizaci´on actualizada de informaci´on y el an´alisis de la misma. Adem´as de los objetivos relacionados con las caracter´ısticas intr´ınsecas de funcionamiento, estructura y configuraci´on del sistema, habr´a que
  18. 18. Introducci´on 5 tener en cuenta el modo en el que se presenta la informaci´on recolecta- da. Se deber´a proporcionar al administrador una herramienta para la visualizaci´on y el an´alisis de la informaci´on generada por los sensores de monitorizaci´on y de detecci´on de intrusos. El objetivo fundamental es que el administrador pueda acceder de forma sencilla a ´esta, permi- tiendo el conocimiento general del estado de las m´aquinas en la red, para su actuaci´on frente a posibles problemas que pudieran surgir a lo largo del tiempo. 1.4. Antecedentes y estado del arte Como se ha mencionado en la definici´on del problema, se plantea el desarrollo de una herramienta para la integraci´on de la distribuci´on y visua- lizaci´on de alertas generadas por distintas aplicaciones de monitorizaci´on de sistemas y de detecci´on de intrusos. De este modo, la evaluaci´on de antecedentes y del estado del arte de- ber´a fijar su foco en dos tem´aticas fundamentales: la elecci´on de un sistema de distribuci´on y tratamiento de informaci´on, con el objetivo de gestionar y distribuir los datos generados por los distintos sensores; y la valoraci´on de las distintas herramientas susceptibles de integrarse en el sistema. Por ´ultimo, se incluir´an algunos ejemplos de aplicaciones que han basado su funciona- miento en la integraci´on de sistemas de monitorizaci´on y de detecci´on de intrusos de terceros. 1.4.1. Antecedentes en distribuci´on de datos Paradigma cliente/servidor El desarrollo de aplicaciones distribuidas ha merecido grandes esfuerzos de investigaci´on en las ´ultimas d´ecadas. Entre las herramientas desarrolladas en este contexto, es de especial inter´es la API3 Berkeley Socket Distribution [10]. A partir de la implementaci´on de ´esta, se han propuesto numerosos middleware especificados con el objetivo de simplificar los costes de desarro- llo, optimizar las prestaciones y utilizaci´on de los recursos de la red, ofrecer mayor 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 ejecuci´on de procedimientos remotos, merce una menci´on especial. 3 Siglas de Application programming interface, Interfaz de programaci´on de aplicacio- nes. Se trata de un conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a servicios desde los procesos y representa un m´etodo para conseguir abstracci´on en la programaci´on.
  19. 19. 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 hace uso del protocolo HTTP para el transporte de transacciones. El intercambio de mensajes basados en XML sobre HTTP [12] ha dado lugar al protocolo SOAP (Simple Object Access Protocol) [13], parte fun- damental de la pila de protocolos que da soporte a los as´ı denominados Web Services [14], definidos por el consorcio W3C. En esta aproximaci´on, se utiliza WSDL (Web Services Description Language) [15] para describir la interfaz a los objetos remotos. Es tambi´en destacable la API RMI (Remote Method Invocation) [16] para Java, la cual proporciona una funcionalidad parecida a la de RPC. Finalmente, no puede faltar una menci´on a la arquitectura CORBA (Common Object Request Broker Architecture) [17] definida por el consorcio OMG. CORBA proporciona una aproximaci´on basada en objetos, accesibles de forma remota a trav´es de la interfaz IDL (Interface Definition Language) [18]. El paradigma publicador/suscriptor Todas las tecnolog´ıas anteriormente citadas tienen en com´un la adop- ci´on del as´ı denominado paradigma cliente/servidor. Alternativamente, y especialmente dise˜nado para su utilizaci´on en aplicaciones con requisitos de tiempo real, se ha propuesto un middleware que adopta un paradigma dis- tinto al anterior basado en una metodolog´ıa de publicaci´on/suscripci´on. Este modelo se fundamenta en el intercambio as´ıncrono de mensajes. Aqu´ı, las entidades generadoras declaran una serie de topics4 que est´an dispuestas a publicar y las consumidoras se suscriben a distintos topics de su inter´es. De este modo, cuando un productor publica un dato con una tem´atica concreta, todos los suscriptores de ´esta lo reciben de forma transparente a la aplica- ci´on. El paradigma adopta una aproximaci´on denominada data centric, ya que desacopla (en el tiempo y el espacio) la interacci´on entre los partici- pantes (consumidores o generadores de informaci´on), y enfoca su esfuerzo en la distribuci´on de los datos, con independencia de la localizaci´on y el instante de origen o destino de los mismos. Para la distribuci´on de infor- maci´on de acuerdo con el paradigma publicaci´on/suscripci´on, la OMG ha especificado recientemente el est´andar DDS [1] lo que, dada la solvencia y reconocimiento de esta instituci´on, ha venido a consolidar definitivamente este nuevo paradigma como modelo de interacci´on alternativo. De los modelos comentados anteriormente, el que mejor se adapta a la plataforma a implementar es el paradigma de publicaci´on/suscripci´on. De 4 Se utiliza el t´ermino ingl´es topic al tratarse del nombre de la entidad DDS. Dicho t´ermino podr´ıa traducirse como tema o tem´atica.
  20. 20. Introducci´on 7 acuerdo con este modelo, las aplicaciones de monitorizaci´on y de detecci´on podr´ı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 elecci´on del est´andar DDS de la OMG para el desarrollo del proyecto garantiza las siguientes ventajas de acuerdo con [19]: 1. ´Este proporciona un paradigma conceptualmente sencillo como es pu- blicaci´on/suscripci´on. 2. Es escalable din´amicamente. 3. Soporta comunicaciones de uno a uno, de uno a muchos o de muchos a muchos. 4. Facilita al desarrollador enormemente la tarea de implementaci´on de aplicaciones para la distribuci´on de datos. 1.4.2. Herramientas de monitorizaci´on y detecci´on de intru- sos Una vez definido el sistema de distribuci´on de datos para el desarrollo de la plataforma es necesario seleccionar una serie de herramientas de mo- nitorizaci´on y de detecci´on de intrusos susceptibles de ser integradas en el proyecto. ´Estas se clasificar´an de acuerdo con las categor´ıas establecidas en Pardo-Castellote et al. [20]. Sistemas de detecci´on de intrusos Snort. Es un sistema de detecci´on y prevenci´on de intrusos (IDS)5 ca- paz de realizar an´alisis en tiempo real sobre redes IP [21]. ´Este incluye un sistema de reglas flexible, que permite dise˜nar filtros o acciones ante determinados eventos. La instalaci´on de Snort proporciona reglas para ataques web, backdoor, Nmap, finger, CGI, etc. La base de datos de ataques de Snort se actualiza de forma constante, admiti´endose la inclusi´on de reglas por parte de usuarios a trav´es de la lista de correo de firmas de Snort. Adem´as, existen extensiones que permiten la utilizaci´on de ´este con preprocesadores capaces de detectar anomal´ıas en el tr´afico, como es el caso de SPADE. 5 Se pueden clasificar los detectores de intrusos en tres tipos: (1) Host IDS (HIDS), donde los sensores se encuentra en cada m´aquina, y por lo tanto vigilan ´unicamente dicha m´aquina, caso de OSSEC; (2) Network IDS (NIDS), donde los sensores se encuentran en segmentos de red, vigilando el tr´afico de la misma, caso de Snort; y (3) Distributed IDS (DIDS), donde una serie de NIDS se comunican mediante un sensor central.
  21. 21. 8 1.4. Antecedentes y estado del arte OSSEC. Se trata de un detector de intrusos en host (HIDS). Propor- ciona, entre otras, las funcionalidades de an´alisis de logs, verificaci´on de integridad de ficheros, monitorizaci´on del registro de Windows o la detecci´on de rootkits6 en tiempo real, permitiendo configurar respues- tas activas [22]. Escaneo de vulnerabilidades Nessus. Se trata de una aplicaci´on para la detecci´on de vulnerabilida- des. Est´a compuesta por un demonio, nessusd, que realiza el escaneo de un sistema objetivo; y un cliente, nessus, que muestra el avance y las conclusiones del proceso. Sus resultados pueden almacenarse en multitud de formatos, permiti´endose la toma en consideraci´on de ´estos en futuros an´alisis de vulnerabilidades [23]. Nmap. Es una aplicaci´on para la exploraci´on de la red y la auditor´ıa de seguridad. Permite el descubrimiento de m´aquinas activas en la red, el escaneo de puertos de una m´aquina objetivo, los servicios que se est´an ejecutando en la misma o el sistema operativo que utiliza [24]. Saint Scanner. Es una herramienta para la identificaci´on 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, anticip´andose a posibles intrusos [25]. Sniffers Wireshark. Es un analizador de protocolos, se trata de una herra- mienta muy utilizada para el an´alisis y resoluci´on de problemas en redes de comunicaciones. A˜nade numerosas opciones de organizaci´on y filtrado de informaci´on, permitiendo la visualizaci´on de todo el tr´afi- co que pasa a trav´es de la red una vez establecida la configuraci´on de la interfaz en modo promiscuo [26]. Kismet. Es un detector de redes, husmeador de paquetes (sniffer) y detector de intrusos para redes LAN inal´ambricas 802.11. Realiza un funcionamiento pasivo, es decir, permite la detecci´on de puntos de acceso, clientes inal´ambricos y su asociaci´on, sin el env´ıo de paquetes detectables. Funciona en cualquier tarjeta que soporte el modo monitor raw [27]. 6 Un rootkit es una herramienta, o grupo de herramientas, que tiene la finalidad de esconder programas, procesos, archivos, directorios, claves de registro o puertos que per- miten a un intruso acceder a un sistema de forma remota.
  22. 22. Introducci´on 9 OS fingerprinting e identificaci´on de servicios P0f. Se trata de una herramienta de identificaci´on pasiva de sistema operativo. Permite detectar el sistema y la versi´on de las m´aquinas conectadas a un equipo, con las que se establece una conexi´on, o sobre las que se puede examinar el tr´afico. P0f permite adem´as detectar la distancia f´ısica a un sistema remoto, detectar la existencia de balanceadores de carga o de firewalls. Esta aplicaci´on no genera tr´afico en la red, lo que permite identificar el sistema de equipos detr´as de un cortafuegos [28]. Monitorizaci´on de sistemas Ganglia. Es una herramienta escalable de monitorizaci´on de sistemas de altas prestaciones como clusters o grids. Permite al usuario exami- nar estad´ısticas como, por ejemplo, la carga de CPU o la utilizaci´on de la red en una serie de m´aquinas. Utiliza dos demonios, gmond, que se ejecuta en cada uno de los nodos del cluster que se desea monitorizar; y gmetad, que obtiene informaci´on v´ıa XML a intervalos regulares de tiempo desde los nodos, almacenan- do la informaci´on en una base de datos Round-Robin7 [29]. LibGTop. Es una biblioteca para la monitorizaci´on de sistemas que forma parte del proyecto GNOME. ´Esta permite, a trav´es de una serie de funciones definidas en la misma, acceder a datos de un host como la carga de CPU, la ocupaci´on del disco duro, memoria principal y swap, adem´as de informaci´on relativa al uso de las distintas interfaces de red del mismo [30]. 1.4.3. Aplicaciones integradoras de herramientas de monito- rizaci´on Nagios Nagios es un sistema de monitorizaci´on de redes ampliamente utilizado [31]. Proporciona informaci´on acerca de una serie de recursos de diferentes m´aquinas como la carga del procesador, la utilizaci´on del disco o la ocupa- ci´on de la memoria principal; as´ı como de servicios de red, entre los que se 7 En concreto utiliza RRDtool, una herramienta que trabaja con una base de datos con planificaci´on Round-Robin. Se trata de una aplicaci´on utilizada en otros sistemas de monitorizaci´on como Munin. Se tratar´a este tipo de almacenamiento con un mayor nivel de detalle en el apartado 4.4.4.
  23. 23. 10 1.4. Antecedentes y estado del arte encuentran SMTP, POP3, HTTP o PING. No obstante, su verdadero poten- cial recae en la escalabilidad de la plataforma. ´Esta implementa un sistema de plugins que le permite recolectar informaci´on de cualquier tipo a trav´es de la utilizaci´on del complemento adecuado. El sistema permite dos tipos de comunicaciones: modo cliente, estable- ci´endose conexiones SSL entre Nagios y sistemas de monitorizaci´on remotos; y modo servidor, recibiendo de forma pasiva los resultados de los diferentes nodos de monitorizaci´on. AlienVault OSSIM OSSIM (Open Source Security Information Management) [32] es una co- lecci´on de herramientas dise˜nadas para la gesti´on de la seguridad en sistemas a trav´es de la detecci´on y la prevenci´on de intrusos. Por tanto, a diferencia del caso anterior, esta plataforma est´a enfocada en la seguridad de redes en lugar de en la monitorizaci´on de sistemas. OSSIM incluye herramientas como Snort o Nessus para la detecci´on de intrusiones, P0f para el an´ali- sis de los sistemas de la red o Ntop para la detecci´on de comportamientos an´omalos. No obstante, la colecci´on de herramientas incluye la capacidad de recolecci´on de informaci´on de sistemas de monitorizaci´on como Nagios. La estructura de OSSIM integra una base de datos para el almacena- miento de informaci´on, diferentes agentes para la recolecci´on de datos y un servidor para procesar la informaci´on recolectada. Adem´as, ´esta incorpora un motor de correlaci´on que permite la actuaci´on de OSSIM como sistema de prevenci´on de intrusos. MonAMI MonAMI es un framework para la recopilaci´on y difusi´on de informaci´on procedente de distintos sensores y sistemas [33]. Su implementaci´on se basa en el establecimiento de un demonio de monitorizaci´on para la recolecci´on de datos procedentes de distintos objetivos a trav´es de una arquitectura de plugins, permitiendo la inclusi´on de funcionalidad de forma progresiva. En- tre los plugins de monitorizaci´on se implementa el control de aplicaciones como Apache HTTP, MySQL, Torque, Apache Tomcat o Disk Pool Manager (DPM). Adem´as, el sistema ofrece diferentes alternativas para la difusi´on de la informaci´on de monitorizaci´on recogida, entre ´estas se encuentra la utili- zaci´on de ficheros de log, bases de datos MySQL o el sistema de visualizaci´on de Ganglia y GridView.
  24. 24. Introducci´on 11 Pandora FMS Pandora FMS (Flexible Monitoring System) es una aplicaci´on para la monitorizaci´on de todo tipo de sistemas y aplicaciones [34]. Permite cono- cer el estado de cualquier elemento hardware, de aplicaciones o del sistema operativo, recolectando informaci´on incluso a trav´es del protocolo SNMP (Simple Network Monitoring Protocol), lo que le permite recibir informa- ci´on de cualquier dispositivo que utilice ´este. La aplicaci´on utiliza el paradigma cliente/servidor, examinando la infor- maci´on a trav´es del uso de agentes de monitorizaci´on. Este sistema es muy flexible e incluye agentes incluso para el acceso a datos procedente de Na- gios. La informaci´on recolectada por ´estos es almacenada, finalmente, por servidor de Pandora FMS en una base de datos. 1.5. Restricciones A continuaci´on se exponen una serie de restricciones, o factores limita- tivos, existentes en el ´ambito del dise˜no e implementaci´on de la aplicaci´on, que condicionan la selecci´on 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 tendr´an en cuenta los siguientes: Aspectos Econ´omicos En relaci´on al apartado econ´omico, 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 el proyecto debe estar finalizado antes de diciembre de 2010. Hardware Para el desarrollo y simulaci´on del sistema se contar´a con: Dos ordenadores personales pertenecientes al autor del proyecto. Una red LAN gestionada a trav´es de la conexi´on de dispositivos a un router WIFI de 4 puertos 10/100 Mbit/s. Software Dentro de los aspectos software se deber´an considerar algunas circunstancias relacionadas con la plataforma de desarrollo. El pro- yecto deber´a tener en cuenta las arquitecturas, sistemas operativos
  25. 25. 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 trabajar´a con las plataformas soportadas por el middleware i64Linux2.6gcc4.3.2 e i86Linux2.6gcc4.1.2.tar.gz, para arquitecturas x86 y x86 64 sobre GNU/Linux, respectivamente. Humanos En el desarrollo del proyecto participar´an un alumno y los dos directores del proyecto. 1.5.2. Factores estrat´egicos Los factores estrat´egicos son factores que no dependen de la naturaleza del problema, permitiendo tomar decisiones entre diversas alternativas con la mejora de aspectos como los costes, la calidad o la escalabilidad del proyecto en mente. Para este proyecto, se consideran como decisiones estrat´egicas: Plataforma de desarrollo Se escoge GNU/Linux como plataforma para el desarrollo debido a la libertad que ofrece al programador y la gran cantidad de herramientas que se proporcionan para ´este. El RTI Data Distribution Service soporta este sistema, por lo que se podr´an utilizar las herramientas y bibliotecas del mismo sin ning´un problema. Entorno de programaci´on Se ha elegido el entorno de desarrollo libre para C/C++, Eclipse C/C++ Development Tooling - CDT. Eclipse es un entorno de desarrollo que proporciona, adem´as de herramien- tas para la edici´on y gesti´on de c´odigo, una buena integraci´on con el depurador libre GDB, la herramienta GNU Make y el compilador GCC. Depuraci´on de errores y rendimiento Se incluir´an opciones de compi- laci´on condicional para activar mensajes de depuraci´on en el c´odigo con el objetivo de detectar y corregir errores tanto en la etapa de desarrollo, como en la de mantenimiento del software. Adem´as, se uti- lizar´a la herramienta Valgrind para examinar la correcta liberaci´on de recursos, comprobando as´ı el uso eficiente de la memoria por parte de la aplicaci´on. 1.6. Recursos A continuaci´on se describir´an los recursos necesarios para el desarrollo del proyecto. Se diferenciar´an ´estos en funci´on de su condici´on, es decir, recursos humanos, hardware y software.
  26. 26. Introducci´on 13 1.6.1. Humanos Prof Dr. Juan Manuel L´opez Soler. Profesor del Departamento de Teor´ıa de Se˜nal, Telem´atica y Comunicaciones de la Universidad de Granada, como tutor del proyecto. D. Javier S´anchez Monedero. Becario FPDI del Departamento de In- form´atica y An´alisis Num´erico de la Universidad de C´ordoba, como co-tutor del proyecto. D. Fernando Garc´ıa Aranda. Alumno de Ingenier´ıa de Inform´atica de la Escuela T´ecnica Superior de Ingenier´ıas Inform´atica y de Teleco- municaci´on de la Universidad de Granada, que ser´a el encargado de realizar el proyecto siguiendo las directrices definidas por los tutores del 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), 2 GHz, 4 MB de memoria cach´e, 2 GB de memoria RAM y 120 GB de disco duro. Ordenador PC sobremesa, con procesador Intel Core I3, 2.8 GHz, 4MB de memoria cach´e, 4 GB de memoria RAM y 1 TB de disco duro. Router WIFI Xavi 7868r. 1.6.3. Software Los recursos software ser´an: Ubuntu Linux 10.04 y 10.10, distribuci´on de GNU/Linux bajo la que realizar´a el desarrollo principal de la soluci´on. Adem´as, se probar´a el correcto funcionamiento de la aplicaci´on en Fedora y CentOS. Entorno de desarrollo integrado para C/C++ Eclipse C/C++ Deve- lopment Tooling - CDT. Planner, herramienta para la gesti´on y seguimiento de proyectos. Colecci´on de Compiladores de GNU (GCC), que incluye los compila- dores de C y C++ que utilizaremos.
  27. 27. 14 1.7. Fases de desarrollo GNU build system o Autotools, herramienta muy utilizada en proyectos de software libre para la generaci´on autom´atica de ficheros Makefile adaptados a cada sistema, generaci´on y mantenimiento de traducciones con Gettext, an´alisis de dependencias, etc. Depurador GDB. Valgrind como herramienta de depuraci´on de problemas de memoria y de rendimiento de programas. Doxygen, generador multilenguaje para la documentaci´on del c´odigo fuente de la aplicaci´on. VirtualBox, software de virtualizaci´on para la realizaci´on de pruebas con diferentes m´aquinas en una red. Biblioteca de distribuci´on 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 editor de textos GEdit. 1.7. Fases de desarrollo Para el desarrollo de este proyecto se han considerado una serie de fases bien diferenciadas Definici´on del proyecto En esta fase se realizar´a una primera aproxima- ci´on a la problem´atica a la que se quiere dar soluci´on. De esta forma, se valorar´a el contexto actual y se establecer´a una primera definici´on formal del proyecto. Especificaci´on de requisitos Se trata de delimitar la definici´on del pro- yecto realizada anteriormente. Para ello, se identificar´an los objetivos y se capturar´an los requerimientos funcionales y no funcionales del sistema. Revisi´on del estado del arte En esta fase se realizar´a un estudio de las partes fundamentales en el desarrollo de la aplicaci´on final: Se deber´a realizar una revisi´on de las tecnolog´ıas relacionadas con DDS, as´ı como las diferentes implementaciones disponibles del est´andar.
  28. 28. Introducci´on 15 Se examinar´an soluciones previas que se acerquen a la definici´on del problema desarrollada anteriormente, observ´andose solucio- nes disponibles para la monitorizaci´on de eventos y la detecci´on de intrusos en sistemas en red. Con objeto de analizar la implementaci´on un sistema que inte- gre herramientas de forma escalable, se estudiar´an bibliotecas y t´ecnicas de implementaci´on de sistemas de plugins. Por ´ultimo, se examinar´an diferentes soluciones para la notifica- ci´on de eventos a usuarios. An´alisis del sistema En esta fase se analizar´an los requerimientos para sentar las bases de una soluci´on al problema, incluy´endose la identifi- caci´on a alto nivel de las necesidades del sistema. Dise˜no del sistema Esta etapa incluir´a el dise˜no arquitect´onico del siste- ma, la especificaci´on de operaciones, el diagrama de clases del mismo, etc. Implementaci´on Se implementar´an los modelos descritos en las fases an- teriores. Pruebas Durante esta fase se evaluar´an las prestaciones de las herramientas desarrolladas a trav´es de su ejecuci´on en entornos reales, valorando especialmente su flexibilidad. Revisi´on del trabajo Se realizar´a una revisi´on del trabajo documental generado a lo largo de las fases anteriores, de la que resultar´a un ma- nual t´ecnico final. Adem´as, se obtendr´an una serie de conclusiones y se establecer´an las bases y v´ıas para futuros trabajos.
  29. 29. Cap´ıtulo 2 Especificaci´on de requisitos El objetivo de este cap´ıtulo es identificar el conjunto de requerimientos que el sistema debe cumplir. 2.1. Requisitos funcionales Son aquellos que se encuentran orientados a la funcionalidad que debe desempe˜nar la aplicaci´on de cara al usuario final. Entre ´estos se identifican: Construcci´on de un entorno extensible Implementaci´on de una arqui- tectura de plugins que proporcione una interfaz sencilla para la incor- poraci´on progresiva de funcionalidad a la aplicaci´on. Implementaci´on de plugins Inclusi´on sucesiva de plugins para el tra- tamiento de la informaci´on generada por diferentes herramientas de monitorizaci´on y de detecci´on de intrusos. Definici´on de pol´ıticas de Calidad de Servicio (QoS) Se deber´a in- corporar a la aplicaci´on la posibilidad de establecer una serie de pol´ıti- cas de QoS para la transmisi´on de la informaci´on generada por los diferentes sensores. Definici´on de una interfaz para la administraci´on Se deber´a imple- mentar una interfaz para el establecimiento de las diferentes pol´ıticas de emisi´on de informaci´on. De forma complementaria, se deber´a cons- truir un entorno que muestre la informaci´on recogida por los suscrip- tores de los diferentes sensores de la red. Definici´on de un sistema de configuraci´on La aplicaci´on deber´a incluir un sistema de configuraci´on intuitivo para la adaptaci´on del funciona- miento de la aplicaci´on a las necesidades del administrador. 17
  30. 30. 18 2.2. Requisitos no funcionales 2.2. Requisitos no funcionales Se orientan al funcionamiento final de la aplicaci´on. Se trata de requi- sitos que no tienen que ver con la funcionalidad de ´esta, sino que, como se observar´a m´as adelante, est´an orientados a caracter´ısticas que debe cumplir el funcionamiento de la misma. Entre ´estos se incluyen: Portabilidad Se deber´a adoptar una soluci´on lo suficientemente portable para permitir su uso en sistemas GNU/Linux, compilando tanto para arquitecturas x86 como para x86 64. Rendimiento y consumo de recursos La creaci´on de entidades DDS, hebras, etc. conllevar´a la asignaci´on y liberaci´on constante de recur- sos. ´Esta deber´a realizarse de forma eficiente, para no degradar las prestaciones de la m´aquina donde se ejecuta el proceso. Facilidad de instalaci´on El proceso de instalaci´on del sistema deber´a ser sencillo, siendo equivalente al de otras aplicaciones en GNU/Linux. Transparencia y abstracci´on Deber´a abstraerse al m´aximo al usuario administrador de tareas de programaci´on, creaci´on de entidades DDS, etc.
  31. 31. Cap´ıtulo 3 Planificaci´on A partir de las fases del proyecto definidas en el cap´ıtulo de introducci´on, se presenta una estimaci´on inicial de las tareas en las que se descompondr´a el desarrollo del mismo. La planificaci´on del proyecto se gestiona con ayuda de la aplicaci´on libre Planner [35]. ´Esta proporciona un entorno de gesti´on de tareas sencillo que permite: 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 asignaci´on temporal a las tareas defini- das en el apartado 1.7. En la Figura 3.1 se muestra el diagrama de Gantt correspondiente a dicha asignaci´on. 19
  32. 32. 20 Tarea Inicio Fin D´ıas 1. Definici´on del proyecto 1 dic 11 dic 9 d´ıas 1.1 Descripci´on del problema 1 dic 4 dic 4 d´ıas 1.2 Definici´on de objetivos y restricciones 7 dic 11 dic 5 d´ıas 2. Especificaci´on de requisitos 14 dic 18 dic 5 d´ıas 2.1 Elaboraci´on del documento 14 dic 18 dic 5 d´ıas 3. Revisi´on del estado del arte 21 dic 15 ene 39 d´ıas 3.1 Investigaci´on de soluciones previas 21 dic 1 ene 10 d´ıas 3.2 Investigaci´on de componentes software 4 ene 15 ene 29 d´ıas 3.2.1 Bibliotecas y t´ecnicas de plugins 4 ene 15 ene 10 d´ıas 3.2.2 Bibliotecas de monitorizaci´on 4 ene 15 ene 10 d´ıas 3.2.3 Bibliotecas de notificaci´on 4 ene 15 ene 9 d´ıas 4. An´alisis del sistema 25 feb 18 mar 16 d´ıas 4.1 Modelado est´atico 15 feb 5 mar 7 d´ıas 4.2 Modelado din´amico 8 mar 16 mar 2 d´ıas 4.3 Revisi´on del documento 17 mar 18 mar 2 d´ıas 5. Dise˜no 19 mar 16 abr 21 d´ıas 5.1 Modelado est´atico 15 feb 5 mar 7 d´ıas 5.2 Modelo de interacci´on 30 mar 6 abr 6 d´ıas 5.3 Diagrama de clases 7 abr 14 abr 6 d´ıas 5.4 Revisi´on del documento 15 abr 16 abr 2 d´ıas 6. Implementaci´on 1 jul 13 oct 75 d´ıas 6.1 Demonio (CCPublisher) 1 jul 25 ago 40 d´ıas 6.1.1. Sistema de plugins 1 jul 12 jul 8 d´ıas 6.1.2. Integraci´on de DDS 13 jul 19 jul 5 d´ıas 6.1.3. Desarrollo de plugins 20 jul 16 ago 20 d´ıas 6.1.4. Ficheros de configuraci´on 17 ago 25 ago 7 d´ıas 6.2 Programa cliente (CCSubscriber) 26 ago oct 7 31 d´ıas 6.2.1. Sistema de plugins 26 ago 2 sep 6 d´ıas 6.2.2. Integraci´on de DDS 3 sep 9 sep 5 d´ıas 6.2.3. Desarrollo de plugins 10 sep 23 sep 10 dias 6.2.4. Interfaz 24 sep 7 oct 10 d´ıas 6.3. Empaquetado de los programas 8 oct 13 oct 4 d´ıas 7. Pruebas 14 oct 27 oct 10 d´ıas 7.1. Realizaci´on de pruebas 14 oct 20 oct 5 d´ıas 7.2. Revisi´on de errores 21 oct 27 oct 5 d´ıas 8. Revisi´on del trabajo 28 oct 8 nov 8 d´ıas 8.1. Revisi´on de la documentaci´on 28 oct 3 nov 5 d´ıas 8.2. Obtenci´on de conclusiones 4 nov 8 nov 3 d´ıas Cuadro 3.1: Planificaci´on del proyecto: tareas
  33. 33. Planificaci´on 21 Figura 3.1: Diagrama de Gantt
  34. 34. Cap´ıtulo 4 An´alisis del sistema Una vez descrito el problema a trav´es de la identificaci´on de requisitos, el siguiente paso ser´a la realizaci´on de un an´alisis detallado de los mismos. De este modo, utilizando el Lenguaje Unificado de Modelado (UML), se identificar´an y describir´an de forma gr´afica y textual los distintos casos de uso del sistema, se examinar´an los subsistemas funcionales a trav´es de diagramas de paquetes y se analizar´a la interacci´on entre los distintos objetos del sistema mediante el uso de diagramas de secuencia. Adem´as, se realizar´a un an´alisis de los distintos elementos que com- pondr´an el sistema: la arquitectura de monitorizaci´on, el middleware, los sistemas de almacenamiento y configuraci´on y la interfaz de usuario. 4.1. An´alisis de requisitos 4.1.1. Casos de uso del sistema Los casos de uso proporcionan escenarios para describir, a grandes rasgos, la interacci´on entre el sistema a implementar y distintos usuarios o sistemas ajenos. En este apartado se identificar´an los actores involucrados en el sis- tema que se pretende desarrollar, definiendo el diagrama de casos de uso que genera la interacci´on de ´estos con el sistema, as´ı como una descripci´on detallada de cada uno los casos identificados. Identificaci´on de los actores Usuario Se identifica con el administrador de sistemas que utiliza la he- rramienta de monitorizaci´on y detecci´on de intrusos para examinar y analizar el estado actual y el desempe˜no de los distintos hosts de una red. 23
  35. 35. 24 4.1. An´alisis de requisitos Objeto de Monitorizaci´on Es el elemento, o elementos, que se desea ana- lizar peri´odicamente a trav´es del uso de la aplicaci´on a desarrollar. DDS Middleware Se trata del software encargado de gestionar la funcio- nalidad relacionada con la distribuci´on de datos, siguiendo el paradig- ma de publicaci´on/suscripci´on descrito en el apartado 1.4.1. Sistema de Almacenamiento Proporciona soporte para el almacenamien- to de informaci´on recolectada en los procesos de an´alisis de los distintos Objetos de Monitorizaci´on. Diagrama de casos de uso La Figura 4.1 presenta el diagrama de casos de uso de la aplicaci´on. ´Este expone, con gran nivel de abstracci´on, la interacci´on del sistema con los distintos actores definidos en el apartado anterior. Figura 4.1: Digrama de casos de uso del sistema Especificaci´on de los casos de uso El est´andar UML [36] no especifica ning´un formato de plantilla para la descripci´on de los diferentes casos de uso definidos para un sistema. Por lo tanto, en la pr´actica se utilizan multitud de especificaciones dise˜nadas por diferentes autores, compa˜n´ıas, etc. En la descripci´on de los casos de uso del presente proyecto, identificados en la Figura 4.1, se utilizar´a la plantilla que se define en el Cuadro 4.1.
  36. 36. An´alisis del sistema 25 No obstante, en la bibliograf´ıa se incluyen plantillas alternativas como la de Alistair Cockburn [37] o Dan North [38]. CU#id: Nombre del Caso de Uso Descripci´on breve del caso de uso y sus objetivos. Dependencias Si el caso de uso depende de otros (o los incluye). Actores Actores que interaccionan con un caso de uso espec´ıfico. Precondiciones Conjunto de condiciones que han de ser ciertas al comenzar la secuencia de interacciones que se definen en un caso de uso. Postcondiciones Condici´on siempre cierta al final del curso normal. Curso normal Narraci´on de la secuencia de pasos m´as habitual en el caso de uso. Curso alternativo Descripci´on de las ramas alternativas o situaciones excepcionales fuera del curso normal. Cuadro 4.1: Plantilla para la definici´on de casos de uso Una vez definida la plantilla, se describe cada uno de casos identificados en la Figura 4.1. CU#1: Difundir datos de monitorizaci´on El Usuario desea difundir a la red el estado actual de una serie par´ametros del Objeto de Monitorizaci´on. Dependencias Se necesitan, a trav´es de su inclusi´on, los casos de uso CU4 y CU5. Actores Usuario, Objeto de Monitorizaci´on y DDS Middleware. Precondiciones No existen precondiciones para este caso de uso. Postcondiciones La informaci´on recolectada del Objeto de Monitorizaci´on, en relaci´on a la serie de par´ametros previamente indicada, es transmitida a la red por DDS Middleware. Curso normal 1. El Usuario inicia el procedimiento de difusi´on de la informaci´on de monitorizaci´on.
  37. 37. 26 4.1. An´alisis de requisitos 2. A trav´es de la inclusi´on del caso de uso CU4 se realiza la carga de la configuraci´on. ´Esta manejar´a tanto el proceso de difusi´on, como los par´ametros que se examinan del Objeto de Monitorizaci´on en el paso siguiente. 3. Mediante la inclusi´on del caso de uso CU5, de acuerdo con los par´ame- tros recogidos en el paso anterior, se realiza la extracci´on de la informaci´on requerida acerca del Objeto de Monitorizaci´on. 4. Una vez recogidos estos datos, DDS Middleware se encarga de difun- dirlos a la red. Curso alternativo No existen cursos alternativos para este caso de uso. CU#2: Recibir datos de monitorizaci´on El Usuario desea recibir datos de monitorizaci´on procedentes de elementos de la red de acuerdo a una serie de par´ametros especificados previamente. Dependencias Se necesita, a trav´es de su inclusi´on, el caso de uso CU4. Actores Usuario, DDS Middleware y Sistema de Almacenamiento. Precondiciones No existen precondiciones para este caso de uso. Postcondiciones El Usuario recibe informaci´on relativa a una serie de par´ametros que diferentes entidades han difundido en la red. Curso normal 1. El Usuario inicia el procedimiento de recepci´on de la informaci´on. 2. Mediante la inclusi´on del caso de uso CU4, se carga la configuraci´on de la recepci´on de la informaci´on, incluyendo los par´ametros de monito- rizaci´on que el Usuario desea recibir. 3. Se reciben peri´odicamente, de forma as´ıncrona, los par´ametros de mo- nitorizaci´on definidos en el paso anterior. Curso alternativo Dependiendo de si as´ı se indica en la configuraci´on recogida en el segun- do paso, se deber´a realizar el siguiente procedimiento cada vez que se produzca la recepci´on de informaci´on: 4. Se almacena la informaci´on recolectada a trav´es del caso de uso CU6. CU#3: Visualizar datos de monitorizaci´on El usuario desea visualizar de forma unificada los datos de monitorizaci´on que han sido, y est´an siendo, recolectados. Dependencias Este caso de uso no tiene dependencias.
  38. 38. An´alisis del sistema 27 Actores Usuario y Sistema de Almacenamiento. Precondiciones No existen precondiciones para este caso de uso. Postcondiciones Se muestran al Usuario, de forma normalizada, los eventos recibidos y acumulados en el Sistema de Almacenamiento. Curso normal 1. El usuario solicita la visualizaci´on de datos de monitorizaci´on. 2. Se realiza una petici´on al Sistema de Almacenamiento para la lectura de los datos de monitorizaci´on que en ´el se registran. 3. Se muestra la informaci´on de forma normalizada al Usuario. Curso alternativo No existe un curso alternativo en este caso de uso. CU#4: Cargar configuraci´on CU1 y CU2 necesitan la carga de una serie de caracter´ısticas que influyen en diversos aspectos de la difusi´on y recepci´on de informaci´on. CU4 realiza esta labor, lo que le convierte en un caso de uso de inclusi´on para ´estos. Dependencias El caso de uso es utilizado, a trav´es de su inclusi´on, tanto por CU1 como por CU2. Actores Usuario. Precondiciones El Usuario debe haber iniciado el caso de uso CU1 o CU2. Postcondiciones Se extraen las caracter´ısticas de configuraci´on necesarias para las tareas posteriores de CU1 o CU2. Curso normal 1. El caso de uso base solicita, a ra´ız de una petici´on del Usuario, la carga de configuraci´on para la difusi´on o recepci´on de informaci´on. 2. Se extrae, a partir de una serie de ficheros de configuraci´on, la infor- maci´on requerida para el desarrollo del caso de uso que incluye a ´este: par´ametros a examinar en el Objeto de Monitorizaci´on, frecuencia de env´ıo de informaci´on, pol´ıticas de QoS, opciones de recepci´on, etc. 3. Se proporciona la informaci´on adecuada al caso de uso base. Curso alternativo No existe un curso alternativo en este caso de uso.
  39. 39. 28 4.1. An´alisis de requisitos CU#5: Obtener datos de monitorizaci´on Una vez obtenidos los par´ametros de configuraci´on necesarios, a trav´es de la inclusi´on de CU4, el caso de uso CU1 requiere la obtenci´on de una serie de datos procedentes del Objeto de Monitorizaci´on para la difusi´on de informaci´on. El presente caso de uso realiza dicha labor. Dependencias El caso de uso es utilizado (a trav´es de su inclusi´on) por CU1. Actores Usuario y Objeto de Monitorizaci´on. Precondiciones El Usuario debe haber iniciado el caso de uso CU1 y deben haberse car- gado los par´ametros de configuraci´on (CU4). Postcondiciones Se obtiene informaci´on acerca del estado actual de una serie de par´ametros relativos al Objeto de Monitorizaci´on. Curso normal 1. El caso de uso CU1 solicita el estado actual del Objeto de Monitoriza- ci´on de acuerdo a una serie de par´ametros. 2. Se examina el estado actual de dichos par´ametros en el Objeto de Monitorizaci´on y se extraen en un formato normalizado para su difusi´on en CU1. Curso alternativo No existe un curso alternativo en este caso de uso. CU#6: Almacenar datos de monitorizaci´on El CU2 permite, como uno de sus posibles flujos de ejecuci´on, la acu- mulaci´on de la informaci´on de monitorizaci´on recolectada en un Sistema de Almacenamiento. Este procedimiento se realiza en el presente caso de uso. Dependencias El caso de uso es utilizado, extiende funcionalidad, en CU2. Actores Usuario y Sistema de Almacenamiento. Precondiciones El Usuario debe haber iniciado el caso de uso CU2. Adem´as, se debe haber realizado previamente la carga de la configuraci´on de la recepci´on (CU4). Postcondiciones La informaci´on de monitorizaci´on recolectada queda guardada en el Sis- tema de Almacenamiento. Curso normal 1. El caso de uso CU2 solicita el almacenamiento de una serie de datos de monitorizaci´on en el Sistema de Almacenamiento.
  40. 40. An´alisis del sistema 29 2. Se realiza una conexi´on con el Sistema de Almacenamiento y se intro- ducen los datos de acuerdo con las caracter´ısticas indicadas en la confi- guraci´on cargada en CU4 y en funci´on de la naturaleza de los mismos. Curso alternativo No 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 ser´a la clasificaci´on de ´estos de acuerdo con su funcionalidad. Este procedimiento, que se realizar´a a trav´es de la elaboraci´on del diagrama de paquetes UML del mismo, permitir´a establecer una divisi´on del problema en distintos sub- sistemas funcionales. Un diagrama de paquetes puede ser utilizado para organizar cualquier tipo de clasificador UML: clases, entidades, casos de uso, etc. Para la ela- boraci´on del diagrama, se toma como ejemplo el modelo presentado en [39]: se establecen los principales subsistemas de funcionamiento como paquetes y se relacionan ´estos con los actores involucrados en los casos de uso que contiene cada subsistema. El resultado se muestra en la Figura 4.2. Como puede observarse, se han identificado tres subsistemas funcionales sobre los que deber´a organizarse la soluci´on final: Publisher, Subscriber y User Interface. Publisher Dentro del subsistema Publisher se incluyen los diferentes casos de uso relacionados con el proceso de difusi´on de informaci´on proce- dente de los distintos Objetos de Monitorizaci´on. Se incluyen en ´el, por lo tanto, los siguientes casos de uso: Difundir datos de monitorizaci´on (CU1). Cargar configuraci´on (CU4). Obtener datos de monitorizaci´on (CU5). De esta forma, el subsistema Publisher deber´a ser capaz de recolectar informaci´on de diferentes par´ametros procedentes de Objetos de Mo- nitorizaci´on, de acuerdo a una serie de caracter´ısticas de configuraci´on, difundiendo los datos obtenidos en un dominio DDS. Subscriber El subsistema Subscriber contiene los casos de uso relacionados con la recepci´on de informaci´on de monitorizaci´on difundida por el subsistema Publisher. Los casos de uso incluidos son: Recibir datos de monitorizaci´on (CU2). Cargar configuraci´on (CU4).
  41. 41. 30 4.1. An´alisis de requisitos Figura 4.2: Diagrama de paquetes del sistema Almacenar datos de monitorizaci´on (CU6). Por lo tanto, el subsistema Subscriber se encargar´a de obtener la infor- maci´on difundida por Publisher en un dominio DDS. La recepci´on se realizar´a de acuerdo a una serie de caracter´ısticas de configuraci´on, pu- di´endose almacenar dicha informaci´on para su visualizaci´on y an´alisis posterior. User Interface El ´ultimo subsistema que compone el proyecto es la inter- faz de visualizaci´on. ´Esta est´a compuesta ´unicamente por el caso de uso “Visualizar datos de monitorizaci´on” (CU3), encarg´andose as´ı de proporcionar al administrador un sistema de visualizaci´on normalizado de 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
  42. 42. An´alisis del sistema 31 secci´on se analizar´an, a grandes rasgos, los procesos de interacci´on que si- guen los principales subsistemas identificados en el diagrama de paquetes de la Figura 4.2. Los diagramas de secuencia describen la colaboraci´on entre los diferen- tes objetos que componen el sistema. Se trata, por tanto, de una serie de diagramas de interacci´on que detallan las operaciones que se llevan a cabo, qu´e mensajes son enviados y cu´ando. La descripci´on de las distintas operaciones, presentadas a continuaci´on, ser´a refinada en el siguiente cap´ıtulo, una vez sean definidas las clases y objetos sobre los que se basar´a directamente la implementaci´on 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 desarrollo de los casos de uso que ´este alberga: Usuario, Objeto de la Monitorizaci´on y DDS Middleware. Figura 4.3: Diagrama de secuencia: Publisher A continuaci´on se realiza una descripci´on paso a paso del diagrama: 1. El usuario env´ıa el mensaje iniciar monitorizacion() a Publisher con objeto de que ´este inicie todo el proceso de recolecci´on de datos y la difusi´on de la informaci´on de monitorizaci´on. 2. Una vez recibido el mensaje de iniciaci´on, Publisher debe cargar la configuraci´on que definir´a tanto las caracter´ısticas de extracci´on de la
  43. 43. 32 4.1. An´alisis de requisitos informaci´on, como las pol´ıticas que deber´a seguir a la hora de trans- mitir ´esta a trav´es del middleware. 3. Una vez cargada la informaci´on, se inicia un bucle de monitorizaci´on- difusi´on, que s´olo podr´a ser interrumpido por un mensaje de finaliza- ci´on de la monitorizaci´on. El primer paso en este bucle ser´a la petici´on, desde Publisher al Objeto de la Monitorizaci´on, del estado actual de los par´ametros deseados a trav´es del mensaje obtener datos(). 4. El Objeto de la Monitorizaci´on devuelve la informaci´on requerida a Publisher. 5. Una vez obtenidos los datos actuales del objeto de monitorizaci´on, Publisher transmite ´estos al middleware para la realizaci´on del env´ıo. 6. Los datos son enviados por el middleware y se vuelve al paso 3. 7. Si Publisher recibe en alg´un momento, por parte del Usuario, el men- saje finalizar monitorizacion(), se detiene el bucle de monitori- zaci´on-difusi´on 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 est´a relacionado tanto con el Usuario como con DDS Middleware, adem´as, en caso de ser requerido por la configuraci´on, ´este se relacionar´a tambi´en con el Sistema de Almacena- miento. A continuaci´on se describe la interacci´on que realiza este subsistema a trav´es de la siguiente serie de pasos: 1. Al igual que en Publisher, el Usuario inicia el proceso de recepci´on de informaci´on a trav´es del mensaje iniciar recepcion(), que reci- bir´a Subscriber. 2. Una vez recibido este mensaje, Subscriber inicia el proceso de recepci´on cargando primero la configuraci´on que fijar´a tanto las caracter´ısticas del proceso de recepci´on, como la posibilidad de almacenar la infor- maci´on recibida en el proceso. 3. Se inicia el bucle de recepci´on-almacenamiento esperando la llegada de los datos de monitorizaci´on a los que Subscriber est´a suscrito. De este modo, en cuanto el middleware recibe datos, los comunica a Subscriber a trav´es del mensaje datos recibidos().
  44. 44. An´alisis del sistema 33 Figura 4.4: Diagrama de secuencia: Subscriber 4. El procedimiento que se sigue una vez recibidos los datos depende de las caracter´ısticas de configuraci´on que se cargaron en el paso 2. Si se ha seleccionado el almacenamiento en alg´un tipo de Sistema de Almacenamiento, se env´ıa el mensaje almacenar datos() a ´este para que incluya los datos recibidos en su registro. 5. Subscriber sigue a la espera de la recepci´on as´ıncrona de un nuevo mensaje por parte del middleware, proceso que s´olo se interrumpe en caso de recibirse el mensaje finalizar recepcion() por parte del Usuario. User Interface El ´ultimo escenario presentado es el que relaciona el subsistema de vi- sualizaci´on, User Interface, tanto con el Usuario que solicita ´esta, como con el Sistema de Almacenamiento que alberga los datos de monitorizaci´on. El diagrama de secuencia de User Interface se muestra en la Figura 4.5. A continuaci´on se describen los pasos de ´este: 1. El Usuario solicita a User Interface la visualizaci´on de los datos de monitorizaci´on actuales e hist´oricos a trav´es del paso del mensaje mostrar datos monitorizacion(). 2. Ante la petici´on que realiza el usuario, User Interface debe recuperar
  45. 45. 34 4.2. An´alisis de la arquitectura de monitorizaci´on Figura 4.5: Diagrama de secuencia: User Interface los datos de monitorizaci´on 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 User Interface. 4. Con los datos obtenidos del Sistema de Almacenamiento, User Inter- face muestra al usuario la informaci´on solicitada. 4.2. An´alisis de la arquitectura de monitorizaci´on Los subsistemas funcionales definidos hacen frente a un proceso de mo- nitorizaci´on y de detecci´on de intrusos a trav´es de la difusi´on de eventos utilizando el middleware DDS. En Millar et al. [33] se muestra un estudio de la arquitectura de MonAMI, un framework para la monitorizaci´on de servicios a trav´es de un sistema de plugins. MonAMI parte de un modelo sencillo de interacci´on, al que denomi- na three-component model, que presenta un intercambio interactivo de flujos de informaci´on entre tres componentes: monitoring target (objeto de la mo- nitorizaci´on), monitoring agent (agente de monitorizaci´on) e information storage (almacenamiento de informaci´on). El sistema de monitorizaci´on y de detecci´on de intrusiones que se desea desarrollar, al que se denominar´a de ahora en adelante Cave Canem, toma como referencia este modelo sencillo de monitorizaci´on, englobando los tres componentes de ´este en de los subsistemas identificados anteriormente. A continuaci´on se describe cada uno de los elementos que lo componen: Monitoring target Se trata del sistema sobre el que se desea mantener in- formaci´on. ´Esta puede estar relacionada tanto con componentes hard-
  46. 46. An´alisis del sistema 35 ware (como la frecuencia o temperatura de un procesador), como con servicios software (por ejemplo, las alertas generadas por un IDS). A partir del an´alisis de casos de uso realizado en el apartado 4.1.1, se podr´ıa identificar al monitoring target con el actor Objeto de Moni- torizaci´on con el que el Publisher de Cave Canem, al que se denomi- nar´a de ahora en adelante Cave Canem Publisher o CCPublisher, mantiene contacto peri´odico para actualizar el estado de una serie de par´ametros. Monitoring agent Este segundo componente representa al software que traslada el flujo de informaci´on desde el monitoring target al sistema de almacenamiento. El medio de interacci´on con los diferentes objetos de la monitorizaci´on difiere en funci´on de la naturaleza del mismo. Por tanto, el dise˜no debe contemplar un sistema de interacci´on espec´ıfico para cada objetivo. En Cave Canem, los agentes de monitorizaci´on estar´an integrados en CCPublisher. Information storage Este ´ultimo componente utiliza m´etodos de almace- namiento, normalmente no vol´atiles, para registrar de forma peri´odica la informaci´on recibida. Entre los sistemas de almacenamiento m´as usados en sistemas de monitorizaci´on se encuentran, entre otros, los ficheros de log, las bases de datos relacionales (como MySQL) o las bases de datos Round-Robin (como es el caso de RRDtool en Ganglia [29]). Como pudo observarse en la identificaci´on de los actores involucrados en los casos de uso de la aplicaci´on, el sistema de almacenamiento se representa en ´estos como un actor con el que el Subscriber de Cave Ca- nem, al que se denominar´a de ahora en adelante Cave Canem Subscri- ber o CCSubscriber, realiza un proceso de comunicaci´on as´ıncrono, almacenando la informaci´on recibida en cuanto ´esta se encuentra dis- ponible, si as´ı se indica en la configuraci´on. 4.3. An´alisis del middleware Otro de los aspectos a tener en cuenta en este an´alisis son las carac- ter´ısticas que el middleware elegido ofrece al sistema a implementar. En este apartado, se realizar´a una descripci´on de las principales particularida- des de DDS que permiten la mejora del rendimiento de la distribuci´on de la informaci´on de monitorizaci´on en Cave Canem. Una descripci´on m´as amplia de estas caracter´ısticas puede obtenerse en Farabaugh et al. [19].
  47. 47. 36 4.3. An´alisis del middleware 4.3.1. Desacople en tiempo y espacio Como se coment´o en el apartado 1.4.1, DDS proporciona un modelo de distribuci´on de publicaci´on/suscripci´on que desacopla a publicadores y suscriptores en tiempo y en espacio. El desacople en tiempo se basa en la utilizaci´on del par´ametro Durabi- lity en la definici´on de las pol´ıticas de QoS de la aplicaci´on. Este par´ametro controla el comportamiento del middleware respecto al almacenamiento de las muestras de informaci´on distribuidas, poniendo en cuesti´on si ´estas de- ben almacenarse para el consumo por parte de suscriptores que se unan al dominio DDS despu´es de la publicaci´on de ´estas. El comportamiento puede ser, de este modo: Volatile Bajo esta configuraci´on, el middleware no almacenar´a muestras pasadas de los datos transmitidos. Transient El middleware almacenar´a un cierto n´umero de muestras de los datos transmitidos para su procesamiento por consumidores que se suscriban en un determinado momento. Persistent Implica el almacenamiento de todas las muestras transmitidas, de modo que cualquier suscriptor pueda recibir el hist´orico de trans- misiones de un determinado dominio DDS. El desacople en espacio viene manejado impl´ıcitamente por el modelo de comunicaci´on de DDS. Esta caracter´ıstica permite situar a los publicadores y suscriptores de Cave Canem en cualquier nodo de la red sin la necesidad de realizar, en principio, ninguna configuraci´on extra. Por lo tanto, se pue- den establecer puntos redundantes de procesamiento y visualizaci´on de la informaci´on de forma sencilla. 4.3.2. Filtros en la recepci´on de topics DDS se basa en el uso de topics para la comunicaci´on publicador/sus- criptor. Una de las funcionalidades que aporta el middleware, en relaci´on a la recepci´on de informaci´on, es el filtrado de topics en funci´on a su contenido. Los Content Filtered Topics permiten definir expresiones de filtrado pa- ra la recepci´on de informaci´on. Es decir, s´olo las muestras que cumplan la definici´on de un filtro ser´an recibidas por las partes suscriptoras que lo defi- nan y se notificar´an, por lo tanto, a la aplicaci´on. En unicast, el filtrado de informaci´on se implementa en el origen, en lugar de en la parte suscriptora, lo que reduce en gran medida el consumo de ancho de banda.
  48. 48. An´alisis del sistema 37 4.3.3. Monitorizaci´on de eventos a trav´es del uso de listeners El uso de listeners es uno de los mecanismos que permite a una apli- caci´on DDS detectar cambios en el estatus de la comunicaci´on data-centric publish-subscribe (DCPS)1. El uso de ´estos permite al programador delegar dicha funci´on en el middleware. Adem´as, a la hora de realizar la recepci´on (como reacci´on al evento on data available), el listener crea una hebra de ejecuci´on, de forma transparente al programador, para la realizaci´on de tareas de recepci´on como, por ejemplo, el registro de la informaci´on reci- bida en un sistema de almacenamiento. Este hecho permite a la aplicaci´on suscriptora seguir trabajando sin que se produzcan bloqueos. 4.3.4. Algunos par´ametros de QoS Como ya se ha mencionado, a trav´es del uso de los diferentes par´ame- tros de QoS proporcionados por DDS, los procesos de comunicaci´on pueden adaptarse a las necesidades del sistema, mejorando as´ı el rendimiento de ´este. DDS realiza la configuraci´on de QoS por entidad. Por lo tanto, se pue- den definir diferentes pol´ıticas en topics, DataReaders o DataWriters. Entre estos par´ametros son resaltables, por la ayuda que pueden prestar para la mejora del rendimiento de la aplicaci´on, los siguientes: Reliability Especifica si un DataReader recibe informaci´on de forma con- fiable desde un DataWriter. B´asicamente, puede seleccionarse una co- municaci´on Best Effort, que suprima el control de retransmisi´on de in- formaci´on para incrementar el rendimiento; o una comunicaci´on fiable, que asegure la recepci´on de todos lo datos emitidos. De esta manera, el escenario de la monitorizaci´on podr´ıa configurarse de forma distinta para la transmisi´on de informaci´on de diversa ´ındole. As´ı, se podr´ıa escoger una pol´ıtica Best Effort para la transmisi´on de temperaturas, por ejemplo, donde cualquier muestra de informaci´on puede ser sus- tituida por una m´as reciente; y fiable para la publicaci´on de alertas generadas por un IDS, donde toda la informaci´on debe ser tenida en cuenta. Time-based Filter Este par´ametro define la separaci´on m´ınima, en tiem- po, que puede existir entre los mensajes recibidos por un DataReader. De esta forma, se puede definir una tasa de recepci´on menor que la tasa de env´ıo. Esta configuraci´on puede ser ´util en aquellos casos en los que no se necesite registrar toda la informaci´on que es enviada por los DataWriters, sino valores puntuales en el tiempo. 1 Tambi´en existen conditions y wait-sets [1].
  49. 49. 38 4.4. An´alisis del sistema de almacenamiento History Especifica el n´umero de muestras de informaci´on almacenadas pa- ra env´ıos posteriores en DDS. Puede escogerse el almacenamiento de todas estas muestras, KEEP ALL, o guardar un numero N de muestras, KEEP LAST N. 4.4. An´alisis del sistema de almacenamiento Como se coment´o anteriormente, uno de los requisitos de la soluci´on planteada es la presencia de un sistema de almacenamiento que permita el registro de la informaci´on recolectada por el sistema de monitorizaci´on. Dada la importancia de este elemento, en el presente apartado se realizar´a un an´ali- sis de las posibles soluciones a implementar en Cave Canem. M´as adelante, en el cap´ıtulo de dise˜no, se concretar´a la adaptaci´on del sistema escogido para su posterior implementaci´on. En el apartado 4.2 se enumeraron algunos de los sistemas de almacena- miento m´as utilizados por herramientas de monitorizaci´on. A continuaci´on se realiza un an´alisis detallado de los mismos. 4.4.1. Ficheros de log Los ficheros de log son un tipo de archivos para el registro de acciones ocurridas en el funcionamiento de un sistema. Por ejemplo, los servidores web mantienen ficheros log que registran las diferentes peticiones realizadas al mismo. De este modo, a trav´es del an´alisis de ´estos, los administradores de sistemas pueden obtener informaci´on acerca del uso que se ha dado al servidor, examinar problemas que han ocurrido o predecir problemas que puedan suceder. Syslog es un est´andar para el env´ıo y almacenamiento de mensajes de log definido en el RFC 5424 [40]. Los logs generados se utilizan en la adminis- traci´on de sistemas, en la realizaci´on de auditor´ıas de seguridad, as´ı como en el an´alisis y depuraci´on de programas. La informaci´on recolectada puede ser difundida a trav´es de mensajes enviados a dispositivos locales, como una terminal; puede almacenarse en ficheros, como es el caso de /var/log en Unix; o puede ser utilizada por demonios Syslog remotos. La concepci´on del sistema descrita en apartados anteriores establece co- mo requerimiento el almacenamiento continuo de datos referentes a distintos par´ametros de diferentes objetos de monitorizaci´on. Estos datos, deber´an ser procesados posteriormente por una interfaz de usuario, que necesitar´a rapi- dez en la recuperaci´on de la informaci´on. El almacenamiento de datos de monitorizaci´on en ficheros de log incre- mentales ofrece como ventaja un acceso r´apido para la escritura de infor-
  50. 50. An´alisis del sistema 39 maci´on, en contraposici´on a los sistemas gestores de bases de datos. Sin embargo, la recuperaci´on y gesti´on relacional de informaci´on en este tipo de ficheros supone un coste poco asumible para su utilizaci´on junto a la interfaz de usuario. Se trata, por tanto, de un sistema de almacenamiento a tener en cuenta en la generaci´on de mensajes de depuraci´on a la hora de implementar la aplicaci´on, pero inadecuado para el almacenamiento de los datos generados en el proceso de monitorizaci´on. 4.4.2. Ficheros estructurados: XML y CSV Dentro de este apartado se realiza un an´alisis de dos formatos de ficheros estructurados ampliamente utilizados en sistemas de almacenamiento, como son XML y CSV. XML, siglas de eXtensible Markup Language o lenguaje extensible de marcas, es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C) [41]. XML permite definir la gram´atica de lenguajes espec´ıficos, por lo que no se trata de un lenguaje en particular, sino que representa una herramienta para la definici´on de lenguajes para diferentes necesidades. Entre las principales ventajas de XML son destacables las siguientes: Se basa en est´andares internacionales y como tal es un est´andar abier- to. Puede representar estructuras de datos comunes en el campo de la inform´atica como registros, listas y ´arboles. Los algoritmos de an´alisis sint´actico para XML son simples, eficientes y consistentes dadas sus restricciones de sintaxis y an´alisis. Puede utilizase para el almacenamiento y procesamiento de documen- tos. La adopci´on de XML en la industria y campos de investigaci´on es alta, por lo tanto existe una gran cantidad de herramientas para la generaci´on de documentos y procesado de informaci´on almacenada en XML. Un lenguaje basado en XML puede ser f´acilmente modificado de forma incremental sin perder compatibilidad hacia atr´as. No obstante, XML tambi´en presenta una serie de desventajas, en especial en relaci´on a algunas circunstancias que se detallan ampliamente en [42]. Algunas de ´estas son:
  51. 51. 40 4.4. An´alisis del sistema de almacenamiento La sintaxis de XML es redundante y grande, en t´erminos de tama˜no, en comparaci´on a representaciones de datos alternativas, especialmente si se utiliza para representar datos tabulares. Esta redundancia afecta al rendimiento de las aplicaciones al aumentar el tama˜no de almacena- miento y transferencia, as´ı como el coste de procesamiento. La sintaxis presenta sobrecarga de informaci´on para un lector humano en comparaci´on con otros formatos de transferencia de datos. Su modelo jer´arquico de representaci´on del conocimiento es limitado en comparaci´on con otras alternativas, como por ejemplo, las orientadas a grafos. Promueve el uso de estructuras de datos no relacionales (datos no normalizados). XML introduce un fuerte acoplo entre la representaci´on elegida y el procesamiento de la informaci´on a diferencia de alternativas de alma- cenamiento relacional con SQL. Como se puede observar, la mayor parte de las desventajas est´an rela- cionadas con la validez de XML para la representaci´on de datos complejos y las relaciones entre ´estos. Especialmente, a la hora de representar grandes cantidades de datos que deben procesarse o transmitirse, XML presenta una sobrecarga en el tama˜no que ocupa la informaci´on serializada. En el caso de Cave Canem, el almacenamiento de la informaci´on de monitorizaci´on reco- lectada necesitar´a, para su an´alisis y visualizaci´on por parte de la interfaz de usuario, un m´etodo de recuperaci´on eficiente con la posibilidad de realizar b´usquedas en un tiempo asumible, algo para lo que XML no est´a dise˜nado. No obstante, teniendo en cuenta las caracter´ısticas y ventajas identificadas, se puede considerar XML como un candidato a tener en cuenta para su adopci´on por parte del sistema de configuraci´on de Cave Canem, tal como se analizar´a en el apartado 4.5. Por otro lado, los ficheros CSV (Comma-Separated Values) son un tipo de documento sencillo para la representaci´on 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 car´acter de separaci´on definido), mientras que las filas se identifican mediante saltos de l´ınea (por lo que los campos que contengan este tipo de caracteres deber´an ser encerrados entre comillas dobles). El formato CSV no indica ning´un juego de caracteres concretos, ni c´omo van situados los bytes, ni el formato para el salto de l´ınea2. Estas es- 2 No existe una especificaci´on formal para los ficheros CSV. Las ´unicas directrices se definen en el documento RFC 4180 [43], que describe un formato com´un y establece el tipo MIME “text/csv”, registrado por el IANA; y en la especificaci´on del est´andar Fielded
  52. 52. An´alisis del sistema 41 pecificaciones deben indicarse, normalmente, al abrir el fichero, por ejemplo mediante un programa de hojas de c´alculo. La principal ventaja de CSV, adem´as de la especificaci´on sencilla y la facilidad de lectura para cualquier lenguaje de programaci´on, es que los prin- cipales sistemas de hojas de c´alculo del mercado son capaces de leer y operar con dicho formato (por ejemplo OpenOffice.org Calc o Excel de Microsoft Office). Esto permite la visualizaci´on sencilla de los valores almacenados a trav´es de estas aplicaciones, facilitando la labor de documentaci´on y la evaluaci´on de los datos obtenidos. No obstante, CSV presenta las mismas desventajas que XML en relaci´on a la velocidad de recuperaci´on de datos de cara a su uso en una interfaz de usuario, m´as a´un trat´andose de un for- mato sin etiquetado. Por tanto, en este caso las bases de datos tradicionales tambi´en suponen una soluci´on mucho m´as eficiente. 4.4.3. Sistemas gestores de bases de datos Las bases de datos son agrupaciones de informaci´on, pertenecientes a un contexto determinado, que se almacenan sistem´aticamente para su posterior uso. Los sistemas gestores de bases de datos (SGBD) permiten el almace- namiento y recuperaci´on de informaci´on de forma r´apida y estructurada de una base de datos, siendo el modelo relacional el m´as utilizado en la imple- mentaci´on de dichos sistemas. Las bases de datos relacionales se organizan en tablas, distribuidas a su vez en registros (filas y columnas). Estos regis- tros pueden estar relacionados con otros registros de la misma u otra tabla a trav´es del uso de claves primarias y for´aneas. La organizaci´on que propor- ciona este tipo de almacenamiento presenta una serie de ventajas para el registro de informaci´on de monitorizaci´on: Los SGBD proporcionan lenguajes de consulta o generadores de infor- mes que permiten la consulta y recuperaci´on 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 el dise˜no del esquema de almacenamiento, facilitando a su vez la recupe- raci´on y comparaci´on de la informaci´on recogida en ´estas. La mayor´ıa de SGBD gestionan el acceso concurrente a la informaci´on, garantizando la ausencia de problemas derivados del acceso simult´aneo por parte de distintas entidades a la informaci´on almacenada. Text [44], que cubre en uno de sus apartados el formato CSV. Se pueden encontrar m´as referencias a especificaciones de este formato en [45] y [46].
  53. 53. 42 4.4. An´alisis del sistema de almacenamiento Entre los inconvenientes del uso de bases de datos en sistemas de moni- torizaci´on encontramos: Los SGBD son programas complejos y requieren una cantidad de espa- cio en disco y memoria mucho mayor al de sistemas de almacenamiento m´as sencillos como los ficheros de log, XML o CSV. El acceso y la escritura de informaci´on en una base de datos es un proceso costoso. Por ejemplo, el IDS Snort recomienda la utilizaci´on de sistemas de almacenamiento alternativos en redes con un nivel alto de tr´afico, debido a su imposibilidad para analizar paquetes durante el 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 el almacenamiento circular de informaci´on. En ´estos se almacena una cantidad de informaci´on fija, definida al de crear la base de datos, sustituy´endose progresivamente las entradas m´as antiguas por los ´ultimos valores recibidos. Se trata de un esquema ideal para el almacenamiento de informaci´on de monitorizaci´on num´erica como temperaturas, cargas del procesador, tasas de transferencia en redes, etc. Entre las ventajas de la utilizaci´on de este esquema de almacenamiento cabe resaltar: La rapidez y facilidad de escritura y recuperaci´on de la informaci´on que proporciona este tipo de herramientas, permitiendo incluso la rea- lizaci´on de consultas sobre la base de datos. La capacidad para limitar el consumo de espacio de la base de datos, almacenando ´unicamente la informaci´on m´as reciente. El sistema de almacenamiento Round-Robin m´as conocido es RRDtool (Round Robin Database tool) [48]. ´Este suma a las ventajas anteriormente descritas la capacidad de generar gr´aficas para representar la evoluci´on de variables de la base de datos en el tiempo. RRDtool se utiliza en aplicaciones tan conocidas como Ganglia, Cacti, JFFNMS, Lighttpd, MRTG, Munin, Smokeping o Zenoss [49]. La principal desventaja de RRDtool es, en relaci´on al sistema que se pretende implementar, la imposibilidad de realizar almacenamiento de in- formaci´on no num´erica, hecho que impide, por ejemplo, el tratamiento de datos como las alertas generadas por un IDS.
  54. 54. An´alisis del sistema 43 La soluci´on a este inconveniente viene dada por la adopci´on de un esque- ma de almacenamiento h´ıbrido, basado en la utilizaci´on de una base de datos relacional con almacenamiento Round-Robin. Se describir´a este esquema con m´as detalle en el Cap´ıtulo 5. 4.5. An´alisis del sistema de configuraci´on En este apartado se revisar´an algunos de los formatos m´as utilizados para la especificaci´on de ficheros de configuraci´on. A partir de este an´alisis se definir´a el formato a utilizar en el sistema de configuraci´on de Cave Canem. 4.5.1. YAML YAML (YAML Ain’t Another Markup Language) [50] es un formato de serializaci´on de datos que define un lenguaje realmente legible, pudiendo ser utilizado para la especificaci´on de ficheros de configuraci´on. YAML toma conceptos de lenguajes C, Perl o Python, as´ı como ideas de XML y el formato para correos electr´onicos definido por el RFC 2822 [51]. La principal ventaja que presenta YAML es su legibilidad y facilidad de uso, que le ha convertido en el formato de configuraci´on escogido por frameworks tan utilizados como Symfony. A continuaci´on se muestra un ejemplo 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 definici´on de ficheros de configuraci´on. Se asocia a productos de Microsoft aunque es muy utilizado tambi´en en otras plataformas, por ejemplo en los ficheros de configuraci´on de PHP. Los ficheros INI pueden ser editados manualmente de forma sencilla. Sin embargo, pueden encontrarse algunos problemas en funci´on de la definici´on de los saltos de l´ınea utilizada por el sistema operativo donde se ejecute la aplicaci´on. A continuaci´on se muestra un fichero de ejemplo que se extrae de [53].
  55. 55. 44 4.5. An´alisis del sistema de configuraci´on [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 el intercambio de datos. JSON es un subconjunto de la notaci´on literal de objetos de JavaScript. Dada la simplicidad del formato, suele utilizarse ´este como alternativa a XML en AJAX, siendo mucho m´as sencilla la realizaci´on de un analizador sem´antico de JSON que uno de XML. JSON se aplica en entornos donde el tama˜no del flujo de datos entre cliente y servidor es de vital importancia, siendo utilizado en algunos servi- cios proporcionados por compa˜n´ıas como Yahoo o Google. A continuaci´on se 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 mencion´o en el apartado 4.4.2, XML es un lenguaje ideal para el desarrollo de ficheros de configuraci´on: permite representar distintas estruc- turas de datos, se basa en est´andares abiertos y es utilizado ampliamente en entornos industriales y de investigaci´on. A continuaci´on se muestra un ejemplo de fichero XML: <reliability > <kind > RELIABLE_RELIABILITY_QOS </kind > <max_blocking_time > <sec >5</sec > </max_blocking_time > </reliability >

×