Instalación y configuración de OSSIM (alias "The Perfect Setup")
Después de hacer una introducción a esta interesante herramienta de monitoreo, y ya teniendo en mente los programas que utiliza y qué función desempeña cada uno, podemos comenzar a instalar y configurar el sistema. Para el que se perdió las entregas anteriores, pueden leer el completo review que hice de OSSIM en los siguientes links: Parte I, Parte II, y Parte III.
Si bien la instalación es tan simple como la de cualquier otra distribución, la configuración no lo es tanto. Todo va a depender de la red que estamos monitoreando y de las funciones que deseamos utilizar.
En este artículo voy a plantear la configuración que realicé en el sistema de mi empresa, pero puede que no se adapte a toda red. La realidad es que no existe una receta mágica, y uno se va dando cuenta de lo que necesita alertar y lo que desea obviar una vez que tiene el sistema sniffeando.
Lo que planteo a continuación es una lista de pasos de configuración que realicé, a partir de la observación y la lectura de muchos manuales/artículos/tutoriales. Hace más de dos meses que utilizo OSSIM y todavía queda mucho por aprender. La idea es tener un sistema seguro, que alerte sólo lo que necesitamos.

El artículo inicial lo escribí hace más de un mes, pero como era extremadamente extenso y muchos temas se podían tratar por separado, decidí partirlo en varios artículos genéricos, como el uso de NTP, la activación de HTTPS, la configuración de Snort, las modificaciones a Oinkmaster y las actualizaciones automáticas. En este artículo haré referencia a ellos en el caso que la explicación lo requiera.


Configurar switch para monitorear

Para poder monitorear, primero tenemos que ser capaces de recibir el tráfico que nos interesa. En redes switcheadas, si todo va bien, sólo veremos el tráfico dirigido a la máquina conectada, y el tráfico broadcast. Esto por supuesto no nos sirve si queremos monitorear varios servidores o la red completa.
Por suerte los switchs vienen preparados para realizar monitoreo. No se de otras marcas, pero los Cisco ofrecen dirigir el tráfico de otros ports a un dado port. Es decir, es posible enviar al port donde está conectada nuestra máquina monitor todo el tráfico de otros ports.

Los comandos a ejecutar para realizar esta tarea son muy simples. Debemos definir una sesión de monitoreo, y asignar los ports fuentes y el port destino (nuestra máquina monitor).
Suponiendo que tenemos nuestra máquina monitor en el port GigabitEthernet 0/1, y que deseamos monitorear los ports Gi0/4, Gi0/5 y Fa1/7, los comandos a ejecutar serían:
switch(config)# monitor session 1 destination interface G0/1
switch(config)# monitor session 1 source interface Gi0/4, Gi0/5
switch(config)# monitor session 1 source interface Fa1/7
Listo, ya podemos monitorear =)


Instalando OSSIM

OK, el paso más simple será descargar e instalar OSSIM en la máquina destinada a monitoreo.
La descarga la pueden realizar en la sección download de la página de alienvault. La primer decisión que deberán tomar es si instalar la versión de 32 o la de 64 bits. Mi recomendación es que si tienen un procesador de 64bits, instalen la versión de 64bits. Esta versión aprovechará mejor los recursos, y a pesar de la creencia general, las distribuciones de 64bits no ocasionan problemas. Yo utilizo debian de 64bits hace más de 3 años, y no he tenido ningún inconveniente.

El requerimiento de hardware dependerá de la cantidad de hosts a monitorear, y las herramientas de monitoreo que activen. La gente de alienvault recomienda tener una máquina con un mínimo de 2GB de RAM, y por supuesto, una placa de red de 1 Gbit. No hacen ninguna referencia al procesador o al disco, pero por mi experiencia recomendaría como mínimo un Core 2 Duo o un Athlon X2 de 2GHz, y 500GB de disco (realmente se generan muuuuchos logs). Si bien con 2GB de RAM, y desactivando algunos monitoreos, el sistema puede sobrevivir, les recomiendo que se gasten en tener 4GB, así utilizan menos swap y aceleran el sistema.

Los pasos de la instalación son tan simples como el de cualquier distribución basada en debian. Igualmente pueden encontrar una guía en la misma página de OSSIM.


Pasos iniciales

