Existen varias razones para tener a buen recaudo los registros de nuestro servidor pero la principal razón es la seguridad. Disponer de un sistema centralizado en donde almacenar esta información nos permite auditar de una manera más eficiente lo que sucede en nuestro sistema. Si algo falla podemos recurrir al servidor y saber qué ha ocurrido, pero podemos ir un poco más allá, podemos reenviar esa información a un Workspace de Azure Monitor para su posterior análisis o utilizar Azure Sentinel como plataforma de gestión de eventos e información de seguridad (SIEM) para automatizar el proceso de gestión de grandes volúmenes de datos mediante inteligencia artificial. Suena bien, ¿cierto? Para ello usaremos el agente de Log Analytics pero este agente solo es compatible con determinadas distribuciones GNU/Linux. ¿Entonces cómo podemos enviar los registros de Syslog incluso de distribuciones no compatibles con el agente? Existe un método. Usando el servidor colector como un relé. Pero vayamos por partes.
Syslog es el acrónimo de System Logging Protocol, que significa protocolo de registro del sistema. Se trata de un protocolo estándar utilizado para enviar mensajes de registro o eventos del sistema a un servidor específico, llamado servidor de Syslog. El Syslog se utiliza principalmente para recopilar varios registros de dispositivos de diversas máquinas diferentes en una ubicación central para la supervisión y su análisis.
Aunque Syslog tiene algunos problemas de seguridad, su sencillez ha hecho que muchos dispositivos lo implementen como routers, switches, cortafuegos e incluso en algunas impresoras y escáneres. Además, Syslog está disponible en sistemas basados en Linux/Unix y en muchos servidores web como Apache. Syslog no está instalado de manera predeterminada en los sistemas Windows, que usan su propio registro de eventos; si bien es capaz de reenviarlos a través de herramientas de terceros u otras configuraciones utilizando el protocolo Syslog.
RFC 5424 define el protocolo Syslog, haciendo obsoleto el RFC 3164 anterior. El software utilizado para enviar registros de forma remota es rsyslog, viene de forma predeterminada en Debian y distribuciones de Linux derivadas.
Tradicionalmente, Syslog usa el protocolo UDP en el puerto 514, si bien puede configurarse para usar cualquier otro puerto. Adicionalmente, ciertos dispositivos usan el puerto TCP 1468 para enviar datos de Syslog a fin de obtener confirmaciones de entrega de los mensajes.
El protocolo Syslog es muy sencillo. Necesitamos un ordenador servidor ejecutando el servidor de Syslog, conocido como Syslogd (demonio de Syslog), a donde el dispositivo cliente envía un pequeño mensaje de texto (de menos de 1024 bytes).
Los mensajes de Syslog se suelen enviar vía UDP, por el puerto 514, en formato de texto plano. Algunas implementaciones del servidor, como syslog-ng, permiten usar TCP en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados mediante SSL/TLS.
Aunque Syslog tiene algunos problemas de seguridad, su sencillez ha hecho que muchos dispositivos lo implementen, tanto para enviar como para recibir. Eso hace posible integrar mensajes de varios tipos de sistemas en un solo repositorio central.
Estructura del mensaje
El mensaje enviado se compone de tres campos:
Entre todos no han de sumar más de 1024 bytes, pero no hay longitud mínima.
Prioridad y transmisión
La prioridad es un número de 8 bits que indica tanto el recurso (tipo de aparato que ha generado el mensaje) como la severidad (importancia del mensaje), números de 5 y 3 bits respectivamente. Los códigos de recurso y severidad los decide libremente la aplicación, pero se suele seguir una convención para que clientes y servidores se entiendan.
La transmisión de paquetes de Syslog es asíncrona, y los mensajes se generan según se haya configurado en el equipo correspondiente, ya se trate de un router, un switch o un servidor. A diferencia de otros protocolos de supervisión, como SNMP, no existe un mecanismo para sondear los datos de Syslog. En determinadas implementaciones, SNMP puede usarse para establecer o modificar parámetros de Syslog de forma remota.
El protocolo Syslog puede generar muchos mensajes, y se dedica simplemente a reenviarlos tan rápido como pueda. A causa de ello, la capacidad más importante para un servidor Syslog es la de filtrar correctamente y reaccionar de forma adecuada a los datos de Syslog entrantes.
El servidor Syslog también se conoce como el colector o el receptor de Syslog. Los mensajes de Syslog se envían desde el dispositivo emisor al receptor. Para ello, debe configurarse en el propio dispositivo emisor la dirección IP del servidor Syslog de destino, ya sea mediante la línea de comandos o a través de un archivo conf. Una vez configurado, todos los datos de Syslog se enviarán a ese servidor. Dentro del protocolo Syslog no existe ningún mecanismo para que un servidor diferente solicite la información de Syslog a un emisor.
Rsyslog es un eficiente y rápido sistema de procesamiento de registros de sistema. Ofrece un diseño modular de alto desempeño y niveles de seguridad apropiados. A diferencia de sus predecesores —sysklog y syslog— permite ingreso de datos desde diversas fuentes, transformación de datos y salida de resultados hacia varios destinos. El paquete rsyslog es un componente esencial y obligatorio de cualquier distribución de GNU/Linux moderna y por tanto viene instalado de modo predeterminado y el servicio estará activo en todos los niveles de ejecución.
Puedes verificar si rsyslog se encuentra funcionando usando la siguiente instrucción: sudo service rsyslog status
Si el estado indica que no se encuentra activo deberemos usar
sudo service rsyslog start o systemctl start rsyslogY, ya por último. En caso de que necesitemos instalar rsyslog bastaría con ejecutar:
sudo apt install rsyslogEl siguiente paso pasa por habilitar el a rsyslog en el servidor para escuchar eventos a través del puerto 514:
Editamos el fichero de configuración:
# nano /etc/rsyslog.confY descomentamos las siguientes líneas como muestra la imagen a continuación:
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
Con esto hemos descomentado y agregado recepciones de logs a través de UDP y TCP, podemos permitir y discriminar solo uno de ellos o ambos, una vez descomentado o agregado, deberemos editar las reglas del firewall para permitir registros entrantes, para permitir la recepción de registros a través de la ejecución de TCP:
# ufw allow 514/tcpPara permitir la ejecución de registros entrantes a través del protocolo UDP:
# ufw allow 514/udpYa por ultimo reiniciamos el servicio rsyslog:
sudo service rsyslog restart
El siguiente paso es dirigirnos a cada uno de los servidores cliente o dispositivos Linux y habilitar la opción de enviar sus logs al servidor principal o colector.
Editamos el fichero de configuración y añadimos nuestra dirección IP como en la imagen de ejemplo: # nano /etc/rsyslog.conf
*.* @@NUESTRADIRECCIONIP:514
Tras esto salvamos los cambios y reiniciamos el servicio rsyslog:
sudo service rsyslog restartAhora si volvemos al servidor y revisamos los últimos registros de syslog dentro de /var/log, deberíamos poder observar cómo se ahora aparecen varios nombres de dispositivos además de nuestro propio servidor:
Azure Monitor es una potente herramienta de análisis y generación de informes. Maximiza la disponibilidad y el rendimiento de nuestras aplicaciones al ofrecer una solución integral para recopilar, analizar y actuar sobre la telemetría desde la nube y entornos locales. Nos ayuda por tanto a comprender el rendimiento de nuestras aplicaciones e identifica de modo proactivo los problemas que las afectan y los recursos de los que dependen, y a responder de manera proactiva a las fallas que se produzcan.
Azure Monitor recibe datos de recursos como aplicaciones, sistemas operativos, recursos de Azure, suscripciones de Azure e inquilinos de Azure. La naturaleza del recurso define qué tipos de datos están disponibles. Un tipo de datos será una métrica, un registro u ambos. Estos datos se pueden procesar luego para realizar diferentes tareas como análisis, visualización de datos, definición de alertas, automatización e integraciones.
El agente de Log Analytics para Linux viene en un conjunto de scripts de shell autoextraíbles e instalables. Este paquete contiene los paquetes Debian y RPM para cada uno de los componentes del agente y se pueden instalar directamente o extraerse para recuperar los paquetes individuales. Hay dos paquetes, uno para arquitecturas x64 y otro para arquitecturas x86.
En nuestro ejemplo instalaremos la versión para 64 bits. El primer paso será descargar la versión más reciente del agente:
wget
https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.13.40-0/omsagent-1.13.40-0.universal.x64.shAhora instalamos el paquete utilizando el argumento --install. Para incluir un área de trabajo de Log Analytics durante la instalación, proporcionamos los parámetros -w
sudo sh ./omsagent-*.universal.x64.sh --install -w
Azure Monitor admite la recopilación de mensajes enviados por rsyslog o syslog-ng, donde rsyslog es el demonio predeterminado. Tras seguir los pasos anteriores, una vez conectado nuestro servidor al Workspace de Azure Log Analytics, debemos ir al portal y habilitar la recolección de datos. Esto lo haremos desde el menú de configuración de agentes del área de trabajo.
Nota: Si estás pensando en usar Red Hat, CentOS u Oracle Linux no podrás trabajar con el demonio Sysklog para recopilar eventos de Syslog, en su lugar debes instalar primer rsyslog
De forma predeterminada, todos los cambios realizados en la configuración se insertan automáticamente en todos los agentes. Por lo que no tendremos que hacer mucho más salvo esperar un par de minutos para permitir la ingestión de datos.
Si todo es correcto podemos ver cómo se van recibiendo los datos con una simple consulta usando Kusto.
Y a partir de aquí las posibilidades son infinitas. Podemos por ejemplo, conectar nuestro WorkSpace a Azure Sentinel, otro servicio del cual hablaremos en otro artículo y que nos ayuda a detectar potenciales amenazas en nuestra infraestructura mediante el uso de algoritmos de inteligencia artificial.
Y con esto hemos llegado al final. Si te ha gustado no dudes en compartir, y si tienes alguna duda, deja tu comentario.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
