Búsqueda de sitios web

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

Para que el administrador del sistema identifique o solucione 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 momento específico. período de tiempo de los 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 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 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 Systemd Journal Daemon (journald). fuerte>).

El servidor Rsyslog está construido como un servicio de arquitectura cliente/servidor y puede lograr ambas funciones simultáneamente. Puede ejecutarse como servidor y recopilar todos los registros transmitidos por otros dispositivos en la red o puede ejecutarse como cliente enviando todos los eventos internos del sistema registrados a un servidor syslog de punto final 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 syslog remoto en 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)

R. La instalación o tipo de datos está representada por los procesos internos del sistema que generan los mensajes. En Linux los procesos internos (instalaciones) que generan registros están estandarizados de la siguiente manera:

  • auth = mensajes generados por procesos de autenticación (iniciar 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 séptima prioridad es el nivel más alto de todos.

  • emerg = Emergencia – 0
  • alerta = Alertas – 1
  • err = Errores – 3
  • warn = Advertencias – 4
  • aviso = Notificación – 5
  • info = Información – 6
  • debug = Depuración – 7

Palabras clave especiales de Rsyslog:

  • *=todas las instalaciones o prioridades
  • none=las instalaciones no tienen prioridades determinadas. Por ejemplo: mail.none

C. La tercera parte del esquema syslog está representada por la directiva destino . El demonio Rsyslog puede enviar mensajes de registro para escribirlos en un archivo en el sistema de archivos local (principalmente en un archivo en el directorio /var/log/) o para canalizarlos a otro proceso local o enviarlos a un 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 servidor de registro central, primero debemos verificar y asegurarnos de que la partición /var donde se registran 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 utilizar una unidad separada (LVM, RAID) para montar el directorio /var/log/.

Requisitos

  1. Procedimiento de instalación de CentOS 7.3
  2. 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 debería ejecutarse en CentOS/RHEL 7. Para verificar 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 ejecuta 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, usando 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 hashtag # al principio 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 garantiza la fiabilidad de los datos transmitidos.

Sin embargo, si necesita utilizar el protocolo TCP para la recepción de registros, debe buscar y descomentar las siguientes líneas del archivo /etc/rsyslog.conf para configurar el demonio Rsyslog para vincular y escuchar un socket TCP en 514. puerto. 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 la red syslog. La plantilla debe agregarse antes del comienzo del bloque DIRECTIVAS GLOBALES como se ilustra en el siguiente extracto.

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

La directiva $template RemoteLogs instruye al demonio Rsyslog para que recopile y escriba 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 el Las propiedades definidas 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 nombre de host de la máquina cliente y se almacenarán en el directorio /var/log/.

La regla de redireccionamiento & ~ indica al servidor Rsyslog local que deje de procesar el mensaje de registro recibido y descarte los mensajes (no los escriba en archivos de registro internos).

El nombre RemoteLogs es un nombre arbitrario dado a esta directiva de plantilla. Puede utilizar el nombre que mejor se adapte a su 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 instalación que generó el mensaje, utilice el siguiente extracto.

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

Otro ejemplo de una plantilla donde todos los mensajes con el indicador de función de autenticación se registrarán en una plantilla denominada "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. Después de haber editado el archivo de configuración de Rsyslog con su propia configuración 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 los clientes syslog. Para verificar los sockets de red de Rsyslog, ejecute el comando netstat con privilegios de root y use grep para filtrar la cadena de rsyslog.

netstat -tulpn | grep rsyslog

8. Si tiene SELinux habilitado en CentOS/RHEL 7, emita el siguiente comando para configurar SELinux para permitir el tráfico rsyslog dependiendo 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 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 registros de clientes remotos. En el próximo artículo, veremos cómo configurar el cliente Rsyslog en el servidor CentOS/RHEL 7.

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