Copias de Respaldo II: Verificación de Integridad

Enviado por Black Rider el 27 Octubre, 2011 - 15:15.

Una faceta que muchos olvidan incluir en su política de backups es la comprobación de la integridad del sistema antes de copiarlo. Imaginemos una persona que tiene un sólo ordenador y que emplea un disco duro externo para hacer sus copias de respaldo. Ésta persona se cree muy lista, porque guarda tres capturas distintas del sistema (la del mes pasado, la de hace dos meses y la de hace tres). Desgraciadamente, un error de software ha corrompido un archivo de su ordenador, pero nadie se ha dado cuenta de ello. Nuestra persona hace un nuevo backup del sistema y borra la copia de respaldo más antigua, con lo cual ahora tiene otras tres copias: la nueva (que tiene los datos corruptos) y las dos anteriores.

Si el error sigue sin detectarse, nuestro amigo hará una nueva captura del sistema dentro de un mes, con lo cual tendrá dos copias corruptas y una sana. Un mes más tarde, todas sus copias estarán corruptas. Cuando el error finalmente se detecte, no quedarán copias sanas del archivo.

¿Cómo se evita esto? El remedio más sencillo consiste en mantener un historial largo como un día sin pan. Si tus copias de respaldo retroceden un año en el tiempo, una corrupción de datos que sea detectada en menos de doce meses probablemente sea subsanable.

Ahora bien, el administrador precavido debe tener un as en la manga. Uno no puede confiar en ser capaz de detectar los errores en el margen de tiempo dado sólo mediante inspección manual, a menos que esté respaldando pocos archivos. En casos donde el volumen de datos es notable, es recomendable emplear una herramienta de comprobación de integridad.

VERIFICAR LA INTEGRIDAD DEL SISTEMA SANO

Tu copia de respaldo sólo es tan buena como el sistema del que se origina, así que el primer paso es asegurarse de que los archivos que estamos copiando están sanos. Para ello, nos podemos servir de herramientas como Aide o Tripwire.

Aide es una herramienta concebida para desempeñar funciones de Host Based Intrusion Detection System. En otras palabras, es un mecanismo de seguridad. Lo que Aide hace es crear un banco de datos con las propiedades que tienen los archivos de un sistema dado, de modo que si un Black Hat se cuela en tu sistema y empieza a borrar o a corromper tus datos, estos cambios serán detectados cuando Aide descubra que las nuevas propiedades no se parecen a las que contiene el banco de datos previo. Al ser un mecanismo de seguridad, Aide es capaz de realizar multitud de pruebas y verificaciones simultáneas: mtime, ctime, tamaño, checksums de varios tipos, inodos...

Imagino que ya estás imaginando cómo emplear Aide en tu política de copias de respaldo. Básicamente, los pasos para instalar, configurar y usarlo son los siguientes:

1-Lo instalas con aptitude o con el software de tu distribución.

2-Lo configuras. Aide tiene un archivo de configuración principal situado en /etc/aide.conf

El archivo de configuración típico tiene la siguiente forma:

database=file:/mnt/usb/aide.db
database_out=file:/mnt/usb/aide.db.new
gzip_dbout=yes

/etc/ld.so.cache p+ftype+l+u+g
/etc/ntp/drift   p+ftype+l+u+g

/boot R
/etc R
/bin R
/lib R
/usr/lib R
/usr/libexec R
/usr/lib64 R
/lib64 R
/usr/bin R
/usr/local/bin R
/sbin R
/usr/sbin R
/usr/local/sbin R
=/var/log R

Donde los apartados importantes son el de configuración inicial y la lista de comprobación.

Las líneas de configuración inicial indican parámetros generales de funcionamiento. En el ejemplo, estas son:

database=file:/mnt/usb/aide.db
database_out=file:/mnt/usb/aide.db.new
gzip_dbout=yes

