Registros centralizados en Linux con Rsyslog
A esta altura del partido no hace falta que os diga la importancia de llevar un buen control de la actividad de nuestro equipo, consultando debidamente los registros del sistema. Dichos registros dejan constancia de las acciones de los usuarios, los eventos del sistema, la actividad de los servicios, el estado de la red, etcétera. Sin suda uno de los sistemas de registro más populares es Rsyslog
Logs centralizados en GNU/Linux con Rsyslog
Rsyslog es una utilidad englobada dentro de la filosofía de desarrollo de código abierto y que utiliza una licencia de software libre. Es muy utilizada en sistemas UNIX y similares, como GNU/Linux. Esta se encarga de reenviar mensajes de registro dentro de una red.
Se encarga de implementar el protocolo de syslog básico, lo extiende con filtrado basado en un contenido dado, con capacidades de filtrado enriquecido, opciones de configuración flexibles y agrega características como uso de TCP para el transporte.
Desde sus inicios ha evolucionado como desde un servicio de syslog estándar, a un sistema de registro profesional. Su diseño es de cliente / servidor, por lo tanto, puede configurarse tanto como cliente como como servidor (véase máquina central)
Esquema de Rsyslog (click en la imagen para ampliar)
Además permite gestionar agentes para sistemas privativos como Microsoft Windows.
Según comenta su propia página web se trata de “el sistema más rápido para el procesamiento de registros”
Instalación y configurar de Rsyslog en GNU/Linux
Antes de nada, veamos la pequeña infraestructura virtual para las pruebas:
Servidor central con CentOS 7 con dirección IP 192.168.0.180 (Reutilizo el que utilicé para ElasticStack)
Servidor cliente con CentOS 7 con dirección IP 192.168.0.23 (Reutilizo el que utilicé para WildFly)
La mayoría de las distribuciones tienen ya instalado este paquete, pero si fuese necesario instalarlo:
#En sistemas como RHEL, Centos o Scientific Linuxsudo yum install rsyslog
#En sistemas como Debian, Ubuntu o Linux Mintsudo apt install rsyslog
Una vez instalado lo debemos añadir al inicio, de la siguiente manera, en las últimas versiones de nuestras distribuciones favoritas, que utilicen systemd:
sudo systemctl enable rsyslog
# Además lo encendemossudo systemctl start rsyslog
El fichero principal de configuración se encuentra ubicado en /etc/rsyslog.conf, desde donde se definen los módulos a cargar, las directivas globales, contiene incluso las reglas para procesar mensajes de registro. Además dentro de la carpeta /etc/rsyslog.d, se incluyen diferentes ficheros de configuración para varias aplicaciones y servicios.
Editamos dicho fichero:
sudo vi /etc/rsyslog.conf
De forma predeterminada el servicio utiliza los módulos “imjournal” y “imusock” para importar mensajes de registro estructurados, desde el diario de systemd, en lo que respecta a “imjournal”. En el caso de “imusock” se encarga de aceptar mensajes de syslog de aplicaciones que se ejecuten en el sistema local, a través de sockets Unix.
Para poder utilizar Rsyslog como registro central se debe configurar el puerto, utilizando los protocolos TCP y/o UDP, para así poder recibir los registros de los clientes. En nuestro caso utilizaremos tanto el protocolo de red TCP como UDP.
Para ello buscaremos las siguientes líneas y las descomentamos:
# Provides UDP syslog reception$ModLoad imudp$UDPServerRun 514
# Provides TCP syslog reception$ModLoad imtcp$InputTCPServerRun 514
A continuación, definimos el conjunto de reglas para procesar los registros remotos con el siguiente formato:
facility.severity_level destination (where to store log)
Expliquemos un poco estos conceptos:
- facility: Se trata del tipo de mensaje de proceso que se genera, que incluye auth, cron, daemon, kernel, local 0 hasta local 7. Utilizando * serían todos los tipos
- severity_level: Es el tipo de mensaje de registro: emerg-0, alert-1, crit-2, err-3, warn-4, notice-5, info-6, debug-7 En este caso también podemos utilizar el símbolo * para incluir todos los niveles de gravedad y no incluir nada, significa ningún nivel de gravedad.
- destination: es un fichero local o un servidor Rsyslog remoto (definido en forma de IP más puerto)
En nuestro caso utilizaremos los filtros:
# Provides UDP syslog reception$ModLoad imudp$UDPServerRun 514
# Provides TCP syslog reception$ModLoad imtcp$InputTCPServerRun 514
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
Hay que tener en cuenta, que, dentro del apartado de directivas, esta siempre tiene que ser la primera.
La directiva “$template” le dice a Rsyslog que reúna y escriba todos los mensajes remotos recibidos en distintos registros bajo /var/log, según el nombre de host y programa.
La segunda línea “. ?RemoteLogs” significa mensajes de registro de todas las instalaciones en todos los niveles de severidad, usando la configuración de la plantilla de RemoteLogs.
Respecto a las plantillas siempre podemos consultar la documentación original al respecto: Plantillas Rsyslog
Una vez hechos los cambios, guardamos y salimos del fichero de configuración.
Procedemos a reiniciar el servicio:
sudo systemctl restart rsyslog
Para verificar la actividad podemos utilizar el comando: lsof
lsof -i 514
O bien utilizando netstat
En mi caso:
[root@servcentos-elasticstack ~]# lsof -i :514
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMErsyslogd 3626 root 3u IPv4 21488 0t0 UDP *:syslog
rsyslogd 3626 root 4u IPv6 21489 0t0 UDP *:syslog
rsyslogd 3626 root 5u IPv4 21492 0t0 TCP *:shell (LISTEN)
rsyslogd 3626 root 6u IPv6 21493 0t0 TCP *:shell (LISTEN)
Si tenemos habilitado SELINUX, podemos habilitar el puerto 514, para el protocolo de red TCP
sudo semanage -a -t syslogd_port_t -p tcp 514
sudo semanage -a -t syslogd_port_t -p udp 514
Y en el caso del cortafuegos:
sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --reload
Configurar cliente Rsyslog para el envío de registros
La instalación es igual en los nodos clientes que en el central, que hemos visto antes.
Para habilitar el envío de registros editamos el fichero /etc/rsyslog.conf, y añadimos:
*.* @@192.168.0.180:514
Vemos su situación en la imagen, justo al final del fichero:
#$ActionResumeRetryCount -1 # infinite retries if host is down# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional#*.* @@remote-host:514*.* @@192.168.0.180:514
# ### end of the forwarding rule ###
Una vez añadido, guardamos y reiniciamos el servicio:
sudo systemctl restart rsyslog
Y así en el host con el rol de servidor central, ya podemos que están llegando los registros del nuevo cliente:
[root@servcentos-elasticstack ~]# lsof -c rsyslog | grep -i wildfly
rsyslogd 3626 root 14w REG 253,0 14941 5342 /var/log/servwildfly/standalone.sh.log
rsyslogd 3626 root 22w REG 253,0 790 5358 /var/log/servwildfly/systemd.log
En mi caso con los ficheros:
[root@servcentos-elasticstack /]# ls -la /var/log/servwildfly/*
-rw------- 1 root root 298 oct 29 19:05 /var/log/servwildfly/dbus.log
-rw------- 1 root root 313 oct 29 19:05 /var/log/servwildfly/dhclient.log
-rw------- 1 root root 882 oct 29 19:05 /var/log/servwildfly/NetworkManager.log
-rw------- 1 root root 225 oct 29 19:05 /var/log/servwildfly/nm-dispatcher.log
-rw------- 1 root root 0 oct 29 19:04 /var/log/servwildfly/polkitd.log
-rw------- 1 root root 0 oct 29 19:04 /var/log/servwildfly/rsyslogd.log
-rw------- 1 root root 59946 oct 29 19:06 /var/log/servwildfly/standalone.sh.log
-rw------- 1 root root 2630 oct 29 19:06 /var/log/servwildfly/systemd.log
Espero que el artículo os haya parecido de interés. ¿Has trabajado con Rsyslog alguna vez? ¿Quieres contar tu experiencia en los comentarios?
