Comparativa Pandora FMS versus Graylog 2

Graylog 2 VS Pandora FMS: comparación en profundidad

Para poder conocer el funcionamiento de Graylog 2 primero debemos descubrir qué es syslog. La historia se remonta a 1981, cuando Eric Paul Allman trabajaba en la Universidad de California, en Berkeley, y escribió un software que sería el predecesor del correo electrónico moderno, Sendmail. Así necesitaba un pequeño programa que informaba de los acontecimientos en cada servidor que ejecutara Sendmail.

UNIX, integrado en su propio kernel, tenía la capacidad de generar sus propios mensajes, que eran guardados en archivos de texto dentro del sistema de ficheros. Eric Allman desarrolló un programa de servicio (“daemon” en inglés o demonio en castellano) llamado syslogd, encargado de leer los archivos con dichos mensajes guardados y estableció el protocolo syslog para enviarlos a otros ordenadores (llamado colector) para analizar los datos. Pueden ampliar sus conocimientos si leen la norma RFC 5424 acerca de las capas y sus esquemas de funcionamiento (nota: la norma indica que tranquilamente todos los componentes de syslog pueden residir en un único ordenador; sin embargo la imagen ilustra sobre dos ordenadores que se comunican de alguna manera. Tampoco debemos confundir syslog con syslogd).

Syslog se volvió tan popular que pronto nació la necesidad de que el colector no solo llevara los registros del servidor que ejecutara Sendmail, sino que recibiera los registros de los clientes que se conectaran a ese servidor de correo, ya que fusionar cronológicamente ambos documentos de manera provisional, ayudaba – y aún ayuda – a rastrear errores en el código. Así se dió a syslog un futuro totalmente distinto del que tenía.

Graylog 2 nació de la mano de Lennart Koopmann a mediados de 2009, cuando decidió crear un software propio al ver los altos costes de los softwares de monitoreo. En sus propias palabras asegura que la oferta en ese sector de código fuente abierta era nula, pero os aseguramos que Pandora FMS estaba en su versión 3.0.

Su página web oficial es www.graylog2.org (aunque la página web redirige automáticamente hacia www.graylog.org) y su cuenta en Twitter es @Graylog2 . Este cambio de nombre ocurrió el 16 de enero de 2015 al sacar la versión 1.0 (beta). A lo largo de este artículo usaremos preferentemente su nombre original, Graylog 2. En estos dos últimos dos años ha registrado un aumento explosivo de usuarios y el 27 de abril de 2016 liberan la versión 2.0. Actualmente está vigente la 2.3.2 (19 de octubre de 2017).

Funcionamiento de Graylog 2

El software privativo y el software libre van a estar con nosotros durante mucho tiempo y por esto apuesta Graylog 2. ¡Pues bien, comencemos por hablar de seguridad y rendimiento!

syslog, syslog-ng, rsyslog, logrotate y nxlog

Graylog 2, aunque sea un software libre, no es una “caja negra” manejada por terceros, sino que podemos manejarla nosotros mismos. Así, los datos que le entreguemos a este programa son responsabilidad nuestra, única y exclusivamente.

Teniendo esto en mente, nuestras necesidades de monitoreo son para muchos dispositivos ya sea dentro de nuestra red de área local o en el resto del mundo y syslog solo establece el envío de información por parte de paquetes UDP. Los cuales no ofrecen “acuse de recibo” ni “estrechamiento de manos”, así que no podremos usar un protocolo seguro de encriptamiento para garantizar que nuestra información no caiga en manos de terceros. Tal vez se nos ocurra instalar redes privadas virtuales (“VPN”) a diestra y siniestra para enviarlos pero, incluso así, un dispositivo cualquiera seguirá enviando información. Si se ha caído la comunicación o incluso nuestro servidor Graylog 2 está apagado o fuera de servicio, puede no ser demasiado bueno para nuestros propósitos.

Es por eso que aparte de syslog han surgido otras soluciones que envían por paquetes TCP -que pueden implementar protocolos seguros y garantizan la entrega de cada uno de los paquetes enviados- además de otras características adicionales, como por ejemplo entregarlos directamente en un motor de base de datos como MySQL o preprocesamiento de ficheros e incluso su nomenclatura de nombres para guardar de manera ordenada muchos dispositivos.

