Proyecto Fin de Máster

Gestión de seguridad en entornos virtualizados utilizando herramientas open source

Ander Elexpuru Ramírez

Director: Ángel Barrio Martínez Bilbao, septiembre de 2010

Resumen ejecutivo
Mediante la utilización de herramientas de código abierto, se ha desarrollado un Sistema de Gestión de la Seguridad para un entorno virtualizado. A este respecto, el alcance se ha limitado a la monitorización de sistemas de escritorio virtuales (VDI). El objetivo principal es conseguir una gestión centralizada de los ficheros de log de seguridad, utilizando para ello herramientas SIEM basadas en el paquete de código abierto OSSIM. Para ello, se han recolectado ficheros de log de diferentes fuentes heterogéneas tales como: directorio activo, antivirus, firewalls, sistemas DLP, accesos a la plataforma VDI, etc. y se han establecido reglas de correlación entre ellos, con el objeto de conseguir mostrar alertas reales y significativas, reduciendo al máximo el número de falsos positivos. Asimismo, dentro del proyecto, cabe destacar la realización de las siguientes tareas: • Prueba y despliegue de herramientas de código abierto (Nagios) para la gestión de sistemas de información, como alternativa a soluciones de pago utilizadas masivamente en las empresas tales como: HP Openview ó IBM Tívoli. • Despliegue, configuración y tunning de sistemas IDS de código abierto basados en Snort, integración de fuentes de datos con OSSIM. • Personalización del portal y cuadro de mando de OSSIM con alertas más relevantes en servidores virtualizados.. • Integración con el API de VMware en el portal de OSSIM para la realización automática de acciones en los servidores virtualizados: encendido, apagado, etc. • Investigación de otras herramientas de seguridad de código abierto que pudieran aportar valor al proyecto. A este respecto, se han realizado pruebas de herramientas de cortafuegos de aplicación: 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. PLANIFICACIÓN..................................................................................................................... 5 4. TAREAS................................................................................................................................... 7

4.1. Recopilación de información......................................................................................................7 4.2. Preparación de la infraestructura de virtualización....................................................................7 4.3. Preparación y puesta a punto de la herramienta SIEM..............................................................9 4.4. Preparación de las máquinas de testeo.......................................................................................9 4.5. Integración del SIEM en el entorno virtual..............................................................................10 4.6. Preparación del servidor web con firewall de nivel 7..............................................................11 4.7. Realización de pruebas.............................................................................................................11 4.8. Redacción de la documentación...............................................................................................13 4.9. Control periódico......................................................................................................................13
5. CONCLUSIONES................................................................................................................... 15

5.1. Análisis de resultados...............................................................................................................15 5.2. Puntos de mejora......................................................................................................................16 5.3. Conclusiones personales...........................................................................................................16
6. Anexo A: DESARROLLO TÉCNICO.....................................................................................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. Correlación...............................................................................................................................34 7.5. Plugins......................................................................................................................................34 7.6. Requisitos de hardware.............................................................................................................35

v

7.7. Instalación.................................................................................................................................35 7.8. Administración SSH.................................................................................................................36 7.9. Administración web..................................................................................................................37
7.9.1. Cuadros de mando..................................................................................................................37 7.9.2. Incidentes................................................................................................................................39 7.9.3. Análisis...................................................................................................................................40 7.9.4. Informes..................................................................................................................................42 7.9.5. Activos....................................................................................................................................43 7.9.6. Inteligencia.............................................................................................................................45 7.9.7. Monitores................................................................................................................................49 7.9.8. Configuración.........................................................................................................................51 7.9.9. Herramientas...........................................................................................................................53 8. Anexo C: VIRTUALIZACIÓN.................................................................................................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. BIBLIOGRAFÍA.................................................................................................................... 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: Creación de redes.................................................................................................................9 Figura 6.1: Crear una acción nueva......................................................................................................20 Figura 6.2: Acciones para la gestión de MV's......................................................................................20 Figura 6.3: Panel de control VDI..........................................................................................................21 Figura 6.4: Creación del cuadro VDI....................................................................................................23 Figura 7.1: Arquitectura de OSSIM......................................................................................................31 Figura 7.2: Esquema de generación 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: Generación 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: Políticas de OSSIM..........................................................................................................45 Figura 7.16: Acciones para las políticas...............................................................................................45 Figura 7.17: Directiva de correlación...................................................................................................46 Figura 7.18: Regla de una directiva......................................................................................................47 Figura 7.19: Correlación 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: Configuración de usuarios de OSSIM.............................................................................51 Figura 7.24: Listado de plugins............................................................................................................52 Figura 7.25: SIDs de Snort....................................................................................................................52 Figura 7.26: Versión 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 sensibilización en materia de seguridad, en las empresas, cada vez se utilizan más controles, tanto software como hardware, para mantener la seguridad de los entornos y cada control genera sus propios ficheros de log. Estos ficheros son heterogéneos y normalmente se tornan difíciles de manejar para un tratamiento manual, haciendo extremadamente compleja la búsqueda de información durante la gestión de incidentes de seguridad y haciendo inviable, por tanto, la toma de acciones preventivas en relación al análisis de dicha información. Con este proyecto, se pretende estudiar la aplicación de una aproximación preventiva a la gestión 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 heterogéneos entre sí que, mediante la definición de reglas avanzadas de correlación, 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 gestión más sencilla y eficiente de la seguridad. Con la correlación de logs de seguridad se podría 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 más temprana durante el transcurso de un incidente de seguridad, minimizando e incluso pudiendo llegar a evitar por completo el impacto del mismo. En contraposición, 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 podría llegar a dañar seriamente la imagen de la empresa, pudiendo llegar a causar graves perjuicios económicos. A todo esto, habría que añadir los costes de un posterior análisis 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 utilización de herramientas con enfoque preventivo, se persigue detectar incidentes antes de que estos lleguen a producir impacto alguno, contribuyendo activamente con una estrategia de reducción de costes. La situación de crisis actual ha hecho que el software libre sea un producto a tener en consideración por muchas empresas para contribuir a la reducción 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 configuración adecuada, se puede llegar a construir un sistema de gestión de la seguridad con una muy buena relación coste/eficiencia, que puede evitar grandes desembolsos económicos a empresas que se encuentren en una situación delicada, permitiendo así sacar adelante proyectos de seguridad que, de otra forma y debido a fuertes recortes presupuestarios, serían cancelados o post-puestos indefinidamente.

1

Máster Universitario en Seguridad de la Información - 2009-2010

La tendencia creciente del mercado de Tecnologías de la Información hacia la virtualización, y con especial relevancia la incipiente adopción de la virtualización de escritorios (VDI), como un enfoque que mejora los costes a la vez que permite una mejor gestión de la seguridad, hace que la orientación del presente proyecto a un entorno virtualizado, sea uno de las características más reseñables del mismo. Se verán las ventajas de utilizar servidores virtuales frente a servidores físicos como el ahorro en costes y energía, o el mantenimiento más sencillo y ágil. Los entornos virtuales disponen de una serie de características especiales que los distinguen de los entornos físicos a la hora de aplicar controles de seguridad. Por este motivo, se estudiará cómo es posible controlar la seguridad en una red virtual y cómo 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 cómo funciona un correlador de eventos: qué información utiliza para tomar decisiones, cómo se generan las alarmas, etc. Es interesante observar como a través de la concatenación de eventos heterogéneos procedentes de diversos programas, se pueden llegar a unas pocas alertas significativas de seguridad que facilitan la gestión 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 máquinas, y otras aplicaciones más sencillas pero igualmente importantes para gestionar la seguridad como ARPWatch, p0d o Pads. Conocer las características de la virtualización, así como las ventajas que ofrece frente a un entorno físico, 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 implantación de un sistema de gestión de la seguridad en un entorno de semejantes características. Comprobar cómo la virtualización permite el aislamiento de escritorios y la centralización 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 están poniendo en marcha plataformas de basadas en escritorios virtuales (VDI) para controlar las prestaciones de servicios críticos 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 información, código malicioso, etc.. Comprender cómo funciona un firewall de nivel de aplicación, así como la correcta configuración de políticas y reglas, teniendo en cuenta que tiene que trabajar con el protocolo de una aplicación especifica para la cual cumple la función de firewall. Por último, aprender cómo se puede utilizar esta información para gestionar la seguridad del entorno de forma preventiva.