Una vez terminada la instalación, se encuentran con que el sistema inicia en modo consola. Si bien pueden instalar algún entorno gráfico, no creo que valga la pena, simplemente sobrecargarán al ya sobrecargado sistema (a menos que tengan un server con recursos de sobra). Además el sistema funciona completamente por Web, solamente la configuración inicial requerirá que utilicen la consola.

Como bien dije, las herramientas más importantes se visualizan por Web. Por un lado tienen el OSSIM, y por otro Ntop. Si bien Ntop está (al igual que el resto de las herramientas), embebido en las secciones del OSSIM, pueden accederlo directamente a través del port 3000. Ntop no corre sobre apache, sino que ejecuta su propio servidor Web. Les recomiendo que utilicen esta interfaz porque Ntop trae muchísima información que no es desplegada dentro de OSSIM.

Para el resto de la configuración no necesitan estar sentados frente a la máquina monitor, sino que pueden accederlo remotamente a través de SSH, el cual ya viene instalado y funcionando. Claro está que les recomiendo tener siempre un teclado y monitor a mano, porque cuando configuremos el firewall, puede que perdamos la conexión remota =P


Configurar el firewall

OSSIM por defecto trae una configuración de iptables que nos permite acceder a los servicios más importantes (SSL, HTTP y HTTPS), pero obviamente al no conocer de antemano las IPs que tienen permitido el acceso, utiliza una política permisiva que debemos cambiar.
El script que inicia/detiene/reinicia el firewall es /etc/init.d/ossim-firewall. En este script encontrarán que OSSIM realiza un restore de las reglas ubicadas en /etc/ossim_firewall, así que debemos tocar este último archivo.
En ossim_firewall encontrarán, como les anticipé, que las políticas default son ACCEPT. Antes de cambiar esto, debemos modificar las reglas que nos permiten acceso, porque sino, perderemos la conexión (a quién no le ha pasado alguna vez =)).
Para cada servicio utilizado, debemos agregar las IPs desde las que se lo puede acceder. En nuestro caso, remotamente solo accederemos a través de SSH, HTTP, HTTPS, y Ntop, mientras que permitiremos a MySQL que acceda localmente.
Suponiendo que la IP de la máquina monitor es 192.168.1.30 y que permitimos el acceso desde la IP 192.168.1.2, las reglas deberían quedar como las siguientes:
# permitimos ssh
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

# aceptamos que MySQL se conecte localmente
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -s 127.0.0.1 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -s 192.168.1.30 -j ACCEPT

# permitimos HTTP
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

# permitimos HTTPS
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

# permitimos Ntop
-A INPUT -s 192.168.1.2 -p tcp -m state --state NEW -m tcp --dport 3000 -j ACCEPT
Ahora que ya sabemos lo que vamos a permitir, rechacemos todo el resto. Para ello, modificamos las políticas default, cambiando las líneas
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
por
:INPUT DROP [0:0]
:FORWARD DROP [0:0]


Habilitar NTP

Si tenemos una red de mediana a grande, probablemente tengamos configurado algún servidor NTP (sobre todo si están en un entorno Windows Active Directory).
Tal como anticipé en la introducción, hace uno días publiqué cómo configurar el sistema como cliente NTP en el artículo Configurar NTP en GNU/Linux. Se aplica exactamente lo mismo en OSSIM.


Habilitando HTTPS


En la instalación default, OSSIM no provee seguridad para acceder a su interfaz Web, simplemente transmite los datos a través de HTTP. Absolutamente todo fluye a través de HTTP, incluso las credenciales de acceso al server. Por ello, el primer paso a realizar es activar HTTPS.
Al igual que en el caso de NTP, hace un tiempo publiqué un artículo que explica cómo habilitar HTTPS en Apache y sobre cómo forzar el uso de SSL. Me remito entonces a tal artículo porque se aplica lo mismo en este caso: Activar HTTPS en Apache + Forzar SSL.


Deshabilitar servicios

Si bien todas las herramientas tiene su utilidad, puede que no necesitemos todas, y si no las necesitamos, es mejor desactivarlas para que no consuman valiosos recursos.
En mi caso, encontré que las herramientas que detectan servicios en la red no eran necesarias, debido a que conozco los dispositivos que se encuentran conectados, y el gasto de recursos que suponían no valía la pena. Por esto, desactivé las herramientas pads y p0f.
Pads me resultó llamativo por el consumo de CPU. Estando pads activado, la utilización de CPU estaba siempre al 100%, con pads encabezando la lista con alrededor de un 97% de utilización. Realmente este alto consumo no justificaba una funcionalidad que puedo realizar con nmap.
P0f no consume tantos recursos pero si genera muchos logs del tipo "se encontró que una máquina tiene el mismo sistema operativo que antes", es decir, mensajes totalmente inútiles que llenan logs y fastidian la vida de la persona que los lee.
A su vez, dado que el administrador de dominio de la red ya cuenta con otras herramientas para monitorear los hosts, también deshabilité el Nagios.

