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:

systemctl status rsyslog --no-pager
rsyslogd -v | head -n 1

● 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:

sudo install -d -o syslog -g adm -m 0750 /var/log/remote

Crea el archivo de configuración:

sudo nano /etc/rsyslog.d/10-remote.conf

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:

sudo rsyslogd -N1

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:

sudo systemctl restart rsyslog
sudo ss -tlnp | grep 514

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:

sudo ufw allow OpenSSH
sudo ufw allow from client_ip to any port 514 proto tcp
sudo ufw enable
sudo ufw status

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:

sudo nano /etc/rsyslog.d/90-forward.conf

*.* 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:

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:

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:

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:

sudo ls /var/log/remote/
sudo tail -n 1 /var/log/remote/web01/prueba-central.log

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:

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:

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:

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:

sudo nano /etc/rsyslog.d/10-remote.conf

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:

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:

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:

sudo nano /etc/rsyslog.d/90-forward.conf

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:

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/<cliente>/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:

sudo nano /etc/logrotate.d/remote-logs

/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:

sudo logrotate --debug /etc/logrotate.d/remote-logs

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.