+++ /dev/null
-%%
-%%
-
-\chapter{Using Stunnel to Encrypt Communications}
-\label{StunnelChapter}
-\index[general]{Using Stunnel to Encrypt Communications to Clients }
-
-Prior to version 1.37, Bacula did not have built-in communications encryption.
-Please see the \ilink {TLS chapter}{CommEncryption} if you are using Bacula
-1.37 or greater.
-
-Without too much effort, it is possible to encrypt the communications
-between any of the daemons. This chapter will show you how to use {\bf
-stunnel} to encrypt communications to your client programs. We assume the
-Director and the Storage daemon are running on one machine that will be called
-{\bf server} and the Client or File daemon is running on a different machine
-called {\bf client}. Although the details may be slightly different, the same
-principles apply whether you are encrypting between Unix, Linux, or Win32
-machines. This example was developed between two Linux machines running
-stunnel version 4.04-4 on a Red Hat Enterprise 3.0 system.
-
-\section{Communications Ports Used}
-\index[general]{Used!Communications Ports }
-\index[general]{Communications Ports Used }
-
-First, you must know that with the standard Bacula configuration, the Director
-will contact the File daemon on port 9102. The File daemon then contacts the
-Storage daemon using the address and port parameters supplied by the Director.
-The standard port used will be 9103. This is the typical server/client view of
-the world, the File daemon is a server to the Director (i.e. listens for the
-Director to contact it), and the Storage daemon is a server to the File
-daemon.
-
-\section{Encryption}
-\index[general]{Encryption }
-
-The encryption is accomplished between the Director and the File daemon by
-using an stunnel on the Director's machine (server) to encrypt the data and to
-contact an stunnel on the File daemon's machine (client), which decrypts the
-data and passes it to the client.
-
-Between the File daemon and the Storage daemon, we use an stunnel on the File
-daemon's machine to encrypt the data and another stunnel on the Storage
-daemon's machine to decrypt the data.
-
-As a consequence, there are actually four copies of stunnel running, two on the
-server and two on the client. This may sound a bit complicated, but it really
-isn't. To accomplish this, we will need to construct four separate conf files
-for stunnel, and we will need to make some minor modifications to the
-Director's conf file. None of the other conf files need to be changed.
-
-\section{A Picture}
-\index[general]{Picture }
-
-Since pictures usually help a lot, here is an overview of what we will be
-doing. Don't worry about all the details of the port numbers and such for the
-moment.
-
-\footnotesize
-\begin{verbatim}
- File daemon (client):
- stunnel-fd1.conf
- |===========|
- Port 29102 >----| Stunnel 1 |-----> Port 9102
- |===========|
- stunnel-fd2.conf
- |===========|
- Port 9103 >----| Stunnel 2 |-----> server:29103
- |===========|
- Director (server):
- stunnel-dir.conf
- |===========|
- Port 29102 >----| Stunnel 3 |-----> client:29102
- |===========|
- stunnel-sd.conf
- |===========|
- Port 29103 >----| Stunnel 4 |-----> 9103
- |===========|
-\end{verbatim}
-\normalsize
-
-\section{Certificates}
-\index[general]{Certificates }
-
-In order for stunnel to function as a server, which it does in our diagram for
-Stunnel 1 and Stunnel 4, you must have a certificate and the key. It is
-possible to keep the two in separate files, but normally, you keep them in one
-single .pem file. You may create this certificate yourself in which case, it
-will be self-signed, or you may have it signed by a CA.
-
-If you want your clients to verify that the server is in fact valid (Stunnel 2
-and Stunnel 3), you will need to have the server certificates signed by a CA
-(Certificate Authority), and you will need to have the CA's public certificate
-(contains the CA's public key).
-
-Having a CA signed certificate is {\bf highly} recommended if you are using
-your client across the Internet, otherwise you are exposed to the man in the
-middle attack and hence loss of your data.
-
-See below for how to create a self-signed certificate.
-
-\section{Securing the Data Channel}
-\index[general]{Channel!Securing the Data }
-\index[general]{Securing the Data Channel }
-
-To simplify things a bit, let's for the moment consider only the data channel.
-That is the connection between the File daemon and the Storage daemon, which
-takes place on port 9103. In fact, in a minimalist solution, this is the only
-connection that needs to be encrypted, because it is the one that transports your
-data. The connection between the Director and the File daemon is simply a
-control channel used to start the job and get the job status.
-
-Normally the File daemon will contact the Storage daemon on port 9103
-(supplied by the Director), so we need an stunnel that listens on port 9103 on
-the File daemon's machine, encrypts the data and sends it to the Storage
-daemon. This is depicted by Stunnel 2 above. Note that this stunnel is
-listening on port 9103 and sending to server:29103. We use port 29103 on the
-server because if we would send the data to port 9103, it would go directly to the
-Storage daemon, which doesn't understand encrypted data. On the server
-machine, we run Stunnel 4, which listens on port 29103, decrypts the data and
-sends it to the Storage daemon, which is listening on port 9103.
-
-\section{Data Channel Configuration}
-\index[general]{Modification of bacula-dir.conf for the Data Channel }
-\index[general]{baculoa-dir.conf!Modification for the Data Channel }
-
-The Storage resource of the bacula-dir.conf normally looks something like the
-following:
-
-\footnotesize
-\begin{verbatim}
-Storage {
- Name = File
- Address = server
- SDPort = 9103
- Password = storage_password
- Device = File
- Media Type = File
-}
-\end{verbatim}
-\normalsize
-
-Notice that this is running on the server machine, and it points the File
-daemon back to server:9103, which is where our Storage daemon is listening. We
-modify this to be:
-
-\footnotesize
-\begin{verbatim}
-Storage {
- Name = File
- Address = localhost
- SDPort = 9103
- Password = storage_password
- Device = File
- Media Type = File
-}
-\end{verbatim}
-\normalsize
-
-This causes the File daemon to send the data to the stunnel running on
-localhost (the client machine). We could have used client as the address as
-well.
-
-\section{Stunnel Configuration for the Data Channel}
-\index[general]{Stunnel Configuration for the Data Channel }
-
-In the diagram above, we see above Stunnel 2 that we use stunnel-fd2.conf on the
-client. A pretty much minimal config file would look like the following:
-
-\footnotesize
-\begin{verbatim}
-client = yes
-[29103]
-accept = localhost:9103
-connect = server:29103
-\end{verbatim}
-\normalsize
-
-The above config file does encrypt the data but it does not require a
-certificate, so it is subject to the man in the middle attack. The file I
-actually used, stunnel-fd2.conf, looked like this:
-
-\footnotesize
-\begin{verbatim}
-#
-# Stunnel conf for Bacula client -> SD
-#
-pid = /home/kern/bacula/bin/working/stunnel.pid
-#
-# A cert is not mandatory here. If verify=2, a
-# cert signed by a CA must be specified, and
-# either CAfile or CApath must point to the CA's
-# cert
-#
-cert = /home/kern/stunnel/stunnel.pem
-CAfile = /home/kern/ssl/cacert.pem
-verify = 2
-client = yes
-# debug = 7
-# foreground = yes
-[29103]
-accept = localhost:9103
-connect = server:29103
-\end{verbatim}
-\normalsize
-
-You will notice that I specified a pid file location because I ran stunnel
-under my own userid so I could not use the default, which requires root
-permission. I also specified a certificate that I have as well as verify level
-2 so that the certificate is required and verified, and I must supply the
-location of the CA (Certificate Authority) certificate so that the stunnel
-certificate can be verified. Finally, you will see that there are two lines
-commented out, which when enabled, produce a lot of nice debug info in the
-command window.
-
-If you do not have a signed certificate (stunnel.pem), you need to delete the
-cert, CAfile, and verify lines.
-
-Note that the stunnel.pem, is actually a private key and a certificate in a
-single file. These two can be kept and specified individually, but keeping
-them in one file is more convenient.
-
-The config file, stunnel-sd.conf, needed for Stunnel 4 on the server machine
-is:
-
-\footnotesize
-\begin{verbatim}
-#
-# Bacula stunnel conf for Storage daemon
-#
-pid = /home/kern/bacula/bin/working/stunnel.pid
-#
-# A cert is mandatory here, it may be self signed
-# If it is self signed, the client may not use
-# verify
-#
-cert = /home/kern/stunnel/stunnel.pem
-client = no
-# debug = 7
-# foreground = yes
-[29103]
-accept = 29103
-connect = 9103
-\end{verbatim}
-\normalsize
-
-\section{Starting and Testing the Data Encryption}
-\index[general]{Starting and Testing the Data Encryption }
-\index[general]{Encryption!Starting and Testing the Data }
-
-It will most likely be the simplest to implement the Data Channel encryption
-in the following order:
-
-\begin{itemize}
-\item Setup and run Bacula backing up some data on your client machine
- without encryption.
-\item Stop Bacula.
-\item Modify the Storage resource in the Director's conf file.
-\item Start Bacula
-\item Start stunnel on the server with:
-
- \footnotesize
-\begin{verbatim}
- stunnel stunnel-sd.conf
-
-\end{verbatim}
-\normalsize
-
-\item Start stunnel on the client with:
-
- \footnotesize
-\begin{verbatim}
- stunnel stunnel-fd2.conf
-
-\end{verbatim}
-\normalsize
-
-\item Run a job.
-\item If it doesn't work, turn debug on in both stunnel conf files, restart
- the stunnels, rerun the job, repeat until it works.
- \end{itemize}
-
-\section{Encrypting the Control Channel}
-\index[general]{Channel!Encrypting the Control }
-\index[general]{Encrypting the Control Channel }
-
-The Job control channel is between the Director and the File daemon, and as
-mentioned above, it is not really necessary to encrypt, but it is good
-practice to encrypt it as well. The two stunnels that are used in this case
-will be Stunnel 1 and Stunnel 3 in the diagram above. Stunnel 3 on the server
-might normally listen on port 9102, but if you have a local File daemon, this
-will not work, so we make it listen on port 29102. It then sends the data to
-client:29102. Again we use port 29102 so that the stunnel on the client
-machine can decrypt the data before passing it on to port 9102 where the File
-daemon is listening.
-
-\section{Control Channel Configuration}
-\index[general]{Control Channel Configuration }
-
-We need to modify the standard Client resource, which would normally look
-something like:
-
-\footnotesize
-\begin{verbatim}
-Client {
- Name = client-fd
- Address = client
- FDPort = 9102
- Catalog = BackupDB
- Password = "xxx"
-}
-\end{verbatim}
-\normalsize
-
-to be:
-
-\footnotesize
-\begin{verbatim}
-Client {
- Name = client-fd
- Address = localhost
- FDPort = 29102
- Catalog = BackupDB
- Password = "xxx"
-}
-\end{verbatim}
-\normalsize
-
-This will cause the Director to send the control information to
-localhost:29102 instead of directly to the client.
-
-\section{Stunnel Configuration for the Control Channel}
-\index[general]{Config Files for stunnel to Encrypt the Control Channel }
-
-The stunnel config file, stunnel-dir.conf, for the Director's machine would
-look like the following:
-
-\footnotesize
-\begin{verbatim}
-#
-# Bacula stunnel conf for the Directory to contact a client
-#
-pid = /home/kern/bacula/bin/working/stunnel.pid
-#
-# A cert is not mandatory here. If verify=2, a
-# cert signed by a CA must be specified, and
-# either CAfile or CApath must point to the CA's
-# cert
-#
-cert = /home/kern/stunnel/stunnel.pem
-CAfile = /home/kern/ssl/cacert.pem
-verify = 2
-client = yes
-# debug = 7
-# foreground = yes
-[29102]
-accept = localhost:29102
-connect = client:29102
-\end{verbatim}
-\normalsize
-
-and the config file, stunnel-fd1.conf, needed to run stunnel on the Client
-would be:
-
-\footnotesize
-\begin{verbatim}
-#
-# Bacula stunnel conf for the Directory to contact a client
-#
-pid = /home/kern/bacula/bin/working/stunnel.pid
-#
-# A cert is not mandatory here. If verify=2, a
-# cert signed by a CA must be specified, and
-# either CAfile or CApath must point to the CA's
-# cert
-#
-cert = /home/kern/stunnel/stunnel.pem
-CAfile = /home/kern/ssl/cacert.pem
-verify = 2
-client = yes
-# debug = 7
-# foreground = yes
-[29102]
-accept = localhost:29102
-connect = client:29102
-\end{verbatim}
-\normalsize
-
-\section{Starting and Testing the Control Channel}
-\index[general]{Starting and Testing the Control Channel }
-\index[general]{Channel!Starting and Testing the Control }
-
-It will most likely be the simplest to implement the Control Channel
-encryption in the following order:
-
-\begin{itemize}
-\item Stop Bacula.
-\item Modify the Client resource in the Director's conf file.
-\item Start Bacula
-\item Start stunnel on the server with:
-
- \footnotesize
-\begin{verbatim}
- stunnel stunnel-dir.conf
-
-\end{verbatim}
-\normalsize
-
-\item Start stunnel on the client with:
-
- \footnotesize
-\begin{verbatim}
- stunnel stunnel-fd1.conf
-
-\end{verbatim}
-\normalsize
-
-\item Run a job.
-\item If it doesn't work, turn debug on in both stunnel conf files, restart
- the stunnels, rerun the job, repeat until it works.
- \end{itemize}
-
-\section{Using stunnel to Encrypt to a Second Client}
-\index[general]{Using stunnel to Encrypt to a Second Client }
-\index[general]{Client!Using stunnel to Encrypt to a Second }
-
-On the client machine, you can just duplicate the setup that you have on the
-first client file for file and it should work fine.
-
-In the bacula-dir.conf file, you will want to create a second client pretty
-much identical to how you did for the first one, but the port number must be
-unique. We previously used:
-
-\footnotesize
-\begin{verbatim}
-Client {
- Name = client-fd
- Address = localhost
- FDPort = 29102
- Catalog = BackupDB
- Password = "xxx"
-}
-\end{verbatim}
-\normalsize
-
-so for the second client, we will, of course, have a different name, and we
-will also need a different port. Remember that we used port 29103 for the
-Storage daemon, so for the second client, we can use port 29104, and the
-Client resource would look like:
-
-\footnotesize
-\begin{verbatim}
-Client {
- Name = client2-fd
- Address = localhost
- FDPort = 29104
- Catalog = BackupDB
- Password = "yyy"
-}
-\end{verbatim}
-\normalsize
-
-Now, fortunately, we do not need a third stunnel to on the Director's machine,
-we can just add the new port to the config file, stunnel-dir.conf, to make:
-
-\footnotesize
-\begin{verbatim}
-#
-# Bacula stunnel conf for the Directory to contact a client
-#
-pid = /home/kern/bacula/bin/working/stunnel.pid
-#
-# A cert is not mandatory here. If verify=2, a
-# cert signed by a CA must be specified, and
-# either CAfile or CApath must point to the CA's
-# cert
-#
-cert = /home/kern/stunnel/stunnel.pem
-CAfile = /home/kern/ssl/cacert.pem
-verify = 2
-client = yes
-# debug = 7
-# foreground = yes
-[29102]
-accept = localhost:29102
-connect = client:29102
-[29104]
-accept = localhost:29102
-connect = client2:29102
-\end{verbatim}
-\normalsize
-
-There are no changes necessary to the Storage daemon or the other stunnel so
-that this new client can talk to our Storage daemon.
-
-\section{Creating a Self-signed Certificate}
-\index[general]{Creating a Self-signed Certificate }
-\index[general]{Certificate!Creating a Self-signed }
-
-You may create a self-signed certificate for use with stunnel that will permit
-you to make it function, but will not allow certificate validation. The .pem
-file containing both the certificate and the key can be made with the
-following, which I put in a file named {\bf makepem}:
-
-\footnotesize
-\begin{verbatim}
-#!/bin/sh
-#
-# Simple shell script to make a .pem file that can be used
-# with stunnel and Bacula
-#
-OPENSSL=openssl
- umask 77
- PEM1="/bin/mktemp openssl.XXXXXX"
- PEM2="/bin/mktemp openssl.XXXXXX"
- ${OPENSSL} req -newkey rsa:1024 -keyout $PEM1 -nodes \
- -x509 -days 365 -out $PEM2
- cat $PEM1 > stunnel.pem
- echo "" >>stunnel.pem
- cat $PEM2 >>stunnel.pem
- rm $PEM1 $PEM2
-\end{verbatim}
-\normalsize
-
-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.
-
-
-\section{Getting a CA Signed Certificate}
-\index[general]{Certificate!Getting a CA Signed }
-\index[general]{Getting a CA Signed Certificate }
-
-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:
-\elink{
-http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
-{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
-Note, this link may change.
-
-\section{Using ssh to Secure the Communications}
-\index[general]{Communications!Using ssh to Secure the }
-\index[general]{Using ssh to Secure the Communications }
-
-Please see the script {\bf ssh-tunnel.sh} in the {\bf examples} directory. It
-was contributed by Stephan Holl.
projects / bacula / docs / blobdiff