2
Mis conclusiones: Como ya he dicho antes, Alienvault ha hecho bastante por OSSIM, permitiendo que la versión libre y la comercial se retroalimenten, lo cuál es beneficioso para ambas. Ossim dispone de un mantenimiento y una evolución, y Alienvault mejora un producto que luego vende a clientes, y a un precio nada barato por cierto. Como ventajas de la versión Pro podríamos destacar, la cantidad de directivas de correlación de eventos que vienen hechas, es mucho más rica en la pro, aunque en la libre puedes añadir lo que quieras manualmente; la gestión de sondas en la versión libre, los vitals o stats de la máquina, es únicamente la del servidor, y en la pro puedes ver stats de cada sonda en un formato gráfico muy trabajado. Desde un punto de vista de guardar TODOS los eventos, sean o no falsos positivos, OSSIM no permite configurar (o al menos no he encontrado cómo hacerlo) qué eventos quiero definir como falsos positivos, para que no vuelvan a aparecer. Me pregunto yo: ¿qué sentido tiene guardar eventos producidos por mis propias máquinas que sé positivamente que son falsos positivos? Según Alienvault puedes crear una directiva para que no aparezcan pero,… ¿no es más sencillo una opción que te permita hacer un "mute" a esa regla, o crear una excepción? Cuando planificas una auditoría con Openvas o Nessus, te aparecerán alertas de ataques de tus propias sondas. Obviamente, estoy auditando internamente máquinas. ¿Tampoco existe una forma sencilla de añadir direcciones IP a una lista blanca para que no aparezcan nunca como origen? Asimismo, cuando aparecen hosts nuevos, aunque los borres la primera vez, si vuelves a hacer una auditoría, vuelven a aparecer. Esto es más un "nice-to-have" que un "must", pero estaría bien que OSSIM "aprendiera" lo que le dices respecto a direcciones IP anteriormente borradas. La integración con Nagios no está tan lograda como se debería. Sí, te crea automáticamente un fichero con la configuración del asset que quieres monitorizar, pero a la hora de enviar las alertas, hay que tocar el fichero de configuración de Nagios a mano, indicando las direcciones de correo, grupos, etc, a los que hay que notificar cuando haya algún problema en la monitorización de los assets. ¿No debería esto hacerse automáticamente desde la consola? En esta instalación, en el despliegue de un cliente, me dí cuenta que NTOP no monitorizaba el tráfico de los interfaces de red deseados. Buscando los ficheros de configuración, en /var/lib/ntop/init.cfg, la variable INTERFACES estaba siempre con valor "lo" (es decir, localhost)… y con los menús no había manera de hacer que cambiase. Se supone que cuando configuras qué interfaz es el de escucha de tráfico,

Conclusion Es

Embed Size (px)

DESCRIPTION

Conclusiones

Citation preview

Mis conclusiones: Como ya he dicho antes, Alienvault ha hecho bastante por OSSIM, permitiendo que la versión

libre y la comercial se retroalimenten, lo cuál es beneficioso para ambas. Ossim dispone de un mantenimiento y una evolución, y Alienvault mejora un producto que luego vende a clientes, y a un precio nada barato por cierto.

Como ventajas de la versión Pro podríamos destacar, la cantidad de directivas de correlación de eventos que vienen hechas, es mucho más rica en la pro, aunque en la libre puedes añadir lo que quieras manualmente; la gestión de sondas en la versión libre, los vitals o stats de la máquina, es únicamente la del servidor, y en la pro puedes ver stats de cada sonda en un formato gráfico muy trabajado. 

Desde un punto de vista de guardar TODOS los eventos, sean o no falsos positivos, OSSIM no permite configurar (o al menos no he encontrado cómo hacerlo) qué eventos quiero definir como falsos positivos, para que no vuelvan a aparecer. Me pregunto yo: ¿qué sentido tiene guardar eventos producidos por mis propias máquinas que sé positivamente que son falsos positivos? Según Alienvault puedes crear una directiva para que no aparezcan pero,… ¿no es más sencillo una opción que te permita hacer un "mute" a esa regla, o crear una excepción?

Cuando planificas una auditoría con Openvas o Nessus, te aparecerán alertas de ataques de tus propias sondas. Obviamente, estoy auditando internamente máquinas. ¿Tampoco existe una forma sencilla de añadir direcciones IP a una lista blanca para que no aparezcan nunca como origen?

Asimismo, cuando aparecen hosts nuevos, aunque los borres la primera vez, si vuelves a hacer una auditoría, vuelven a aparecer. Esto es más un "nice-to-have" que un "must", pero estaría bien que OSSIM "aprendiera" lo que le dices respecto a direcciones IP anteriormente borradas. 

La integración con Nagios no está tan lograda como se debería. Sí, te crea automáticamente un fichero con la configuración del asset que quieres monitorizar, pero a la hora de enviar las alertas, hay que tocar el fichero de configuración de Nagios a mano, indicando las direcciones de correo, grupos, etc, a los que hay que notificar cuando haya algún problema en la monitorización de los assets. ¿No debería esto hacerse automáticamente desde la consola?

En esta instalación, en el despliegue de un cliente, me dí cuenta que NTOP no monitorizaba el tráfico de los interfaces de red deseados. Buscando los ficheros de configuración, en /var/lib/ntop/init.cfg, la variable INTERFACES estaba siempre con valor "lo" (es decir, localhost)… y con los menús no había manera de hacer que cambiase. Se supone que cuando configuras qué interfaz es el de escucha de tráfico, esto debería modificarse automáticamente. Hablando con gente interna de Alienvault, efectivamente en la versión 4.2.1 hay un bug que no actualiza ese fichero. Si se viene de un upgrade de la 4.1 (como era en mi laboratorio) esto sí que funciona correctamente.

Sigo teniendo múltiples problemas con la configuración de envío de correos indicándole un servidor, tanto desde la consola, como un relay desde las sondas. En mi laboratorio funciona correctamente. En la instalación del cliente, una 4.2.1 pura, ni siquiera hace ademán de enviar un correo (comprobado con un tcpdump -n -i eth0 port 25), teniendo un hostname en formato FQDN.

Si bien la documentación existente a disposición de los mortales me parece bastante pobre, el producto en sí es bastante intuitivo de usar por lo que para cosas más avanzadas como la creación de directivas complejas sería deseable que no se guardasen todo para la versión de pago.

En cuanto a consumo de recursos, si os animais a probarlo, os emplazo a que tengáis cuanta más RAM mejor, puesto que todos los procesos que corren en OSSIM, devoran memoria como si no hubiera un mañana.

Por lo demás, me parece un producto que va en la dirección correcta. Imagino que en la versión free pasa como Fedora con RedHat, en la que los usuarios son los testers de las últimas funcionalidades, con lo bueno y con lo malo que esto tiene. La información que provee es bastante buena y permite aunar en un mismo framework la consola de monitorización de assets, herramientas de monitorización de tráfico de red como NTOP, así como correlar ataques detectados con sistemas operativos/versiones de aplicaciones existentes en la organización junto a auditorías de herramientas automatizadas como Openvas o Nessus con reportes integrados.