Gestión de Seguridad en Entornos Virtualizados Utilizando Herramientas Open Source

Proyecto Fin de Mster
Gestin de seguridad en entornos virtualizados utilizando herramientas open source
Ander Elexpuru Ramrez
Director: ngel Barrio Martnez Bilbao, septiembre de 2010
Resumen ejecutivo
Mediante la utilizacin de herramientas de cdigo abierto, se ha desarrollado un Sistema de Gestin de la Seguridad para un entorno virtualizado. A este respecto, el alcance se ha limitado a la monitorizacin de sistemas de escritorio virtuales (VDI). El objetivo principal es conseguir una gestin centralizada de los ficheros de log de seguridad, utilizando para ello herramientas SIEM basadas en el paquete de cdigo abierto OSSIM. Para ello, se han recolectado ficheros de log de diferentes fuentes heterogneas tales como: directorio activo, antivirus, firewalls, sistemas DLP, accesos a la plataforma VDI, etc. y se han establecido reglas de correlacin entre ellos, con el objeto de conseguir mostrar alertas reales y significativas, reduciendo al mximo el nmero de falsos positivos. Asimismo, dentro del proyecto, cabe destacar la realizacin de las siguientes tareas: Prueba y despliegue de herramientas de cdigo abierto (Nagios) para la gestin de sistemas de informacin, como alternativa a soluciones de pago utilizadas masivamente en las empresas tales como: HP Openview IBM Tvoli. Despliegue, configuracin y tunning de sistemas IDS de cdigo abierto basados en Snort, integracin de fuentes de datos con OSSIM. Personalizacin del portal y cuadro de mando de OSSIM con alertas ms relevantes en servidores virtualizados.. Integracin con el API de VMware en el portal de OSSIM para la realizacin automtica de acciones en los servidores virtualizados: encendido, apagado, etc. Investigacin de otras herramientas de seguridad de cdigo abierto que pudieran aportar valor al proyecto. A este respecto, se han realizado pruebas de herramientas de cortafuegos de aplicacin: ModSecurity.
Descriptores
Seguridad, OSSIM, VMware, SIEM, IDS.
iii
ndice general
1. OBJETIVOS............................................................................................................................. 1
1.1. Objetivos del proyecto................................................................................................................1 1.2. Objetivos personales...................................................................................................................2

2. ALCANCE................................................................................................................................ 3 3. PLANIFICACIN..................................................................................................................... 5 4. TAREAS................................................................................................................................... 7
4.1. Recopilacin de informacin......................................................................................................7 4.2. Preparacin de la infraestructura de virtualizacin....................................................................7 4.3. Preparacin y puesta a punto de la herramienta SIEM..............................................................9 4.4. Preparacin de las mquinas de testeo.......................................................................................9 4.5. Integracin del SIEM en el entorno virtual..............................................................................10 4.6. Preparacin del servidor web con firewall de nivel 7..............................................................11 4.7. Realizacin de pruebas.............................................................................................................11 4.8. Redaccin de la documentacin...............................................................................................13 4.9. Control peridico......................................................................................................................13
5. CONCLUSIONES................................................................................................................... 15
5.1. Anlisis de resultados...............................................................................................................15 5.2. Puntos de mejora......................................................................................................................16 5.3. Conclusiones personales...........................................................................................................16

6. Anexo A: DESARROLLO TCNICO.....................................................................................19
6.1. Acciones...................................................................................................................................19 6.2. Panel de control VDI................................................................................................................20 6.3. Plugin VDI................................................................................................................................28

7. Anexo B: ALIENVAULT OSSIM............................................................................................ 31
7.1. Perfiles......................................................................................................................................31 7.2. Activos......................................................................................................................................32 7.3. Riesgo.......................................................................................................................................33 7.4. Correlacin...............................................................................................................................34 7.5. Plugins......................................................................................................................................34 7.6. Requisitos de hardware.............................................................................................................35
7.7. Instalacin.................................................................................................................................35 7.8. Administracin SSH.................................................................................................................36 7.9. Administracin web..................................................................................................................37

7.9.1. Cuadros de mando..................................................................................................................37 7.9.2. Incidentes................................................................................................................................39 7.9.3. Anlisis...................................................................................................................................40 7.9.4. Informes..................................................................................................................................42 7.9.5. Activos....................................................................................................................................43 7.9.6. Inteligencia.............................................................................................................................45 7.9.7. Monitores................................................................................................................................49 7.9.8. Configuracin.........................................................................................................................51 7.9.9. Herramientas...........................................................................................................................53 8. Anexo C: VIRTUALIZACIN.................................................................................................57
8.1. VMware....................................................................................................................................57
8.1.1. VMware Tools........................................................................................................................59 8.1.2. El API VIX.............................................................................................................................60 8.1.3. Vmrun.....................................................................................................................................60 9. Anexo D: OSSEC.................................................................................................................. 65 10. Anexo E: MODSECURITY................................................................................................... 69 11. GLOSARIO.......................................................................................................................... 71 12. BIBLIOGRAFA.................................................................................................................... 73 13. LICENCIA............................................................................................................................. 75 GNU Free Documentation License.................................................................................................75
vi
ndice de figuras
Figura 2.1: Servidor HP..........................................................................................................................3 Figura 3.1: Diagrama de Gantt I.............................................................................................................5 Figura 3.2: Diagrama de Gantt II............................................................................................................5 Figura 3.3: Diagrama de Gantt III...........................................................................................................6 Figura 4.1: Port-Mirroring......................................................................................................................8 Figura 4.2: Creacin de redes.................................................................................................................9 Figura 6.1: Crear una accin nueva......................................................................................................20 Figura 6.2: Acciones para la gestin de MV's......................................................................................20 Figura 6.3: Panel de control VDI..........................................................................................................21 Figura 6.4: Creacin del cuadro VDI....................................................................................................23 Figura 7.1: Arquitectura de OSSIM......................................................................................................31 Figura 7.2: Esquema de generacin del riesgo.....................................................................................33 Figura 7.3: Cuadros de mando..............................................................................................................38 Figura 7.4: Riesgo: compromiso y ataque............................................................................................38 Figura 7.5: Panel de alarmas.................................................................................................................39 Figura 7.6: Panel de tickets...................................................................................................................40 Figura 7.7: Panel SIEM.........................................................................................................................40 Figura 7.8: Escaneos de vulnerabilidades.............................................................................................41 Figura 7.9: Lanzamiento de un escaneo................................................................................................41 Figura 7.10: Informe de vulnerabilidades.............................................................................................42 Figura 7.11: Generacin de informes...................................................................................................42 Figura 7.12: Activos de la red...............................................................................................................43 Figura 7.13: Servidor OCS...................................................................................................................44 Figura 7.14: Monitorizar registro con OCS..........................................................................................44 Figura 7.15: Polticas de OSSIM..........................................................................................................45 Figura 7.16: Acciones para las polticas...............................................................................................45 Figura 7.17: Directiva de correlacin...................................................................................................46 Figura 7.18: Regla de una directiva......................................................................................................47 Figura 7.19: Correlacin cruzada..........................................................................................................48
vii
Figura 7.20: NfSen................................................................................................................................49 Figura 7.21: Panel de Nagios................................................................................................................50 Figura 7.22: Plugins de un sensor.........................................................................................................50 Figura 7.23: Configuracin de usuarios de OSSIM.............................................................................51 Figura 7.24: Listado de plugins............................................................................................................52 Figura 7.25: SIDs de Snort....................................................................................................................52 Figura 7.26: Versin de OSSIM...........................................................................................................53 Figura 7.27: Copias de datos de Snort..................................................................................................54 Figura 7.28: Escaneo de redes..............................................................................................................55 Figura 7.29: Resultados de Net Discovery...........................................................................................55 Figura 7.30: Propiedades de nuevos hosts............................................................................................56 Figura 8.1: Arquitectura VMware.........................................................................................................58 Figura 8.2: vSphere Client....................................................................................................................58
viii
ndice de tablas
Tabla 3.1: Tareas de desarrollo...............................................................................................................5 Tabla 9.1: Logs de Windows................................................................................................................66
ix
1. OBJETIVOS
1. OBJETIVOS
1.1. Objetivos del proyecto
Actualmente y debido a la cada vez mayor sensibilizacin en materia de seguridad, en las empresas, cada vez se utilizan ms controles, tanto software como hardware, para mantener la seguridad de los entornos y cada control genera sus propios ficheros de log. Estos ficheros son heterogneos y normalmente se tornan difciles de manejar para un tratamiento manual, haciendo extremadamente compleja la bsqueda de informacin durante la gestin de incidentes de seguridad y haciendo inviable, por tanto, la toma de acciones preventivas en relacin al anlisis de dicha informacin. Con este proyecto, se pretende estudiar la aplicacin de una aproximacin preventiva a la gestin de la seguridad, en las empresas, utilizando para ello herramientas SIEM. Este tipo de herramientas, permiten salvar los inconvenientes anteriormente mencionados, centralizando diferentes ficheros de log, totalmente heterogneos entre s que, mediante la definicin de reglas avanzadas de correlacin, permiten conseguir el objetivo de proporcionar la inteligencia de seguridad suficiente como para que la herramienta nicamente genere aquellas alertas que no arrojen dudas acerca de su veracidad y por tanto, facilitando una gestin ms sencilla y eficiente de la seguridad. Con la correlacin de logs de seguridad se podra llegar a detectar ataques antes de que estos llegasen a suceder, constituyendo de esta forma un control de seguridad preventivo. Este enfoque permite aplicar controles de forma ms temprana durante el transcurso de un incidente de seguridad, minimizando e incluso pudiendo llegar a evitar por completo el impacto del mismo. En contraposicin, el enfoque reactivo, que se ha venido utilizado en mayor medida en las empresas para controlar la seguridad, no permite minimizar el impacto, dado que este ya ha tenido lugar cuando se detecta el incidente. En muchas ocasiones, dicho impacto podra llegar a daar seriamente la imagen de la empresa, pudiendo llegar a causar graves perjuicios econmicos. A todo esto, habra que aadir los costes de un posterior anlisis forense del incidente para descubrir la causa que lo provoc junto con los costes de aplicar los controles preventivos encaminados a minimizar y/o impedir que el incidente vuelva a suceder. Mediante la utilizacin de herramientas con enfoque preventivo, se persigue detectar incidentes antes de que estos lleguen a producir impacto alguno, contribuyendo activamente con una estrategia de reduccin de costes. La situacin de crisis actual ha hecho que el software libre sea un producto a tener en consideracin por muchas empresas para contribuir a la reduccin de costes. El proyecto pretender demostrar que las herramientas libres pueden aportar una funcionalidad equiparable en muchas ocasiones con sus equivalentes comerciales, y que realizando una configuracin adecuada, se puede llegar a construir un sistema de gestin de la seguridad con una muy buena relacin coste/eficiencia, que puede evitar grandes desembolsos econmicos a empresas que se encuentren en una situacin delicada, permitiendo as sacar adelante proyectos de seguridad que, de otra forma y debido a fuertes recortes presupuestarios, seran cancelados o post-puestos indefinidamente.
Mster Universitario en Seguridad de la Informacin - 2009-2010
La tendencia creciente del mercado de Tecnologas de la Informacin hacia la virtualizacin, y con especial relevancia la incipiente adopcin de la virtualizacin de escritorios (VDI), como un enfoque que mejora los costes a la vez que permite una mejor gestin de la seguridad, hace que la orientacin del presente proyecto a un entorno virtualizado, sea uno de las caractersticas ms reseables del mismo. Se vern las ventajas de utilizar servidores virtuales frente a servidores fsicos como el ahorro en costes y energa, o el mantenimiento ms sencillo y gil. Los entornos virtuales disponen de una serie de caractersticas especiales que los distinguen de los entornos fsicos a la hora de aplicar controles de seguridad. Por este motivo, se estudiar cmo es posible controlar la seguridad en una red virtual y cmo se puede implantar una herramienta SIEM en un entorno virtualizado.
1.2. Objetivos personales

