Cómo centralizar registros con Journald en Debian 10

El autor seleccionó el Fondo de Código Libre y Abierto para recibir una donación como parte del programa Write for DOnations.

Introducción

Los registros del sistema son un componente extremadamente importante para la administración de sistemas Linux. Proporcionan una valiosa perspectiva sobre cómo funcionan los sistemas y también sobre cómo se utilizan, ya que, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para los sistemas Linux es almacenar sus registros localmente en el mismo sistema en el que se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema a medida que aumenta la cantidad 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 dedicado.

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

• Reduce la cantidad de espacio en disco necesario en cada host para almacenar archivos de registro.
• Los registros se pueden conservar durante más tiempo ya que el servidor de registro dedicado se puede configurar con más capacidad de almacenamiento.
• Se puede realizar un análisis de registros avanzado que requiere registros de múltiples sistemas y también más recursos computacionales de los que pueden estar disponibles en los hosts.
• Los administradores de sistemas pueden acceder a los registros de todos sus sistemas a los que no puedan iniciar sesión directamente por razones de seguridad.

En esta guía, configurará un componente del conjunto de herramientas systemd para retransmitir mensajes de registro desde sistemas 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 a medida que se transmiten a través de redes inseguras, como Internet, y también para autenticarse entre sí.

Prerrequisitos

Antes de comenzar esta guía necesitarás lo siguiente:

• Dos servidores Debian 10.
• Un usuario no root con privilegios sudo en ambos servidores. Siga la guía Configuración inicial del servidor con Debian 10 para obtener instrucciones sobre cómo hacerlo. También debe 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 recopilación de registros . Aprenda a apuntar nombres de host a los Droplets de DigitalOcean consultando la documentación de Dominios y DNS.

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

• client.your_domain:El sistema cliente que genera los registros.
• server.your_domain:El servidor de recopilación de registros.

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

Nota : A lo largo del tutorial, los bloques de comando están etiquetados con el nombre del servidor ( cliente o servidor ) en el que se debe ejecutar el comando.

Paso 1 — Instalaciónsystemd-journal-remote

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

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

Cliente y servidor

sudo apt update
sudo apt upgrade

A continuación, instale el systemd-journal-remotepaquete:

Cliente y servidor

sudo apt install systemd-journal-remote

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

Servidor

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

La --nowopción del primer comando inicia los servicios inmediatamente. No la usaste en el segundo comando porque este servicio no se iniciará hasta que tenga certificados TLS, que crearás en el siguiente paso.

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

Cliente

sudo systemctl enable systemd-journal-upload.service

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

Servidor

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

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

Cliente

sudo ufw allow in 80/tcp

Ya ha instalado los componentes necesarios y ha completado la configuración básica del sistema en el cliente y el servidor. Antes de poder configurar estos componentes para que comiencen a transmitir mensajes de registro, deberá registrar los certificados TLS de Let's Encrypt para el cliente y el servidor mediante la certbotutilidad.

Paso 2: Instalación de Certbot y registro de certificados

Let's Encrypt es una autoridad de certificación que emite certificados TLS gratuitos. Estos certificados permiten a los equipos cifrar los datos que se envían entre ellos y también verificar la identidad de los demás. Estos certificados son los que le permiten proteger su navegación por Internet con HTTPS. Los mismos certificados pueden ser utilizados por cualquier otra aplicación que desee el mismo nivel de seguridad. El proceso de registro del certificado es el mismo sin importar para qué los use.

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

Primero, instale certbotla curlutilidad en ambos hosts:

Cliente y servidor

sudo apt install certbot curl

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

Cliente y servidor

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

Las opciones de este comando significan lo siguiente:

• certonly:Registre el certificado y no realice ningún otro cambio en el sistema.
• --standalone:Utilice el servidor web integrado de certbot para verificar la solicitud de certificado.
• --agree-tos:Acepta automáticamente los Términos de servicio de Let's Encrypt.
• --email your-email:Esta es la dirección de correo electrónico que Let's Encrypt utilizará 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. Debe coincidir con el sistema en el que lo ejecuta.

Cuando ejecute este comando, se le preguntará si desea compartir la dirección de correo electrónico con Let's Encrypt para que puedan enviarle noticias y otra información sobre su trabajo. Hacer esto es opcional. Si no comparte su dirección de correo electrónico, el registro del certificado se completará de manera normal.

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

Por último, debe descargar una copia de los certificados CA e intermedios de Let's Encrypt y colocarlos en el mismo archivo. journaldUtilizará este archivo para verificar la autenticidad de los certificados en el cliente y el servidor cuando se comuniquen entre sí.

El siguiente comando descargará los dos certificados del sitio web Let's Encrypt y los colocará en un solo archivo llamado letsencrypt-combined-certs.pemen el directorio de inicio de su usuario.

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

Cliente y servidor

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:

Cliente y servidor

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

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

Paso 3: Configuración del servidor

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

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

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

