1 / 25

Centralización de Logs: Presentación

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.

fausto
Télécharger la présentation

Centralización de Logs: Presentación

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Centralización de logs: Una experiencia realDaniel Sánchez Doradodani@fib.upc.eduFacultad de Informática de BarcelonaUniversidad Politéctica de CatalunyaJornadas Técnicas Rediris 200616 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:

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

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

  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

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

  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 admin@fib.upc.edu • 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

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

  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 }

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

More Related