108.2 Lección 1

Certificación:

LPIC-1

Versión:

5.0

Tema:

108 Servicios esenciales del sistema

Objetivo:

108.2 Registros del sistema

Lección:

1 de 2

Introducción

Los registros pueden ser el mejor amigo de un administrador de sistemas. Son archivos (normalmente de texto) en los que se registran cronológicamente todos los eventos del sistema y de la red desde el momento en que se inicia. Así, la gama de información que se puede encontrar en los registros incluye prácticamente todos los aspectos del sistema: intentos fallidos de autenticación, errores de programas y servicios, hosts bloqueados por el cortafuegos, etc. Como puedes imaginar, los registros facilitan mucho la vida de los administradores de sistemas a la hora de solucionar problemas, comprobar recursos, detectar comportamientos anómalos de los programas, etc. En esta lección discutiremos una de las facilidades de registro más comunes que se encuentran actualmente en las distribuciones de GNU/Linux: rsyslog. Estudiaremos los diferentes tipos de logs que existen, dónde se almacenan, qué información incluyen y cómo se puede obtener y filtrar esa información. También discutiremos cómo se pueden mantener los logs en servidores centralizados a través de redes IP, la rotación de logs y el ring buffer del kernel.

Registro del sistema

En el momento en que el kernel y los diferentes procesos de tu sistema comienzan a ejecutarse y a comunicarse entre sí, se genera mucha información en forma de mensajes (que en su mayoría) se envían a los registros.

Sin los registros, la búsqueda de un evento ocurrido en un servidor supondría un dolor de cabeza para los administradores del sistema, de ahí la importancia de contar con una forma estandarizada y centralizada de realizar un seguimiento de cualquier suceso del sistema. Los registros son determinantes y reveladores cuando se trata de la resolución de problemas y la seguridad, y son fuentes de datos fiables para entender las estadísticas del sistema y hacer predicciones de tendencias.

Dejando de lado systemd-journald (del que hablaremos en la próxima lección), el registro ha sido tradicionalmente manejado por tres servicios principales dedicados: syslog, syslog-ng (syslog new generation) y rsyslog ("`the rocket-fast system for log processing"). El rsyslog aportó importantes mejoras (como el soporte de RELP) y se ha convertido en la opción más popular hoy en día. Cada uno recoge mensajes de otros servicios y programas, y los almacena en archivos de registro, normalmente en /var/log. Sin embargo, algunos servicios se encargan de sus propios registros (por ejemplo, el servidor web Apache HTTPD o el sistema de impresión CUPS). Asimismo, el kernel de Linux utiliza el ring buffer para almacenar sus mensajes de registro.

Note	`RELP` significa Reliable Event Logging Protocol y amplía la funcionalidad del protocolo syslog para proporcionar una entrega fiable de los mensajes.

Dado que rsyslog se ha convertido en la instalación de registro estándar oficial en todas las principales distros, nos centraremos en ella para la presente lección. rsyslog utiliza un modelo cliente-servidor. El cliente y el servidor pueden estar en el mismo host o en diferentes máquinas. Los mensajes son enviados y recibidos en un formato particular y pueden ser guardados en servidores centralizados de rsyslog a través de la red. El demonio de rsyslog — rsyslogd — trabaja junto con klogd (que gestiona los mensajes del kernel). En las próximas secciones se hablará de rsyslog y su infraestructura de registro.

Note	Un demonio es un servicio que se ejecuta en segundo plano. Tenga en cuenta la "d" final en los nombres de los demonios: "klogd" o "rsyslogd".

Tipos de registros

Como los registros son datos variables, normalmente se encuentran en /var/log. A grandes rasgos, se pueden clasificar en registros de sistema y registros de servicio o programa.

Veamos algunos registros del sistema y la información que guardan: /var/log/auth.log:: Actividades relacionadas con los procesos de autenticación: usuarios registrados, información sudo, trabajos cron, intentos fallidos de inicio de sesión, etc.

