Archivo del Autor: Alberto Gonzalez Iniesta

No pierdas el correo de tus servidores

Históricamente los servidores GNU/Linux han contando con un servidor de correo en sus instalaciones más básicas, aunque sólo fuese para uso propio/interno. Por ello hay aplicaciones como cron, at, logcheck, smartmontools, etc. que dan por hecho que este servicio está presente y bien configurado y lo usan para enviar avisos, algunos de máxima importancia. Por este motivo es importante asegurarse de que nuestra máquina hará llegar los posibles correos que se envíen desde ella a una dirección de correo que sea comprobada de forma periódica. Por ejemplo a nuestra propia dirección de correo.

Como alternativa podríamos entrar en la máquina y mirar el correo en ella (por ejemplo con el comando mail del paquete «mailx» o similares). El problema de esta solución es que hay que tener la disciplina de hacerlo frecuentemente y no escala en el momento que gestionemos varios servidores.

Acciones a realizar para asegurarse de que el correo llegará correctamente a una cuenta externa:

  • El servidor tiene un nombre válido de DNS (servidor.example.net) o pone uno a los correos que salgan de él.
  • El servidor tiene que tener acceso a Internet (para sacar el correo) o al menos a un servidor de correo que usemos como relay.
  • El servidor tiene que ser capaz de resolver entradas DNS (tener un servidor DNS alcanzable en el /etc/resolv.conf), salvo que lo entregue por un servidor de relay.
  • Las cuentas de los usuarios deben apuntar a la cuenta de correo real a la que queremos que llegue el correo.
  • Siempre realizar pruebas (por ejemplo con el comando mail) para comprobar el correcto comportamiento.

No voy a entrar en la configuración de red (salida a Internet y DNS) en este post, porque debería ser trivial. Si entraré en detalle en los otros puntos.

Nombre válido del servidor

La mayoría de los servidores de correo en Internet rechazarán correo proveniente de una dirección no válida, por ejemplo: root@mi_servidor, root@mi_servidor.local o root@mi_servidor.dominio_que_no_exite.com. Por ello debemos asegurarnos de que el nombre completo (FQDN) de nuestra máquina puede ser resuelto por el sistema DNS, o configurar el servidor local de correo para que use un dominio válido (por ejemplo cuando el nombre de nuestro servidor sólo es válido en su red local). En el caso de Postfix podemos usar la variable myorigin para indicarlo:

# En /etc/postfix/main.cf
# En el caso de Debian el valor de la variable está en el fichero mailname
# Podemos cambiarlo ejecutando: echo servidor.example.net > /etc/mailname
# Ejecutar "postfix reload" después de hacer los cambios
myorigin = /etc/mailname
# También podríamos especificarlo directamente
#myorigin = servidor.example.net

Servidor relay

Si nuestra máquina no está conectada directamente a Internet, porque presta un servicio local, lo ideal es que haga llegar todo su correo a un servidor que pueda realizar esta labor. Por ejemplo el servidor de correo que usemos normalmente. Llegados a este punto existen dos posibilidades: que nuestra máquina pueda ser identificada por su IP en el servidor de correo (y por tanto este último acepte su correo directamente) o que esto no sea posible y por tanto nuestra máquina tenga que identificarse con un usuario y contraseña SMTP en el servidor (como lo haría cualquier cliente de correo). Como fan de Postfix, pondré los ejemplos de configuración para dicho software. Esta sería la configuración para que un servidor (con Postfix instalado) use a otro (relay) para sacar su correo interno:

# El correo se envía a 10.20.30.40 para que éste lo envíe al destinatario final
# También podemos usar el nombre del servidor de correo en vez de su IP
relayhost = 10.20.30.40
# En caso de necesitar autenticación en el servidor relay,
# descomentar las siguientes líneas y crear el fichero indicado
#smtp_sasl_auth_enable = yes
#smtp_sasl_password_maps = hash:/etc/postfix/passwords