2

2. ALCANCE

2. ALCANCE
Como ya se ha mencionado el proyecto se ha desarrollado sobre un entorno virtualizado. Como software de virtualización de base se ha elegido VMware vSphere 4. Este entorno se ejecutaba sobre unas máquinas físicas que hacían de servidores de virtualización. En este caso se han utilizado 2 servidores HP sobre los que corría VMware ESX 4.0.

Figura 2.1: Servidor HP

Características 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. Además 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 establecía una relación directa entre ellos con objeto de realizar un trabajo lo más independiente posible.

3

Máster Universitario en Seguridad de la Información - 2009-2010

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 instalación 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 edición de 32 bits de OSSIM y una máquina 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 información 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 atención 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 transmisión de logs de las máquinas de testeo a OSSIM. • Snort, para la captura de tráfico 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 máquinas de testeo. • OpenVAS, para el análisis de vulnerabilidades de las máquinas de testeo. Uno de los objetivos más interesantes del proyecto ha sido la integración del OSSIM con VMware a través de su API. Dicha integración se ha limitado a conseguir la capacidad para apagar y encender máquinas virtuales desde el propio OSSIM. No ha pretendido conseguir una integración completa que permitiera tomar acciones sobre las máquinas virtuales, como si se estuviera utilizando el vSphere Client, sino una funcionalidad mínima con la que quedara demostrada la capacidad de enviar ordenes a las máquinas virtuales sin la necesidad de tener una conexión directa con ellas, utilizando el API del entorno virtual.

4

3. PLANIFICACIÓN

3. PLANIFICACIÓN
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 día de lunes a viernes. En la siguiente tabla se muestra la duración planificada para cada tarea que compone el proyecto.

Tareas de desarrollo Recopilación de la información requerida para iniciar las instalaciones Preparación de la infraestructura de virtualización Preparación y puesta a punto de la herramienta SIEM Preparación de las máquinas de testeo Integración del SIEM con el entorno virtual Preparación del servidor web con firewall de nivel 7 Pruebas de las herramientas utilizadas y de las aplicaciones desarrolladas Redactar la documentación que recoge todo el trabajo realizado
Tabla 3.1: Tareas de desarrollo

Días 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

5

Máster Universitario en Seguridad de la Información - 2009-2010

Figura 3.3: Diagrama de Gantt III

Hay que tener en cuenta que a pesar de la planificación que se realizó originalmente, algunas tareas se han desviado en el tiempo por su complejidad haciendo que fuera imposible dedicar tiempo a otras.

6

4. TAREAS

4. TAREAS
4.1. Recopilación de información
En esta tarea se ha empleado una gran cantidad de tiempo con objeto de recopilar información precisa de apoyo para manejar correctamente las herramientas que se han utilizado. A pesar de no utilizar la información a medida que se adquiría, se ha tomado nota cada vez que se conseguía algo interesante que pudiera aportar algún 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 código abierto muy reconocidos en el mundo de la seguridad, para los cuales es preciso recolectar información para comprender su funcionamiento. Por este motivo, la recolección de información sobre la herramienta SIEM no se ha limitado a buscar documentación de OSSIM sino que también 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 investigación es la integración 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 información detallada sobre la API de VMware. La mayor parte de la información se ha conseguido a través de las documentaciones oficiales y buscadores, pero otras fuentes muy recurridas han sido la utilización de listas de distribución y foros, donde se ha podido discutir directamente con gente sobre las cuestiones que iban surgiendo a lo largo del proyecto.

4.2. Preparación de la infraestructura de virtualización
Aunque se tenga que trabajar con hardware virtualizado esto no cambia los requisitos hardware con respecto al hardware físico que se utilizaría. En primer lugar, se han tenido que establecer estos requisitos hardware para cada una de las máquinas del proyecto, que posteriormente serían utilizados por las máquinas virtuales. Una vez establecidos estos requisitos se ha decidido sobre el entorno de virtualización donde se reservarían estos recursos para su utilización en el proyecto. Se ha seleccionado un entorno VMware vSphere 4 compartido con otros proyectos para hacer un aprovechamiento más óptimo de los recursos. Además de la determinación de los requisitos de hardware, se ha establecido una red virtual con

7

Máster Universitario en Seguridad de la Información - 2009-2010

acceso a Internet que solo fuera utilizada por los servidores pertenecientes al proyecto con el fin de evitar conflictos con el resto de máquinas. Una de las herramientas que integra OSSIM, Snort, tiene la capacidad de capturar todo el tráfico que pasa por su interfaz de red configurada en modo promiscuo. Por este motivo, ha sido imprescindible una configuración de la red que permitiera que todo el tráfico de la red llegara a esta interfaz. En el caso de la red virtual, los equipos estaban conectados mediante switches, y estos impedían que el tráfico entre 2 equipos fuera capturado por los demás, haciendo inútil la interfaz promiscua. Para solucionar este problema ha sido necesario configurar Por-Mirroring en los switches de la red. Con el Port-Mirroring el tráfico 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 más tráfico del que se necesita: • Tráfico duplicado. Esto podría pasar si se configura Port-Mirroring en 2 switches de la misma red. • Tráfico que no se puede analizar. Si una red se va a usar como VPN de nada sirve capturar el tráfico 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 característica en los switches, y las herramientas de captura de información de la red no han funcionado. También ha sido crucial la configuración del firewall de la red virtual. OSSIM incluye OpenVAS como componente para mostrar las posibles vulnerabilidades de las máquinas de la red y para que este pudiera funcionar era imprescindible dar permisos de conexión desde el servidor OSSIM hasta las máquinas del entorno.

8

4. TAREAS

4.3. Preparación y puesta a punto de la herramienta SIEM
Esta tarea incluye la descarga de OSSIM de Internet, la preparación de una máquina virtual y la instalación de OSSIM en esta. Para el desarrollo del proyecto se ha utilizado la versión 2.2.1 y la edición de 64 bits. Después de la instalación, se ha actualizado el sistema a la última versión y se han configurado todos los parámetros necesarios para que funcionara la herramienta. Para obtener un mayor detalle al respecto, se puede consultar el punto 7.8 (Administración SSH). Una vez comprobado el correcto funcionamiento de OSSIM, se ha procedido a la instalación 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 máquinas de testeo estas se pudieran escanear.

Figura 4.2: Creación de redes

4.4. Preparación de las máquinas de testeo
Para hacer las pruebas del sistema se ha decidido utilizar un par de máquinas virtuales con Windows para simular ataques entre ellas. Una se ha utilizado como atacante, y la otra como víctima. El atacante no tendría porque ser un usuario malintencionado, sino que podría 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. Además de esto, son más conocidas sus vulnerabilidades lo que lo convierte en un sistema perfecto para realizar las pruebas de ataques. Para la preparación de las máquinas de testeo, se ha creado una máquina virtual, se ha instalado

9

Máster Universitario en Seguridad de la Información - 2009-2010

Windows XP en ella, se ha configurado la red, se han instalado las VMware Tools y por último, aprovechando las características de la virtualización, está máquina se ha duplicado desde el vClient, consiguiendo así dos máquinas virtuales con Windows iguales. Una vez preparadas en la red las máquinas virtuales con Windows, estas han sido agregadas a la parte de activos de OSSIM para tenerlas identificadas por la herramienta y que fuera más sencillo identificarlas en la lista de eventos. Sobre las máquinas de testeo, se ha realizado la instalación del software OSSEC para monitorizar la seguridad de los sistemas. Con este software se ha conseguido transmitir información relevante desde los sistemas con Windows a OSSIM, esto incluye: • Logs de seguridad y del sistema. • Logs de aplicaciones. • Alteración de ficheros importantes, como los ficheros de arranque boot.ini y autoexec.bat. • Alteración de entradas de registro, como las entradas que se cargan al arrancar el sistema. También se ha instalado la herramienta de inventario OCS que ha permitido transmitir de forma automática una lista detallada del hardware y el software que contiene cada máquina Windows. Esto ha permitido conocer, por ejemplo, si se instalaba algún software nuevo que no fuera deseado, o si se ha actualizado el sistema, ya que también informa de las versiones de los programas.

