Correlacin de Eventos

Qu es un Correlacionador?
Correlacin.-

Del latn Co (cum)- reunin y relacin (relatio, onis) Comparacin. Es la reunin de eventos con la finalidad de llevar a cabo una comparacin. De acuerdo a la definicin anterior, un correlacionador es un dispositivo cuya finalidad es comparar una serie de sucesos, para un fin determinado.

Qu es un Correlacionador?
En el caso de los sistemas de seguridad informtica, la finalidad de un correlacionado es:
Prevenir

ataques. Mitigar el impacto. Planear nuevas estrategias de seguridad.

Qu hace especficamente?
Detecta y determina el nivel de severidad de:

Ataques a vulnerabilidades conocidas (Exploits). Ataques por Fuerza bruta. Ataques DoS. Malware. Ataques a nivel de Red. Ataques a sistemas SCADA (Software de Adquisicin de Datos y Control de Supervisin). Escaneo y sondeo de la red. Actividad Maliciosa.

Cmo?
Rene

informacin que generan los sistemas de deteccin de intrusos (IDS), los sistemas de prevencin (IPSs o IDPs), los sistemas de monitoreo de disponibilidad, los logs de sistema y los HIDS, compara sus resultados contra una serie de polticas, previamente establecidas y lanza una seal de alerta.

Importancia
Los

correlacionadores de eventos, entre otros dispositivos, permiten a los administradores de red y a los encargados del monitoreo de la actividad de trfico, tener un panorama general y con esto, poder determinar el un espacio temporal el estado de su infraestructura en relacin con la posible actividad maliciosa o viral dentro de ella.

Importancia
Por

tal, para proporcionar al correlacionador reglas adecuadas que prevengan un desastre, es importante que el administrador de red tenga bien claro cules son los activos importantes de su infraestructura y que conozca perfectamente cuales son los servicios que son susceptibles de ataques.

Qu correlacionador elegir?
Splunk

(Libre y Comercial) Check Point Threat Prevention Appliance AlienVault (comercial) Ossim (Libre) CSMA&RS (Cisco Security Monitoring, Analysis and Response System) Implementacin personal.

AlienVault
Para

fines de esta clase, usaremos Ossim, versin libre de Alienvault.

Qu se debe monitorear?

Disponibilidad de plataformas y servicios. (Servicios importantes para la institucin o empresa: Servidores WEB, Bases de Datos, etc.) La integridad de informacin en plataformas y servicios. Proteccin intrusiones. perimetral ante atacantes e

Correlacin

Acciones que se deben llevar a cabo

Gestin de sistemas de proteccin de datos ( Antivirus entre otros). Gestin de vulnerabilidades de plataformas (Pruebas peridicas). Gestin de eventos e incidentes de seguridad. Gestin de dispositivos y plataformas de seguridad y comunicaciones.

 Dependiendo

de la fiabilidad de las alarmas que produzca nuestro correlacionador, depender el tiempo de respuesta y de sta, el impacto que un ataque tenga dentro de la institucin o empresa, el cul puede ser meditico y/o econmico.

Niveles de Correlacin
Para prevenir al mximo la generacin de falsos-positivos, Ossim establece que la correlacin se debe llevar a cabo en 4 niveles:

Niveles de Correlacin
Nivel de correlacin 1 Nivel de correlacin 2
1 evento de Autentificacin SSH fallida

Autentificacin SSH exitosa

10 eventos de Autentificacin SSH fallida

Nivel de correlacin 3
Nivel de correlacin 4

Autentificacin SSH exitosa

100 eventos de Autentificacin SSH fallida

Conexin persistente

Autentificacin SSH exitosa

1000 eventos de Autentificacin SSH fallida

Correlacin - nivel 1
Para habilitar el registro de un evento que se ajuste al primer nivel de correlacin, se debe activar la primera directiva en el servidor, definiendo una poltica de inteligencia: (Intelligence Correlation Directives). La primer regla de una directiva deber cumplir las siguientes condiciones:

Siempre ser un regla de detector, pues las reglas de monitor no pueden ser usadas en el primer nivel de una directiva. Slo esperar la ocurrencia singular de un evento. Siempre estar activa, es decir, que la condicin del primer nivel se cargar mientras el servidor est en ejecucin. En el servidor slo se generar un evento, pues la primer regla de directiva de nivel 1.

Correlacin - nivel 1
Para fines de esta muestra, la directiva que crearemos, los datos provendrn de eventos del SSH server, el cual reportar un intento de autentificacin fallida. Es importante que siempre consideremos todas las posibilidades que tiene un evento, de acuerdo a su naturaleza. Por ejemplo, las variantes de un ataque, en un ataque de fuerza bruta sobre SSH cubren los siguiente aspectos:

Password incorrecto Intento de conexin con usuario bloqueado Intento de conexin con Login de root no habilitado Intento de conexin con un nombre de usuario no permitido: Usuario ilegal Intento de conexin con un nombre de usuario inexistente inten

Correlacin - nivel 1

La regla siempre esperar un evento de un plugin nico, el cual se identifica con un ID, posteriormente con uno o varios eventos identificados por Subidentificadores (SID). En este caso, esperar un evento con el ID de plugin 4003 y los identificar de acuerdo al SID de Plugin, el cul corresponde al tipo de evento que se halla elegido.

Correlacin - nivel 1
Plugin ID 4003, con los eventos que le conforman SID, numerados del 1 al 10

plugin_id="4003"plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20"

Correlacin - nivel 1

Si revisamos nuestra regla con el editor XML del server, lucir de la siguiente forma:

<rule type="detector" name=Ataque a servidor SSH DST_IP" reliability="0" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20"/>
Ntese el uso de la variable: DST_IP.

Correlacin - nivel 1

Nuestra directiva lucir de la siguiente forma:

<directive id="500000" name=Ataque a servidor SSH DST_IP" priority="4"> <rule type="detector" name="SSH Login fallido" reliability="0" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20"/> </directive>

Correlacin - nivel 1
Formato XML para la regla:
rule type=" " name= " " reliability=" " occurrence=" " from=" " to=" " port_from=" " port_to=" " plugin_id=" " plugin_sid=" "/>

Formato XML para la Directiva:

<directive id=" " name=" " priority=" "> <rule type=" " name=" " reliability=" " occurrence=" " from=" " to=" " port_from=" " port_to=" " plugin_id=" " plugin_sid=" "/> </directive>

Correlacin - nivel 2
Despus de recibir uno de los eventos de error en la autentificacin del servidor SSH, el correlacionador evala el paso al segundo nivel de correlacin, de acuerdo a las siguientes posibilidades:
Un

autentificacin exitosa. Una o varias autenficaciones fallidas (con el mismo origen y destino)

Correlacin - nivel 2

En caso de obtener un evento de autentificacin de usuario exitosa, la correlacin de esta directiva terminar. Si despus de ste se obtuvieran ms eventos de autentificacin fallida, desde un mismo origen a un mismo destino, inmediatamente se disparara el tercer nivel. Si asumimos que un ataque de fuerza bruta genera una gran cantidad de eventos en un corto perodo de tiempo, entonces debemos establecer un tiempo pequeo de espera. La fiabilidad se establece a 1, pues no se puede considerar que un inicio de sesin exitoso, tras un evento fallido, se deba a un ataque de fuerza bruta.

Correlacin - nivel 2

La primer regla del segundo nivel de correlacin quedar de la siguiente forma:

<rule type="detector" name=Login SSH exitoso 1 fallido" reliability="1" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="20" port_to="ANY" plugin_id="4003" plugin_sid="7,8"/>

Correlacin - nivel 2
Esto

significa que una vez que un evento llegue al segundo nivel de correlacin, el servidor de alienvault esperar 20 segundos para recibir una autentificacin exitosa, con una direccin y un destino que coincidan con el evento de la regla del primer nivel.

Correlacin - nivel 2
Todas