En el caso de necesitar autenticación, crearíamos el fichero passwords con el siguiente contenido y posteriormente ejecutaremos el comando «postmap /etc/postfix/passwords» como root:

# Contenido del fichero /etc/postfix/passwords
# Servidor          usuario_smtp:clave_smtp
10.20.30.40         fulanito@example.com:s3cr3t0s
# El campo servidor debe coincidir exactamente
# con el indicado en la opción relayhost

Dirigir el correo de los usuarios locales a una cuenta externa

Por defecto el correo para usuarios locales (root, logcheck, tu propio usuario) se quedará en la propia máquina. Para que llegue a nuestro correo tenemos varias opciones. Mi preferida es mandar todos los correos de usuarios de sistema a root, y el de éste a mi usuario local:

# /etc/aliases
logcheck: root
nagios: root
www-data: root
# [ los que ya vengan por defecto]
root: agi

Importante: Después de modificar el fichero /etc/aliases, debemos ejecutar el comando «newaliases» como root.

Llegados a este punto tenemos dos opciones. Una es meter la siguiente entrada en el /etc/aliases también:

agi: example@example.net

La otra es crear un fichero llamado «.forward» en nuestro $HOME con nuestra dirección de correo como único contenido:

echo "example@example.net" > ~/.forward

Esta última solución tiene como ventaja que no requiere del uso de root (o la ejecución de newaliases), por lo que es más útil para usuarios que no tengan dichos privilegios.

Prueba que funciona

Una vez todo configurado, queda probar que el correo llega a su destino. Para ello basta con ejecutar «ps ax | mail root» o «ls -l /etc | mail mi_usuario» o «cat /etc/hosts | mail logcheck» y comprobar que el correo llega a nuestra dirección de correo. En caso contrario habrá que empezar a revisar los logs de correo.

Es vital que se realice esta comprobación, incluso de vez en cuando de forma manual si la máquina no suele generar correo. El objetivo es evitar que el día que la herramienta de monitorización de discos (por poner un ejemplo), empieza a detectar errores y notificarnos por correo, nos enteremos inmediatamente y no pasados unos días cuando el disco esté completamente muerto.

$ exit

Monitorización de cambios en ficheros con tripwire (II)

Si has instalado tripwire, habrás empezado a recibir correos con los cambios en el sistema de ficheros desde la última actualización de la base de datos.

En algunas ocasiones son cambios que has realizado tú, o cualquier otra persona o proceso, y que simplemente requieren que actualices la base de datos (tripwire -m u) para que queden registrados. Pero en otras ocasiones se trata de ficheros o directorios que están en constante cambio (spools de correo o impresión, directorios de usuarios, bases de datos, logs, etc…).

En este caso debemos enseñar a tripwire que esos cambios son normales (dentro de unos límites) y evitar que en el correo con el informe diario vengan listados como cambios no esperados. Esto es de vital importancia porque acabaremos acostumbrándonos a que el correo de tripwire liste un montón de cambios (y hará inútil el uso de la herramienta) y porque no podremos diferenciar un cambio normal en un fichero que varía con el tiempo, por ejemplo que cambie su fecha de modificación, de un cambio sospechoso, por ejemplo que cambie su propietario o permisos. Repito lo que dije en mi post anterior. El correo diario de tripwire debe limitarse a decir: No violations.

El fichero de políticas (/etc/tripwire/tw.pol) nos permite definir que ficheros no pueden cambiar en absoluto, cuales pueden ver su contenido modificado pero no otros atributos como propietario o permisos, cuales debemos ignorar porque varían aleatoriamente (como el $HOME de un usuario), etc. El fichero de políticas se genera partiendo de un fichero de texto (en los paquetes de la distribución suele venir uno base: /etc/tripwire/twpol.txt), es este fichero en el que definimos las reglas y posteriormente generamos el fichero de políticas real.

Adicionalmente con la documentación de tripwire (normalmente bajo /usr/share/doc/tripwire) viene un fichero de ejemplo hiper-documentado con casi todas las posibilidades que permite el fichero de políticas, su nombre es policyguide.txt.