4.5. Integración del SIEM en el entorno virtual
Esta tarea ha sido una de las que más tiempo ha tomado, ya que ha supuesto integrar dos herramientas de software totalmente heterogéneas e inconexas, para establecer una comunicación entre ellas, por un lado OSSIM y por el otro el servidor VMware. Para conseguir esta comunicación, ha sido indispensable la utilización 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 según los pasos explicados en el capítulo 8.1.2. Inmediatamente después ya era posible lanzar el comando vmrun. No obstante para que la comunicación 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 comunicación, se ha procedido a desarrollar el software que permitiera una integración profunda entre OSSIM y el entorno VDI. • Se han creado acciones para el encendido y el apagado automático de máquinas virtuales (punto 6.1). Estas acciones se han utilizado dentro de políticas para reaccionar de forma automática ante distintos eventos, por ejemplo, para evitar la expansión de una infección por la red o un ataque DoS, se puede apagar la máquina 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 máquinas virtuales y comprobar si se encuentran encendidas o apagadas (punto 6.2). Además, en el cuadro se ha implantado un enlace que permite apagar o encender estas máquinas con un solo clic. Este cuadro administrativo ha permitido un manejo sencillo de las máquinas virtuales desde el propio cuadro de mando de OSSIM. • Se ha desarrollado un plugin capaz de normalizar la información 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. Preparación del servidor web con firewall de nivel 7
Para la realización de esta tarea, se ha creado una máquina virtual en el entorno de pruebas y se le ha hecho una instalación de la última versión estable de Debian. En el servidor Debian, se ha hecho una instalación del servidor web Apache y se le ha aplicado el módulo ModSecurity como firewall de nivel de aplicación. Por falta de tiempo, no se ha podido integrar el log de ModSecurity en OSSIM. Para conseguir este objetivo se pretendía instalar un agente de OSSIM en el servidor web que monitorizaría los logs de Apache y de ModSecurity mediante los plugins que ya están desarrollados. El agente iría conectado al servidor OSSIM para comunicarle los eventos del servidor web y del firewall.

4.7. Realización de pruebas
Durante la instalación y configuración de los hosts, se han hecho pequeñas 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 dependía, funcionaban correctamente. Cuando se tenía 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 máquinas 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 utilización de Snort en este entorno ya que era incapaz de capturar tráfico de red. Afortunadamente, gracias al entorno auxiliar con VMware Workstation, se han podido realizar

11

Máster Universitario en Seguridad de la Información - 2009-2010

algunas pruebas, aunque limitadas por los recursos. En este entorno si que funcionaba la captura de tráfico, pero por la limitación de recursos solo se contaba con una máquina de testeo además del servidor SIEM, que tenía 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 cuál no generaba alarmas, era que el riesgo de tal evento no era alto. Así que se decidió hacer una segunda prueba después de subir el valor del activo de la máquina de testeo y la prioridad del evento de escaneo de puertos. La segunda prueba fue más exitosa ya que al capturar los eventos del escaneo de puertos, el riesgo era alto y se generaba una alarma automáticamente. En el entorno principal de pruebas, se ha comprobado cómo se activa una directiva con la que detectar varios intentos fallidos de acceso a la máquina. Para realizar esta prueba, se ha intentado entrar en la máquina con Windows escribiendo mal la contraseña. Si no se hacían muy rápidos los intentos, en OSSIM se podía observar el fallo pero no se generaba ninguna alarma. Sin embargo, cuando se han hecho varios intentos seguidos, se han detectado los múltiples fallos y se ha lanzado una alarma informando de lo sucedido. En esta prueba además ha quedado demostrado el funcionamiento de OSSEC que es el encargado de transmitir el log de Windows a OSSIM. Se ha probado el análisis 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 compartición de archivos de Windows. Otras pruebas realizadas han sido la creación de políticas. En el visor de eventos del SIEM aparecían falsos positivos con demasiada frecuencia y esto hacía muy incómoda la gestión. A través de políticas 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 máquinas pulsando el enlace 'Encender' y se ha podido observar como el cuadro cambiaba al de unos segundos el estado de las máquinas a arrancado, luego se han apagado pulsando 'Apagar' y rápidamente 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 ofrecía. Se ha hecho inyección de comandos en la URL pasados como parámetros 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 máquinas se ha observado que en el visor de eventos aparecían las ordenes indicando qué máquina se estaba apagando o arrancando. Se ha considerado de interés la inclusión de estos eventos en el SIEM porque de esta forma, esta información podría ser utilizada en la creación de directivas, con objeto de dotar al sistema de mayor inteligencia. Habría 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 algún intento de ataque. Pero la falta de tiempo ha hecho imposible la integración de esta información.

4.8. Redacción de la documentación
Como última tarea del proyecto se ha recogido todo el trabajo realizado en una documentación. 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 técnicas 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 utilización de todo el software libre posible, se ha mantenido esta filosofía a la hora de hacer la documentación. • Para redactar la documentación se ha utilizado OpenOffice Writer, que ha permitido, mediante el uso de estilos, agilizar el uso de referencias dentro de la documentación y de índices. • Para la modificación de las figuras se ha usado Gimp. Esta herramienta ha permitido recortar las imágenes para mostrar en la documentación lo realmente importante. • Para la creación de diagramas Dia ha sido de gran utilidad, ya que es una herramienta muy sencilla que sin conocerla ha permitido la creación de diagramas estupendos. • Y por último, para la creación de diagramas de Gantt se ha utilizado OpenProj.

4.9. Control periódico
Durante toda la fase de desarrollo se ha realizado un seguimiento periódico del estado del proyecto. El control se ha realizado a través 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 interés que se hayan descubierto en los que mereciera la pena indagar.

13

5. CONCLUSIONES

5. CONCLUSIONES
5.1. Análisis de resultados
Después 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 además 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 gestión y mantenimiento. Se ha comprobado cómo, a partir de muchas fuentes heterogéneas de información, el SIEM destacaba únicamente un pequeño grupo de eventos. Esto facilita enormemente la tarea del Responsable de Seguridad, al permitir obtener información precisa sobre los incidentes de seguridad fácilmente sin que sea necesario revisar todos los ficheros de las aplicaciones de seguridad, que tomaría una gran cantidad de tiempo. Pero la inteligencia que ofrece la herramienta ha ido más 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 políticas correctamente configuradas y actualizadas, adecuadas a la Política de Seguridad de la empresa dónde se implante. Aunque OSSIM traiga preinstalado un grupo de políticas, el verdadero trabajo del Responsable de Seguridad reside en configurar las políticas que se necesitan para un entorno concreto, tarea que debe llevarse a cabo por personas con conocimientos detallados sobre la arquitectura de seguridad y Política 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 contraseña, 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 información de intentos de acceso habría quedado registrada en el log pero no se habría tomado acción alguna. En cuanto a la integración de OSSIM con la API de VMware, he comprobado que se pueden lanzar acciones de VMware desde cualquier máquina. 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 máquinas virtuales. Las acciones a las MV's se han limitado a dos, encender y apagar, pero con el mismo comando utilizado, también se pueden gestionar ficheros y ejecutar comandos. Además, como se ha visto, no solo se pueden lanzar ordenes de forma manual, sino que se pueden predefinir y ejecutarlas automáticamente cuando sea necesario mediante políticas.

15

Máster Universitario en Seguridad de la Información - 2009-2010

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 podrían haber realizado otras más. En el punto 8.1.3 se describen las funcionalidades que se pueden tener con vmrun. La manipulación de snapshots es una característica muy interesante dado que permite modificar el estado de una máquina a otro anterior, por ejemplo una máquina cuya seguridad se ha visto comprometida se podría restaurar a un estado correcto. El uso de vmrun para ejecutar programas en máquinas virtuales con Windows XP funciona muy bien pero desde Windows Vista, con la inclusión del UAC como medida de seguridad, esto no es tan sencillo. Existe un método que consiste en la creación 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 podría investigar otro método que proporcione mayor flexibilidad y que no obligue a desactivar el UAC. Me habría gustado integrar el log de ModSecurity en OSSIM. Un servidor web es uno de los principales objetivos de los delincuentes por su mayor exposición a ataques, y por esta razón, la información que puede proporcionar un firewall de aplicación sería muy valiosa para el correlador de eventos. Por este motivo, estimo como una gran mejora la transmisión de los logs del servidor Apache y del módulo de firewall al servidor OSSIM. Sería muy interesante comprobar cómo al hacer una consulta contra el servidor web con una URL sospechosa, aparece esta información en el visor de eventos.