las reglas en el mismo nivel de correlacin intentarn recopilar eventos al mismo tiempo, por lo que el servidor de AlienVault no tendr que esperar 15 segundos para iniciar la segunda regla, en el segundo nivel de correlacin. Tambin podemos tener reglas con diferentes valores time_out.

Correlacin - nivel 2

En nuestro caso vamos a esperar 40 segundos para recoger 10 eventos de autenticacin fallida, con la IP de origen y de destino que coincida con el primer nivel de correlacin. As que los primeros 15 segundos ambas normas podran coincidir con los eventos de entrada, pero despus, slo la segunda regla del segundo nivel de correlacin se mantendr a la espera de nuevos eventos entrantes.

Correlacin - nivel 2
En

este caso, los eventos que coincidan con esta regla, tambin deberan coincidir con la primera regla de correlacin de la Directiva. Por eso es que se utiliza el valor sticky="true", de esta manera se evita que los eventos de este nivel de correlacin inicien su propia directiva, en vez de ello, se siguen agrupando dentro de la misma directiva de correlacin.

Correlacin - nivel 2

Segunda regla del segundo nivel de correlacin:

<rule type="detector" name=Login SSH fallido 10 veces" reliability="2" occurrence="10" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="40" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20" sticky="true"/>

Correlacin - nivel 2

Si creamos las reglas con el editor XML, usaremos la etiqueta de las reglas para abrir cada nivel de correlacin (La primera se inici con la etiqueta de la Directiva):

<rules> <rule type="detector" name=login exitoso 1 fallido" reliability="1" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out=20" port_to="ANY" plugin_id="4003" plugin_sid="7,8"/> <rule type="detector" name=" Login SSH fallido 10 veces" reliability="2" occurrence="10" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out=60" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16, 19, 20" sticky="true"/> </rules>

Correlacin - nivel 2
Una

vez que una de las reglas coincide con eventos de entrada, la otra regla se descarta y la correlacin continuar, si es que existen otras reglas definidas despus de la regla que ha coincidido.

Correlacin - nivel 2

<directive id="500002" name="Ataque a servidor SSH DST_IP" priority="3"> <rule type="detector" name="SSH Login fallido" entity="ANY" from="ANY" to="ANY" port_from="ANY" port_to="ANY" reliability="0"occurrence=" 1" plugin_id="4003" plugin_sid="1,2,3,4,5,9,10,12,13,19,20" sensor="c30b6765-2567-11e3-b8f00800276679ab"> <rules> <rule type="detector" name="Login SSH exitoso 1 fallido" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="1" oc currence="1" time_out="20" plugin_id="4003" plugin_sid="8,7"/> <rule type="detector" name="Login SSH fallido 10 veces" entity="ANY" from="ANY" to="ANY" port_from="1:SRC_PORT"port_to="1:DST_PORT" reliability="2" occurrence="10" time_out="60" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20,19"st icky="true"/> </rules> </rule> </directive>

Correlacin - nivel 2

En este nivel de correlacin es posible que tengamos una alarma generada, ya que el evento generado en la segunda regla tendr la prioridad 3 y una fiabilidad igual a 2.

El Riesgo se calcula de acuerdo a la siguiente frmula:

RISK = (Valor del activo* 3 * 2) /25 Si el resultado es mayor a 1, el sistema lazar una alarma.

Correlacin - nivel 2
Un

evento se convierte en alarma cuando se obtiene un valor de riesgo mayor o igual que 1. De tal modo que con un activo con un valor igual o mayor que 4, obtendramos una alarma despus de 11 eventos de autentificacin fallidos.

Correlacin - nivel 2
Es importante no utilizar valores time_out muy altos en un segundo nivel de correlacin, cuando en el primer nivel de la directiva se han establecido condiciones simples: (plugin_sid = "ANY", from = "ANY", to = "ANY" ...) Esto causar que una gran cantidad de eventos lleguen al segundo nivel de correlacin y que con esto se aumente en gran medida el consumo de memoria del servidor de correlacin.

Correlacin - nivel 3
Es

