¡Hola! En una anterior oportunidad, por este vuestro blog, os desglosamos en 17 categorías las mejores herramientas de red para gestionar vuestra red (en idioma inglés) e incluimos a Graylog2 como software administrador de registros. También os publicamos un artículo sobre monitoreo de red (en castellano) con sus definiciones y características y disertamos sobre el monitoreo de red básico: en esta categoría ubicaremos a Graylog2 y para el monitoreo de red avanzado a Pandora FMS. Es por ello que este artículo es meramente comparativo: estamos tratando de cotejar peras con manzanas pero con propósitos didácticos nos embarcamos en esta singladura ¡vamos!

Breve historia de syslog y Graylog2

Para poder conocer el funcionamiento de Graylog2 debemos saber qué es syslog, piedra angular del software que hoy nos ocupa. La historia se remonta a 1981 cuando Eric Paul Allman trabajaba en la Universidad de California en Berkeley y escribió el software Sendmail, prácticamente el padre del correo electrónico moderno, y necesitaba un pequeño programa que le informara de los acontecimientos en cada servidor que ejecutara Sendmail. Ya UNIX, integrado en su propio kernel, tenía la capacidad de generar sus propios mensajes (incluyendo mensajes de alerta) y 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 otro ordenador (llamado colector) para analizar los datos. Pueden ampliar sus conocimientos si leen la norma RFC 5424 acerca de las capas y su esquema 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).

De hecho 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 incluso 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. De ese punto el darle a syslog un proposito totalmente distinto para elq ue fue creado restaba solu un paso y rápdiamente fue dado. He aquí los albores de la monitorización de red a nivel muy básico y Graylog2 es uno de los tantos programas que se encargan de ello y que más adelante veremos con detalle su funcionamiento.

Graylog2 nació de la mano de Lennart Koopmann a mediados de 2009 debido a su obervación de los altos costes de licencia del software de monitoreo, así que él decidió escribir uno propio. 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, ese detalle de quitarle el número «s», 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 Graylog2 ya que incluso grandes empresas de alojamiento web lo conocen como Graylog2 (y recomiendan su uso). Es entonces que 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 y al momento de escribir estas líneas está vigente la 2.3.2 (19 de octubre de 2017) que será la que revisaremos.

Funcionamiento de Graylog2

El registro de mensajes por parte del kernel de los sistemas operativo en ficheros de texto plano, tanto en software privativo como software libre, estará con nosotros durante mucho tiempo y a eso apuesta de seguro Graylog2 ¡pues bien comencemos por hablar de seguridad y rentabilidad!

syslog, syslog-ng, rsyslog, logrotate y nxlog

Graylog2 por ser software libre no es para nada una «caja negra» manejada por terceros sino por nosotros mismos, así que los datos que le entreguemos a este programa pues es 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 envio de información por parte de paquetes UDP. Los cuales no ofrecen «acuse de recibo» ni «estrechamiento de manos» («handshaking» en inglés) 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 red privadas virtuales («VPN» en inglés) a diestra y siniestra para enviarlos pero incluso así un dispositivo cualquiera seguirá enviando información, así se haya caido la comunicación o incluso nuestro servidor Graylog2 esté apagado o fuera de servicio, tal escenario no conviene a nuestros propósitos.

Es por ello que aparte de syslog han surgido soluciones que envíen por paquetes TCP -que pueden implementar protocolos seguros y garantizan la entrega de cada uno de los paquetes enviados- amén de otras características adicionales, como por ejemplo entregarlos directamente en un motros 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 existe desde 1998, tiene versión libre y una versión empresarial (esta última con módulos adicionales) y está disponible para las grandes distros de Linux e incluso hay una versión para Windows bajo Cygwin, software que permite una emulación de Linux en Windows. Pero claro, hay muchas otras alternativas sin embargo nos enfocaremos 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, en CentOS y similares está presente en los repositorios oficiales y Ubuntu 16 («distro» de Debian) lo trae por defecto como parte de una utilería mayor: Logrotate. Para efectos prácticos los registros de eventos de cada ordenador, una vez hayan sido enviados a Graylog2, pues poco nos importa el destino final de esta información: por el contrario, es una trabajo menos que no tendremos que lidiar en neustra labor de administrar y/o monitorear redes.