5.3. Conclusiones personales
Había oído hablar de OSSIM y tenía 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 podrían dar la sensación de software inmaduro. Tras hacer la instalación hay elementos fundamentales para el funcionamiento de OSSIM que no arrancan por configuraciones incompletas que se podrían hacer de forma automática. He notado que la versión de 32 bits está bastante abandonada si se compara con la de 64 bits, el instalador ni siquiera iniciaba el proceso de instalación y algunos de los componentes de la administración web, como el analizador de vulnerabilidades, no funcionaban. La documentación se puede decir que es bastante caótica y está tan obsoleta que contiene páginas explicando paneles que no existen en el OSSIM actual o al revés, 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 páginas web que, actualmente, ya no existen.

16

5. CONCLUSIONES

La comunidad que tiene en sus foros tiene un tamaño reducido aunque es bastante activa. Sin embargo no se percibe que la gente de OSSIM tenga en consideración las pequeñas 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 podría competir directamente con soluciones comerciales análogas. La creación de directivas de correlación 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 año, me he encontrado en varias empresas con VMware vSphere e incluso lo he podido utilizar. Había trabajado con Workstation pero me he dado cuenta de que es muy diferente la funcionalidad. El hecho de tener máquinas virtuales ejecutándose a lo largo de varias máquinas físicas proporciona una gran flexibilidad. No hay que limitarse a pensar que una máquina está bajo un servidor porque se puede apagar el servidor y la máquina virtual sigue ejecutándose. Tan solo esta característica me parece que le da ya un gran valor a la virtualización por encima de tener servidores físicos. 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 información es muy baja, y esto ayuda también al cumplimiento de normativas , de carácter crítico, como la LOPD. Sin embargo, los programas de seguridad tradicionales no consiguen obtener muchas ventajas de la virtualización. La complejidad para controlar la seguridad en una red virtual me ha parecido muy similar a la de una red física, básicamente hay que aplicar los mismos controles. No obstante, he averiguado que VMware está trabajando en cambiar esto con su tecnología VMSafe, con la que ofrece a las herramientas de seguridad una serie de ventajas o accesos especiales a las máquinas 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 conocía. Algunas, gracias a que han dado más problemas para que funcionaran, las he conocido con más detalle que otras. • He descubierto que Nagios realiza pings a las máquinas 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 aplicación no se encuentra muy bien integrada en OSSIM. Me ha parecido una herramienta estupenda para monitorizar el

17

Máster Universitario en Seguridad de la Información - 2009-2010

estado de cualquier máquina, pero la utilización desde OSSIM se limita a comprobar si las máquinas y sus servicios están arrancados y respondiendo, no pudiendo saber el estado la memoria RAM o la CPU, que también son funcionalidades de Nagios si se usan agentes. • Me habría gustado conocer con más profundidad OpenVAS. Su utilización desde OSSIM ha sido completamente transparente ya que se utiliza a través de la administración web. • OCS es una aplicación que realiza inventarios del software y hardware instalado en las máquinas y centraliza toda esta información en un servidor. Este software tiene muchas más opciones que no he podido ver, además la integración en OSSIM no parecía 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 detección de intrusos en la red. Las reglas cuentan con una condición que cuando un grupo de paquetes detectados en la red la cumplen se activa la regla. Además sus reglas se pueden actualizar automáticamente utilizando la aplicación oinkmaster. • OSSEC ha funcionado perfectamente durante las pruebas comunicando cada evento que sucedía en las máquinas 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 conexión 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 dirección MAC de un equipo. No conozco ningún 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 más 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 máquina virtual, habría que investigarlo. • Pads y p0f también vienen integradas en OSSIM y funcionan desde el inicio. Estas herramientas detectan los servicios y los sistemas operativos de las máquinas 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 tráfico. Se quedan escuchando en la interfaz de red promiscua y sacan toda su información de los paquetes que toquen la interfaz. Y es por este motivo que no pueden ser detectadas convirtiéndose 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 doméstico. 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 páginas web.

18

6. Anexo A: DESARROLLO TÉCNICO

6. Anexo A: DESARROLLO TÉCNICO
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 máquinas 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 información que tiene OSSIM para identificar los equipos es su IP. Una solución es crear un fichero de configuración 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 petición de arrancar la máquina 172.18.40.75 a arrancar [DSII] WinXP.vmx. Para esto se ha realizado el siguiente script que recibe la IP de la máquina 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 configuración, el fichero vmx que corresponde a la IP indicada y con esto ya puede lanzar el comando vmrun. Se asume que la contraseña de administrador va a ser la misma para todos los equipos, si no fuera así solo habría que introducirlas en el fichero de configuración y obtenerlas de la misma forma que el fichero vmx. Con este pequeño desarrollo ya se pueden definir acciones en OSSIM con argumentos variables para que se puedan automatizar.

19

Máster Universitario en Seguridad de la Información - 2009-2010

Figura 6.1: Crear una acción nueva

Un uso muy práctico sería crear las acciones para encender o apagar la máquina origen o destino de un evento. Y mediante el uso de políticas se podrían programar estas acciones como respuesta a ante diferentes eventos.

Figura 6.2: Acciones para la gestión de MV's

Un ejemplo sería la creación de una política que detecte si una máquina está realizando demasiadas conexiones a sus vecinas, una máquina infectada por algún virus o troyano, y que automáticamente se envié una orden de apagar la máquina para evitar que se expanda la infección y se envíe correo electrónico al responsable informándole 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

6. Anexo A: DESARROLLO TÉCNICO

para tomar acciones manuales. Sería muy interesante poder ver en el cuadro de mando de OSSIM el estado de las máquinas 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 máquina está encendida o apagada, y un enlace para lanzar la acción 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 página principal creando más cuadros con la información que se quiera así que se ha agregado un cuadro más y se ha configurado para que muestre un fichero RSS. Este fichero se ha generado a partir del fichero de configuración mencionado antes, al que se ha agregado algo más de información: 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 configuración 'maquinas.cfg' ha sido procesado por el siguiente script para generar automáticamente 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

Máster Universitario en Seguridad de la Información - 2009-2010

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 &lt;img align=top src=http://172.18.40.74/ossim/vdi/verde.png&gt; – &lt;a href=”/ossim/vdi/alterar.php? i=172.18.40.75&amp;a=0”&gt;Apagar&lt;/a&gt;</descripcion> </item> <item> <description>172.18.40.76 – WindowsSeg2-76 &lt;img align=top src=http://172.18.40.74/ossim/vdi/rojo.png&gt; – &lt;a href=”/ossim/vdi/alterar.php? i=172.18.40.76&amp;a=0”&gt;Encender&lt;/a&gt;</descripcion> </item> </channel> </rss>

22

6. Anexo A: DESARROLLO TÉCNICO

En el cuadro de mando de OSSIM se ha pulsado en el enlace 'Edit' que aparece a la derecha para agregar más cuadros. Se ha elegido uno para modificarlo como cuadro de control VDI. Se le ha puesto un título, 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: Creación 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 página web capaz de ejecutar procesos. Ya que OSSIM tiene PHP instalado se ha decidido utilizar esta tecnología. Cuando se haga clic en algún enlace del fichero RSS se carga la web PHP que realmente no lleva nada visible, tan solo ejecuta las acciones pertinentes sobre la máquina seleccionada. A continuación 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

Máster Universitario en Seguridad de la Información - 2009-2010

} 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 atención a esto se podrían inyectar comandos de forma maliciosa. Para controlar la seguridad en este pequeño desarrollo, en primer lugar, se ha validado la sesión del usuario. Si el cliente web no tiene una sesión válida no se le permite hacer nada. En segundo lugar, se han validado los parámetros que recibe el fichero PHP para

24

6. Anexo A: DESARROLLO TÉCNICO

garantizar que son una IP y un número y no la ejecución de un proceso. Por último, se ha mantenido un log que registra cada acción 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 además de registrar los eventos en el log, tiene que realizar la propia acción de arrancar o apagar las máquinas. El siguiente script se encarga de ejecutar el comando vmrun que se comunicará por fin con el servidor VMware.

25