/var/log/syslog: Es un archivo centralizado para prácticamente todos los registros capturados por rsyslogd. Debido a que incluye tanta información, los registros se distribuyen a través de otros archivos de acuerdo con la configuración suministrada en /etc/rsyslog.conf.
/var/log/debug: Información de depuración de programas.
/var/log/kern.log: Mensajes de kernel.
/var/log/messages: Mensajes informativos que no están relacionados con el kernel sino con otros servicios. También es el destino por defecto del registro del cliente remoto en una implementación de servidor de registro centralizado.
/var/log/daemon.log: Información relacionada con los demonios o servicios que se ejecutan en segundo plano.
/var/log/mail.log: Información relacionada con el servidor de correo electrónico, por ejemplo, postfix.
/var/log/Xorg.0.log: Información relacionada con la tarjeta gráfica.
/var/run/utmp and /var/log/wtmp: Registros de acceso exitosos.
/var/log/btmp: Intentos fallidos de inicio de sesión, por ejemplo, ataque de fuerza bruta a través de ssh.
/var/log/faillog: Intentos de autenticación fallidos.
/var/log/lastlog: Fecha y hora de los últimos inicios de sesión de los usuarios.

Veamos ahora algunos ejemplos de registros de servicio:

/var/log/cups/: Directorio para los registros del Sistema de impresión (Common Unix Printing System). Normalmente incluye los siguientes archivos de registro por defecto: error_log, page_log y access_log.
/var/log/apache2/ or /var/log/httpd: Directorio para los registros del Servidor Web Apache. Normalmente incluye los siguientes archivos de registro por defecto: access.log, error_log, y other_vhosts_access.log.
/var/log/mysql: Directorio para los registros del Sistema de Gestión de Bases de Datos Relacionales MySQL. Suele incluir los siguientes archivos de registro por defecto: error_log, mysql.log y mysql-slow.log.
/var/log/samba/: Directorio para los registros del protocolo Session Message Block (SMB). Suele incluir los siguientes archivos de registro por defecto: log., log.nmbd and log.smbd.

Note	El nombre exacto y el contenido de los archivos de registro pueden variar según la distribución de Linux. También hay registros particulares de distribuciones específicas como `/var/log/dpkg.log` (que contiene información relacionada con los paquetes `dpkg`) en Debian GNU/Linux y sus derivados.

Leyendo registros

Para leer los archivos de registro, primero asegúrese de que es el usuario root o de que tiene permisos de lectura sobre el archivo. Puede utilizar una variedad de utilidades como:

less o more

Permiten ver y desplazarse por una página a la vez:

root@debian:~# less /var/log/auth.log
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2
Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol.
Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0)
(...)

zless or zmore

Lo mismo que less y more, pero utilizado para los registros que se comprimen con gzip (una función común de logrotate):

root@debian:~# zless /var/log/auth.log.3.gz
Aug 19 20:05:57 debian sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now
Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus)
Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0.
Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22.
(...)

tail

Muestra las últimas líneas de un archivo (el valor por defecto es de 10 líneas). El poder de tail reside en el parámetro -f, que muestra dinámicamente las nuevas líneas a medida que se añaden:

root@suse-server:~# tail -f /var/log/messages
2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root
2019-09-14T13:57:38.038298+02:00 suse-server sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages
2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...

head

Ver las primeras líneas de un archivo (por defecto son 10 líneas):

root@suse-server:~# head -5 /var/log/mail
2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running
2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system
2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix
2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system
2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15

grep

Utilidad de filtrado que permite buscar cadenas específicas:

root@debian:~# grep "dhclient" /var/log/syslog
Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67
Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1
Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds.
(...)

Como habrá notado, la salida se imprime en el siguiente formato:

Marca de tiempo
Nombre del host desde el que se originó el mensaje
Nombre del programa/servicio que ha generado el mensaje
El PID del programa que generó el mensaje
Descripción de la acción realizada

Hay algunos ejemplos en los que los registros no son de texto, sino archivos binarios, y por consiguiente, hay que utilizar comandos especiales para analizarlos:

/var/log/wtmp

Use who (or w):

root@debian:~# who
root    pts/0        2020-09-14 13:05 (192.168.1.75)
root    pts/1        2020-09-14 13:43 (192.168.1.75)

/var/log/btmp

Use utmpdump o last -f:

root@debian:~# utmpdump /var/log/btmp
Utmp dump of /var/log/btmp
[6] [01287] [    ] [dave     ] [ssh:notty   ] [192.168.1.75        ] [192.168.1.75   ] [2019-09-07T19:33:32,000000+0000]

/var/log/faillog

Use faillog:

root@debian:~# faillog -a | less
Login       Failures Maximum Latest                   On

root            0        0   01/01/70 01:00:00 +0100
daemon          0        0   01/01/70 01:00:00 +0100
bin             0        0   01/01/70 01:00:00 +0100
sys             0        0   01/01/70 01:00:00 +0100
sync            0        0   01/01/70 01:00:00 +0100
games           0        0   01/01/70 01:00:00 +0100
man             0        0   01/01/70 01:00:00 +0100
lp              0        0   01/01/70 01:00:00 +0100
mail            0        0   01/01/70 01:00:00 +0100
(...)

/var/log/lastlog

Use lastlog:

root@debian:~# lastlog | less
Username         Port     From             Latest
root                                       Never logged in
daemon                                     Never logged in
bin                                        Never logged in
sys                                        Never logged in
(...)
sync                                       Never logged in
avahi                                      Never logged in
colord                                     Never logged in
saned                                      Never logged in
hplip                                      Never logged in
carol            pts/1    192.168.1.75     Sat Sep 14 13:43:06 +0200 2019
dave             pts/3    192.168.1.75     Mon Sep  2 14:22:08 +0200 2019

Note	También hay herramientas gráficas para leer los archivos de registro, por ejemplo: `gnome-logs` y `KSystemLog`.

¿Cómo se convierten los mensajes en registros?

El siguiente proceso ilustra cómo se escribe un mensaje en un archivo de registro:

Las aplicaciones, los servicios y el kernel escriben mensajes en archivos especiales (sockets y buffers de memoria), por ejemplo /dev/log o /dev/kmsg.
rsyslogd obtiene la información de los sockets o buffers de memoria.
Dependiendo de las reglas encontradas en /etc/rsyslog.conf y/o de los archivos en /etc/ryslog.d/, rsyslogd mueve la información al archivo de registro correspondiente (típicamente encontrado en /var/log).

Note	Un socket es un archivo especial utilizado para transferir información entre diferentes procesos. Para listar todos los sockets de su sistema, puede utilizar el comando `systemctl list-sockets --all`.

Facilidades, prioridades y acciones

El archivo de configuración de rsyslog es /etc/rsylog.conf (en algunas distribuciones también puede encontrar archivos de configuración en /etc/rsyslog.d/). Normalmente se divide en tres secciones: MODULES, GLOBAL DIRECTIVES y RULES. Vamos a echarle un vistazo explorando el fichero rsyslog.conf en nuestro host Debian GNU/Linux 10 (buster) — para hacer esto puede usar sudo less /etc/rsyslog.conf.

MODULES incluye el soporte de módulos para el registro, la capacidad de mensajes y la recepción de registros UDP/TCP:

#################
#### MODULES ####
#################

module(load="imuxsock") # proporciona soporte para el registro del sistema local
module(load="imklog")   # proporciona soporte de registro del kernel
#module(load="immark")  # proporciona la capacidad de mensajes --MARK--.

# proporciona la recepción de syslogs UDP
#module(load="imudp")
#input(type="imudp" port="514")

# proporciona la recepción de syslogs TCP
#module(load="imtcp")
#input(type="imtcp" port="514")

GLOBAL DIRECTIVES permiten configurar una serie de cosas como los registros y los permisos del directorio de registros:

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# UtilicE el formato tradicional de marca de tiempo.
#  Para habilitar las marcas de tiempo de alta precisión, comenta la siguiente línea.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Establezca los permisos por defecto para todos los archivos de registro.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Dónde colocar los archivos de spool y de estado
#
$WorkDirectory /var/spool/rsyslog

#
# Incluir todos los archivos de configuración en /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

RULES es donde entran las facilidades, las prioridades y las acciones. Las configuraciones de esta sección le dicen al demonio de registro que filtre los mensajes de acuerdo con ciertas reglas y los registre o envíe cuando sea necesario. Para comprender estas reglas, primero debemos explicar los conceptos de facilidades y prioridades de rsyslog. A cada mensaje de registro se le da un número de facilidad y una palabra clave que están asociados con el subsistema interno de Linux que produce el mensaje:

Número Palabra clave Descripción

0

kern

Mensajes del kernel de Linux

1

user

Mensajes a nivel de usuario

2

mail

Mensajes del sistema de correo

3

daemon

Demonios del sistema

4

auth, authpriv

Mensajes de seguridad/autorización

5

syslog

Mensajes de syslogd

6

lpr

Subsistema de impresión de línea

7

news

Mensajes del subsitema de red

8

uucp

Subsistema UUCP (Unix-to-Unix Copy Protocol)

9

cron

Demonio del reloj

10

auth, authpriv

Mensajes de seguridad/autorización

11

ftp

Demonio del FTP

12

ntp

Demonio del NTP

13

security

Registros de auditoría

14

console

Registros de alertas

15

cron

Demonio del cron

16 - 23

De local0 al local7

Local utiliza 0 - 7

Además, a cada mensaje se le asigna un nivel de prioridad:

Código Severidad Palabra clave Descripción

0

Emergency

emerg, panic

El sistema es inutilizable

1

Alert

alert

Hay que actuar inmediatamente

2

Critical

crit

Condiciones críticas

3

Error

err, error

Condiciones de error

4

Warning

warn, warning

Condiciones de advertencia

5

Notice

notice

Condición normal pero significativa

6

Informational

info

Mensajes informativos

7

Debug

debug

Mensajes de nivel de depuración

Aquí hay un extracto de rsyslog.conf de nuestro sistema Debian GNU/Linux 10 (buster) que incluye algunas reglas de ejemplo:

###############
#### RULES ####
###############

# Primero algunos archivos de registro estándar.  Registro por instalación.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Registro para el sistema de correo.  Dividirlo para que
# sea fácil escribir scripts para analizar estos archivos.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Algunos archivos de registro "catch-all"
#
*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none          -/var/log/messages

El formato de la regla es el siguiente:`<facilidad>.<prioridad>` <acción>

Los selectores <facilidad>.<prioridad> filtran los mensajes que deben coincidir. Los niveles de prioridad son jerárquicamente inclusivos, lo que significa que rsyslog coincidirá con los mensajes de la prioridad especificada y superiores. El selector <acción> muestra la acción a realizar (dónde enviar el mensaje de registro). Aquí hay algunos ejemplos para mayor claridad:

auth,authpriv.*                 /var/log/auth.log

Independientemente de su prioridad (*), todos los mensajes de auth or authpriv serán enviados a /var/log/auth.log.

*.*;auth,authpriv.none          -/var/log/syslog

Todos los mensajes — independientemente de su prioridad (*) — de todas las facilidades (*) — descartando los de auth o authpriv (de ahí el sufijo .none) — se escribirán en /var/log/syslog (el signo menos (-) antes de la ruta evita excesivas escrituras en disco). Tenga en cuenta el punto y coma (;) para dividir el selector y la coma (,) para concatenar dos instalaciones en la misma regla (auth,authpriv).

mail.err                        /var/log/mail.err

Los mensajes de la instalación de mail con un nivel de prioridad de error o superior (crítico, alerta o emergencia) se enviarán a /var/log/mail.err.

*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug

Los mensajes de todas las instalaciones con la prioridad debug y ninguna otra (=) se escribirán en /var/log/debug — excluyendo cualquier mensaje procedente de las instalaciones auth, authpriv, news y mail (nótese la sintaxis: ;\).

Entradas manuales en el registro del sistema: `logger`

El comando logger es muy útil para los scripts de la shell o para propósitos de prueba. El comando logger agregará cualquier mensaje que reciba a /var/log/syslog (o a /var/log/messages cuando se registre en un servidor de registro central remoto, como se verá más adelante en esta lección):

carol@debian:~$ logger this comment goes into "/var/log/syslog"

Para imprimir la última línea en /var/log/syslog, utilice el comando tail con la opción -1:

root@debian:~# tail -1 /var/log/syslog
Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog

`rsyslog` como servidor central de registros

Para explicar este tema vamos a añadir un nuevo host a nuestra configuración. La disposición es la siguiente:

Role Hostname S.O IP Address

Central Log Server

suse-server

openSUSE Leap 15.1

192.168.1.6

Client

debian

Debian GNU/Linux 10 (buster)

192.168.1.4

Empecemos por configurar el servidor. En primer lugar, nos aseguramos de que rsyslog este en funcionamiento:

root@suse-server:~# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 832 (rsyslogd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─832 /usr/sbin/rsyslogd -n -iNONE

openSUSE incluye un archivo de configuración dedicado al registro remoto: /etc/rsyslog.d/remote.conf. Vamos a activar la recepción de mensajes de los clientes (hosts remotos) a través de TCP. Debemos descomentar las líneas que cargan el módulo e inician el servidor TCP en el puerto 514:

# ######### Recepción de mensajes de hosts remotos ##########
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imtcp.so  # load module
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
$InputTCPServerRun 514  # Starts a TCP server on selected port

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
#$UDPServerRun 514  # start a UDP syslog server at standard port 514

Una vez hecho esto, debemos reiniciar el servicio rsyslog y comprobar que el servidor está escuchando en el puerto 514:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# netstat -nltp | grep 514
[sudo] password for root:
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      2263/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      2263/rsyslogd

A continuación, debemos abrir los puertos en el firewall y recargar la configuración:

root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp
success
root@suse-server:~# firewall-cmd --reload
success

Note	Con la llegada de openSUSE Leap 15.0, `firewalld` sustituyó por completo al clásico `SuSEFirewall2`.

Plantillas y condiciones de filtrado

Por defecto, los registros del cliente se escribirán en el archivo /var/log/messages del servidor, junto con los del propio servidor. Sin embargo, crearemos una plantilla y una condición de filtro para que los registros de nuestro cliente se almacenen en directorios propios. Para ello, añadiremos lo siguiente a /etc/rsyslog.conf (o /etc/rsyslog.d/remote.conf):

$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
& stop

Template

La plantilla corresponde a la primera línea y permite especificar un formato para los nombres de registro mediante la generación dinámica de nombres de archivo. Una plantilla se compone de:

Directiva de plantillas ($template)
Nombre de la plantilla (RemoteLogs)
Texto de la plantilla ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Opciones (optional)

Nuestra plantilla se llama RemoteLogs y su texto consiste en una ruta en /var/log. Todos los registros de nuestro host remoto irán al directorio remotehosts, donde se creará un subdirectorio basado en el nombre del host de la máquina (%HOSTNAME%). Cada nombre de archivo en este directorio consistirá en la fecha (%$NOW%), la gravedad (también conocida como prioridad) del mensaje en formato de texto (%syslogseverity-text%) y el sufijo .log. Las palabras entre los signos de porcentaje son propiedades y permiten acceder al contenido del mensaje de registro (fecha, prioridad, etc.). Un mensaje syslog tiene una serie de propiedades bien definidas que pueden utilizarse en las plantillas. A estas propiedades se accede -y se pueden modificar- mediante el llamado reemplazador de propiedades que implica escribirlas entre signos de porcentaje.

Condición del filtro

Las dos líneas restantes corresponden a la condición del filtro y su acción asociada:

Filtro basado en expresiones (if $FROMHOST-IP=='192.168.1.4')
Acción (then ?RemoteLogs, & stop)

La primera línea comprueba la dirección IP del host remoto que envía el registro y — si es igual a la de nuestro cliente Debian — aplica la plantilla RemoteLogs. La última línea (& stop) garantiza que los mensajes no se envían simultáneamente a /var/log/messages (sino sólo a los ficheros del directorio /var/log/remotehosts).

Note	Para saber más sobre plantillas, propiedades y reglas, puedes consultar la página del manual de `rsyslog.conf`.

Con la configuración actualizada, reiniciaremos rsyslog de nuevo y confirmaremos que aún no existe el directorio remotehosts en /var/log:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# ls /var/log/
acpid             chrony     localmessages   pbl.log          Xorg.0.log
alternatives.log  cups       mail            pk_backend_zypp  Xorg.0.log.old
apparmor          firebird   mail.err        samba            YaST2
audit             firewall   mail.info       snapper.log      zypp
boot.log          firewalld  mail.warn       tallylog         zypper.log
boot.msg          krb5       messages        tuned
boot.omsg         lastlog    mysql           warn
btmp              lightdm    NetworkManager  wtmp