Para desactivar herramientas, primero eliminamos los links desde los diferentes rc* para que no se inicien cada vez que arrancamos el sistema:
# update-rc.d pads remove
# update-rc.d nagios3 remove
También necesitamos eliminar los servicios de la lista de servicios levantados por OSSIM. Esto lo hacemos comentando las líneas correspondientes en /etc/ossim/agent/config.cfg, en la sección [plugins]:
#p0f_eth0=/etc/ossim/agent/plugins/p0f_eth0.cfg
#pads_eth0=/etc/ossim/agent/plugins/pads_eth0.cfg
La anécdota con este último paso es que si no lo realizamos, cada vez que matamos un servicio, OSSIM lo vuelve a revivir! (servicio Highlander como suele llamarlo Javi).

Ahora sí, estando seguros de que nadie revivirá los servicios, los detendremos con su correspondiente script en /etc/init.d, o bien ejecutamos un kill:
# /etc/init.d/pads stop
# /etc/init.d/nagios3 stop
# killall p0f_eth0


Mantener el sistema actualizado

Algo que es extremadamente importante es mantener el sistema actualizado. Esto permite mantener el sistema seguro, parchando vulnerabilidades.
Tal como les expliqué en el artículo Actualizaciones automáticas de seguridad en GNU/Linux, realizar actualizaciones automáticas pueden provocar inestabilidad y por ello es recomendable aplicar automáticamente sólo actualizaciones de seguridad. En el artículo citado les comento cómo hacer esto con la herramienta unattended upgrades.

Además de las actualizaciones de seguridad, también necesitamos mantener actualizadas las reglas de nuestro snort. Los temas relacionados a la configuración de snort los traté en el artículo Customizando Snort (). Particularmente el tema de actualizar reglas lo pueden encontrar rápidamente en la sección "Mantener Snort actualizado" de dicho artículo.

Cuando se actualizan las reglas de snort, si queremos que OSSIM las detecte debemos ejecutar un script en perl que mapea reglas con entradas en la base de datos del OSSIM (ver Install Oinkmaster and update snort rules):
perl /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules/
Esto lógicamente hay que ejecutarlo cada vez que se agregan/actualizan/eliminan reglas, es decir, cada vez que Oinkmaster hace su trabajo. Por ello podemos agregar una entrada en cron que cada día actualice la base de atos:
# rebuild the sid database of ossim
perl /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules/ 2>&1 | logger -t ossim-snort
Si leen el artículo sobre snort, encontrarán que ya había creado un script para cron que ejecute tareas relacionadas a la actualización de reglas, así que tranquilamente pueden la línea anterior a dicho script.


Acceso a la interfaz Web OSSIM

Cuando utilicen por primera vez la interfaz Web de OSSIM, se encontrarán con que les pide credenciales que ustedes nunca crearon. Pues bien, esta información la pueden encontrar rápidamente en la guía de OSSIM, pero para ahorrarles el trabajo les comento que las credenciales default son admin:admin.
Cuando se logueen por primera vez usando las credenciales anteriores el sistema les pedirá que cambien el password.


Administración de ntop

Luego de instalar OSSIM, ntop ya se encuentra en funcionamiento y podemos ver las estadísticas que arma a partir de los paquetes observados. Pero si quieren ingresar a la sección "Admin", no van a poder porque requiere un password que nunca asignamos. El password lo podemos asignar desde la consola ejecutando el comando:
# ntop -A
En particular, necesité acceder a las preferencias de la sección Admin para setear el path al programa dot, el cual se encarga de graficar la conexión entre nodos. El gráfico lo pueden ver en "IP -> Local -> Network Traffic Map", eso si, si logran entender algo, es un milagro =P


Corregir Nagios

