viernes, 16 de mayo de 2014

3.-OSSIM. Políticas y acciones personalizadas. ¿Qué hago como mis logs?

Tercer artículo de la serie sobre OSSIM nuestro framework para realizar nuestras tareas SIEM.
Parte 1234567 , 89 10

Cuando hablamos de la gestión de la información nos referimos no solo a la detección y almacenamiento, sino a todas las posibles acciones que debemos llevar a cabo ante esas situaciones.

Vivimos en un mundo conectado a la red las 24 horas del día, y la pregunta no es ¿Tendré algún incidente de seguridad? sino ¿Cuando tendré algún incidente de seguridad?. Podríamos debatir largo y tendido sobre este concepto, sobre todo con directores financieros pero asumimos que estamos en esa corriente, en la de ser todo lo proactivos que podamos.


Vamos a poner un ejemplo sencillo. Has seguido la serie de artículos uno y dos, has montado tu sistema y recibes al día 1200 logs, o 12000. Aún no has conectado tus sistemas de producción, salvo el ejemplo que hicimos de instalar OSSEC en un servidor Windows. Solo con los propios logs de OSSIM del demonio ssh ya tenemos entretenimiento para rato. Podemos desactivar la monitorización del demonio ssh o podemos desactivar toda la monitorización del demonio en ese servidor, salgo los intentos de login con una clave incorrecta. Viendo el proceso descubriréis lo fácil e intuitivo que es.


Podemos trabajar con una política por defecto para todo el sistema, o para un política concreta para un servidor. En esta prueba realizaremos la política por defecto.


Podemos movernos por las distintas opciones pinchando en los bloques de color o en los menús laterales.
Configuramos las opciones relativas al origen, destino, puertos.



Ahora configuramos los eventos. Podemos seleccionar eventos por su taxonomía, por la categorización que tienen, o bien por fuentes de datos o DS (data sources). Vamos a crearnos una fuente de datos específica para el componente SSHD.





 Podríamos configurar de golpe todos los eventos generados por el sensor SSHD y creando una segunda política para incluir solo el evento de SSH password failure como notificación. Usamos la ordenación de políticas, como hacemos con los firewalls, para procesar primero la regla de "aceptar", en nuestro caso, la segunda regla.


O podemos hacerlo al revés. Seleccionando evento por evento dentro del sensor SSHD y dejando sin marcar el que queremos que SI notifique.




Dentro de las opciones relativas a las consecuencias nos vamos a centrar en la parte de SIEM. Solo queremos limpiar eventos innecesarios pero que pueden aportar valor.

En el próximo artículo haremos varias pruebas de acciones. La parte de Logger y fordwarding no está operativa en la versión OSSIM que estamos usando ( Alienvault=pago). Logger básicamente lo que hace es guardar los logs que recibimos de nuestras fuentes en formato RAW. OSSIM almacena las alertas generadas durante el tiempo que indiquemos, pero no conserva el log completo. Si hay campos que no se parsean por OSSIM se pierden. Por supuesto al alcanzar el ciclo de retención también se pierden. Podría ser necesario almacenar el log en raw para temas forenses, judiciales, etc. Fordwarding básicamente hace lo mismo con las alertas hacia otro servidor syslog.

Por defecto se retienen los eventos durante 5 días. Podemos configurarlo..



Para este ejemplo de "limpiar" los eventos SSH del propio servidor salvo las contraseñas incorrectas simplemente activaremos NO en Sql Storage. .

Set Event Priority:
Risk Assessment.
Logical Correlation.
Cross Correlation.
Sql Storage.

**Introducción.En próximos capítulos ampliaremos estos conceptos**

Risk Assessment. Establece niveles de alerta para eventos.

Cross Correlation. Referencias que se hacen entre eventos que contienen una ip de destino común. Por ejemplo, podríamos no almacenar un evento de fallo de inicio de sesión pero usar Cross Correlation. Varios intentos de inicio de sesión nos proporcionarían una correlación que llamamos "ataque de fuerza bruta" igual que las alertas de Snort y similares. Por supuesto podemos crear nuestras propias correlaciones...

Logical Correlation: Referencias entre eventos que no tienen por qué tener como denominador común la ip de destino. Pongamos un ejemplo, tenemos una regla que no alerta de los login correctos en un ssh. Tenemos una regla para los ataques de fuerza bruta, con 3 intentos en n tiempo. Imaginar que un atacante intenta una password, no la encuentra, intenta otra password y acierta. No tendríamos ningún evento de la intrusión. Podríamos haber creado esa referencia o directiva.

***

Ya tenemos configurada la gestión de los eventos del demonio ssh para que no nos inunde de información, pero conseguimos toda la potencia que nos ofrece un sistema de correlación de logs como OSSIM.

Espero que os haya gustado el artículo. En próximos capítulos ampliaremos mas información.

Gracias por leerme.



2 comentarios:

  1. Buenas,

    Me encuentro en la misma situación que planteas. He puesto en marcha OSSIM (la versión no de pago) y recibo una gran cantidad de alertas del tipo:
    "SSHd: Did not receive identification string"
    "SSHd: Login sucessful, Accepted publickey"

    La idea es solo recibir alertas de tipo: "SShd: Failed password"

    He seguido los pasos expuestos pero sigo recibiendo las mismas alertas.

    Te comento lo que he hecho por si puedes ver qué estoy haciendo mal:

    1- Voy a Data Source \ Data Source Groups \ Add New Groups. Le doy un nombre y descripción y busco por tipo de evento con la palabra "password" y en el segundo filtrado con "ssh". Marco el "4003 sshd 1 SSHd:Failed password", agregar y actualizar. Ya me aparece en "Data Source Groups".

    2- Voy a Policy \ Default Policy Group \ New. De origen pongo el servidor Ossim y destino ANY. Puertos origen y destino ANY. En tipos de eventos desmarco ANY y marco el creado el en paso 1. En "policy consequences" marco SQL Storege "No". Actualizo política.

    3- Recargo la política y espero a ver las siguientes alarmas que me llegan.

    En resumen estoy intentando que me aparezcan solo los mensajes de "Fail password" creando una única política.

    Te agradezco mucho tu ayuda.

    Un saludo.

    ResponderEliminar
  2. Hola Kino, si quiero detectar ataques hechos desde kali con meterpreter dentro de la red?. Los activos que ataco tienen agentes ossec y aun así el alien vault no me genera alarmas por el ataque, ni por nmap, ni por ataques de fuerza bruta. Gracias de antemano Kino

    ResponderEliminar

Gracias por comentar !!

Related Posts Plugin for WordPress, Blogger...