In a previous article, we looked at how to safely transmit a backup from the client to the server. In that article, the data was transmitted from the client to the server over an encrypted channel. However, the server would store that data unencrypted. That left anyone with access to the storage server and the right permissions to potentially get access to the data. In this article we’ll see how storing encrypted backups in Bacula is configured.
This article assumes that the keys and certificates have been generated with the subjectKeyIdentifier extension. I wrote about how to do this in a previous article.
Substantial risk of data loss
First, an important note. If you encrypt your backups and subsequently loose the encryption keys, you WILL NOT be able to restore any backup encrypted with those keys. Bacula supports a set of backup keys that can be used to restore an encrypted backup if the original keys are lost. However, make sure that you have backups of your encryption keys and store them in a safe and secure spot, preferably offline and off-site.
The process in which Bacula encrypts the backups are as follows. The Bacula server will contact the client to request that it performs a backup. The client gathers the files and folders for that job, encrypts it and sends them to the server. The server then stores the backup.
Since the encryption part takes place on the client, we only need to make changes to the client’s bacula-fd.conf file.
Those changes consists of adding four new parameters to the bacula-fd.conf configuration file. This process must be repeated for all the clients that we want to enable encryption for.
PKI Encryption = Yes # Enable Data Encryption PKI Signatures = Yes # Enable Data Signing PKI Keypair = <file location> # Public and Private Keys PKI Master Key = <file location> # ONLY the Public Key
The two first parameters are fairly self explanatory. We want the backups encrypted and signed so we can verify the integrity of the backups when restoring.
PKI Keypair parameter needs the location of the client’s private and public key. Since there is only one parameter for the public and private key, we need to combine the them into one file. We do this on Linux with the following command:
cat client.key client.crt > client.pem
Alternatively, you can use a text editor to copy the contents of the two files, the client’s private key and certificate, into it and then save the file.
This new file, client.pem, contains the client’s key and certificate. When Bacula is performing the encryption, it will extract the public key from the certificate automatically.
This new file must be kept in a secure location with only the necessary permission since it contains the client’s private key. Depending on where you place it, you must make sure that Bacula has read access to the file and location. In this example, I placed the file in the /etc/ssl/private directory and changed the file permissions to read-only using the following commands:
chmod 600 client.pem chown root:root client.pem
PKI Master Key
Lastly, the final parameter, PKI Master Key though optional, is highly recommended. In this example, I’m using the Bacula server’s certificate. Unless you’ve done so already, you need to copy the server certificate to the client. Then, place the certificate in a location, such as /etc/ssl/certs. It is recommended to have a master key as this ads another set of keys that can be used to restore a backup. There is a trade off here though. Without the parameter, the client is the only one that can restore a backup. That increases security, but if the client looses their keys, the backups are unusable.
On the other hand, with the Master Key parameter enabled, there is another set of keys that can be used to restore. So it is imperative that those keys and the user is trusted by the client. Should the client lose their keys, the trusted user can restore the backup using their key pair.
After making the necessary changes to bacula-fd.conf file, save it and restart the Bacula client process.
There are no server changes required, the storage server will not need to be modified to accommodate encrypted backups. One thing I haven’t fully tested is any potential overhead in terms of space requirement now that the backup is encrypted and signed.
Unless there are any issues with the configuration file, you have now enabled encrypted backup jobs.
Verifying encrypted backups
Just out of curiosity, I wanted to see how the encryption process worked. I started digging around in the Bacula source code and verified several references and uses of the c++ crypto library. I then decided to inspect the data sent to the server from the client. To do that, I installed WireShark on the client machine so that I could intercept the network traffic. Once captured, WireShark presents that data in a graphical user interface where its content can be searched.
If you try this, you should turn off compression first. Otherwise, it will be difficult to find the data that you are looking for. You can turn off compression by commenting out the compression flag in the FileSet directive in bacula-dir.conf file on the server.
Transmitting unencrypted backups
I now needed to create some data that I could easily find in WireShark. So I created a test file, called test.txt that contained the text : ABCDEFG.
After I started WireShark, I started a backup job via bconsole on the server and instructed Bacula to perform a backup.
After some searching I came across the packet containing the information from the file test.txt.
I then enabled the encryption flag on the client and restarted the Bacula process. Then, I restarted WireShark and on the server, started a new backup. We can see the encrypted content of the file in the screenshot below.