Centralización de logs: Una experiencia real Daniel Sánchez Dorado dani@fib.upc.edu Facultad de Informática de Barcelona Universidad Politéctica de.

Presentación del tema: "Centralización de logs: Una experiencia real Daniel Sánchez Dorado dani@fib.upc.edu Facultad de Informática de Barcelona Universidad Politéctica de."— Transcripción de la presentación:

1 Centralización de logs: Una experiencia real Daniel Sánchez Dorado Facultad de Informática de Barcelona Universidad Politéctica de Catalunya Jornadas Técnicas Rediris Noviembre 2006

2 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

3 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.

4 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.

5 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?

6 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

7 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

8 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

9 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

10 Centralización de Logs: Tabla de facilitys centralizada
Al final, hemos de llegar a una tabla como esta: Trucos/Experiencias Las iptables de linux no se pueden cambiar de facility (sólo kernel). Como generan mucha informacion las agrupamos en debug En Solaris, todos los mensajes del ipfilter van forzosamente el local0. Esta distribucion también es para los logs de la propia máquina central

11 Centralización de Logs: Windows
Usaremos el NTSyslog para integrar los “sucesos de sistema” de Windows ( 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 y (Descripciones de los sucesos de seguridad de Windows 2000) Elegimos los mensajes que consideremos importantes Escogemos las categorías que engloban todos estos mensajes

12 Centralizacion de Logs: política de Windows
Seguridad Sistema Aplicación

13 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 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

14 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

15 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

16 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

17 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, …)

18 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 Nosotros hemos elegido swatch

19 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 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 .*.*)/ watchfor /(.*list .* permitted .*.*)/ watchfor /(.*)/ exec perl /home/soft/swatch/send_alarm ‘switch1:switch2' 2 '' '$1' Opciones útiles: Ignore: nos permite ignorar un determinado mensaje Truco: si el mensaje no es aceptado por ningun filtro, generamos un error. Acciones: bell, echo, mail, o ejecutar un programa concreto

20 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 En ficheros con gran cantidad de mensajes podemos decidir que todo lo no reconocido sea ignorado.

21 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 No hace falta explicar demasiado sobre Nagios, es una herramienta sobradamente conocida.

22 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;-;-;- Muy técnico 4 opciones: OK/WARNING/CRITICAL/NONE Aprovechamos para añadir opciones de tiempo

23 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 } Muy técnico El send_alarm además discrimina entre las diferentes máquinas o elige todas “ALL” y envia la alarma a Nagios y la contra-alarma justo después.

24 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

25 Centralización: Documentación interesante
Documentación sobre las auditorías de Windows: Logsurfer+ Cross-Platform Event Reporting Remote System Logs via SSH Sitio web sobre temas de logs. Buenos artículos y referencias Guia de mensajes inesperados en los logs: Snare EventLog (LotusNotes, windows, … es GNU)

26 Centralización de Logs: syslog.conf
# equipos redes local6.panic;local6.emerg;local6.alert;local6.crit /syslog/xarxes_greu.log local6.err;local6.warning;local6.notice;local6.info;local6.debug /syslog/xarxes.log # Logs del amavis para analizar ftp.=notice /syslog/amavis_mail.log ftp.=info /syslog/amavis_mail2.log ftp.=debug /syslog/amavis_zona.log # Copia para analizar Mailgraph # Enviamos copia de todo el mail y los del amavis mail.debug;ftp.=notice;ftp.=info;ftp.=debug /syslog/analisis_mail.log # Windows news.debug /syslog/Windows_Security.log uucp.debug /syslog/Windows_System.log