Bacula TLS (Transport Layer Security) is built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh. The data written to Volumes by the Storage daemon is not encrypted by this code. For data encryption, please see the Data Encryption ChapterDataEncryption of this manual.
The Bacula encryption implementations were written by Landon Fuller.
Supported features of this code include:
This document will refer to both "server" and "client" contexts. These terms refer to the accepting and initiating peer, respectively.
Diffie-Hellman anonymous ciphers are not supported by this code. The use of DH anonymous ciphers increases the code complexity and places explicit trust upon the two-way CRAM-MD5 implementation. CRAM-MD5 is subject to known plaintext attacks, and it should be considered considerably less secure than PKI certificate-based authentication.
Appropriate autoconf macros have been added to detect and use OpenSSL if enabled on the ./configure line with --
with-openssl
To generate the parameter file, you may use openssl:
openssl dhparam -out dh1024.pem -5 1024
You may create a self-signed certificate for use with the Bacula TLS that will permit you to make it function, but will not allow certificate validation. The .pem file containing both the certificate and the key valid for ten years can be made with the following:
openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 3650
The above script will ask you a number of questions. You may simply answer each of them by entering a return, or if you wish you may enter your own data.
Note, however, that self-signed certificates will only work for the outgoing end of connections. For example, in the case of the Director making a connection to a File Daemon, the File Daemon may be configured to allow self-signed certificates, but the certificate used by the Director must be signed by a certificate that is explicitly trusted on the File Daemon end.
This is necessary to prevent ``man in the middle'' attacks from tools such as ettercaphttp://ettercap.sourceforge.net/. Essentially, if the Director does not verify that it is talking to a trusted remote endpoint, it can be tricked into talking to a malicious 3rd party who is relaying and capturing all traffic by presenting its own certificates to the Director and File Daemons. The only way to prevent this is by using trusted certificates, so that the man in the middle is incapable of spoofing the connection using his own.
See the next section for how to get a trusted Certificate Authority certificate.
The program TinyCA has a very nice Graphical User Interface that allows you to easily setup and maintain your own CA. TinyCA can be found at http://tinyca.sm-zone.net/http://tinyca.sm-zone.net/.
The process of getting a certificate that is signed by a CA is quite a bit more complicated. You can purchase one from quite a number of PKI vendors, but that is not at all necessary for use with Bacula. To get a CA signed certificate, you will either need to find a friend that has setup his own CA or to become a CA yourself, and thus you can sign all your own certificates. The book OpenSSL by John Viega, Matt Mesier & Pravir Chandra from O'Reilly explains how to do it, or you can read the documentation provided in the Open-source PKI Book project at Source Forge: http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htmhttp://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm. Note, this link may change.
Landon has supplied us with the TLS portions of his configuration files, which should help you setting up your own. Note, this example shows the directives necessary for a Director to Storage daemon session. The technique is the same between the Director and the Client and for bconsole to the Director.
bacula-dir.conf
Director { # define myself Name = backup1-dir ... TLS Enable = yes TLS Require = yes TLS Verify Peer = yes TLS Allowed CN = "bacula@backup1.example.com" TLS Allowed CN = "administrator@example.com" TLS CA Certificate File = /usr/local/etc/ssl/ca.pem # This is a server certificate, used for incoming # console connections. TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem TLS Key = /usr/local/etc/ssl/backup1/key.pem } Storage { Name = File Address = backup1.example.com ... TLS Require = yes TLS CA Certificate File = /usr/local/etc/ssl/ca.pem # This is a client certificate, used by the director to # connect to the storage daemon TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem } Client { Name = backup1-fd Address = server1.example.com ... TLS Enable = yes TLS Require = yes TLS CA Certificate File = /usr/local/etc/ssl/ca.pem }
bacula-fd.conf
Director { Name = backup1-dir ... TLS Enable = yes TLS Require = yes TLS Verify Peer = yes # Allow only the Director to connect TLS Allowed CN = "bacula@backup1.example.com" TLS CA Certificate File = /usr/local/etc/ssl/ca.pem # This is a server certificate. It is used by connecting # directors to verify the authenticity of this file daemon TLS Certificate = /usr/local/etc/ssl/server1/cert.pem TLS Key = /usr/local/etc/ssl/server1/key.pem } FileDaemon { Name = backup1-fd ... # you need these TLS entries so the SD and FD can # communicate TLS Enable = yes TLS Require = yes TLS CA Certificate File = /usr/local/etc/ssl/ca.pem TLS Certificate = /usr/local/etc/ssl/server1/cert.pem TLS Key = /usr/local/etc/ssl/server1/key.pem }
bacula-sd.conf
Storage { # definition of myself Name = backup1-sd ... # These TLS configuration options are used for incoming # file daemon connections. Director TLS settings are handled # below. TLS Enable = yes TLS Require = yes # Peer certificate is not required/requested -- peer validity # is verified by the storage connection cookie provided to the # File Daemon by the director. TLS Verify Peer = no TLS CA Certificate File = /usr/local/etc/ssl/ca.pem # This is a server certificate. It is used by connecting # file daemons to verify the authenticity of this storage daemon TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem TLS Key = /usr/local/etc/ssl/backup1/key.pem } # # List Directors who are permitted to contact Storage daemon # Director { Name = backup1-dir ... TLS Enable = yes TLS Require = yes # Require the connecting director to provide a certificate # with the matching CN. TLS Verify Peer = yes TLS Allowed CN = "bacula@backup1.example.com" TLS CA Certificate File = /usr/local/etc/ssl/ca.pem # This is a server certificate. It is used by the connecting # director to verify the authenticity of this storage daemon TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem TLS Key = /usr/local/etc/ssl/backup1/key.pem }
Kern Sibbald 2018-02-03