Si decidieron utilizar Nagios, se van a encontrar con un problema. No investigué demasiado, pero alguno de los programas que descubren hosts, los va agregando automáticamente a Nagios para poder realizar el seguimiento. El problema está en que no realiza correctamente la configuración, porque los agrega en un archivo pero no crea la definición del host.
Por ejemplo, el programa descubre un host que escucha en el port 445, entonces agrega el host a hostgroup-services/port_445_Servers.cfg. Ese archivo define grupos de host que escuchan en el port 445. Hasta aca todo bien. Pero como no crea una definición para el host, cuando Nagios intenta leer la configuración, arroja un error del estilo "Error: Could not find any host matching '<IP>' (config file '/etc/nagios3/conf.d/ossim-configs/hostgroup-services/port_445_Servers.cfg', starting on line 1)".
Para que Nagios vuelva a funcionar debemos, o bien quitar de port_445_Servers.cfg la IP del host, o bien crear una definición para el Host. Las definiciones de Hosts están agrupadas en /etc/nagios3/conf.d/ossim-configs/hosts/. Pueden agarrar algún archivo de host ya configurado como base, copiarlo y cambiar la IP. El formato de los archivos que definen hosts es:
define host{
host_name <IP>
address <IP>
use generic-host
}
Deberán generar uno de estos archivos por cada host que tengan en la red. También pueden agregar varias definiciones en un mismo archivo, lo de separarlos es por seguir el funcionamiento de OSSIM.


Desactivar alertas molestas

Como menciono al principio del artículo, OSSIM funciona bien apenas lo instalamos, pero es necesario customizarlo para que nos alerte lo que necesitamos. Las configuraciones default nunca son buenas, y este no es un caso especial. Apenas conecten la máquina a la red para monitorear, van a notar una montaña de alertas con falsos positivos. En mi caso, en dos días monitoreando 8 servidores el log creció 40GB! así no hay disco que aguante. Lo bueno es que uno puede reconocer rápidamente cuáles son los falsos positivos más recurrentes y desactivarlos.

Recuerden que en OSSIM se muestran las alertas de todas las herramientas que corren por debajo, como ser snort, OSSEC, p0f, pads, arpwatch, etc. Por supuesto que el que genera la mayor cantidad de alertas es snort. El segundo en generar alertas molestas es OSSEC. Por ello voy a tratar estas dos herramientas en particular.


Configurar snort

Snort es probablemente la herramienta más importante dentro de OSSIM, pero también la más compleja. Con ella perdi la mayor cantidad de tiempo, monitoreando alertas, buscando y aprendiendo lo que reportaban y desactivando lo que no necesito.

En el artículo Customizando Snort traté todos los temas relacionados a esta herramienta, incluída la desactivación de alertas y la configuración de preprocesadores. Me remito entonces a tal artículo.
Lo único que deben tener en cuenta al leer el artículo es que OSSIM genera un archivo de configuración por cada interfaz de red que utilicemos para monitorear. Por ejemplo, si deseamos monitorear con la interfaz eth0, OSSIM genera y utiliza el archivo de configuración /etc/snort/snort.eth0.conf en lugar del clásico snort.conf. A su vez, como explico también en el artículo de snort, los paquetes snort de debian utilizan las variables configuradas en snort.debian.conf, que en OSSIM están en archivos dependientes de la interfaz (tomando como ejemplo eth0, el archivo se llamará snort.debian.eth0.conf).

Algo que también me llamó la atención es el hecho de tener dos binarios para el snort. Por un lado tenemos el común "snort", y por otro uno llamado "snort_eth0". En el caso de tener más placas de red, tal vez OSSIM habría creado un tercer binario llamado snort_eth1, pero no pude encontrar información al respecto, así que no puedo asegurarlo. No descubrí diferencias entre los binarios snort y snort_eth0, incluso calculé los hashes md5 y dan igual... si alguien tiene idea de cuál es el sentido de tener dos binarios, agradeceré comentarios. La teoría de Javi es que esta distinción entre nombres es para que cuando se listan procesos (por ejemplo usando top), uno pueda ver rápidamente en qué interfaz está escuchando cada proceso de snort.


Personalizar alertas en OSSEC

OSSEC se mostró incordioso con los errores en los logs. Básicamente OSSEC busca expresiones regulares en los logs y cuando detecta patrones extraños, los reporta. También posee otras funcionalidades, pero ésta es la que más se utiliza por default en OSSIM.
Luego de observar un rato los alertas en OSSIM, descubrimos rápidamente el error "Unknown problem somewhere in the system" por destacarse en cantidad de apariciones. Este error para nada descriptivo lo arroja OSSEC cuando detecta la presencia de palabras como error, failure, failed, en los logs, y no existe alguna regla que entienda el error. Esto es, una regla detecta la palabra error, si no existe otra regla que detecte un patrón conocido en esa línea, se arroja el error "Unknown problem somewhere in the system" porque no sabe con qué está lidiando, sólo sabe que es un error.