Sintaxis

En el fichero de políticas podemos encontrar (entre otras cosas):

  • Propiedades a tener en cuenta en los ficheros o directorios a vigilar. Por ejemplo:
 g - El grupo propietario
 i - El número de inodo
 l - El tamaño de un fichero va en aumento (para logs, aunque cuando sean rotados fallaría)
 m - La fecha de modificación
 n - El número de enlaces duros. Que varía sobre todo en directorios con la creación o borrado de subdirectorios
 p - Los permisos
 s - El tamaño
 t - El tipo de fichero
 u - El propietario
 C - CRC32 del contenido
 M - MD5 del contenido
 S - SHA del contenido
  • Variables que nos permiten organizar mejor nuestro fichero. Su contenido puede ser cualquier valor que podamos usar en el fichero de políticas (el nombre de un directorio, una lista de propiedades comunes que podemos aplicar a varios ficheros, etc..):
# Para agrupar propiedades
Intocable = +pinugtsdbmCM-rlacSH;
# Y luego usarlo en reglas
/etc/passwd -> $(Intocable);
  • Ficheros o directorios sobre los que aplicar reglas:
# /etc no debe cambiar
/etc -> +pinugtsdbmM-rlacCSH;
# el mtab varia en su contenido
/etc/mtab -> +pnugtd-ismMrlacCSHM;
# este fichero puede estar o puede no estar, lo ignoramos totalmente
!/etc/foobar;
  • Agrupaciones de ficheros/directorios para aplicarles la misma gravedad ante cambios, notificar a unos destinatarios concretos o ejecutar chequeos sólo sobre ese grupo:
(Rulename=sistemabase, severity=90)
{
/etc -> +pinugtsdbmM-rlacCSH;
/bin -> +pinugtsdbmM-rlacCSH;
/lib -> +pinugtsdbmM-rlacCSH;
/usr -> +pinugtsdbmM-rlacCSH;
}
(Rulename=aplicacion, emailto=desarrollo@example.com, severity=50)
{
/usr/local/foo -> +pinugtsdbmM-rlacCSH;
/usr/local/foo/data -> +pinugtd-srlbacmCMSH;
}

 Definiendo una política

El verdadero trabajo con tripwire consiste en ajustar una política a nuestro sistema. Podemos partir de la que viene definida por el fichero de políticas que viene en el paquete (o en la instalación desde fuentes). O podemos comenzar con una de cero. Esta última opción será más dura, pero posiblemente cubrirá mejor nuestras necesidades.

Empezaríamos definiendo una regla que abarque todo el sistema de ficheros y que indica que no debe cambiar nada (luego iremos corrigiendo). Para mayor comodidad podemos definir alguna variable que englobe tipos de cambios comunes (ficheros inmutables, ficheros que cambian su contenido, cambios en las propiedades pero no en el contenido, etc..)

@@section FS

# INTOCABLE. Ignoramos la fecha de acceso, alguna propiedad
# menos interesante y los checksums CRC, Haval, y SHA1 por
# economía en los chequeos. Dejamos el MD5 para comprobar la
# integridad del contenido del fichero.
# Para los más paranoicos, mover CSH a continuación de la "M"
# Equivalente a la variable predefinida por tripwire llamada
# "ReadOnly"
INTOCABLE = +pinugtsdbmM-rlacCSH ;

# CAMBIA_CONTENIDO. Ficheros en los que el contenido cambia,
# pero que deben mantener otros atributos (propietarios,
# permisos, inodo, dispositivo,...)
# Igual que la variable "Dynamic" de tripwire
# CAMBIA_CONTENIDO = $(Dynamic)
CAMBIA_CONTENIDO = +pinugtd-srlbacmCMSH ;

/ -> $(INTOCABLE) ;

Si ya tenemos una política (ya estamos haciendo chequeos diarios), tendremos que cambiar la política con el siguiente comando:

# tripwire -m p -Z low mi_politica.txt

El motivo de usar la opción «-Z low» es que nos permita cambiar la política aún cuando ya hay ficheros que se salen de la política anterior. De otra forma no nos dejaría realizar el cambio. Si no hemos usado ninguna política hasta ahora, es decir no estamos ejecutando tripwire todos los días, deberemos de firmar nuestra política e inicializar la base de datos:

# twadmin -m P -S mi_politica.txt
# tripwire -m i

En ambos casos podemos encontrarnos con advertencias de este tipo:

The object: "/boot" is on a different file system...ignoring.
The object: "/dev" is on a different file system...ignoring.
The object: "/proc" is on a different file system...ignoring.
The object: "/run" is on a different file system...ignoring.

Se trata de sistemas de ficheros diferentes al de la partición raíz. Esto significa que debemos de añadir una regla para cada uno de ellos. En algunos casos (por ejemplo en /boot con el kernel y el gestor de arranque) querremos chequearlos y en otros ignorarlos por completo, o aplicar reglas menos estrictas. En este caso podemos añadir las siguientes reglas a nuestro fichero de políticas:

# Comprobar /boot. Necesario por ser un sistema de ficheros
# diferente al raíz
/boot -> $(INTOCABLE) ;

# Para /dev hay una variable que vigila permisos, propietarios
# y algún atributo propio de dispositivos: $(Device)
/dev -> $(Device) ;

# /proc varía mucho lo ignoramos por completo. Pero podemos
# vigilar las variables de configuración en /proc/sys
!/proc;
/proc/sys -> $(INTOCABLE) ;

# En /run tenemos ficheros de PID y sockets, podemos vigilarlos
# pero teniendo en cuenta que cambiaran sus contenidos, fechas,
# ID de dispositivo e inodo. Podemos partir de CAMBIA_CONTENIDO
# y quitar estas cosas:
/run -> $(CAMBIA_CONTENIDO) -id ;

Una vez más tendríamos que actualizar la política con el contenido de nuestro fichero de texto:

# tripwire -m p -Z low mi_politica.txt

Y una vez más veremos cosas que corregir, por ejemplo de ficheros que no se pueden leer:

### Filename: /proc/sys/net/ipv6/route/flush
### Permission denied
### Continuing...
### Warning: File could not be opened.
### Filename: /proc/sys/vm/compact_memory
### Permission denied

Así que añadimos unas reglas que ignoren esos ficheros por completo:

# Algunos ficheros en /proc/sys no se pueden leer, los ignoramos
!/proc/sys/net/ipv4/route/flush;
!/proc/sys/net/ipv6/route/flush;
!/proc/sys/vm/compact_memory;

Volveríamos a ejecutar la actualización de política (-m p) y si ya no tenemos errores mi recomendación es ejecutar un chequeo (-m c). De esta forma vamos a tener inmediatamente un listado de ficheros que están cambiando (logs, bases de datos, directorios temporales) y que por tanto hay que añadir nuevamente a la política. Y el segundo motivo es que los ficheros de tripwire habrán sido modificados con la actualización de la política y por tanto un chequeo y posterior actualización de la base de datos (-m u) evitará que en el chequeo nocturno salgan como modificados con nuestro consiguiente susto 🙂

En mi caso un chequeo me devolvió campos en el directorio de la base de datos, el spool del servidor de correo y algunos logs. Así que añadiré unas reglas que los contemplen:

# Los logs varían, pero los permisos y propietarios no.
# Si lo hará su inodo
/var/log/ -> $(CAMBIA_CONTENIDO) -i ;

# La propia base de datos de tripwire varía cuando se actualiza,
# así que no podemos vigilar el contenido. Por eso viene la
# recomendación de tenerla en un dispositivo que evite su
# modificación
/var/lib/tripwire/ -> $(CAMBIA_CONTENIDO) ;
# El directorio de informes de tripwire va creciendo
# No nos interesa el contenido, sí sus permisos
/var/lib/tripwire/report -> $(CAMBIA_CONTENIDO) (recurse=false) ;

