Introducción
En cualquier sistema Linux el registro de eventos es fundamental para monitorizar el comportamiento, diagnosticar problemas y asegurar la integridad del entorno. El mecanismo más tradicional y ampliamente adoptado es el sistema syslog, que centraliza los mensajes generados por el kernel, los servicios y las aplicaciones en un formato estructurado.
¿Qué es syslog?
Syslog es un protocolo y un conjunto de herramientas diseñados para capturar, clasificar y almacenar eventos de sistema. Cada mensaje incluye una marca de tiempo, el nombre del host que lo generó, una facility que indica el origen del mensaje y un nivel de severidad que refleja su criticidad.
Historia y evolución
El origen de syslog se remonta a la década de 1980, cuando se implementó en el sistema Unix de Berkeley como un daemon simple llamado syslogd. Con el tiempo surgieron alternativas más avanzadas como rsyslog y syslog-ng, que añaden características como filtrado basado en expresiones regulares, soporte para TLS y escritura en bases de datos.
Componentes principales
En una instalación típica de Linux encontramos varios daemon que pueden cumplir el rol de syslog:
- syslogd: el daemon original, todavía presente en algunas distribuciones minimalistas.
- rsyslog: una mejora de syslogd con alta performance, módulos de entrada y salida, y capacidad de procesamiento en tiempo real.
- syslog-ng: otra alternativa enfocada en la escalabilidad y el filtrado complejo, con soporte nativo para JSON y estructuras de datos.
Todos estos daemon leen la configuración desde archivos como /etc/rsyslog.conf o /etc/syslog-ng.conf y escriben los mensajes en diversos destinos, como archivos locales, consolas remotas o servidores de log centralizados.
Niveles de severidad y facilities
Cada mensaje syslog lleva dos clasificaciones que permiten filtrar y enrutar la información:
- Facility: indica el subsistema que originó el mensaje. Los valores más comunes son kern (kernel), user (procesos de usuario), mail, daemon, auth, syslog, lpr, news, uucp, cron, local0 hasta local7 (reservados para uso local).
- Severity (nivel de gravedad): sigue el estándar RFC 5424 y va desde 0 (emergency) hasta 7 (debug). Los niveles son: emergency, alert, critical, error, warning, notice, informational y debug.
Gracias a esta combinación, un administrador puede crear reglas que, por ejemplo, envíen todos los mensajes de auth con nivel error o superior a un servidor de seguridad separado.
Configuración básica
En la mayoría de las distribuciones modernas el daemon por defecto es rsyslog. Su archivo de configuración principal se encuentra en /etc/rsyslog.conf. La sintaxis básica de una regla es:
facility.nivel acción
Donde facility y nivel pueden ser un asterisco (*) para indicar cualquiera, y la acción suele ser la ruta de un archivo, un tubo o una dirección remota.
Un ejemplo sencillo que guarda todos los mensajes de nivel warning y superior en /var/log/warnings.log sería:
*.warning /var/log/warnings.log
Para capturar únicamente los eventos de autenticación con nivel error o superior se usaría:
auth.err /var/log/auth_errors.log
Ejemplo de reglas
Un archivo de configuración más completo puede contener varias secciones que dirijan diferentes tipos de información a distintos destinos:
- kern.* /var/log/kernel.log # todos los mensajes del kernel
- mail.info /var/log/mail.info # información del servicio de correo
- auth,authpriv.* /var/log/secure # intentos de login y autenticación
- daemon.* /var/log/daemon.log # servicios en segundo plano
- *.=debug; auth,authpriv.none; news.none; mail.none -/var/log/debug # depuración excluyendo ciertos facilities
- *.emerg :omusrmsg:* # envío de emergencias a todos los usuarios conectados
Estas líneas muestran cómo se pueden combinar facilities y niveles, usar el punto y coma para separar múltiples selectores, y emplear el signo menos (-) antes de la ruta para desactivar la sincronización después de cada escritura, lo que mejora el rendimiento en sistemas de alta carga.
Envío a servidores remotos
Una de las ventajas de syslog es la capacidad de reenviar los logs a un servidor centralizado, lo que facilita la correlación de eventos y la retención a largo plazo. En rsyslog la directiva de reenvío tiene la siguiente forma:
*.* @logservidor.example.com:514
El símbolo @ indica transporte UDP; si se prefiere TCP se usa @@ en su lugar. Para añadir cifrado TLS se puede emplear el módulo omtls:
action(type='omtls' target='logservidor.example.com' port='6514' mode='peer' authmode='anon' caFile='/etc/ssl/certs/ca-certificates.crt')
Esta configuración envía todos los mensajes mediante TLS al puerto 6514 del servidor de logs, garantizando la confidencialidad y la integridad de la información durante el tránsito.
Rotación de logs
Los archivos de log tienden a crecer indefinidamente, por lo que es necesario rotarlos periódicamente para evitar el agotamiento del espacio en disco y facilitar su gestión. La herramienta estándar en Linux es logrotate, que se ejecuta mediante cron y aplica políticas definidas en /etc/logrotate.conf y en los archivos de /etc/logrotate.d/.
Un ejemplo típico de configuración para los archivos de syslog sería:
- /var/log/syslog {
weekly
rotate 4
compress
delaycompress
missingok
notifempty
create 640 root adm
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Esta regla rota el archivo cada semana, conserva cuatro copias comprimidas, crea un nuevo archivo con permisos 640 y ejecuta un script para indicarle a rsyslog que vuelva a abrir sus descriptores de archivo.
Buenas prácticas
Para obtener el máximo beneficio del sistema de registro se recomienda seguir algunas directrices:
- Separar los logs críticos (auth, kernel) de los menos relevantes en archivos distintos y enviarlos a un servidor de seguridad dedicado.
- Utilizar niveles de severidad apropiados: evitar registrar mensajes de debug en producción salvo que se esté solucionando un problema específico.
- Aplicar filtrado en el origen para reducir el volumen de datos transmitidos y almacenados.
- Proteger los canales de transmisión con TLS o VPN cuando los logs salgan del perímetro de confianza.
- Revisar periódicamente las reglas de rotación y retención para cumplir con políticas de cumplimiento (por ejemplo, GDPR o ISO 27001).
- Monitorear el uso de disco y configurar alertas cuando el espacio disponible caiga bajo un umbral seguro.
Conclusión
El comando syslog y sus implementaciones modernas como rsyslog y syslog-ng siguen siendo la columna vertebral del registro de eventos en entornos Linux. Su flexibilidad, basada en facilities y niveles de severidad, permite adaptar la captura de mensajes a casi cualquier requisito operacional o de seguridad. Comprender su funcionamiento, saber configurar reglas de filtrado y reenvío, y aplicar buenas prácticas de rotación y protección son habilidades esenciales para cualquier administrador de sistemas que busque mantener una infraestructura visible, segura y fácil de depurar.