Aquí se muestra que la base de datos que se usará para verificar la integridad del sistema se encuentra en /mnt/usb/aide.db, que las nuevas bases de datos que se generen irán a parar a /mnt/usb/aide.db.new y que las basas de datos serán comprimidas.

La lista de archivos a verificar contiene los archivos que se verificarán y cómo se verificarán. Tiene la forma [ruta del archivo] [lista de propiedades a comprobar]

El parámetro de verificación R es muy paranoico. Registrará cambios de permisos, cambios del tipo de archivo, inodos, nombre del enlace del archivo, el número de enlaces al archivo, el usuario que lo posee, el grupo, el tamaño, el mtime, el ctime y un hash md5. R es un parámetro aceptable para entornos de seguridad, pero si quieres comprobar la integridad de una partición que contiene 500Gb de películas, únicamente para propósitos de backup, nos conviene otro tipo de verificación más rápida.

Un archivo de configuración para un Aide empleado como herramienta de detección de errores podría ser algo así:

database=file:/mnt/usb/backup.db
database_out=file:/mnt/usb/backup.db.new
gzip_out=yes

/home/usuario/carpeta i+b+s+m+c

Esto hará que Aide compruebe cualquier cambio que se efectúe en los contenidos de /home/usuario/carpeta a mayor velocidad que con la opción R, pero con una fiabilidad suficiente para nuestro propósito actual.

3-Creas tu base de datos. Se recomienda hacerlo en un medio extraíble.

# aide --init

Con el /etc/aide.conf de ejemplo, la base de datos se escribirá en /mnt/usb/aide.db.new

Renombramos y firmamos la base de datos.

#cd /mnt/usb
#mv /mnt/usb/aide.db.new /mnt/usb/aide.db
#gpg -ba aide.db

Lo de la firma no es realmente necesario, pero a mí me gusta emplearla.

4-Cuando vayas a hacer tu próxima copia de respaldo, verifica el sistema para detectar posible corrupción.

#gpg --verify aide.db.asc # Para comprobar la firma digital.
#aide --update

Esto generará un informe en pantalla, explicando detalladamente qué archivos han cambiado y cómo. Los cambios más aberrantes (por ejemplo, archivos que deberían ocupar diez megas pero ocupan 0) pueden indicar una corrupción de datos (como los provocados por un apagón en un sistema de ficheros que use delayed allocation).

También se generará un banco de datos actualizado en /mnt/usb/aide.db.new. Podremos borrar el banco antiguo, renombrar el nuevo y volverlo a firmar.

Lógicamente, Aide tiene más sentido cuando se usa con directorios que no cambian de forma significativa entre backups. Meter un “/home R” en aide.conf no es buena idea, ya que ~.mozilla y otros directorios del usuario cambian mucho con el tiempo y podrían inundar nuestros informes.

VERIFICACIÓN DE INTEGRIDAD DE LAS COPIAS DE RESPALDO

Cuando hagas una copia de respaldo, puede ser aconsejable tomar su checksum. Hacer un hash de un backup nos servirá para verificar que las copia de respaldo están sanas si alguna vez las necesitamos.

Ejemplos:

Guardar el Hash de un archivador Dar en el archivo Checksum.txt:

$openssl dgst -md5 copia_de_respaldo.dar >> Checksum.txt

Hash de mis planes para conquistar el mundo:

$openssl dgst -sha512 World_Domination_Plan.tar.asc >> Checksum.txt

Si en algún momento del futuro repites esta orden contra el mismo archivo y obtienes un checksum diferente, es que el archivo ha cambiado y hay riesgo de corrupción.

Nótese que md5 es útil para la comprobación de errores, pero es un algoritmo propenso a las colisiones y no se considera apto para materia de seguridad. Para archivos importantes, quizá quieras emplear artillería más pesada, como los sha256, sha384 o sha512.

