4
\section*{Using stunnel to Encrypt Communications to Clients}
6
\index[general]{Clients!Using Bacula to Encrypt Communications to }
7
\index[general]{Using Bacula to Encrypt Communications to Clients }
8
\addcontentsline{toc}{section}{Using Bacula to Encrypt Communications to
11
Prior to version 1.37, Bacula did not have built-in communications encryption.
12
Please see the TLS chapter if you are using Bacula 1.37 or greater.
14
Without too much effort, it is possible to encrypt the communications
15
between any of the daemons. This chapter will show you how to use {\bf
16
stunnel} to encrypt communications to your client programs. We assume the
17
Director and the Storage daemon are running on one machine that will be called
18
{\bf server} and the Client or File daemon is running on a different machine
19
called {\bf client}. Although the details may be slightly different, the same
20
principles apply whether you are encrypting between Unix, Linux, or Win32
21
machines. This example was developed between two Linux machines running
22
stunnel version 4.04-4 on a Red Hat Enterprise 3.0 system.
24
\subsection*{Communications Ports Used}
25
\index[general]{Used!Communications Ports }
26
\index[general]{Communications Ports Used }
27
\addcontentsline{toc}{subsection}{Communications Ports Used}
29
First, you must know that with the standard Bacula configuration, the Director
30
will contact the File daemon on port 9102. The File daemon then contacts the
31
Storage daemon using the address and port parameters supplied by the Director.
32
The standard port used will be 9103. This is the typical server/client view of
33
the world, the File daemon is a server to the Director (i.e. listens for the
34
Director to contact it), and the Storage daemon is a server to the File
37
\subsection*{Encryption}
38
\index[general]{Encryption }
39
\addcontentsline{toc}{subsection}{Encryption}
41
The encryption is accomplished between the Director and the File daemon by
42
using an stunnel on the Director's machine (server) to encrypt the data and to
43
contact an stunnel on the File daemon's machine (client), which decrypts the
44
data and passes it to the client.
46
Between the File daemon and the Storage daemon, we use an stunnel on the File
47
daemon's machine to encrypt the data and another stunnel on the Storage
48
daemon's machine to decrypt the data.
50
As a consequence, there are actually four copies of stunnel running, two on the
51
server and two on the client. This may sound a bit complicated, but it really
52
isn't. To accomplish this, we will need to construct four separate conf files
53
for stunnel, and we will need to make some minor modifications to the
54
Director's conf file. None of the other conf files need to be changed.
56
\subsection*{A Picture}
57
\index[general]{Picture }
58
\addcontentsline{toc}{subsection}{Picture}
60
Since pictures usually help a lot, here is an overview of what we will be
61
doing. Don't worry about all the details of the port numbers and such for the
69
Port 29102 >----| Stunnel 1 |-----> Port 9102
73
Port 9103 >----| Stunnel 2 |-----> server:29103
78
Port 29102 >----| Stunnel 3 |-----> client:29102
82
Port 29103 >----| Stunnel 4 |-----> 9103
87
\subsection*{Certificates}
88
\index[general]{Certificates }
89
\addcontentsline{toc}{subsection}{Certificates}
91
In order for stunnel to function as a server, which it does in our diagram for
92
Stunnel 1 and Stunnel 4, you must have a certificate and the key. It is
93
possible to keep the two in separate files, but normally, you keep them in one
94
single .pem file. You may create this certificate yourself in which case, it
95
will be self-signed, or you may have it signed by a CA.
97
If you want your clients to verify that the server is in fact valid (Stunnel 2
98
and Stunnel 3), you will need to have the server certificates signed by a CA
99
(Certificate Authority), and you will need to have the CA's public certificate
100
(contains the CA's public key).
102
Having a CA signed certificate is {\bf highly} recommended if you are using
103
your client across the Internet, otherwise you are exposed to the man in the
104
middle attack and hence loss of your data.
106
See below for how to create a self-signed certificate.
108
\subsection*{Securing the Data Channel}
109
\index[general]{Channel!Securing the Data }
110
\index[general]{Securing the Data Channel }
111
\addcontentsline{toc}{subsection}{Securing the Data Channel}
113
To simplify things a bit, let's for the moment consider only the data channel.
114
That is the connection between the File daemon and the Storage daemon, which
115
takes place on port 9103. In fact, in a minimalist solution, this is the only
116
connection that needs to be encrypted, because it is the one that transports your
117
data. The connection between the Director and the File daemon is simply a
118
control channel used to start the job and get the job status.
120
Normally the File daemon will contact the Storage daemon on port 9103
121
(supplied by the Director), so we need an stunnel that listens on port 9103 on
122
the File daemon's machine, encrypts the data and sends it to the Storage
123
daemon. This is depicted by Stunnel 2 above. Note that this stunnel is
124
listening on port 9103 and sending to server:29103. We use port 29103 on the
125
server because if we would send the data to port 9103, it would go directly to the
126
Storage daemon, which doesn't understand encrypted data. On the server
127
machine, we run Stunnel 4, which listens on port 29103, decrypts the data and
128
sends it to the Storage daemon, which is listening on port 9103.
130
\subsection*{Modification of bacula-dir.conf for the Data Channel}
131
\index[general]{Modification of bacula-dir.conf for the Data Channel }
132
\index[general]{Channel!Modification of bacula-dir.conf for the Data }
133
\addcontentsline{toc}{subsection}{Modification of bacula-dir.conf for the Data
136
The Storage resource of the bacula-dir.conf normally looks something like the
145
Password = storage_password
152
Notice that this is running on the server machine, and it points the File
153
daemon back to server:9103, which is where our Storage daemon is listening. We
162
Password = storage_password
169
This causes the File daemon to send the data to the stunnel running on
170
localhost (the client machine). We could have used client as the address as
173
\subsection*{config Files for stunnel to Encrypt the Data Channel}
174
\index[general]{Config Files for stunnel to Encrypt the Data Channel }
175
\index[general]{Channel!config Files for stunnel to Encrypt the Data }
176
\addcontentsline{toc}{subsection}{config Files for stunnel to Encrypt the Data
179
In the diagram above, we see above Stunnel 2 that we use stunnel-fd2.conf on the
180
client. A pretty much minimal config file would look like the following:
186
accept = localhost:9103
187
connect = server:29103
191
The above config file does encrypt the data but it does not require a
192
certificate, so it is subject to the man in the middle attack. The file I
193
actually used, stunnel-fd2.conf, looked like this:
198
# Stunnel conf for Bacula client -> SD
200
pid = /home/kern/bacula/bin/working/stunnel.pid
202
# A cert is not mandatory here. If verify=2, a
203
# cert signed by a CA must be specified, and
204
# either CAfile or CApath must point to the CA's
207
cert = /home/kern/stunnel/stunnel.pem
208
CAfile = /home/kern/ssl/cacert.pem
214
accept = localhost:9103
215
connect = server:29103
219
You will notice that I specified a pid file location because I ran stunnel
220
under my own userid so I could not use the default, which requires root
221
permission. I also specified a certificate that I have as well as verify level
222
2 so that the certificate is required and verified, and I must supply the
223
location of the CA (Certificate Authority) certificate so that the stunnel
224
certificate can be verified. Finally, you will see that there are two lines
225
commented out, which when enabled, produce a lot of nice debug info in the
228
If you do not have a signed certificate (stunnel.pem), you need to delete the
229
cert, CAfile, and verify lines.
231
Note that the stunnel.pem, is actually a private key and a certificate in a
232
single file. These two can be kept and specified individually, but keeping
233
them in one file is more convenient.
235
The config file, stunnel-sd.conf, needed for Stunnel 4 on the server machine
241
# Bacula stunnel conf for Storage daemon
243
pid = /home/kern/bacula/bin/working/stunnel.pid
245
# A cert is mandatory here, it may be self signed
246
# If it is self signed, the client may not use
249
cert = /home/kern/stunnel/stunnel.pem
259
\subsection*{Starting and Testing the Data Encryption}
260
\index[general]{Starting and Testing the Data Encryption }
261
\index[general]{Encryption!Starting and Testing the Data }
262
\addcontentsline{toc}{subsection}{Starting and Testing the Data Encryption}
264
It will most likely be the simplest to implement the Data Channel encryption
265
in the following order:
268
\item Setup and run Bacula backing up some data on your client machine
271
\item Modify the Storage resource in the Director's conf file.
273
\item Start stunnel on the server with:
277
stunnel stunnel-sd.conf
282
\item Start stunnel on the client with:
286
stunnel stunnel-fd2.conf
292
\item If it doesn't work, turn debug on in both stunnel conf files, restart
293
the stunnels, rerun the job, repeat until it works.
296
\subsection*{Encrypting the Control Channel}
297
\index[general]{Channel!Encrypting the Control }
298
\index[general]{Encrypting the Control Channel }
299
\addcontentsline{toc}{subsection}{Encrypting the Control Channel}
301
The Job control channel is between the Director and the File daemon, and as
302
mentioned above, it is not really necessary to encrypt, but it is good
303
practice to encrypt it as well. The two stunnels that are used in this case
304
will be Stunnel 1 and Stunnel 3 in the diagram above. Stunnel 3 on the server
305
might normally listen on port 9102, but if you have a local File daemon, this
306
will not work, so we make it listen on port 29102. It then sends the data to
307
client:29102. Again we use port 29102 so that the stunnel on the client
308
machine can decrypt the data before passing it on to port 9102 where the File
311
\subsection*{Modification of bacula-dir.conf for the Control Channel}
312
\index[general]{Channel!Modification of bacula-dir.conf for the Control }
313
\index[general]{Modification of bacula-dir.conf for the Control Channel }
314
\addcontentsline{toc}{subsection}{Modification of bacula-dir.conf for the
317
We need to modify the standard Client resource, which would normally look
346
This will cause the Director to send the control information to
347
localhost:29102 instead of directly to the client.
349
\subsection*{config Files for stunnel to Encrypt the Control Channel}
350
\index[general]{Config Files for stunnel to Encrypt the Control Channel }
351
\index[general]{Channel!config Files for stunnel to Encrypt the Control }
352
\addcontentsline{toc}{subsection}{config Files for stunnel to Encrypt the
355
The stunnel config file, stunnel-dir.conf, for the Director's machine would
356
look like the following:
361
# Bacula stunnel conf for the Directory to contact a client
363
pid = /home/kern/bacula/bin/working/stunnel.pid
365
# A cert is not mandatory here. If verify=2, a
366
# cert signed by a CA must be specified, and
367
# either CAfile or CApath must point to the CA's
370
cert = /home/kern/stunnel/stunnel.pem
371
CAfile = /home/kern/ssl/cacert.pem
377
accept = localhost:29102
378
connect = client:29102
382
and the config file, stunnel-fd1.conf, needed to run stunnel on the Client
388
# Bacula stunnel conf for the Directory to contact a client
390
pid = /home/kern/bacula/bin/working/stunnel.pid
392
# A cert is not mandatory here. If verify=2, a
393
# cert signed by a CA must be specified, and
394
# either CAfile or CApath must point to the CA's
397
cert = /home/kern/stunnel/stunnel.pem
398
CAfile = /home/kern/ssl/cacert.pem
404
accept = localhost:29102
405
connect = client:29102
409
\subsection*{Starting and Testing the Control Channel}
410
\index[general]{Starting and Testing the Control Channel }
411
\index[general]{Channel!Starting and Testing the Control }
412
\addcontentsline{toc}{subsection}{Starting and Testing the Control Channel}
414
It will most likely be the simplest to implement the Control Channel
415
encryption in the following order:
419
\item Modify the Client resource in the Director's conf file.
421
\item Start stunnel on the server with:
425
stunnel stunnel-dir.conf
430
\item Start stunnel on the client with:
434
stunnel stunnel-fd1.conf
440
\item If it doesn't work, turn debug on in both stunnel conf files, restart
441
the stunnels, rerun the job, repeat until it works.
444
\subsection*{Using stunnel to Encrypt to a Second Client}
445
\index[general]{Using stunnel to Encrypt to a Second Client }
446
\index[general]{Client!Using stunnel to Encrypt to a Second }
447
\addcontentsline{toc}{subsection}{Using stunnel to Encrypt to a Second Client}
449
On the client machine, you can just duplicate the setup that you have on the
450
first client file for file and it should work fine.
452
In the bacula-dir.conf file, you will want to create a second client pretty
453
much identical to how you did for the first one, but the port number must be
454
unique. We previously used:
468
so for the second client, we will, of course, have a different name, and we
469
will also need a different port. Remember that we used port 29103 for the
470
Storage daemon, so for the second client, we can use port 29104, and the
471
Client resource would look like:
485
Now, fortunately, we do not need a third stunnel to on the Director's machine,
486
we can just add the new port to the config file, stunnel-dir.conf, to make:
491
# Bacula stunnel conf for the Directory to contact a client
493
pid = /home/kern/bacula/bin/working/stunnel.pid
495
# A cert is not mandatory here. If verify=2, a
496
# cert signed by a CA must be specified, and
497
# either CAfile or CApath must point to the CA's
500
cert = /home/kern/stunnel/stunnel.pem
501
CAfile = /home/kern/ssl/cacert.pem
507
accept = localhost:29102
508
connect = client:29102
510
accept = localhost:29102
511
connect = client2:29102
515
There are no changes necessary to the Storage daemon or the other stunnel so
516
that this new client can talk to our Storage daemon.
518
\subsection*{Creating a Self-signed Certificate}
519
\index[general]{Creating a Self-signed Certificate }
520
\index[general]{Certificate!Creating a Self-signed }
521
\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
523
You may create a self-signed certificate for use with stunnel that will permit
524
you to make it function, but will not allow certificate validation. The .pem
525
file containing both the certificate and the key can be made with the
526
following, which I put in a file named {\bf makepem}:
532
# Simple shell script to make a .pem file that can be used
533
# with stunnel and Bacula
537
PEM1="/bin/mktemp openssl.XXXXXX"
538
PEM2="/bin/mktemp openssl.XXXXXX"
539
${OPENSSL} req -newkey rsa:1024 -keyout $PEM1 -nodes \
540
-x509 -days 365 -out $PEM2
541
cat $PEM1 > stunnel.pem
542
echo "" >>stunnel.pem
543
cat $PEM2 >>stunnel.pem
548
The above script will ask you a number of questions. You may simply answer
549
each of them by entering a return, or if you wish you may enter your own data.
552
\subsection*{Getting a CA Signed Certificate}
553
\index[general]{Certificate!Getting a CA Signed }
554
\index[general]{Getting a CA Signed Certificate }
555
\addcontentsline{toc}{subsection}{Getting a CA Signed Certificate}
557
The process of getting a certificate that is signed by a CA is quite a bit
558
more complicated. You can purchase one from quite a number of PKI vendors, but
559
that is not at all necessary for use with Bacula.
562
certificate, you will either need to find a friend that has setup his own CA
563
or to become a CA yourself, and thus you can sign all your own certificates.
564
The book OpenSSL by John Viega, Matt Mesier \& Pravir Chandra from O'Reilly
565
explains how to do it, or you can read the documentation provided in the
566
Open-source PKI Book project at Source Forge:
568
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
569
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
570
Note, this link may change.
572
\subsection*{Using ssh to Secure the Communications}
573
\index[general]{Communications!Using ssh to Secure the }
574
\index[general]{Using ssh to Secure the Communications }
575
\addcontentsline{toc}{subsection}{Using ssh to Secure the Communications}
577
Please see the script {\bf ssh-tunnel.sh} in the {\bf examples} directory. It
578
was contributed by Stephan Holl.
added
removed
manual-de/stunnel.tex
