Backups seguros con Bacula

Introducción

Bacula es una solución completa y profesional de backup, libre, modular, con arquitectura cliente/servidor, de gestión centralizada, que permite respaldar, recuperar y verificar datos procedentes de clientes heterogéneos (Unix, Linux, Windows) de forma segura y a través de una red no fiable.

Lo que sigue son los procedimientos para cifrar las comunicaciones entre los componentes de Bacula, así como los datos respaldados. Por tanto, se asume que se dispone de Bacula previamente configurado y operativo entre sus distintos componentes.

1. Bacula TLS - Cifrado de comunicaciones

Nota: Antes de intentar configurar la comunicación entre Bacula y sus componentes de forma cifrada, conviene asegurarse de que todo funciona bien sin TLS.

El objetivo de Bacula TLS (Transport Layer Security) es cifrar las comunicaciones (no los datos) entre los componentes de Bacula de forma similar a la funcionalidad que ofrece SSH o stunnel. El cifrado de la comunicación es algo imprescindible si hacemos backups remotos o a través de una red no fiable para impedir que terceros puedan capturar los datos respaldados. Si no lo hacemos, estaremos comprometiendo los datos transmitidos al hacer los backups (desde usuarios y passwords de máquinas hasta toda clase de datos privados).

Para ello, primero debe crearse una CA o Autoridad Certificadora (o bien usar una como CAcert) y un par de claves para cada componente de bacula (director, bconsole, storage, clientes…). Es esencial armonizar el nombre de máquina (hostname) que indicamos en el “Common Name” de cada certificado con los nombres de máquina especificados en los archivos de configuración de Bacula. Aunque no es un requisito, lo recomendado es poner en el CN del certificado un nombre de máquina completo (FQDN), como por ejemplo foobar.example.com. Por tanto, es imprescindible incluir ese nombre en el archivo /etc/hosts o disponer de un servidor DNS bien configurado.

Creación de los certificados

1. Creamos una clave privada RSA de 4096 bits (server.key) y algoritmo de cifrado Triple DES. Podemos usar una sola clave privada maestra para todos los certificados que generemos, o bien crear una distinta por cada cliente.

openssl genrsa -des3 -out server.key 4096

2. Con la clave privada, creamos ahora una solicitud de certificado:

openssl req -new -key server.key -out director.example.com.csr 

Deberemos rellenar los datos del certificado. El fundamental es el campo CN (Common Name), donde pondremos el nombre FQDN de la máquina para la que estamos creando el certificado (en este caso, director.example.com).

Podemos crear tantas solicitudes como vayamos a necesitar (una por cliente, con el CN correspondiente a cada nombre de máquina):

openssl req -new -key server.key -out client1.example.com.csr 
openssl req -new -key server.key -out client2.example.com.csr 

3. El siguiente paso es que una CA (autoridad certificadora) firme esas solicitudes. En nuestro caso, usamos CAcert como CA. Para ello, como es lógico, deberemos tener cuenta creada en CAcert y ser administradores del dominio para el que hemos creado la solicitud de certificación. CAcert nos envía un email a una cuenta administrativa del dominio, pues de ese modo se asegura que se trata de una solicitud legítima (por ello CAcert solo certifica por este método no presencial el CN o nombre de máquina). Si no tomásemos precauciones para que una CA firme nuestros certificados estaríamos expuestos a un ataque MitM (Man in the Middle).

A través del correspondiente formulario, CAcert nos devolverá el certificado firmado, que copiaremos en un directorio de la máquina accesible por Bacula con extensión .pem (o .cert). Por ejemplo, al certificado firmado lo podemos llamar director.example.com.cert.

Nota: Si usamos CAcert y nuestro sistema no incluye su certificado raíz en /etc/ssl/certs (o un directorio análogo), podemos descargarlo de su página web.

4. Generamos una versión de la clave privada sin contraseña:

openssl rsa -in server.key -out server.key.unsecure

Este último paso es necesario pues Bacula no soporta claves con contraseña.

5. A la hora de configurar los componentes de Bacula, deberemos indicar la ruta a los certificados generados dentro de las siguientes directivas (para el caso de la máquina director.example.com, y lo mismo con el resto de máquinas y componentes de Bacula):

TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem    # certificado raíz de cacert
TLS Certificate = /etc/ssl/certs/director.example.com.cert # certificado público firmado por cacert
TLS Key = /etc/ssl/certs/bacula/director.example.com.key   # clave privada con la que generamos el certificado

Esto se explica con detalle en las siguientes secciones.

Consola --> Director

Empezamos conectando bconsole con el director para que se comuniquen utilizando TLS. Este ejemplo asume que bconsole y el director se están ejecutando en la misma máquina (director.example.com).

Editamos /etc/bconsole.conf y añadimos las siguientes líneas en la sección Director:

Director {
  Name = director-dir
  DIRport = 9101
  address = director.example.com
  Password = "secret"
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key
}

Con esto le decimos a bconsole que debe usar obligatoriamente TLS para conectarse al director. Si bconsole se ejecutase desde un host remoto, bastaría con utilizar los certificados correspondientes a ese host.

A continuación necesitamos configurar el director para que igualmente use TLS. Para ello editamos la sección Director en /etc/bacula/bacula-dir.conf:

Director {
  Name = director-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 5
  Password = "secret"
  Messages = Daemon
  TLS Enable = yes
  TLS Require = yes
  TLS Verify Peer = yes
  TLS Allowed CN = "director.example.com"
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key
}

Director --> Cliente

Ahora activamos la comunicación TLS entre el Director y el File Daemon (FD), es decir, el cliente. En este ejemplo el cliente de bacula corre en una máquina remota llamada client1.example.com, para la cual debemos crear antes los correspondientes certificados.

Editamos la sección Director en /etc/bacula-fd.conf de la máquina cliente para que quede de esta forma:

Director {
  Name = director-dir
  Password = "secret"
  TLS Enable = yes
  TLS Require = yes
  TLS Verify Peer = yes
  TLS Allowed CN = "director.example.com"
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem
  TLS Certificate = /etc/ssl/certs/client1.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/client1.example.com.key
}

Esto obliga a que las comunicaciones desde el director vayan cifrada y le dice al FD que sólo permita conexiones entrantes desde director.example.com.

A continuación tendremos que configurar al director para que hable TLS con este cliente, lo cual se realiza en el recurso Cliente en /etc/bacula/bacula-dir.conf:

Client {
  Name = client1-fd
  Address = client1.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "secret"
  Job Retention = 1 year
  File Retention = 60 days
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem    
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key
}

Finalmente reiniciamos el FD y el Director.

Director --> Storage

La configuración del Storage Daemon requiere cifrar dos partes: 1) la comunicación con el Director y 2) la comunicación con los clientes (File Daemons). Comenzaremos cifrando la comunicación entre el Director y el Storage, que en este ejemplo están instalados en la misma máquina (director.example.com):

Editamos /etc/bacula-sd.conf:

Director {
  Name = director-dir
  Password = "secret"
  TLS Enable = yes
  TLS Require = yes
  TLS Verify Peer = yes
  TLS Allowed CN = "director.example.com"
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem    
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key  
  }

Esto le dice al Storage Daemon que tiene que usar TLS en sus comunicaciones con el Director y que debe permitírselo solamente a una máquina cuyo certificado coincida con el CN director.example.com.

Ahora configuramos el recurso Storage del Director en /usr/local/etc/bacula-dir.conf:

Storage {
  Name = director-sd
  Address = director.example.com
  SDPort = 9103
  Password = "secret"
  Device = FileStorage
  Media Type = File
  TLS Enable = yes
  TLS Require = Yes
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem    
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key
}

Reiniciamos bacula-dir y bacula-sd.

FileDaemon --> StorageDaemon

Nos queda una última comunicación por cifrar, la que existe entre el demonio de almacenamiento (Storage Daemon) y el cliente (File Daemon). Este paso es clave para garantizar que los datos entre nuestros clientes y el servidor de backup es seguro:

En primer lugar le decimos al Storage Daemon que requiere TLS. Para ello editamos /etc/bacula-sd.conf:

Storage {
  Name = foo-sd
  SDPort = 9103
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 10
  TLS Enable = yes
  TLS Require = yes
  TLS Verify Peer = no
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem    
  TLS Certificate = /usr/local/etc/bacula/certs/director.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/director.example.com.key
}

Por último, configuramos el File Daemon para que utilice TLS, pues el Storage se lo va a exigir. Para ello editamos /etc/bacula-fd.conf en nuestra máquina cliente (client1.example.com):