La lista con los checksums obtenidos puede guardarse en cualquier parte. Si eres especialmente metódico, puedes plantearte imprimirla y guardarla en el mismo cajón donde guardas los medios de respaldo. También es factible grabar el archivo con las sumas de comprobación junto con los datos a los que comprueba. Incluso si un defecto (como el paso del tiempo, o tu hermano pequeño frotando tus DVD con un estropajo) alterase tu archivo de hashes, en el momento en el que te dispusieses a hacer una comprobación notarías que algo no va bien.

PŔOXIMA ENTREGA: EL PODER DE RSYNC

Imagen de cnicolas
Enviado por cnicolas el 27 Octubre, 2011 - 15:41.

No conocia esta herramienta gracias por la informacion. Por lo pronto se me ocurre que algo que se podria hacer es comprobar la integridad de los archivos de la propia herramienta para ver si se han corrompido o alguien nos los ha modificado (es un poco modo paranoico).
Por curiosidad de que tamaño suele ser la base de datos generada ( si la vas a montar en un medio externo como puede ser un pendrive) s conveniente que tenga la capacidad suficiente claro.

Imagen de Black Rider
Enviado por Black Rider el 27 Octubre, 2011 - 15:52.
cnicolas escribió:

Por lo pronto se me ocurre que algo que se podria hacer es comprobar la integridad de los archivos de la propia herramienta para ver si se han corrompido o alguien nos los ha modificado (es un poco modo paranoico).

Si lo que quieres es emplear Aide como medida de seguridad, lo mejor que se puede hacer es montarse un LiveCD con él instalado, y cargar los archivos de configuración y las bases de datos desde un pendrive. Así, un individuo malicioso que entre en tu sistema no podrá modificar los binarios del LiveCD y difícilmente podrá afectar tus bancos de datos.

cnicolas escribió:

Por curiosidad de que tamaño suele ser la base de datos generada ( si la vas a montar en un medio externo como puede ser un pendrive) s conveniente que tenga la capacidad suficiente claro.

Depende de cuánto quieras archivar y de qué propiedades escanees. Yo empleo dos bases de datos: una para los archivos del sistema (con configuración paranoica) y otra para algunos datos de mi /home (con configuración permisiva). La paranoica (que cubre 7G) ocupa unos pocos megas comprimida, la permisiva (que cubre 300 Gb de datos reales) ocupa 1,5Mb o así.

Imagen de sebas
Enviado por sebas el 27 Octubre, 2011 - 18:35.

Impecable Rider da gusto leerte, espero ansioso lo de rsync.. smile
Abrazos!
Sebas

Imagen de cnicolas
Enviado por cnicolas el 28 Octubre, 2011 - 07:00.

En un momento hablas de un archivador Dar, me imagino que querras decir tar ¿no?.
No se si la herramienta lo hara o no, pero si pudiera comprobar una base de datos antigua con la que genera nueva tendrias un posible backup diferencial, es solo una idea que se me acaba de ocurrir.

Imagen de Black Rider
Enviado por Black Rider el 28 Octubre, 2011 - 08:46.
cnicolas escribió:

En un momento hablas de un archivador Dar, me imagino que querras decir tar ¿no?.

Dar viene de Disk Archive, y es una aplicación disañeda para sobreponerse a algunas limitaciones funcionales de Tar (Tape Archive). Tenía previsto hablar de ellos largo y tendido después de rsync.

cnicolas escribió:

No se si la herramienta lo hara o no, pero si pudiera comprobar una base de datos antigua con la que genera nueva tendrias un posible backup diferencial, es solo una idea que se me acaba de ocurrir.

Aide tiene la capacidad de comparar bases de datos, efectivamente. Tienes que habilitar una línea en el fichero de configuración para designar una base de datos que comparar con la base de datos habitual del sistema primero:

database_new=file:/mnt/usb/aide.db.compare

Después puedes comparar ambos bancos de datos con:

aide --compare

