Los ficheros log se encargan de registrar los eventos que ocurren en el sistema,aplicaciones incluidas. ¿Qué eventos? Pueden ser accesos al sistema, mensajes de información del kernel, el tráfico capturado por un sniffer e incluso los famosos logs del IRC, TODO esto son ficheros log, o en cristiano, ficheros de registro. Normalmente “ficheros log” lo solemos recortar a simplemente logs, que es como nos referiremos a ellos de aquí en adelante.
Los clasificamos en dos apartados: Ficheros log de texto plano y Ficheros log binarios.
Ficheros log de texto plano
– /var/log/syslog: En este fichero log se almacenan todos los logs por defecto. En teoría es el más importante, aquí estará todo lo que busquemos, si no hemos cambiado nada del demonio Syslogd, que más adelante veremos.
– /var/log/messages: Contiene mensajes del sistema, no es un log “alerta”, es más bien informativo. Viene bien para arreglar problemas en el sistema.
– /var/log/secure: En este fichero están los logs de todas las conexiones que se realizan hacia nuestra máquina.
– /var/log/auth.log: Contiene el registro de todas las autentificaciones en el sistema, tanto las aceptadas como las fallidas.
– /var/log/debug: Aquí es donde se almacena la información de depuración de los programas que ejecutamos en el sistema. Esta información la envía el núcleo del sistema (Kernel) o bien los propios programas.
– /var/log/kern.log: Aquí están los mensajes que procedentes del Kernel.
– /var/log/daemon.log: Contiene los logs de los demonios que se cargan en el sistema.
– /var/log/mail.log: En caso de tener un servidor SMTP en el equipo, nos muestra información de todos los mensajes que entran y salen por nuestro servidor.
– /var/log/boot.log: Contiene los mensajes de arranque del sistema.
– /var/log/loginlog: Este fichero log contiene un registro de todos los intentos de login fallidos. Solo se registran si se han realizado 5 o más intentos, aunque este valor se puede cambiar en el fichero /var/default/login, en la entrada RETRIES.
– /var/log/sulog: Contiene la información acerca de las ejecuciones de la órden su. Indica la fecha, la hora, el usuario que lanza el comando su y el login que adopta, la terminal asociada y si se ha realizado con éxito (+) o ha fracasado (-). En algunas distros de linux es necesario editar el fichero /etc/login.defs y marcar que si queremos loguear los registros de su.
– /home/user/.bash_history: Este fichero log se suele pasar por alto, al no estar donde los demás, pero lo cierto es que puede contener información muy sensible.
Lo que contiene este fichero es un historial de todos los comandos que hemos ejecutado en nuestra shell bash.
– /home/user/.mysql_history: Este también es muy peligroso, encontraremos este fichero log si tenemos instalado el cliente de MySQL. Contiene todas las órdenes introducidas en el cliente MySQL, por ejemplo si introducimos una orden para cambiar la contraseña del usuario root de una base de datos, en este fichero quedará almacenada la orden, incluida la nueva contraseña en texto plano.
Herramientas para trabajar con logs
Cualquier herramienta de texto puede usarse para trabajar con logssi son de texto. Aquí hay algunas particularmente útiles.
dmesg
Para ver rápidamente el log del último inicio del sistema, usa el comando dmesg. Te mostrará grandes cantidades de texto, así que puedes «entubar» ésta salida para leerla pausadamente, así:
dmesg | more
El comando de arriba te mostrará los mensajes de inicio paginando la informacion.
tail
Este comando nos muestra las 10 ultimas lineas (-n xx seran las que queremos mostrar).A veces quieres leer continuamente las actualizaciones de algo que está ocurriendo, añadiendo el parámetro -f, tail continuará mostrando las nuevas líneas a medida que se vayan agregando al archivo.
tail -f /var/log/messages
El comando de arriba te mostrará las últimas diez líneas de /var/log/messages, y luego continuará monitoreando el archivo mostrando nuevas líneas incorporadas. Para detener el comando tail -f, usa el atajo de teclado CTRL + C para cerrar el proceso.
more
More funciona igual que su versión para DOS. puedes apuntarlo a un archivo o «entubar» su entrada desde otro comando para ver la información pantalla por pantalla. Por ejemplo, para mostrar el contenido del log de inicio de XFree86 haz:
more /var/log/XFree86.0.log
Usa «q» o [Ctrl]-C para salir del programa.
less
Less es otro visor de texto, pero este permite hacer scroll y buscar información mientras se lee un archivo.
less /var/log/messages
El comando de arriba desplegará el contenido del archivo /var/log/messages. Usa «q» para salir del programa. Usa «h» para obtener ayuda acerca del uso de less.
logger
Tambien puedes querer incluir tus propios mensajes dentro un archivo de log. Podrías simplemente añadir el mensaje de logeo al archivo apropiado, pero tendrías que duplicar el estilo de logeo del sistema; también tendrías que cambiar su código si el sistema de logeo fuera cambiado o personalizado. El comando logger te permite enviar tus propios mensajes al sistema de logeo, úsalo en scripts para informar acerca de errores y ejecución de programas.
Personalizando la grabacion de logs
Hay dos servicios o demonios que controlan la grabacion de mensajes, klogd y syslogd. klogd solo graba mensajes del kernel. syslogd trabaja con otros mensajes del sistema, como los de las aplicaciones por ej. Puedes configurar el comportamiento de ambos editando los archivos /etc/syslog.conf y /etc/sysconfig/syslog, respectivamente. La personalización completa de la grabacion de mensajes está más allá del objetivo de este artículo, pero puedes aprender más detalles en los enlaces listados al final. También puede aprender leyendo la página man de /etc/sylogd.conf.
Esencialmente cada mensaje generado por software provee alguna información para identificar su origen y de qué se trata. El archivo /etc/syslog.conf te permite especificar qué hacer con este tipo de mensajes. Puedes guardarlos en los archivos de mensajes, o en algún archivo personal; puedes enviarlos a un host remoto donde será procesado según las reglas de configuración del otro syslogd. Los logeos remotos son una excelente característica de seguridad. Añadiendo sus logs a un sistema remoto puede prevenir una brecha de seguridad que cubra sus rastros alterando los archivos de logs.
Aquí hay un ejemplo de logeo personalizado tomado de la página man /etc/syslog.conf:
Logeo personalizado
Kernel messages are first, stored in the kernel
file, critical messages and higher ones also go
to another host and to the console
#
kern.* /var/adm/kernel
kern.crit @finlandia
kern.crit /dev/console
kern.info;kern.!err /var/adm/kernel-info
La primera regla direcciona cualquier mensaje del kernel al archivo /var/adm/kernel.
La segunda sentencia direcciona todos los mensajes del kernel de prioridad «critic» al host remoto «finlandia». Esto es útil ya que si el host local cae y el disco queda irrecuperable, Ud. no podría leer los mensajes almacenados. Si están en un host remoto también, los podrá leer y determinara la razón de la caída del host local.
La tercera regla direcciona los mismos mensajes de la segunda a la consola local, así la persona que esté trabajando podrá leerlos (también).
La cuarta línea le dice a syslogd que guarde todos los mensajes del kernel de prioridad «info» (kern.info), hasta «advertencia» en el archivo /var/adm/kernel-info. Toda prioridad «error» (err), y superior es excluída.
La posibilidad de personalizar el logeo así provee un muy buen grado de flexibilidad y control sobre el ambiente Linux.
Aquí esta fichero de configuración de syslog (/etc/syslog.conf )
# /etc/syslog.conf Configuration file for syslogd.
#
# For more information see syslog.conf(5)
# manpage.
#
# First some standard logfiles. Log by facility.
#
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
uucp.* -/var/log/uucp.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
# Logging for INN news system
#
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice
#
# Some `catch-all’ logfiles.
#
*.=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
#
# Emergencies are sent to everybody logged in.
#
*.emerg *
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
# news.=crit;news.=err;news.=notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn /dev/tty8
# The named pipe /dev/xconsole is for the `xconsole’ utility. To use it,
# you must invoke `xconsole’ with the `-file’ option:
#
# $ xconsole -file /dev/xconsole […]
#
# NOTE: adjust the list below, or you’ll go crazy if you have a reasonably
# busy site..
#
daemon.*;mail.*;\
news.crit;news.err;news.notice;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole
local2.* -/var/log/ppp.log
Como curiosidad hacer notar que las entradas de ficheros que van precedidos por un guión (-) indican que no se hace un «sync» cada vez que existe una entrada en ese log, de modo que si hay una caida del sistema pueden perderse datos en este fichero.
Ficheros log binarios
– /var/log/wtmp: Almacena toda la información de conexiones y desconexiones al sistema. La estructura de este fichero es utmp. Contiene información como el nombre de usuario, por donde accede, el orígen y la hora de acceso. Al ser un fichero binario, para verlo se necesita una aplicación externa, en este caso se trata del comando last.
– /var/log/utmp: Contiene información de todos los usuarios conectados. No incluye los usuarios que están conectados a servicios como FTP, IMAP, etc, ya que estos servicios no utilizan utmp para loguear.
Como en el caso anterior y en todos los binarios, para verlo es necesario teclear el comando w o who, que dará una salida con los logins de los usuarios conectados, la terminal por la que se han conectado, la fecha y la hora.
– /var/log/lastlog: Contiene la fecha y la hora de la última conexión de cada usuario existente en el sistema. Si un usuario nunca se ha conectado, en vez de salir la fecha y la hora de la última conexión saldrá el mensaje “Nunca ha entrado”. La aplicación para ver la información de este log es el comando lastlog.
– /var/log/faillog: Contiene los intentos de login fallidos en el sistema. Es muy parecido al anterior, pero este únicamente muestra los intentos de login fallidos.
Para verlo ejecutamos el comando faillog.
– Acct (o pacct): Registra los comandos ejecutados por todos los usuarios.Solamente los comandos, los argumentos no. Funciona si está activado el proceso “accounting”, que se activa mediante el comando accton. Si nos dice que no encuentra el comando, es que no lo tenemos instalado, para instalarlo en Debian tecleamos “apt-get install acct & accton”. Este log es bastante eficaz, por ejemplo aunque el atacante pare el proceso acct, en el log aparecerá el comando ejecutado por el atacante para pararlo. El único inconveniente es que si usamos bastante la máquina, este log se hará enorme, con las consecuencias que ello lleva.
Para ver estos logs es necesario ejecutar el comando lastcomm o acctomm.
Otros logs en Linux
Además de syslog y de los logs generados por él mismo, hay otros logs que hay que tener en cuenta para saber en cada momento que ocurre o a ocurrido en nuestro sistema. Enumeramos aquí algunos y su cometido.
/var/log/xferlog Este fichero es creado por los servidores de ftp e indica la fecha de las transferencias de ficheros, los ficheros, cantidad de bytes, etc…
/var/log/apache/access.log Fichero creado por el servidor web apache e indica las conexiones al servidor, con que versión http, si ha sido un GET o un put, etc.
/var/log/apache/error.log Da los errores (categorizados por warn, notice, etc… ) que surgen en el servidor web.
/var/log/setuid.changes Log generado por el programa checksecurity incluido en la distribución Debian y que da un listado de los setuids en el sistema. Se activa en el cron.
/var/log/wtmp Es un log binario que guarda los usuarios del sistema que han hecho logins. No se usa directamente pero si podemos usarlo con la instrucción last por ejemplo.
/var/log/XFree86.0.log
Este log muestra los resultados de la última ejecución del servidor XWindow. Si Ud. está teniedo problemas al iniciar en modo gráfico, este archivo le facilitará casi seguramente algo de información para ver qué es lo que está fallando.
«Rotado» y Replicado de logs.
En tanto en cuanto los logs representan a nuestros sistema, es necesario tener un cuidado con los mismos y «sanearlos» de alguna manera, veremos en primer lugar el rotado de logs y posteriormente el replicado de los mismos para asegurar una consistencia y redundancia que evite problemas en un posible compromiso de la maquina donde residen estos logs.
Rotado
Los logs, especialmente algunos de ellos, tienden a crecer de manera exagerada, de modo que es un uso habitual guardar (en ocasiones comprimidos) los logs de vez en cuando e iniciar un nuevo log. Como ejemplo, tomemos este ‘ls’ de /var/log:
migarcia@migarcia-desktop: ~$/var/log $ ls -1 syslog*
syslog
syslog.0
syslog.1.gz
syslog.2.gz
syslog.3.gz
syslog.4.gz
syslog.5.gz
syslog.6.gz
Vemos que hay un syslog, otro numerado con 0 y los demás numerados y comprimidos. Esto lo podemos hacer con la utilidad logrotate incluyendola en el cron.
La utilidad logrotate tiene un fichero de configuración que podemos comentar:
# see «man logrotate» for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# send errors to root
errors root
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
# RPM packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp or btmp — we’ll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
# system-specific logs may be configured here
Este fichero rige los rotados de logs, en este caso se haran cada semana ( weekly ), guardaran los logs antiguos 4 semanas y creará unos nuevos cada vez que lo rote. Además existe la posibilidad de especificar el comportamiento especifico de algunos ficheros determinados en este caso btmp y wtmp.
Replicado
El replicado de logs está más encaminado a la redundancia y seguridad de los logs que al propio saneamiento. Syslog da la posibilidad de logear de manera remota además de en la propia máquina en otras máquinas de una red, de modo que la misma información este replicada y distribuida por más nodos de la red en caso de que una determinada maquina haya sufrido una intrusión y se haya intentado borrar información.
Describiremos los pasos para hacerlo, enumerandolos:
Arranque de syslog: Activaremos syslog con el parámetro -r en la máquina que va a recibir los mensajes de syslog remotos. Por defecto syslog no permite mensajes remotos.
/etc/services: Es importante incluir una entrada en /etc/services que indique el puerto y protocolo de syslog de este modo:
syslog 514/udp
/etc/syslog.conf: Indicaremos ahora en el fichero de configuración de syslog que mensajes queremos replicar y a que nodos, por ejemplo, podríamos replicarlos todos del siguiente modo:
# Sample syslogd configuration file to
# messages to a remote host forward all.
*.* @hostname
o un subsistema (facility) concreta con sus determinadas prioridades, por ejemplo:
kern.warm @hostname
Es importante hacer algunas aclaraciones en cuanto al replicado, en primer lugar que el transporte se realiza con UDP, es decir nada nos asegura que esos paquetes lleguen a su destino. Existen programas que ya realizan el transporte con TCP. También es necesario hacer notar que corremos el peligro de que exista «sniffing» en la red o que alguien intente enviar logs falsos algunos de los nodos existentes. Algunas de las soluciones pasan por encriptación o por tuneles «seguros»
Utilidades para logs
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
Monitorización de Logs
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/
Logs del Kernel
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/.