importante tener en cuenta que, en caso de que obtengamos un evento de una autenticacin exitosa, esta se habr producido despus de varios intentos fallidos, por lo que ser una situacin que deber ser analizada. Para esto, tendrmos que aumentar la fiabilidad en la primer regla del tercer nivel, en caso se cumpla esta regla, para facilitar la generacin de una alarma.

Correlacin - nivel 3
Primera regla del tercer nivel: En caso de que esta regla de correlacin coincida se generar una alarma, cuando el valor de uno los activos involucrado sea al menos 2.

<rule type="detector" name=Login SSH exitoso 10 fallidos" reliability="4" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="10" port_to="ANY" plugin_id="4003" plugin_sid="7,8"/>

Correlacin - nivel 3
Segunda

regla del tercer nivel:

<rule type="detector" name=Login SSH fallido 100 veces" reliability="4" occurrence=100" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out=300" port_to="ANY" plugin_id="4003"plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20" sticky="true"/>

Correlacin - nivel 3

Hasta ste momento, nuestra directiva global, debe lucir de la siguiente forma, desde el editor XML:

<directive id="500002" name="Ataque a servidor SSH DST_IP" priority="3"> <rule type="detector" name="SSH Login fallido" entity="ANY" from="ANY" to="ANY" port_from="ANY" port_to="ANY" reliability="0"occurrence="1" plugin_id="4003" plugin_si d="1,2,3,4,5,9,10,12,13,19,20" sensor="c30b6765-2567-11e3-b8f0-0800276679ab"> <rules> <rule type="detector" name="Login SSH exitoso 1 fallido" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="1" occurrence="1" time_out="20" pl ugin_id="4003" plugin_sid="8,7"/> <rule type="detector" name="Login SSH fallido 10 veces" entity="ANY" from="ANY" to="ANY" port_from="1:SRC_PORT"port_to="1:DST_PORT" reliability="2" occurrence="10" time_out="60" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20,19"sticky="true"> <rules> <rule type="detector" name="Login SSH exitoso 10 fallidos" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="4" occurrence="1" time_out="10" p lugin_id="4003" plugin_sid="7,8" sensor="c30b6765-2567-11e3-b8f0-0800276679ab" sticky="true"/> <rule type="detector" name="Login SSH fallido 100 veces" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="4" occurrence="100" time_out="300" p lugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,11,12,13,14,15,16,20"sensor="c30b6765-2567-11e3-b8f0-0800276679ab" sticky="true"/> </rules> </rule> </rules> </rule> </directive>

Correlacin - nivel 4
En

el cuarto nivel de correlacin, tambin mantendremos abierta la posibilidad de continuar recibiendo logueos SSH con autentificaciones fallidas o de recibir un evento con xito. El valor de time_out tambin se incrementar, as como el valor de la fiabilidad.

Correlacin - nivel 4
Agregaremos

nivel 4.

las dos siguientes reglas al

<rule type="detector" name="SSH Successful Authentication (After 1 failed)" reliability="6" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="150" port_to="ANY" plugin_id="4003" plugin_sid="7,8"/> <rule type="detector" name="SSH Authentication failure (1000 times)" reliability="7" occurrence="10" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="4000" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20" sticky="true"/>

Correlacin - nivel 4

Este nivel tambin incluye una regla de tipo monitor, que se utiliza para comprobar si hay una conexin establecida entre los dos anfitriones (atacante y atacado). En este caso vamos a utilizar el plugin de monitor Ntop de sesiones (sesin monitor.cfg). Todos los plugins del monitor se encuentran en la carpeta siguiente, todos ellos incluyen el monitor en sus nombres:
/etc/ossim/agent/plugins/

Correlacin - nivel 4
Ntop

se halla con el _ plugin_id 2005, y es compatible con muchos tipos diferentes de solicitud, cada solicitud se identifica con un plugin_sid diferente. En este caso, vamos a comprobar la duracin de la sesin entre los dos equipos.

 La

regla quedar de la siguiente forma:

<rule type="monitor" name=Persistente" reliability="+4" from="1:SRC_IP" to="1:DST_IP" port_from="1:SRC_PORT" port_to="1:DST_PORT" plugin_id="2005" plugin_sid="248" condition="ge" value="10" interval="20" time_out="120" absolute="true"/>

<rule type="detector" name="SSH Successful Authentication (After 1 failed)" reliability="6" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="150" port_to="ANY" plugin_id="4003" plugin_sid="7,8"/> <rule type="detector" name="SSH Authentication failure (1000 times)" reliability="7" occurrence="10" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="4000" port_to="ANY" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20" sticky="true"/> <rule type="monitor" name="More than 10 secs persistence" reliability="+4" from="1:SRC_IP" to="1:DST_IP" port_from="1:SRC_PORT" port_to="1:DST_PORT" plugin_id="2005" plugin_sid="248" condition="ge" value="10" interval="20" time_out="120" absolute="true"/>

 Cada

directiva de correlacin puede incluir tantas reglas como sea necesario. Siempre es aconsejable incluir un ltimo nivel de capturar un gran nmero de eventos. Por lo tanto, si el ataque contina durante un largo perodo de tiempo, estos eventos entran en la misma Directiva y se agrupan dentro de la misma alarma.

<directive id="500002" name="Ataque a servidor SSH DST_IP" priority="3"> <rule type="detector" name="SSH Login fallido" entity="ANY" from="ANY" to="ANY" port_from="ANY" port_to="ANY" reliability="0"occurrence="1" plugin_id= "4003" plugin_sid="1,2,3,4,5,9,10,12,13,19,20" sensor="c30b6765-2567-11e3-b8f0-0800276679ab"> <rules> <rule type="detector" name="Login SSH exitoso 1 fallido" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="1" occurrence="1" time_out="20" plugin_id="4003" plugin_sid="8,7"/> <rule type="detector" name="Login SSH fallido 10 veces" entity="ANY" from="ANY" to="ANY" port_from="1:SRC_PORT"port_to="1:DST_PORT" reliability="2" occurrence="1 0" time_out="60" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,12,13,14,15,16,20,19"sticky="true"> <rules> <rule type="detector" name="Login SSH exitoso 10 fallidos" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="4" occurrence="1" time_out="10" plugin_id="4003" plugin_sid="7,8" sensor="c30b6765-2567-11e3-b8f0-0800276679ab" sticky="true"/> <rule type="detector" name="Login SSH fallido 100 veces" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_from="ANY"port_to="ANY" reliability="4" occurrence="100" time_out="300" plugin_id="4003" plugin_sid="1,2,3,4,5,6,9,10,11,12,13,14,15,16,20"sensor="c30b6765-2567-11e3b8f0-0800276679ab" sticky="true"> <rules> <rule type="detector" name="Login SSH exitoso 111 fallidos" entity="ANY" from="1:SRC_IP" to="1:DST_IP"port_from="ANY" port_to="ANY" reliability="6" occurrence="1" time_out="180" plugin_id="4003" plugin_sid="7,8" sensor="c30b6765-2567-11e3-b8f0-0800276679ab" sticky="true"/> <rule type="detector" name="Login SSH fallido 1000 veces" entity="ANY" from="1:SRC_IP" to="1:DST_IP"port_from="ANY" port_to="ANY" reliability="7" occurrence="1000" time_out="3600" plugin_id="4003"plugin_sid="1,2,3,4,5,6,9,10,11,12,13,14,15,16,19,20" sensor="c30b6765-256711e3-b8f0-0800276679ab" sticky="true"/> <rule type="monitor" name="Persistente" entity="ANY" from="1:SRC_IP" to="1:DST_IP" port_fro m="ANY" port_to="ANY"reliability="+4" time_out="180" plugin_id="2005" plugin_sid="248" absolute="true" interval= "20" sensor="c30b6765-2567-11e3-b8f0-0800276679ab" sticky="true"/> </rules> </rule> </rules> </rule> </rules> </rule> </directive>