Conocer en profundidad una herramienta SIEM, la importancia que tiene para seguridad de una empresa, y el papel que cumple dentro de sta. Comprender cmo funciona un correlador de eventos: qu informacin utiliza para tomar decisiones, cmo se generan las alarmas, etc. Es interesante observar como a travs de la concatenacin de eventos heterogneos procedentes de diversos programas, se pueden llegar a unas pocas alertas significativas de seguridad que facilitan la gestin del Responsable de Seguridad. Descubrir nuevas herramientas que sirvan para controlar la seguridad de una red como Snort que detecta patrones maliciosos en la red, OSSEC que informa sobre los logs del sistema operativo, OpenVAS para detectar vulnerabilidades en los servidores, Nagios, que monitoriza el estado en que se encuentran los servidores, OCS que mantiene un inventario del software y hardware de las mquinas, y otras aplicaciones ms sencillas pero igualmente importantes para gestionar la seguridad como ARPWatch, p0d o Pads. Conocer las caractersticas de la virtualizacin, as como las ventajas que ofrece frente a un entorno fsico, como el ahorro que supone en costes y la flexibilidad que ofrece en el mantenimiento. Aprender a gestionar la seguridad en este entorno, y que beneficios e inconvenientes conlleva la implantacin de un sistema de gestin de la seguridad en un entorno de semejantes caractersticas. Comprobar cmo la virtualizacin permite el aislamiento de escritorios y la centralizacin de medidas de control en los mismos a la vez que permite dar respuesta a escenarios de continuidad de negocio. Por ejemplo, actualmente, varias empresas estn poniendo en marcha plataformas de basadas en escritorios virtuales (VDI) para controlar las prestaciones de servicios crticos en manos de externos, tales como prestadores de servicios de TI, Call centers, etc., permitiendo mitigar riesgos asociados a puestos de trabajo no controlados en redes externas del proveedor: robo de informacin, cdigo malicioso, etc.. Comprender cmo funciona un firewall de nivel de aplicacin, as como la correcta configuracin de polticas y reglas, teniendo en cuenta que tiene que trabajar con el protocolo de una aplicacin especifica para la cual cumple la funcin de firewall. Por ltimo, aprender cmo se puede utilizar esta informacin para gestionar la seguridad del entorno de forma preventiva.
2. ALCANCE
2. ALCANCE
Como ya se ha mencionado el proyecto se ha desarrollado sobre un entorno virtualizado. Como software de virtualizacin de base se ha elegido VMware vSphere 4. Este entorno se ejecutaba sobre unas mquinas fsicas que hacan de servidores de virtualizacin. En este caso se han utilizado 2 servidores HP sobre los que corra VMware ESX 4.0.
Figura 2.1: Servidor HP
Caractersticas de cada servidor: 2 x Intel Xeon X5570 @ 2.93GHz. 8 GB RAM. 1 puerto gigabit Ethernet. 1 puerto 10 gigabit Ethernet. 1 disco duro SCSI de 100GB. Adems hay un almacenamiento iSCSI de 210GB compartido entre los 2 servidores. El presente proyecto se encontraba alineado con otro proyecto para el despliegue de VDI en la empresa en la que se ha desarrollado, con objeto de dotar de seguridad a los escritorios virtuales. Ambos proyectos se desarrollaban sobre la misma infraestructura aunque no se estableca una relacin directa entre ellos con objeto de realizar un trabajo lo ms independiente posible.
El entorno VMware descrito, es el entorno principal que se ha utilizado, sin embargo, se ha trabajado bajo otro entorno con menos recursos, que se puede describir como auxiliar. Este entorno auxiliar ha consistido en una instalacin de VMware Workstation sobre un ordenador de escritorio. Como la capacidad de ese host ha sido muy limitada, en este entorno virtual solo se ha podido instalar un servidor con la edicin de 32 bits de OSSIM y una mquina de pruebas con Windows XP. Como herramienta SIEM, el proyecto se ha limitado al uso de OSSIM por ser una herramienta libre muy extendida. Gracias a la gran cantidad de plugins que esta contiene permite correlar informacin de los logs de otras herramientas de seguridad de terceros ampliamente reconocidas en el mundo de la seguridad. Entre las herramientas que OSSIM incorpora se ha dedicado especial atencin a las siguientes: Nagios, para comprobar la disponibilidad de los equipos que se encuentran en la red y el buen funcionamiento de los servicios de estos. OSSEC, para la transmisin de logs de las mquinas de testeo a OSSIM. Snort, para la captura de trfico en la red. ARPWatch, para vigilar el valor de las direcciones MAC de las interfaces de red del entorno. OCS, para el listado de inventarios de software y hardware de las mquinas de testeo. OpenVAS, para el anlisis de vulnerabilidades de las mquinas de testeo. Uno de los objetivos ms interesantes del proyecto ha sido la integracin del OSSIM con VMware a travs de su API. Dicha integracin se ha limitado a conseguir la capacidad para apagar y encender mquinas virtuales desde el propio OSSIM. No ha pretendido conseguir una integracin completa que permitiera tomar acciones sobre las mquinas virtuales, como si se estuviera utilizando el vSphere Client, sino una funcionalidad mnima con la que quedara demostrada la capacidad de enviar ordenes a las mquinas virtuales sin la necesidad de tener una conexin directa con ellas, utilizando el API del entorno virtual.
3. PLANIFICACIN
3. PLANIFICACIN
El proyecto comenz el 1 de marzo y finaliz el 31 de junio. Durante este periodo de tiempo se le ha dedicado 5 horas al da de lunes a viernes. En la siguiente tabla se muestra la duracin planificada para cada tarea que compone el proyecto.
Tareas de desarrollo Recopilacin de la informacin requerida para iniciar las instalaciones Preparacin de la infraestructura de virtualizacin Preparacin y puesta a punto de la herramienta SIEM Preparacin de las mquinas de testeo Integracin del SIEM con el entorno virtual Preparacin del servidor web con firewall de nivel 7 Pruebas de las herramientas utilizadas y de las aplicaciones desarrolladas Redactar la documentacin que recoge todo el trabajo realizado
Tabla 3.1: Tareas de desarrollo
Das 15 4 6 6 18 4 13 14
En las siguientes figuras se muestran las fechas concretas marcadas para cada tarea:
Figura 3.1: Diagrama de Gantt I
Figura 3.2: Diagrama de Gantt II
Figura 3.3: Diagrama de Gantt III
Hay que tener en cuenta que a pesar de la planificacin que se realiz originalmente, algunas tareas se han desviado en el tiempo por su complejidad haciendo que fuera imposible dedicar tiempo a otras.
4. TAREAS
4. TAREAS
4.1. Recopilacin de informacin
En esta tarea se ha empleado una gran cantidad de tiempo con objeto de recopilar informacin precisa de apoyo para manejar correctamente las herramientas que se han utilizado. A pesar de no utilizar la informacin a medida que se adquira, se ha tomado nota cada vez que se consegua algo interesante que pudiera aportar algn valor al proyecto o que se pudiera necesitar posteriormente. Como herramienta SIEM para desarrollar el proyecto se ha decidido utilizar OSSIM, por ser software libre y por tener reconocido prestigio entre las herramientas SIEM del mercado. Es un software que para su correcto funcionamiento se apoya en programas externos de cdigo abierto muy reconocidos en el mundo de la seguridad, para los cuales es preciso recolectar informacin para comprender su funcionamiento. Por este motivo, la recoleccin de informacin sobre la herramienta SIEM no se ha limitado a buscar documentacin de OSSIM sino que tambin ha sido imprescindible documentarse sobre las herramientas que la componen. Algunas de estas herramientas son Snort, OpenVAS, Nagios y OSSEC. Otro objetivo que ha requerido una mayor labor de investigacin es la integracin de OSSIM con el servidor VMware. Para llevar a cabo el objetivo de monitorizar y manipular los servidores virtuales desde el propio SIEM ha sido imprescindible buscar informacin detallada sobre la API de VMware. La mayor parte de la informacin se ha conseguido a travs de las documentaciones oficiales y buscadores, pero otras fuentes muy recurridas han sido la utilizacin de listas de distribucin y foros, donde se ha podido discutir directamente con gente sobre las cuestiones que iban surgiendo a lo largo del proyecto.
4.2. Preparacin de la infraestructura de virtualizacin

Aunque se tenga que trabajar con hardware virtualizado esto no cambia los requisitos hardware con respecto al hardware fsico que se utilizara. En primer lugar, se han tenido que establecer estos requisitos hardware para cada una de las mquinas del proyecto, que posteriormente seran utilizados por las mquinas virtuales. Una vez establecidos estos requisitos se ha decidido sobre el entorno de virtualizacin donde se reservaran estos recursos para su utilizacin en el proyecto. Se ha seleccionado un entorno VMware vSphere 4 compartido con otros proyectos para hacer un aprovechamiento ms ptimo de los recursos. Adems de la determinacin de los requisitos de hardware, se ha establecido una red virtual con
acceso a Internet que solo fuera utilizada por los servidores pertenecientes al proyecto con el fin de evitar conflictos con el resto de mquinas. Una de las herramientas que integra OSSIM, Snort, tiene la capacidad de capturar todo el trfico que pasa por su interfaz de red configurada en modo promiscuo. Por este motivo, ha sido imprescindible una configuracin de la red que permitiera que todo el trfico de la red llegara a esta interfaz. En el caso de la red virtual, los equipos estaban conectados mediante switches, y estos impedan que el trfico entre 2 equipos fuera capturado por los dems, haciendo intil la interfaz promiscua. Para solucionar este problema ha sido necesario configurar Por-Mirroring en los switches de la red. Con el Port-Mirroring el trfico que pasa por el switch es redirigido a una de sus interfaces.
Figura 4.1: Port-Mirroring
Al hacer Port-Mirroring, hay que tener en cuenta que no se debe mandar ms trfico del que se necesita: Trfico duplicado. Esto podra pasar si se configura Port-Mirroring en 2 switches de la misma red. Trfico que no se puede analizar. Si una red se va a usar como VPN de nada sirve capturar el trfico porque no se puede analizar. Lo mismo ocurre con las conexiones cifradas: HTTPS, SSH, etc. Sin embargo, debido a que el entorno era compartido con otros proyectos, no ha sido posible configurar esta caracterstica en los switches, y las herramientas de captura de informacin de la red no han funcionado. Tambin ha sido crucial la configuracin del firewall de la red virtual. OSSIM incluye OpenVAS como componente para mostrar las posibles vulnerabilidades de las mquinas de la red y para que este pudiera funcionar era imprescindible dar permisos de conexin desde el servidor OSSIM hasta las mquinas del entorno.
4. TAREAS
4.3. Preparacin y puesta a punto de la herramienta SIEM

Esta tarea incluye la descarga de OSSIM de Internet, la preparacin de una mquina virtual y la instalacin de OSSIM en esta. Para el desarrollo del proyecto se ha utilizado la versin 2.2.1 y la edicin de 64 bits. Despus de la instalacin, se ha actualizado el sistema a la ltima versin y se han configurado todos los parmetros necesarios para que funcionara la herramienta. Para obtener un mayor detalle al respecto, se puede consultar el punto 7.8 (Administracin SSH). Una vez comprobado el correcto funcionamiento de OSSIM, se ha procedido a la instalacin de las VMware Tools para tener un rendimiento ptimo en el sistema. Se pueden encontrar los pasos en el punto 8.1.1 (VMware Tools). Por ltimo, se ha agregado a la parte de activos de OSSIM la red en la que est ubicado para que cuando se tuvieran las mquinas de testeo estas se pudieran escanear.
Figura 4.2: Creacin de redes
4.4. Preparacin de las mquinas de testeo

Para hacer las pruebas del sistema se ha decidido utilizar un par de mquinas virtuales con Windows para simular ataques entre ellas. Una se ha utilizado como atacante, y la otra como vctima. El atacante no tendra porque ser un usuario malintencionado, sino que podra ser un ordenador personal cuya seguridad ha sido comprometida, por ejemplo con una botnet, y se ha convertido en una amenaza para el resto de la red local sin que el propio usuario del equipo lo supiera, existen multitud de escenarios posibles. Entre todos los Windows, se ha decidido utilizar Windows XP por consumir pocos recursos y ofrecer una gran compatibilidad con los programas actuales. Adems de esto, son ms conocidas sus vulnerabilidades lo que lo convierte en un sistema perfecto para realizar las pruebas de ataques. Para la preparacin de las mquinas de testeo, se ha creado una mquina virtual, se ha instalado
Windows XP en ella, se ha configurado la red, se han instalado las VMware Tools y por ltimo, aprovechando las caractersticas de la virtualizacin, est mquina se ha duplicado desde el vClient, consiguiendo as dos mquinas virtuales con Windows iguales. Una vez preparadas en la red las mquinas virtuales con Windows, estas han sido agregadas a la parte de activos de OSSIM para tenerlas identificadas por la herramienta y que fuera ms sencillo identificarlas en la lista de eventos. Sobre las mquinas de testeo, se ha realizado la instalacin del software OSSEC para monitorizar la seguridad de los sistemas. Con este software se ha conseguido transmitir informacin relevante desde los sistemas con Windows a OSSIM, esto incluye: Logs de seguridad y del sistema. Logs de aplicaciones. Alteracin de ficheros importantes, como los ficheros de arranque boot.ini y autoexec.bat. Alteracin de entradas de registro, como las entradas que se cargan al arrancar el sistema. Tambin se ha instalado la herramienta de inventario OCS que ha permitido transmitir de forma automtica una lista detallada del hardware y el software que contiene cada mquina Windows. Esto ha permitido conocer, por ejemplo, si se instalaba algn software nuevo que no fuera deseado, o si se ha actualizado el sistema, ya que tambin informa de las versiones de los programas.
4.5. Integracin del SIEM en el entorno virtual

Esta tarea ha sido una de las que ms tiempo ha tomado, ya que ha supuesto integrar dos herramientas de software totalmente heterogneas e inconexas, para establecer una comunicacin entre ellas, por un lado OSSIM y por el otro el servidor VMware. Para conseguir esta comunicacin, ha sido indispensable la utilizacin del API de VMware, VIX. Este API permite desarrollar herramientas para comunicarse con el servidor VMware, pero en este caso no ha sido necesario utilizar el API para desarrollar, dado que el mismo paquete de software trae consigo un programa, llamado vmrun, que ya realiza estas funciones. As que desde el servidor SIEM se ha descargado el API y se ha instalado segn los pasos explicados en el captulo 8.1.2. Inmediatamente despus ya era posible lanzar el comando vmrun. No obstante para que la comunicacin funcionara, ha sido imprescindible conceder, desde el firewall de la red, los permisos para conectar desde el servidor OSSIM al servidor VMware. Una vez conocido que era posible establecer la comunicacin, se ha procedido a desarrollar el software que permitiera una integracin profunda entre OSSIM y el entorno VDI. Se han creado acciones para el encendido y el apagado automtico de mquinas virtuales (punto 6.1). Estas acciones se han utilizado dentro de polticas para reaccionar de forma automtica ante distintos eventos, por ejemplo, para evitar la expansin de una infeccin por la red o un ataque DoS, se puede apagar la mquina que est lanzando las conexiones, y
10
4. TAREAS
as evitar que lleguen a producir un mayor impacto. Se ha creado un cuadro de control VDI en el cual se puede observar una lista de las mquinas virtuales y comprobar si se encuentran encendidas o apagadas (punto 6.2). Adems, en el cuadro se ha implantado un enlace que permite apagar o encender estas mquinas con un solo clic. Este cuadro administrativo ha permitido un manejo sencillo de las mquinas virtuales desde el propio cuadro de mando de OSSIM. Se ha desarrollado un plugin capaz de normalizar la informacin del log VDI, de forma que pueda ser procesado por el SIEM y correlado junto al resto de eventos del entorno (punto 6.3).
4.6. Preparacin del servidor web con firewall de nivel 7

Para la realizacin de esta tarea, se ha creado una mquina virtual en el entorno de pruebas y se le ha hecho una instalacin de la ltima versin estable de Debian. En el servidor Debian, se ha hecho una instalacin del servidor web Apache y se le ha aplicado el mdulo ModSecurity como firewall de nivel de aplicacin. Por falta de tiempo, no se ha podido integrar el log de ModSecurity en OSSIM. Para conseguir este objetivo se pretenda instalar un agente de OSSIM en el servidor web que monitorizara los logs de Apache y de ModSecurity mediante los plugins que ya estn desarrollados. El agente ira conectado al servidor OSSIM para comunicarle los eventos del servidor web y del firewall.
4.7. Realizacin de pruebas

Durante la instalacin y configuracin de los hosts, se han hecho pequeas pruebas que garantizaban el correcto funcionamiento de la infraestructura para evitar que fuera un problema a la hora de hacer las pruebas conjuntas. De la misma forma, los desarrollos se han ido probando paralelamente, de forma individual, asegurando en todo momento que cuando comenzaba un desarrollo nuevo, los anteriores, de los que dependa, funcionaban correctamente. Cuando se tena toda la infraestructura preparada se han hecho pruebas conjuntas para demostrar el funcionamiento del sistema. El entorno de pruebas ha sido un entorno virtual VMware vSphere en el que se ha utilizado un servidor OSSIM como herramienta de seguridad SIEM y dos mquinas de testeo para simular ataques con Windows XP. Lamentablemente, las pruebas han estado muy limitadas por no haber podido activar el portmirroring en los switches. Esto ha hecho imposible la utilizacin de Snort en este entorno ya que era incapaz de capturar trfico de red. Afortunadamente, gracias al entorno auxiliar con VMware Workstation, se han podido realizar
11
algunas pruebas, aunque limitadas por los recursos. En este entorno si que funcionaba la captura de trfico, pero por la limitacin de recursos solo se contaba con una mquina de testeo adems del servidor SIEM, que tena un rendimiento muy bajo. En el entorno auxiliar se han lanzado escaneos de puertos utilizando Nmap desde el equipo de testeo. Esto, por defecto, no generaba ninguna alarma en OSSIM pero si se registraban los eventos. El motivo por el cul no generaba alarmas, era que el riesgo de tal evento no era alto. As que se decidi hacer una segunda prueba despus de subir el valor del activo de la mquina de testeo y la prioridad del evento de escaneo de puertos. La segunda prueba fue ms exitosa ya que al capturar los eventos del escaneo de puertos, el riesgo era alto y se generaba una alarma automticamente. En el entorno principal de pruebas, se ha comprobado cmo se activa una directiva con la que detectar varios intentos fallidos de acceso a la mquina. Para realizar esta prueba, se ha intentado entrar en la mquina con Windows escribiendo mal la contrasea. Si no se hacan muy rpidos los intentos, en OSSIM se poda observar el fallo pero no se generaba ninguna alarma. Sin embargo, cuando se han hecho varios intentos seguidos, se han detectado los mltiples fallos y se ha lanzado una alarma informando de lo sucedido. En esta prueba adems ha quedado demostrado el funcionamiento de OSSEC que es el encargado de transmitir el log de Windows a OSSIM. Se ha probado el anlisis de vulnerabilidades que hace OpenVAS en OSSIM. Para ello, se ha escaneado uno de los hosts con Windows XP, y se han descubierto algunas vulnerabilidades de gravedad baja como el servicio de comparticin de archivos de Windows. Otras pruebas realizadas han sido la creacin de polticas. En el visor de eventos del SIEM aparecan falsos positivos con demasiada frecuencia y esto haca muy incmoda la gestin. A travs de polticas se han filtrado esos falsos positivos, dejando claramente a la vista los eventos realmente importantes, facilitando el trabajo del Responsable de Seguridad. El cuadro de control VDI se ha probado en profundidad para garantizar su correcto funcionamiento, dado que esta parte ha sido desarrollada en el propio proyecto. Se han arrancado mquinas pulsando el enlace 'Encender' y se ha podido observar como el cuadro cambiaba al de unos segundos el estado de las mquinas a arrancado, luego se han apagado pulsando 'Apagar' y rpidamente pasaban su estado a apagado. Paralelamente, se ha comprobado mediante el cliente de VMware, que estos cambios funcionaban como se esperaba. Antes de terminar el desarrollo completo de los scripts, se ha comprobado la seguridad que ofreca. Se ha hecho inyeccin de comandos en la URL pasados como parmetros y efectivamente se ha descubierto que se ejecutaban esos comandos. Estos errores han sido corregidos con objeto de aumentar el de nivel de seguridad del desarrollo. Mientras se lanzaban las ordenes de apagado y encendido de mquinas se ha observado que en el visor de eventos aparecan las ordenes indicando qu mquina se estaba apagando o arrancando. Se ha considerado de inters la inclusin de estos eventos en el SIEM porque de esta forma, esta informacin podra ser utilizada en la creacin de directivas, con objeto de dotar al sistema de mayor inteligencia. Habra sido interesante integrar los eventos de los logs del servidor web y del firewall de nivel 7 con
12
4. TAREAS
el resto de eventos capturados por OSSIM, y activar acciones reactivas cuando se detecte algn intento de ataque. Pero la falta de tiempo ha hecho imposible la integracin de esta informacin.
4.8. Redaccin de la documentacin