Máster Universitario en Seguridad de la Información - 2009-2010

############ 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 configuración (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

6. Anexo A: DESARROLLO TÉCNICO

# 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 configuración 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 máquinas se pueden apagar y arrancar mediante otros métodos ajenos a este control, convenía tener siempre ejecutando un servicio que comprobara el estado de las máquinas cada cierto tiempo. Para esto, se generó el siguiente script que se mantiene en un bucle.

27

Máster Universitario en Seguridad de la Información - 2009-2010

############ 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 máquinas, 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, tenían 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 tenían que ser leídos, 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 máquinas 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 podía 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

6. Anexo A: DESARROLLO TÉCNICO

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

Máster Universitario en Seguridad de la Información - 2009-2010

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 información 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 máquina virtual se observe tal evento en el panel de eventos SIEM. Y si se desea, se puede correlar esta información en directivas utilizando el id y los sids que se les ha asignado. Un caso práctico que utilice esto, sería un entorno en el que haya un grupo de máquinas dando un servicio de correo electrónico y que en caso de que si se apagan todas no funcionase el correo. Se podría crear una política 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

7. Anexo B: ALIENVAULT OSSIM
OSSIM es un sistema de seguridad integral de código abierto que cubre desde la detección hasta la generación de métricas 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 instalación de otras herramientas de código 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 valoración del riesgo de cada evento y entonces tiene lugar la correlación. Durante el proceso de correlación, a partir de una serie de patrones, se generan nuevos eventos para detectar ataques o problemas en la red. Para acceder a toda la información recogida y generada por el sistema se hace uso de una consola web que además permite configurar el sistema y observar el estado global de la red en tiempo real. Desde esta consola web, también es posible acceder a un gran número de utilidades e informes. Esto pretende ser un pequeño manual de usuario para iniciarse en OSSIM sin entrar en mucho detalle.

7.1. Perfiles
No es necesario instalar OSSIM en una única máquina, se dispone de varios perfiles que podrán instalarse en un mismo servidor o distribuidos en varios dependiendo de las complejidad del entorno.

Figura 7.1: Arquitectura de OSSIM

Sensor
La máquina con perfil sensor se encarga de la colección y normalización 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 términos sensor y agente. Cada herramienta lleva un plugin asociado que indica al sistema cómo ha de procesar la información 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

Máster Universitario en Seguridad de la Información - 2009-2010

En el perfil Sensor se instalan Snort, Ntop, Arpwatch, P0f y Pads. Estas herramientas se encargan de analizar el tráfico 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 también 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 administración 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 máquina 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 combinación de todos los perfiles en una única máquina. Es el perfil de instalación por defecto.

7.2. Activos
Para una empresa un activo es todo aquello que tiene valor para la misma. La información, es uno de los activos más importantes dado que ésta permite llevar a cabo las tareas diarias y sin información, sería imposible la existencia de la empresa. Por consiguiente, hay que entender la información como activo importante a proteger. ¿Dónde se encuentra la información? Se puede llegar a pensar que únicamente en un servidor de base de datos, pero también hay información importante en cualquier otro servidor dentro de la red. También los equipos del personal albergan información más o menos importante dependiendo de las tareas de cada uno. Por lo tanto, para proteger la información habrá que proteger todos y cada uno de los puntos dónde ésta se encuentra. Por todo esto explicado, se van a considerar las máquinas de la red como activos de mayor o

32

7. Anexo B: ALIENVAULT OSSIM

menor valor dependiendo de la información que contengan. Hay dos formas de realizar un análisis del valor de un activo: • Cuantitativo. Se valora en base a su precio. Es un método muy costoso por la complejidad que supone valorar el precio de la información. • Cualitativo. Es un método muy sencillo que consiste en valorar dentro de un rango pequeño la importancia del activo. OSSIM utiliza este método, 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. Además no es igual de relevante el riesgo de un ordenador de uso personal que el de un servidor de ficheros, por lo tanto también hay que tener en cuenta el valor del activo a la hora del calcular el riesgo. También 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 días.

Figura 7.2: Esquema de generación del riesgo

¿Por qué es tan importante el cálculo del riesgo? El riesgo no se puede eliminar por completo, puesto que toda actividad conlleva un riesgo intrínseco, 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 automática. Para ello cuenta con los parámetros prioridad y fiabilidad. Cada evento que pueda suceder en la red debe tener asociado una prioridad y una fiabilidad. • La prioridad, se define por cómo 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

Máster Universitario en Seguridad de la Información - 2009-2010

• 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 parámetro es delicado porque si se cree que algo no es probable que ocurra le se daría un valor bajo pero esto no significa que no vaya a ocurrir, si llegara a suceder podría no lanzarse una alarma por haber asignado un valor bajo aquí. El cálculo del riesgo una vez se tiene el activo, la prioridad y la fiabilidad es muy sencillo. Se corresponde con la siguiente función:
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. Correlación
La correlación, es el proceso por el cual se comprueba cada evento detectado en busca de evidencias que determinen, con cierto grado de seguridad, la aparición de ataques evitando la mayor cantidad posible de falsos positivos. De esta forma se disminuye el número de eventos significativos de millones al día a tan solo unas decenas, simplificando el trabajo para el responsable de seguridad. La correlación 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 situación peligrosa, entonces se lanza la alarma. Lo complicado de la correlación, 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 información captada. Una vez estandarizada ya se puede tratar como un evento y enviársela 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 están continuamente trabajando, leen la información 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

7. Anexo B: ALIENVAULT OSSIM

plugins para Snort, p0f, Arpwatch, Pads y muchos más. • Monitores. Estos solo funcionan bajo petición del servidor. Estos plugins envían la petición a su herramienta asociada y tras obtener la respuesta se la envían al servidor. Todos los eventos detectados por los plugins son los que se correlarán para generar las correspondientes alarmas.

7.6. Requisitos de hardware
A continuación, se describen algunos de los requisitos para hacer una instalación 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 ejecutándose en paralelo por lo que los procesadores multi-núcleo son bienvenidos. Además 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-núcleo de 64 bits. Es más importante la arquitectura que las frecuencias así que no se debe dar importancia a esto último. El tamaño del disco duro es bastante relativo, con 10 GB se puede empezar pero para algo muy básico, para hacer pruebas. En un entorno de producción 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 más o menos potente. Se necesita conexión a Internet para hacer algunas descargas durante la instalación y hacer posteriores actualizaciones. También se necesita una unidad de DVD para montar la imagen ISO de la instalación de OSSIM.

7.7. Instalación
Para hacer la instalación de OSSIM se necesita descargar 1 la imagen ISO de la última versión disponible, en mi caso la 2.2.1. AlienVault recomienda la edición de 64 bits por ser más rápida y yo personalmente la recomiendo porque he encontrado varias características que no funcionaban correctamente en la versión de 32 bits. Se monta la ISO en la unidad de DVD del servidor, se arranca la máquina y comienza la instalación: 1) Se selecciona el modo texto. 2) Idioma el inglés para evitar problemas con tildes y eñes. Pero después se debe elegir
1- http://www.alienvault.com/opensourcesim.php?section=Downloads

35

Máster Universitario en Seguridad de la Información - 2009-2010

correctamente el país y teclado. 3) Para este proyecto se ha hecho la instalación todo en uno (Database, Framework, Server y Agent) aunque lo más interesante sería poner los agentes en otras máquinas. 4) Como interfaz de red primaria se indica la de gestión. 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 partición. Esto genera una partición Ext2 para los ficheros de arranque y una partición 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 instalación puede que necesite bajarse paquetes de Internet, esto puede hacer que se alargue bastante el proceso así que como último paso se requiere paciencia. Después de hacer la instalación, se debe actualizar el sistema y asegurarse de que los diferentes componentes de OSSIM están funcionando correctamente. En el punto 7.8 (Administración SSH) se explica cómo hacerlo.