Se imprimirá en pantalla un informe con las diferencias entre las bases de datos. La verdad es que yo nunca uso esta función, pues lo que "aide --update" hace es comparar el sistema con el índice de datos y crear un banco de datos nuevo, por lo que te quedas con los dos (viejo y nuevo) hasta que decides borrar alguno.

Si estás pensando en comprobar la integridad del backup con una base de datos generada a partir del sistema original, dudo que sea buena idea. Aide emplea rutas absolutas, así que no puedes pretender que se crea que /home/cnicolas/Mis_cosas es el mismo archivo que /mnt/usb/backup/Mis_cosas. Además, muchas propiedades no coincidirían. Para comprobar las diferencias entre el backup y el original, la mayoría de las aplicaciones de respaldo proporcionan opciones específicas.

Si lo que te preocupa es verificar que tu copia de respaldo está sana y no se ha degradado con el tiempo, puedes utilizar un archivador para guardarla (Tar, Dar, Cpio) y guardar un checkusm del mismo. Además, estoy investigando la capacidad de generar registros de recuperación de datos.

Imagen de cnicolas
Enviado por cnicolas el 28 Octubre, 2011 - 10:53.

No conocia lo de dar, gracias
La idea es poder comparar una base de datos con una anterior y solo salvaguardar lo que se ha modificado entre ambas, es decir en vez de guardar todo el sistema de nuevo solo guardas lo modificado entre ambos.
A raiz de esto hay un parametro que no me queda claro, es que verifica si se han echo cambios en los ficheros , pero ¿desde cuando lo verifica?, no he visto y ahora me doy cuenta que en la configuracion se especifique el numero de dias

Imagen de Black Rider
Enviado por Black Rider el 28 Octubre, 2011 - 12:29.
cnicolas escribió:

No conocia lo de dar, gracias
A raiz de esto hay un parametro que no me queda claro, es que verifica si se han echo cambios en los ficheros , pero ¿desde cuando lo verifica?, no he visto y ahora me doy cuenta que en la configuracion se especifique el numero de dias

Las bases de datos se crean y comparan manualmente, esto es, tienes que introducir tú mismo las órdenes y las opciones. Un día creas una base de datos, el día que vayas a hacer el backup compruebas que los archivos del sistema tienen el mismo estado que el que refleja la base de datos y, si procede, generas una base de datos nueva y borras la anterior.

Obviamente, puedes emplear cron o anacron para automatizarlo todo.

Recuerda que Aide sólo proporciona verificación de integridad, y que no realiza copias de respaldo por sí mismo. Rsync, Tar y otros tantos también son capaces de hacer verificaciones de integridad, lo que ocurre es que Aide es muchos más completo. Además, para hacer la comprobación Aide sólo necesita un banco de datos de dos megas, mientras que la mayoría de las demás opciones requieren que conectes el backup entero al equipo (o al menos parte de él) para compararlo con el sistema activo.

cnicolas escribió:

La idea es poder comparar una base de datos con una anterior y solo salvaguardar lo que se ha modificado entre ambas, es decir en vez de guardar todo el sistema de nuevo solo guardas lo modificado entre ambos.

Los bancos de datos de Aide son archivos de texto plano, con compresión opcional. En un momento dado puedes hacer un diff sobre ellos. No obstante, como ya he comentado, con hacer "aide --update" o "aide --compare" y redirigir la salida a un archivo ya se obtiene un resumen muy detallado de los cambios. Desgraciadamente, el propio Aide no conoce el concepto de base de datos diferencial, y requiere ficheros completos para funcionar.

Los archivos de Aide ocupan muy poco espacio. En un principio, no hay motivos para no guardarlos enteros si es lo que deseas. Si el tamaño te preocupa, puedes desactivar la compresión mediante gzip y emplear lrzip manualmente. Lrzip es un algoritmo especialmente diseñado para guardar muchos archivos que se parecen entre sí, buscando datos repetitivos y guardándolos una sola vez. Además, se encadena automáticamente con otros algoritmos como LZMA, bzip2 o mi favorito: zpaq.