Como ltima tarea del proyecto se ha recogido todo el trabajo realizado en una documentacin. Esta se ha redactado estructurando las tareas en grupos de forma que quedaran explicadas de forma clara, sin entrar en mucho detalle, las actividades y experiencias realizadas. En cada tarea se ha hecho referencia a los anexos donde se han hecho explicaciones tcnicas de los procesos seguidos para que si se desea se puedan reproducir en cualquier momento. Como uno de los objetivos de este proyecto es la utilizacin de todo el software libre posible, se ha mantenido esta filosofa a la hora de hacer la documentacin. Para redactar la documentacin se ha utilizado OpenOffice Writer, que ha permitido, mediante el uso de estilos, agilizar el uso de referencias dentro de la documentacin y de ndices. Para la modificacin de las figuras se ha usado Gimp. Esta herramienta ha permitido recortar las imgenes para mostrar en la documentacin lo realmente importante. Para la creacin de diagramas Dia ha sido de gran utilidad, ya que es una herramienta muy sencilla que sin conocerla ha permitido la creacin de diagramas estupendos. Y por ltimo, para la creacin de diagramas de Gantt se ha utilizado OpenProj.
4.9. Control peridico

Durante toda la fase de desarrollo se ha realizado un seguimiento peridico del estado del proyecto. El control se ha realizado a travs de reuniones cada 2 semanas aproximadamente. El objetivo de estas reuniones era detectar problemas que bloqueasen el avance del proyecto, buscar soluciones a estos problemas, y discutir sobre nuevos puntos de inters que se hayan descubierto en los que mereciera la pena indagar.
13
5. CONCLUSIONES
5. CONCLUSIONES
5.1. Anlisis de resultados
Despus de probar OSSIM, he observado que es un proyecto muy interesante porque no solo es un software de gran utilidad para las empresas, sino que adems es libre, lo que supone un coste nulo a la hora de adquirirlo para el que lo quiera implantar. No obstante, es una herramienta que exige muchas horas de trabajo para hacer un buen tunning y que funcione correctamente, lo que supone un gran coste de gestin y mantenimiento. Se ha comprobado cmo, a partir de muchas fuentes heterogneas de informacin, el SIEM destacaba nicamente un pequeo grupo de eventos. Esto facilita enormemente la tarea del Responsable de Seguridad, al permitir obtener informacin precisa sobre los incidentes de seguridad fcilmente sin que sea necesario revisar todos los ficheros de las aplicaciones de seguridad, que tomara una gran cantidad de tiempo. Pero la inteligencia que ofrece la herramienta ha ido ms all, porque ha sido capaz de correlar estos eventos en busca de patrones que sugirieran un ataque, y en el momento que lo ha detectado, ha lanzado una alarma informando del suceso. Esto ha demostrado que se puede prevenir un incidente si se conocen los eventos que le preceden, por esto es muy importante tener unas polticas correctamente configuradas y actualizadas, adecuadas a la Poltica de Seguridad de la empresa dnde se implante. Aunque OSSIM traiga preinstalado un grupo de polticas, el verdadero trabajo del Responsable de Seguridad reside en configurar las polticas que se necesitan para un entorno concreto, tarea que debe llevarse a cabo por personas con conocimientos detallados sobre la arquitectura de seguridad y Poltica de Seguridad de la empresa. Se ha podido comprobar la idoneidad de tomar un enfoque preventivo en seguridad, frente al tradicional enfoque reactivo. As, por ejemplo, en la prueba que se ha hecho en la que se intentaba entrar repetidamente en Windows sin conocer la contrasea, OSSIM ha lanzado una alarma para avisar de tal suceso con objeto de que se pudieran tomar medidas. Sin este tipo de herramientas, toda esta informacin de intentos de acceso habra quedado registrada en el log pero no se habra tomado accin alguna. En cuanto a la integracin de OSSIM con la API de VMware, he comprobado que se pueden lanzar acciones de VMware desde cualquier mquina. Se ha desarrollado algo bastante simplificado para comprobar si se pueden manejar MV's desde una herramienta SIEM, y se ha descubierto que efectivamente es posible. Se puede hacer un cuadro de mando configurable desde donde mandar acciones a las mquinas virtuales. Las acciones a las MV's se han limitado a dos, encender y apagar, pero con el mismo comando utilizado, tambin se pueden gestionar ficheros y ejecutar comandos. Adems, como se ha visto, no solo se pueden lanzar ordenes de forma manual, sino que se pueden predefinir y ejecutarlas automticamente cuando sea necesario mediante polticas.
15
5.2. Puntos de mejora

En este desarrollo, tan solo se han creado las acciones para apagar y encender MV's, pero en realidad se podran haber realizado otras ms. En el punto 8.1.3 se describen las funcionalidades que se pueden tener con vmrun. La manipulacin de snapshots es una caracterstica muy interesante dado que permite modificar el estado de una mquina a otro anterior, por ejemplo una mquina cuya seguridad se ha visto comprometida se podra restaurar a un estado correcto. El uso de vmrun para ejecutar programas en mquinas virtuales con Windows XP funciona muy bien pero desde Windows Vista, con la inclusin del UAC como medida de seguridad, esto no es tan sencillo. Existe un mtodo que consiste en la creacin de una tarea en el programador de tareas para que sea ejecutada por un usuario con permisos, y lanzar la tarea desde un archivo por lotes. El problema de esto, es que se necesita predefinir todas las tareas que se vayan a realizar eliminando parte de la flexibilidad de vmrun. Se podra investigar otro mtodo que proporcione mayor flexibilidad y que no obligue a desactivar el UAC. Me habra gustado integrar el log de ModSecurity en OSSIM. Un servidor web es uno de los principales objetivos de los delincuentes por su mayor exposicin a ataques, y por esta razn, la informacin que puede proporcionar un firewall de aplicacin sera muy valiosa para el correlador de eventos. Por este motivo, estimo como una gran mejora la transmisin de los logs del servidor Apache y del mdulo de firewall al servidor OSSIM. Sera muy interesante comprobar cmo al hacer una consulta contra el servidor web con una URL sospechosa, aparece esta informacin en el visor de eventos.
5.3. Conclusiones personales

Haba odo hablar de OSSIM y tena una ligera idea acerca de su funcionamiento, pero ahora lo he podido observar con detalle. He probado cada panel en profundidad, algunos me han parecido muy interesantes, como el visor de eventos o el cuadro de mando, otros en cambio, me han parecido mejorables, como las descargas o las copias de seguridad. A pesar de la edad que tiene el proyecto OSSIM, he notado que tiene bastantes deficiencias, que al principio podran dar la sensacin de software inmaduro. Tras hacer la instalacin hay elementos fundamentales para el funcionamiento de OSSIM que no arrancan por configuraciones incompletas que se podran hacer de forma automtica. He notado que la versin de 32 bits est bastante abandonada si se compara con la de 64 bits, el instalador ni siquiera iniciaba el proceso de instalacin y algunos de los componentes de la administracin web, como el analizador de vulnerabilidades, no funcionaban. La documentacin se puede decir que es bastante catica y est tan obsoleta que contiene pginas explicando paneles que no existen en el OSSIM actual o al revs, no existe la ayuda para el panel que quieres consultar. Todo esto, supone que todos los enlaces de ayuda de los paneles de OSSIM apuntan a pginas web que, actualmente, ya no existen.
16
5. CONCLUSIONES
La comunidad que tiene en sus foros tiene un tamao reducido aunque es bastante activa. Sin embargo no se percibe que la gente de OSSIM tenga en consideracin las pequeas aportaciones de los participantes. A pesar de todo esto, si se configura correctamente, y se hace un buen tunning, se consigue un correlador de eventos que podra competir directamente con soluciones comerciales anlogas. La creacin de directivas de correlacin me ha parecido una tarea muy compleja, y no me refiero al editor de directivas, sino al propio hecho de saber qu eventos tienen que formar parte de una directiva para que sta funcione correctamente, as como, los plugins que se deben incluir en sta. Mayormente, he utilizado las directivas predefinidas en OSSIM, ya que realizar unas directivas especializadas en el entorno requiere de mucho tiempo y unos conocimientos muy avanzados de la red y de la arquitectura de seguridad de la empresa. A lo largo de este ao, me he encontrado en varias empresas con VMware vSphere e incluso lo he podido utilizar. Haba trabajado con Workstation pero me he dado cuenta de que es muy diferente la funcionalidad. El hecho de tener mquinas virtuales ejecutndose a lo largo de varias mquinas fsicas proporciona una gran flexibilidad. No hay que limitarse a pensar que una mquina est bajo un servidor porque se puede apagar el servidor y la mquina virtual sigue ejecutndose. Tan solo esta caracterstica me parece que le da ya un gran valor a la virtualizacin por encima de tener servidores fsicos. En cuanto a la seguridad en entornos virtuales, hay claras ventajas al tener los escritorios centralizados en un servidor. Al tener los escritorios aislados del exterior de la estructura empresarial, se minimizan los riesgos existentes en los escritorios tradicionales. La probabilidad de que se produzca una perdida o robo de informacin es muy baja, y esto ayuda tambin al cumplimiento de normativas , de carcter crtico, como la LOPD. Sin embargo, los programas de seguridad tradicionales no consiguen obtener muchas ventajas de la virtualizacin. La complejidad para controlar la seguridad en una red virtual me ha parecido muy similar a la de una red fsica, bsicamente hay que aplicar los mismos controles. No obstante, he averiguado que VMware est trabajando en cambiar esto con su tecnologa VMSafe, con la que ofrece a las herramientas de seguridad una serie de ventajas o accesos especiales a las mquinas virtuales del entorno para controlarlas externamente. De la misma forma creo que con el desarrollo del presente proyecto, se ha roto esa barrera que existe entre las herramientas de seguridad y los entornos virtualizados, obteniendo ventajas reales, como han sido el arranque y apagado de MV's en este caso. Como consecuencia de haber trabajado profundamente con OSSIM he encontrado nuevas aplicaciones que no conoca. Algunas, gracias a que han dado ms problemas para que funcionaran, las he conocido con ms detalle que otras. He descubierto que Nagios realiza pings a las mquinas que se le hayan indicado con el objetivo de saber si estas se encuentran en linea o no. De forma similar realiza conexiones contra los servicios que se le hayan indicado, si alguno no responde como debe, se graba una entrada en el correlador de eventos. Sin embargo, esta aplicacin no se encuentra muy bien integrada en OSSIM. Me ha parecido una herramienta estupenda para monitorizar el
17
estado de cualquier mquina, pero la utilizacin desde OSSIM se limita a comprobar si las mquinas y sus servicios estn arrancados y respondiendo, no pudiendo saber el estado la memoria RAM o la CPU, que tambin son funcionalidades de Nagios si se usan agentes. Me habra gustado conocer con ms profundidad OpenVAS. Su utilizacin desde OSSIM ha sido completamente transparente ya que se utiliza a travs de la administracin web. OCS es una aplicacin que realiza inventarios del software y hardware instalado en las mquinas y centraliza toda esta informacin en un servidor. Este software tiene muchas ms opciones que no he podido ver, adems la integracin en OSSIM no pareca muy buena por lo que no invitaba a usarlo. Snort es el detector de intrusos de red por excelencia y est perfectamente integrado en OSSIM. Cuenta con muchas reglas avanzadas para la deteccin de intrusos en la red. Las reglas cuentan con una condicin que cuando un grupo de paquetes detectados en la red la cumplen se activa la regla. Adems sus reglas se pueden actualizar automticamente utilizando la aplicacin oinkmaster. OSSEC ha funcionado perfectamente durante las pruebas comunicando cada evento que suceda en las mquinas de testeo. Realmente ha sido mi herramienta favorita por la facilidad con la que se instala y lo bien que funciona. Sin embargo, esta herramienta ha supuesto tener una conexin contra el servidor OSSEC que se encontraba en OSSIM, lo que condiciona bastante el medio. Se deben permitir conexiones entrantes desde todos los hosts a OSSIM y los hosts deben tener IP's fijas. ARPWatch detecta cambios en la direccin MAC de un equipo. No conozco ningn buen motivo para que un equipo sufra un cambio de su MAC, por lo que detectar esto, es un buen indicio de que hay alguien con malas intenciones. He observado que tiene problemas con equipos con ms de una interfaz, por ejemplo el servidor OSSIM que tiene dos interfaces era detectado como si cambiara su MAC, tal vez el problema fuera la mquina virtual, habra que investigarlo. Pads y p0f tambin vienen integradas en OSSIM y funcionan desde el inicio. Estas herramientas detectan los servicios y los sistemas operativos de las mquinas que se encuentran en la red e incuso fuera de ella en otras redes. Snort, ARPWatch, Pads y p0f son absolutamente silenciosas ya que no generan nada de trfico. Se quedan escuchando en la interfaz de red promiscua y sacan toda su informacin de los paquetes que toquen la interfaz. Y es por este motivo que no pueden ser detectadas convirtindose en unas herramientas muy importantes. Apenas he podido trabajar con ModSecurity, pero al comprender lo que era un firewall de nivel 7, me he dado cuenta de que llevo mucho tiempo utilizando uno a nivel domstico. El router que tengo en casa me permite bloquear directamente aplicaciones o patrones de URL's, cosa que utilizo para bloquear la publicidad de las pginas web.
18
6. Anexo A: DESARROLLO TCNICO

