2.5 Ubicar e interpretar archivos de registro del sistema y diarios

Todos los eventos que suceden dentro del sistema operativo llevados a cabo tanto por el kernel o los procesos que estén corriendo deben ser registrados en archivos conocidos como logs, estos son muy útiles para la revisión de y corrección de errores o bien por temas de auditoría, de forma estándar estos archivos logs son guardados en el directorio /var/log. En este directorio existen importantes archivos de log del sistema y de servicios

 

  • boot.log Mensajes relacionados con el arranque del sistema (boot)
  • secure Eventos relacionados con autenticación y seguridad
  • maillog Eventos relacionados con el servicio de correo (postfix)
  • cron Mensajes relacionados con tareas programadas (crond)
  • messages El fichero de log más conocido y utilizado por los administradores ya que la mayoría de los eventos de syslog se registran aquí  (rsyslog.service)

 

ryslog

Syslog es el protocolo utilizado comúnmente por el sistema (kernel), procesos y bien por programas para poder realizar los registros de eventos en los archivos determinados, un servicio o programa que utiliza este protocolo y que lo hemos utilizado en versiones pasadas de Red Hat Enterprise Linux es rsyslod.

 

Los eventos son clasificados por tipo de mensaje y prioridad (gravedad) de estas últimas tenemos 8

 

Prioridad Código Gravedad
emerg 0 El sistema no se puede usar
alert 1 Requiere acción inmediata
crit 2 Evento o condición crítica
err 3 Condición de error no crítica
warning 4 Advertencia
notice 5 Evento normal pero importante
info 6 Condición informativa
debug 7 Mensaje a nivel depuración (debug)

 

El archivo de configuración del servicio rsyslog se encuentra en /etc/rsyslog.conf, es es en este donde se configura el tipo de mensaje y prioridad de los eventos mediante este archivo en el apartado ####RULES#### o en archivos *.conf dentro del directorio /etc/rsyslog.d/

 

Por ejemplo para la línea del messages encontramos en el rsyslog.conf lo siguiente

 

*.info;mail.none;authpriv.none;cron.none                /var/log/messages

 

*   Aplicación

info Nivel de severidad o gravedad

/var/log/messages A donde se almacenan estos eventos

 

Separados por ; las reglas que apliquen al mismo archivos

mail.none no guarda nada del servicio de correo (postfix)

authpriv.none no guarda nada que servicio de autenticación (auth)

cron.none no guarda nada de eventos referente a tareas programadas crond

 

Todo los eventos de cualquier severidad  referentes authpriv (autenticación y seguridad) se van al fichero /var/log/secure

authpriv.*                                              /var/log/secure

 

Para un mayor entendimiento del archivo de configuración de rsyslog ejecutar

 

logrotate (Rotación del archivo de registro)

 

Existe un utilidad en el sistema llamada logrotate que nos permite llevar a cabo un proceso denominado rotar, un mecanismo que permite que se llene el sistema de eventos en los archivos logs del directorio /var/log, y consiste en renombrar el archivo de log regularmente con un sufijo o extensión en formato de fecha para saber el dia en que roto y creando un archivo vacío, notificando al servicio que debe escribir en el  

 

boot.log-20180911 roto el dia 11 de septiembre del 2018

messages-20181021 roto el dia 21 de octubre del 2018

 

La configuración de logrotate se encuentra en el fichero en /etc/logrotate.conf y este contiene lineas de configuracion como las de a continuación

 

#rota cada semana

weekly

##mantiene los últimos 4 archivos de log

rotate 4

## cuando se rota se cree uno nuevo

create

## que agregue el sufijo de fecha al archivo rotado

dateext

##se toman en cuenta los archivos *.conf dentro del directorio logrotate.d/

include /etc/logrotate.d

 

Para profundizar más en el tema ejecutar

 

 

Analisis de log

Una vez comprendido cómo opera los servicios rsyslog veremos cómo poder trabajar con los archivos *.log, es decir, el formato en el que son generados y cómo leerlos.

es de suma importancia por cuestiones de seguridad y auditoria no abrir los archivos con un editor de texto como es el caso de VI ya que esto podría modificar los registros de modificación de los archivos log y puede prestarse a que hubo una manipulación de ellos, para estas tareas utilizaremos comandos como less, more, head, cat, grep y tail, siendo este último de mucha utilidad con su parámetro -f (–follow) que nos permite ver en tiempo real la actualización de los archivos logs y así tener un monitoreo de eventos, si quieres comprobar lo anterior te invito a que abras dos terminales y en una ejecutes  tailf /var/log/messages y en otras un systemctl restart sshd, y veas el comportamiento.

 

Dec 16 22:33:38 localhost systemd: Stopping OpenSSH server daemon…

Dec 16 22:33:39 localhost systemd: Starting OpenSSH server daemon…

Dec 16 22:33:39 localhost systemd: Started OpenSSH server daemon.

 

Lo anterior en formato de columnas tenemos

1 Marca de tiempo del registro

2 El Host donde se efectuó el evento

3 El servicio, programa o proceso que envio el mensaje

4 El mensaje

 

Una forma de comprobar que nuestro servicio de rsyslog y que el protocolo syslog esté funcionando correctamente podemos emitir eventos a un fichero utilizando el programa logger

 

 

systemd-journald

Este servicio es integrado en las versiones RHEL 7.x y bien CentOS 7.x, es posible que sea una versión mejorada de rsyslog y su principal función o característica es tener todos los registros y eventos del sistema en una sola ubicación y esto nos permite realizar filtrados por usuario, servicios, horas etc. a diferencia de rsyslog que utiliza archivos separados de log.

 

Journal utiliza una base de datos ubicada en /run/log/journal,  y por entendido que todo lo que está en el directorio /run/ al reiniciar se pierde esto nos da una idea que journal no es persistente al reinicio

 

Trabajando con journalctl

Para llevar a cabo el análisis de logs o bien el monitoreo de eventos nos apoyamos del programa journalctl que con sus diferentes parámetros podemos obtener resultados bastantes granulares y complejos.

Ejecutando individualmente el siguiente comando obtendremos los eventos del sistema comenzando por la entrada más antigua, el programa resalta en negritas los mensajes de texto con severidad de aviso o advertencia y los mensajes de error o superiores lo resalta en rojo.

Esto suele ser un poco complicado ya que obtendremos un sin fin de líneas y los mas sano es acotar estos resultados, mostrar la ultimas 8 lineas del registro

Filtrar resultados por prioridad

Similar al comando tail -f o tailf, journalctl nos proporciona el parámetro follow para tema de monitoreo en tiempo real

Si se requiere buscar eventos por rango de tiempo utilizamos las opciones –since y –until con formato de fecha y hora YYYY-MM-DD hh:mm:ss

Existe una manera  de ver las líneas de un evento con un agregado de campos para obtener más información

Eventos por servicio

journal persistente

Como se había mencionado anteriormente journal no se mantiene después de un reinicio del sistema pero si nuestra necesidad es que se mantenga de forma permanente en el file system llevaremos a cabo los siguientes pasos

crear el directorio /var/log/journal

Los permisos correspondientes

Reiniciamos el servicio de journald

Consideraciones

  • El journal tiene un mecanismo de rotación de registro mensualmente.
  • El journal no podrá tener más del 10 % del sistema de archivos en el que está ubicado ni dejar menos del 15 % del sistema de archivos libre.
  • Estos valores pueden ajustarse en el archivo de configuración /etc/systemd/journald.conf
  • Un avez realizado algún cambio en el archivo de configuración es importante reiniciar el servicio  systemctl restart systemd-journald

@franklinux

 

Deja un comentario