Syslog-n tiene una versión libre y una versión empresarial (esta última con módulos adicionales) y está disponible para Linux e incluso hay una versión para Windows bajo Cygwin. A pesar de que hay muchas otras alternativas, nos centraremos en rsyslog, que surge en 2004 por mano de Rainer Gerhards en competencia directa con syslog-ng y hoy en día viene preinstalado en Debian, CentOS, Ubuntu 16 (distro de Debian, que además lo trae por defecto como parte de Logrotate). A efectos prácticos los registros de eventos de cada ordenador dejan de importarnos después de haber sido enviados a Graylog 2.

¿A dónde vamos con toda esta explicación y qué diantres tiene que ver con Graylog2? Pues bien, Logrotate, como su nombre sugiere, se encarga de rotar y comprimir, además de podarlos periódicamente. Ya que de no hacer esto, nuestros discos duros acabarían por llenarse. En el caso del sistema operativo privativo Windows, desde la versión 2000 (y todos sus sucesores) tienen su propio servicio integrado de:

• Registro de eventos de aplicaciones (por ejemplo, fallos en acceder a una base de datos con MS SQL).
• Eventos relacionados con el Active Directory, una tecnología que permite administrar cientos de ordenadores por medio de dominios con ayuda de DNS. ¡Imaginad la cantidad de datos generados por uno de estos servidores que maneje un árbol o un bosque completo de dominios!
• Eventos relacionados (en categoría aparte) con los DNS, manejen o no algún Active Directory.
• Replicación de archivos, suerte de respaldos distribuidos que se sincronizan entre sí.
• Seguridad: para el caso de los administradores todo lo relacionado con los accesos al sistema operativo tales como manejo de usuarios, ingresos fallidos de contraseña, etc.
• Por último lo más importante: los eventos relacionados con el sistema operativo y su interacción con el hardware, tales como S.M.A.R.T. de los discos duros, tiempo en servicio, reinicios y apagados forzosos, etc.

Incluso podemos grabar nuestros propios eventos de prueba en Windows; con las debidas credenciales de administrador en la línea de comandos podemos practicar lo siguiente:

eventcreate /s nombre_servidor /t ERROR /id 100 /l APPLICATION /d "Un registro de evento, como prueba"

El comando eventcreate se encargará de grabarlo para luego transmitirlo a nuestro servidor Graylog 2. Ya que de nuevo tocamos el tema de la transmisión, en Windows podremos instalar una solución de código abierto con este propósito: Nxlog. Esta aplicación está disponible tanto para Windows como para Unix, Linux, BSD y Android: el registro de eventos del sistema operativo como la de las aplicaciones (correctamente programadas para ello). ¿Cómo saber cuál es cuál? Volvamos a lo último que vimos sobre crear nuestros propios eventos en Windows (en otros sistemas operativos transcurre de manera similar). Con los parámetros “/t” y “/l” a continuación le pasamos la severidad y origen del mensaje de registro. Veamos:

Parámetro “/t”:

• ERROR
• WARNING
• INFORMATION
• SUCCESSAUDIT
• FAILUREAUDIT

Parámetro “/l”:

• APPLICATION
• SYSTEM

Graylog 2: funcionamiento y requisitos

El funcionamiento de Graylog 2 y su instalación están íntimamente relacionados; creamos este esquema simplificado. (No está recomendado más que para simples pruebas, en un ambiente de producción puede ser imposible usarlo de esta manera.)

Así arrancamos con los requisitos de instalación (funcionamiento incluido), aclarando que solo lo instalaremos en un anfitrión Linux, ya que no se recomienda hacerlo sobre Windows:

• Graylog 2 como tal, en su componente de servidor, está programado con Java, así que necesitaremos mínimo Java SDK 8. Se encargará, en esencia, de recibir los registros de los otros dispositivos (sin datos de origen no hay proceso alguno que valga).