# Del spool de postfix nos interesa su estructura, no su contenido
# Miramos sólo el primer nivel
/var/spool/postfix/ -> $(CAMBIA_CONTENIDO) -i (recurse=1) ;

# /tmp es el caos, vigilamos sólo el propio directorio
/tmp -> $(CAMBIA_CONTENIDO) (recurse=0) ;

# El HOME de root puede variar por su uso
/root -> $(CAMBIA_CONTENIDO);
# El .viminfo cambia de inodo con el uso de vim
/root/.viminfo -> $(CAMBIA_CONTENIDO) -i;

Y repetimos el proceso una vez más. Digamos que quedaría un modus operandi de este tipo:

## Editamos el fichero txt de reglas y actualizamos la política
tripwire -m p -Z low mipolitica.txt
## Ejecutamos un chequeo
## (sin prioridad de io, para dejar a la máquina hacer su trabajo)
ionice -c 3 tripwire -m c
## Si lo único que sale del chequeo son los cambios en los ficheros de tripwire,
## actualizamos la base de datos con ellos y listo
tripwire -m u -r /var/lib/tripwire/report/$( hostname ) -FECHA-HORA.twr

Una vez tengamos la política afinada, sólo tendremos que actualizar la base de datos (-m u) cuando hagamos cambios fuera del funcionamiento normal de la máquina (actualizaciones, cambios de configuración, etc.).

Una vez más, el objetivo es:

===============================================================================
Object Summary: 
===============================================================================

-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------

No violations.

===============================================================================
Error Report: 
===============================================================================

No Errors

-------------------------------------------------------------------------------
*** End of report ***

 

$ exit

Monitorización de cambios en ficheros con tripwire (I)

Introducción

Tripwire es una de las primeras herramientas en el campo de la verificación de integridad del sistema de ficheros. Esto que suena tan retorcido no es más que una base de datos con toda la información de los ficheros y directorios (tamaño, permisos, checksum, inodo, fechas, …) en una máquina que permite a una tarea periódica verificar que nada ni nadie modifica un fichero sin que tú te enteres. Originalmente tripwire era software propietario (sí, sé que hoy hay otro término más aceptado. Soy viejo), pero posteriormente fue publicado bajo licencia GPL. Hay otras aplicaciones similares (AIDE es la más popular y surge como alternativa cuando tripwire no era libre) pero no son tripwire 🙂

El objetivo principal de tripwire, y la categoría de software a la que pertenece, es la detección de intrusos. Es decir, avisar de una presencia no autorizada en una máquina mediante la detección de cambios no esperados en sus ficheros. Adicionalmente, a mí me ha permitido saber de cambios realizados por clientes en máquinas que administro junto a ellos, o validar unos ficheros recuperados de un backup después de la restauración (por ejemplo, que sus permisos/checksum son los originales). Hoy considero tripwire imprescindible en cualquier servidor, necesito saber que el software que contiene es confiable y está tal y como lo dejé la última vez.

Como siempre podemos instalar desde fuentes [1][2], o usar los paquetes disponibles en las distribuciones más populares: Debian y derivadas, (Open)Suse o Fedora/RH y derivadas (en el repositorio EPEL). Aunque en el resto del artículo haré mención al paquete y los ficheros en Debian, el funcionamiento y configuración en el resto de distribuciones es muy similar.

Componentes de tripwire

