1 \chapter{Using Stunnel to Encrypt Communications}
3 \index[general]{Using Stunnel to Encrypt Communications to Clients }
5 Prior to version 1.37, Bacula did not have built-in communications encryption.
6 Please see the \ilink{TLS chapter}{CommEncryption} if you are using Bacula
9 Without too much effort, it is possible to encrypt the communications
10 between any of the daemons. This chapter will show you how to use {\bf
11 stunnel} to encrypt communications to your client programs. We assume the
12 Director and the Storage daemon are running on one machine that will be called
13 {\bf server} and the Client or File daemon is running on a different machine
14 called {\bf client}. Although the details may be slightly different, the same
15 principles apply whether you are encrypting between Unix, Linux, or Win32
16 machines. This example was developed between two Linux machines running
17 stunnel version 4.04-4 on a Red Hat Enterprise 3.0 system.
19 \section{Communications Ports Used}
20 \index[general]{Used!Communications Ports }
21 \index[general]{Communications Ports Used }
23 First, you must know that with the standard Bacula configuration, the Director
24 will contact the File daemon on port 9102. The File daemon then contacts the
25 Storage daemon using the address and port parameters supplied by the Director.
26 The standard port used will be 9103. This is the typical server/client view of
27 the world, the File daemon is a server to the Director (i.e. listens for the
28 Director to contact it), and the Storage daemon is a server to the File
32 \index[general]{Encryption }
34 The encryption is accomplished between the Director and the File daemon by
35 using an stunnel on the Director's machine (server) to encrypt the data and to
36 contact an stunnel on the File daemon's machine (client), which decrypts the
37 data and passes it to the client.
39 Between the File daemon and the Storage daemon, we use an stunnel on the File
40 daemon's machine to encrypt the data and another stunnel on the Storage
41 daemon's machine to decrypt the data.
43 As a consequence, there are actually four copies of stunnel running, two on the
44 server and two on the client. This may sound a bit complicated, but it really
45 isn't. To accomplish this, we will need to construct four separate conf files
46 for stunnel, and we will need to make some minor modifications to the
47 Director's conf file. None of the other conf files need to be changed.
50 \index[general]{Picture }
52 Since pictures usually help a lot, here is an overview of what we will be
53 doing. Don't worry about all the details of the port numbers and such for the
61 Port 29102 >----| Stunnel 1 |-----> Port 9102
65 Port 9103 >----| Stunnel 2 |-----> server:29103
70 Port 29102 >----| Stunnel 3 |-----> client:29102
74 Port 29103 >----| Stunnel 4 |-----> 9103
79 \section{Certificates}
80 \index[general]{Certificates }
82 In order for stunnel to function as a server, which it does in our diagram for
83 Stunnel 1 and Stunnel 4, you must have a certificate and the key. It is
84 possible to keep the two in separate files, but normally, you keep them in one
85 single .pem file. You may create this certificate yourself in which case, it
86 will be self-signed, or you may have it signed by a CA.
88 If you want your clients to verify that the server is in fact valid (Stunnel 2
89 and Stunnel 3), you will need to have the server certificates signed by a CA
90 (Certificate Authority), and you will need to have the CA's public certificate
91 (contains the CA's public key).
93 Having a CA signed certificate is {\bf highly} recommended if you are using
94 your client across the Internet, otherwise you are exposed to the man in the
95 middle attack and hence loss of your data.
97 See below for how to create a self-signed certificate.
99 \section{Securing the Data Channel}
100 \index[general]{Channel!Securing the Data }
101 \index[general]{Securing the Data Channel }
103 To simplify things a bit, let's for the moment consider only the data channel.
104 That is the connection between the File daemon and the Storage daemon, which
105 takes place on port 9103. In fact, in a minimalist solution, this is the only
106 connection that needs to be encrypted, because it is the one that transports your
107 data. The connection between the Director and the File daemon is simply a
108 control channel used to start the job and get the job status.
110 Normally the File daemon will contact the Storage daemon on port 9103
111 (supplied by the Director), so we need an stunnel that listens on port 9103 on
112 the File daemon's machine, encrypts the data and sends it to the Storage
113 daemon. This is depicted by Stunnel 2 above. Note that this stunnel is
114 listening on port 9103 and sending to server:29103. We use port 29103 on the
115 server because if we would send the data to port 9103, it would go directly to the
116 Storage daemon, which doesn't understand encrypted data. On the server
117 machine, we run Stunnel 4, which listens on port 29103, decrypts the data and
118 sends it to the Storage daemon, which is listening on port 9103.
120 \section{Data Channel Configuration}
121 \index[general]{Modification of bacula-dir.conf for the Data Channel }
122 \index[general]{baculoa-dir.conf!Modification for the Data Channel }
124 The Storage resource of the bacula-dir.conf normally looks something like the
133 Password = storage_password
140 Notice that this is running on the server machine, and it points the File
141 daemon back to server:9103, which is where our Storage daemon is listening. We
150 Password = storage_password
157 This causes the File daemon to send the data to the stunnel running on
158 localhost (the client machine). We could have used client as the address as
161 \section{Stunnel Configuration for the Data Channel}
162 \index[general]{Stunnel Configuration for the Data Channel }
164 In the diagram above, we see above Stunnel 2 that we use stunnel-fd2.conf on the
165 client. A pretty much minimal config file would look like the following:
171 accept = localhost:9103
172 connect = server:29103
176 The above config file does encrypt the data but it does not require a
177 certificate, so it is subject to the man in the middle attack. The file I
178 actually used, stunnel-fd2.conf, looked like this:
183 # Stunnel conf for Bacula client -> SD
185 pid = /home/kern/bacula/bin/working/stunnel.pid
187 # A cert is not mandatory here. If verify=2, a
188 # cert signed by a CA must be specified, and
189 # either CAfile or CApath must point to the CA's
192 cert = /home/kern/stunnel/stunnel.pem
193 CAfile = /home/kern/ssl/cacert.pem
199 accept = localhost:9103
200 connect = server:29103
204 You will notice that I specified a pid file location because I ran stunnel
205 under my own userid so I could not use the default, which requires root
206 permission. I also specified a certificate that I have as well as verify level
207 2 so that the certificate is required and verified, and I must supply the
208 location of the CA (Certificate Authority) certificate so that the stunnel
209 certificate can be verified. Finally, you will see that there are two lines
210 commented out, which when enabled, produce a lot of nice debug info in the
213 If you do not have a signed certificate (stunnel.pem), you need to delete the
214 cert, CAfile, and verify lines.
216 Note that the stunnel.pem, is actually a private key and a certificate in a
217 single file. These two can be kept and specified individually, but keeping
218 them in one file is more convenient.
220 The config file, stunnel-sd.conf, needed for Stunnel 4 on the server machine
226 # Bacula stunnel conf for Storage daemon
228 pid = /home/kern/bacula/bin/working/stunnel.pid
230 # A cert is mandatory here, it may be self signed
231 # If it is self signed, the client may not use
234 cert = /home/kern/stunnel/stunnel.pem
244 \section{Starting and Testing the Data Encryption}
245 \index[general]{Starting and Testing the Data Encryption }
246 \index[general]{Encryption!Starting and Testing the Data }
248 It will most likely be the simplest to implement the Data Channel encryption
249 in the following order:
252 \item Setup and run Bacula backing up some data on your client machine
255 \item Modify the Storage resource in the Director's conf file.
257 \item Start stunnel on the server with:
261 stunnel stunnel-sd.conf
266 \item Start stunnel on the client with:
270 stunnel stunnel-fd2.conf
276 \item If it doesn't work, turn debug on in both stunnel conf files, restart
277 the stunnels, rerun the job, repeat until it works.
280 \section{Encrypting the Control Channel}
281 \index[general]{Channel!Encrypting the Control }
282 \index[general]{Encrypting the Control Channel }
284 The Job control channel is between the Director and the File daemon, and as
285 mentioned above, it is not really necessary to encrypt, but it is good
286 practice to encrypt it as well. The two stunnels that are used in this case
287 will be Stunnel 1 and Stunnel 3 in the diagram above. Stunnel 3 on the server
288 might normally listen on port 9102, but if you have a local File daemon, this
289 will not work, so we make it listen on port 29102. It then sends the data to
290 client:29102. Again we use port 29102 so that the stunnel on the client
291 machine can decrypt the data before passing it on to port 9102 where the File
294 \section{Control Channel Configuration}
295 \index[general]{Control Channel Configuration }
297 We need to modify the standard Client resource, which would normally look
326 This will cause the Director to send the control information to
327 localhost:29102 instead of directly to the client.
329 \section{Stunnel Configuration for the Control Channel}
330 \index[general]{Config Files for stunnel to Encrypt the Control Channel }
332 The stunnel config file, stunnel-dir.conf, for the Director's machine would
333 look like the following:
338 # Bacula stunnel conf for the Directory to contact a client
340 pid = /home/kern/bacula/bin/working/stunnel.pid
342 # A cert is not mandatory here. If verify=2, a
343 # cert signed by a CA must be specified, and
344 # either CAfile or CApath must point to the CA's
347 cert = /home/kern/stunnel/stunnel.pem
348 CAfile = /home/kern/ssl/cacert.pem
354 accept = localhost:29102
355 connect = client:29102
359 and the config file, stunnel-fd1.conf, needed to run stunnel on the Client
365 # Bacula stunnel conf for the Directory to contact a client
367 pid = /home/kern/bacula/bin/working/stunnel.pid
369 # A cert is not mandatory here. If verify=2, a
370 # cert signed by a CA must be specified, and
371 # either CAfile or CApath must point to the CA's
374 cert = /home/kern/stunnel/stunnel.pem
375 CAfile = /home/kern/ssl/cacert.pem
381 accept = localhost:29102
382 connect = client:29102
386 \section{Starting and Testing the Control Channel}
387 \index[general]{Starting and Testing the Control Channel }
388 \index[general]{Channel!Starting and Testing the Control }
390 It will most likely be the simplest to implement the Control Channel
391 encryption in the following order:
395 \item Modify the Client resource in the Director's conf file.
397 \item Start stunnel on the server with:
401 stunnel stunnel-dir.conf
406 \item Start stunnel on the client with:
410 stunnel stunnel-fd1.conf
416 \item If it doesn't work, turn debug on in both stunnel conf files, restart
417 the stunnels, rerun the job, repeat until it works.
420 \section{Using stunnel to Encrypt to a Second Client}
421 \index[general]{Using stunnel to Encrypt to a Second Client }
422 \index[general]{Client!Using stunnel to Encrypt to a Second }
424 On the client machine, you can just duplicate the setup that you have on the
425 first client file for file and it should work fine.
427 In the bacula-dir.conf file, you will want to create a second client pretty
428 much identical to how you did for the first one, but the port number must be
429 unique. We previously used:
443 so for the second client, we will, of course, have a different name, and we
444 will also need a different port. Remember that we used port 29103 for the
445 Storage daemon, so for the second client, we can use port 29104, and the
446 Client resource would look like:
460 Now, fortunately, we do not need a third stunnel to on the Director's machine,
461 we can just add the new port to the config file, stunnel-dir.conf, to make:
466 # Bacula stunnel conf for the Directory to contact a client
468 pid = /home/kern/bacula/bin/working/stunnel.pid
470 # A cert is not mandatory here. If verify=2, a
471 # cert signed by a CA must be specified, and
472 # either CAfile or CApath must point to the CA's
475 cert = /home/kern/stunnel/stunnel.pem
476 CAfile = /home/kern/ssl/cacert.pem
482 accept = localhost:29102
483 connect = client:29102
485 accept = localhost:29102
486 connect = client2:29102
490 There are no changes necessary to the Storage daemon or the other stunnel so
491 that this new client can talk to our Storage daemon.
493 \section{Creating a Self-signed Certificate}
494 \index[general]{Creating a Self-signed Certificate }
495 \index[general]{Certificate!Creating a Self-signed }
497 You may create a self-signed certificate for use with stunnel that will permit
498 you to make it function, but will not allow certificate validation. The .pem
499 file containing both the certificate and the key can be made with the
500 following, which I put in a file named {\bf makepem}:
506 # Simple shell script to make a .pem file that can be used
507 # with stunnel and Bacula
511 PEM1="/bin/mktemp openssl.XXXXXX"
512 PEM2="/bin/mktemp openssl.XXXXXX"
513 ${OPENSSL} req -newkey rsa:1024 -keyout $PEM1 -nodes \
514 -x509 -days 365 -out $PEM2
515 cat $PEM1 > stunnel.pem
516 echo "" >>stunnel.pem
517 cat $PEM2 >>stunnel.pem
522 The above script will ask you a number of questions. You may simply answer
523 each of them by entering a return, or if you wish you may enter your own data.
526 \section{Getting a CA Signed Certificate}
527 \index[general]{Certificate!Getting a CA Signed }
528 \index[general]{Getting a CA Signed Certificate }
530 The process of getting a certificate that is signed by a CA is quite a bit
531 more complicated. You can purchase one from quite a number of PKI vendors, but
532 that is not at all necessary for use with Bacula.
535 certificate, you will either need to find a friend that has setup his own CA
536 or to become a CA yourself, and thus you can sign all your own certificates.
537 The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
538 explains how to do it, or you can read the documentation provided in the
539 Open-source PKI Book project at Source Forge:
541 http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
542 {http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
543 Note, this link may change.
545 \section{Using ssh to Secure the Communications}
546 \index[general]{Communications!Using ssh to Secure the }
547 \index[general]{Using ssh to Secure the Communications }
549 Please see the script {\bf ssh-tunnel.sh} in the {\bf examples} directory. It
550 was contributed by Stephan Holl.