Incident Response, Security and Forensics"

.

viernes, 23 de enero de 2009

LOG=EVIDENCIA+TRAZABILIDAD

En muchas ocasiones las empresas cuando tienen un incidente quieren saber en menos de un minuto respuestas a las siguientes preguntas ¿cuando ocurrió?, ¿quien lo hizo?, ¿por que lo hizo?.

Muchas de ellas no tienen respuesta ni la tendran por no disponer de una buena calidad en los registros de auditoría (y os aseguro que en estos casos la tensión se puede medir con un voltímetro.).

No voy a definir lo que es un log, pero personalmente para mi es una formula que se compone de EVIDENCIA + TRAZABILIDAD.

Evidencia porque representa un hecho o acción que es registrada. Trazabilidad por que permite realizar un seguimiento en el tiempo de las acciones, si a ello le añadimos 'el filtro' de sentido común podremos avanzar de forma significativa en una investigación.

Por lo tanto debemos de pensar que ante un incidente se precisan de 'pruebas' y estas son ni más ni menos que los registros del sistema y/o aplicaciones. Más cuando hay algún requerimiento judicial, ya que el Juez o el perito nos va a requerir de evidencias.

Personalmente me atrevo a dar una recomendación personal, antes de que pongamos herramientas para monitorizar o recolectar logs. No nos dejemos atraer por los 'cantos de sirena' de los productos comerciales o libres, o que nos quieran vender una herramienta con sistema operativo powerpoint (en la que todo funciona) os recomiendo el sentido común.

Sentido común el mejor filtro de un log.

Si compro la herramienta y luego me genera un evento que no se interpretar, ya puedo tirar la herramienta. Por muy buena que esta sea y por muy parametrizada que este siempre necesitará de interpretación y lógica humana. Con esto quiero decir que la persona que recibe la alerta debe de estar preparada para actuar ante el evento o desecharlo si este es un falso positivo.

Aquí, es donde esta el error, pretendemos explotar información a base de herramientas. Craso error. Primero hay que aprender e interpretar los logs de seguridad, observar y definir que eventos necesitamos (esto es lo que más tiempo lleva) y sobre todo discernir entre lo 'bueno' y lo 'malo'. Una vez aprendido es cuando podemos apoyarnos en herramientas para que nos ayuden.

Tipos de eventos a observar.

Distinguimos a dos clases. Aquellos eventos que son registros fijos que se almacenan en ficheros y que no tienen caducidad ninguna y aquellos que son volátiles.

Para aclarar quiero definir el concepto de volatilidad.

Volatilidad

Se define como volátil aquellas evidencias que se mantienen durante un tiempo y que pueden ser objeto de modificaciones o perdidas.

Por ejemplo, los registros del visor de eventos de Windows XP, Vista y 2003, posee un tamaño de 16 Mb de manera predeterminada. En el caso de haber muchas entradas de eventos al registro, estos se sobrescriben y la evidencia desaparece.

Lo mismo ocurre en dispositivos de comunicaciones como Switches y Routers, por lo tanto si se sobreescribe el log ya no tenemos respuestas a las preguntas formuladas al principio de este post.

Una vez sepamos interpretar o decidir ante un evento o alerta, como primer paso antes de comprar la herramienta, es asegurar que disponemos de una política de logs. Es decir analizar que máquinas y servicios deben disponer de logs y que eventos ha de filtrar o recoger (si es posible).

Como segundo paso, recomendaría que estuvieran centralizados (incluidos switches, routers, cortafuegos, antivirus, etc) de esta forma es más sencillo el poner reglas y herramientas que permitan explotar el contenido.

Como tercer paso y esto lo hablaremos en otro post, será mantener la integridad con firma digital.

No obstante como muchos ya habran dado el paso y estarán familiarizados con la interpretación de logs, quiero poner una pequeña lista de herramientas y a la que a buen seguro alguna me dejare.

logs centralizados

Snare - Multiplataforma y destaco que dispone de agentes para Notes, Exchange, apache, ISS, etc..
OSSEC - Recolector multiplataforma con multitud de agentes
syslog-ng - flexíble y escalable. Permite el almacenado seguro de logs centralizados en maquinas remotas (mejorado de syslog).
sdscsyslog - SDSC Syslog es un sustituto moderno y fiable de syslogd.
Lasso - Recolector centralizado de eventos de Windows con soporte para logs de aplicaciones de terceros.
Winlogd - Cliente syslog para Windows que permite al Log de Eventos hablar con syslog.

Análisis de logs y Correlación

logwatch - Sistema configurable para el análisis de logs.
logsurfer - Sistema diseñado para la monitorización de algunos ficheros de logs basados en texto en tiempo real.
logcheck - Simple utilidad diseñada para permitir a los administradores de sistemas, visualizar archivos de logs producidos en hosts bajo su control.
Logias - Consola para la detección de intrusiones en tiempo real para sistemas Windows NT/2K/XP.
LogMonitor - Herramienta basada en LogIDS que presenta la información de una manera más amigable
Logrep- Entorno de seguridad multiplataforma para la recolección, extracción y presentación de información de distintos ficheros de logs.
OSSIM - Herramienta que permite integrar y administrar en un mismo entorno distintas herramientas Open source. (cuadro de Mandos)
swatch - Herramienta para monitorización active de logs en sistemas Unix.

2 comentarios:

Todo el tema de análisis de logs y su posterior correlación es muy importante pero muy dificil. Una empresa a poco que tenga varios servidores y una red complejilla puede ser un caos, gestionar todos los eventos de forma centralizada, filtrar los eventos y correlarlos para ver su importancia y su criticidad.

La verdad es que es un trabajo muy duro de configurar pero una vez que ya está todo configurado ya es mas tranquilo. Es un trabajo que pocas empresas quieren hacer hasta que no ven que les pasa algún incidente :), como siempre pasa en este pais, que hasta que no ocurre 2 o 3 veces la gente no se conciencia del problema.

Todo el mundo habla de correlación cuando se refiere a gestión y centralización de logs. Es cierto que tenerlos juntos permite correlar pero yo no le he visto muchas ventajas a la correlación hasta ahora. El ejemplo clásico es correlar un scan en el IDS con una conexión en un servidor público pero el sistema que administro recibe logs de 50 dispositivos diferentes (BBDD, firewalls, IDS, antivirus, switches, controladores, mainframe,...) y la correlación no nos ha sido muy útil hasta ahora.
Sin embargo viene siendo más importante que los logs almacenados sean en raw para poder utilizarlos cómo prueba judicial en caso de necesidad. Un problema ya que muchos comprimen, recortan o transforman los eventos para optimizar el rendimiento.