OSSIM 19. El poder de la correlación. ejemplo iptables denial of services
SERIE OSSIM. (1, 2, 3, 4, 5, 6, 7 , 8. 9 10, 11, 12 13, 14.,15, 16 ,17 18)
En el artículo de hoy vamos a trabajar con la correlación, el motor de inteligencia de OSSIM.
En el artículo de hoy vamos a trabajar con la correlación, el motor de inteligencia de OSSIM.
Hemos visto muchos usos de OSSIM relacionados con la seguridad, pero momento no deja de ser un Syslog centralizado, con una interface gráfica, y una serie de herramientas integradas en una distribución.
El mundo SIEM ( Gestión de eventos de la seguridad de la información) es toda una disciplina dentro de la seguridad, al igual que el pentesting, reversing, forensic etc. Esta es la opinión de la gente de Gartner sobre el software SIEM para 2014.
Cuando alguien se inicia en este mundo suele empezar con la instalación de una herramienta de logs centralizada en la que observar lo que pasa en su entorno. El principal reto es discriminar los logs de información, identificando cuales son relativos a la seguridad, o la seguridad que yo necesito.
Vamos a poner un ejemplo gráfico.
Hay eventos de seguridad, hay logs, es gráfico, pero es un logs de 3 minutos, filtrado por las opciones que me deja el front-end (log-analyzer). Como encontrar un incidente de seguridad más o menos complejo, en un log de 300.000 líneas, para un solo día? Ahí es donde podemos usar el motor de inteligencia de OSSIM.
Vamos a trabajar con un supuesto de iptables.
Cuando ejecutamos una regla en iptables tenemos la opción de indicar que haga log, creamos dos líneas una para el drop y otra para el log, en orden inverso xD ( si primero bloqueas, no llega al log).
Yo tengo activado en OSSIM el PLUGIN que parsea los logs de iptables, que los "entiende", sin tener que hacer uno a medida con regular expressións.
Cada vez que iptables bloquea un paquete de una ip por la coincidencia de una regla, crea un log que visualizo en OSSIM.
Esto es mucha información, en unos segundos se nos va a llenar la lista de este evento. El ser humano tiene la capacidad de adaptación, por lo que el segundo día, no haces NADA con los logs, los borras, buscando el log mágico que te de toda la información a un click... Igual que con las alertas de Nagios mal configuradas, el servicio de correo al final es un simple "heart beat" del sistema, si llevas una tarde sin alertas de Nagios es que Nagios está roto, no que todo va bien :-).
En el tercer artículo la serie hablábamos de crear una política para incluir los eventos que no nos interesan, o que nos proporcionan poca información, para ocultarlos en el sistema.
Una de las opciones que indicamos fue la de no mostrar los eventos en el panel SIEM, pero usarlos en la correlación.
Podemos hacer esto con el evento de arriba de Iptables, que no lo muestre, pero lo use con la inteligencia.
Podría haber usado el típico ejemplo de la fuerza bruta: no muestres un login_failed, pero en tres intentos muestra un evento de fuerza bruta. Pero quizás este también os interese.
El propósito de mi correlación es detectar amenazas persistentes o ataques de denegación de servicios distribuidos.
Si tenemos unas reglas de iptables para cortar ataques, como sabemos que seguimos siendo atacados? Con este log de iptables. Recuerda que son ip´s que están baneadas y aún siguen intentando conectar.
Mi correlación va a ser simple, cuando encuentre 50 ocurrencias del log, muestra un evento que diga: Posible DDOS 50 intentos.
**
La idea completa es anidar esta correlación con otra correlación. Tener este evento, y que ocurra en más de 50 ip de origen, es un claro síntoma de un ataque DDOS. Para una ip o dos puede ser un bot tonto o un mal hacker. La idea es asociar una serie de medidas de contención automáticas contra un ataques DDOS.
**
Entramos en la sección de inteligencia y a continuación Directives.
Podemos ver las directivas que vienen con OSSIM, incluso clonarlas para editarlas a nuestro gusto.
Nosotros vamos a por todas y creamos una nueva.
Si leíste la teoría del artículo 10 sobre el cálculo del riesgo, esta parte es obvia.
Elegimos el Data Source del evento, en este caso indicamos que es un evento IPTABLES.
A continuación indicamos el evento que queremos que dispare nuestra correlación. Si no indicamos nada la correlación se iniciaría con cualquier evento de esa fuente.
Ahora podemos granular, afinar los orígenes y destinos del evento. Podemos trabajar como siempre en OSSIM con la información de Assets, o incluso con la variables Home_Net.
Podríamos indicar más opciones como tipo de puerto, usar los campos específicos del evento, usuario y contraseña si el evento manejase esta información, etc. Para esta regla no es necesario.
Ahora añadimos una acción, que será la ejecución de otra regla. En este caso, crearemos la misma regla que anteriormente, pero modificaremos el número de ocurrencias a 50.
Es importante indicar que la Reliability o la posibilidad de que este evento no sea un falso positivo, un valor que al ejecutar la regla del cálculo del riesgo de un valor por encima de 1, o no nos mostrará la información en el SIEM. Seguro que te has leído la teoría :-)
La directiva queda de la siguiente forma:
De esta manera, no tenemos los molestos logs por cada intento de conexión, pero cuando una ip intente 50 veces conectar, nos aparecerá el evento de posible DOS.
/etc/ossim/server/**********************# vim user.xml
En otra entrada realizaremos una directiva o correlación que anide otra correlación, y haremos alguna un poco más compleja usando diferentes data sources e incluso ntop.
**
por ejemplo podríamos crear una directiva que sea:
si encuentra más de un evento snort ( dos por ejemplo) y luego encuentra un login_ok desde la misma ip, alertar de un posible ataque fructuoso.
si encuentra un brute force y luego un login de ese mismo usuario, aunque sea de una ip origen distinta...
**
Espero que os guste, gracias por leerme.
