Herramientas de usuario

Herramientas del sitio


Barra lateral

manuales:nagios:capacitacion:correlacion_de_eventos

Correlación de eventos

Si bien Nagios provee de monitoreo en vivo para saber el estado de nuestros servicios, a veces necesitamos un proceso para analizar los datos de eventos e identificar patrones, que nos ayudaran a entender causas comunes y causas iniciales, por medios de reglas para estados predefinidos.

Para poder determinar estos casos deberemos implementar una Bitácora centralizada de eventos del sistema (SYSLOG).

Sistema de loggueo centralizado

Se tiene la necesidad de un sistema que reciba y almacenes archivos de registros determinados de n* servidores. Que se disponga de una interfaz de acceso a esos datos, para la organizacion y procesamiento de los mismos, con lo cual se podran detectar eventos, resolver situaciones y emitir distintos tipos de alarmas.

Syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.

Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.

Es útil registrar, por ejemplo:

  • Un intento de acceso con contraseña equivocada
  • Un acceso correcto al sistema
  • Anomalías: variaciones en el funcionamiento normal del sistema
  • Alertas cuando ocurre alguna condición especial
  • Información sobre las actividades del sistema operativo
  • Errores del hardware o el software

También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele estar separado del resto de alertas.

El protocolo syslog es muy sencillo: existe un ordenador servidor ejecutando el servidor de syslog, conocido como syslogd (demonio de syslog). El cliente envía un pequeño mensaje de texto (de menos de 1024 bytes).

Los mensajes de syslog se suelen enviar vía UDP, por el puerto 514, en formato de texto plano. Algunas implementaciones del servidor, como syslog-ng, permiten usar TCP en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados mediante SSL/TLS.

Generalidades de un sistema de log.

Log es el registro de acciones y eventos que tienen lugar en un sistema.

Los logs son el primer registro de la actividad en los sistemas y redes.

Los logs de un sistema son una parte primaria de la seguridad y pueden ser usados en la detección de ataques e intrusiones, así como en el análisis de fallas de hardware y software.

El programa syslog, es una interface que provee un framework standard para que tanto programas como el mismo sistema operativo puedan generar mensajes que peuden ser almacenados localmente o ser enviados a un host remoto. Originalmente escrito para Unix, se convirtió en un standard que se usa en muchos sistemas operativos y dispositivos de red.

¿ Cual es la utilidad de un sistema de syslog centralizado ?

En un sistema de syslog centralizado, un server común recibe todos los mensajes de syslog de todos los sistemas de la red. Esto incluye logs de los servers Unix/linux/Windows etc, firewalls, y dispositivos de red (routers, switches, etc)

Hay varias ventajas de un sistema de syslog centralizado

  • El syslog puede ser conectado en un segmento de red diferente protegido por un firewall

para mantener más segura la información

  • Teniendo los mensajes de todos los equipos, puede hacerse una correlación de ataques o

fallas en distintos puntos de una manera mucho más sencilla. Por ejemplo si en el syslog aparece un mensaje de desconexión de la interface de red de varios servers en el mismo momento, es lógico suponer una falla en el switch donde estos servers estan conectados.

  • Un usuario no deseado que haya ingresado en un server, no podrá alterar los mensajes que

se hayan almacenado en el server central.

  • Se pueden generar alertas usando sistemas de monitoreo de logs.
Sistema de monitoreo de logs

El análisis de logs es una herramienta muy importante para mantener el control de servers y dispositivos de red.

Sin embargo esta es una de las tareas que más tiempo consume y por consiguiente que menos se hace.

Con la cantidad de mensajes informativos que se generan en un sistema de log, detectar en forma manual los mensajes de problemas es muy dificultoso y con mucha probabilidad de error. Esto se vé aumentado cuando se usa un sistema de syslog centralizado, donde la información proviene de varias fuentes distintas. Muchas soluciones de monitoreo se basan en sumarizar la información de archivos de log de dias previos.

Esto es muy útil para la generación de estadísticas y análisis posterior a una falla o intrusión, pero no tanto para la resolución de problemas.

Un administrador no puede actuar en forma proactiva, previamente a que el error ocurra.

Muchas fallas o accesos no autorizados se ven precedidos por mensajes que de haber sido detectados, podrían haber permitido tomar acciones preventivas.

Por ejemplo, un acceso no autorizado via ssh, puede haber estado precedido por una gran cantidad de intentos fallidos de acceso.

Disponer una solución online de monitoreo, permite disponer de herramientas que pueden ayudar a prevenir problemas graves antes que ocurran.

Detectar eventos en el momento que ocurren permite generar acciones en ese mismo instante y no luego de las consecuencias.

