SOMBI - Still One More Backup Implementation

Submitted by gwolf on Sat, 02/09/2008 - 21:09
Written in...: 
2001

I presented this proposal about a backup system in the Computer Security 2001 Conference. Here I present a proposal for the implementation of a cyphered, automatic remote backup scheme.

Resumen: 

Presenté esta propuesta de esquema de respaldo en el Congreso de Seguridad en Cómputo 2001, presenta una propuesta para la implementación de un esquema de respaldo remoto, cifrado, automático.

SOMBI: Still One More Backup Implementation

Gunnar Wolf
gwolf@campus.iztacala.unam.mx
Congreso de Seguridad en Cómputo 2001
UNAM FES Iztacala

Abstract:

Hay una gran cantidad de implementaciones ya existentes para llevar a cabo de manera automática en sistemas en red -- Por diferentes razones, ninguno de ellos me convenció para las necesidades (nada atípicas, en mi opinión) de mi situación. Lo que aquí presento es un esquema muy simple que permite hacer respaldos de manera automática sobre la red con cifrado y contemplando diferentes tipos de respaldo.

¿Qué hay de malo con los esquemas de respaldo existentes?

Si estoy proponiendo un nuevo esquema de respaldos, esto es porque los ya existentes tienen alguna carencia que no me permite resolver de una manera simple mis necesidades. Entonces pues, ¿qué hay de malo con los esquemas de respaldo que existen hoy?

1.1 Mis necesidades

...Que pueden no ser las de los demás, pero seguramente habrá alguien con necesidades similares

  • Hacer los respaldos de manera periódica y automática
  • Hacer los respaldos sobre la red
  • Cifrar los respaldos conforme son realizados
  • Almacenarlos en un medio que me proporcione acceso fácil, rápido y confiable
  • Que sea simple y poco intrusivo, para cualquier administrador
  • Que sea software libre

1.2 El medio donde se almacena el respaldo

¿Por qué no usar cintas DAT?

  • Confiabilidad
  • Costo
  • Reusabilidad del medio
  • Velocidad
  • Compatibilidad entre plataformas

1.3 La transmisión de datos sensibles sobre la red

  • ¿Hacernos de la vista gorda y pasarlo en claro? ¿''ocultarlo'' con gzip?
  • ¿Cifrado en el transporte?
  • ¿Cifrado en el archivo?
  • Tiempo de procesador que esto ocupa

2 Consideraciones previas a SOMBI

2.1 Lo más común que he visto

  • Directo a la cinta, conectada localmente
    • ¿Y si no tengo una cinta en esta computadora?
    • ¿Y si no confío en las cintas?
  • Directo a cinta, en un host remoto
    • Típicamente con rsh -- Tremendamente inseguro!
    • ¿Y si no confío en las cintas?
  • Respaldo local con tar o equivalente
    • Un respaldo debería ser remoto o desmontable...

2.2 Mi esquema previo - sus fuerzas y debilidades

  • tar xf - /etc /home /var/mail | ssh $SERVER 'cat > respaldo'
  • Funciona, pero
    • Requiere root tanto en cliente como en servidor
    • No es automatizable (¿pondrías tu contraseña de root en un script?)

3 Esquema operativo de SOMBI

3.1 Soporte a diferentes tipos de respaldo

  • Como está en este momento, permite tres tipos de respaldo: Completo, de configuración y de datos de usuario. Ampliarlo, sin embargo, a que acepte otros tipos de respaldo es trivial.
  • Las pruebas que he hecho son con tar, pero podemos usar algún otro método para archivar, siempre que permita enviar la salida a un flujo de datos, con modificar bkCmd

3.2 Cifrado del lado del cliente

  • El cifrado se hace con un programa externo que nos permita trabajar sobre un flujo de datos
  • GPG (versión GNU de PGP) parece ideal
    • Cifrado con llave pública: No es necesario siquiera poder descifrar el respaldo con la información contenida en el cliente ni en el servidor
    • GPG incluye compresión (probablemente gzip)
  • Podrían usarse otros métodos -- Basta con modificar cryptCmd

3.3 Doble conexión

El proceso que sigue una conexión es:

  1. El cliente se conecta al puerto indicado del servidor
  2. El servidor verifica que la conexión venga de una dirección aprobada
  3. El cliente abre un puerto aleatorio, e informa al servidor cuál puerto abrió
  4. El servidor se conecta de vuelta con el cliente por este puerto
  5. El cliente verifica que la conexión venga del servidor
  6. El cliente envía el respaldo completo cifrado al servidor a través de este nuevo puerto
  7. El servidor almacena los datos en un lugar predeterminado

Proceso a agregar próximamente:

  • En el paso 3, enviar el puerto cifrado con una llave secreta que tengan tanto cliente como servidor
  • En el paso 5, verificar no sólo por la IP, sino que por una cadena cifrada con la llave secreta, que es realmente el servidor.

3.4 Medio en el que se almacena el respaldo

  • Se almacena en el disco duro de un servidor remoto
    • ¿Cuánto cuesta hoy en día un disco duro grande?
    • Velocidad, confiabilidad
  • Se puede combinar con crontab para quemar un CD-ROM periódicamente
    • Hacer más granular lo que se graba -- ¿Necesitas grabar en CD TODO el sistema?
    • Los CD-Rs y CD-RWs son ya muy baratos

3.5 Seguridad implementada por el esquema

  • Cifrado con GPG
  • Spoofing difícil (aunque a estas alturas, aún no imposible)
  • El respaldo es almacenado en un medio confiable
  • El respaldo puede trasladarse sin mayor problema a un medio removible

3.6 Problemas con este esquema

  • Está hecho para resolver mis necesidades, no cualquier necesidad
  • Costo de disco duro para respaldos masivos
  • No contempla (nativamente) guardar respaldos en medio removible
  • Estando cifrado con GPG, un bit corrupto puede hacer inútil al respaldo entero
  • Es una idea nueva y, por tanto, no del todo confiable