Centralizacion logs-UPC

Centralización de logs:
FACULTAT D’INFORMÀTICA DE BARCELONA
Una experiencia real
Daniel Sánchez Dorado

dani@fib.upc.edu
Facultad de Informática de Barcelona

Universidad Politéctica de Catalunya
Jornadas Técnicas Rediris 2006

16 Noviembre 2006
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
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.
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.
Centralización de Logs: Lista de tareas
Las tareas básicas son:
 Recolección local
 ¿Qué recojo? ¿Cómo lo clasifico?
 Envío a un servidor central

 ¿Qué envío?
 Análisis
 ¿Qué busco?
 Entrega de resultados
 ¿Cómo lo enseño?
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
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 -/var/log/warn
*.crit /var/log/warn
#
# Some foreign boot scripts require local7
#
local0,local1.* -/var/log/localmessages
local2,local3.* -/var/log/localmessages
Centralización de Logs: syslog.conf
# Mensajes de kernel
kern.panic;kern.emerg;kern.alert;kern.crit;kern.err /syslog/kern_greu.log
kern.warning;kern.notice;kern.info /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
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
Centralización de Logs:
Tabla de facilitys centralizada
 Al final, hemos de llegar a una tabla como esta:

Facility Uso
kern Mensajes del kernel, reservado
kern.debug El ipfilter de linux va forzosamente a kern.*. Elegimos ponerlo en debug -> lo redirecionaremos al ip.log
user Mensajes de usuario, user.notice usado para mensajes de conexion de usuarios de FIBNETLESS
mail Mail
daemon Daemons varios: dns, dhcp, …
incluye script de actualizacion de fichero de firmas en ricino
auth ssh
syslog mensajes del syslog
lpr Impresoras
news Logs de windows -> Windows Security
uucp Logs de windows -> Windows System
cron
authpriv
ftp Amavis de ricino
ntp
log audit
log alert
clock daemon
local0 LOGS de firewalls (Linux ipfilter & Solaris iptables)
El ipfilter de Solaris va forzosamente al local0 --> OK -> lo redirecionaremos al ip.log
local1 usos locales
local2 usos locales
local3 LDAP
local4 samba
local5 Tripwire
local6 Redes - mensajes
local7 Para todo en general
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
Centralizacion de Logs: política de Windows
Seguridad
Sistema
Aplicación
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
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
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 @nodo-central
 En gestores de mail, añadimos:

*.mail @nodo-central
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
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, …)
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
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 xxxx@fib.upc.edu
exec perl /home/soft/swatch/send_alarm 'ALL' 0 '' '$1'
watchfor /(.*Attempted to connect to RSHELL from .*.*)/
watchfor /(.*list .* denied .*.*)/
watchfor /(.*list .* permitted .*.*)/
watchfor /(.*)/
exec perl /home/soft/swatch/send_alarm ‘switch1:switch2' 2 '' '$1'
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 admin@fib.upc.edu
 En ficheros con gran cantidad de mensajes podemos decidir que

todo lo no reconocido sea ignorado.
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
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;-;-;-
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
}
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
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

Centralizacion logs-UPC

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Centralizacion logs-UPC

Cargado por

Copyright:

Formatos disponibles

Centralización de logs:

FACULTAT D’INFORMÀTICA DE BARCELONA

Una experiencia real

Daniel Sánchez Dorado

Facultad de Informática de Barcelona

Jornadas Técnicas Rediris 2006

El Laboratorio de Cálculo de la Facultad de Informática de

En general, cada equipo es una fuente local de logs

Esos logs generalmente están basados en el sistema de

Pero, … ¿quién mira esos logs?

El problema es que nadie controla estos logs

… y nosotros queremos que

El año pasado emprendimos un proyecto cuyo objetivo es

incorporar la información útil de los logs a nuestro

Existen gran cantidad de artículos explicando como se

Descubrimos que estos artículos obvian ciertos

El objetivo de esta presentación es exponer todos los

Las tareas básicas son:

 Envío a un servidor central

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

 Cada aplicación envía los logs a una facility

 La mayoría de distribuciones actuales agrupan los

# Logs de los ipfilters de los firewals Linux

# Logs de los iptables de Solaris

# Logs del tripwire

 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

 A veces el mismo software ¡ ocupa distintas facility en distintos

 Al final, hemos de llegar a una tabla como esta:

 Usaremos el NTSyslog para integrar los “sucesos de sistema” de

 Las categorías de sucesos de Windows parecen las de syslog,

 Los IOS de Cisco incorporan un cliente syslog, sólo hay que

 Las impresoras HP y las tarjetas de gestión de los SAIs modernos

 Aplicaciones específicas que dejan mensajes en ficheros concretos

 Para el resto de dispositivos se puede habilitar un gestor de traps

sincronizado en todos los servidores, simplemente hemos de

Nuestra política de syslog:

 Se envían todos los logs de severity: emerg, alert, crit y error

 Para enviar los logs, simplemente añadir esta línea al syslog.conf

 En firewalls, añadimos el iptables

 En gestores de mail, añadimos:

 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

 En general, los programas normales utilizan una única severity

 Sólo los programas más sofisticados usan correctamente toda la

 Para el análisis de los logs existen muchos programas de parser,

los más conocidos son:

 Nuestra recomendación es agrupar cada facility en un fichero y

 Swatch se basa en un fichero de configuración del estilo:

####################### Configuracion SWATCH ############################

 Una vez centralizados los logs, acumular mensajes en cada

 La primera regla que nos aparecerá

 Algunos mensajes ya son sobradamente conocidos, así que ya

 Añadimos una opción de “todo lo que no interpreto, genero una

 En ficheros con gran cantidad de mensajes podemos decidir que

 Swatch es bueno reconociendo

patrones, pero nosotros

 Para integrarlo necesitamos un elemento más, que nos relacione

determinados logs con sus servidores y añada en nivel de OK,

 Para incorporar las alarmas a Nagios usaremos la opción de