6.1. Acciones
Una vez que se ha instalado el API de VMware VIX, ya se pueden lanzar comandos contra el servidor VMware con objeto de ejecutar acciones contra las mquinas virtuales. Para hacer esto hay que indicar el fichero vmx de la MV que se encuentra en el servidor ESX, por ejemplo:
vmrun -h http://172.18.40.58/sdk -u vmadmin -p adminpass -gu administrador -gp ospass start [DSII] WinXP.vmx
El problema es que la nica informacin que tiene OSSIM para identificar los equipos es su IP. Una solucin es crear un fichero de configuracin en el que se relacionen las IP's con el fichero vmx.
172.18.40.75 [DSII] WinXP.vmx 172.18.40.76 [DSII] WinXP-COPIA.vmx
Para esto, se necesita un programa que traduzca la peticin de arrancar la mquina 172.18.40.75 a arrancar [DSII] WinXP.vmx. Para esto se ha realizado el siguiente script que recibe la IP de la mquina y un 0 o 1 si se quiere apagar o encenderla.
grep $1 /root/vdi/maquinas | while read p_ip p_ruta do if [ $2 = 1 ] then # ENCENDER vmrun -h http://172.18.40.58/sdk -u vmadmin -p adminpass -gu administrador -gp ospass start "$p_ruta" echo "$1 encendido" else # APAGAR vmrun -h http://172.18.40.58/sdk -u vmadmin -p adminpass -gu administrador -gp ospass stop "$p_ruta" soft echo "$1 apagado" fi done
El script obtiene, filtrando el fichero de configuracin, el fichero vmx que corresponde a la IP indicada y con esto ya puede lanzar el comando vmrun. Se asume que la contrasea de administrador va a ser la misma para todos los equipos, si no fuera as solo habra que introducirlas en el fichero de configuracin y obtenerlas de la misma forma que el fichero vmx. Con este pequeo desarrollo ya se pueden definir acciones en OSSIM con argumentos variables para que se puedan automatizar.
19
Figura 6.1: Crear una accin nueva
Un uso muy prctico sera crear las acciones para encender o apagar la mquina origen o destino de un evento. Y mediante el uso de polticas se podran programar estas acciones como respuesta a ante diferentes eventos.
Figura 6.2: Acciones para la gestin de MV's
Un ejemplo sera la creacin de una poltica que detecte si una mquina est realizando demasiadas conexiones a sus vecinas, una mquina infectada por algn virus o troyano, y que automticamente se envi una orden de apagar la mquina para evitar que se expanda la infeccin y se enve correo electrnico al responsable informndole de lo sucedido.
6.2. Panel de control VDI

Las acciones que se han creado en el apartado anterior sirven para automatizar respuestas pero no
20
para tomar acciones manuales. Sera muy interesante poder ver en el cuadro de mando de OSSIM el estado de las mquinas y poder ejecutar acciones con un solo clic. Para conseguir este objetivo se ha realizado un cuadro que muestra una lista con las IP's y los nombres de los hosts del entorno virtual. Al lado de cada host se muestra, con un circulo verde o rojo, si la mquina est encendida o apagada, y un enlace para lanzar la accin de apagado o encendido. En la figura 6.3 se puede observar el cuadro.
Figura 6.3: Panel de control VDI
OSSIM permite personalizar la pgina principal creando ms cuadros con la informacin que se quiera as que se ha agregado un cuadro ms y se ha configurado para que muestre un fichero RSS. Este fichero se ha generado a partir del fichero de configuracin mencionado antes, al que se ha agregado algo ms de informacin: nombre del host y estado.
############ Fichero: maquinas.cfg ############ 172.18.40.75 WindowsSeg-75 172.18.40.76 WindowsSeg2-76 %%on%% %%on%% [DSII] WinXP.vmx [DSII] WXP.vmx
El fichero de configuracin 'maquinas.cfg' ha sido procesado por el siguiente script para generar automticamente el RSS.
############ Fichero: procesar.sh ############ #!/bin/bash entrada=/root/vdi/maquinas.cfg salida=/usr/share/ossim/www/vdi/rss.xml verde="<img align=top src=http://172.18.40.74/ossim/vdi/verde.png>" rojo="<img align=top src=http://172.18.40.74/ossim/vdi/rojo.png>" alterar="<a href=\"/ossim/vdi/alterar.php?i="; apagar="&a=0\">Apagar</a>"; encender="&a=1\">Encender</a>";
21
echo "<?xml version=\"1.0\"?>" > $salida echo "<rss version=\"2.0\">" >> $salida echo -e "\t<channel>" >> $salida cat $entrada | while read ip nombre estado ruta do echo -e "\t\t<item>" >> $salida echo -ne "\t\t\t<description>$ip - $nombre " >> $salida if [ $estado = %%on%% ] then echo -e "$verde -- $alterar$ip$apagar</description>" >> $salida else echo -e "$rojo -- $alterar$ip$encender</description>" >> $salida fi echo -e "\t\t</item>" >> $salida done echo -e "\t</channel>" >> $salida echo "</rss>" >> $salida exit 0
Este script ha generado el siguiente fichero RSS en la ruta /usr/share/ossim/www/vdi/rss.xml que se puede mostrar en el cuadro de mando utilizando la ruta http://172.18.40.74/ossim/vdi/rss.xml.
############ Fichero: rss.xml ############ <?xml version=1.0?> <rss version=2.0> <channel> <item> <description>172.18.40.75 WindowsSeg-75 <img align=top src=http://172.18.40.74/ossim/vdi/verde.png> <a href=/ossim/vdi/alterar.php? i=172.18.40.75&a=0>Apagar</a></descripcion> </item> <item> <description>172.18.40.76 WindowsSeg2-76 <img align=top src=http://172.18.40.74/ossim/vdi/rojo.png> <a href=/ossim/vdi/alterar.php? i=172.18.40.76&a=0>Encender</a></descripcion> </item> </channel> </rss>
22
En el cuadro de mando de OSSIM se ha pulsado en el enlace 'Edit' que aparece a la derecha para agregar ms cuadros. Se ha elegido uno para modificarlo como cuadro de control VDI. Se le ha puesto un ttulo, se ha seleccionado RSS Feed y se ha indicado la ruta del fichero rss.xml. Se han aplicado los cambios y se ha conseguido el cuadro que se mostraba antes en la figura 6.3 (Panel de control VDI).
Figura 6.4: Creacin del cuadro VDI
Al cuadro de control VDI se le han puesto unos enlaces para encender y apagar las MV's. Esto ha desencadenado la necesidad de crear una pgina web capaz de ejecutar procesos. Ya que OSSIM tiene PHP instalado se ha decidido utilizar esta tecnologa. Cuando se haga clic en algn enlace del fichero RSS se carga la web PHP que realmente no lleva nada visible, tan solo ejecuta las acciones pertinentes sobre la mquina seleccionada. A continuacin se muestra el fichero PHP que es llamado desde los enlaces.
############ Fichero: alterar.php ############ <?php // menu authentication require_once('classes/Session.inc'); require_once('classes/Security.inc'); Session::logcheck("MenuControlPanel", "ControlPanelExecutive"); header("Location: ../panel/panel.php"); function isIpaddr ($ipaddr){ $patron = '/^([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9] {1,3})$/'; if (preg_match($patron, $ipaddr, $digit)){ if (($digit[1] <= 255) && ($digit[2] <= 255) && ($digit[3] <= 255) && ($digit[4] <= 255)){ return TRUE; }
23
} return FALSE; }; function esAccion ($acc){ if (preg_match('/^[0-9]$/', $acc)){ if ($acc <= 1){ return TRUE; } } return FALSE; }; $ip=$_GET['i']; $accion=$_GET['a']; $ipremota=$_SERVER['REMOTE_ADDR']; # Validar que la ip sea correcta if (!isIpaddr($ip)){ exec("/root/vdi/logear.sh '_._._._' '_' '$ipremota' 'ERROR1 IP erronea.'"); # Validar la accion }elseif (!esAccion($accion)){ exec("/root/vdi/logear.sh '$ip' '_' '$ipremota' 'ERROR2 Accion desconocida.'"); # Validar que la ip no sea la del servidor }elseif ($ip == $_SERVER['HTTP_HOST']){ exec("/root/vdi/logear.sh '$ip' '_' '$ipremota' 'ERROR3 IP del servidor.'"); # Los parametros son correctos }else{ exec("/root/vdi/logear.sh '$ip' '$accion' '$ipremota' 'OK'"); exec("/root/vdi/alterar.sh '$ip' '$accion'"); } ?>
Ha sido necesario controlar la seguridad de esta web por ser sensible a ataques. A pesar de no mostrar nada, ejecuta procesos y si no se hubiera prestado atencin a esto se podran inyectar comandos de forma maliciosa. Para controlar la seguridad en este pequeo desarrollo, en primer lugar, se ha validado la sesin del usuario. Si el cliente web no tiene una sesin vlida no se le permite hacer nada. En segundo lugar, se han validado los parmetros que recibe el fichero PHP para
24
garantizar que son una IP y un nmero y no la ejecucin de un proceso. Por ltimo, se ha mantenido un log que registra cada accin y error que haya surgido.
############ Fichero: logear.sh ############ #!/bin/bash ip=$1 accion=$2 ipremota=$3 mensaje=$4 string="`date '+%Y/%m/%d_%H:%M:%S'` $ipremota -> $ip" if [ $accion -eq 0 ] then string="$string APAGAR" elif [ $accion -eq 1 ] then string="$string ENCENDER" else string="$string _" fi string="$string $mensaje" echo "$string" >> /root/vdi/vdi.log exit 0
Este script graba un fichero log con el siguiente aspecto.

############ Fichero: vdi.log ############ 2010/06/03_09:04:20 212.8.0.74 -> 172.18.0.76 APAGAR OK 2010/06/03_09:04:53 212.8.0.74 -> 172.18.0.75 ENCENDER OK 2010/06/03_09:05:10 212.8.0.74 -> 172.18.0.76 ENCENDER OK 2010/06/03_09:05:47 212.8.0.74 -> 172.18.0.75 APAGAR OK 2010/06/03_09:06:20 212.8.0.74 -> 172.18.0.76 APAGAR OK
Volviendo a la web PHP (alterar.php), se ha visto que adems de registrar los eventos en el log, tiene que realizar la propia accin de arrancar o apagar las mquinas. El siguiente script se encarga de ejecutar el comando vmrun que se comunicar por fin con el servidor VMware.
25
############ Fichero: alterar.sh ############ #!/bin/bash # Comprobar parametros if [ $# -ne 2 ]; then echo "Parametros incorrectos. estado IP VALOR" exit 1 fi grep $1 /root/vdi/maquinas.cfg | while read p_ip p_nombre p_estado p_ruta do if [ $2 = 1 ]; then vmrun -h http://172.18.40.58/sdk -u admin -p vmpass -gu administrador -gp ospass start "$p_ruta" echo "$1 encendido" else vmrun -h http://172.18.40.58/sdk -u admin -p vmpass -gu administrador -gp ospass stop "$p_ruta" soft echo "$1 apagado" fi done sleep 10 # Actualizar el estado de las maquinas virtuales /root/vdi/comprobar.sh exit 0
Por ltimo, solo queda actualizar el fichero de configuracin (maquinas.cfg) para que refleje el nuevo estado de las MV's. Para ello, se ha desarrollado el siguiente script.
############ Fichero: comprobar.sh ############ #!/bin/bash if [ ! -f /root/vdi/guests.tmp ] then # Consultar el estado de las maquinas virtuales vmrun -h http://172.18.40.58/sdk -u seguridad -p *1segprep list | grep ".vmx" > /root/vdi/guests.tmp
26
# Ordenar el fichero por IP por si se ha modificado manualmente sort -nu -t. -k1,1 -k2,2 -k3,3 -k4,4 /root/vdi/maquinas > /root/vdi/maquinas.tmp cat /root/vdi/maquinas.tmp | while read p_ip p_nombre p_estado p_ruta do estado=0 grep "\\$p_ruta" /root/vdi/guests.tmp > /dev/null && estado=1 if [ $estado == 1 ] then # El guest esta encendido sed "/$p_ip/s/%%off%%/%%on%%/" /root/vdi/maquinas.tmp > /root/vdi/maquinas echo $p_ip, ON, $p_nombre, $p_ruta else # El guest esta apagado sed "/$p_ip/s/%%on%%/%%off%%/" /root/vdi/maquinas.tmp > /root/vdi/maquinas echo $p_ip, OFF, $p_nombre, $p_ruta fi cp /root/vdi/maquinas /root/vdi/maquinas.tmp done rm /root/vdi/*.tmp # Generar RSS /root/vdi/procesar.sh fi exit 0
Y una vez el fichero de configuracin est actualizado ya se puede volver a actualizar el fichero RSS con 'procesar.sh' para que se reflejen los cambios en el cuadro de mando de OSSIM, y as se cierra el bucle. Como las mquinas se pueden apagar y arrancar mediante otros mtodos ajenos a este control, convena tener siempre ejecutando un servicio que comprobara el estado de las mquinas cada cierto tiempo. Para esto, se gener el siguiente script que se mantiene en un bucle.
27
############ Fichero: servicio.sh ############ #!/bin/bash while true do # Actualizar el estado de las maquinas virtuales /root/vdi/comprobar.sh echo "- - - - - - - - - - - - - - - -- - - - - - - - - - - - - -" sleep 60 done exit 0
As, se puede observar desde OSSIM el estado de las mquinas, como si se estuviera en el propio cliente de VMware vSphere. En todo momento, se han tenido en cuenta los permisos de los ficheros. Por defecto, tenan permiso de lectura y escritura para root pero el usuario que ejecuta el servidor web es 'www-data' por lo que todos los ficheros que tenan que ser ledos, escritos o ejecutados desde la web necesitaban permisos para este usuario.
6.3. Plugin VDI

Dado que se ha generado un log que almacena los movimientos de las mquinas virtuales, se decidi que este era un buen fichero para ser procesado por OSSIM, de forma que si se desea, pueda ser correlado como cualquier otro log. Para hacer esto, se ha creado un nuevo plugin. El id del plugin poda ser cualquiera que estuviera libre. Las reglas del plugin son cada una de las diferentes acciones que se pueden detectar en el log.
############ Fichero: vdi_plugin.cfg ############ ;; vdi ;; type: detector ;; $Id: vdi.cfg, v 1.0 2010/05/21 $ [DEFAULT] plugin_id=1888 [config] type=detector enable=yes source=log location=/root/vdi/vdi.log
28
create_file=false process= start=no stop=no startup= shutdown= ################### Rules ##################### [ENCENDER OK] # 2010/05/20_13:54:39 212.8.125.74 -> 172.18.40.75 ENCENDER OK event_type=event regexp="^(?P<date>\d+/\d+/\d+_\d+:\d+:\d+)\s(?P<src>\IPV4)\s->\s(? P<dst>\IPV4)\sENCENDER\sOK$" plugin_sid=11 date={normalize_date($date)} src_ip={$src} dst_ip={$dst} [APAGAR OK] # 2010/05/20_13:54:44 212.8.125.74 -> 172.18.40.75 APAGAR OK event_type=event regexp="^(?P<date>\d+/\d+/\d+_\d+:\d+:\d+)\s(?P<src>\IPV4)\s->\s(? P<dst>\IPV4)\sAPAGAR\sOK$" plugin_sid=12 date={normalize_date($date)} src_ip={$src} dst_ip={$dst} [ERROR1 IP erronea] # 2010/05/20_13:39:00 212.8.125.74 -> _._._._ _ ERROR1 IP erronea. event_type=event regexp="^(?P<date>\d+/\d+/\d+_\d+:\d+:\d+)\s(?P<src>\IPV4)\s>\s_._._._\s_\sERROR1\s" plugin_sid=1 date={normalize_date($date)} src_ip={$src} [ERROR2 Accion desconocida] # 2010/05/20_13:39:14 212.8.125.74 -> 172.18.40.75 _ ERROR2 Accion desconocida. event_type=event regexp="^(?P<date>\d+/\d+/\d+_\d+:\d+:\d+)\s(?P<src>\IPV4)\s->\s(? P<dst>\IPV4)\s_\sERROR2\s"
29
plugin_sid=2 date={normalize_date($date)} src_ip={$src} dst_ip={$dst} [ERROR3 IP del servidor] # 2010/05/20_13:39:27 212.8.125.74 -> 172.18.40.74 _ ERROR3 IP del servidor. event_type=event regexp="^(?P<date>\d+/\d+/\d+_\d+:\d+:\d+)\s(?P<src>\IPV4)\s->\s(? P<dst>\IPV4)\s_\sERROR3\s" plugin_sid=3 date={normalize_date($date)} src_ip={$src} dst_ip={$dst}
Y por ltimo, para que el plugin funcione, se ha introducido en la base de datos la informacin del plugin y de sus sids, es decir, sus distintos eventos los cuales tienen cada uno una prioridad y una fiabilidad. Para hacer esto, se ha conectado a la base de datos MySQL y se han insertado los siguientes registros:
INSERT INTO plugin (id, type, name, description) VALUES (1888, 1, 'vmware-action', 'vmware-hypervisor command log'); INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (1888, 1, NULL, NULL, 'vmware: wrong IP address', 2, 1); INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (1888, 2, NULL, NULL, 'vmware: wrong action', 2, 1); INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (1888, 3, NULL, NULL, 'vmware: server IP address', 2, 1); INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (1888, 11, NULL, NULL, 'vmware: Power ON Host', 1, 1); INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (1888, 12, NULL, NULL, 'vmware: Power OFF Host', 1, 1);
Siguiendo estos pasos se ha conseguido que cada vez que se apague o encienda una mquina virtual se observe tal evento en el panel de eventos SIEM. Y si se desea, se puede correlar esta informacin en directivas utilizando el id y los sids que se les ha asignado. Un caso prctico que utilice esto, sera un entorno en el que haya un grupo de mquinas dando un servicio de correo electrnico y que en caso de que si se apagan todas no funcionase el correo. Se podra crear una poltica que detecte si se han apagado demasiadas MV's y en ese caso, se encienda alguna para mantener el servicio.
30
7. Anexo B: ALIENVAULT OSSIM

