viernes, 29 de agosto de 2014

OSSIM 13. Conectando un sensor Snort externo y jugando con scripts.

En anteriores episodios de OSSIM, el sistema SIEM open source de AlienVault hablamos de:

1234567 , 89 10, 11, 12 13, 14.

Por cierto, has visto el cuadrante mágico de Gartner para el mundo SIEM de 2014?



En esta entrega vamos a conectar nuestro sistema Snort externo a OSSIM.
Aunque la distribución OSSIM trae por defecto snort y suricata para la recolección de eventos, por motivos de infraestructura puede que queramos conectar los logs de un sistema snort externo, como pueda ser un VPS, una delegación remota, un segmento de red aislado, etc.


El procedimiento es sencillo, aunque deberíamos mejorarlo por tema de perfomance, ahora os cuento.
Basícamente lo que hacemos es que configuamos Snort con una salida syslog.
Configuramos rsyslog en el servidor snort para que envie al rsyslog de OSSIM.
Configuramos el plugin en OSSIM para Snort-Syslog, para que sepa decodificar los eventos.
Adicionalmente vamos a crear una política que ejecute un script por cada detección de evento. El script realizará un baneo de la ip que origina el evento, en varios servidores.

La configuración de snort para la salida hacia SYSLOG es:

alert_syslog output: host = IP: PUERTO, LOG_AUTH LOG_ALERT

He detectado que de esta manera añade al syslog local del servidor Snort los logs, en la rama /var/log/messages.

En el fichero /etc/rsyslog.conf añadimos el servidor remoto, en nuestro caso, OSSIM, que previamente tiene hechos el nat y la reglas del firewall ya que son dos elementos conectados mediante la red de redes (Internet? )

auth.alert @ip:puerto

En esta sección podrás encontrar si cotejas este procedimiento con otros, que la gente hace *.* @. Con esto estaríamos enviando todos los logs del syslog del servidor snort hacia OSSIM, los logs de Snort, y todos los del sistema.
De la manera que indico se filtran gran parte de eventos, aunque se puede jugar más con rsyslog para crear un filtro por la palabra Snort. Tampoco es muy preocupante, pero el Performance disminuye ya que tiene que enviar más log. No muy grave. 

Esto va a hacer que como mediante el agente OSSEC TAMBIEN INSTALADO EN EL SERVIDOR SNORT, para File Integrity Monitor como vimos en el anterior capítulo, está recolectando y enviando logs a OSSIM de sur /var/log/messages, en OSSIM tendremos duplicado el evento IDS Snort, uno que le viene por OSSEC y otro que enviamos por Rsyslog. Crearemos una regla para excluir esto...

Ahora toca el turno de la parte receptora, el servidor OSSIM. En la linea del rsyslog autorizamos la recepción de logs del servidor Snort.

*.* @ip snort.

Ahora configuramos una regla para que los logs que vengan de Snort, los almacene en un fichero exclusivo. Este fichero será el que indiquemos en el plugin snort-syslog ( el que conoce la estructura del log) para poder leer.

vim /etc/rsyslog.d/snortovh.conf :
if $ fromhost == '***********' then /var/log/snortovh2.log
& ~

vim /etc/ossim/agent/plugins/snort_syslog.cfg
source=log
location=/var/log/snortovh2.log

Reiniciamos en ambos servers rsyslog.

En Ossim>configuration>deployment>sensor config.>collection añadimos el plugin snort-syslog.


Ya tenemos los eventos en el SIEM.


Has visto las ip que aparecen con un circulo amarillo? recuerdas el post de OTX? eso es una ip maliciosa. 

Ahora retomamos el post para creación de políticas para nuestros logs, y metemos el evento genérico IDS EVENT que nos viene de /var/log/messages y que no se parsea bien, y lo metemos en una política que me gusta usar llamada "errores_habituales" en la que añado los id de evento que me aparecen, pero no quiero ver en el SIEM. Recuerda que a OSSIM le van a llegar los eventos de Snort por dos vías, por rsyslog y por ossec. Como hemos configurado el plugin que lee snort_syslog para que lea los log del rsyslog, los de ossec aparecen genéricos, por eso los omitimos.

Y ahora? Ya tenemos información de lo que pasa en nuestro servidor. Ahora vamos a pasarle la IP a un script por cada evento, para que banee en varios firewalls. No es la mejor opción, pero dada la infraestructura y necesidades del servidor Snort ( es un vps externo) no podemos poner Snort en modo inline, en modo IPS, es decir, que Snort no para los ataques. Las reglas DROP no funcionan, por ejemplo, si está puesto en modo pasivo mediante un port mirroring o span port en un switch.


Si un atacante ejecuta un exploit, este se ejecuta, pero lo detecta Snort y banea la ip. Esto es útil para escaneos y herramientas de juacker, ya que si el primer exploit o ataque no es satisfactorio, esa ip se banea. En el caso de usar un ataque mediante la red Tor, la cosa se complica ya que la IP del atacante no será la misma. Para estos casos yo recomiendo unos scripts que se bajan todos los días y se incluyen en iptables con las ip´s de Tor que tienen acceso a tu servidor. En otro capítulo lo hablamos o me lo preguntáis directamente.


Las posibilidades de ejecutar comando por cada detección es increíble, la imaginación al poder.

Simplemente tenemos que crear un script en el servidor OSSIM, con la identificación de la shell o lenguaje al principio, como indican las buenas prácticas de scripting, y darle permisos de ejecución.

En OSSIM, creamos una política e indicamos que es para todos los eventos de Snort Signature.


Más abajo en Policy Consequences creamos una acción de ejecución de script, y la vinculamos a la política. Debemos hacer un Reload Policies para que quede activa.



Puedes crear un script sencillo que te escriba en un log para probar que funciona. Por ejemplo.

#!/bin/sh

/bin/echo `/bin/date`: La IP $1 Está atacado >> /tmp/prueba-script.log

chmod 755 script.sh

También puedes probar a pasarle más argumentos al script, como hacemos cuando la acción es enviar un correo informativo.

Espero que os guste el artículo y como siempre, gracias por leerme !!!