Recolección centralizada de logs de sistema mediante jouranld
- Francisco Javier Huete
- Administracion sistemas
- January 27, 2025
Índice
Para configurar un servidor de journald en la red local es necesario que todos los equipos de la red cuenten con el componente systemd-journal-remote instalado. Este componente de systemd permite a los diferentes nodos de la red interactuar entre sí y trasladar la información relativa a los logs del sistema desde los clientes al servidor de logs.
Con esta herramienta cliente y servidor establecen una comunicación usando HTTP o HTTPS para transferir los ficheros de log desde los clientes al servidor. El servidor se puede configurar en modo activo para que solicite periódicamente los logs a los clientes de la red o en modo pasivo para que reciba los logs cada vez que los clientes los envíen.
En este caso, se configura un cliente y un servidor en modo activo que usan HTTP para centralizar el registro de logs de la red.
Configuración de journald usando HTTP
Configuración del cliente
Para que un equipo de una red local pueda funcionar como cliente de un servidor de logs necesita tener instalada la utilidad systemd-journal-upload, que se incluye en el paquete systemd-journal-remote.
sudo apt update
sudo apt install systemd-journal-remote
En el fichero /etc/systemd/journal-upload.conf se configura la dirección IP del servidor de logs, así como el puerto de escucha del servidor para recibir los ficheros de journald de los clientes que, por defecto, es el 19532.
[Upload]
URL=http://10.0.0.157:19532
Para poner en funcionamiento el cliente hay que arrancar el servicio.
sudo systemctl start systemd-journal-upload.service
Este servicio se puede hacer persistente a los reinicios del sistema habilitando su ejecución durante el arranque.
sudo systemctl enable systemd-journal-upload.service
Configuración del servidor
En el servidor también hay que instalar el componente de systemd que permite centralizar el registro de logs de los equipos de la red a través de journald.
sudo apt update
sudo apt install systemd-journal-remote
Como se puede ver en el fichero /lib/systemd/system/systemd-journal-remote.socket, el puerto de escucha configurado por defecto es el 19532.
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Journal Remote Sink Socket
[Socket]
ListenStream=19532
[Install]
WantedBy=sockets.target
La configuración por defecto del servicio systemd-journal-remote se recoge en el fichero cat /lib/systemd/system/systemd-journal-remote.service.
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Journal Remote Sink Service
Documentation=man:systemd-journal-remote(8) man:journal-remote.conf(5)
Requires=systemd-journal-remote.socket
[Service]
ExecStart=/lib/systemd/systemd-journal-remote --listen-https=-3 --output=/var/log/journal/remote/
LockPersonality=yes
LogsDirectory=journal/remote
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateNetwork=yes
PrivateTmp=yes
ProtectProc=invisible
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
User=systemd-journal-remote
WatchdogSec=3min
# If there are many split up journal files we need a lot of fds to access them
# all in parallel.
LimitNOFILE=524288
[Install]
Also=systemd-journal-remote.socket
Para configurar el servicio para que use HTTP en vez de HTTPS se debe cambiar la opción --listen-https=-3 del comando indicado en el parámetro ExecStart del servicio por la opción --listen-http=-3. Sin embargo es conveniente no editar directamente este fichero, sino hacer una copia en otra ubicación para mantener la integridad del fichero original con la configuración del servicio por defecto.
sudo cp /lib/systemd/system/systemd-journal-remote.service /etc/systemd/system/systemd-journal-remote.service
La copia del fichero se puede modificar para adaptar las opciones por defecto.
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Journal Remote Sink Service
Documentation=man:systemd-journal-remote(8) man:journal-remote.conf(5)
Requires=systemd-journal-remote.socket
[Service]
ExecStart=/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/
LockPersonality=yes
LogsDirectory=journal/remote
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateNetwork=yes
PrivateTmp=yes
ProtectProc=invisible
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
User=systemd-journal-remote
WatchdogSec=3min
# If there are many split up journal files we need a lot of fds to access them
# all in parallel.
LimitNOFILE=524288
[Install]
Also=systemd-journal-remote.socket
Por último, se puede habilitar y activar el servicio para que el servidor empiece a recibir los logs de los equipos de la red.
sudo systemctl enable systemd-journal-remote.service
sudo systemctl start systemd-journal-remote.service
El componente systemd-journal-remote genera en el directorio configurado en el fichero de configuración de la unidad de systemd un fichero de log para cada cliente de la red.
debian@debian12:~$ ls -l /var/log/journal/remote/
total 24580
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 25165824 Jan 17 09:09 remote-10.0.0.57.journal
Para ver el contenido de los logs se puede usar el comando journalctl que permite leer los logs de un fichero o directorio.
Configuración de journald usando HTTPS
Para configurar un servidor de recolección centralizada de logs usando journald a través de HTTPS es necesario contar con una autoridad certificadora que firme los certificados tanto del servidor como de los clientes cuyos ficheros de log recolecta.
Creación y firma de certificados
Para la creación y firma de los certificados se usa la herramienta Easy-RSA. Esta herramienta se instala desde los repositorios de Debian con el paquete easy-rsa.
apt update
apt install easy-rsa
Para poder configurar la Autoridad Certificadora se parte del fichero /usr/share/easy-rsa/vars.example.
cp /usr/share/easy-rsa/vars.example /usr/share/easy-rsa/vars
En este fichero se editan los campos necesarios para cumplimentar la información tanto de la Autoridad Certificadora como de los diferentes certificados de cada una de las máquinas del escenario.
set_var EASYRSA_REQ_COUNTRY "ES"
set_var EASYRSA_REQ_PROVINCE "Andalucia"
set_var EASYRSA_REQ_CITY "Dos Hermanas"
set_var EASYRSA_REQ_ORG "JaviHueteCA"
A continuación, la herramienta Easy-RSA permite inicializar un nuevo directorio de la Autoridad Certificadora en el que se trabajará para generar y firmar de forma sencilla los diferentes certificados necesarios, así como crear la Autoridad Certificadora a partir de la configuración especificada.
./easyrsa init-pki
./easyrsa build-ca
Tanto el servidor, luffy como cada cliente necesitan una clave privada y un certificado. La solicitud de certificados también se puede generar con Easy-RSA. Para evitar problemas de desencriptación de la clave privada en la configuración tanto de los clientes como del servidor de recolección de ficheros de log, las solicitudes de certificado se generan con la opción nopass, que crea una clave privada sin frase de paso a la que systemd podrá acceder sin problema para identificar a los clientes frente al servidor y viceversa de forma segura.
./easyrsa gen-req luffy nopass
./easyrsa gen-req nami nopass
./easyrsa gen-req sanji nopass
./easyrsa gen-req zoro nopass
Esta misma herramienta también facilita la firma de estos certificados por parte de la CA.
./easyrsa sign-req server luffy
./easyrsa sign-req server nami
./easyrsa sign-req server sanji
./easyrsa sign-req server zoro
Tras firmar los certificados, cada máquina del escenario debe contar con los siguientes ficheros:
- El certificado autofirmado de la Autoridad Certificadora (cacert.pem)
- Una clave privada (máquina.key)
- Un certificado firmado por la CA (máquita.crt)
Estos ficheros se pasan desde el equipo en el que se han creado y firmado, en este caso el servidor luffy, al resto de equipos de la red.
scp pki/ca.crt usuario@nami:/home/usuario
scp pki/ca.crt usuario@sanji:/home/usuario
scp pki/ca.crt usuario@zoro:/home/usuario
scp pki/private/nami.key usuario@nami:/home/usuario
scp pki/private/sanji.key usuario@sanji:/home/usuario
scp pki/private/zoro.key usuario@zoro:/home/usuario
scp pki/issued/nami.crt usuario@nami:/home/usuario
scp pki/issued/sanji.crt usuario@nami:/home/usuario
scp pki/issued/zoro.crt usuario@zoro:/home/usuario
En el servidor, se recomienda ubicar estos ficheros en el directorio /etc/ssl/. En él, la clave se guarda en el directorio private/ y los certificados, tanto del servidor como de la CA en el directorio certs/.
cp pki/ca.crt /etc/ssl/certs/
cp pki/private/luffy.key /etc/ssl/certs/
cp pki/issued/luffy.crt /etc/ssl/private/
Configuración del servidor
En este escenario, luffy funciona como servidor de logs para el resto de máquinas de la red. Así, la configuración del servidor se realiza en esta máquina. En el servidor hay que instalar el componente de systemd que permite centralizar el registro de logs de los equipos de la red a través de journald.
sudo apt update
sudo apt install systemd-journal-remote
En el fichero /lib/systemd/system/systemd-journal-remote.socket se define el puerto de escucha del servidor. En este caso, el 19532, el puerto de escucha por defecto.
[Socket]
ListenStream=19532
Igualmente, en el fichero /lib/systemd/system/systemd-journal-remote.service se recoge la configuración del servicio. Como en este escenario los clientes deben usar HTTPS para enviar sus logs al servidor, en este fichero de configuración el parámetro ExecStart debe incluir la opción --listen-https=-3.
[Service]
ExecStart=/lib/systemd/systemd-journal-remote --listen-https=-3 --output=/var/log/journal/remote/
Finalmente, para configurar la conexión HTTPS entre el servidor y los clientes se edita el fichero /etc/systemd/journal-remote.conf en el que hay que indicar la ruta a los ficheros del certificado tanto de la CA como del servidor, junto a la ruta a la clave privada del servidor.
[Remote]
# Seal=false
# SplitMode=host
ServerKeyFile=/etc/ssl/private/luffy.key
ServerCertificateFile=/etc/ssl/certs/luffy.crt
TrustedCertificateFile=/etc/ssl/certs/ca.crt
Para garantizar el correcto funcionamiento del servidor es necesario verificar que el usuario systemd-journal-remote puede acceder a los certificados y la clave privada. En este caso, ha sido necesario cambiar el grupo de los certificados y el propietario del directorio /etc/ssl/private en el que está la clave privada.
chown root:systemd-journal-remote /etc/ssl/certs/luffy.crt
chown root:systemd-journal-remote /etc/ssl/certs/ca.crt
chown -R systemd-journal-remote: /etc/ssl/private
Para aplicar la configuración se reinicia el servicio y para hacer que se ejecuta tras cada reinicio de la máquina, se habilita.
systemctl start systemd-journal-remote.service
systemctl enable systemd-journal-remote.service
Configuración de los clientes
Para que el resto de equipos de la red pueda funcionar como clientes del servidor de logs necesita tener instalada la utilidad systemd-journal-upload, que se incluye en el paquete systemd-journal-remote.
sudo apt update
sudo apt install systemd-journal-remote
La configuración de los clientes del escenario es mucho más sencilla. El fichero de configuración más relevante es /etc/systemd/journal-upload.conf, que recoge la dirección del servidor al que los clientes deben enviar los logs junto al puerto de escucha configurado en el servidor. Además, en esta configuración también se apunta a los certificados, tanto del cliente como de la Autoridad Certificadora, así como a la clave privada del cliente.
[Upload]
URL=https://luffy.javi.gonzalonazareno.org:19532
ServerKeyFile=/etc/ssl/private/nami.key
ServerCertificateFile=/etc/ssl/certs/nami.crt
TrustedCertificateFile=/etc/ssl/certs/ca.crt
Para que el servicio se puede ejecutar correctamente, es necesario establecer una pequeña modificación en el fichero de la unidad de systemd que define el servicio. En /lib/systemd/system/systemd-journal-upload.service se cambia el parámetro DynamicUser a no y en el parámetro User hay que corregir el usuario de systemd-journal-upload, que no se instala al instalar el paquete a systemd-journal-remote.
[Service]
DynamicUser=no
...
User=systemd-journal-remote
Otra alternativa para solucionar este error es crear el usuario systemd-journal-upload sin permisos para iniciar sesión.
Además, es fundamental que el usuario que ejecuta el servicio, en este caso systemd-journal-remote, tenga los permisos necesarios para acceder a todos los ficheros a los que se apunta desde la configuración.
chown systemd-journal-remote: /etc/ssl/certs/zoro.crt
chown systemd-journal-remote: /etc/ssl/certs/ca.crt
chown -R systemd-journal-remote: /etc/ssl/private
La misma configuración se replica en el resto de clientes de la red, de manera que, una vez que se ha configurado el servicio tanto en el servidor como en todos los clientes el directorio configurado en el servidor para almacenar los logs de la red contiene un fichero de log para cada uno de los clientes.
usuario@luffy:~$ ls -l /var/log/journal/remote/
total 40972
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 16777216 Jan 24 18:01 remote-172.16.0.200.journal
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 16777216 Jan 24 18:17 remote-192.168.0.2.journal
-rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jan 24 19:00 remote-192.168.0.3.journal
Comprobación del funcionamiento
Para verificar que los clientes envían correctamente sus registros de log al servidor se genera un mensaje manualmente usando la herramienta logger desde uno de ellos.
logger
Mensaje escrito manualmente
En el servidor se leen los ficheros de log registrados.
journalctl -D /var/log/journal/remote/
Y, entre los logs recibidos, aparece el mensaje escrito en los logs del cliente.
|
|
Fuentes
How To Centralize Logs With Journald on Debian 10
How to configure systemd journal-remote?
Introduction to the Systemd journal