El servidor ya está configurado. A continuación, configuraremos el cliente.

De nuevo, debemos asegurarnos de que rsyslog está instalado y funcionando:

root@debian:~# sudo systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset:
   Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 351 (rsyslogd)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─351 /usr/sbin/rsyslogd -n

En nuestro entorno de ejemplo hemos implementado la resolución de nombres en el cliente añadiendo la línea 192.168.1.6 suse-server a /etc/hosts. Así podemos referirnos al servidor tanto por su nombre (suse-server) como por su dirección IP (192.168.1.6).

Nuestro cliente Debian no viene con un fichero remote.conf en /etc/rsyslog.d/, así que aplicaremos nuestras configuraciones en /etc/rsyslog.conf. Escribiremos la siguiente línea al final del fichero:

*.* @@suse-server:514

Por último, reiniciamos rsyslog.

root@debian:~# systemctl restart rsyslog

Ahora, volvamos a nuestra máquina suse-server y comprobemos la existencia de remotehosts en /var/log:

root@suse-server:~# ls /var/log/remotehosts/debian/
2019-09-17.info.log  2019-09-17.notice.log

Ya tenemos dos registros dentro de /var/log/remotehosts como se describe en nuestra plantilla. Para completar esta sección, ejecutamos tail -f 2019-09-17.notice.log en suse-server mientras enviamos un registro manualmente desde nuestro cliente Debian y confirmamos que los mensajes se añaden al archivo de registro como se esperaba (la opción -t proporciona una etiqueta para nuestro mensaje):

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)

carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4

Mecanismo de rotación de registros

Los registros se rotan con regularidad, lo que sirve para dos propósitos principales: * Evitar que los archivos de registro más antiguos utilicen más espacio de disco del necesario.

Mantenga los registros con una longitud manejable para facilitar su consulta.

La utilidad encargada de la rotación (o ciclado) de los registros es logrotate y su trabajo incluye acciones como mover los archivos de registro a un nuevo nombre, archivarlos y/o comprimirlos, a veces enviarlos por correo electrónico al administrador del sistema y eventualmente borrarlos a medida que envejecen. Hay varias convenciones para nombrar estos archivos de registro rotados (añadiendo un sufijo con la fecha al nombre del archivo, por ejemplo); sin embargo, la práctica común es simplemente añadir un sufijo con un número entero:

root@debian:~# ls /var/log/messages*
/var/log/messages  /var/log/messages.1  /var/log/messages.2.gz  /var/log/messages.3.gz  /var/log/messages.4.gz

Expliquemos ahora lo que ocurrirá en la próxima rotación del registro:

messages.4.gz se eliminará.
El contenido de messages.3.gz se trasladará a messages.4.gz.
El contenido de messages.2.gz se trasladará a messages.3.gz.
El contenido de messages.1 se trasladará a messages.2.gz.
El contenido de messages se trasladará a messages.1 y messages estará vacío y listo para registrar nuevas entradas de registro.

Observe que según las directivas logrotate (que verá en breve), los tres archivos de registro más antiguos están comprimidos, mientras que los dos más recientes no lo están. Además, conservaremos los registros de las últimas 4-5 semanas. Para leer los mensajes de hace una semana, consultaremos messages.1 (y así sucesivamente).

logrotate se ejecuta como un proceso automatizado o trabajo cron diariamente a través del script /etc/cron.daily/logrotate y lee el archivo de configuración /etc/logrotate.conf. Este archivo incluye algunas opciones globales y está bien comentado con cada opción introducida por una breve explicación de su propósito:

carol@debian:~$ sudo less /etc/logrotate.conf
# see "man logrotate" for details
# rotar los archivos de registro semanalmente
weekly

# mantener 4 semanas
rotate 4

# crear nuevos archivos de registro (vacíos) después de rotar los antiguos
create

# Descomente esto si quiere que sus archivos de registro se compriman
#compress

# los paquetes dejan la información de la rotación del registro en este directorio
include /etc/logrotate.d