• Elasticsearch, basado en Apache Lucene, y ambos escritos por completo en Java (en su versión v2.X pero no una versión superior con Graylog 2 v2.2). Este componente será el encargado de realizar el trabajo pesado. Elasticsearch es un programa que recibirá TODOS los registros y hará todo lo necesario para desglosar, clasificar, relacionar y almacenar la información sin importar en qué formato vengan (maneja una gran variedad de protocolos). Recalcamos que será aquí donde reposarán nuestros datos y necesitaremos varias máquinas. El trabajo es fuerte y Graylog 2 lo sabe y maneja el siguiente esquema de trabajo: los usuarios (empresas) generalmente utilizan los últimos 30 días de registro y hasta por un máximo de un año, es lo que recomiendan para que el sistema no se vea resentido en su desempeño.Pandora FMS, a diferencia, mantiene migrando constantemente sus datos con un “servidor de predicción” de manera transparente a sus usuarios: usted es quien decide cuándo eliminar la información; además en la versión empresarial contará con el servidor Goliat para mover y migrar datos realmente grandes.¿Recuerdan que hablamos sobre logrotate? Pues bien, para ese trabajo en Graylog 2 ofrecen una versión empresarial para resguardar datos (comprimidos, encriptados y transportados por Internet con protocolos seguros para proteger la privacidad de los clientes).
• Si en Pandora FMS necesitamos solo un motor de base de datos (MySQL) en Graylog 2 necesitaremos instalar, además de Java y Elasticsearch, el software MongoDB para todo lo relacionado con el acceso de los usuarios por el componente de la interfaz web (HTML más CSS y JavaScript) y algo mucho, muchísimo más importante: las condiciones de alerta que queremos nos sean informadas de manera inmediata comenzando así, de manera seria, las labores de monitoreo básico. También MongoDB nos permitirá almacenar nuestros perfiles de indexado para Elasticsearch. Graylog 2 se encargará de eliminar automáticamente los índices que hayan cumplido su ciclo de vida útil, e incluso recrearlos a solicitud.

¿Filtrando o seleccionando información?

Consideramos que Elasticsearch como herramienta de auditoría e incluso para minería de datos es una gran ayuda, pero nunca deberemos dejar de alimentarla.

¿Recuerdan a rsyslog? En el archivo de configuración que llamaremos “60-graylog.conf” agregaremos lo siguiente:

*.* @direccion_ip_del_servidor_Graylog 2:8514;RSYSLOG_SyslogProtocol23Format

El asterisco-punto-asterisco del principio indica enviar todo al servidor Graylog 2 y eso genera una gran cantidad de tráfico de datos, ¡aún a pesar de estar comprimido! Por el contrario, Pandora FMS delega el envío en Agentes Consola (utilizan normas reconocidas y aceptadas, ya vienen en los dispositivos a monitorear) y en Agentes Software con una amplia variedad de opciones a monitorear (temperatura del equipo, estado de un servidor web o servidor de base de datos) y de esta manera seleccionamos la información que realmente nos interesa conocer. ¡Atención, no decimos que el resto de los datos no sea importante! Simplemente siempre hay cosas prioritarias que deben ser monitorizadas. (Pandora FMS tiene perfiles prefijados para cada tipo de cliente, configuraciones que se consideran típicas ¡y en la versión Empresarial se pueden crear agentes a medida!).

Para dar sustento a nuestra afirmación anterior, en Graylog 2 a partir de la versión 2.x crearon un “Proceso de tubería“, en los cuales se deben configurar los siguientes elementos:

• Tuberías o “pipelines”.
• Reglas o “rules”.
• Conectores de flujo o “stream connections”.
• Funciones o “functions”.

Una vez hayamos establecido todo esto, podremos proceder a filtrar la información que llega al servidor Graylog 2 para que el servidor mismo no procese absolutamente nada que no cumpla con lo prefijado (y mucho menos pase a Elasticsearch).

Podremos concluir en esta sección que filtrar implica “mover” todos los datos para entonces quedarnos con los que nos interesa y seleccionar -el enfoque de Pandora FMS- es extraer la información que nos interese: con ambos métodos obtenemos el mismo resultado pero a muy diferentes costes.

Extendiendo las capacidades de Graylog 2

Si os pareció complicado, os recordamos que apenas es un ejemplo básico; incluso lo podremos montar en un dispositivo como Azure, pero en la vida real, en un entorno de producción, debemos agregar más, mucho más a Graylog 2.