OSSIM es un sistema de seguridad integral de cdigo abierto que cubre desde la deteccin hasta la generacin de mtricas e informes a un nivel ejecutivo. Es un producto de seguridad que permite integrar en una nica consola todos los dispositivos y herramientas de seguridad de la red, as como la instalacin de otras herramientas de cdigo abierto y de reconocido prestigio como Snort, OpenVAS, Ntop y OSSEC. Una vez los eventos generados por las diferentes herramientas y dispositivos han sido recogidos por el sistema, este realiza una valoracin del riesgo de cada evento y entonces tiene lugar la correlacin. Durante el proceso de correlacin, a partir de una serie de patrones, se generan nuevos eventos para detectar ataques o problemas en la red. Para acceder a toda la informacin recogida y generada por el sistema se hace uso de una consola web que adems permite configurar el sistema y observar el estado global de la red en tiempo real. Desde esta consola web, tambin es posible acceder a un gran nmero de utilidades e informes. Esto pretende ser un pequeo manual de usuario para iniciarse en OSSIM sin entrar en mucho detalle.
7.1. Perfiles
No es necesario instalar OSSIM en una nica mquina, se dispone de varios perfiles que podrn instalarse en un mismo servidor o distribuidos en varios dependiendo de las complejidad del entorno.
Figura 7.1: Arquitectura de OSSIM
Sensor
La mquina con perfil sensor se encarga de la coleccin y normalizacin de eventos. Para ello, es necesario que se hagan llegar al sensor todos los eventos generados por las herramientas de las que se dispone en la red haciendo uso de Syslog, Ftp, Samba, Ossec... El software instalado en un sensor se llama agente, por este motivo muchas veces se confunden los trminos sensor y agente. Cada herramienta lleva un plugin asociado que indica al sistema cmo ha de procesar la informacin con el objeto de generar un evento normalizado e independiente de la herramienta que lo haya generado. Los eventos normalizados son enviados al servidor.
31
En el perfil Sensor se instalan Snort, Ntop, Arpwatch, P0f y Pads. Estas herramientas se encargan de analizar el trfico de red, por lo que, para que resulten de utilidad se debe utilizar un concentrador o configurar un Port-Mirroring en la red.
Servidor
Procesa los eventos enviados por los agentes y los almacena en la base de datos, correla eventos y gestiona el riesgo para generar alarmas. Dentro de este perfil tambin se incluye un agente de OSSIM para monitorizar la seguridad del propio servidor.
Framework
Lleva incluido un servidor web que pone en linea toda la administracin de OSSIM. Ejecuta programas externos y realiza los escaneos de vulnerabilidades. Solo puede haber un framework en toda la red OSSIM.
Base de datos
El perfil de base de datos har que la mquina se encargue del almacenamiento de los eventos, inventarios y configuraciones del sistema. Para ello se instala un servidor de base de datos MySQL.
All-in-one
El perfil all-in-one es una combinacin de todos los perfiles en una nica mquina. Es el perfil de instalacin por defecto.
7.2. Activos
Para una empresa un activo es todo aquello que tiene valor para la misma. La informacin, es uno de los activos ms importantes dado que sta permite llevar a cabo las tareas diarias y sin informacin, sera imposible la existencia de la empresa. Por consiguiente, hay que entender la informacin como activo importante a proteger. Dnde se encuentra la informacin? Se puede llegar a pensar que nicamente en un servidor de base de datos, pero tambin hay informacin importante en cualquier otro servidor dentro de la red. Tambin los equipos del personal albergan informacin ms o menos importante dependiendo de las tareas de cada uno. Por lo tanto, para proteger la informacin habr que proteger todos y cada uno de los puntos dnde sta se encuentra. Por todo esto explicado, se van a considerar las mquinas de la red como activos de mayor o
32
menor valor dependiendo de la informacin que contengan. Hay dos formas de realizar un anlisis del valor de un activo: Cuantitativo. Se valora en base a su precio. Es un mtodo muy costoso por la complejidad que supone valorar el precio de la informacin. Cualitativo. Es un mtodo muy sencillo que consiste en valorar dentro de un rango pequeo la importancia del activo. OSSIM utiliza este mtodo, permitiendo valorar los activos de 0 a 5, significando 0 que no tiene valor y 5 que es algo imprescindible.
7.3. Riesgo
El riesgo es la probabilidad de que una amenaza explote una vulnerabilidad. Un activo puede tener vulnerabilidades y est sujeto a amenazas y como consecuencia de estas dos se expone a un riesgo. Cuanto mayor sea la amenaza o la vulnerabilidad mayor es el riesgo que corre. Adems no es igual de relevante el riesgo de un ordenador de uso personal que el de un servidor de ficheros, por lo tanto tambin hay que tener en cuenta el valor del activo a la hora del calcular el riesgo. Tambin hay que tener en cuenta la probabilidad de que una amenaza explote una vulnerabilidad, ya que no es igual el riesgo de algo que no es probable que ocurra de algo que puede ocurrir todos los das.
Figura 7.2: Esquema de generacin del riesgo
Por qu es tan importante el clculo del riesgo? El riesgo no se puede eliminar por completo, puesto que toda actividad conlleva un riesgo intrnseco, por tanto, hay que conocerlo, con objeto de tomar medidas encaminadas a minimizarlo. OSSIM tiene un una forma similar de calcular el riesgo de forma automtica. Para ello cuenta con los parmetros prioridad y fiabilidad. Cada evento que pueda suceder en la red debe tener asociado una prioridad y una fiabilidad. La prioridad, se define por cmo de importante es un evento si este se convierte en un ataque exitoso. Es decir, como de perjudicial puede llegar a ser. El valor que se le puede dar es de 0 a 5.
33
La fiabilidad, se refiere a la probabilidad de que un evento sea un ataque exitoso. Se le puede asignar un valor de 0 a 10. Este parmetro es delicado porque si se cree que algo no es probable que ocurra le se dara un valor bajo pero esto no significa que no vaya a ocurrir, si llegara a suceder podra no lanzarse una alarma por haber asignado un valor bajo aqu. El clculo del riesgo una vez se tiene el activo, la prioridad y la fiabilidad es muy sencillo. Se corresponde con la siguiente funcin:
Riesgo = (Activo * Prioridad * Fiabilidad) / 25
Si el riesgo resultante es al menos 1, se considera que el evento es suficientemente importante como para generar una alarma y que sea notificado el personal responsable.
7.4. Correlacin
La correlacin, es el proceso por el cual se comprueba cada evento detectado en busca de evidencias que determinen, con cierto grado de seguridad, la aparicin de ataques evitando la mayor cantidad posible de falsos positivos. De esta forma se disminuye el nmero de eventos significativos de millones al da a tan solo unas decenas, simplificando el trabajo para el responsable de seguridad. La correlacin es un proceso en el que se van evaluando condiciones hasta que estas llevan a un estado de riesgo. Mientras los eventos sucedidos no supongan un peligro no hay por qu alarmar a nadie, pero si se detectan varios sucesos que puedan indicar una situacin peligrosa, entonces se lanza la alarma. Lo complicado de la correlacin, es establecer correctamente unas condiciones que no den muchos falsos positivos y sobre todo que detecten las situaciones de riesgo.
7.5. Plugins
Los plugins son los elementos que contiene un agente para analizar y estandarizar la informacin captada. Una vez estandarizada ya se puede tratar como un evento y envirsela al servidor. Cada plugin solo puede tratar datos de una fuente especifica, esto se identifica con un plugin_id, mientras que cada uno de los diferentes eventos detectados de esa fuente se identifica con un plugin_sid. Hay dos tipos de plugins: Detectores. Estos plugins estn continuamente trabajando, leen la informacin de los diferentes logs que son almacenados por los procesos de captura de eventos. Como ya se ha dicho, cada detector se especializa en tipo de log y tiene que estandarizarlo para que todos tengan el mismo formato y el servidor pueda entender los eventos que suceden. Existen
34
plugins para Snort, p0f, Arpwatch, Pads y muchos ms. Monitores. Estos solo funcionan bajo peticin del servidor. Estos plugins envan la peticin a su herramienta asociada y tras obtener la respuesta se la envan al servidor. Todos los eventos detectados por los plugins son los que se correlarn para generar las correspondientes alarmas.
7.6. Requisitos de hardware

A continuacin, se describen algunos de los requisitos para hacer una instalacin de OSSIM sobre un servidor. Como OSSIM es un gran consumidor de memoria RAM, necesita al menos 2 GB para funcionar. Tiene multitud de componentes distintos ejecutndose en paralelo por lo que los procesadores multi-ncleo son bienvenidos. Adems la arquitectura de 64 bits supone una gran mejora en el rendimiento frente a la de 32 bits. As que lo mejor es elegir un procesador multi-ncleo de 64 bits. Es ms importante la arquitectura que las frecuencias as que no se debe dar importancia a esto ltimo. El tamao del disco duro es bastante relativo, con 10 GB se puede empezar pero para algo muy bsico, para hacer pruebas. En un entorno de produccin en el que se van a tener muchos eventos en la red, 50 GB dan mayor tranquilidad. Hacen falta al menos 2 interfaces de red, dependiendo de la cantidad de datos que se necesiten capturar de la red se requiere una interfaz ms o menos potente. Se necesita conexin a Internet para hacer algunas descargas durante la instalacin y hacer posteriores actualizaciones. Tambin se necesita una unidad de DVD para montar la imagen ISO de la instalacin de OSSIM.
7.7. Instalacin
Para hacer la instalacin de OSSIM se necesita descargar 1 la imagen ISO de la ltima versin disponible, en mi caso la 2.2.1. AlienVault recomienda la edicin de 64 bits por ser ms rpida y yo personalmente la recomiendo porque he encontrado varias caractersticas que no funcionaban correctamente en la versin de 32 bits. Se monta la ISO en la unidad de DVD del servidor, se arranca la mquina y comienza la instalacin: 1) Se selecciona el modo texto. 2) Idioma el ingls para evitar problemas con tildes y ees. Pero despus se debe elegir
1- http://www.alienvault.com/opensourcesim.php?section=Downloads
35
correctamente el pas y teclado. 3) Para este proyecto se ha hecho la instalacin todo en uno (Database, Framework, Server y Agent) aunque lo ms interesante sera poner los agentes en otras mquinas. 4) Como interfaz de red primaria se indica la de gestin. Ser la que sirva para conectar con el servidor y la que utilizar este para hacer las conexiones a otros equipos e Internet. Hay que asignarle una IP fija. 5) Se especifica un nombre para el host. 6) Para el particionado no es necesario complicarse. Se selecciona guiado, usar todo el disco con LVM y todos los ficheros en una particin. Esto genera una particin Ext2 para los ficheros de arranque y una particin LVM que se divide en 2 particiones, la de swap y la de datos. 7) Cuanto pide la clave de AlienVault Pro se deja en blanco. Esto habilita algunas funciones de logs pero es comercial as que solo es posible conseguirla comprando el producto. 8) La interfaz de red promiscua ser la de datos. Se especifica la red que se quiere monitorizar. 9) Durante la instalacin puede que necesite bajarse paquetes de Internet, esto puede hacer que se alargue bastante el proceso as que como ltimo paso se requiere paciencia. Despus de hacer la instalacin, se debe actualizar el sistema y asegurarse de que los diferentes componentes de OSSIM estn funcionando correctamente. En el punto 7.8 (Administracin SSH) se explica cmo hacerlo.
7.8. Administracin SSH

Se puede conectar al servidor OSSIM remotamente con cualquier cliente SSH a travs del puerto 22. Existen muchos clientes para Windows pero se recomienda PuTTY. El nico usuario con el que se puede conectar a la mquina es 'root' as que se tiene control total sobre la mquina. Se puede instalar software nuevo utilizando utilizando apt-get como con cualquier distribucin Debian. Tambin se puede actualizar el software usando 'apt-get update && apt-get dist-upgrade', de hecho se recomienda hacerlo despus de hacer la instalacin de OSSIM para tener la ltima versin de los paquetes. Para modificar la configuracin definida durante la instalacin, hay un programa con men: 'ossim-setup'. Desde este programa se pueden cambiar parmetros de la hora, leer algunos logs, activar y desactivar detectores y monitores, seleccionar la red que se quiere monitorizar y alguna cosa ms. Esta informacin se encuentra en el fichero de configuracin /etc/ossim/ossim-setup.conf. Se puede modificar manualmente este fichero con editor de texto (vi, nano...) y despus solo hay que ejecutar 'ossim-reconfig' para que los cambios tengan efecto. En el fichero de configuracin mencionado, se encuentra la contrasea de la base de datos de la
36
instalacin de OSSIM. Est en el apartado 'database' y viene con el nombre de variable 'pass'. Es interesante y casi obligatorio conocer esta contrasea porque hay otros ficheros de configuracin que deben tenerla pero que les falta tras hacer la instalacin. Por ejemplo, si no no en ejecucin la instancia de ossim-server es probable que a su fichero de configuracin /etc/ossim/server/config.xml le falte la contrasea de conexin a la base de datos. Esto pasa cada vez que se actualiza el sistema. Otro error que se puede tener tras instalar OSSIM, es que la instancia de ossim-framework no escuche en el puerto 4003. Para resolver esto hay que modificar en el fichero /usr/share/ossimframework/Const.py el parmetro LISTENER_ADDRESS y darle valor 0.0.0.0. Con las ltimas actualizaciones, se han incluido entre las novedades otro fallo. El fichero de arranque '/etc/init.d/ossim-server' tiene incorrectamente informada la ruta de ossim-server. Lleva DAEMON=/usr/local/bin/$NAME cuando debera ser DAEMON=/usr/bin/$NAME. Sin este servicio no funciona absolutamente nada. En general la configuracin de OSSIM se encuentra en /etc/ossim: Configuracin global /etc/ossim/ossim_setup.conf Configuracin del servidor /etc/ossim/server/config.xml Configuracin del framework /etc/ossim/framework/ossim.conf Configuracin del agente /etc/ossim/agent/config.cfg Como se puede comprobar, OSSIM no est exento de problemas de funcionamiento, por lo que es interesante conocer su configuracin interna.
7.9. Administracin web