Siguiendo con el ejemplo del acceso ssh, podría bloquearse el acceso ssh desde determinada dirección IP despues de un número de intentos fallidos de acceso.

Un concepto que aparece aquí es el de correlación de eventos.

Un sistema automatizado de análisis de logs que pueda hacer una correlación de varios eventos simplifica y acelera el monitoreo de eventos consolidando alertas y mensajes de error en un mensaje más corto y fácil de entender.

Una serie de operaciones están relacionadas con la correlación de eventos.

Compresión toma varias apariciones del mismo evento y se examina la duplicación de información, se remueve las redundacias y se reporta como un único evento. De esta manera 1000 mensajes “route failed” se convierte en un único alerta que dice “route failed 1000 times” Recuento reporta un número específico de eventos similares como uno solo. Esto se diferencia de la compresión en que no solo cuenta en que sea el mismo evento, sino que se supere un determinado umbral para generar un reporte.

Supresión asocia prioridades con alarmas y permite que el sistema suprima un alarma de prioridad más baja si ha ocurrido un evento de prioridad mayor.

Generalización asocia alarmas con eventos de más alto nivel que son los que son reportados.

Esto puede ser útil para por ejemplo para correlacionar eventos de múltiples discos de un array.

No se necesita ver cada mensaje específico si se puede determinar que el array completo tiene problemas.

Correlación basada en tiempo puede ser útil estableciendo causalidad. A menudo una información puede ser obtenida relacionando eventos que tienen una relación temporal específica.

Ejemplos genéricos:

  • El Evento A está seguido del Evento B.
  • Este es el primer Evento A desde el Evento B reciente.
  • El Evento A sigue al Evento B dentro de los dos minutos.
  • El Evento A no fue observado dentro del Intervalo I.

Objetivos

Simplificar y optimizar la administración de diferentes servicios para conocer su estado minuto a minuto, y elaborar planes de acción. A su vez el sistema debe ser simple de utilizar por el administrador, y ser posible de ver via web los registros del sistema, realizar busquedas etc.

Es útil registrar, por ejemplo:

  • Un intento de acceso con contraseña equivocada
  • Un acceso correcto al sistema
  • Anomalías: variaciones en el funcionamiento normal del sistema
  • Alertas cuando ocurre alguna condición especial
  • Información sobre las actividades del sistema operativo
  • Errores del hardware o el software

También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele estar separado del resto de alertas.

Puede logguear tanto por UDP como por TCP, teniendo compatibilidad con el viejo syslog, soportando a su vez muchas mas opciones y tareas que el syslog comun.

Sobre Syslog-NG

Syslog-NG es un sistema para el envío de mensajes de registro en una red.

Es útil registrar, por ejemplo:

  • Un intento de acceso con contraseña equivocada
  • Un acceso correcto al sistema
  • Anomalías: variaciones en el funcionamiento normal del sistema
  • Alertas cuando ocurre alguna condición especial
  • Información sobre las actividades del sistema operativo
  • Errores del hardware o el software

También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele estar separado del resto de alertas.

Puede logguear tanto por UDP como por TCP, teniendo compatibilidad con el viejo syslog, soportando a su vez muchas mas opciones y tareas que el syslog comun.

Explicacion tecnica simple

Syslog-NG se compone en capas de funcionamiento

Osea tengo en primer lugar opciopnes generales, luego fuentes de donde obtener datos de los registros, ya sean locales, externos por red (udp, tcp, archivos de texto), y luego tenemos destinos y filtros configurados, uniendolos forman los registros de sistema

Tareas

Se instalo el software syslog-ng dentro de un servidor Debian.

apt-get install syslog-ng

En la instalacion como resultante se tiene el siguiente archivo de configuracion principal

/etc/syslog-ng/syslog-ng.conf

Clientes

En los clientes se procedió a configurar el syslog convencional para que loggueara por UDP hacia el servidor syslog.

syslog-ng.conf

syslog-ng.conf
destination syslog_server {
    tcp( "10.1.1.2" port(514) );
};
 
filter      f_local6       { facility(local6); };
 
filter f_auth {
    facility(auth, authpriv);
};
log { 
    source(src);
    filter(f_auth);
    destination(syslog_server);
};
 
log { 
    source(src);
    filter(f_local6);
    destination(syslog_server);
};

syslog.conf

syslog.conf
auth.*;authpriv.*;auth.notice;auth.error;auth.info;authpriv.none;     @10.1.1.2
local6.*                @10.1.1.2

/etc/profile.local

