Ficheros de Log y otros métodos de monitorización

Una de las partes integrales de cualquier sistema UNIX son las facilidades para hacer logging. La mayoría del logging de Linux viene proporcionado por dos programas principales, sysklogd y klogd, el primero proporciona servicios de logging a programas y aplicaciones, el segundo proporciona capacidad de logging al kernel de Linux. Klogd en realidad envía la mayoría de los mensajes al syslogd, pero de vez en cuando lanzará mensajes a la consola (p. ej., cuando el kernel entra en pánico). Sysklogd en realidad maneja la tarea procesar la mayoría de los mensajes y de enviarlos al fichero o dispositivo apropiado, lo cual se configura desde /etc/syslog.conf. Por defecto, la mayoría del logging a ficheros tiene lugar en /var/log/, y generalmente los programas que manejan su propio logging (la mayoría de servidores httpd manejan sus logs internamente) lo hacen a /var/log/nombreprograma/, lo cual te permite centralizar los ficheros de log y hace más sencillo situarlos en particiones diferentes (algunos ataques pueden consumir los logs rápidamente, y tener una partición / no es algo divertido). Además, existen programas que manejan internamente sus logs, siendo uno de los más interesantes el shell de comandos bash. Por defecto, bash mantiene un historial de los comandos ejecutados en la línea de comandos. Apache maneja todos sus logs internamente, configurable desde httpd.conf y extremadamente flexible con la aparición de Apache 1.3.6 (soporta logging condicional). Sendmail maneja sus logs vía syslogd, pero también tiene la opción (vía línea de comandos con el atributo –X) de hacer un log de todas las transacciones SMTP directamente a un fichero. Esto es altamente desaconsejable, puesto que el fichero crecerá enormemente en un corto espacio de tiempo, pero es útil para hacer debugging. Para más información, ver las secciones acerca de seguridad de red en Apache y sendmail.

Por lo general, no querrás permitir que los usuarios vean los ficheros de log de un servidor, y especialmente que puedan ser capaces de modificarlos o borrarlos. En general, la mayoría de los ficheros de log son propiedad del usuario y grupo root, y no tienen asignados permisos para otros, de modo que en la mayoría de los casos, el único usuario que será capaz de modificar los logs será el root (y si alguien revienta la cuenta del root, pues apaga y vámonos). Se pueden tomar medidas de seguridad adicionales, siendo la más simple el uso de "chattr" (CHange ATTRibutes, el comando para cambiar los atributos), para dejar el exclusivamente permiso de sólo-añadir a los ficheros de log. De tal forma que si se da un problema de raza en /tmp que permita a la gente sobreescribir ficheros del sistema no se puedan dañar ficheros de logs. Para dejar un fichero en modo sólo-añadir, utiliza:

A la función chattr sólo tiene acceso el superusuario. Si dejas todos los ficheros en modo sólo-añadir, recuerda que fallarán los programas de rotación de logs, puesto que no pueden dejar en cero el fichero de log. Añade una línea al script para deshabilitar el atributo sólo-añadir:

y añade una línea después del script de rotación de logs para reiniciar el flag de sólo-añadir. Si los ficheros de logs se dejan en el sistema, quizás prefieras activar también el flag de inmutables, de forma que no se puedan falsificar con facilidad. Para activar el fichero como inmutable, simplemente:

lo que evitará cualquier cambio (debida a razas en el /tmp, etc.) en el fichero, a menos que el atacante tenga acceso de root (en cuyo caso vas a sufrir de todas formas).

sólo el usuario root tiene acceso al flag de inmutable.