• Para que Graylog 2 crezca, lo primero que debemos hacer es montar más racimos “clusters” para el funcionamiento de Elasticsearch y su motor de base de datos.
• Para MongoDB deberemos instalar réplicas para aumentar su confiabilidad, sin embargo no veremos mejora en su desempeño.
• Otra ventaja de tener a Elasticsearch es el poder utilizar otros productos de la misma compañía tales como Logstash, un potente transporte y filtrados de datos (por supuesto en formato Elasticsearch). También podremos usar Kibana para fantásticas y maravillosas representaciones gráficas… pero debemos adquirir una solución aparte para el manejo de usuarios, cosa de la cual sí se encarga Graylog 2 con ayuda de MongoDB (y en la versión empresarial el proceso de auditoría de usuarios).
• Si necesitamos monitorear varias redes de área locales desperdigadas por todo un país o a lo largo y ancho del globo terráqueo, deberemos instalar un Servidor Graylog 2 que recoja los datos en dicha red de área local para luego enviarlos por Internet. ¿Recuerdan la diferencia entre filtrar y seleccionar? Pues éste sería el momento de aplicarlo antes de enviarlo a un servidor central. Pandora FMS es capaz de lidiar con este asunto con un ligero “servidor satélite“, el cual es especializado y a la medida para este trabajo; con Graylog 2 prácticamente deberemos instalar de nuevo la solución completa.

Otras soluciones que podremos optar, relacionadas con el punto anterior:

• Instalar Windows Servers 2008 o superiores e instalarles Windows Event Collector Service para recoger los datos de una red de área local y a esos servidores a su vez colocarles Nxlog, para así tener un granja de servidores Graylog 2 que centralicen las operaciones.
• Instalar Graylog Collector Sidecar y utilizar la API integrada de Graylog 2 (en Pandora FMS esto no es necesario porque tiene sus propios Agentes Software).
• Graylog 2 apuesta fuertemente por su propia norma de envío llamada GELF (Graylog Extended Log Format) que permite envío de mensajes más de 1024 bytes bien estructurados, “predigeridos” diríamos nosotros, y se pueden picar hasta en 128 trozos para enviarlos comprimidos en protocolo UDP (el cual es inseguro). Lo que impide enviarlos comprimidos por TCP es el delimitador de null en el formato Json, lo cual también ha traído problemas con Logstash, la solución por ahora es el “Graylog TcpLogstashOutput Plugin“, una utilería desarrollada por terceros y que añade una labor a nuestro trabajo de monitorización.
• Todas estas utilerías desperdigadas han tenido cobijo bajo el graylog marketplace donde se encargan de categorizarlos y almacenar los enlaces correspondientes para que los usuarios los integren Graylog 2.
• Ya dijimos que el envío de todos los registros para su posterior filtrado cuando llegue a un servidor Graylog 2 será una gran cantidad de datos, así que se recomiendan balanceadores de carga para la granja de servidores; así tendremos todo en un solo sitio con un mejor desempeño tolerante a fallos (por el contrario, el tener un servidor Graylog 2 dedicado por cada zona geográfica obtendremos siempre unos servidores más ocupados que otros e incluso algunos ociosos, balancear la carga los mantiene a todos siempre activos y trabajando para nosotros).
• Tanto Pandora FMS como Graylog 2 tiene soporte para autenticación LDAP o Active Directory.

Conclusiones

Definitivamente Pandora FMS y Graylog 2 tienen algunas similitudes a la hora de la recolección de datos; teniendo en cuenta el filtrado de datos contra la selección de datos, sus maneras de trabajar son distintas. Mientras Graylog 2 descansa en gran medida sobre productos de terceros con dos motores de bases de datos para distintos juegos de información, Pandora FMS utiliza un solo motor de base de datos que se puede replicar tranquilamente con absolutamente toda la información en un solo sitio y recoge los datos de primera mano de una forma bien seleccionada. En Pandora FMS la flexibilidad también implica sencillez, en contraste con la complejidad de Graylog 2.

Si os a gustado este artículo y consideráis que falta algo o debemos corregir algún detalle no dudéis en comentar más abajo, donde gustosamente os atenderemos.

¿Quieres saber más sobre Pandora FMS?