All you need is Log !! Capítulo 1.

En el capítulo de hoy voy a comenzar una mini seria sobre el mundo de los logs.
Después de escribir varios artículos sobre OSSIM y tocando de cerca muchos conceptos de la gestión de eventos de seguridad de la información o SIEM, creo que debo empezar a comentar la base sobre la que se sostiene, los logs de información.

Todos los manejamos a diario, o deberíamos, pero leyendo muchos artículos, manuales y sobre todo, hablando con los compañeros, percibo un cierto desconocimiento de todo el poder que nos brindan, y que en pocas ocasiones veo en clientes buenos despliegues.

Quizás la primera tarea que debemos cumplir al iniciarnos en un proyecto de gestión de logs es la definición del propósito.

Debemos establecer el tiempo en el que mantendremos nuestros logs en cada sistema, según sea su propósito.

Pongamos el ejemplo de una infraestructura en la que contamos con un servidor web Apache, que escribe sus logs localmente en un fichero. Si estamos usando un servidor centralizado de logs debemos enviar los eventos a dicho servidor, pero debemos borrar los registros locales en el servidor Apache, ya que esa información ya se ha transmitido y nos genera espacio, y riesgo de fugas de información en caso de verse comprometido. Este post de Security By default nos da unas buenas pistas de como solucionarlo.

Si estamos usando un servidor para SIEM como OSSIM o Splunk, para gestionar eventos de seguridad, debemos de tener en cuenta que son sistemas para monitorizar la seguridad en tiempo real. Podemos hacer uso de las opciones de búsqueda para realizar un análisis forense de un suceso a investigar, pero no son herramientas diseñadas para ello, y puede que necesitemos cierta agilidad que no nos proporcionan estas herramientas. 

Para solucionar esta situación podemos instalar un segundo servidor de logs denominada Retención, en el que a priori, no realizaremos ninguna gestión diaria, pero la información estará disponible para futuras investigaciones.

Un ejemplo práctico y simple de entender. Puede que en nuestra consola de seguridad OSSIM descartemos los eventos de login correcto de los sistemas Windows, ya que solo genera "ruido" y puede que no solo no aporte información, sino que enmascare información real. PERO puede que esa información sin sea necesaria para investigar un Data Leak en un futuro.

Esta reflexión puede ser trivial, pero es importante realizar este esquema de funcionamiento y retención de logs entre los sistemas. Un fichero de log en un escenario de brute force, de DDOS, debug de algún sistema, o cualquier anomalía, puede crecer exponecialmente, sobrepasando nuestra "tranquilidad" de un fichero de unos cuantos MB a llenar el disco. Creerme, la solución no es comprar más discos.

Otra consideración a la hora de hacer este esquema es el de "inventariar" nuestras fuentes de logs, incluyendo en nuestra estructura centralizada todos los registros de sistemas que queremos monitorizar en tiempo real, o archivar. Seguro que haciendo esta auto-reflexión descubres servicios que llevabas MUCHO tiempo sin revisar sus logs.

En muchas escuelas, en distintas asignaturas se emplea la conexión: Dato, Información, Conocimiento. Que para nuestra aproximación nos viene genial

En la primera fase de nuestro despliegue de gestión de logs vamos a trabajar, a ser posible, a nivel DATO. Vamos a poner un ejemplo con Snort.

Si tenemos un paquete con el único flag FPU marcado Snort bien configurado seguramente nos tirará una alerta del tipo Nmap Xmas Scan.

El dato sería el stream tcp con la cabecera, el payload, TODO.

La información sería que estamos sufriendo un Xmas Scan.

El conocimiento podría ser si cruzamos la información de la ip de origen con una base de datos de reputación, en la que el conocimiento sea "Posible ataque desde esta IP maliciosa".

Si ponemos el ejemplo de un servicio web, el dato seria el registro concreto de la petición http, cookie, user-agent, etc.

La información podría ser una alerta de posible Sql Inyection.

El conocimiento podría ser si se detecta que la misma fuente está probando varias secuencias de comandos, o solo ha sido una botnet intentando explotar un fallo concreto.

No esperes llegar al conocimiento sin pasar por una buena gestión de información y por supuesto dato.

Podemos empezar a clasificar los logs según su categoría:

• INFO.
• DEBUG.
• WARNING.
• ERROR.
• ALERT.

Esta clasificación suele ser estandard. Para el caso que vamos a estudiar en detalle, el formato SYSLOG, podemos encontrar con que la categoría se denomina Security Level y es tal que así, vía WIKIPEDIA( o mejor el RFC):

Podemos clasificar los logs según su manera de transmitir:

• SYSLOG. Suele ser el formato nátivo de los sistemas Linux y puede transportarse mediante TCP y UDP. En formato texto sin cifrar.
• WINDOWS EVENT: El formato nativo de los sistemas Microsoft, es un formato binario, por lo que necesitaremos una herramienta para visualizarlos.
• SNMP: Algunos sistemas emplean este protocolo para el envio de tramas hacia un servidor central, las cuales c.ontienen la información de log.
• DATABASE: Sistemas que escriben su información de logs directamente en una base de datos.
• PROPIOS FABRICANTE.

De momento esto es todo por hoy sobre el mundo de los logs.

En próximas ediciones analizaremos en detalle más sistemas de logs y alguna herramienta para su gestión, aparte de OSSIM :-).

Espero que os guste, gracias por leerme.