FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de logs:
Una experiencia real
Daniel Sánchez Dorado
[email protected]
Facultad de Informática de Barcelona
Universidad Politéctica de Catalunya
Jornadas Técnicas Rediris 2006
16 Noviembre 2006
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Presentación
El Laboratorio de Cálculo de la Facultad de Informática de
Barcelona (LCFIB) dispone de unos 80 servidores y 60
equipos diversos (SAIs, access points, routers,
switches, impresoras, sensores, cámaras, …) los cuales
son capaces de generar logs sobre su estado.
En general, cada equipo es una fuente local de logs
Esos logs generalmente están basados en el sistema de
syslog de unix, en el sistema de eventos de Windows,
en traps SNMP o en ficheros locales
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Presentación II
Pero, … ¿quién mira esos logs?
El problema es que nadie controla estos logs
constantemente, lo cual nos lleva a que …
… los logs
nos dicen qué ha pasado …
… y nosotros queremos que
nos digan qué está pasando.
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Presentación III
El año pasado emprendimos un proyecto cuyo objetivo es
incorporar la información útil de los logs a nuestro
sistema de monitorización (Nagios) en tiempo real.
Existen gran cantidad de artículos explicando como se
consigue todo esto de manera sencilla.
Por ejemplo:
Sysadmin Diciembre 2004 • Vol 13 • Number 12
Centralized Logging for UNIX, Windows, and Network Devices • Corey Ramsden
Descubrimos que estos artículos obvian ciertos
“problemillas”
El objetivo de esta presentación es exponer todos los
problemas con que nos encontraremos para facilitar
esta tarea a futuros usuarios.
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Lista de tareas
Las tareas básicas son:

Recolección local


Envío a un servidor central


¿Qué envío?
Análisis


¿Qué recojo? ¿Cómo lo clasifico?
¿Qué busco?
Entrega de resultados

¿Cómo lo enseño?
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Syslog local
El sistema de syslog se encarga de recoger y almacenar en ficheros
los eventos en función de 2 parámetros: la facility y la severity
En el syslog.conf clasificamos y archivamos los logs en ficheros en
función de ellos
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Syslog local II

Cada aplicación envía los logs a una facility
determinada

La mayoría de distribuciones actuales agrupan los
logs por severity
#
# print most on tty10 and on the xconsole pipe
#
kern.warning;*.err;authpriv.none
/dev/tty10
kern.warning;*.err;authpriv.none
|/dev/xconsole
*.emerg
*
#
# Warnings in one file
#
*.=warning;*.=err
*.crit
-/var/log/warn
/var/log/warn
#
# Some foreign boot scripts require local7
#
local0,local1.*
-/var/log/localmessages
local2,local3.*
-/var/log/localmessages
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: syslog.conf
# Mensajes de kernel
kern.panic;kern.emerg;kern.alert;kern.crit;kern.err
kern.warning;kern.notice;kern.info
/syslog/kern_greu.log
/syslog/kern.log
# Logs de los ipfilters de los firewals Linux
kern.debug
/syslog/ip.log
user.debug
/syslog/user.log
mail.debug
/syslog/mail.log
daemon.debug
/syslog/daemon.log
syslog.debug
/syslog/syslog.log
lpr.emerg;lpr.alert;lpr.crit;lpr.notice /syslog/lpr.log
# Logs de los iptables de Solaris
local0.debug
/syslog/ip.log
local2.debug
/syslog/local2.log
# Logs de SAMBA
local4.warning
/syslog/samba.log
# Logs del tripwire
local5.debug
/syslog/tripwire.log
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Consideraciones

Hay aplicaciones que tienen la facility y severity dentro del código.
Otras en cambio, se pueden configurar

No siempre disponemos del código fuente, o no es posible
cambiarlo: por ejemplo software propietario.

A veces el mismo software ¡ ocupa distintas facility en distintos
servidores !

Hay que hacer una revisión de todas las aplicaciones de todos los
sistemas y hacer una tabla para agrupar los logs por categorías de
facilitys comunes
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs:
Tabla de facilitys centralizada

Al final, hemos de llegar a una tabla como esta:
Facility
kern
kern.debug
Uso
Mensajes del kernel, reservado
El ipfilter de linux va forzosamente a kern.*. Elegimos ponerlo en debug -> lo redirecionaremos al ip.log
user
mail
daemon
Mensajes de usuario, user.notice usado para mensajes de conexion de usuarios de FIBNETLESS
Mail
Daemons varios: dns, dhcp, …
incluye script de actualizacion de fichero de firmas en ricino
ssh
mensajes del syslog
Impresoras
Logs de windows -> Windows Security
Logs de windows -> Windows System
auth
syslog
lpr
news
uucp
cron
authpriv
ftp
ntp
log audit
log alert
clock daemon
local0
local1
local2
local3
local4
local5
local6
local7
Amavis de ricino
LOGS de firewalls (Linux ipfilter & Solaris iptables)
El ipfilter de Solaris va forzosamente al local0 --> OK -> lo redirecionaremos al ip.log
usos locales
usos locales
LDAP
samba
Tripwire
Redes - mensajes
Para todo en general
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Windows