En el caso de mi monitor, encontré que había muchos errores del tipo "Error reading channel stat information. Missing key" en syslog, y por ello saltaba la alerta. La regla que dispara esta alerta está ubicada en /var/ossec/rules/syslog_rules.xml y tiene el siguiente formato:
<rule id="1002" level="2">
<match>$BAD_WORDS</match>
<options>alert_by_email</options>
<description>Unknown problem somewhere in the system.</description>
</rule>
donde $BAD_WORDS es "core_dumped|failure|error|attack|bad |illegal |denied|refused|unauthorized|fatal|failed|Segmentation Fault|Corrupted". Como no me interesa llenar mi pantalla de monitoreo con este tipo de errores, decidí crear una regla que se abstenga de reportar.

Escribir reglas para OSSEC es relativamente sencillo, posee un poderoso motor de expresiones regulares, así que podemos crear reglas complejas. El formato es XML, así que cualquiera puede adaptarse rápidamente.
Al igual que snort, poseemos un archivo donde agregar reglas definidas por nosotros, el cual es /var/ossec/rules/local_rules.xml.
La regla que definiré no reportará el error si la expresión regular coincide con el error "Error reading channel stat information. Missing key" y el programa que la reporta es nfsen:
<rule id="101002" level="2">
<if_sid>1002</if_sid>
<program_name>^nfsen</program_name>
<regex>Error reading channel stat information. Missing key \s+</regex>
<options>no_email_alert</options>
</rule>
Como observan, el nuevo id es diferente al original. De esta forma, primero matchea la primer regla, pero como hay una regla que dice no alertar estos casos, entonces no lo hace.

Pueden leer más sobre customizar reglas OSSEC en Why does ossec send me so many emails?. Me resultó interesante la frase que citan en el mismo: "To keep ossec useful and yourself sane you need to do some tunning to keep the signal to noise ratio high" =)

Para aprender más sobre OSSEC, vean el FAQ donde pueden encontrar mucha ayuda.


FIN (fin?)

Ya escribí 4 artículos sobre OSSIM (y 5 más que surgieron durante la configuración) y todavía no se si he finalizado o no de analizar esta distribución. Las herramientas que trae son grandiosas, pero requieren de bastante configuración para que se adapten correctamente a nuestras necesidades.
Sin dudas snort es la herramienta más importante y merece un buen estudio, leyendo sus manuales, aprendiendo sobre sus reglas y preprocesadores. Pero así como es de grandiosa es de molesta. Si no está correctamente configurada, tendremos miles de logs inútiles que nos darán un buen dolor de cabeza. Lo bueno es que el código está ahí, ustedes pueden deshabilitar/modificar/agregar reglas de forma muy simple!

Es claro que la configuración que presenté en este artículo está adaptada a las necesidades de mi empresa, pero creo que es lo suficientemente general para adaptarla a la mayoría de las empresas/instituciones, por lo que espero que les sea de mucha utilidad.
Lo que planteo en este artículo tiene muchas horas de investigación, prueba y error, lectura de manuales/blogs/tutoriales/etc. Muchas horas de enojos cuando algo no sale y satisfacción cuando las cosas andan.

Espero haber brindado con esta seguidilla de artículos una especie de guía, algo que yo no tuve, recopilando información y a la vez aportando experiencias y datos que no encontré en ningún lugar.

24 comentarios:

Bumiga dijo...

Excelente artículo, gracias.

Esperemos que no sea el último.

Anónimo dijo...

Excelentes todos tus articulos sobre OSSIM. Ojala no sea el ultimo. Muchas Gracias por compartir.

Anónimo dijo...

Muchas Gracias por estos artículos,,, te cuento que en este momento estoy realizando mi trabajo de grado con esta herramienta y la verdad es que es muy completa, me gustaria poder comentarte algunas cosas extras que he aprendido y me gustaría poder preguntarte otras que aun no entiendo.... ljog10@gmail.com

francesc.joan@gmail.com dijo...

