Archivo de la categoría: Administración de sistemas

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

1 respuesta

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)

Deja un comentario

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

Terminar una copia interrumpida con scp

1 respuesta

Hace tiempo que tengo el siguiente alias en mi .bashrc:

alias rescp='rsync --size-only --partial --progress --stats --inplace'

Lo saqué de no se sabe donde, así que no puedo citar la fuente original, pero no soy yo.

Permite terminar un scp después de quedar interrumpido por cualquier motivo (CTRL-C, pérdida de conectividad, …), únicamente transfiriendo lo que restase. Sólo hay que recuperar el comando original y sustituir scp por rescp. Por ejemplo, si falla:

scp -r /etc/bar foo/bar* baz servidor.example.com:/tmp

Podemos continuar con:

rescp -r /etc/bar foo/baz* servidor.example.com:/tmp

Dos notas: necesitas rsync instalado en ambas máquinas, y no termines los nombres de directorio en /. SI: /etc/bar, NO: /etc/bar/. La barra final cambia el comportamiento de rsync y copiaría el contenido de /etc/bar directamente en /tmp en vez de en /tmp/bar).

$ exit