Registros de seguridad en Linux: journald, auditd y logs centralizados

Cuando algo sale mal en un servidor Linux, los registros (logs) son la forma de saber qué pasó, y los atacantes lo saben: borrar o alterar los logs es una de las primeras cosas que hace un intruso. Haga que los logs sirvan para la seguridad en cinco pasos: mantenga el journal de systemd persistente y con un límite de retención claro, mantenga el reloj de cada servidor exacto con chrony, registre los cambios sensibles con auditd (cuentas de usuario, reglas de sudo, configuración de SSH), reenvíe todo por TLS a un servidor central de logs que los servidores de aplicaciones no puedan modificar y revise una lista corta de eventos cada semana.

Los comandos siguientes aplican a Debian 12/13, Ubuntu 24.04 y RHEL/AlmaLinux 9/10 actuales.

Qué logs importan para la seguridad

No necesita leerlo todo. Estas fuentes responden la mayoría de las preguntas de seguridad:

• Autenticación: inicios de sesión SSH (exitosos y fallidos), uso de sudo, inicios de sesión en la consola local.
• Cambios de cuentas y privilegios: usuarios nuevos, cambios de contraseña, pertenencia a grupos, ediciones de las reglas de sudo.
• Cambios de configuración en SSH, el firewall, las tareas de cron y los servicios.
• Servicios: logs del servidor web, del correo y de las aplicaciones, sobre todo errores e intentos de inicio de sesión.
• Herramientas de seguridad: bloqueos de fail2ban, escáneres de malware, actualizaciones de paquetes.

Paso 1: Haga persistente el journal, con límites

En las distribuciones modernas, la mayoría de estos eventos llegan al journal de systemd. Si el journal se guarda solo en memoria, un reinicio lo borra, justo cuando quizá lo necesite.

Revise qué tiene:

ls -ld /var/log/journal          # si existe = almacenamiento persistente
journalctl --list-boots | head   # varios arranques = el historial sobrevive a los reinicios
journalctl --disk-usage

La documentación upstream de systemd indica persistent como valor predeterminado actual, mientras que versiones anteriores usaban auto (persistente solo si existe /var/log/journal). Tenga en cuenta que Debian 12 y posteriores ya no instalan rsyslog por defecto, así que el journal puede ser el único log local. Defínalo explícitamente con un archivo drop-in en lugar de editar journald.conf:

/etc/systemd/journald.conf.d/50-retention.conf:

[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=90day

sudo systemctl restart systemd-journald

SystemMaxUse limita el uso de disco (por defecto, el 10 % del sistema de archivos, hasta 4 GB) y MaxRetentionSec elimina las entradas más antiguas que la edad indicada (desactivado por defecto). Elija un periodo de retención que se ajuste a su negocio y a los requisitos regulatorios o contractuales que tenga.

Consultas útiles:

journalctl -u ssh --since "24 hours ago"      # sshd.service en RHEL
journalctl _COMM=sudo --since today
journalctl -p warning --since yesterday

Paso 2: Mantenga la hora sincronizada con chrony

Los logs de varios servidores solo sirven si sus marcas de tiempo coinciden. RHEL y AlmaLinux usan chrony por defecto; en Debian y Ubuntu, instalar chrony reemplaza al más sencillo systemd-timesyncd.

sudo apt install chrony            # Debian / Ubuntu
sudo systemctl enable --now chronyd   # RHEL / AlmaLinux (el servicio se llama "chrony" en Debian/Ubuntu)
chronyc tracking
chronyc sources -v
timedatectl

Apunte todos los servidores a las mismas fuentes de hora confiables y genere una alerta si el desfase de un servidor aumenta.

Paso 3: Registre los cambios sensibles con auditd

El sistema de auditoría de Linux (Linux Audit) registra eventos a nivel del kernel, incluido quién cambió un archivo vigilado, aunque el cambio se haya hecho con una herramienta que no deja registro por sí misma. Instálelo en Debian/Ubuntu con sudo apt install auditd; en RHEL viene instalado por defecto.

Ponga las reglas en un archivo dentro de /etc/audit/rules.d/:

/etc/audit/rules.d/50-business.rules:

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
-w /root/.ssh/ -p wa -k root_ssh
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
## Comandos ejecutados como root por usuarios reales (puede generar mucho volumen; pruébelo antes)
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k admin_cmds

-w vigila una ruta, -p wa registra escrituras y cambios de atributos, y -k agrega una clave por la que puede buscar. Cargue y verifique las reglas:

sudo augenrules --load
sudo auditctl -l

En RHEL, Red Hat indica que el comando service es la forma correcta de reiniciar auditd (sudo service auditd restart); use systemctl solo para habilitarlo o ver su estado.

Busque en los resultados:

sudo ausearch -k identity -i --start today
sudo ausearch -k sudoers -i
sudo aureport --login --summary -i

Cuando las reglas estén estables, agregar -e 2 como última regla hace que la configuración de auditoría sea inmutable hasta el siguiente reinicio, de modo que un intruso no pueda desactivarla sin que se note. Red Hat también incluye conjuntos de reglas de ejemplo en /usr/share/audit/sample-rules/, con la advertencia de que son un punto de partida, no una prueba de cumplimiento.

Paso 4: Saque los logs del servidor

Los logs que solo existen en el servidor pueden ser borrados por cualquiera que obtenga acceso root allí. Un servidor central de logs guarda una copia a la que los servidores de aplicaciones pueden enviar datos, pero que no pueden cambiar. rsyslog es la herramienta estándar y admite TLS.

Instálelo en cada cliente y en el servidor de logs. En Debian 12 y posteriores rsyslog ya no se instala por defecto; en RHEL viene instalado y lee el journal mediante su módulo imjournal.

sudo apt install rsyslog rsyslog-gnutls     # Debian / Ubuntu
sudo dnf install rsyslog rsyslog-gnutls     # RHEL / AlmaLinux

Necesitará una pequeña autoridad de certificación privada: un certificado de CA, más un certificado y una llave para el servidor de logs y para cada cliente.

Cliente: reenviar todo por TLS

/etc/rsyslog.d/90-forward.conf:

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog-tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog-tls/web01-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog-tls/web01-key.pem"
)
*.* action(type="omfwd" target="logs.example.internal" port="6514" protocol="tcp"
      StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name"
      StreamDriverPermittedPeers="logs.example.internal"
      queue.type="LinkedList" queue.filename="fwd_central"
      queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
      action.resumeRetryCount="-1")

