Cómo crear un servidor de registro centralizado con Rsyslog en CentOS / RHEL 7


Para que el administrador del sistema identifique o resuelva un problema en un sistema CentOS 7 o RHEL 7 , debe conocer y ver los eventos que ocurrieron en el sistema en una período de tiempo desde los archivos de registro almacenados en el sistema en el directorio /var/log .

El servidor de syslog en una máquina Linux puede actuar como un punto de monitoreo central en 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 un problema interno específico o solo mensajes informativos pueden enviar sus registros .

En un sistema CentOS/RHEL 7 , el daemon Rsyslog es el servidor de registro principal preinstalado, seguido de Daemon del diario del sistema ( journald ).

El servidor Rsyslog se construye como un servicio de arquitectura cliente/servidor y puede lograr ambas funciones simultáneamente. Puede ejecutarse como un servidor y recopilar todos los registros transmitidos por otros dispositivos en la red o puede ejecutarse como un cliente mediante el envío de todos los eventos internos del sistema registrados a un servidor remoto de syslog.

Cuando rsyslog se configura 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 syslog remoto en al mismo tiempo.

El servidor Syslog opera cualquier mensaje de registro usando el siguiente esquema:

type (facility).priority (severity)  destination(where to send the log)

A. El servicio o los datos de 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 = messages generated by authentication processes (login).
  • cron= messages generated by scheduled processes (crontab).
  • daemon = messages generated by daemons (internal services).
  • kernel = messages generated by the Linux Kernel itself.
  • mail = messages generated by a mail server.
  • syslog = messages generated by the rsyslog daemon itself.
  • lpr = messages generated by local printers or a print server.
  • local0 – local7 = custom messages defined by an administrator (local7 is usually assigned for Cisco or 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 séptima prioridad es el nivel más alto de todos.

  • emerg = Emergency – 0
  • alert = Alerts – 1
  • err = Errors – 3
  • warn = Warnings – 4
  • notice = Notification – 5
  • info = Information – 6
  • debug = Debugging – 7

Palabras clave especiales de Rsyslog:

  • * = all facilities or priorities
  • none = the facilities have no given priorities Eg: mail.none

C. La tercera parte del esquema de syslog está representada por la directiva destino . El daemon Rsyslog puede enviar mensajes de registro para que se escriban en un archivo en el sistema de archivos local (principalmente en un archivo en el directorio /var/log/) o que se canalicen a otro proceso local o que se envíen a un consola de usuario local (a la versión estándar), o enviar el mensaje a un servidor de 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 asegurar que la partición /var donde se registra todo el archivo de registro sea lo suficientemente grande ( unos pocos GB como mínimo) para poder almacenar todos los archivos de registro que serán enviados por otros dispositivos. Es una buena decisión usar una unidad separada (LVM, RAID) para montar el directorio /var/log/.

  1. CentOS 7.3 Installation Procedure
  2. RHEL 7.3 Installation Procedure

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 verificar si el daemon está iniciado 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 pretende utilizar como servidor de registro centralizado, ejecute el siguiente comando para instalar el paquete rsyslog.

# yum install rsyslog

3. El primer paso que debemos realizar 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, usando su editor de texto favorito, el archivo de configuración principal de /etc/rsyslog.conf , tal como se presenta en el extracto a continuación.

# vi /etc/rsyslog.conf

En el archivo de configuración principal de rsyslog, busque y descomente las siguientes líneas (quite el hashtag # al comienzo de la línea) para proporcionar recepción de transporte UDP al servidor Rsyslog a través de 514 Puerto. 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 de TCP, lo que lo hace más rápido para transmitir datos que el protocolo TCP. Por otro lado, el protocolo UDP no asegura la fiabilidad de los datos transmitidos.

Sin embargo, si necesita usar el protocolo TCP para la recepción de registros, debe buscar y eliminar las siguientes líneas del archivo /etc/rsyslog.conf para configurar el demonio Rsyslog para enlazar y escuchar un socket TCP en 514 Puerto. Los zócalos de escucha TCP y UDP para la 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 le indicará al servidor Rsyslog local dónde guardar los mensajes recibidos que envían los clientes de la red de syslog. La plantilla debe agregarse antes del comienzo del bloque DIRECTRICES GLOBALES como se ilustra en el extracto a continuación.

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" 
. ?RemoteLogs & ~

La directiva anterior Registros remotos instruye al demonio Rsyslog a recopilar y escribir todos los mensajes de registro recibidos en archivos distintos, según el nombre de la máquina cliente y la instalación del cliente remoto (aplicación) que generó los mensajes según las propiedades definidas presenta 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 que lleva el nombre del host del equipo cliente y se almacenará en el directorio/var/log /.

El & amp; ~ la regla de redireccionamiento indica al servidor Rsyslog local que deje de procesar aún más el mensaje de registro recibido y descarte los mensajes (no los escriba en los archivos de registro internos).

El nombre de RemoteLogs es un nombre arbitrario dado a esta directiva de plantilla. Puede usar el nombre que mejor se adapte a su plantilla.

Para escribir todos los mensajes recibidos de los clientes en un único archivo de registro que lleva el nombre de la dirección IP del cliente remoto, sin filtrar la instalación que generó el mensaje, use el extracto a continuación.

$template FromIp,"/var/log/%FROMHOST-IP%.log" 
. ?FromIp & ~ 

Otro ejemplo de una plantilla en la que todos los mensajes con el indicador de facilidad 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 una definición de 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 el comando man rsyslog.conf o consulte la documentación en línea de Rsyslog.

6. Una vez que haya editado el archivo de configuración de Rsyslog con su propia configuración como se explicó anteriormente, reinicie el daemon Rsyslog para aplicar los cambios emitiendo el siguiente comando:

# service rsyslog restart

7. En este momento, el servidor Rsyslog debería estar configurado para actuar como un servidor de registro centralizado y registrar mensajes de los clientes de 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 habilitado SELinux en CentOS/RHEL 7 , ejecute el siguiente comando para configurar SELinux para permitir el tráfico rsyslog según el tipo de socket de la 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 los clientes remotos. En el siguiente artículo, veremos cómo configurar el cliente Rsyslog en el servidor CentOS/RHEL 7.

Al usar el servidor Rsyslog como un punto central de monitoreo para los mensajes de registro remotos, puede inspeccionar los archivos de registro y observar el estado de salud de los clientes o depurar los problemas de los clientes más fácilmente cuando los sistemas fallan o están bajo algún tipo de ataque.