--- title: "Centralizar logs con rsyslog en Ubuntu 24.04 con TLS" description: "Configura un servidor central de logs con rsyslog en Ubuntu 24.04, reenvía los logs de tus servidores por TCP con cola en disco, cífralos con TLS y rótalos." category: "Monitoring Logging" language: es source: https://cubepath.com/es/docs/monitoring-logging/envio-de-logs-a-servidor-centralizado-con-rsyslog updated: 2026-09-25 --- # Centralizar logs con rsyslog en Ubuntu 24.04 con TLS rsyslog es el demonio de syslog que Ubuntu instala por defecto. Además de escribir los logs locales en `/var/log`, puede recibir mensajes de otras máquinas y reenviar los suyos a un servidor remoto. Centralizar los logs te permite buscar en un único sitio y conservar el rastro de lo ocurrido aunque un servidor caiga o sea comprometido. En este tutorial configurarás un servidor central con rsyslog en Ubuntu 24.04 que guarda los logs de cada cliente en su propio directorio, configurarás los clientes para reenviar por TCP con una cola en disco, cifrarás el transporte con TLS y rotarás los archivos recibidos. ## Requisitos previos Para seguir esta guía necesitas: - Un servidor para centralizar los logs con Ubuntu 24.04 LTS (en los ejemplos, `logs.your_domain` con IP `log_server_ip`), por ejemplo un VPS de CubePath con espacio en disco suficiente. - Uno o más servidores cliente con Ubuntu 24.04 LTS. - Un usuario no root con privilegios `sudo` en todas las máquinas. - Si los clientes llegan al servidor por Internet y quieres usar TLS (paso 5), un registro DNS que apunte `logs.your_domain` a `log_server_ip`. Si los servidores se comunican por una red privada, puedes quedarte en TCP sin cifrar (pasos 1 a 4). Si el tráfico cruza Internet, haz también el paso 5. ## Paso 1: Comprobar rsyslog rsyslog viene instalado y activo en Ubuntu 24.04. Compruébalo en el servidor y en los clientes: ```bash systemctl status rsyslog --no-pager rsyslogd -v | head -n 1 ``` ```output ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; preset: enabled) Active: active (running) since Fri 2026-09-25 09:12:03 UTC; 2h ago rsyslogd 8.2312.0 (aka 2023.12) compiled with: ``` Si no estuviera instalado, instálalo con `sudo apt install rsyslog`. ## Paso 2: Configurar el servidor central La configuración se añade en un archivo propio dentro de `/etc/rsyslog.d/`, sin tocar `/etc/rsyslog.conf`. En el servidor, crea el directorio donde se guardarán los logs recibidos. rsyslog se ejecuta como el usuario `syslog`, que debe poder escribir en él: ```bash sudo install -d -o syslog -g adm -m 0750 /var/log/remote ``` Crea el archivo de configuración: ```bash sudo nano /etc/rsyslog.d/10-remote.conf ``` ```text module(load="imtcp") template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME:::secpath-replace%/%PROGRAMNAME:::secpath-replace%.log") ruleset(name="remote") { action(type="omfile" dynaFile="RemoteLogs" dirCreateMode="0750" fileCreateMode="0640") stop } input(type="imtcp" port="514" ruleset="remote") ``` Qué hace cada parte: - `imtcp` es el módulo que recibe syslog por TCP. TCP es preferible a UDP porque no pierde mensajes en silencio y permite TLS. - La plantilla `RemoteLogs` genera una ruta por host y programa, por ejemplo `/var/log/remote/web01/sshd.log`. La opción `secpath-replace` sustituye las barras de los valores recibidos, para que un cliente no pueda escribir fuera de `/var/log/remote`. - El `ruleset` se asocia solo a la entrada TCP, así que los mensajes remotos se escriben en su directorio y `stop` evita que acaben también en el `/var/log/syslog` del servidor. Valida la configuración antes de reiniciar: ```bash sudo rsyslogd -N1 ``` ```output rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye. ``` Reinicia rsyslog y comprueba que escucha en el puerto 514: ```bash sudo systemctl restart rsyslog sudo ss -tlnp | grep 514 ``` ```output LISTEN 0 25 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=6210,fd=6)) LISTEN 0 25 [::]:514 [::]:* users:(("rsyslogd",pid=6210,fd=7)) ``` ### Abrir el firewall solo a los clientes Cualquiera que llegue al puerto 514 puede escribir en tus logs, así que ábrelo solo a las IP de tus clientes (o a la subred privada donde están). Repite la segunda línea por cada cliente: ```bash sudo ufw allow OpenSSH sudo ufw allow from client_ip to any port 514 proto tcp sudo ufw enable sudo ufw status ``` ```output Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 514/tcp ALLOW client_ip ``` ## Paso 3: Configurar los clientes En cada cliente, crea un archivo que reenvía todos los mensajes al servidor: ```bash sudo nano /etc/rsyslog.d/90-forward.conf ``` ```text *.* action(type="omfwd" target="log_server_ip" port="514" protocol="tcp" queue.type="LinkedList" queue.filename="fwd_central" queue.maxDiskSpace="1g" queue.saveOnShutdown="on" action.resumeRetryCount="-1") ``` Los parámetros de cola son la parte importante: - `queue.type="LinkedList"` con `queue.filename` crea una cola asistida por disco: si el servidor central no está disponible, los mensajes se guardan en `/var/spool/rsyslog` en vez de perderse. - `queue.maxDiskSpace="1g"` limita cuánto disco puede ocupar esa cola. - `queue.saveOnShutdown="on"` conserva los mensajes pendientes si el cliente se reinicia. - `action.resumeRetryCount="-1"` reintenta indefinidamente hasta que el servidor vuelve. Los logs locales siguen escribiéndose en `/var/log` como siempre; esta acción solo añade una copia remota. Si prefieres reenviar solo una parte, sustituye `*.*` por un selector. Por ejemplo, solo autenticación y mensajes de aviso o más graves: ```text auth,authpriv.*;*.warning action(type="omfwd" target="log_server_ip" port="514" protocol="tcp" queue.type="LinkedList" queue.filename="fwd_central" queue.maxDiskSpace="1g" queue.saveOnShutdown="on" action.resumeRetryCount="-1") ``` Valida y reinicia: ```bash sudo rsyslogd -N1 sudo systemctl restart rsyslog ``` ## Paso 4: Probar el reenvío En un cliente, genera un mensaje con `logger`, que escribe en syslog con la etiqueta que le indiques: ```bash logger -t prueba-central "Mensaje de prueba desde $(hostname)" ``` En el servidor, comprueba que ha aparecido un directorio con el nombre del cliente y el archivo de esa etiqueta: ```bash sudo ls /var/log/remote/ sudo tail -n 1 /var/log/remote/web01/prueba-central.log ``` ```output web01 2026-09-25T11:32:18.402113+00:00 web01 prueba-central: Mensaje de prueba desde web01 ``` Sustituye `web01` por el nombre de tu cliente. Con el tiempo verás un archivo por programa (`sshd.log`, `sudo.log`, `CRON.log`, `systemd.log`...). Para comprobar que la cola funciona, detén rsyslog en el servidor, envía varios mensajes desde el cliente y vuelve a arrancarlo. Los mensajes aparecerán en unos segundos, cuando el cliente reintente la conexión. ## Paso 5: Cifrar el transporte con TLS syslog por TCP viaja en texto plano, y los logs contienen nombres de usuario, IP y rutas internas. Si el tráfico cruza Internet, cífralo con el controlador TLS de rsyslog (`gtls`, basado en GnuTLS). Instala el módulo en el servidor y en todos los clientes: ```bash sudo apt install rsyslog-gnutls ``` ### Crear una CA y el certificado del servidor Crearás una pequeña CA propia que firma el certificado del servidor. Los clientes solo necesitan el certificado de la CA para comprobar que hablan con tu servidor. Hazlo en el servidor central, en un directorio de trabajo: ```bash mkdir ~/rsyslog-ca && cd ~/rsyslog-ca openssl req -x509 -newkey rsa:4096 -nodes -days 3650 \ -keyout ca-key.pem -out ca.pem -subj "/CN=rsyslog CA" openssl req -newkey rsa:4096 -nodes \ -keyout server-key.pem -out server.csr -subj "/CN=logs.your_domain" openssl x509 -req -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial \ -out server-cert.pem -days 825 \ -extfile <(printf "subjectAltName=DNS:logs.your_domain") ``` Guarda `ca-key.pem` en un lugar seguro: con ella se pueden firmar certificados en los que confiarán tus clientes. Instala los archivos en `/etc/rsyslog.d/tls/`. En Ubuntu 24.04 rsyslog tiene un perfil de AppArmor activo que le permite leer `/etc/rsyslog.d/`, pero no directorios arbitrarios de `/etc`. La clave debe poder leerla el grupo `syslog`: ```bash sudo install -d -m 0750 -o root -g syslog /etc/rsyslog.d/tls sudo install -m 0644 ca.pem server-cert.pem /etc/rsyslog.d/tls/ sudo install -m 0640 -o root -g syslog server-key.pem /etc/rsyslog.d/tls/ ``` rsyslog solo carga los archivos `*.conf` de `/etc/rsyslog.d/`, así que los `.pem` del subdirectorio no se interpretan como configuración. ### Configurar el servidor Sustituye el contenido de `/etc/rsyslog.d/10-remote.conf` para escuchar con TLS en el puerto estándar 6514: ```bash sudo nano /etc/rsyslog.d/10-remote.conf ``` ```text global( DefaultNetstreamDriver="gtls" DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem" DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem" DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem" ) module(load="imtcp" StreamDriver.Name="gtls" StreamDriver.Mode="1" StreamDriver.AuthMode="anon") template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME:::secpath-replace%/%PROGRAMNAME:::secpath-replace%.log") ruleset(name="remote") { action(type="omfile" dynaFile="RemoteLogs" dirCreateMode="0750" fileCreateMode="0640") stop } input(type="imtcp" port="6514" ruleset="remote") ``` `StreamDriver.Mode="1"` exige TLS en todas las conexiones. Con `AuthMode="anon"` el servidor no pide certificado a los clientes; su identidad la sigues controlando con el firewall. Valida, reinicia y cambia la regla de UFW del puerto 514 al 6514: ```bash sudo rsyslogd -N1 sudo systemctl restart rsyslog sudo ufw allow from client_ip to any port 6514 proto tcp sudo ufw delete allow from client_ip to any port 514 proto tcp ``` ### Configurar los clientes Copia `ca.pem` a cada cliente (por ejemplo con `scp`) e instálalo en el mismo directorio: ```bash sudo install -d -m 0755 /etc/rsyslog.d/tls sudo install -m 0644 ca.pem /etc/rsyslog.d/tls/ ``` Sustituye `/etc/rsyslog.d/90-forward.conf` por esta versión, que usa el nombre DNS del servidor: ```bash sudo nano /etc/rsyslog.d/90-forward.conf ``` ```text global(DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem") *.* action(type="omfwd" target="logs.your_domain" port="6514" protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logs.your_domain" queue.type="LinkedList" queue.filename="fwd_central" queue.maxDiskSpace="1g" queue.saveOnShutdown="on" action.resumeRetryCount="-1") ``` `x509/name` hace que el cliente compruebe que el certificado del servidor está firmado por tu CA y que su nombre es `logs.your_domain`, así que nadie puede suplantar al servidor. Valida, reinicia y repite la prueba del paso 4: ```bash sudo rsyslogd -N1 sudo systemctl restart rsyslog logger -t prueba-tls "Mensaje cifrado desde $(hostname)" ``` En el servidor, el mensaje debe aparecer en `/var/log/remote//prueba-tls.log`. ## Paso 6: Rotar los logs recibidos Los logs centralizados crecen rápido. Configura logrotate en el servidor para rotarlos a diario, comprimirlos y conservar 30 días: ```bash sudo nano /etc/logrotate.d/remote-logs ``` ```text /var/log/remote/*/*.log { daily rotate 30 compress delaycompress missingok notifempty sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript } ``` `/usr/lib/rsyslog/rsyslog-rotate` es el mismo script que usa la rotación de los logs locales de Ubuntu: indica a rsyslog que cierre y vuelva a abrir sus archivos. Simula la rotación para comprobar que la configuración es válida: ```bash sudo logrotate --debug /etc/logrotate.d/remote-logs ``` ```output rotating pattern: /var/log/remote/*/*.log after 1 days (30 rotations) empty log files are not rotated, old logs are removed considering log /var/log/remote/web01/prueba-central.log Now: 2026-09-25 11:45 Last rotated at 2026-09-25 11:00 log does not need rotating (log has already been rotated) ``` El modo `--debug` no modifica nada; lo importante es que lista tus archivos y no muestra errores. El temporizador `logrotate.timer` de Ubuntu ejecuta la rotación una vez al día, no necesitas añadir nada a cron. ## Solución de problemas **No llega nada al servidor.** Desde el cliente, comprueba que el puerto es accesible con `nc -vz log_server_ip 514` (o 6514 con TLS). Si falla, revisa UFW en el servidor. En el cliente, `sudo journalctl -u rsyslog -n 50` muestra los errores de conexión del `omfwd`. **`Permission denied` al crear archivos en `/var/log/remote`.** El directorio debe pertenecer a `syslog`. Corrígelo con `sudo chown syslog:adm /var/log/remote`. **Errores de TLS como `certificate invalid` o `peer name not authorized`.** El nombre en `target` y `StreamDriverPermittedPeers` debe coincidir con el `subjectAltName` del certificado del servidor. Revisa el certificado con `openssl x509 -in server-cert.pem -noout -ext subjectAltName`. **rsyslog no puede leer los certificados.** Busca denegaciones de AppArmor con `sudo journalctl -k | grep -i 'apparmor="DENIED"'`. Si guardas los certificados fuera de `/etc/rsyslog.d/`, añade una regla de lectura en `/etc/apparmor.d/local/usr.sbin.rsyslogd` y recarga el perfil con `sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.rsyslogd`. **El nombre del directorio es una IP en lugar del nombre del cliente.** `%HOSTNAME%` es el nombre que el cliente pone en el mensaje. Si prefieres identificar a cada cliente por su IP de origen, usa `%FROMHOST-IP%` en la plantilla. ## Conclusión Tus servidores ya envían sus logs a un servidor central por TCP, con una cola en disco que evita perder mensajes si el servidor no está disponible, cifrados con TLS y con rotación automática en destino. Cada cliente tiene su directorio, lo que facilita buscar con `grep` o seguir un servicio con `tail -f`. Como siguientes pasos puedes analizar los logs centralizados con `awk`, `grep` y `sed`, enviarlos además a Elasticsearch con Logstash para búsquedas y paneles, o crear alertas por correo cuando aparezcan patrones concretos, como muchos intentos fallidos de SSH.