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