¿A dónde vamos con toda esta explicación y qué diantres tiene que ver con Graylog2? Pues que todo esto que os contamos lo repetiremos cuando veamos su funcionamiento por la analogía en cuanto al manejo de la información recibida -y almacenada-. Pues bien logrotate, como su nombre en inglés sugiere, se encarga de rotar y comprimir y además de podarlos periódicamente ya que de no hacer esto nuestros discos duros eventualmente se llenarían. 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 las aplicaciones (por ejemplo, el fallo en acceder a una base de datos con MS SQL).
• Eventos relacionados con el Active Directory, una tecnología que permite adminitrar 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 talaes 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 los 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 Graylog2. Ya que de nuevo tocamos el tema de la transmisión, en Windows podremos instalar una solució 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 cual es cual? Volvamos a lo último que vimos sobre crear nuestros propios eventos en Windows (en otros sistemas oeprativos 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

Graylog2: funcionamiento y requisitos

Acá si ahorraremos tiempo: el funcionamiento de Graylog2 y su instalación está íntimamente relacionados, creamos este esquema simplificado no recomendado más que para simples pruebas, en un ambiente de producción imposible usarlo de esta manera.

Con la imagen como abreboca arrancamos con los requisitos de instalación (funcionamiento incluído), aclarando que solo lo instalaremos en un anfitrión Linux ya que no se recomienda para nada hacerlo sobre Windows:

• Graylog2 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 Graylog2 v2.2). Este componente será el encargado de realizar el trabajo pesado, tanto es así que incluso en un esquema simplificado no dejamos de dibujarlo con racimo («cluster») y no es para menos: 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 que 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 Graylog2 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 información; además en la versión empresarial contará con servidor Goliat para mover y migrar datos realmente grandes). ¿Recuerdan que hablamos sobre logrotate? Pues bien para ese trabajo en Graylog2 ofrecen en la versión empresarial el servicio de resguardo de datos (comprimidos, encriptados y transportados por internet con protocolo seguro para proteger la privacidad de los clientes) con la promesa que podrán ser reimportados cuando sean requeridos a solicitud (también está incluído el contacto directo con los ingenieros y programadores de Graylog2 más un servicio de auditoría de las acciones de usuario cuya información se guarda ¿en cuál base de datos? Pues pasemos al siguiente punto).
• Si en Pandora FMS necesitamos uno y solo un motor de base de datos (MySQl) en Graylog2 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 para, consideramos nosotros, labores de auditoría o minería de datos (por ejemplo, el buscar los registros sobre una aplicación particular en un dispositivo particular para observar su desempeño o cambios en su configuración). Graylog2 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?

A primera vista parece lo mismo pero atentos todos y todas al concepto: con Elasticsearch tenemos una poderosa y hambrienta locomotora por ingerir grandes cantidades de carbón y agua, si no hacemos esto terminaremos con toneladas de hierro frías y estáticas, lo cual no es útil para nada. Consideramos que Elasticsearch como herramienta de auditoría e incluso minería de datos es una gran ayuda nunca deberemos el dejar de alimentarla.

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

*.* @direccion_ip_del_servidor_graylog2:8514;RSYSLOG_SyslogProtocol23Format

El asterisco-punto-asterisco del principio indica enviar todo al servidor Graylog2 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 importantes, no nos vayan a interpretar mal por favor! Simplemente manejamos el concepto que hay cosas realmente importantes a monitorizar, prioritarios (Pandora FMS tiene perfiles prefijados para cada tipo de cliente, configuraciones que se consideran típicas ¡y en la versión Empresarial hasta somos capaces de crear un agente a su medida y necesidades!).

Para dar sustento a nuestra afirmación anterior, en Graylog2 a partir de la versión 2.x crearon un «Proceso de tuberías» en los cuales debemos configurar los siguientes elementos:

• Tuberías «pipelines».
• Reglas «rules».
• Conectores de flujo «stream connections».
• Funciones «functions«.

Una vez hallamos establecido todo esto es que podremos proceder a filtrar la información que llega al servidor Graylog2 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 costos.

Extendiendo las capacidades de Graylog2

Si os pareció complicado hasta ahora, 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 Graylog2.

• No dejamos de repetirlo: para que Graylog2 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) para otros servidores Elasticsearch que ejecuten o no a Graylog2. También podremos usar Kibana para fantásticas y maravillosas representaciones gráficas… pero deberemos adquirir una solución aparte para el manejo de usuarios, cosa de la cual sí se encarga Graylog2 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 Graylog2 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 Graylog2 practicamente deberemos instalar de nuevo la solución completa).
• Otras soluciones que podremos optar, relacionado 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 y así tener un granja de servidores Graylog2 que centralizen las operaciones.
  • Instalar «Graylog Collector Sidecar» y utilizar la API integrada de Graylog2 (en Pandora FMS esto no es necesario porque tiene sus propios Agentes Software).
  • Graylog2 apuesta fuertemente por su propia norma de envio llamada GELF (Graylog Extended Log Format) que permite envio 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 dijimos que es inseguro). Lo que impide enviarlos comprimidos por TCP es el delimitador de null en el formato Json, lo cual también ha traido 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 disperdigadas han tenido cobijo bajo el «graylog marketplace» donde se encargan de categorizarlos y alamcenar los enlaces correspondientes para que los usuarios los integren a Graylog2
• Ya dijimos que el envio de todos los registros para su posterior filtrado cuando llegue a un servidor Graylog2 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 Graylog2 dedicado por cada zona geográfica obtendremos siempre unos servidores más ocupados que otros e incluso algunos ociosos, balancear la carga los manteniene a todos siempre activos y trabajando para nosotros).
• Tanto Pandora FMS como Graylog2 tiene soporte para autenticación LDAP o Active Directory.

Conclusiones.

Definitivamente que Pandora FMS y Graylog2 tienen algunas similitudes a la hora de la recolección de data, teniendo en cuenta el filtrado de datos contra la selección de datos, sus maneras de trabajar son bien distintos: mientras Graylog2 descansa en gran medida sobre productos de terceros con dos motores de bases de datos para distintos juegos de infromació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 muy bien seleccionada. En Pandora FMS la flexibilidad también implica sencillez, en contraste con la complejidad de Graylog2.

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