Análisis de los ficheros de logs

El site "Websecurity.es - Red social sobre seguridad informática" se agrego una nueva parte a la serie de post titulados "Análisis de los ficheros de logs", dichas publicaciones están vinculadas con el estudio del tema del registros de eventos de auditoría (características, recomendaciones, herramientas, etc.).

Un log es un registro de actividad de un sistema, y que se guarda en un fichero de texto sobre el cual podemos ver las acciones que se han realizado sobre nuestro sobre el sistema.

Los logs son útiles en muchos casos , como por ejemplo para los desarrolladores web que sin los logs estarían un poco ciegos con lo que sucede en sus máquinas, y de donde pueden analizar la información para saber el tráfico de su web.

Pero el caso que nos interesa a nosotros es el referente a descubrir posibles ataques a nuestros sistemas a través de los log, ya que nos permiten detectar información sobre posibles problemas o en casos de que se haya producido una incidencia de seguridad.

Uno de los sistemas de registro más simples pero potente es el de los sistemas Unix, los programas en la mayoría de los casos básicamente permiten dos opciones cuando van a generar un fichero de registro:

• Ficheros de registro generados por el proceso -> Algunos programas manejan sus propios registros, esto significa que estos ficheros de registro van a contener únicamente información procedente de esa fuente. Normalmente, los ficheros de registro se determinarán con algún argumento en la línea de comando o en algún fichero de configuración o en el propio código del programa.
  
  Uno de los ejemplos más conocidos es el de l servidor web Apache, que tiene un fichero de log con las Url servidas(llamado access_log), y otro fichero de log que contiene los errores(llamado error_log), donde aparecen los problemas que hayan podido presentarse, como páginas no existentes, respuestas CGI no váidas,etc
• 
  
• Mensajes Syslog -> Es la técnica más utilizada por los programas para registrar la información de lo que sucede en el sistema, es un programa cuyo única función es ofrecer un método común para que programas muy diferentes puedan registrar información.

Otro de los aspectos importantes de los ficheros de registro es revisarlos periódicamente para detectar posibles mensajes de advertencia.

Lo s mensajes de advertencia pueden desvelarnos intentos de conexiones fallidas u otros problemas que no tengan nada que ver con la seguridad, lo que hay que tener claro es que el único propósito de los ficheros de registro es la de ayudar a los administradores de sistemas, por lo que ignorarlos no es muy buena idea.

Pero todo el mundo sabe que leer estos ficheros todos los días es aburrido, puesto que habrá un montón de información en ellos que no tendrá ninguna importancia y que habrá que ignorar, el ello esta en que los administradores no suelen leer los ficheros de registro ellos mismo, sino que confían en herramientas que analicen los ficheros de log y que sólo les muestre la información significativa, principalmente existen dos métodos para ejecutar los programas de análisis de registro:

• Realizar comprobaciones periódicas, de modo la herramienta se ejecute a la hora que queramos mediante un cron. La ventaja de este método es que sólo se ejecuta una vez y durante un periodo corto de tiempo, con lo que no únicamente consumirá recursos en ese intervalo de tiempo. Y la desventaja es que tendremos que buscarnos alguna manera de que el programa sólo mire los registros a partir desde la última vez que hizo el análisis, ya que podríamos estar revisando continuamente los mismos ficheros.
• Realizar comprobaciones constantes mediante un demonio, algunos programas estarán leyendo continuamente los ficheros de log, examinando las entradas según se van añadiendo, aunque este método consume más recursos que el anterior, es la forma más rápida de tener noticias de los mensajes de advertencias.

Una de las cosas que nunca hay que hacer es ejecutar los programas de análisis como root, sino que es mejor crear un grupo que por ejemplo se llame log y que ejecutes chgrp sobre tus ficheros de log.
Las razones por las que un programa de análisis no debería ejecutarse como root, desde mi punto de vista son:

• Hay que ser muy selectivo a la hora de decidir que programas se ejecutan como root, y utilizar el usuario root como último recurso.
• Algunos de los programas que analizan registro pueden ejecutar programas externos, y no es muy recomendable ejecutar todos ellos como root.
• Podría existir alguna vulnerabilidad en el programa de análisis, con lo que no es muy recomendable que la cuenta de root se vea afectada, siempre es preferible que sea la cuenta de un usuario normal.

Un error muy común a la hora de analizar los log con los programas que analizan los registros, es que todos suelen quitar las líneas que no son muy relevantes, pero siempre es aconsejable que cada uno se haga sus propias reglas de filtrado, y decidir que líneas ignorar, que líneas tratar de forma especial y mostrare resto de líneas no tratadas, ya que puede que sean un nuevo tipo de ataque y lo pasemos por alto.

Syslog es un sistema de registros estándar que se utiliza en muchos programas de Linux, pudiendo registrar información basándose en el origen o en el nivel de severidad.

La función basada en el origen del mensaje es únicamente la de tener los programas clasificados en grupos a la hora de generar información de registro, mientras que los mensajes basados en nivel de severidad los programas generan cada entrada en el registro con un cierto nivel, y según la configuración que hayamos puesto en el fichero de configuración de syslogd el demonio puede aceptarla o rechazarla.

