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

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

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 .*.*)/ 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

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

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

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.

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

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