FileDaemon {
  Name = client1-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 20
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = /etc/ssl/certs/cacert.org.pem
  TLS Certificate = /etc/ssl/certs/client1.example.com.cert
  TLS Key = /etc/ssl/certs/bacula/client1.example.com.key
}

Reiniciamos bacula-sd y bacula-fd en todos nuestros clientes (client1, client2….) y todas nuestras comunicaciones entre componentes de Bacula quedarán cifradas.

2. Cifrado de los datos

Bacula permite no solo cifrar las comunicaciones de red, sino también cifrar y firmar los datos respaldados. El proceso de cifrado se realiza también con infraestructura de clave pública (PKI) y tiene lugar en el cliente (File Daemon), antes de enviarse los datos al servidor de almacenamiento (Storage Daemon). De esta forma, los datos en ningún instante aparecen en claro para el servidor (ni para el operador de backups).

El sistema de cifrado y firmado se basa en claves privadas RSA y un certificado público autofirmado x509. El cliente genera una clave de sesión para efectuar un cifrado simétrico de los datos. Cada File Daemon (cliente) necesita su propio par de claves. Además, creamos un par de claves maestro que, si se perdiese el certificado de un cliente, será capaz de restaurar el contenido de cualquiera de los clientes. Al ser tan poderosa, es fundamental que la clave privada maestra se guarde a buen recaudo, en un sitio externo y seguro, jamás en una de las máquinas cliente.

Cómo cifrar y firmar los datos respaldados

En primer lugar generamos la clave maestra y un certificado público autofirmado (master.cert):

# openssl genrsa -out master.key 2048
# openssl req -new -key master.key -x509 -out master.cert -days 3650

El certificado tendrá una validez de 10 años. Si no indicamos nada, por defecto solo tendrá 30 días de vigencia.

A continuación generamos un par de claves único para cada FD (cliente) y las concatenamos en un solo fichero (fd-example.pem):

# openssl genrsa -out fd-example.key 2048
# openssl req -new -key fd-example.key -x509 -out fd-example.cert -days 3650
# cat fd-example.key fd-example.cert > fd-example.pem

Por último configuramos las directivas para activar el firmado (SHA-256) y el cifrado de ficheros en /etc/bacula/bacula-fd.conf, es decir, el fichero de configuración de cada máquina cliente:

FileDaemon {
   [...] 
   # Data Encryption
   PKI Signatures = Yes            # Enable Data Signing
   PKI Encryption = Yes            # Enable Data Encryption
   PKI Keypair = "/etc/ssl/fd-example.pem"    # Public and Private Keys
   PKI Master Key = "/etc/ssl/master.cert"    # ONLY the Public Key
}

Obsérvese que especificamos también la clave pública del par de claves maestro. Eso permitirá restaurar los datos con la clave privada maestra, si fuese necesario. Pueden indicarse si se desea varias claves públicas maestras.

Reiniciamos el FD y podemos realizar un trabajo de prueba. Al completarse el mismo, los logs nos deberían indicar que nuestros datos están cifrados (Encryption: Yes):

FD Bytes Written:       467 (467 B)
SD Bytes Written:       556 (556 B)
Rate:                   0.1 KB/s
Software Compression:   None
VSS:                    no
**Encryption:             yes**
Volume name(s):         Vol001

Para restaurar un backup, el proceso de descifrado será transparente, tiene lugar únicamente en el cliente y se realiza de la forma habitual. Si alguna vez se pierden los certificados o las claves de un cliente, podremos usar el par de claves maestro para restaurar la copia. Para ello concatenamos master.crt y master.key en un solo fichero (master.keypair), e indicamos su nombre en la directiva PKI Keypair:

PKI Keypair = master.keypair

Téngase en cuenta que, si perdemos las claves y no conservamos el par de claves maestro (master.keypair en este ejemplo), ¡nunca podremos restaurar nuestro backup!

Por último, señalar que el cifrado solo se realiza sobre los datos, no sobre los metadatos, como rutas, nombres de ficheros y directorios, permisos o atributos, pues de ese modo son accesibles para el Catálogo y el Director, que los manejará como ficheros normales.

Referencias

es/security/bacula.txt · Last modified: 2013/08/02 21:15 by mvidal
 
Except where otherwise noted, content on this wiki is licensed under the following license: CC0 1.0 Universal
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki