X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fmanual%2Fstunnel.tex;h=4907865175d951904e7ec9a5c0d953db86b2d01e;hb=c957321e0c7ff8d440bcc1fd5755536e9c53b8a8;hp=8a3f62d367cb261fbc453eceb5be354959329022;hpb=43c7a9ed95849481477c1c4b75d36fbcb0391690;p=bacula%2Fdocs diff --git a/docs/manual/stunnel.tex b/docs/manual/stunnel.tex index 8a3f62d3..49078651 100644 --- a/docs/manual/stunnel.tex +++ b/docs/manual/stunnel.tex @@ -1,15 +1,13 @@ %% %% -\section*{Using stunnel to Encrypt Communications to Clients} -\label{_ChapterStart6} -\index[general]{Clients!Using Bacula to Encrypt Communications to } -\index[general]{Using Bacula to Encrypt Communications to Clients } -\addcontentsline{toc}{section}{Using Bacula to Encrypt Communications to -Clients} +\chapter{Using Stunnel to Encrypt Communications} +\label{StunnelChapter} +\index[general]{Using Stunnel to Encrypt Communications to Clients } -Prior to verion 1.37, Bacula did not have built-in communications encryption. -Please see the TLS chapter if you are using Bacula 1.37 or greater. +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 @@ -21,41 +19,38 @@ 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. -\subsection*{Communications Ports Used} +\section{Communications Ports Used} \index[general]{Used!Communications Ports } \index[general]{Communications Ports Used } -\addcontentsline{toc}{subsection}{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 in the typical server/client view of +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. +daemon. -\subsection*{Encryption} +\section{Encryption} \index[general]{Encryption } -\addcontentsline{toc}{subsection}{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 a stunnel on the File daemon's machine (client), which decrypts the +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 -server and two on client. This may sound a bit complicated, but it really +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. -\subsection*{A Picture} +\section{A Picture} \index[general]{Picture } -\addcontentsline{toc}{subsection}{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 @@ -84,9 +79,8 @@ moment. \end{verbatim} \normalsize -\subsection*{Certificates} +\section{Certificates} \index[general]{Certificates } -\addcontentsline{toc}{subsection}{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 @@ -105,33 +99,30 @@ middle attack and hence loss of your data. See below for how to create a self-signed certificate. -\subsection*{Securing the Data Channel} +\section{Securing the Data Channel} \index[general]{Channel!Securing the Data } \index[general]{Securing the Data Channel } -\addcontentsline{toc}{subsection}{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 needs to be encrypted, because it is the one that transports your +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 a stunnel that listens on port 9103 on +(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 sent the data to port 9103, it would go directly to 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. -\subsection*{Modification of bacula-dir.conf for the Data Channel} +\section{Data Channel Configuration} \index[general]{Modification of bacula-dir.conf for the Data Channel } -\index[general]{Channel!Modification of bacula-dir.conf for the Data } -\addcontentsline{toc}{subsection}{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: @@ -170,13 +161,10 @@ 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. -\subsection*{config Files for stunnel to Encrypt the Data Channel} -\index[general]{Config Files for stunnel to Encrypt the Data Channel } -\index[general]{Channel!config Files for stunnel to Encrypt the Data } -\addcontentsline{toc}{subsection}{config Files for stunnel to Encrypt the Data -Channel} +\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 stunnel-fd2.conf on +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 @@ -256,10 +244,9 @@ connect = 9103 \end{verbatim} \normalsize -\subsection*{Starting and Testing the Data Encryption} +\section{Starting and Testing the Data Encryption} \index[general]{Starting and Testing the Data Encryption } \index[general]{Encryption!Starting and Testing the Data } -\addcontentsline{toc}{subsection}{Starting and Testing the Data Encryption} It will most likely be the simplest to implement the Data Channel encryption in the following order: @@ -293,10 +280,9 @@ in the following order: the stunnels, rerun the job, repeat until it works. \end{itemize} -\subsection*{Encrypting the Control Channel} +\section{Encrypting the Control Channel} \index[general]{Channel!Encrypting the Control } \index[general]{Encrypting the Control Channel } -\addcontentsline{toc}{subsection}{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 @@ -308,11 +294,8 @@ 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. -\subsection*{Modification of bacula-dir.conf for the Control Channel} -\index[general]{Channel!Modification of bacula-dir.conf for the Control } -\index[general]{Modification of bacula-dir.conf for the Control Channel } -\addcontentsline{toc}{subsection}{Modification of bacula-dir.conf for the -Control Channel} +\section{Control Channel Configuration} +\index[general]{Control Channel Configuration } We need to modify the standard Client resource, which would normally look something like: @@ -346,11 +329,8 @@ Client { This will cause the Director to send the control information to localhost:29102 instead of directly to the client. -\subsection*{config Files for stunnel to Encrypt the Control Channel} +\section{Stunnel Configuration for the Control Channel} \index[general]{Config Files for stunnel to Encrypt the Control Channel } -\index[general]{Channel!config Files for stunnel to Encrypt the Control } -\addcontentsline{toc}{subsection}{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: @@ -406,10 +386,9 @@ connect = client:29102 \end{verbatim} \normalsize -\subsection*{Starting and Testing the Control Channel} +\section{Starting and Testing the Control Channel} \index[general]{Starting and Testing the Control Channel } \index[general]{Channel!Starting and Testing the Control } -\addcontentsline{toc}{subsection}{Starting and Testing the Control Channel} It will most likely be the simplest to implement the Control Channel encryption in the following order: @@ -441,10 +420,9 @@ encryption in the following order: the stunnels, rerun the job, repeat until it works. \end{itemize} -\subsection*{Using stunnel to Encrypt to a Second Client} +\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 } -\addcontentsline{toc}{subsection}{Using stunnel to Encrypt to a Second Client} 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. @@ -515,10 +493,9 @@ connect = client2:29102 There are no changes necessary to the Storage daemon or the other stunnel so that this new client can talk to our Storage daemon. -\subsection*{Creating a Self-signed Certificate} +\section{Creating a Self-signed Certificate} \index[general]{Creating a Self-signed Certificate } \index[general]{Certificate!Creating a Self-signed } -\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate} 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 @@ -534,8 +511,8 @@ following, which I put in a file named {\bf makepem}: # OPENSSL=openssl umask 77 - PEM1=`/bin/mktemp openssl.XXXXXX` - PEM2=`/bin/mktemp openssl.XXXXXX` + 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 @@ -549,14 +526,15 @@ 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. -\subsection*{Getting a CA Signed Certificate} +\section{Getting a CA Signed Certificate} \index[general]{Certificate!Getting a CA Signed } \index[general]{Getting a CA Signed Certificate } -\addcontentsline{toc}{subsection}{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 +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 @@ -567,10 +545,9 @@ 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. -\subsection*{Using ssh to Secure the Communications} +\section{Using ssh to Secure the Communications} \index[general]{Communications!Using ssh to Secure the } \index[general]{Using ssh to Secure the Communications } -\addcontentsline{toc}{subsection}{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.