La cola respaldada en disco guarda los mensajes si el servidor de logs no está disponible y los envía cuando vuelve. StreamDriverAuthMode="x509/name" hace que el cliente verifique que está hablando con el servidor de logs real.

Servidor de logs: recibir y guardar por equipo

/etc/rsyslog.d/10-receive.conf:

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog-tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog-tls/logs-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog-tls/logs-key.pem"
)
module(load="imtcp" StreamDriver.Name="gtls" StreamDriver.Mode="1"
       StreamDriver.AuthMode="x509/name" PermittedPeer=["*.example.internal"])
template(name="PerHost" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
ruleset(name="remote") { action(type="omfile" dynaFile="PerHost") }
input(type="imtcp" port="6514" ruleset="remote")

Valide con rsyslogd -N1, reinicie rsyslog, abra el puerto TCP 6514 solo para sus servidores y pruebe con logger "test from web01" en un cliente. En RHEL con SELinux, confirme que el puerto que usa está permitido para rsyslog (semanage port -l | grep syslog). Proteja también el propio servidor de logs: pocos administradores, sin cuentas compartidas y sin acceso SSH desde los servidores de aplicaciones.

Para enviar también los eventos de auditoría al servidor de logs, active el plugin de syslog de audit (active = yes en /etc/audit/plugins.d/syslog.conf; en algunas distribuciones viene en el paquete audispd-plugins) o haga que rsyslog lea /var/log/audit/audit.log.

Paso 5: Rote y conserve los logs

• Los logs de texto los rota logrotate. En el servidor central, agregue una regla para los archivos de cada equipo:

/etc/logrotate.d/remote-logs:

/var/log/remote/*/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl kill -s HUP rsyslog.service
    endscript
}

• auditd rota su propio log mediante max_log_file, num_logs y max_log_file_action en /etc/audit/auditd.conf.
• El journal se recorta con los límites del Paso 1.
• Respalde el servidor central de logs, como cualquier otro servidor importante.

Qué revisar cada semana

Una revisión semanal de 15 minutos detecta a tiempo la mayoría de los problemas:

1. Inicios de sesión SSH exitosos desde direcciones inesperadas o a horas inusuales.
2. Picos de inicios de sesión fallidos (SSH, correo, paneles de administración) y bloqueos de fail2ban.
3. Cualquier evento de auditoría identity, sudoers, sshd_config o root_ssh, comparado con los cambios aprobados.
4. Tareas de cron o servicios de systemd nuevos que nadie recuerda haber creado.
5. Huecos: un servidor que dejó de enviar logs es, por sí solo, una señal de alerta.
6. Desfase de hora reportado por chrony.

Si encuentra algo que no puede explicar, siga nuestra guía sobre las primeras 24 horas después de una brecha y preserve los logs antes de cambiar nada. Para el resto de la configuración base del servidor, consulte fundamentos de endurecimiento de servidores Linux.

¿Necesita ayuda para que sus logs sean útiles?

Core Florida IT configura registros, auditoría y monitoreo de servidores Linux para empresas en Miami-Dade y todo el sur de Florida, con soporte remoto en todo el país, como parte de nuestros servicios de ciberseguridad y soporte de TI administrado. Si no está seguro de que sus servidores le dirían qué pasó después de un incidente, solicite una evaluación de TI gratuita.

Fuentes

• systemd: manual de journald.conf
• Notas de la versión de Debian 12: cambios en el sistema de registro
• Red Hat Enterprise Linux 9: Auditing the system
• Red Hat Enterprise Linux 9: Configuring a remote logging solution
• Documentación de rsyslog: módulo de salida omfwd
• Documentación de rsyslog: módulo de entrada imtcp
• Documentación de chrony