Aunque se pueda conectar a OSSIM a travs de SSH, su verdadero uso se hace a travs de su pgina web. Escribiendo la IP del servidor en un navegador se puede acceder a ella. El usuario de administracin es 'admin' y la contrasea por defecto 'admin' que debe ser cambiada inmediatamente si no se quiere que pueda acceder cualquier persona al control del sistema de seguridad. 7.9.1. Cuadros de mando Cuadros de mando Este el primer panel que se ve una vez se ha entrado. Aqu se pueden apreciar varias pestaas con informacin resumida sobre el estado de la red y de las mquinas que se encuentran en ella. En cada pestaa hay varios grficos que ayudan a conocer la informacin ms relevante en un rpido vistazo.
37
Figura 7.3: Cuadros de mando
Riesgo El panel de riesgos muestra los niveles de compromiso y ataque que tienen las redes y los equipos de estas. Esto se mide en mtricas. Este valor se incrementa con los eventos detectados a lo largo del tiempo y se decrementa cada 15 segundos con el 'Recovery Ratio'.
Figura 7.4: Riesgo: compromiso y ataque
38
El 'Revovery Ratio' se encuentra en la configuracin avanzada donde tambin se puede obsevar el 'Global Threshold' que es el valor lmite de eventos a partir del cual debe ser preocupante la situacin de la seguridad. Por esto es necesario filtrar los eventos que sucedan con frecuencia y que no sean relevantes. Un ataque representa el riesgo potencial debido a una conexin entrante a la mquina. En otras palabras, representa la posibilidad de que est siendo atacada pero esto no significa que el ataque haya sido exitoso. La seccin de compromiso representa las conexiones salientes de una mquina. Al hacer conexiones salientes se supone que esta ya ha sufrido un ataque exitoso y en ese momento est atacando al resto.
7.9.2. Incidentes Alarmas Cuando el nivel de riesgo de un evento supera el 1 se genera automticamente una alarma. En este panel aparecen todos esos eventos que por el motivo que sea ha alcanzado un nivel de riesgo importante y merecen la creacin de una alarma para que los administradores sean notificados y tomen medidas.
Figura 7.5: Panel de alarmas
Tickets Los tickets permiten a los usuarios hacer un seguimiento de los problemas que puedan ir surgiendo. Los tickets se pueden generar automticamente o de forma manual. La gestin de tickets es muy cmoda ya que permite aadir comentarios, adjuntar ficheros, notificar de los cambios a los involucrados y todo esto queda registrado con fecha y hora.
39
Figura 7.6: Panel de tickets
7.9.3. Anlisis SIEM Aqu se encuentra una de las partes ms interesantes de OSSIM. El SIEM muestra todos los eventos detectados a lo largo del tiempo. Por cada evento se ve, adems de la fecha y hora, de dnde proviene y hacia dnde, el valor de los activos de cada extremo, la prioridad y la fiabilidad del evento, y por ltimo el riesgo del evento. Adems se ofrecen muchos filtros para mostrar la informacin que ms interesa. Los eventos se pueden agrupar para saber cuntos eventos de un tipo concreto han sucedido por ejemplo, y los eventos que no interesan se pueden borrar permanentemente.
Figura 7.7: Panel SIEM
40
Vulnerabilidades
Figura 7.8: Escaneos de vulnerabilidades
Desde este panel se pueden lanzar anlisis de vulnerabilidades haciendo uso de OpenVAS. Realmente la herramienta es transparente ya que se hace todo a travs de la interfaz web. Se puede lanzar un anlisis inmediato contra una mquina o contra varias. Tambin se pueden programar los anlisis para que se realicen peridicamente como se puede ver en la figura 7.9.
Figura 7.9: Lanzamiento de un escaneo
En la pestaa vulnerabilidades se encuentran los informes de los anlisis realizados. Aqu se pueden observar las vulnerabilidades de cada mquina y apreciar cmo de grave es la situacin de cada una. Esto depende de los servicios que tenga abiertos.
41
Figura 7.10: Informe de vulnerabilidades
Originalmente OSSIM utilizaba Nessus como escner de vulnerabilidades pero al convertirse en un proyecto cerrado fue sustituido por OpenVAS. Este es un fork de Nessus que ha demostrado estar a la altura del primero. Segn comparativas, Nessus tiene una base de datos ms grande y encuentra ms vulnerabilidades conocidas sin embargo OpenVAS encuentra ms vulnerabilidades recientes lo que lleva a pensar que est creciendo con ms fuerza que su antecesor.
7.9.4. Informes En OSSIM se puede generar una gran cantidad de informes diferentes: activos, eventos, vulnerabilidades, tickets, alarmas.... Todos se pueden lanzar desde este panel, adems se encuentran disponibles en varios formatos.
Figura 7.11: Generacin de informes
42
7.9.5. Activos Activos
Figura 7.12: Activos de la red
Desde este panel se gestionan todos los activos de la red: ordenadores personales, servidores, firewalls, routers... Tras hacer una instalacin de OSSIM lo recomendable es ir a la pestaa Networks y definir la red que quiere gestionar y las redes colindantes alrededor. Una vez defina la red se pueden definir las mquinas que se desean monitorizar en la pestaa Hosts. Aqu solo se pueden introducir equipos de uno en uno, lo que puede lleva bastante tiempo si la red tiene muchos elementos. Si se utiliza la herramienta 'Net Discovery', que se explica en el punto 7.9.9, se pueden definir todos los elementos de una vez. Si hay un grupo de mquinas que suelen tener un tratamiento comn se las puede introducir en un grupo definido en la pestaa 'Host groups'. La pestaa 'Network groups' es similar pero para redes. En la pestaa 'Ports' se pueden definir listados de puertos que se vayan a utilizar con frecuencia. La pestaa 'Inventory' es la web de administracin del servidor OCS. Esto es un servidor de inventario. Si pide usuario/contrasea al entrar se debe utilizar la de administracin de OSSIM, admin/admin por defecto. Para utilizarlo hay que instalar un cliente OCS en las mquinas que quiere inventariar. A continuacin se explica cmo inventariar un equipo con Windows. 1) Descargar 'OCS for Windows' del men de OSSIM Tools Downloads. 2) Modificar los archivos bat. Sustituir las IP's por las del servidor OSSIM y poner entre comillas dobles las rutas que aparezcan para evitar problemas con nombres largos.
43
3) Ejecutar en el sistema con Windows como Administrador el script 'install.bat' y cuando termine ejecutar 'inventorize_now.bat'.
Figura 7.13: Servidor OCS
Despus de realizar estos pasos se puede comprobar la presencia de la mquina con Windows en el inventario de OSSIM (figura 7.13). Si se hace clic en su nombre se puede observar todo el hardware y el software que tiene instalado. Por defecto no se inventara el registro de Windows porque sera demasiada informacin pero puede ser muy til conocer algunas entradas del registro, por ejemplo que se ejecuta al arrancar el sistema operativo. Para hacer esto en el men 'Config' hay que habilitar la opcin 'REGISTRY' y despus en el men 'Registry' agregar una entrada para especificar lo que se quiere monitorizar: Nombre descriptivo. Raz de la que cuelga la clave de registro. Ruta en la que est la clave de registro. Hay que ponerlo con doble contra-barra, por ejemplo: SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run Nombre de la clave a monitorizar. Poner asterisco (*) para todas.
Figura 7.14: Monitorizar registro con OCS
44
Componentes SIEM En esta pestaa se pueden observar los componentes de OSSIM, es decir, todas las mquinas que estn relacionadas en la instalacin. Si se ha realizado una instalacin All-in-one entonces solo aparecer un servidor, si se hace clic en l, se muestra informacin de los servicios que est ejecutando y a travs de que puerto se comunica. 7.9.6. Inteligencia Polticas y Acciones El panel de polticas sirve para determinar que hacer cuando suceden ciertos eventos. Por ejemplo, cuando se hace una instalacin nueva de OSSIM siempre hay algn evento que sucede con frecuencia y ahoga la lista SIEM de falsos positivos, con esto se pueden crear poltica para ignorar estos eventos tan ruidosos. Del mismo modo, si hay algn evento que sea importante se puede hacer que se responda de forma automtica con la accin que se quiera.
Figura 7.15: Polticas de OSSIM
En la pestaa de acciones se pueden crear 2 tipos de acciones: mandar un correo electrnico o lanzar un comando del sistema. Esto proporciona mucha flexibilidad ya que se pueden lanzar todos los scripts que se quiera.
Figura 7.16: Acciones para las polticas
45
Directivas de Correlacin Las directivas de correlacin son la herramienta ms potente de OSSIM, sirven para lanzar eventos a partir de otros eventos que aislados. Cada directiva se trata de un conjunto de condiciones que si se dan es porque algo interesante ha sucedido. Si la directiva se cumple, se lanza un evento que puede llegar a tener un riesgo tan alto que haga que se lance una alarma. De esta forma eventos que de forma separada no dicen nada, si estn correlados se puede llegar a una conclusin importante y notificar al administrador. Al crear una directiva nueva hay que especificar los siguientes parmetros: Nombre de la directiva. Identificador de directiva. Prioridad que tiene, es decir, la gravedad. Una vez hecho esto la directiva est vaca, hay que agregarle reglas. Las reglas son los eventos que tienen que ocurrir para que se cumpla la directiva, se podran llamarlas condiciones.
Figura 7.17: Directiva de correlacin
Para crear una regla hay que pulsar el + dentro de la directiva, se le da un nombre a la regla y se empiezan a rellenar las condiciones: id del plugin que ha lanzado el evento, sid del plugin que ha lanzado el evento, desde qu IP-puerto y a qu IP-puerto A continuacin se detallan los posibles valores de estos campos: From. IP origen. Se puede expresar de muchas formas. Una IP, o varias separadas por comas. Un nombre de red definido en OSSIM. ANY para cualquier origen. Una IP relativa. Por ejemplo 1:SRC_IP se refiere a la IP origen de la primera regla, 2:DST_IP significa la IP destino de la segunda regla.
46
Se pueden negar orgenes con el smbolo de admiracin (!) de forma que !127.0.0.1 se referira a cualquier IP menos 127.0.0.1. To. IP destino. Los valores posibles aqu son los mismos que en el From. Reliability. Fiabilidad. Occurrence. Es el nmero de veces que el evento de una regla debe detectarse antes de que sea activada. Time_out. Este campo no tiene sentido en la primera regla de una directiva, se mira a partir de la segunda. Es el tiempo en segundos durante el cual se va a monitorizar la regla para activarla si es que se producen sus eventos. Pasado este tiempo la directiva se reinicia y es como si las reglas anteriores nunca hubieran sucedido. Si se especifica un tiempo muy corto podra no detectarse un ataque lento. Las siguientes caractersticas solo aplican a plugins de tipo monitor: Condicin y valor. Condicin que se tiene que cumplir para activar la regla. Intervalo. Durante cuanto tiempo tiene que cumplirse la condicin. Absoluto. El valor de la condicin es relativo o absoluto. Sticky. Por defecto, aunque las reglas tengan indicado ANY en algn campo, se generar un control de directiva distinto cada vez que suceda un evento con diferente valor en este campo. Si se pone este flag a True, los eventos con distintos valores para los campos ANY se acumularn en la misma directiva. Sticky different. Este campo evita los efectos del flag 'Sticky' pero solo para un campo concreto.
Figura 7.18: Regla de una directiva
47
A continuacin se muestra un ejemplo prctico de cmo funciona una directiva. Se trata de una directiva con 2 reglas anidadas: 1) La primera tiene como condicin que se cumpla un evento 3 veces. 2) Para la segunda se tiene que cumplir un evento 2 veces y tiene un time_out de 20 segundos. Se supone que se detecta la siguiente serie de eventos: 1) Se detecta el evento de la primera regla hasta 3 veces entonces se activa la regla y se empieza a monitorizar la segunda. 2) A los 10 segundos se detecta el evento de la regla pero pasados los 20 segundos no vuelve a suceder as que no se sigue monitorizando. 3) Se vuelve a detectar el evento de la primera regla 3 veces, se activa y se monitoriza la segunda. 4) A los 5 segundos se detecta el evento y a las 10 otra vez as que se activa la segunda regla y con esto la directiva lanza un evento. 5) El evento, dependiendo de los activos involucrados y la prioridad y la fiabilidad que tenga la directiva, podr lanzar una alarma si el riesgo es mayor o igual a 1. Las reglas de una directiva se pueden anidar con la flecha derecha como se ha explicado de forma que para comprobar si una condicin se cumple se tiene que cumplir antes otra. De esta forma la fiabilidad de una regla puede tener un valor absoluto para la directiva o puede incrementar la fiabilidad de la directiva dentro de la que est anidada. Pero las reglas tambin se pueden poner al mismo nivel de forma que sean condiciones sin orden que se tienen que cumplir. Correlacin Cruzada
Figura 7.19: Correlacin cruzada
La correlacin cruzada permite priorizar eventos para los que se es vulnerable. Se utiliza para
48
alterar la fiabilidad de un evento, aumentando de esta forma el riesgo y por consecuencia la generacin de alarmas. Por ejemplo, si Snort ha descubierto un ataque a una IP y se sabe que esa IP tiene una vulnerabilidad detectada por OpenVAS, la fiabilidad de ambos se suma. 7.9.7. Monitores Network En la pestaa 'Traffic' se encuentra NfSen. Esto es una interfaz web a la herramienta NfDump para el anlisis de netflow.
Figura 7.20: NfSen
En la pestaa 'Properties' se encuentra la interfaz de Ntop. Esta herramienta permite monitorizar en tiempo real los usuarios y aplicaciones que estn consumiendo recursos de red en un instante concreto y ayuda a detectar malas configuraciones en los equipos (las banderas amarillas y rojas son errores leves y graves respectivamente). Disponibilidad Este panel es la interfaz de Nagios. Esta herramienta es un sistema de monitorizacin de equipos y servicios de redes alertando cuando el comportamiento de los mismos no sea el deseado. En OSSIM sirve para comprobar que los equipos estn disponibles y que sus servicios estn funcionando correctamente. La administracin de Nagios normalmente se hace a travs de sus ficheros de configuracin pero en este caso no es necesario. OSSIM agrega automticamente los equipos a la configuracin de Nagios si cuando se definen los activos se marca la casilla 'Enable Nagios'. Se puede hacer esto en cualquier momento modificando los activos, adems desde el mismo sitio se pueden especificar los
49
servicios que se quiere monitorizar de cada equipo. La integracin de Nagios con OSSIM no es perfecta. Aunque se hayan introducidos unos hostnames descriptivos a los activos, en Nagios aparecen las IP's como hostnames.
Figura 7.21: Panel de Nagios
La configuracin interna de Nagios se encuentra en '/etc/nagios3/' pero no es recomendable modificarla manualmente porque se pierde al hacer cambios con OSSIM. Sistema En esta pestaa se pueden observar los sensores de OSSIM, si se ha hecho una instalacin All-inone entonces solo aparece el sensor del propio servidor. Si se hace clic en un sensor, se muestra informacin de los plugins que se estn ejecutando en este. Algunos informan de si estn funcionando correctamente, otros no pero esto no significa que haya algo mal. En la pestaa 'User Activity' se puede observar un log con los movimientos de los usuarios.
Figura 7.22: Plugins de un sensor
50
7.9.8. Configuracin Principal Aqu se encuentra la configuracin interna de los componentes de OSSIM. Tiene una vista sencilla y otra ms completa. Es mejor no tocar nada aqu si las cosas funcionan bien. Usuarios La pgina de configuracin de usuarios es muy sencilla de usar. Aqu se gestionan los usuarios que tendrn acceso a la web de administracin de OSSIM. En un principio solo existe 'admin' que tiene acceso a todo pero se pueden crear otros usuarios con un perfil de acceso ms restringido al rea que tenga que gestionar.
Figura 7.23: Configuracin de usuarios de OSSIM
Desde aqu tambin se dispone de una pestaa con la actividad realizada por cada usuario para no perder detalle de lo que el personal haya realizado. Coleccin Todos los plugins disponibles para OSSIM se encuentran aqu. Se muestran todos ordenados por su identificador nico: el plugin id. Cada plugin es capaz de monitorizar un grupo de eventos determinados. Para ver los eventos de un plugin se puede hacer clic en el plugin y estos se muestran.
51
Figura 7.24: Listado de plugins
Cada evento tiene asociado un identificador nico que es el plugin sid, de esta forma con solo el plugin id ms el sid OSSIM sabe que evento concreto ha sucedido. Cada evento tiene asociada una prioridad y una fiabilidad que se puede modificar segn las necesidades particulares del entorno.
Figura 7.25: SIDs de Snort
52
Actualizacin de Software En esta pgina se muestra la versin de OSSIM que se est ejecutando y la versin del esquema de la base de datos, 2.2.3 para ambos en la captura. Cuando se hace una actualizacin va apt-get se actualizar el software, es decir, la versin de OSSIM, pero no el esquema de base de datos. Este hay que actualizarlo inmediatamente despus desde esta pgina. En el apartado 'Required upgrades' aparece un enlace que se encargar de modificar la base de datos para que cumpla los requisitos de la nueva versin del software.
Figura 7.26: Versin de OSSIM
En la parte inferior aparecen todas las actualizaciones que se han hecho a lo largo del tiempo desde las primeras versiones de OSSIM. Lo cierto es que no tiene mucho sentido mostrarlas aqu ya que hacer clic sobre uno de esos enlaces modificara la base de datos a un estado antiguo. 7.9.9. Herramientas Backup La informacin de Snort permanece en la base de datos durante un periodo de tiempo a partir del cual se saca y se almacena por si se llegar a necesitar. La pgina de backup permite precisamente esto, recupera la informacin de Snort del da que se desee y la vuelca en la base de datos para que se pueda estudiar. Tambin hace la operacin inversa para cuando ya no se necesite esta informacin en la base de datos. En la pgina aparecen 2 columnas, una con las fechas que se pueden insertar en la base de datos y otra con las fechas que ya estn en la base de datos y que se pueden sacar para almacenarlas. Debajo de estas columnas se puede observar un log con las operaciones realizadas con esta herramienta.
53
Figura 7.27: Copias de datos de Snort
Descargas La pgina de descargas contiene una serie de programas que se pueden instalar en otras mquinas de la red para que se puedan comunicar con el servidor OSSIM. Algunos vienen con ficheros de configuracin pre-modificados para funcionar especficamente con el servidor que se est administrando aunque conviene mirarlos por si hay algo incorrecto. A continuacin se muestra una lista con el software que se puede encontrar: PuTTY for Windows. Cliente para manejar el servidor OSSIM a travs de consola SSH. OSSIM Agent para Windows. Un agente OSSIM para instalar en Windows. Python para Windows. Intrprete de comandos necesario para ejecutar programas escritos en Python sobre Windows. Es mejor obtener la ltima versin desde su web oficial. OCS. Esta aplicacin sirve para inventariar el hardware y software del equipo donde se instala. Tiene versiones para varios sistemas operativos. Estos inventarios se pueden comprobar en Assets Assets Inventory. FW1 Loggrabber. Si se tiene un firewall Checkpoint esta aplicacin puede ser til para comunicar los logs a OSSIM. OpenVPN para Windows. Gestin de una VPN. Snare. Este programa es capaz de comunicar los logs de sucesos del sistema a OSSIM. Osiris. Este programa comprueba peridicamente modificaciones en ficheros importantes del sistema y en caso de encontrar cambios los informa a OSSIM.
54
OSSEC. Combina las caractersticas de Snare y Osiris y al igual que los anteriores se puede encontrar para varios sistemas operativos. Recomendado instalar este agente en cualquier equipo que se desee monitorizar desde OSSIM. En realidad no se necesita todo este software, puede que ninguno dependiendo de las necesidades particulares de cada entorno. Adems es probable que encontrar versiones ms recientes de los programas en sus respectivas pginas web. Net Discovery
Figura 7.28: Escaneo de redes
Este panel permite escanear una red en busca de hosts y servicios. Tan solo se selecciona una red disponible de la lista y se ve al lado el rango IP que se va a escanear. Las redes que aparecen en esta lista son las que se han definido en el men 'Activos' as que si no est la red que se quiere solo hay que ir all a definirla. Al pulsar el botn 'Scan' OSSIM escanea la red y cuando termina se pueden observar los resultados encontrados. Dependiendo del tipo de escaneado realizado se ve ms o menos informacin. Cada host encontrado tiene un check para indicar que se quiere agregar a la lista de activos. Tras seleccionarlos se pulsa 'Update database values' para confirmar los hosts que se quieren
Figura 7.29: Resultados de Net Discovery
55
agregar. Despus de esto se muestra una ventana que permite configurar las propiedades que van a tener los hosts agregados. Si no se quiere que tengan las mismas propiedades no importa porque posteriormente se pueden modificar individualmente. Las propiedades son las siguientes: Group name. Si se quiere introducir el host en un grupo que se haya definido se puede especificar aqu. Asset value. Valor del activo, de la informacin que contiene el host. Threshold C. Umbral de compromiso. Threshold A. Umbral de ataque. RRD profile. Perfil de almacenamiento de datos. NAT. Sensors. Agente que monitorizar el host. Scan options. Esta opcin permite agregar el host a la lista de Nagios, para que este verifique peridicamente su disponibilidad. Description. Descripcin del host. Una vez alimentados los campos con los valores deseados, se pulsa OK y los hosts se agregan a la lista de activos.
Figura 7.30: Propiedades de nuevos hosts
56
8. Anexo C: VIRTUALIZACIN
La virtualizacin es la abstraccin de los recursos de un ordenador. Se trata de una capa de software entre al hardware de la mquina fsica y el sistema operativo de la mquina virtual que permite crear una versin virtual de un dispositivo o recurso, como un servidor, un dispositivo de almacenamiento, una red, etc. Esta capa de software gestiona los recursos de la mquina fsica (CPU, memoria, red, almacenamiento) y los reparte dinmicamente entre las mquinas virtuales que se estn ejecutando. De modo que permite tener varias mquinas virtuales sobre el mismo equipo fsico. Por ejemplo, si se dispone de una red empresarial en la que cada empleado tiene un ordenador. Si se piensa en virtualizar, no sera necesario comprar un equipo a cada empleado. Basta con tener un par de servidores potentes en los que se virtualizaran las mquinas y la red. El mantenimiento del hardware es mucho ms sencillo. En 4 pasos se puede ampliar la memoria o el almacenamiento de cualquier MV. Adems el hardware virtual eleva el factor de obsolescencia de las mquinas fsicas ya que viene limitado por los servidores sobre los que se est ejecutando.
8.1. VMware
VMware es una compaa que ha creado varios productos para la virtualizacin de hardware. Se puede decir que esta compaa a sabido utilizar las ventajas de la virtualizacin como ninguna. Su producto ms fuerte actualmente es VMware vSphere que adems de permitir crear mquinas virtuales cuenta con las siguientes caractersticas propias: Fault Tolerance. Se mantiene siempre una copia del estado en curso de las mquinas virtuales para que en caso de que falle el servidor las mquinas virtuales puedan continuar funcionando en otro servidor disponible como si nada hubiera sucedido. VMSafe. Se trata de una API con la que los fabricantes de soluciones de seguridad pueden controlar la seguridad de una MV desde otra mquina. vNetwork Distributed Switch. Capacidad para crear redes complejas virtuales. vShield Zones. Es el nombre que le dan a los firewalls. Son capaces de controlar el trfico tanto entre mquinas virtuales como entre hosts fsicos. vCenter CapacityIQ. Esta caracterstica hace que equilibre la carga de las mquinas virtuales entre las servidores ESX aprovechando al mximo los recursos y evitando que los servicios que necesitan mucha potencia queden mermados. vCenter Data Recovery. Se mantiene una copia de los datos de las mquinas virtuales para que en caso de que se hayan perdido datos estos se puedan recuperar rpidamente. vCenter Configuration Manager. Este gestor comprueba de forma automtica que los cambios que se hagan en el sistema cumplen con las polticas establecidas. vCenter Orchestrator. Automatizacin de tareas de gestin de mquinas virtuales que se
57
hacen con mucha frecuencia de forma manual evitando hacer trabajos repetitivos. vCenter Chargeback. Esta herramienta ayuda a comprender el uso de los recursos y de su coste y que se puede hacer para optimizar esto. vCenter AppSpeed. Analiza el rendimiento de las aplicaciones y el flujo de la informacin entre las mquinas para descubrir cuellos de botella.
Figura 8.1: Arquitectura VMware
Una arquitectura sencilla para entender cmo funciona una instalacin de VMware se podra explicar con la figura 8.1. Se necesita un servidor de almacenamiento que contenga las mquinas virtuales, varios servidores ESX que sern los que ejecuten las MV's y un servidor vCenter desde donde controlar el estado tanto de los servidores ESX como de las mquinas virtuales que ejecutan.
Figura 8.2: vSphere Client
En la figura 8.2 se puede observar un cliente vSphere conectado a un servidor mostrando lo que se acaba de explicar pero en un entorno fsico. Al igual que en el esquema anterior, hay dos
58
servidores ESX ejecutando varias mquinas virtuales. Realmente no importa en que ESX se est ejecutando cada una porque eso es transparente y solo estn para equilibrar la carga de recursos haciendo entre ambos que las MV's corran lo mejor posible.
8.1.1. VMware Tools Una sistema operativo ejecutndose bajo VMware tiene muchas optimizaciones si este tiene VMware Tools instalado. A continuacin se muestran estas caractersticas: Controlador del ratn. Da libertad de movimiento del ratn entre la maquina virtual y el anfitrin. Optimizacin del controlador de vdeo. Mejora el rendimiento de la reproduccin multimedia pero no llega a ser aceleracin por hardware. Soporte drag&drop para arrastrar ficheros con el ratn entre las mquinas. Transferencia de portapapeles entre ambas mquinas. Optimizacin del controlador de red. Mejora del rendimiento de red, sobretodo al utilizar recursos compartidos (NetBIOS, Samba). Sincronizacin del reloj entre la maquina virtual y el anfitrin. Posiblemente esto sea lo ms importante porque es imposible controlar la seguridad de un sistema si no se sabe a qu hora suceden las cosas. Cuando se apaga una mquina virtual su reloj deja de funcionar y al arrancarla tendra la misma hora que al apagarlo. Compatibilidad con las herramientas de lnea de comandos de VMware del anfitrin. Permiten arrancar, apagar, pausar... las mquinas virtuales. La instalacin de las Tools en un sistema operativo Windows es muy sencilla ya que se hace a travs de un asistente en el que solo hay que pulsar Siguiente, Siguiente, Siguiente. En un entorno Linux, como es OSSIM, es algo ms complicado. A continuacin se describen los pasos para la instalacin: 1) Como se van a compilar las Tools hay que tener un compilador y las cabeceras del kernel:
# apt-get install gcc linux-headers-`uname -r` # ln -s /usr/src/linux-headers-`uname -r` /usr/src/linux
2) Montar la imagen de VMware Tools desde el men de VMware. Luego montarla en el sistema y copiar el fichero tar.gz de la imagen a /root:
# mount /media/cdrom # cp /media/cdrom/VMwareTools-5.0.0-<xxxx>.tar.gz
3) Descomprimir el fichero:
59
# tar zxvpf VMwareTools-5.0.0-<xxxx>.tar.gz
4) Ejecutar el instalador:
# cd vmware-tools-distrib # ./vmware-install.pl
5) Se instalarn varios componentes en distintos directorios y se tendrn que compilar algunos mdulos cuando se ejecute el programa de configuracin vmware-config-tools.pl.
8.1.2. El API VIX VIX es una API de VMware que permite escribir programas y scripts para automatizar las operaciones de las mquinas virtuales. Esto incluye ejecutar programas y manipular ficheros. Funciona tanto bajo Windows como bajo Linux y soporta todo tipo de servidores VMware: Workstation, Server y vSphere (ESX/ESXi). Algunas de las capacidades de VIX son: Registrar y desregistrar MV's. Encender, apagar y pausar MV's. Gestionar snapshots. Aadir y borrar directorios compartidos. Copiar ficheros a y desde la MV. Arrancar y detener procesos. Aunque VIX ofrece una API para programar tambin ofrece un programa ya compilado con el que se puede interactuar con las mquinas virtuales. Para hacer la instalacin de VIX hay que descargar 2 el paquete de instalacin. Como sper usuario ejecutar la instalacin, aceptar las condiciones y seguir los pasos de instalacin:
# sh VMware-VIX-1.8.0-xxxxxx.i386.bundle
Despus de la instalacin se puede lanzar vmrun contra el servidor VMware desde cualquier ruta.
8.1.3. Vmrun Vmrun es una utilidad que permite mandar comandos al servidor VMware para gestionar las mquinas virtuales. Para conseguirla basta con instalar la API de VMware VIX. Su modo de empleo es el siguiente:
2- http://www.vmware.com/support/developer/vix-api/
60
vmrun <flags> <comando> <parametros>
Flags
-T <tipo-de-servidor>
Dependiendo del tipo de servidor VMware que se tenga habr que poner: player, ws, fusion, server, esx, vc.
-h <ruta-al-servidor>
Ruta al servidor, normalmente es del tipo https://111.111.111.111/sdk. Si el servidor es local como Workstation no es necesario este flag.
-P <num-puerto>
Puerto donde escucha el servidor. Por defecto es 443.

