Administración - Registros del Sistema

Archivos de bitácora

En un sistema GNU/Linux prácticamente todo queda registrado. Y es que hay un demonio (syslogd) que se encarga de hacerlo. Toda información relevante (mensajes de arranque, accesos, errores de conexión en los servidores, ...) se guarda en unos archivos. Son los logs o bitácoras del sistema. Predeterminadamente están en el directorio /var/log/. Pero esto puede cambiarse e indicar incluso que que se registren en otra máquina distinta. Nosotros no hemos llegado a ese grado de paranoia. ¿Para qué eso? Pues, por ejemplo, para evitar que un atacante que se infiltre en nuestra máquina pueda borrar entradas o logs completos con el fin de ocultar su rastro. Y es que si todo ha ido quedando registrado en otra máquina ahora sería más difícil.

El archivo de configuración general de syslogd es /etc/syslog.conf. Los dos archivos globales de registro de información son syslog y messages.

La cantidad de carpetas y de archivos que encontremos en /var/log/ dependerá en gran medida de los servicios que haya en nuestra máquina. Así, por ejemplo, los mensajes referentes a nuestro servidor web los encontramos en /var/log/httpd/, y los de nuestro servidor de correo en /var/log/mail/.

Conforme va pasando el tiempo, los archivos de registro van engordando. ¿Hasta el infinito? Bueno, el demonio logrotate se encarga de la rotación. Así, los mensajes más antiguos se van guardando en sucesivas copias de seguridad, marcadas con números, hasta su definitiva eliminación (p.ej. syslog.2.gz o access_log.1).

Leyendo el contenido

Prácticamente todos los archivos son de texto plano y los podemos examinar por ello con cualquier editor de textos: desde un simple cat (filtrando y ordenando) en un terminal hasta kate pasdando por vi. En Mandriva dispondemos de una herramienta gráfica para visualizar y analizar los logs, que es logdrake, que permite filtrar, guardar, configurar el envío de alertas por correo, etc. Pero no la verdad, no la uso.

Hay un archivo que no puede verse directamente: /var/log/lastlog, que registra los últimos accesos de los usuarios del sistema y que podemos examinar con

# lastlog

Herramientas para analizar: logwatch y logcheck

Bueno, hemos puesto en marcha un Servidor en un Centro Educativo y procuramos instalar las actualizaciones de seguridad. Tenemos en marcha un portal y una plataforma educativa. Realizamos y archivamos periódicas copias de seguridad. El Administrador no es un profesional, ni se dedica a esto ni cobra por ello. ¿Y ahora a mirar los logs? ¿Y cuándo? La verdad es que ¿quién puede revisarlos a menudo? Ahora bien, hay contadas ocasiones en las que es preciso.

Tal y como está configurado ahora el servidor, se generan los siguientes informes sobre la marcha del sistema, que recibo en mi correo: dos diarios de la herramienta de seguridad global msec, tres semanales de copias de seguridad (los cursos de la plataforma moodle, el script de backup_semanal y el de mybackup_semanal. Además, están los enviados por logrotate y por moodle cuando se producen intentos fallidos.

Para un análisis simple de múltiples archivos de registro instalamos la utilidad logwatch. Su instalación es tan simple como esto:

# urpmi logwatch

Y no toqué nada en su simple archivo de configuración /etc/log.d/conf/logwatch.conf. Pero sí tuve que retocar archivos referentes a varios servicios, pues no se corresponden los logs que venían con los que usa MandrivaLinux 2006. Veámoslos:

# cat /etc/log.d/conf/logfiles/clam-update.conf
LogFile = clamav/clamd.log
LogFile = clamav/freshclam.log
Archive = clamav/*.gz

# cat /etc/log.d/conf/logfiles/cron.conf
LogFile = cron/errors
LogFile = cron/warnings
LogFile = cron/info
Archive = cron/*.gz

# cat /etc/log.d/conf/logfiles/http.conf
LogFile = httpd/access_log
LogFile = httpd/error_log
LogFile = httpd/ssl_access_log
LogFile = httpd/ssl_error_log
LogFile = httpd/ssl_request_log
Archive = httpd/*_log.*
*ExpandRepeats
*ApplyhttpDate

# cat /etc/log.d/conf/logfiles/maillog.conf
LogFile = mail/errors
LogFile = mail/info
LogFile = mail/warnings
Archive = mail/*.gz
*ExpandRepeats
*OnlyHost
*ApplyStdDate

# cat /etc/log.d/conf/logfiles/secure.conf
LogFile = secure
LogFile = security.log
LogFile = auth.log
Archive = secure.*
Archive = security.*
Archive = auth.log.*
*ExpandRepeats
*OnlyHost
*ApplyStdDate

# cat /etc/log.d/conf/services/postfix.conf
Title = "POSTFIX"
LogFile = maillog
*OnlyService = "postfix/[a-zA-Z0-9]*"
*RemoveHeaders =

Ahora cada día se enviará a root un correo, "LogWatch for web.iesdelgadohenandez.es", que resumirá toda la información registrada durante el anterior en los logs relacionada con: amavis, clam-update, cron, httpd, kernel (con mensajes del firewall), pam-unix, postfix, sshd y Disk Space (espacio en disco ocupado/libre). Es muy útil y sus resúmenes son magníficos.

Terminamos con otra herramienta que instalé, logcheck, pues leí artículos sobre seguridad que la recondaban. Bastó un simple:

# urpmi logcheck

Sin configurar nada, nos enviará un correo con un análisis pormenorizado de los logs. En él distinguirá, si los hay, tres tipos de registros: Active System Attack Alerts, Security Violations y Unusual System Events. Esta clasificación es uno de sus puntos fuertes, pues permite concentrarte en las "Alertas por Ataques Activos al Sistema", por si hay algo que revisar más a fondo. Pero tiene dos grandes inconvenientes:

  • No hace un resumen de los registros correspondientes a un mismo incidente (como hace logwatch), sino que muestras todas las líneas del archivo de registro. Así, ante un mensaje del tipo "kernel: FW [DOS Attack/SYN escan?]..." nos encontraremos centenares de líneas de mensajes de información del firewall, o las relacionadas por el rechazo de correos debidas a las medidas anti-spam de postfix. Esto hace que pierda, a mi entender, su utilidad como analizador.
  • Se solapa con los mensajes que registra msec: las interpreta como alertas y aparecen duplidas y mezcladas con las demás.

Bueno, con esto creo que es suficiente. Pero siempre se puede mejorar...

. : .