En resumen, klogd maneja los mensajes del kernel, dependiendo de tu configuración, puede ir desde casi ninguno a una buena cantidad, si por ejemplo activas la opción de contabilidad de procesos. Después se pasa la mayoría de los mensajes al syslogd, para el manejo real (es decir, es el que escribe los datos físicamente al fichero). Las páginas del manual del sysklog, klogd y syslog.conf son bastante buenas, con ejemplos claros. Una característica del syslog muy potente y a menudo despreciada es la posibilidad de hacer un log de mensajes a hosts remotos que estén ejecutando syslog. Puesto que se pueden definir múltiples ubicaciones para los mensajes del syslog (p. ej., enviar todos los mensajes del kernel al fichero /var/log/messages, y a consola, a uno o múltiples hosts remotos), lo cual te permite centralizar las tareas de logs a un único host, y verificar con facilidad violaciones en la seguridad o demás anomalías. Sin embargo, existen varios problemas con syslogd y klogd, siendo el principal la facilidad con la que un atacante, una vez que ha conseguido acceso de root, puede borrar/modificar ficheros de log, no existe un método de autentificación construido dentro de las capacidades de hacer logging.

Los ficheros de log standard y que normalmente vienen definidos en syslog.conf son:

El primero (messages) por lo general captura la mayoría de la información; el usuario hace el login, los TCP_WRAPPERS vuelcan aquí la información, el cortafuegos de paquetes IP también vuelca información aquí, etc. El segundo generalmente registra entradas de eventos tales como usuarios cambiando su UID/GID (vía su, sudo, etc.), intentos fallidos cuando se requieren contraseñas, etc. El fichero maillog guarda por lo general entradas de cada conexión pop/imap (nombre de usuario y logout), y el encabezamiento de cada uno de los correos que entran o salen del sistema (de quien, a quien, msgid, estado, etc.). El fichero spooler ya no se suele usar, puesto que el número de gente que utiliza usenet o uucp ha caído en picado, el uucp ha sido reemplazado por el ftp y el correo, y la mayoría de los servidores de usenet suelen ser por lo general, máquinas extremadamente potentes como para manejar un newsfeed parcial o completo, lo cual quiere decir que no hay muchos de ellos (generalmente uno por cada PSI o más, dependiendo del tamaño). La mayoría de los usuarios desde casa o de pymes no van a estar ejecutando un servidor de usenet (al menos no deberían, en mi opinión), la cantidad de ancho de banda y potencia de máquina que se requiere es inmensa, y no digamos ya los riesgos de seguridad.

También se pueden definir ficheros de log adicionales, por ejemplo, se podría añadir:

Y se puede hacer un log selectivamente a otro host para logs separado:

Lo cual daría como resultado que todos los mensajes del kernel fuesen a parar a /var/log/kernel-log, lo cual es útil en servidores sin monitor, ya que por defecto todos los mensajes del kernel van a /dev/console (p. ej. si alguien está conectado en las máquinas). En el segundo caso, todos los mensajes de emergencia irían al host "syslog-host", y todos los ficheros del log de correo se enviarían al servidor "mail-log-host", permitiéndote mantener ficheros de log de varios servicios centralizados

secure-syslog

El problema principal con el syslog es que falsificar los ficheros es algo trivial. Sin embargo existe una versión segura del syslogd, disponible en http://www.core-sdi.com/ssyslog/ (estos chicos suelen hacer buenas herramientas de seguridad y tiene una buena reputación, en cualquier caso es software de fuente abierta, para aquellos que sean realmente paranoicos). Esta te permite firmar criptográficamente los logs, para asegurarse de que no han sido falsificados. Sin embargo, en último lugar, un atacante podría borrar los ficheros de log, de modo que es una buena idea enviarlos a otro host, especialmente en el caso de un cortafuegos, para prevenir que el disco duro se llene.

next generation syslog

Otra alternativa es "syslog-ng" (Next Generation Syslog, Syslog de Nueva Generación), que parece bastante más personalizable que incluso el syslog o secure-syslog, soporta firmas digitales para prevenir falsificación de ficheros, y puede filtrar basándose en el contenido del mensaje, no sólo la procedencia y la prioridad (algo bastante útil para reducir el volumen). Syslog-ng está disponible en: http://www.balabit.hu/products/syslog-ng.html

Nsyslogd

Nsyslogd soporta tcp y SSL para enviar el log a sistemas remotos. Se ejecuta en una gran variedad de plataformas UNIX, lo puedes descargar de: http://coombs.anu.edu.au/~avalon/nsyslog.html

Psionic Logcheck