En general, lo que hace es enviar al dispositivo /dev/log las salidas de los programas, donde son recogidas por syslog y añadidas a un fichero de registro.
Dentro de los ficheros de registro podemos encontrar syslogd y syslog-ng, sobre el que hablaremos en el próximo artículo.

Syslogd es el demonio registrador instalado de forma predeterminada en los sistemas UNIX, y puede ser configurado mediante el fichero /etc/syslog.conf que nos permite especificar dónde enviar los mensajes dependiendo si la información está basada en el origen o en la severidad.

El fichero /etc/syslog.conf controla cada uno de los mensajes que se registran mediante syslogd, y el formato de cada línea de este fichero es el siguiente donde los campos están separados por tabulaciones:

origen.nivel_de_registro_ destino_registro

Por ejemplo, la siguiente línea sería un línea válida para el fichero de configuración, donde syslogd escribiría todos los registros que hayan hecho uso de la etiqueta daemon y que tengan el nivel de severidad notice o superior en el fichero /var/log/daemon.log. Pero lo mejor es consultar la página del manual de syslog.conf para ver todas las opciones que se pueden utilizar para personalizar nuestro fichero de registro.

Syslog aplica el siguiente formato a los mensajes que va recibiendo:

Mon Day Time hostname processname[pid]: log_record

De esta forma un fragmento del fichero de registro podría tener el siguiente aspecto:

Jul 21 00:00:12 websecurity named[1827]: Cleaned cacheo f 14 RRsets

Jul 21 00:10:12 websecurity named[1840]: Lame Server on 'www.websecurity.es'

Syslog-ng es un demonio de registro del sistema mejor que syslogd, sin embargo no viene instalado en la mayoría de los sistemas Linux.

El fichero de configuración de syslog-ng es syslog-ng.conf , y al igual que pasaba con syslogd es posible indicar múltiples destinos para nuestros fichero de registro del sistema, pero tiene la ventaja que se pueden definir los origenes de los mensajes y actuar de manera diferente si el mensaje proviene del sistema local o de uno remoto.

Por otro lado syslog-ng es más potente a la hora de filtrar los mensajes, ya que estos filtros pueden generarse utilizando expresiones regulares en vez de enviar por ejemplo todos los mensajes daemon a un único destino donde luego habrá que ordenarlos manualmente.

Otra de las cosas buenas que tiene syslog-ng es que puede enviar y recibir mensajes vía TCP, además de por UDP, lo que significa que es posible utilizar un sistema verdaderamente fiable de registro, puesto que TCP garantiza la llegada de los paquetes mientras que UDP no.

Sólo por esa razón syslog-ng puede ser más útil en entornos en los que tenemos que estar seguros de que no se pierden mensajes cuando se envían a un sistema de registro dedicado.

Cada una de las herramientas que veremos a lo largo de esta serie de artículos tiene sus propios funcionalidades, por lo que sería recomendable que probará cada una de ellas hasta encontrar la que más se adapte a sus necesidades.

La primera herramienta de la cual me gustaría hablar es logsentry, que forma parte de un conjunto de herramientas de Abacus, es una herramienta de análisis que se ejecuta periódicamente mediante el planificador cron.

Logsentry se basa en varios ficheros de configuración que poseen sencillas expresiones regulares simples egrep con las que analiza cada línea del fichero de registro y determina si debe o no informar de ella.

Los informes se envían mediante correo al root o al usuario que decidamos, además contiene una serie de patrones predefinidos construidos a partir de los registros de ataques del Internet Security Scanner(ISS), de mensajes Firewall Toolkit(FWTK), de envoltorios TCP, así como mensajes específicos de Linux, por la que la instalación por defecto de esta herramienta puede sernos muy útil.

Algunos de los ficheros destacados de LogSentry son:

• logcheck.hacking-> Cualquier mensaje que cumpla estas expresiones se envía por correo con una cabecera muy llamativa para que se vea inmediatamente.
• logcheck.violations-> Son las expresiones que denotan acciones inapropiadas, pero no tan serias como el anterior.
• logcheck.violations.ignore-> Son las expresiones que son realmente correctas y de las cuales podemos confiar
• logcheck.ignore-> Si una entrada no coincide con ninguna de las reglas definidas en los ficheros anteriores, se informará de ella a no ser que exista la expresión regular en este fichero.

LogSentry dispone de una utilidad llamada logtail que analiza automáticamente los registros leyendo únicamente las entradas nuevas, de forma que sabemos en todo momento las líneas que ya hemos analizado.

La primera herramienta de la cual me gustaría hablar es Logsurfer, que fue escrito por Wofgang Ley y Uwe Ellerman en DFN-CERT de Alemania, este programa se caracteriza por a posibilidad de establecer reglas dinámicas, además de permitir agrupar líneas del log por contexto, es decir, que permite agrupar todas las referentes por ejemplo a ssh.

Como hemos comentado, Logsurfer nos permite dividir los mensajes en contextos separados y decidir si el contexto en su totalidad es o no sospechoso.

