Para que el administrador del sistema pueda identificar o solucionar un problema en un sistema de servidor CentOS 7 o RHEL 7, debe conocer y ver los eventos que ocurrieron en el sistema en un período de tiempo específico a partir de archivos de registro almacenados en el sistema en el directorio /var/log.
El servidor syslog en una máquina Linux puede actuar como un punto de monitoreo central a través de una red donde todos los servidores, dispositivos de red, enrutadores, conmutadores y la mayoría de sus servicios internos que generan registros, ya sea relacionados con problemas internos específicos o simplemente mensajes informativos, pueden enviar sus registros.
En un sistema CentOS / RHEL 7, el demonio Rsyslog es el servidor de registro principal preinstalado, seguido del Demonio de Diario Systemd (journald).
Servidor Rsyslog en la compilación como un servicio de arquitectura cliente/servidor y puede lograr ambos roles simultáneamente. Puede ejecutarse como servidor y recopilar todos los registros transmitidos por otros dispositivos de la red o puede ejecutarse como cliente enviando todos los eventos internos del sistema registrados a un servidor de registro de sistema de extremo remoto.
Cuando rsyslog está configurado como cliente, los registros se pueden almacenar localmente en archivos en el sistema de archivos local o se pueden enviar de forma remota en lugar de escribirlos en archivos almacenados en la máquina o escribir archivos de registro de eventos localmente y enviarlos a un servidor de registro de sistema remoto al mismo tiempo.
El servidor Syslog opera cualquier mensaje de registro utilizando el siguiente esquema:
type (facility).priority (severity) destination(where to send the log)
A. Los datos de instalación o tipo están representados por los procesos internos del sistema que generan los mensajes. En Linux, los procesos internos (instalaciones) que generan registros se estandarizan de la siguiente manera:
- auth = mensajes generados por procesos de autenticación (inicio de sesión).
- cron = mensajes generados por procesos programados (crontab).
- daemon = mensajes generados por demonios (servicios internos).
- kernel = mensajes generados por el propio Kernel de Linux.
- mail = mensajes generados por un servidor de correo.
- syslog = mensajes generados por el propio demonio rsyslog.
- lpr = mensajes generados por impresoras locales o un servidor de impresión.
- local0-local7 = mensajes personalizados definidos por un administrador (local7 generalmente se asigna para Cisco o Windows).
B. Los niveles de prioridad (gravedad) también están estandarizados. Cada prioridad se asigna con una abreviatura estándar y un número como se describe a continuación. La 7ª prioridad es el nivel más alto de todos.
- emerg = Emergencia – 0
- alerta = Alertas – 1
- err = Errores – 3
- advertir = Advertencias – 4
- aviso = Notificación – 5
- info = Información – 6
- Depuración– 7
Palabras clave especiales de Rsyslog:
- * = todas las instalaciones o prioridades
- ninguna = las instalaciones no tienen prioridades dadas, por ejemplo: correo.ninguno
C. La tercera parte del esquema syslog está representada por la directiva destination. El demonio Rsyslog puede enviar mensajes de registro para ser escritos en un archivo en el sistema de archivos local (principalmente en un archivo en el directorio /var/log/) o para ser canalizados a otro proceso local o para ser enviados a una consola de usuario local (a stdout), o enviar el mensaje a un servidor syslog remoto a través del protocolo TCP/UDP, o incluso descartar el mensaje a /dev/null.
Para configurar CentOS/RHEL 7 como un servidor de registro central, primero debemos verificar y asegurarnos de que la partición /var donde se graban todos los archivos de registro sea lo suficientemente grande (unos pocos GB como mínimo) para poder almacenar todos los archivos de registro que enviarán otros dispositivos. Es una buena decisión usar una unidad separada (LVM, RAID) para montar el directorio /var/log/.
Requisitos
- Procedimiento de instalación de CentOS 7.3
- Procedimiento de instalación de RHEL 7.3
Cómo configurar Rsyslog en el servidor CentOS / RHEL 7
1. De forma predeterminada, el servicio Rsyslog se instala automáticamente y debe ejecutarse en CentOS/RHEL 7. Para comprobar si el demonio se inicia en el sistema, ejecute el siguiente comando con privilegios de root.
# systemctl status rsyslog.service
Si el servicio no se está ejecutando de forma predeterminada, ejecute el siguiente comando para iniciar el demonio rsyslog.
# systemctl start rsyslog.service
2. Si el paquete rsyslog no está instalado en el sistema que desea utilizar como servidor de registro centralizado, ejecute el siguiente comando para instalar el paquete rsyslog.
# yum install rsyslog
3. El primer paso que debemos hacer en el sistema para configurar el demonio rsyslog como un servidor de registro centralizado, para que pueda recibir mensajes de registro para clientes externos, es abrir y editar, utilizando su editor de texto favorito, el archivo de configuración principal de /etc/rsyslog.conf, como se presenta en el siguiente extracto.
# vi /etc/rsyslog.conf
En el archivo de configuración principal de rsyslog, busque y descomente las siguientes líneas (elimine el signo de hashtag # al principio de la línea) para proporcionar recepción de transporte UDP al servidor Rsyslog a través del puerto 514. UDP es el protocolo estándar utilizado para la transmisión de registros por Rsyslog.
$ModLoad imudp $UDPServerRun 514
4. El protocolo UDP no tiene la sobrecarga TCP, lo que lo hace más rápido para transmitir datos que el protocolo TCP. Por otro lado, el protocolo UDP no garantiza la fiabilidad de los datos transmitidos.
Sin embargo, si necesita usar el protocolo TCP para la recepción de registros, debe buscar y descomentar las siguientes líneas de /etc/rsyslog.archivo de configuración para configurar el demonio Rsyslog para enlazar y escuchar un socket TCP en el puerto 514. Los sockets de escucha TCP y UDP para recepción se pueden configurar en un servidor Rsyslog simultáneamente.
$ModLoad imtcp $InputTCPServerRun 514
5. En el siguiente paso, no cierre el archivo todavía, cree una nueva plantilla que se utilizará para recibir mensajes remotos. Esta plantilla indicará al servidor Rsyslog local dónde guardar los mensajes recibidos enviados por los clientes de red syslog. La plantilla debe agregarse antes del comienzo del bloque de DIRECTIVAS GLOBALES, como se ilustra en el siguiente fragmento.
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" . ?RemoteLogs & ~
La directiva anterior Remot template RemoteLogs indica al demonio Rsyslog que recopile y escriba todos los mensajes de registro recibidos en archivos distintos, en función del nombre del equipo cliente y de la instalación de cliente remoto (aplicación) que generó los mensajes en función de las propiedades definidas que se presentan en la configuración de la plantilla: %HOSTNAME% y %PROGRAMNAME%.
Todos estos archivos de registro se escribirán en el sistema de archivos local en un archivo dedicado con el nombre del host de la máquina cliente y se almacenarán en el directorio /var/log/.
La regla de redirección & ~ indica al servidor Rsyslog local que deje de procesar el mensaje de registro recibido y deseche los mensajes (no los escriba en archivos de registro internos).
El nombre de RemoteLogs es un nombre arbitrario dado a esta directiva de plantilla. Puedes usar el nombre que mejor se adapte a tu plantilla.
Para escribir todos los mensajes recibidos de los clientes en un único archivo de registro con el nombre de la dirección IP del cliente remoto, sin filtrar la función que generó el mensaje, utilice el siguiente extracto.
$template FromIp,"/var/log/%FROMHOST-IP%.log" . ?FromIp & ~
Otro ejemplo de plantilla en la que todos los mensajes con el indicador de instalación de autenticación se registrarán en una plantilla llamada «TmplAuth».
$template TmplAuth, "/var/log/%HOSTNAME%/%PROGRAMNAME%.log" authpriv.* ?TmplAuth
A continuación se muestra un extracto de la definición de una plantilla del servidor Rsyslog 7:
template(name="TmplMsg" type="string" string="/var/log/remote/msg/%HOSTNAME%/%PROGRAMNAME:::secpath-replace%.log" )
El extracto de la plantilla anterior también se puede escribir como:
template(name="TmplMsg" type="list") { constant(value="/var/log/remote/msg/") property(name="hostname") constant(value="/") property(name="programname" SecurePath="replace") constant(value=".log") }
Para escribir plantillas complejas de Rsyslog, lea el manual del archivo de configuración de Rsyslog emitiendo man rsyslog.comando conf o consulte la documentación en línea de Rsyslog.
6. Después de editar el archivo de configuración de Rsyslog con sus propios ajustes, como se explicó anteriormente, reinicie el demonio Rsyslog para aplicar los cambios emitiendo el siguiente comando:
# service rsyslog restart
7. A estas alturas, el servidor Rsyslog debería estar configurado para actuar como un servidor de registro centralizado y registrar mensajes de clientes syslog. Para verificar los sockets de red Rsyslog, ejecute el comando netstat con privilegios de root y use grep para filtrar la cadena rsyslog.
# netstat -tulpn | grep rsyslog
8. Si tiene SELinux habilitado en CentOS / RHEL 7, ejecute el siguiente comando para configurar SELinux para permitir el tráfico rsyslog en función del tipo de socket de red.
# semanage -a -t syslogd_port_t -p udp 514# semanage -a -t syslogd_port_t -p tcp 514
9. Si el firewall está habilitado y activo, ejecute el siguiente comando para agregar las reglas necesarias para abrir los puertos rsyslog en Firewalld.
# firewall-cmd --permanent --add-port=514/tcp# firewall-cmd --permanent --add-port=514/udp# firewall-cmd –reload
¡Eso es todo! Rsyslog ahora está configurado en modo servidor y puede centralizar los registros de clientes remotos. En el siguiente artículo, veremos cómo configurar el cliente Rsyslog en el servidor CentOS / RHEL 7.
Utilizando el servidor Rsyslog como punto de monitoreo central para mensajes de registro remotos, puede inspeccionar archivos de registro y observar el estado de salud del cliente o depurar los problemas del cliente más fácilmente cuando los sistemas se bloquean o están bajo algún tipo de ataque.