7.8. Administración SSH
Se puede conectar al servidor OSSIM remotamente con cualquier cliente SSH a través del puerto 22. Existen muchos clientes para Windows pero se recomienda PuTTY. El único usuario con el que se puede conectar a la máquina es 'root' así que se tiene control total sobre la máquina. Se puede instalar software nuevo utilizando utilizando apt-get como con cualquier distribución Debian. También se puede actualizar el software usando 'apt-get update && apt-get dist-upgrade', de hecho se recomienda hacerlo después de hacer la instalación de OSSIM para tener la última versión de los paquetes. Para modificar la configuración definida durante la instalación, hay un programa con menú: 'ossim-setup'. Desde este programa se pueden cambiar parámetros de la hora, leer algunos logs, activar y desactivar detectores y monitores, seleccionar la red que se quiere monitorizar y alguna cosa más. Esta información se encuentra en el fichero de configuración /etc/ossim/ossim-setup.conf. Se puede modificar manualmente este fichero con editor de texto (vi, nano...) y después solo hay que ejecutar 'ossim-reconfig' para que los cambios tengan efecto. En el fichero de configuración mencionado, se encuentra la contraseña de la base de datos de la

36

7. Anexo B: ALIENVAULT OSSIM

instalación de OSSIM. Está en el apartado 'database' y viene con el nombre de variable 'pass'. Es interesante y casi obligatorio conocer esta contraseña porque hay otros ficheros de configuración que deben tenerla pero que les falta tras hacer la instalación. Por ejemplo, si no no en ejecución la instancia de ossim-server es probable que a su fichero de configuración /etc/ossim/server/config.xml le falte la contraseña de conexión 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 parámetro 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 debería ser DAEMON=/usr/bin/$NAME. Sin este servicio no funciona absolutamente nada. En general la configuración de OSSIM se encuentra en /etc/ossim: • Configuración global → /etc/ossim/ossim_setup.conf • Configuración del servidor → /etc/ossim/server/config.xml • Configuración del framework → /etc/ossim/framework/ossim.conf • Configuración 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 configuración interna.

7.9. Administración web
Aunque se pueda conectar a OSSIM a través de SSH, su verdadero uso se hace a través de su página web. Escribiendo la IP del servidor en un navegador se puede acceder a ella. El usuario de administración es 'admin' y la contraseña 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 pestañas con información resumida sobre el estado de la red y de las máquinas que se encuentran en ella. En cada pestaña hay varios gráficos que ayudan a conocer la información más relevante en un rápido vistazo.

37

Máster Universitario en Seguridad de la Información - 2009-2010

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 métricas. 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

7. Anexo B: ALIENVAULT OSSIM

El 'Revovery Ratio' se encuentra en la configuración avanzada donde también se puede obsevar el 'Global Threshold' que es el valor límite de eventos a partir del cual debe ser preocupante la situación 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 conexión entrante a la máquina. En otras palabras, representa la posibilidad de que esté siendo atacada pero esto no significa que el ataque haya sido exitoso. La sección de compromiso representa las conexiones salientes de una máquina. 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 automáticamente 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 creación 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 automáticamente o de forma manual. La gestión de tickets es muy cómoda ya que permite añadir comentarios, adjuntar ficheros, notificar de los cambios a los involucrados y todo esto queda registrado con fecha y hora.

39

Máster Universitario en Seguridad de la Información - 2009-2010

Figura 7.6: Panel de tickets

7.9.3. Análisis SIEM Aquí se encuentra una de las partes más interesantes de OSSIM. El SIEM muestra todos los eventos detectados a lo largo del tiempo. Por cada evento se ve, además de la fecha y hora, de dónde proviene y hacia dónde, el valor de los activos de cada extremo, la prioridad y la fiabilidad del evento, y por último el riesgo del evento. Además se ofrecen muchos filtros para mostrar la información que más interesa. Los eventos se pueden agrupar para saber cuántos 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

7. Anexo B: ALIENVAULT OSSIM

Vulnerabilidades

Figura 7.8: Escaneos de vulnerabilidades

Desde este panel se pueden lanzar análisis de vulnerabilidades haciendo uso de OpenVAS. Realmente la herramienta es transparente ya que se hace todo a través de la interfaz web. Se puede lanzar un análisis inmediato contra una máquina o contra varias. También se pueden programar los análisis para que se realicen periódicamente como se puede ver en la figura 7.9.

Figura 7.9: Lanzamiento de un escaneo

En la pestaña vulnerabilidades se encuentran los informes de los análisis realizados. Aquí se pueden observar las vulnerabilidades de cada máquina y apreciar cómo de grave es la situación de cada una. Esto depende de los servicios que tenga abiertos.

41

Máster Universitario en Seguridad de la Información - 2009-2010

Figura 7.10: Informe de vulnerabilidades

Originalmente OSSIM utilizaba Nessus como escáner 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. Según comparativas, Nessus tiene una base de datos más grande y encuentra más vulnerabilidades conocidas sin embargo OpenVAS encuentra más vulnerabilidades recientes lo que lleva a pensar que está creciendo con más 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, además se encuentran disponibles en varios formatos.

Figura 7.11: Generación de informes

42

7. Anexo B: ALIENVAULT OSSIM

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 instalación de OSSIM lo recomendable es ir a la pestaña Networks y definir la red que quiere gestionar y las redes colindantes alrededor. Una vez defina la red se pueden definir las máquinas que se desean monitorizar en la pestaña 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 máquinas que suelen tener un tratamiento común se las puede introducir en un grupo definido en la pestaña 'Host groups'. La pestaña 'Network groups' es similar pero para redes. En la pestaña 'Ports' se pueden definir listados de puertos que se vayan a utilizar con frecuencia. La pestaña 'Inventory' es la web de administración del servidor OCS. Esto es un servidor de inventario. Si pide usuario/contraseña al entrar se debe utilizar la de administración de OSSIM, admin/admin por defecto. Para utilizarlo hay que instalar un cliente OCS en las máquinas que quiere inventariar. A continuación se explica cómo 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

Máster Universitario en Seguridad de la Información - 2009-2010

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

Después de realizar estos pasos se puede comprobar la presencia de la máquina 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 inventaría el registro de Windows porque sería demasiada información 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 opción 'REGISTRY' y después en el menú 'Registry' agregar una entrada para especificar lo que se quiere monitorizar: • Nombre descriptivo. • Raíz 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

7. Anexo B: ALIENVAULT OSSIM

Componentes SIEM En esta pestaña se pueden observar los componentes de OSSIM, es decir, todas las máquinas que están relacionadas en la instalación. Si se ha realizado una instalación All-in-one entonces solo aparecerá un servidor, si se hace clic en él, se muestra información de los servicios que está ejecutando y a través de que puerto se comunica. 7.9.6. Inteligencia Políticas y Acciones El panel de políticas sirve para determinar que hacer cuando suceden ciertos eventos. Por ejemplo, cuando se hace una instalación nueva de OSSIM siempre hay algún evento que sucede con frecuencia y ahoga la lista SIEM de falsos positivos, con esto se pueden crear política para ignorar estos eventos tan ruidosos. Del mismo modo, si hay algún evento que sea importante se puede hacer que se responda de forma automática con la acción que se quiera.

Figura 7.15: Políticas de OSSIM

En la pestaña de acciones se pueden crear 2 tipos de acciones: mandar un correo electrónico 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 políticas

45

Máster Universitario en Seguridad de la Información - 2009-2010

Directivas de Correlación Las directivas de correlación son la herramienta más 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 están correlados se puede llegar a una conclusión importante y notificar al administrador. Al crear una directiva nueva hay que especificar los siguientes parámetros: • Nombre de la directiva. • Identificador de directiva. • Prioridad que tiene, es decir, la gravedad. Una vez hecho esto la directiva está vacía, hay que agregarle reglas. Las reglas son los eventos que tienen que ocurrir para que se cumpla la directiva, se podrían llamarlas condiciones.

Figura 7.17: Directiva de correlación

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 continuación 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

7. Anexo B: ALIENVAULT OSSIM

◦ Se pueden negar orígenes con el símbolo de admiración (!) de forma que !127.0.0.1 se referiría 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 número 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 podría no detectarse un ataque lento. • Las siguientes características solo aplican a plugins de tipo monitor: ◦ Condición y valor. Condición que se tiene que cumplir para activar la regla. ◦ Intervalo. Durante cuanto tiempo tiene que cumplirse la condición. ◦ Absoluto. El valor de la condición es relativo o absoluto. • Sticky. Por defecto, aunque las reglas tengan indicado ANY en algún 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 acumularán 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

Máster Universitario en Seguridad de la Información - 2009-2010

