Analisis de Logs

Definición

Un log es un registro de actividad del sistema, que generalmente se guarda en un archivo de texto, al que se le van añadiendo líneas a medida de que se realizan acciones sobre el sistema. Se utiliza en muchos casos distintos, para guardar información sobre la actividad del 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.

Cada sistema tiene su propio formato de log.

Windows: EVT o EVTX

Linux: log (formato de texto)

BBDD: trc (trace)

CISCO: log

Clases

Cuando hablamos de logs podemos diferenciar 3 tipos o clases

• LOG’S DE SISTEMA: Estos logs suelen ser eventos del sistema operativo, ya sea un servidor, computadora o dispositivo de red.
  Estos log’s (registros) del sistema son los mas utilizados para poder identificar o investigar actividad sospechosa que involucre a un equipo (HOST) en particular.
  Si queremos diferenciar los tipos de registros de sistema podemos encontrar.
  • Registro de eventos: Estos tipos de registros contienen acciones del sistema (sincronización de hora, inicio de servicio, etc.)
  • Registro de auditoria: (los mas importantes) Estos tipos de registros contiene las acciones realizadas por los usuarios del sistema (inicio de sesión, bloqueo de cuenta, cambio de políticas de seguridad, etc.)
• LOG’S DE APLICACIONES: Estos logs suelen ser eventos de aplicaciones de terceros en el sistema, correo, BB de DD, etc.
  Los log’s (registros) de aplicaciones contienen toda la información que una aplicación tiene guardada. Normalmente estos eventos están sujetos a la configuración del desarrollador.
  Dentro de estos eventos podemos encontrar información como:
  • consultas a servidores
  • informaciones de uso
  • acciones realizadas (ingresos a módulos de una aplicación, etc)
  • información de cuentas de usuarios registrados
• LOG’S DE SEGURIDAD: Estos logs son específicos de aplicaciones de seguridad como antivirus o cortafuegos, son útiles si queremos saber si un malware intento vulnerar el sistema.
  Los log’s (registros) de seguridad son muy específicos sobre aplicaciones instaladas dentro del sistema. Son útiles para el análisis de casos de infección por malware o ransomware.
  Estos registros pueden ser:
  • Eventos de antivirus
  • HIPS/HIDS
  • Webs proxys
  • Rourters (información de la red)
  • Fireware (información de la red)

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.

Como la mayoría de aplicaciones utilizan syslog lo analizaremos con más detenimiento en el próximo artículo, mientras que los programas que generan sus propios logs lo hacen de forma muy diferente por lo que no hablaremos mucho de ellos en futuros artículos.

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

Los 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

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

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 orígenes 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.