Psionic Logcheck navega por los ficheros de mensajes (y otros) a intervalos regulares (normalmente se invoca vía crontab), y envía un correo con un sumario de cualquier actividad sospechosa. Es fácilmente configurable, con varios "tipos" de elementos, intentos activos de penetración, sobre los que enseguida te grita, actividad dañina y actividad que se debe ignorar (por ejemplo, estadísticas del servidor DNS o regeneración de llaves SSH). Psionic Logcheck se encuentra disponible en: http://www.psionic.com/abacus/logcheck/.

colorlogs

colorlogs colorea los ficheros de logs, lo cual te permite identificar con facilidad actividad sospechosa. Basado en un fichero de configuración, busca palabras clave y colorea las líneas (en rojo, cyan, etc.), recibe la entrada desde STDIN, de modo que se puede utilizar para revisar ficheros de log rápidamente (utilizando "cat", "tail" u otras utilidades para alimentar el fichero de logs a través del programa). Se puede conseguir en: http://www.resentment.org/projects/colorlogs/.

WOTS

WOTS recolecta ficheros de logs desde múltiples orígenes, y genera informes o toma medidas basándose en lo que le digas que haga. WOTS busca expresiones regulares que se le definan, y después ejecuta los comandos que le listas (enviar un informe, hacer sonar una alerta, etc.). WOTS requiere que tengas instalado perl, y está disponible en: http://www.vcpc.univie.ac.at/~tc/tools/.

swatch

swatch es muy parecido a WOTS, y la configuración de los ficheros de log es muy similar. Puedes descargarlo de: ftp://ftp.stanford.edu/general/security-tools/swatch/

auditd

auditd te permite utilizar las capacidades de log del kernel (una herramienta muy potente). Se puede hacer un log de mensajes de correo, eventos de sistema y los elementos habituales que cubriría syslog, pero además se pueden cubrir eventos como que usuarios específicos abran ficheros, la ejecución de programas, de programas setuid, etc. Si necesitas sólidos seguimientos de auditoría, esta es la herramienta que necesitas, la puedes conseguir en: ftp://ftp.hert.org/pub/linux/auditd/.

bash

También trataré bash, ya que es el shell por defecto en la mayoría de las instalaciones de Linux, y como tal su posibilidad de hacer logging suele la habitualmente utilizada. bash tiene una gran cantidad de variables que se pueden configurar en tiempo de ejecución o durante su uso, las cuales modifican su comportamiento. Cualquier cosa desde el estilo del prompt hasta cuántos ficheros se pueden almacenar en el fichero de logs.

nombre del fichero de historial, por defecto es ~nombreusuario/.bash_history

número máximo de comandos a mantener en el fichero, se rotan a medida que sea necesario.

el número de comandos que recuerda (p. ej. cuando se usa el cursor arriba).

Las variables se suelen configurar en /etc/profile, lo cual configura el bash globalmente para todos los usuarios, sin embargo, estos valores pueden pasarse por alto con el fichero ~nombreusuario/.bash_profile, y/o usando manualmente el comando export para configurar variables como export EDITOR=emacs. Esta es una de las razones por las que los directorios de los usuarios no deberían ser legibles por el mundo; el fichero .bash_history puede almacenar una gran cantidad de información valiosa para partes hostiles. Se puede hacer que el fichero no sea legible, que no se haga log del fichero .bash_profile, hacer que no se pueda escribir en el fichero (denegando de esta forma al shell la posibilidad de escribir y hacer log de ello) o enlazarlo a /dev/null (lo cual casi siempre suele ser síntoma claro de actividad sospechosa por parte del usuario, o usuarios paranoicos). En cuanto a la cuenta del root, recomendaría encarecidamente configurar el HISTFILESIZE y HISTSIZE con un valor bajo, tal como 10. Por otra parte, si quieres hacer un log del historial de shell de los usuarios, para así reforzar la seguridad, recomendaría dejar los ficheros de configuración de los directorios de los usuarios como inmutables, utilizando el comando chattr, y dejar los ficheros de logs (como .bash_history) como sólo-añadir. Sin embargo, hacer esto tiene implicaciones legales, de modo que asegúrate de que los usuarios son conscientes de que se les está registrando y que están de acuerdo con ello, o si no podrías tener problemas.

Volver