Felicidades por tu aporte al funcionamiento de OSSIM , realmente no hay demasiado informacion estructurada para entender todo su funcionamiento ( yo lo instale hace dos dias y aun tengo problemas con ntop y con el Missing dot , y aun no he encontrado la solucion ni reinstalando graphiz y en el foro en una instalacion default no hay nada) .
Por mi puedes continuar publicando detalles de ossim ( ahora estoy con la integracion de ocs ). Felicidades de nuevo por el articulo :-)

d3m4s1@d0v1v0 dijo...

Gracias por el comentario francesc!
Sigo trabajando con OSSIM, así que probablemente surjan algunos artículos más sobre esta herramienta.
Es verdad que la información disponible no es del todo completa, supongo que con el tiempo irá mejorando.
Lo mejor es buscar la información de cada herramienta por separado y no su relación con OSSIM.

Rodrigo dijo...

Buenas tardes, que gran articulo, me leido los que tienes de OSSIM. Yo apenas estoy empezando a conocerlo y estoy haciendo pequeñas practicas con él.
Tengo un gran inconveniente que no se si me puedas ayudar: Quiero enviar los logs de un switch o un router a mi servidor OSSIM pero no se como hacerlo ni la manera de mostrarlos en la interface gráfica.

Te agradezco muchisimo si me puedes ayudar.

Muchas gracias y muchos éxitos.

d3m4s1@d0v1v0 dijo...

Hola Rodrigo.
No he configurado switchs y routers para que envien los logs a OSSIM, pero he visto que existen plugins en OSSIM para tratar con logs de switchs conocidos, como los Cisco.
Lo que deberías hacer es configurar los switchs y routers para que manden los logs al servidor OSSIM. La forma de hacerlo dependerá de la marca y modelo de cada aparato.
En OSSIM deberás configurar el plugin que trate con dichos logs.
Lamento no poder ayudar más, pero es necesario contar con más información para poder tener una idea de qué plugin se puede usar.

Rodrigo dijo...

Buenas tardes.
Ante todo muchas gracias por tu pronta respuesta. Te comento que voy a trabajar con switchs y routers Cisco y ya logré configurarlos para que envíen logs al servidor OSSIM, pero aún no se como cómo configurar el plugin en el servidor.

Te agradezco muchisimo por tu gran ayuda que me sirve mucho de guía.

Éxitos.

Anónimo dijo...

Excelente trabajo, muchas gracias. Me extraña que casi no mencionas la capacidad de correlacionar de OSSIM. Según tengo entendido es a través de correlación de ataques, vulnerabilidades e inventario que OSSIM elimina los falsos positivos para ofrecer solo alarmas reales. Saludos.

d3m4s1@d0v1v0 dijo...

Si, reconozco que no estoy sacando el máximo provecho de OSSIM. Ultimamente no estuve muy metido en el tema, más que adaptar reglas de snort.
Sin dudas snort es la herramienta que más utilizo y por eso es la que más conozco y sobre la que más me explayo en estos artículos. Espero tener tiempo para trabajar sobre la capacidad de correlacionar.
Hace un tiempo estuve metiendo mano en el código del front end Web de OSSIM, pero todavía no tengo el resultado que deseo. Cuando lo logre, estaré publicando =)
Saludos.

fromem dijo...

Hola Interesantes articulos te agradezco el aporte, los he leido todos cuidadosamente :). Sin embargo, tengo una duda, estoy a penas empezando a probar OSSIM, he trabajado con OSSEC y se que para que un equipo sea monitorizado es necsario instalar un cliente (Agente) y configurarlo para que envie sus log hacia el OSSEC que esta funcionando como Server para ser analizados.

En el caso de OSSIM como le indico que equipos quiero que monitorice? Debo instalar alguna aplicacion cliente en los servidores a ser monitoriados?


Saludos y de antemano, Muchas Gracias por tu ayuda.

d3m4s1@d0v1v0 dijo...

Hola fromem. No es necesario instalar agentes de OSSIM en las máquinas que desees monitorear, sólo debes hacerlo en las máquinas que utilices como sensores, es decir, en las máquinas que monitoreen la red.
Lo que deberás instalar en las máquinas a monitorear depende lo que desees monitorear. Por ejemplo, como mencionas, OSSEC. Tanto OSSEC como Osiris, y Nagios necesitan un agente instalado en la máquina que monitorees. Sin embargo, otras herramientas como snort, arpwatch, y p0f trabajan con datos de la red y sólo deben instalarse en máquinas que actúen de sensores.
Obviamente para decidir dónde instalar los sensores, primero tenes que tener un diagrama actualizado de tu red.
Te recomiendo que leas sobre cada una de las herramientas para ver cuáles necesitan agentes en las máquinas y cuáles no.
Espero te sea de ayuda. Saludos.