A continuación se muestra un ejemplo práctico de cómo funciona una directiva. Se trata de una directiva con 2 reglas anidadas: 1) La primera tiene como condición 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 condición 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 también se pueden poner al mismo nivel de forma que sean condiciones sin orden que se tienen que cumplir. Correlación Cruzada

Figura 7.19: Correlación cruzada

La correlación cruzada permite priorizar eventos para los que se es vulnerable. Se utiliza para

48

7. Anexo B: ALIENVAULT OSSIM

alterar la fiabilidad de un evento, aumentando de esta forma el riesgo y por consecuencia la generación 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 pestaña 'Traffic' se encuentra NfSen. Esto es una interfaz web a la herramienta NfDump para el análisis de netflow.

Figura 7.20: NfSen

En la pestaña 'Properties' se encuentra la interfaz de Ntop. Esta herramienta permite monitorizar en tiempo real los usuarios y aplicaciones que están 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 monitorización 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 están disponibles y que sus servicios están funcionando correctamente. La administración de Nagios normalmente se hace a través de sus ficheros de configuración pero en este caso no es necesario. OSSIM agrega automáticamente los equipos a la configuración de Nagios si cuando se definen los activos se marca la casilla 'Enable Nagios'. Se puede hacer esto en cualquier momento modificando los activos, además desde el mismo sitio se pueden especificar los

49

Máster Universitario en Seguridad de la Información - 2009-2010

servicios que se quiere monitorizar de cada equipo. La integración 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 configuración 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 pestaña se pueden observar los sensores de OSSIM, si se ha hecho una instalación All-inone entonces solo aparece el sensor del propio servidor. Si se hace clic en un sensor, se muestra información de los plugins que se están ejecutando en este. Algunos informan de si están funcionando correctamente, otros no pero esto no significa que haya algo mal. En la pestaña 'User Activity' se puede observar un log con los movimientos de los usuarios.

Figura 7.22: Plugins de un sensor

50

7. Anexo B: ALIENVAULT OSSIM

7.9.8. Configuración Principal Aquí se encuentra la configuración interna de los componentes de OSSIM. Tiene una vista sencilla y otra más completa. Es mejor no tocar nada aquí si las cosas funcionan bien. Usuarios La página de configuración de usuarios es muy sencilla de usar. Aquí se gestionan los usuarios que tendrán acceso a la web de administración de OSSIM. En un principio solo existe 'admin' que tiene acceso a todo pero se pueden crear otros usuarios con un perfil de acceso más restringido al área que tenga que gestionar.

Figura 7.23: Configuración de usuarios de OSSIM

Desde aquí también se dispone de una pestaña con la actividad realizada por cada usuario para no perder detalle de lo que el personal haya realizado. Colección 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

Máster Universitario en Seguridad de la Información - 2009-2010

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 más el sid OSSIM sabe que evento concreto ha sucedido. Cada evento tiene asociada una prioridad y una fiabilidad que se puede modificar según las necesidades particulares del entorno.

Figura 7.25: SIDs de Snort

52

7. Anexo B: ALIENVAULT OSSIM

Actualización de Software En esta página se muestra la versión de OSSIM que se está ejecutando y la versión del esquema de la base de datos, 2.2.3 para ambos en la captura. Cuando se hace una actualización vía apt-get se actualizará el software, es decir, la versión de OSSIM, pero no el esquema de base de datos. Este hay que actualizarlo inmediatamente después desde esta página. 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 versión del software.

Figura 7.26: Versión 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 modificaría la base de datos a un estado antiguo. 7.9.9. Herramientas Backup La información 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 página de backup permite precisamente esto, recupera la información de Snort del día que se desee y la vuelca en la base de datos para que se pueda estudiar. También hace la operación inversa para cuando ya no se necesite esta información en la base de datos. En la página aparecen 2 columnas, una con las fechas que se pueden insertar en la base de datos y otra con las fechas que ya están 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

Máster Universitario en Seguridad de la Información - 2009-2010

Figura 7.27: Copias de datos de Snort

Descargas La página de descargas contiene una serie de programas que se pueden instalar en otras máquinas de la red para que se puedan comunicar con el servidor OSSIM. Algunos vienen con ficheros de configuración pre-modificados para funcionar específicamente con el servidor que se esté administrando aunque conviene mirarlos por si hay algo incorrecto. A continuación se muestra una lista con el software que se puede encontrar: • PuTTY for Windows. Cliente para manejar el servidor OSSIM a través de consola SSH. • OSSIM Agent para Windows. Un agente OSSIM para instalar en Windows. • Python para Windows. Intérprete de comandos necesario para ejecutar programas escritos en Python sobre Windows. Es mejor obtener la última versión desde su web oficial. • OCS. Esta aplicación 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 aplicación puede ser útil para comunicar los logs a OSSIM. • OpenVPN para Windows. Gestión de una VPN. • Snare. Este programa es capaz de comunicar los logs de sucesos del sistema a OSSIM. • Osiris. Este programa comprueba periódicamente modificaciones en ficheros importantes del sistema y en caso de encontrar cambios los informa a OSSIM.

54

7. Anexo B: ALIENVAULT OSSIM

• OSSEC. Combina las características 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. Además es probable que encontrar versiones más recientes de los programas en sus respectivas páginas 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 botón 'Scan' OSSIM escanea la red y cuando termina se pueden observar los resultados encontrados. Dependiendo del tipo de escaneado realizado se ve más o menos información. 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

Máster Universitario en Seguridad de la Información - 2009-2010

agregar. Después 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 información 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 opción permite agregar el host a la lista de Nagios, para que este verifique periódicamente su disponibilidad. • Description. Descripción 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: VIRTUALIZACIÓN

8. Anexo C: VIRTUALIZACIÓN
La virtualización es la abstracción de los recursos de un ordenador. Se trata de una capa de software entre al hardware de la máquina física y el sistema operativo de la máquina virtual que permite crear una versión 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 máquina física (CPU, memoria, red, almacenamiento) y los reparte dinámicamente entre las máquinas virtuales que se estén ejecutando. De modo que permite tener varias máquinas virtuales sobre el mismo equipo físico. Por ejemplo, si se dispone de una red empresarial en la que cada empleado tiene un ordenador. Si se piensa en virtualizar, no sería necesario comprar un equipo a cada empleado. Basta con tener un par de servidores potentes en los que se virtualizarían las máquinas y la red. El mantenimiento del hardware es mucho más sencillo. En 4 pasos se puede ampliar la memoria o el almacenamiento de cualquier MV. Además el hardware virtual eleva el factor de obsolescencia de las máquinas físicas ya que viene limitado por los servidores sobre los que se está ejecutando.

8.1. VMware
VMware es una compañía que ha creado varios productos para la virtualización de hardware. Se puede decir que esta compañía a sabido utilizar las ventajas de la virtualización como ninguna. Su producto más fuerte actualmente es VMware vSphere que además de permitir crear máquinas virtuales cuenta con las siguientes características propias: • Fault Tolerance. Se mantiene siempre una copia del estado en curso de las máquinas virtuales para que en caso de que falle el servidor las máquinas 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 máquina. • 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 tráfico tanto entre máquinas virtuales como entre hosts físicos. • vCenter CapacityIQ. Esta característica hace que equilibre la carga de las máquinas virtuales entre las servidores ESX aprovechando al máximo 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 máquinas virtuales para que en caso de que se hayan perdido datos estos se puedan recuperar rápidamente. • vCenter Configuration Manager. Este gestor comprueba de forma automática que los cambios que se hagan en el sistema cumplen con las políticas establecidas. • vCenter Orchestrator. Automatización de tareas de gestión de máquinas virtuales que se

57

Máster Universitario en Seguridad de la Información - 2009-2010

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 información entre las máquinas para descubrir cuellos de botella.

Figura 8.1: Arquitectura VMware

Una arquitectura sencilla para entender cómo funciona una instalación de VMware se podría explicar con la figura 8.1. Se necesita un servidor de almacenamiento que contenga las máquinas virtuales, varios servidores ESX que serán los que ejecuten las MV's y un servidor vCenter desde donde controlar el estado tanto de los servidores ESX como de las máquinas 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 físico. Al igual que en el esquema anterior, hay dos

58

8. Anexo C: VIRTUALIZACIÓN