(...)

Como puedes ver, también se incluyen los archivos de configuración en /etc/logrotate.d para paquetes específicos. Estos archivos contienen — en su mayoría — definiciones locales y especifican los archivos de registro a rotar (recuerde, las definiciones locales tienen prioridad sobre las globales, y las definiciones posteriores anulan las anteriores). Lo que sigue es un extracto de una definición en /etc/logrotate.d/rsyslog:

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Como puede ver, cada directiva está separada de su valor por espacios en blanco y/o un signo de igualdad opcional (=). Sin embargo, las líneas entre postrotate y endscript deben aparecer en líneas solas. La explicación es la siguiente:

rotate 4: Conserva los registros de 4 semanas.
weekly: Rota los archivos de registro semanalmente.
missingok: No emita un mensaje de error si falta el archivo de registro; simplemente pase al siguiente.
notifempty: No gira el registro si está vacío.
compress: Comprime los archivos de registro con gzip (por defecto).
delaycompress: Pospone la compresión del archivo de registro anterior al siguiente ciclo de rotación (sólo es efectivo cuando se utiliza en combinación con compress). Es útil cuando no se puede indicar a un programa que cierre su archivo de registro y, por tanto, podría seguir escribiendo en el archivo anterior durante algún tiempo.
sharedscripts: Relacionado con los scripts prerotate y postrotate. Para evitar que un script se ejecute varias veces, ejecute los scripts sólo una vez, independientemente de cuántos archivos de registro coincidan con un patrón determinado (por ejemplo, /var/log/mail/*). Además, si los scripts salen con errores, las acciones restantes no se ejecutarán para ningún registro.
postrotate: Indica el inicio de un script postrotate.
invoke-rc.d rsyslog rotate > /dev/null: Utiliza /bin/sh para correr invoke-rc.d rsyslog rotate > /dev/null después de rotar los registros.
endscript: Indica el final del script postrotate .

Note	Para una lista completa de directivas y explicaciones, consulte la página del manual de `logrotate.conf`.

Kernel Ring Buffer

Dado que el kernel genera varios mensajes antes de que rsyslogd esté disponible en el arranque, se hace necesario un mecanismo para registrar esos mensajes. Aquí es donde entra en juego el kernel ring buffer. Es una estructura de datos de tamaño fijo y, por lo tanto, a medida que crece con nuevos mensajes, los más antiguos desaparecen.

El comando dmesg imprime el kernel ring buffer. Debido al tamaño del buffer, este comando se utiliza normalmente en combinación con la utilidad de filtrado de texto grep. Por ejemplo, para buscar mensajes relacionados con los dispositivos del Bus Serie Universal:

root@debian:~# dmesg | grep "usb"
[    1.241182] usbcore: registered new interface driver usbfs
[    1.241188] usbcore: registered new interface driver hub
[    1.250968] usbcore: registered new device driver usb
[    1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19
[    1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
(...)

Ejercicios guiados

Qué utilidades/comandos utilizarías en los siguientes escenarios:

Finalidad y archivo de registro Utilidad

Leer /var/log/syslog.7.gz

Leer /var/log/syslog

Filtrar la palabra renewal en /var/log/syslog

Leer /var/log/faillog

Leer /var/log/syslog dinamicamente

Reorganice las siguientes entradas de registro de manera que representen un mensaje de registro válido con la estructura adecuada:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  El orden correcto es:
Qué reglas añadirías a /etc/rsyslog.conf para cumplir con cada una de las siguientes:
- Enviar todos los mensajes de la instalación mail y una prioridad/gravedad de crit (y superior) a /var/log/mail.crit:
- Envía todos los mensajes de la instalación mail con prioridades de alerta y emergencia a /var/log/mail.urgent:
- Excepto los procedentes de las instalaciones cron y ntp, envía todos los mensajes -independientemente de su facilidades y prioridad - a /var/log/allmessages:
- Con todos los ajustes requeridos correctamente configurados primero, envíe todos los mensajes de la instalación mail a un host remoto cuya dirección IP es 192.168.1.88 usando TCP y especificando el puerto por defecto:
- Independientemente de su facilidad, envía todos los mensajes con la prioridad warning (sólo con la prioridad warning`) a `/var/log/warnings evitando la escritura excesiva en el disco:

Considere la siguiente sección de /etc/logrotate.d/samba y explique las diferentes opciones:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Opción Significado

weekly

missingok

rotate 7

postrotate

endscript

compress

delaycompress

notifyempty

Ejercicios de exploración

En la sección “Plantillas y condiciones de filtrado” hemos utilizado uno basado en expresiones como condición de filtrado. Los filtros basados en propiedades son otro tipo de exclusivo de rsyslogd. Convierta nuestro filtro basado en expresiones en uno basado en propiedades:

Filtro basado en expresiones Filtro basado en propiedades

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
omusrmsg es un módulo integrado en rsyslog que facilita la notificación a los usuarios (envía mensajes de registro al terminal del usuario). Escribe una regla para enviar todos los mensajes de emergencia de todas las instalaciones tanto a root como al usuario regular carol.

Resumen

En esta lección aprendió:

El registro es crucial para la administración del sistema.
rsyslogd es la utilidad encargada de mantener los registros limpios y ordenados.
Algunos servicios se encargan de sus propios registros.
A grandes rasgos, los registros pueden clasificarse en registros de sistema y registros de servicio/programa.
Hay un número de utilidades que son convenientes para la lectura de registros: less, more, zless, zmore, grep, head y tail.
La mayoría de los archivos de registro son de texto plano; sin embargo, hay un pequeño número de archivos de registro binarios.
En cuanto a los registros, rsyslogd recibe la información relevante de archivos especiales (sockets y buffers de memoria) antes de procesarla.
Para clasificar los registros, rsyslogd utiliza reglas en /etc/rsyslog.conf o /etc/rsyslog.d/*.
Cualquier usuario puede introducir sus propios mensajes en el registro del sistema manualmente con la utilidad logger.
rsyslog permite mantener todos los registros de las redes IP en un servidor de registros centralizado.
Las plantillas son útiles para formatear los nombres de los archivos de registro de forma dinámica.
El objetivo de la rotación de registros es doble: evitar que los registros antiguos utilicen un espacio de disco excesivo y hacer que los registros de consulta sean manejables.

Respuesta a los ejercicios guiados

Qué utilidades/comandos utilizarías en los siguientes escenarios:

Finalidad y archivo de registro Utilidad

Leer /var/log/syslog.7.gz

zmore or zless

Leer /var/log/syslog

more or less

Filtrar la palabra renewal en /var/log/syslog

grep

Leer /var/log/faillog

faillog -a

Leer /var/log/syslog dinamicamente

tail -f

Reorganice las siguientes entradas de registro de manera que representen un mensaje de registro válido con la estructura adecuada:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  El orden correcto es:
  Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
Qué reglas añadirías a /etc/rsyslog.conf para cumplir con cada una de las siguientes:
- Enviar todos los mensajes de la instalación mail y una prioridad/gravedad de crit (y superior) a /var/log/mail.crit:
  mail.crit /var/log/mail.crit
- Envía todos los mensajes de la instalación mail con prioridades de alerta y emergencia a /var/log/mail.urgent:
  mail.alert /var/log/mail.urgent
- Excepto los procedentes de las instalaciones cron y ntp, envía todos los mensajes -independientemente de su facilidades y prioridad - a /var/log/allmessages:
  *.*;cron.none;ntp.none /var/log/allmessages
- Con todos los ajustes requeridos correctamente configurados primero, envíe todos los mensajes de la instalación mail a un host remoto cuya dirección IP es 192.168.1.88 usando TCP y especificando el puerto por defecto:
  mail.* @@192.168.1.88:514
- Independientemente de su facilidad, envía todos los mensajes con la prioridad warning (sólo con la prioridad warning`) a `/var/log/warnings evitando la escritura excesiva en el disco:
  *.=warning -/var/log/warnings

Considere la siguiente sección de /etc/logrotate.d/samba y explique las diferentes opciones:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Opción Significado

weekly

Rotar los archivos de registro semanalmente.

missingok

No emita un mensaje de error si falta el registro; simplemente continúe con el siguiente.

rotate 7

Mantenga 7 semanas de atrasos.