Si por ejemplo, hemos detectado que alguien ha escrito en nuestro fichero ssh, y nos gustaría saber que usuario es el que lo ha conseguido, con la mayoría de los programas tendríamos que ir a nuestros ficheros de logs y buscar la línea con la escritura en el fichero de ssh y la línea referente a la conexión realizada, y de las cuales existen muchas líneas de este tipo siendo fácilmente ignoradas por los programas de análisis, mientras que con Logsurfer tendrías ambas líneas al poder decidir el contexto.

La configuración de Logsurfer es un poco compleja, se utilizan expresiones regulares estándar para determinar qué líneas son las importantes.

El formato de las líneas del fichero de configuración es el siguiente:

match-exp not-match-exp stop-exp not-stop-exp timeout action

Donde el significado de cada campo es el siguiente:

• match-exp -> Es la expresión regular que filtra las líneas que deben ser procesadas.
• not-match-exp -> Si se cumple el patrón anterior, pero el patrón not-match-exp también se cumple, entonces no se procesará la línea.
• stop-exp -> Elimina esta regla si la línea cumple este patrón.
• not-stop-exp -> Similar al campo not-match-exp, pero en este caso significa que se elimina la regla si se cumple el patrón stop-exp, a no ser que también se cumpla el patrón not-stop-exp.
• timeout -> Número de segundos que esta regla debe estar activa, un cero indicaría un tiempo de actividad infinito.
• action -> Acción que se realiza si se cumpla la regla.

Dentro de las posibles acciones que se pueden poner en el campo action son las siguientes:

• ignore -> Ignora esta regla.
• exec -> Ejecuta el programa especificado.
• pipe -> Ejecuta el programa especificado y envía la línea del registro por la entrada estándar.
• open -> Inicia un nuevo contexto.
• delete -> Elimina un contexto.
• report -> Abre un programa y envía todas las definiciones de contexto especificadas.
• rule -> Crea una regla dinámica.

Con lo que Logsurfer permite tener un control total sobre los registros de tu sistema, pero como veis la configuración es un poco más complicada, además tiene la desventaja que consume bastante memoria así como CPU, por lo que suele dejar esta herramienta para analizar registros muy específicos y se deja Logsentry o las herramientas que veremos en los siguientes artículos para analizar el grueso de los registros.

En esta ocasión vamos a hablar sobre dos herramientas Sec y Lire, la primera de ellas, SEC (Simple Event Correlator), es capaz de analizar un fichero, una canalización con nombre o la entrada estándar y mediante expresiones regulares reconocer eventos, de modo que cuando se produce una coincidencia con un patrón especificado puede ejecutar comandos del sistema.

Una de las ventajas de esta aplicación es que además de poder analizar ficheros de logs, también puede integrarse con cualquier servicio de red, buscando posibles signos de ataques y realizando la acción que se le indique en el momento apropiado.

Sec puede analizar ficheros en busca de una línea, de varias líneas o de pares de líneas (siempre y cuando sean una seguida de otra), además puede buscar un conjunto de líneas que se hayan generado en un determinado intervalo de tiempo, ignorando ciertas líneas de texto y realizar un acción a intervalos especificados.

La otra herramienta sobre la quería hablar es Lire, que es una herramienta de análisis de registro más sofisticada que Sec, y que nos permite monitorizar y crear informes a modo de resumen de diferentes tipos de ficheros de registro.

Una de las ventajas de usar Lire, es que no es necesario instalarlo, puesto que Lire nos permite enviar nuestro registros por Internet al motor de informes de Lire y recibir los resultados por correo.

A mi personalmente me gusta tenerlo instalado localmente, ya que es más seguro que enviar los registros a una entidad desconocida y sin cifrar a través de Internet, aunque es posible ocultar la identidad de los registros utilizando el programa lr_anonymmize que se incluye en la distribución, lo que se hace es utilizar este programa para ocultar la identidad de los registros, luego se mandan para ser analizados y una vez recibidos los resultados se vuelve a utilizar esta misma aplicación para hacer visibles los resultados, como veis un poco complejo por lo que es mejor tenerlo instalado en local.

Lire admite gran variedad de tipos de registro, entre los que destacan:

• Sendmail, Postfix, qmail, exim y nms.
• MySQL.
• Registros normales y combinado de Apache y Apache mod_gzip.
• Servidores Proxy Squid y WELF.
• Registros de impresión CUPS y LPRng.
• DNS Bind en sus versiones 8 y 9.
• FTP xferlog.
• Firewalls: Cisco, ipfilter, ipchains e iptables.

Lire convierte estos formatos en Distilled Log Format(DLF), que es el que luego se procesa para generar los informes, los cuales son bastante útiles tanto para detectar anomalías como para ayudarnos a optimizar nuestro sistema.

Estas son dos herramientas muy útiles que podemos usar para analizar nuestros ficheros de logs, aunque no son de mis favoritas, en el artículo de la semana que viene continuaremos viendo herramientas que nos sirvan para analizar nuestros fichero de logs, en concreto veremos el uso de Swatch una herramienta muy útil para analizar los ficheros de logs.

Fuente: http://www.websecurity.es/