Cómo centralizar los registros con Journald en Debian 10

El autor seleccionó Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

Introducción

Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas, así como sobre cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envíe sus registros en tiempo real a un servidor de administración de registros específico.

Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

• Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
• Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
• Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que pueden estar disponible en los hosts.
• Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que quizás no acceden directamente por razones de seguridad.

En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

Requisitos previos

Para completar esta guía, necesitará lo siguiente:

• Dos servidores Debian 10.
• Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Debian 10 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
• Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

Esta guía utilizará los dos nombres de host siguientes:

• client.your_domain: el sistema de cliente que genera los registros.
• server.your_domain: el servidor de compilación de registro.

Inicie sesión tanto en el cliente como en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

Paso 1: Instalar systemd-journal-remote

En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

Primero, tanto en el cliente como en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

sudo apt update
sudo apt upgrade

A continuación, instale el paquete systemd-journal-remote:

sudo apt install systemd-journal-remote

En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl enable systemd-journal-remote.service

La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

sudo systemctl enable systemd-journal-upload.service

A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

sudo ufw allow in 19532/tcp
sudo ufw allow in 80/tcp

En el cliente, solo deberá abrir el puerto 80 con este comando:

sudo ufw allow in 80/tcp

Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

Paso 2: Instalar certificados de registro y Certbot

Let’s Encrypt es una Autoridad de certificados que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

Primero, instale certbot y la utilidad curl en ambos hosts:

sudo apt install certbot curl

Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

Las opciones de este comando significan lo siguiente:

• certonly: registra el certificado y no se realizan otros cambios en el sistema.
• --standalone: se utilizar el servidor web integrado de certbot para verificar la solicitud de certificado.
• --agree-tos: se aceptan de forma automática los Términos de uso de Let’s Encrypt.
• --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
• -d your_domain: el nombre de host para el que se registrará el certificado. Esto debe coincidir con el sistema donde lo ejecuta.

Cuando ejecute este comando, se le preguntará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional; si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

Por último, deberá descargar una copia de los certificados CA Let’s Encrypt y de nivel intermedio y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen unos con otros.

El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

Paso 3: Configuración del servidor

En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

sudo nano /etc/systemd/journal-remote.conf

A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

Aquí están las opciones que ha utilizado:

• Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
• SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
• ServerKeyFile: el archivo de clave privada del servidor.
• ServerCertificateFile: el archivo de certificado del servidor.
• TrustedCertificateFile: el archivo que contiene los certificados Let’s Encrypt CA.

Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

Ahora puede iniciar systemd-journal-remote:

sudo systemctl start systemd-journal-remote.service

Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

Paso 4: Configurar el cliente

En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

Estas opciones al comando son:

• --system: crea el nuevo usuario como un usuario de sistema. Esto le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
• --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
• --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
• --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
• --group: crea un grupo con el mismo nombre que el usuario.

A continuación, establezca los permisos y la propiedad de los archivos de certificado Let’s Encrypt:

sudo chmod 0755 /etc/letsencrypt/{live,archive}
sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

sudo nano /etc/systemd/journal-upload.conf

Edite este archivo de forma que tenga el siguiente aspecto:

[Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

sudo systemctl restart systemd-journal-upload.service

Ahora su cliente está configurado y ejecutado, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que los registros se están enviando de forma correcta.

Paso 5: Probar el cliente y el servidor

En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente e al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo se llamará como el nombre de host que utilizó para el certificado TLS.

Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

sudo ls -la /var/log/journal/remote/

Esto imprimirá el contenido del directorio que muestra el archivo de registro:

Output
total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

En el cliente ejecute el siguiente comando logger:

sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

El mensaje de registro aparecerá como se muestra:

Test log message
. . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

Conclusión

En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.