servidores ESX ejecutando varias máquinas virtuales. Realmente no importa en que ESX se está ejecutando cada una porque eso es transparente y solo están 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 ejecutándose bajo VMware tiene muchas optimizaciones si este tiene VMware Tools instalado. A continuación se muestran estas características: • Controlador del ratón. Da libertad de movimiento del ratón entre la maquina virtual y el anfitrión. • Optimización del controlador de vídeo. Mejora el rendimiento de la reproducción multimedia pero no llega a ser aceleración por hardware. • Soporte drag&drop para arrastrar ficheros con el ratón entre las máquinas. • Transferencia de portapapeles entre ambas máquinas. • Optimización del controlador de red. Mejora del rendimiento de red, sobretodo al utilizar recursos compartidos (NetBIOS, Samba). • Sincronización del reloj entre la maquina virtual y el anfitrión. Posiblemente esto sea lo más importante porque es imposible controlar la seguridad de un sistema si no se sabe a qué hora suceden las cosas. Cuando se apaga una máquina virtual su reloj deja de funcionar y al arrancarla tendría la misma hora que al apagarlo. • Compatibilidad con las herramientas de línea de comandos de VMware del anfitrión. Permiten arrancar, apagar, pausar... las máquinas virtuales. La instalación de las Tools en un sistema operativo Windows es muy sencilla ya que se hace a través de un asistente en el que solo hay que pulsar Siguiente, Siguiente, Siguiente. En un entorno Linux, como es OSSIM, es algo más complicado. A continuación se describen los pasos para la instalación: 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

Máster Universitario en Seguridad de la Información - 2009-2010

# tar zxvpf VMwareTools-5.0.0-<xxxx>.tar.gz

4) Ejecutar el instalador:
# cd vmware-tools-distrib # ./vmware-install.pl

5) Se instalarán varios componentes en distintos directorios y se tendrán que compilar algunos módulos cuando se ejecute el programa de configuración 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 máquinas 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. • Añadir y borrar directorios compartidos. • Copiar ficheros a y desde la MV. • Arrancar y detener procesos. Aunque VIX ofrece una API para programar también ofrece un programa ya compilado con el que se puede interactuar con las máquinas virtuales. Para hacer la instalación de VIX hay que descargar 2 el paquete de instalación. Como súper usuario ejecutar la instalación, aceptar las condiciones y seguir los pasos de instalación:
# sh VMware-VIX-1.8.0-xxxxxx.i386.bundle

Después de la instalación 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 máquinas 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

8. Anexo C: VIRTUALIZACIÓN

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>

Contraseña para el servidor de VMware.
-gu <login-os>

Nombre de usuario del sistema operativo virtualizado.
-gp <pass-os>

Contraseña para el sistema operativo virtualizado.

Comandos y parámetros
start <fichero-vmx> [gui | nogui]

Arranca la MV, por defecto con interfaz gráfica. Si se indica nogui no se mostraría 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 señal 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 señal al sistema operativo para que se reinicie.

61

Máster Universitario en Seguridad de la Información - 2009-2010

pause <fichero-vmx>

La MV realiza una pausa guardándose 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 máquina 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 máquina 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 están 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

8. Anexo C: VIRTUALIZACIÓN

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 máquina virtual.
copyFileFromGuesToHost <fichero-vmx> <fichero-mv> <fichero-host>

Copia el fichero de la máquina virtual al servidor VMware.
list

Devuelve un listado con las máquinas virtuales corriendo en el servidor VMware.

Existen más comandos, escribiendo vmrun en la línea de comandos se muestra una pequeña descripción 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 máquinas 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 máquinas de testeo. Antes de hacer una instalación 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 máquina a través 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 través de SSH y se ha ejecutado 'ossim-setup'. En el menú de detectores dentro de la configuración 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 alfanumérica que más tarde se utilizará. Después 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 instalación aparecía una ventana de configuración que pedía 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 había 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 configuración ossec.conf. Este fichero de texto se puede modificar a mano para especificar que se quiere monitorizar. Los logs más interesantes que deben estar son: el de aplicación, el de seguridad y el de sistema. Para la realización 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

Máster Universitario en Seguridad de la Información - 2009-2010

</localfile> <localfile> <location>System</location> <log_format>eventlog</log_format> </localfile>

Pero también se pueden añadir otros logs que estén en forma de fichero con la condición 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 Aplicación Seguridad Sistema Servicio de directorio Servidor DNS Servicio de replicación de ficheros Fichero Función 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 configuración de la política de auditoría Registra eventos de componentes del sistema operativo Registra eventos de directorio activo Registra eventos del servidor DNS

Registra eventos de la replicación 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 tamaño máximo de 16 MB (Windows Server 2003) o 512 KB (Windows 2000/XP) y se sobreescriben los eventos con más de 7 días de antigüedad. Para una red de Windows con directorio activo se puede utilizar el editor de políticas de grupo para cambiar los ajustes de los logs. Estos ajustes se pueden encontrar en la ruta Configuración del equipo → Configuración de Windows → Configuración de seguridad → Registro de sucesos. OSSEC, además de los logs, también permite monitorizar ficheros y entradas de registro para saber si han sido modificadas.

66

9. Anexo D: OSSEC

<syscheck> <!-- Activa o desactiva la monitorización. --> <disabled>no</disabled> <!-- Hacer el escaneo al arrancar --> <scan_on_start>yes</scan_on_start> <!-- Cada cuantos segundos se deben controlar los cambios --> <frequency>72000</frequency> <!-- Ficheros a monitorizar --> <directories check_all="yes">C:\autoexec.bat</directories> <!-- Entradas de registro a monitorizar --> <windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\exefile</wi ndows_registry> <!-- Directorios a monitorizar en TIEMPO REAL --> <directories realtime=”yes” check_all=”yes”>%WINDIR %/system32/</directories> <ignore type="sregex">.log$|.htm$|.jpg$|.png$</ignore> </syscheck>

La monitorización en tiempo real solo funciona con directorios, no ficheros individuales. El servidor de OSSEC que lleva incluido OSSIM tambien lleva la monitorización del propio servidor por defecto. Su fichero de configuración 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 aplicación, o de nivel 7, trabaja filtrando características propias de los protocolos de este nivel, es decir, de la aplicación. En el caso de ModSecurity se trata de un firewall capaz de filtrar tráfico HTTP por lo que se pueden filtrar las URL a las que se intenta acceder a través del servidor web. Esto es muy útil para evitar, por ejemplo, ataques de inyección de comandos en las URL. En el momento en que ModSecurity detecta que una petición HTTP tiene un patrón que se considera malicioso se bloquea y queda registrada. A continuación se detalla cómo aplicar el módulo ModSecurity a Apache para poder filtrar las peticiones al servidor web. Primeramente se necesita instalar las dependencias para poder compilar el módulo:
apt-get install build-essential libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev

Se descarga la última versión 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 debería estar en /usr/lib/apache2/modules/mod_security2.so. Posteriormente se crea un fichero para que apache cargue el módulo.
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 módulos necesarios:
a2enmod mod-security2 a2enmod unique_id

Se crea el siguiente fichero para comunicar a Apache donde se encuentran las reglas de

69

Máster Universitario en Seguridad de la Información - 2009-2010

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 configuración 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, debería 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 organización. DLP: Data Loss Prevention. Prevención 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 detección 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 código fuente de otro para tomar un camino diferente en su desarrollo. IDS: Intrusion Detection System. Sistema de detección de intrusiones. LOPD: Ley Orgánica de Protección de Datos. MV: Máquina 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 prácticamente 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 búsqueda de problemas en la red o en los equipos de esta. Snapshot: Hablando de máquinas virtuales es una fotografía que almacena un estado de la máquina virtual. Tunning: Significa configurar y ajustar un software para optimizarlo y conseguir el máximo beneficio de él. UAC: User Account Control. Es una tecnología 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 virtualización de escritorios.

71

12. BIBLIOGRAFÍA

12. BIBLIOGRAFÍA
“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

Máster Universitario en Seguridad de la Información - 2009-2010

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

Máster Universitario en Seguridad de la Información - 2009-2010

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 parties—for 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

Máster Universitario en Seguridad de la Información - 2009-2010

"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

Máster Universitario en Seguridad de la Información - 2009-2010

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

Sign up to vote on this title
UsefulNot useful