A continuación, descomente todas las líneas debajo de la [Remote]sección y configure las rutas para que apunten a los archivos TLS que acaba de crear:

/etc/systemd/journal-remote.conf

[Remote]Seal=falseSplitMode=hostServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pemServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pemTrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

Estas son las opciones que has utilizado aquí:

• Seal=false: Firme los datos de registro en el diario. Habilite esta opción si necesita máxima seguridad; de lo contrario, puede dejarla como false.
• SplitMode=host:Los registros de los clientes remotos se dividirán por host en /var/log/journal/remote. Si prefiere que todos los registros se agreguen a un solo archivo, configure esto en SplitMode=false.
• ServerKeyFile:El archivo de clave privada del servidor.
• ServerCertificateFile:El archivo de certificado del servidor.
• TrustedCertificateFile:El archivo que contiene los certificados CA de Let's Encrypt.

Ahora, debe cambiar los permisos en los directorios Let's Encrypt que contienen los certificados y la clave para que systemd-journal-remotepuedan leerlos y usarlos.

Primero, cambie los permisos para que el certificado y la clave privada sean legibles:

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

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

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

Ya puedes empezar systemd-journal-remote:

sudo systemctl start systemd-journal-remote.service

Su servidor de recopilación de registros ya está en funcionamiento y listo para comenzar a aceptar mensajes de registro de un cliente . En el siguiente paso, configurará el cliente para que retransmita los registros a su servidor de recopilación .

Paso 4: Configuración del cliente

En este paso, configurará el componente que retransmite los mensajes de registro al servidor de recopilación de registros. Este componente se denomina systemd-journal-upload.

La configuración predeterminada systemd-journal-uploades que se utiliza un usuario temporal que solo existe mientras se ejecuta el proceso. Esto hace que systemd-journal-uploadsea más complicado permitir la lectura de los certificados y claves TLS. Para resolver esto, deberá crear un nuevo usuario del sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

Primero, crea el nuevo usuario llamado systemd-journal-uploaden el cliente con el siguiente addusercomando:

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

Estas opciones para el comando son:

• --system: Cree el nuevo usuario como usuario del sistema. Esto le otorga al usuario un número UID (identificador de usuario) en 1000. Los UID en , 1000por lo general, se asignan a las cuentas de usuario que un humano usará para iniciar sesión.
• --home /run/systemd:Establecer /run/systemdcomo directorio de inicio para este usuario.
• --no-create-home:No cree el conjunto de directorios de inicio, ya que ya existe.
• --disabled-login:El usuario no puede iniciar sesión en el servidor a través de, por ejemplo, SSH.
• --group:Crea un grupo con el mismo nombre que el usuario.

A continuación, configure los permisos y la propiedad de los archivos del 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 de systemd-journal-upload, que se encuentra en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

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

Edite este archivo para que se parezca al siguiente:

/etc/systemd/journal-upload.conf

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

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

sudo systemctl restart systemd-journal-upload.service

Su cliente ya está configurado y funcionando y está enviando sus mensajes de registro al servidor de recopilación de registros. En el siguiente paso, comprobará que los registros se están enviando y registrando correctamente.

Paso 5: Prueba del cliente y del servidor

En este paso, probará que el cliente esté retransmitiendo mensajes de registro al servidor y que el servidor los esté almacenando correctamente.

El servidor de recopilación de registros almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reiniciaste el cliente al final del último paso, comenzó a enviar mensajes de registro, por lo que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo tendrá el nombre del nombre de host que usaste para el certificado TLS.

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

Servidor

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

Esto imprimirá el contenido del directorio mostrando el archivo de registro:

Outputtotal 16620drwxr-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. Utilizará la utilidad de registro para crear un mensaje de registro personalizado en el cliente . Si todo funciona, systemd-journal-uploadretransmitirá este mensaje al servidor .

En el cliente ejecute el siguiente loggercomando:

Cliente

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

En -p syslog.debugeste comando se establece la facilidad y la gravedad del mensaje. Si se establece en , syslog.debugse aclarará que se trata de un mensaje de prueba. Este comando registrará el mensaje en el diario del cliente, que luego lo retransmitirá al servidor .### TEST MESSAGE from client.your_domain ###systemd-journal-upload

A continuación, lea el archivo de registro del cliente en el servidor para comprobar que los mensajes de registro llegan desde el cliente . Este archivo es un archivo de registro binario, por lo que no podrá leerlo con herramientas como less. En su lugar, lea el archivo utilizando journalctlla --file=opción que le permite especificar un archivo de registro personalizado:

Servidor

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

El mensaje de registro aparecerá de la siguiente manera:

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

Su servidor de centralización de registros ahora está recopilando exitosamente registros de su sistema cliente.

Conclusión

En este artículo, se configura un servidor de recopilación central de registros y un cliente para retransmitir una copia de sus registros del sistema al servidor. Puede configurar tantos clientes como necesite para retransmitir mensajes al servidor de recopilación de registros mediante los pasos de configuración de clientes que utilizó aquí.