Anónimo dijo...

Maestro,
¿Cómo tengo que configurar OSSIM para que los sensores (ubicados en redes distintas) se comuniquen con el servidor de OSSIM?.
Ejemplo:
Servidor OSSIM: 192.168.0.1
sensor01: 192.168.0.2
sensor02: 10.0.0.2
Ambas redes (192.168.0.0/24, 10.0.0.0/24) están interconectadas. Podría añadir una interfaz al servidor y asignar una IP del rango 10.0.0.0/24 (ej: 10.0.0.1). De esta manera, el servidor podría comunicarse con el "sensor02".
Sólo tendría que editar el archivo "/etc/OSSIM/ossim.conf" en el sensor02 (10.0.0.2) y añadir la IP 10.0.0.1 (IP del servidor)?

El tema es que el servidor está configurado para escuchar en una sola IP (192.168.0.1)... No entiendo como el sensor02 (ubicado en 10.0.0.2) le pasa la info al servidor.

Agradezco cualquier ayuda! :)
Saludos!

Carlos Noguera dijo...

Excelente articulo!

En estos momentos estoy desarrollando un proyecto con OSSIM y tu blog ha sido de gran ayuda, gracias por compartir esta información.

Saludos!

Anónimo dijo...

Muy interesantes tus post de Ossim , me puedes indicar si instalando la iso de alienwault también te instala el S.O Debian , es decir si es necesario tener el S.O instalado o se instala al hacerlo desde el CD .

Un saludo
Dani

d3m4s1@d0v1v0 dijo...

La ISO que descargas es el sistema operativo completo, no sólo el software OSSIM, no necesitás instalar más nada. Con quemar la ISO en un DVD y arrancar el sistema desde ahí ya tenés todo.
Saludos!

Anónimo dijo...

Gracias por tu pronta respuesta

Un saludo
Dani

Anónimo dijo...

Hola ,

Es necesario que el sensor y al servidor estén en la misma red ?

Saludos

Grillo Red dijo...

Excelente articulo !!

No se si me puedas ayudar necesito monitorear el ancho de banda, pero no se cual es la herramienta que la ejecuta ni como configurarla...
llevo apenas 2 dias con esta gran herramienta hasta el momento puede configurar el OCSinventory y el Nagios para que monitorear servidores windows.

Seria de gran ayuda tu respuesta

Saludos....

d3m4s1@d0v1v0 dijo...

Hola Grillo, no se si querés monitorear el ancho de banda del servidor OSSIM o de otros dispositivos de red. Para monitorear el ancho de banda local podes usar Nagios, o también sar
El monitoreo de otros dispositivos lo podes hacer con MRTG, podes pegar una mirada a este artículo . O también con un plugin de Nagios y PNP4Nagios.
Espero haberte ayudado un poco.
Saludos

Grillo Red dijo...

Hola d3m4s1@d0v1v0 Gracias por tu pronta respuesta !!

Pues quería monitorear el ancho de banda con el MRTG que esta integrado al OSSIM pero no pude configurarlo... pero si me puedes ayudar a monitorear el ancho de banda con Nagios seria genial !! espero ver pronto nuevos artículos de OSSIM son de gran ayuda...

Saludos !!

Karl dijo...

Hola,

Gracias por el articulo, aunque han pasado unos años desde que lo publicaste, me ha sido realmente util.
He desplegado OSSIM y lo tengo operativo, sin embargo me gustaría personalizar su interfaz web, cambiar algun logo/imagen
¿pudiste modificar el frontend de OSSIM? en tal caso, ¿que modificaste?

Saludos.

v3kt0r dijo...

@Grillo, llego un poco tarde quizás, pero podes darle una mirada al artículo Nagios: generar gráficos con PNP4Nagios.

@Karl, no he modificado el front end de OSSIM, pero hasta donde ví es todo código PHP, así que el login no debe ser difícil de encontrar para modificarlo.
Hace un par de años que no uso OSSIM, ojalá tenga la oportunidad de utilizarlo de nuevo.

Saludos

Anónimo dijo...

buenas ante todo, intento poder ver como ossim sincroniza los activos, porque no me muestra todos los datos.

Publicar un comentario