Taller de Seguridad en Linux: Ficheros de logs, logcheck y tripwire

2. Ficheros de logs, logcheck y tripwire

2.1 Ficheros de logs

Presentaremos aqui los fichero de logs mas habituales en un sistema Linux, y la configuracion de alguno de ellos como syslog.

Los ficheros de log en un sistema linux, residen en el directorio

/var/log

y aquí es donde deberían logear todos los programas.

syslog

syslog es un log del sistema y del kernel que nos puede dar importante información de eventos que suceden en el sistema y en sus programas. Syslog provee incluso alguna llamada para que los programas que corren en el sistema logeen en el propio syslog. Todas las entradas que presenta syslog tienen como mínimo una fecha y una hora, el nombre de la maquina y del programa que generó el evento. El fichero de configuración de syslog es

/etc/syslog.conf

y podemos ver un ejemplo de fichero de configuración.

#  /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

Aunque no nos pararemos a ver este archivo de configuración con demasiado detalle, si es interesante ver en base a que criterios trabaja syslog. Podemos ver en el fichero de configuración, lineas que nombran una "facility" ( subsistema de aplicación ) y separados por un punto las palabras crit,debug,info,notice o warn. Por ejemplo:

 mail.warn
-/var/log/mail.warn

Lo que realiza syslog es logear los eventos dependiendo de la aplicación y de la prioridad del evento ( crit = critical, warn=warning, info=information, err=errors .... ) y reenviandolos a syslog o a otros logs separados para "categorizar" mejor cada uno de los eventos, puede usar también comodines de modo que sea posible incluir una linea de este tipo

 kern.* -/var/log/kern.log

de modo que todos los mensajes del kernel vayan a fichero kern.log, sean del tipo que sean.

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.

Otros logs en Linux

Además de syslog y de los logs generados por el 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 version 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 el los usuarios del sistema que han hecho logins. No se usa directamente pero si podemos usarlo con la instrucción last por ejemplo.

"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 compromidos ) los logs de vez en cuando e iniciar un nuevo log. Como ejemplo, tomemos este 'ls' de /var/log:

emain:/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 demas 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"

Logcheck y tripwire

En esta sección veremos dos utilidades una para realizar chequeos automáticos de logs y hacer saltar alarmas por mail de modo automático y la otra para realizar chequeos de integridad de los ficheros de un sistema.

Logcheck

Logcheck permite generar alarmas por mail cuando se encuentran determinados patrones en los logs. El fichero de configuració esta en /etc/logcheck/logcheck.conf y posteriormente tenemos unos ficheros donde existen una serie de patrones que aparecen en casos de intentos de "hacking" etc..., vemos un listado de este directorio:

emain:/etc/logcheck# ls
logcheck.conf     logcheck.ignore      logcheck.violations.ignore
logcheck.hacking  logcheck.violations

y un mail generado por un error en una autentificación:

Date: Wed, 17 May 2000 23:02:02 +0200
From: root <root@emain.celtic.org>
To: root@emain
Subject: emain 05/17/00:23.02 system check


Security Violations
=-=-=-=-=-=-=-=-=-=
May 17 22:09:38 emain PAM_unix[579]: authentication failure; david(uid=1000)
->
root for su service
May 17 22:09:40 emain su[579]: pam_authenticate: Authentication failure

Tripwire

Tripwire es una utilidad aparentemente simple que recorre nuestros sistemas de ficheros y extracta de ellos una suma MD5 que deberemos de guardar en un soporte completamente seguro fisicamente ( por ejemplo un diskette ) y la cual compararemos con la siguiente suma MD5 de los ficheros que hagamos para asegurar que siguen igual y que sus tamaños no han cambiado, de haberlo hecho es casi seguro que estamos ante una intrusión.

Tripwire se basa en un fichero de configuración que reside en

/etc/tripwire/

un ejemplo del mismo:

#
# tripwire.config for Linux/Debian machines
#
# I have tried to provide for a reasonable, minimal configuration file.
# You will have to tune this to your own taste and needs. -- pw.
# 
# I even removed some more stuff to make it fit on a floppy. -- MM

# Define variables for searching devices, tmp directories, and logfiles
@@define DEVSEARCH E+ins
@@define TMPSEARCH E+ugp
@@define LOGSEARCH L-i

# Check all files:
# (We also mention some directories explicitly, as
#  these are often put on a separate filesystem)
/               R
/usr            R
/usr/local      R

# Don't do these
# (/mnt is for temporarily mounted filesystems;
#  do a minimal check on /home anyway;
#  no spool files except the crontab for root):
!/mnt
=/home
!/root

#
# I don't like /var since too many files change automatically. -- MM
#
#/var           R
!/var

# Log files:
#/var/log       @@LOGSEARCH
#/var/account   @@LOGSEARCH

#  /dev, /tmp and /var/tmp
#
/dev            @@DEVSEARCH
=/tmp           @@TMPSEARCH
=/usr/tmp       @@TMPSEARCH

# no checksums for less important files (documentation, word lists):
# you might want to add /usr/X11R6/man if you have X installed
!/usr/doc
!/usr/dict
!/usr/info
!/usr/man
!/usr/src

# but do check the kernel sources
/usr/src/linux

Vemos que en este fichero indicaremos de que directorios no queremos que se hagan copias bien por ser ficheros muy cambiantes o bien por que no tienen información sensible.

El primer paso para analizar con tripwire es la creación de una base con las sumas de los ficheros de los sistmas:

 tripwire -initialize

con esto el programa creará una base de datos que guardará en

/usr/lib/tripwire/databases

o en un lugar indicado previamente ( homde de root ) y que deberemos guardar en un medio fisicamente seguro y nunca accesible por red, para que no se puedan operar cambios en las sumas.

Posteriormente con la orden

 tripwire -initialize -d basededatos

el programa irá a buscar la base de datos anterior que comparará con el estado actual del sistema para comprobar que no ha habido cambios en los binarios.

Next Previous Contents