Usaremos el NTSyslog para integrar los “sucesos de sistema” de
Windows (http://ntsyslog.sourceforge.net/)

Las categorías de sucesos de Windows parecen las de syslog,
pero en la práctica son completamente distintas



facility: Aplicación, Seguridad, Sistema, (hay otras)
severity: Error, Advertencia, Información, Auditoría de aciertos, Auditoría de
errores
¿Qué monitorizamos?
Procedimiento:

Obtenemos la lista completa de sucesos del sistema
• Knowledge Base artículos 299475 y 301677
(Descripciones de los sucesos de seguridad de Windows 2000)


Elegimos los mensajes que consideremos importantes
Escogemos las categorías que engloban todos estos mensajes
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralizacion de Logs: política de Windows
Seguridad
Sistema
Aplicación
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs:otros

Los IOS de Cisco incorporan un cliente syslog, sólo hay que
configurarlo:
switch1#conf t
switch1(config)#
switch1(config)# logging facility local6
switch1(config)# logging 192.168.1.2
switch1(config)# logging trap 4

Las impresoras HP y las tarjetas de gestión de los SAIs modernos
incorporan también un cliente syslog

Aplicaciones específicas que dejan mensajes en ficheros concretos
pueden ser pasadas a syslog mediante un script o usando el
syslog-ng:
tail –f <log> | logger –p user.notice

Para el resto de dispositivos se puede habilitar un gestor de traps
SNMP
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: ¿qué envio?

Una vez hemos agrupado los logs por facility y los hemos
sincronizado en todos los servidores, simplemente hemos de
indicar al syslog que envíe los logs remotos, … pero
¿Qué enviamos? ¿Todo?
Nuestra política de syslog:



Se envían todos los logs de severity: emerg, alert, crit y error
En las máquinas que actúan de firewall: todos los logs de firewall
En las máquinas gestoras de mail: todos los logs de mail
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs

Para enviar los logs, simplemente añadir esta línea al syslog.conf
de cada máquina:
*.emerg;*.alert;*.crit;*.err

@nodo-central
En firewalls, añadimos el iptables
*.emerg;*.alert;*.crit;*.err;kern.=debug

En gestores de mail, añadimos:
*.mail
@nodo-central
@nodo-central
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: ¿Qué envio?
Otras decisiones:

¿Syslog o syslog-ng?
Nuestra experiencia es que syslog-ng es recomendable, pero no
imprescindible
Para una instalación nueva, yo lo instalaría desde el principio.

¿Envío encriptado ?
Syslog envía los mensajes en texto en claro. Nosotros no lo hemos creído
necesario, pero puede serlo en entornos muy seguros

Almacenamiento en una BD
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Análisis

El análisis consiste en buscar los mensajes que realmente nos
aportan información sobre el estado del sistema.

La clasificación de severitys, en general no suele aportar mucho
sobre la gravedad de los mensajes, ya que cada software la
interpreta de formas muy distintas

En general, los programas normales utilizan una única severity
para generar todos los mensajes.

Sólo los programas más sofisticados usan correctamente toda la
clasificación de severitys (kernel, bind, samba, …)
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Análisis

Para el análisis de los logs existen muchos programas de parser,
los más conocidos son:



Logsurfer+
Swatch
Nuestra recomendación es agrupar cada facility en un fichero y
“parsearlo” por separado. Como hemos agrupado por facilitys, los
mensajes de un mismo tipo de programas están agrupados, así
que es mucho más fácil reconocer patrones
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Análisis II

Swatch se basa en un fichero de configuración del estilo:
####################### Configuracion SWATCH ############################
# ATENCION: Fichero generado automaticamente por el SiMLog al ejecutar
# start_simlog.
# Fichero de Log: /xxxx/xarxes.log
#########################################################################
ignore /.*Ethernet.* changed state to .*/
ignore /.*last message repeated.*/
watchfor /(.*Configured from console by .*.*)/
bell
echo
mail [email protected]
exec perl /home/soft/swatch/send_alarm 'ALL'
0 '' '$1'
watchfor /(.*Attempted to connect to RSHELL from .*.*)/
exec perl /home/soft/swatch/send_alarm 'ALL' 1 '' '$1'
watchfor /(.*list .* denied .*.*)/
exec perl /home/soft/swatch/send_alarm 'ALL'
1 '' '$1'
watchfor /(.*list .* permitted .*.*)/
exec perl /home/soft/swatch/send_alarm 'ALL'
0 '' '$1'
watchfor /(.*)/
exec perl /home/soft/swatch/send_alarm ‘switch1:switch2'
2 '' '$1'
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Análisis II
Consejos:

Una vez centralizados los logs, acumular mensajes en cada
categoría durante unos días.

La primera regla que nos aparecerá
ignore /(.*last message repeated.*)/

Algunos mensajes ya son sobradamente conocidos, así que ya
podemos incorporarlos. Otros los podremos obtener a partir de los
ficheros.

Añadimos una opción de “todo lo que no interpreto, genero una
alarma al final”. De esta forma poco a poco irán apareciendo los
mensajes importantes e iremos descartando el resto
watchfor /(.*)/
mailto [email protected]

En ficheros con gran cantidad de mensajes podemos decidir que
todo lo no reconocido sea ignorado.
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Integración con Nagios

Swatch es bueno reconociendo
patrones, pero nosotros
necesitamos integrarlo con
nuestra herramienta de gestión de
redes: Nagios

Mi objetivo final es que cada equipo/servidor tenga una alarma que me
diga qué mensajes son importantes.
Nagios nos permite 3 niveles de alarma: OK, Warning y Critical. También
me interesa incorporar este nivel de alarma a mis mensajes

FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs :Integración con Nagios II


Para integrarlo necesitamos un elemento más, que nos relacione
determinados logs con sus servidores y añada en nivel de OK,
Warning o Critical.
Para ello desarrollamos un script que aporta esta utilidad. Este
script parte de un fichero de configuración como éste y nos genera
los ficheros de configuración de swatch
log: /xxx/xarxes.log
ALL;;/Configured from console by .*/;"";OK;-;-;ALL;;/Attempted to connect to RSHELL from .*/;"";WARN;-;-;switch1,switch2;;/.* GigabitEthernet.*\/52 changed state to .*/;"";CRIT;-;-;switch1,switch2;;/.* GigabitEthernet.* changed state to .*/;"";NONE;-;-;ALL;;/psecure-violation error detected/;"";CRIT;-;-;ALL;;/.* FastEthernet.* changed state to .*/;"";NONE;-;-;ALL;;/FastEthernet.* is experiencing errors/;"";WARN;-;-;ALL;;/GigabitEthernet.* is experiencing errors/;"";WARN;-;-;ALL;;/list .* denied .*/;"";WARN;-;-;ALL;;/list .* permitted .*/;"";OK;-;-;ALL;;/FastEthernet.* link down\/up .* times per min/;"";NONE;-;-;router1,router2;;/GigabitEthernet.* link down\/up .* times per min/;"";CRIT;-;-;ALL;;/last message repeated/;"";NONE;-;-;- router1,router2;;/.*/;"";CRIT;-;-;ALL;;/.*/;"";CRIT;-;-;-
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización de Logs: Integración con Nagios III

Para incorporar las alarmas a Nagios usaremos la opción de
swatch de llamar a un programa externo para pasarle el mensaje,
la máquina y el nivel de alarma

El script “send_alarm” escribe en el fichero de comandos externos
(nagios.cmd) el resultado de la alarma
watchfor /(.*list .* permitted .*.*)/
exec perl /home/soft/swatch/send_alarm 'ALL'

0 '' '$1‘
Para Nagios crearemos una servicio nuevo donde incorporaremos
estos mensajes. Este servicio será de tipo “volátil”
define service{
name simlog-generico
use servicio-generico
service_description MENSAJES
max_check_attempts 1
is_volatile 1
normal_check_interval 60
contact_groups admin-lcfib
check_command reset_alarm
stalking_options o,w,c,u
register 0
}
FACULTAT D’INFORMÀTICA DE BARCELONA
Ventajas adicionales
Ventajas adicionales:
 Logs remotos dan seguridad
añadida ya que no pueden ser
modificados

Nos permite centralizar
software de estadístico,
gráficas, …

Nos permite hacer correlación
de eventos

Notificaciones de scripts
específicos
FACULTAT D’INFORMÀTICA DE BARCELONA
Centralización: Documentación interesante

Documentación sobre las auditorías de Windows:
http://www.microsoft.com/spain/technet/seguridad/2000server/chapters/ch06secops.asp

Logsurfer+
http://www.samag.com/documents/s=9053/sam0403i/0403i.htm

Cross-Platform Event Reporting
http://www.samag.com/articles/2000/0009/

Remote System Logs via SSH
http://www.samag.com/documents/s=1149/sam0106s/0106s.htm

Sitio web sobre temas de logs. Buenos artículos y
referencias
http://www.loganalysis.org/

Guia de mensajes inesperados en los logs:
http://www.loganalysis.org/presentations/syslog_sans_webcast.pdf

Snare EventLog (LotusNotes, windows, … es GNU)
http://www.intersectalliance.com/projects/SnareWindows/index.html
Descargar

Centralizacion Logs