Esto es para logguear todos los comandos que ejecutan los usuarios, funciona aunque ejecuten un sudo o un su sin perder el rastro del usuario original, siempre y cuando no modifiquen la variable de entorno.

export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RETRN_VAL]"'

Configuración del Servidor

Debian GNU/Linux Etch

Archivo /etc/syslog-ng/syslog-ng.conf

Opciones generales, fuentes de donde obtener información, filtros y destinos paracada filtro

options {
      long_hostnames(off);
      # doesn't actually help on Solaris, log(3) truncates at 1024 chars
      log_msg_size(8192);
      # buffer just a little for performance
      # sync(1); <- Deprecated - use flush_lines() instead
      flush_lines(1);
      # memory is cheap, buffer messages unable to write (like to loghost)
      log_fifo_size(16384);
      # Hosts we don't want syslog from
      #bad_hostname("^(ctld.|cmd|tmd|last)$");
      # The time to wait before a dead connection is reestablished (seconds)
      time_reopen(10);
      #Use DNS so that our good names are used, not hostnames
      use_dns(no);
      dns_cache(yes);
      #Use the whole DNS name
      use_fqdn(no);
      keep_hostname(no);
      chain_hostnames(no);
      #Read permission for everyone
      perm(0644);
      # The default action of syslog-ng 1.6.0 is to log a STATS line
      # to the file every 10 minutes.  That's pretty ugly after a while.
      # Change it to every 12 hours so you get a nice daily update of
      # # how many messages syslog-ng missed (0).
      stats(43200000);
};

# Log Interno
source interno {
        # message generated by Syslog-NG
        internal();
        # standard Linux log source (this is the default place for the syslog()
        # function to send logs to)
        unix-stream("/dev/log");
        # messages from the kernel
        file("/proc/kmsg" log_prefix("kernel: "));
};

# Create destination to LogZilla
destination d_logzilla {
   program("/usr/local/nagios/syslog/scripts/db_insert.pl"
   template("$HOST\t$FACILITY\t$PRIORITY\t$LEVEL\t$TAG\t$YEAR-$MONTH-$DAY\t$HOUR:$MIN:$SEC\t$PROGRAM\t$MSG\n")
   );
};
source externo {
        # use the following line if you want to receive remote UDP logging messages
        # (this is equivalent to the "-r" syslogd flag)
        # Ampliamos el limite de conexiones para recibir gran cantidad de datos de LOGS externos
        udp(ip(0.0.0.0) port(514));
        tcp(ip(0.0.0.0) port(514)  max-connections(150) );
};

# Tell syslog-ng to log to our new destination 
log {
    source(externo);
    destination(d_logzilla);
};

# Alertas de Nagios Eventdb

destination d_eventdb {
    pipe(
        "/usr/local/nagios/var/rw/syslog-ng.pipe",
        template("$HOST\t$SOURCEIP\t$PRI\t$YEAR-$MONTH-$DAY\t$HOUR:$MIN:$SEC\t$PROGRAM\t$MSG\n")
        template_escape(no)
    );
};

log {
    source(externo);
    destination(d_eventdb);
};

PHP-Syslog-ng

Para la visualizacion de los logs via web, busqueda y demas operaciones para su administracion se instalo, configuro y modifico a necesidad parte de codigo del sofware php-syslog-ng que provee de una interfaz web con soporte de busquedas y que servia para cubrir la necesidad planteada.

Una vez instalado se configuro el apache para su puesta en marcha de la siguiente manera (se omitieron las directivas de autenticacion).

Alias /syslog "/usr/local/php-syslog-ng/html"
<Directory "/usr/local/php-syslog-ng/html">
    Options All
    Order allow,deny
    Allow from all
    SSLRequireSSL
    AllowOverride None
</Directory>

Integración con Nagios

Eventdb

¿Que es Eventdb?

EventDB es una herramienta para facilitar el tratamiento de los datos basados ​​en eventos de Syslog para herramientas de monitoreo como Nagios o Icinga y su integración con los mismos se logra a través de un plug-in de chequeo. Cuenta con varios plugins para diferentes fuentes de datos. La interfaz web permite a los usuarios buscar, filtrar y reconocer todos los eventos.

¿Cómo funciona?

El EventDB toma los eventos recibidos y los almacena en una base de datos MySQL. Se tomando los datos de syslog-ng desde un pequeño demonio perl (syslog-ng2mysql.pl). syslog-ng2mysql.pl abre una unix-pipe por un lado desde donde recibe los mensajes de syslog-ng, y utiliza DBI en el otro para escribir datos en MySQL.

manuales/nagios/capacitacion/correlacion_de_eventos.txt · Última modificación: 2015/10/22 14:40 por cayu

Herramientas de la página