-u <login-admin>
Nombre de usuario para el servidor de VMware.

-p <pass-admin>
Contrasea para el servidor de VMware.

-gu <login-os>
Nombre de usuario del sistema operativo virtualizado.

-gp <pass-os>
Contrasea para el sistema operativo virtualizado.
Comandos y parmetros
start <fichero-vmx> [gui | nogui]
Arranca la MV, por defecto con interfaz grfica. Si se indica nogui no se mostrara nada al usuario.
stop <fichero-vmx> [hard | soft]
Si se indica hard la MV se apaga inmediatamente, y si se indica soft se manda una seal al sistema operativo para que se apague.
reset <fichero-vmx> [hard | soft]
Si se indica hard la MV se reinicia inmediatamente, y si se indica soft se manda una seal al sistema operativo para que se reinicie.
61
pause <fichero-vmx>
La MV realiza una pausa guardndose su estado para continuar cuando se desee.

unpause <fichero-vmx>
nosVuelve a poner en marcha una MV que estaba pausada.

listSnapshots <fichero-vmx>
Devuelve un listado con los snapshots de una mquina virtual.

snapshot <fichero-vmx> <snapshot>
Genera un snapshot de la MV con el nombre que se le indique.

deleteSnapshot <fichero-vmx> <snapshot>
Borra el snapshot indicado de la mquina virtual.

revertToSnapshot <fichero-vmx> <snapshot>
Modifica el estado de la MV a como se encuentra en el snapshot indicado.

runProgramInGuest <fichero-vmx> <programa> <argumentos>
Lanza un programa con unos argumentos.

runScriptInGuest <fichero-vmx> <interprete> <script>
Lanza un script usando el interprete indicado.

listProcessesInGuest <fichero-vmx>
Devuelve un listado con los procesos que estn corriendo en la MV.

killProcessInGuest <fichero-vmx> <id-proceso>
Mata al proceso indicado.

fileExistsInGuest <fichero-vmx> <fichero>
Comprueba si existe el fichero indicado en la MV.

deleteFileInGuest <fichero-vmx> <fichero>
Borra el fichero indicado en la MV.

renameFileInGuest <fichero-vmx> <fichero-origen> <fichero-destino>
Renombra o mueve el fichero indicado por el nuevo.

createDirectoryInGuest <fichero-vmx> <directorio>
Crea el directorio indicado en la MV.