Dos ficheros de configuración permiten configurar tripwire:

  • /etc/tripwire/tw.cfg (generado partiendo de twcfg.txt). Este fichero contiene los paths (directorios y ficheros) donde tripwire almacena la base de datos, los informes, los ejecutables, etc.), así como la configuración para el envío de correo con los informes periódicos. En el caso de Debian, y creo recordar que en Fedora/RH, no es necesario modificar nada de este fichero en principio. La comprobación se realiza diariamente (/etc/cron.daily) y es la salida de la ejecución la que cron nos hace llegar por correo (a root por defecto). Recordad que es importante tener correctamente configurada la salida de correo de la máquina. Tengo pendiente una entrada de blog a este respecto…
  • /etc/tripwire/tw.pol (generado partiendo de twpol.txt). El fichero de políticas de tripwire es el principal a la hora de usar y adecuar tripwire a nuestro sistema. En él definimos qué ficheros pueden cambiar, o que tipos de modificaciones pueden sufrir. Por ejemplo si puede cambiar su contenido, pero no sus permisos. Tiene una sintaxis especial que veremos en el próximo post.

Dos claves:

  • site key (/etc/tripwire/site.key). Usada para firmar los ficheros de configuración y politicas, evitando cambios no autorizados. Irá protegida con una contraseña que necesitaremos para realizar cambios en dichos ficheros.
  • local key (/etc/tripwire/HOSTNAME-local.key). Usada para firmar  la base de datos. Protegida con una contraseña necesaria cuando sea necesario actualizar la base de datos, por ejemplo después de instalar algún paquete.

En el caso del paquete Debian, las claves pueden ser creadas (y sus contraseñas introducidas) en la instalación del mismo, o posteriormente.

La base de datos, con toda la información de los ficheros vigilados por tripwire. Suele almacenarse en /var/lib/tripwire/HOSTNAME.twd. Es recomendable que tanto la base de datos como las claves se almacenen en un sistema de ficheros no modificable (montado en remoto, en un CDROM,…), impidiendo que un posible atacante pueda reescribirlos a voluntad. Dicho esto, también es verdad que todo depende del nivel de paranoia (o enemigos) tengamos, y que el sólo hecho de estar usando una herramienta como ésta dificulta la tarea de permanecer oculto a niveles fuera de los script-kiddies o atacantes vulgares. También se podrían usar sistemas como SELinux o apparmor para darles una seguridad adicional.

Por último mencionar el directorio /var/lib/tripwire/report/ donde se almacenarán los informes creados en cada ejecución en modo comprobación de tripwire (normalmente por el cron, o de forma manual depués de realizar cambios en el sistema de ficheros y para alimentar la base de datos de nuevo).

Instalación

No soy muy amigo de instalar cosas desde fuentes en mis máquinas, las actualizaciones posteriores son bastante más pesadas que con un gestor de paquetes, además de tener que estar pendiente de cuándo salen nuevas versiones que solventen problemas de seguridad. Así que para instalar os recomiento vuestro gestor de paquetes favorito (apt, yum, zypper, …) y un repositorio oficial o al menos con cierto reconocimiento. En el caso del paquete de Debian (y derivadas), en la instalación se nos ofrecerá crear las claves de sitio y local, así como crear los ficheros de configuración mencionados desde los ficheros txt de ejemplo. Si optáis por hacerlo en este momento podéis saltar hasta la Inicialización de la base de datos, en otro caso, estos serían los pasos manuales (a ejecutar si no lo hace el paquete, por ejemplo en RedHat o Suse):

Generar la clave de sitio:

# twadmin -m G -S /etc/tripwire/site.key

Generar la clave local (de host):

# twadmin -m G -L /etc/tripwire/$( hostname )-local.key

Después de revisar los ficheros, en /etc/tripwire, de configuración fuente (twcfg.txt y twpol.txt, a este último le dedicaremos la siguiente entrada de blog), generar los ficheros firmados (tw.cfg y tw.pol):

# twadmin -m F -S /etc/tripwire/site.key /etc/tripwire/twcfg.txt
# twadmin -m P -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Inicialización de la base de datos

Una vez tenemos las claves y los ficheros de configuración preparados, tendremos que crear la base de datos por primera vez. Lo ideal es que el fichero de políticas ya esté lo más adaptado posible a nuestro sistema, pero para empezar podemos usar el que venga de serie. Luego ya iremos ajustando la política. Creamos la base de datos con el siguiente comando:

# tripwire -m i

Comprobación de la integridad de ficheros

Una vez creada la base de datos, la tarea del cron la usará como referencia para comprobar los ficheros en el sistema, todo cambio no descrito en la política de tripwire aparecerá en su informe. Como comentaba anteriormente, por defecto los paquetes de tripwire instalan una tarea que se ejecuta diariamente y que por salida estándar muestran el resumen del informe correspondiente. Si tenemos bien configurado el correo del usuario root, dicho resumen nos llegará a nuestro correo.

Podemos realizar una comprobación con tripwire en cualquier momento, sólo hay que ejecutar el siguiente comando (recomiendo el uso de ionice(1), para dar prioridad a los servicios que corren en la máquina sobre la ejecución de tripwire, bastante intensa sobre el disco):

# ionice -c 3 tripwire -m c

Al final de la ejecución veremos un resumen de los cambios no «autorizados». Si queremos ver en más detalle por qué se menciona algún fichero o directorio, podemos ver el informe detallado con el siguiente comando:

# twprint -m r -r /var/lib/tripwire/report/andromeda-20140506-062540.twr

Donde «andromeda» es el nombre de la máquina, seguido de la fecha y la hora a la que se creó el informe. Este comando nos dará la información de qué, concretamente, ha cambiado en un fichero o directorio listado (sus permisos, su tamaño, su contenido, el número de inodo, …).

Actualización de la base de datos

Si los cambios observados por tripwire en el sistema de ficheros son legítimos (los hemos hecho nosotros, o son el producto de una aplicación que corre en la máquina o de un usuario autorizado), debemos actualizar la base de datos con dicha información, para que no siga informando de dichos cambios. Por ejemplo si cambiamos algún fichero de configuración, o después de realizar una actualización de paquetes, deberemos ejecutar una comprobación (que informará de los cambios que hemos hecho) y posteriormente usar el informe generado para actualizar la base de datos con las novedades ejecutando este comando:

# tripwire -m u -r /var/lib/tripwire/report/20140506-121030.twr

En este ejemplo estaríamos incorporando los cambios detectados en la comprobación de las 12:10:30 del seis de mayo en la base de datos. En realidad no hay por qué incorporar todos los cambios, al ejecutar el comando anterior podemos marcar qué cambios queremos aceptar y cuáles no queremos cambiar en la base de datos (porque vamos a crear una política para ellos, o borrar un fichero nuevo que sólo tendremos temporalmente).

Resumen

Con todo lo visto anteriormente nos queda un «modus operandi» como el siguiente:

  • Todas las noches nos llegará un correo con el resumen de los cambios en el sistema de ficheros. Si son aceptables tenemos dos posibilidades: a) son cambios puntuales y debemos actualizar la base de datos (tripwire -m u -r /path/al/fichero/con/el/informe), b) son cambios que se produciran con frecuencia (fecha de modificación de un log, directorio que va incluyendo más ficheros cada día, …) y deberemos actualizar la política sobre dicho objeto (en el próximo post).
  • Cuando hagamos cambios en el sistema de ficheros que no cubran las políticas (en ficheros bajo /etc que están declarados como inmutables, porque instalamos algo nuevo, …), deberemos ejecutar un chequeo (tripwire -m c) para posteriormente actualizar la base de datos con los cambios (que estarán reflejados en el informe recién creado).

En la próxima entrega veremos cómo se definen las políticas de tripwire para que no nos maree con los cambios que se producen constantemente en nuestro servidor por el mero hecho de estar prestando servicios. Es importante que los informes de tripwire que nos lleguen por correo todos los días no suelan tener ninguna «violación de las políticas», ya que de otra forma nos acostumbraremos a ver ficheros o directorios en dichos informes y dejaremos de darles importancia. El contenido ideal de un correo de tripwire dice:

No violations.

Cualquier otra cosa requiere actualización de la base de datos, actualización de las políticas, o reinstalación y restauración de backups 😛

$ exit