deleteDirectoryInGuest <fichero-vmx> <directorio>
Borra el directorio indicado.
62
listDirectoryInGuest <fichero-vmx> <directorio>
Devuelve un listado con el contenido del directorio indicado.

copyFileFromHostToGuest <fichero-vmx> <fichero-host> <fichero-mv>
Copia el fichero del servidor VMware a la mquina virtual.

copyFileFromGuesToHost <fichero-vmx> <fichero-mv> <fichero-host>
Copia el fichero de la mquina virtual al servidor VMware.

list
Devuelve un listado con las mquinas virtuales corriendo en el servidor VMware.
Existen ms comandos, escribiendo vmrun en la lnea de comandos se muestra una pequea descripcin de todos ellos.
63
9. Anexo D: OSSEC
9. Anexo D: OSSEC
OSSEC es un software de seguridad que centraliza en un servidor la seguridad de las mquinas donde se han instalado sus agentes. Realmente es un programa informativo ya que solo informa al servidor central y este genera los logs. En este proyecto esto ha sido de gran ayuda ya que ha permitido monitorizar desde el SIEM la seguridad de las mquinas de testeo. Antes de hacer una instalacin de OSSEC, se debe tener en cuenta que las IP's de los hosts deben ser siempre las mismas porque el servidor OSSEC identifica cada mquina a travs de su IP. Para que funcione OSSEC en OSSIM, debe estar activado el plugin de mismo nombre. Para hacerlo se ha conectado a OSSIM a travs de SSH y se ha ejecutado 'ossim-setup'. En el men de detectores dentro de la configuracin del agente se ha activado el pugin OSSEC. Con esto hecho ya se pueden agregar los hosts al servidor OSSEC usando el programa '/var/ossec/bin/manage_agents': 1) Se selecciona agregar un agente. El agente ser el software que se instale en cada host. 2) Se especifica la IP, el hostname y un identificador nico, por defecto est bien. 3) Se selecciona extraer y se especifica el identificador del agente que se quiere instalar. 4) Se apunta la clave alfanumrica que ms tarde se utilizar. Despus de hacer estos pasos, ya se puede instalar el agente OSSEC en el host que se quiera monitorizar. Como en este proyecto los hosts han tenido instalado Windows XP se ha descargado 3 el agente para Windows. Al terminar la instalacin apareca una ventana de configuracin que peda la IP del servidor OSSEC y la clave para el agente. En estos campos se ha introducido la IP del servidor OSSIM y la clave que previamente se haba apuntado. Si se tiene un firewall entre el servidor OSSEC y los hosts de la red se deben permitir las conexiones de estos al puerto UDP 1514 del servidor ya que es donde escucha el servidor OSSEC. En la ruta donde se ha instalado el agente OSSEC para Windows se puede encontrar el fichero de configuracin ossec.conf. Este fichero de texto se puede modificar a mano para especificar que se quiere monitorizar. Los logs ms interesantes que deben estar son: el de aplicacin, el de seguridad y el de sistema. Para la realizacin del proyecto se han introducido los tres.
<localfile> <location>Application</location> <log_format>eventlog</log_format> </localfile> <localfile> <location>Security</location> <log_format>eventlog</log_format>
3 - http://www.ossec.net/main/downloads/
65
</localfile> <localfile> <location>System</location> <log_format>eventlog</log_format> </localfile>
Pero tambin se pueden aadir otros logs que estn en forma de fichero con la condicin de que tenga el formato syslog.
<localfile> <location>C:\Windows\antivirus.log</location> <log_format>syslog</log_format> </localfile>
Windows dispone de varios logs dependiendo del servicio que de el sistema operativo como se ve en la siguiente tabla:
Log Aplicacin Seguridad Sistema Servicio de directorio Servidor DNS Servicio de replicacin de ficheros Fichero Funcin Disponible en Todos los Windows Todos los Windows Todos los Windows Controladores de dominio Servidores DNS
AppEvent.evt Registra eventos determinados por cada fabricante de software SecEvent.evt SysEvent.evt NTDS.evt DnsEvent.evt NtFrs.evt Registra eventos en base a la configuracin de la poltica de auditora Registra eventos de componentes del sistema operativo Registra eventos de directorio activo Registra eventos del servidor DNS
Registra eventos de la replicacin de los Controladores de controladores de dominio dominio
Tabla 9.1: Logs de Windows
Por defecto todos los logs de Windows se almacenan en %Windir%\system32\config, tienen un tamao mximo de 16 MB (Windows Server 2003) o 512 KB (Windows 2000/XP) y se sobreescriben los eventos con ms de 7 das de antigedad. Para una red de Windows con directorio activo se puede utilizar el editor de polticas de grupo para cambiar los ajustes de los logs. Estos ajustes se pueden encontrar en la ruta Configuracin del equipo Configuracin de Windows Configuracin de seguridad Registro de sucesos. OSSEC, adems de los logs, tambin permite monitorizar ficheros y entradas de registro para saber si han sido modificadas.
66
9. Anexo D: OSSEC
<syscheck>  <disabled>no</disabled>  <scan_on_start>yes</scan_on_start>  <frequency>72000</frequency>  <directories check_all="yes">C:\autoexec.bat</directories>  <windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\exefile</wi ndows_registry>  <directories realtime=yes check_all=yes>%WINDIR %/system32/</directories> <ignore type="sregex">.log$|.htm$|.jpg$|.png$</ignore> </syscheck>
La monitorizacin en tiempo real solo funciona con directorios, no ficheros individuales. El servidor de OSSEC que lleva incluido OSSIM tambien lleva la monitorizacin del propio servidor por defecto. Su fichero de configuracin principal est en '/var/ossec/etc/ossec.conf'. Y en el directorio '/var/ossec/rules' se encuentran las reglas de OSSEC para dar mensajes de aviso.
67
10. Anexo E: MODSECURITY
10. Anexo E: MODSECURITY

Un firewall de nivel de aplicacin, o de nivel 7, trabaja filtrando caractersticas propias de los protocolos de este nivel, es decir, de la aplicacin. En el caso de ModSecurity se trata de un firewall capaz de filtrar trfico HTTP por lo que se pueden filtrar las URL a las que se intenta acceder a travs del servidor web. Esto es muy til para evitar, por ejemplo, ataques de inyeccin de comandos en las URL. En el momento en que ModSecurity detecta que una peticin HTTP tiene un patrn que se considera malicioso se bloquea y queda registrada. A continuacin se detalla cmo aplicar el mdulo ModSecurity a Apache para poder filtrar las peticiones al servidor web. Primeramente se necesita instalar las dependencias para poder compilar el mdulo:
apt-get install build-essential libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev
Se descarga la ltima versin de ModSecurity, se compila y se instala:

cd /tmp wget http://ovh.dl.sourceforge.net/project/modsecurity/modsecurity-apache/2.5.12/modsecurity-apache_2.5.12.tar.gz tar zxvf modsecurity-apache_2.5.12.tar.gz cd modsecurity-apache_2.5.12/apache2 ./configure && make && make install
Si todo ha ido bien ModSecurity debera estar en /usr/lib/apache2/modules/mod_security2.so. Posteriormente se crea un fichero para que apache cargue el mdulo.
vi /etc/apache2/mods-available/mod-security2.load
Y se escribe en l lo siguiente:
LoadFile /usr/lib/libxml2.so LoadFile /usr/lib/liblua5.1.so.0 LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so
Se activan los mdulos necesarios:

a2enmod mod-security2 a2enmod unique_id
Se crea el siguiente fichero para comunicar a Apache donde se encuentran las reglas de
69
ModSecurity:
vi /etc/apache2/config.d/mod-security2.conf
Y se introduce la siguiente linea:

Include /etc/modsecurity2/*.conf
Se copian las reglas al directorio definido:

cp /tmp/modsecurity-apache_2.5.12/rules/*.conf /etc/modsecurity2/
Se crean los logs de ModSecurity:

mkdir /etc/modsecurity2 mkdir /etc/modsecurity2/logs touch /etc/modsecurity2/logs/modsec_audit.log touch /etc/modsecurity2/logs/modsec_debug.log
Se comprueba que la configuracin de apache es correcta. El siguiente comando debe devolver OK:
apache2ctl configtest
Y por ltimo se reinicia Apache:

/etc/init.d/apache2 restart
Con el siguiente comando se comprueba que ModSecurity se est ejecutando con Apache:
cat /var/log/apache2/error.log | grep ModSecurity
Si todo est correctamente instalado, debera aparecer en el texto que ModSecurity se ha lanzado.
70
11. GLOSARIO
11. GLOSARIO
Botnet: Es una red de ordenadores personales que sin conocimiento de sus propietarios participan en los planes perversos de alguna organizacin. DLP: Data Loss Prevention. Prevencin de perdida de datos. DoS: Deny of Service. Es un tipo de ataque que tiene como objetivo inutilizar un servidor para que no pueda atender las peticiones de los clientes. Falso positivo: Se refiere a la deteccin de un evento o software como algo maligno cuando en realidad no lo es. Fork: En el mbito del software se refiere a un proyecto que parte del cdigo fuente de otro para tomar un camino diferente en su desarrollo. IDS: Intrusion Detection System. Sistema de deteccin de intrusiones. LOPD: Ley Orgnica de Proteccin de Datos. MV: Mquina Virtual. Port-Mirroring: Se utiliza en los switches de red para mandar una copia de los paquetes de red que circulan por una o varias bocas del switch a otra boca. Los fabricantes suelen darse su propio nombre: SPAN, RAP... SIEM: Security Information & Event Manager. Pueden llamarse SEM o SIM pero son prcticamente lo mismo. Se trata de un gestor que centraliza la captura de logs y otro tipo de informaciones provenientes de distintas fuentes para analizarla y correlarla en la bsqueda de problemas en la red o en los equipos de esta. Snapshot: Hablando de mquinas virtuales es una fotografa que almacena un estado de la mquina virtual. Tunning: Significa configurar y ajustar un software para optimizarlo y conseguir el mximo beneficio de l. UAC: User Account Control. Es una tecnologa incluida en Windows Vista y posteriores que verifica los permisos del usuario antes de realizar acciones administrativas. VDI: Virtual Desktop Infrastructure. Se refiere a la virtualizacin de escritorios.
71
12. BIBLIOGRAFA
12. BIBLIOGRAFA
OSSIM documentation, http://www.alienvault.com/community.php?section=Docs, marzo 2010. OSSIM , Correlation engine explained - Dominique Karg, http://www.alienvault.com/docs/correlation_engine_explained_worm_example.pdf, abril 2010. SNORT Users Manual 2.8.5 - The Snort Project, http://www.snort.org/assets/125/snort_manual-2_8_5_1.pdf, abril 2010. Nagios Core Version 3.x Documentation, http://nagios.sourceforge.net/docs/nagios-3.pdf, abril 2010. Using vmrun to Control Virtual Machines, http://www.vmware.com/pdf/vix160_vmrun_command.pdf, marzo 2010. OpenVAS Compendium, http://www.openvas.org/compendium/openvas-compendium.html, marzo 2010. Nessus/OpenVAS Comparison Test - University of Zagreb, http://security.lss.hr/images/stories/documents/Nessus_vs_OpenVAS_en.pdf, abril 2010. Dominique Karg's Log, http://www.alienvault.com/blog/dk, marzo 2010. VIX API Blog, http://blogs.vmware.com/vix/, abril 2010. Virtualization Wikipedia, http://en.wikipedia.org/wiki/Virtualization, mayo 2010.
Security Information Management with AlienVault - Linux Journal, marzo 2010. OSSEC Host-Based Intrusion Detection Guide - Rory Bray, Daniel Cid, Andrew Hay, abril 2010.
73
13. LICENCIA
13. LICENCIA
GNU Free Documentation License Version 1.3, 3 November 2008 Copyright 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the
75
subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A FrontCover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. The "publisher" means any person or entity that distributes copies of the Document to the public. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these
76
13. LICENCIA
Warranty Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of
77
sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their
78
13. LICENCIA
titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various partiesfor example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled
79
"Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
80
13. LICENCIA
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License. However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
11. RELICENSING
"Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A "Massive Multiauthor Collaboration" (or "MMC") contained in the site means any set of copyrightable works thus published on the MMC site. "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 license published by
81
Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization. "Incorporate" means to publish or republish a Document, in whole or in part, as part of another Document. An MMC is "eligible for relicensing" if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008. The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
82

Gestión de Seguridad en Entornos Virtualizados Utilizando Herramientas Open Source

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestión de Seguridad en Entornos Virtualizados Utilizando Herramientas Open Source

Uploaded by

Copyright:

Available Formats

Proyecto Fin de Mster

Gestin de seguridad en entornos virtualizados utilizando herramientas open source

Ander Elexpuru Ramrez

Director: ngel Barrio Martnez Bilbao, septiembre de 2010

1.1. Objetivos del proyecto................................................................................................................1 1.2. Objetivos personales...................................................................................................................2

Mster Universitario en Seguridad de la Informacin - 2009-2010

1.2. Objetivos personales

Figura 2.1: Servidor HP

Mster Universitario en Seguridad de la Informacin - 2009-2010

Figura 3.1: Diagrama de Gantt I

Figura 3.2: Diagrama de Gantt II

Mster Universitario en Seguridad de la Informacin - 2009-2010

Figura 3.3: Diagrama de Gantt III

4.2. Preparacin de la infraestructura de virtualizacin

Mster Universitario en Seguridad de la Informacin - 2009-2010

Figura 4.1: Port-Mirroring

4.3. Preparacin y puesta a punto de la herramienta SIEM

Figura 4.2: Creacin de redes

4.4. Preparacin de las mquinas de testeo

Mster Universitario en Seguridad de la Informacin - 2009-2010

4.5. Integracin del SIEM en el entorno virtual

4.6. Preparacin del servidor web con firewall de nivel 7

4.7. Realizacin de pruebas

Mster Universitario en Seguridad de la Informacin - 2009-2010

4.8. Redaccin de la documentacin

4.9. Control peridico

Mster Universitario en Seguridad de la Informacin - 2009-2010

5.2. Puntos de mejora

5.3. Conclusiones personales

Mster Universitario en Seguridad de la Informacin - 2009-2010

6. Anexo A: DESARROLLO TCNICO

6. Anexo A: DESARROLLO TCNICO

Mster Universitario en Seguridad de la Informacin - 2009-2010

Figura 6.1: Crear una accin nueva

Figura 6.2: Acciones para la gestin de MV's

6.2. Panel de control VDI

6. Anexo A: DESARROLLO TCNICO

Figura 6.3: Panel de control VDI

Mster Universitario en Seguridad de la Informacin - 2009-2010

6. Anexo A: DESARROLLO TCNICO

Figura 6.4: Creacin del cuadro VDI

Mster Universitario en Seguridad de la Informacin - 2009-2010

6. Anexo A: DESARROLLO TCNICO

Este script graba un fichero log con el siguiente aspecto.

Mster Universitario en Seguridad de la Informacin - 2009-2010

6. Anexo A: DESARROLLO TCNICO

Mster Universitario en Seguridad de la Informacin - 2009-2010

6.3. Plugin VDI

6. Anexo A: DESARROLLO TCNICO

Mster Universitario en Seguridad de la Informacin - 2009-2010

7. Anexo B: ALIENVAULT OSSIM

7. Anexo B: ALIENVAULT OSSIM

Figura 7.1: Arquitectura de OSSIM

Mster Universitario en Seguridad de la Informacin - 2009-2010

7. Anexo B: ALIENVAULT OSSIM

Figura 7.2: Esquema de generacin del riesgo

Mster Universitario en Seguridad de la Informacin - 2009-2010

7. Anexo B: ALIENVAULT OSSIM

7.6. Requisitos de hardware

Mster Universitario en Seguridad de la Informacin - 2009-2010

7.8. Administracin SSH

7. Anexo B: ALIENVAULT OSSIM

7.9. Administracin web