\section*{Bacula Security Issues}
\label{_ChapterStart14}
-\index[general]{Bacula Security Issues }
-\index[general]{Issues!Bacula Security }
+\index[general]{Bacula Security Issues}
+\index[general]{Security}
+\index[general]{Issues!Bacula Security}
\addcontentsline{toc}{section}{Bacula Security Issues}
\begin{itemize}
\item If you are using the recommended ports 9101, 9102, and 9103, you will
probably want to protect these ports from external access using a firewall
and/or using tcp wrappers ({\bf etc/hosts.allow}).
-\item Currently all data that is sent across the network is unencrypted. As a
- consequence, unless you use {\bf ssh} or {\bf stunnel} for port forwarding,
- it is not recommended to do a backup across an insecure network (e.g. the
-Internet). In a future version, we plan to have {\bf ssl} encryption
-built-in.
+\item By default, all data that is sent across the network is unencrypted.
+ However, Bacula does support TLS (transport layer security) and can
+ encrypt transmitted data. Please read the
+ \ilink{TLS (SSL) Communications Encryption}{CommEncryption}
+ section of this manual.
\item You should ensure that the Bacula working directories are readable and
writable only by the Bacula daemons.
\item If you are using {\bf MySQL} it is not necessary for it to run with
\item You can restrict what IP addresses Bacula will bind to by using the
appropriate {\bf DirAddress}, {\bf FDAddress}, or {\bf SDAddress} records in
the respective daemon configuration files.
+\item Be aware that if you are backing up your database using the default
+ script, if you have a password on your database, it will be passed as
+ a command line option to that script, and any user will be able to see
+ this information. If you want it to be secure, you will need to pass it
+ by an environment variable or a secure file.
\end{itemize}
-\label{wrappers}
-\subsection*{Configuring and Testing TCP Wrappers with Bacula}
-\index[general]{Configuring and Testing TCP Wrappers with Bacula }
-\addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers with
-Bacula}
+\subsection*{Backward Compatibility}
+\index[general]{Backward Compatibility}
+\addcontentsline{toc}{subsection}{Backward Compatibility}
+One of the major goals of Bacula is to ensure that you can restore
+tapes (I'll use the word tape to include disk Volumes) that you wrote years
+ago. This means that each new version of Bacula should be able to read old
+format tapes. The first problem you will have is to ensure that the
+hardware is still working some years down the road, and the second
+problem will be to ensure that the media will still be good, then
+your OS must be able to interface to the device, and finally Bacula
+must be able to recognize old formats. All the problems except the
+last are ones that we cannot solve, but by careful planning you can.
+
+Since the very beginning of Bacula (January 2000) until today (December
+2005), there have been two major Bacula tape formats. The second format
+was introduced in version 1.27 in November of 2002, and it has not
+changed since then. In principle, Bacula can still read the original
+format, but I haven't tried it lately so who knows ...
+
+Though the tape format is fixed, the kinds of data that we can put on the
+tapes are extensible, and that is how we added new features
+such as ACLs, Win32 data, encrypted data, ... Obviously, an older
+version of Bacula would not know how to read these newer data streams,
+but each newer version of Bacula should know how to read all the
+older streams.
+
+If you want to be 100% sure that you can read old tapes, you
+should:
+
+1. Try reading old tapes from time to time -- e.g. at least once
+a year.
+
+2. Keep statically linked copies of every version of Bacula that you use
+in production then if for some reason, we botch up old tape compatibility, you
+can always pull out an old copy of Bacula ...
-TCP Wrappers are implemented if you turn them on when configuring ({\bf
-./configure \verb:--:with-libwrap}). With this code enabled, you may control who may
-access your daemons. This control is done by modifying the file: {\bf
-/etc/hosts.allow}. The program name that {\bf Bacula} uses when applying these
-access restrictions is the name you specify in the daemon configuration file.
-You must not use the {\bf twist} option in your {\bf /etc/hosts.allow} or it
-will terminate the Bacula daemon when a connection is refused.
+The second point is probably overkill but if you want to be sure, it may
+save you someday.
+
+
+
+\label{wrappers}
+\subsection*{Configuring and Testing TCP Wrappers}
+\index[general]{Configuring and Testing TCP Wrappers}
+\index[general]{TCP Wrappers}
+\index[general]{Wrappers!TCP}
+\index[general]{libwrappers}
+\addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers}
+
+TCP Wrappers are implemented if you turn them on when configuring
+({\bf ./configure \verb:--:with-tcp-wrappers}).
+With this code enabled, you may control who may access your
+daemons. This control is done by modifying the file: {\bf
+/etc/hosts.allow}. The program name that {\bf Bacula} uses when
+applying these access restrictions is the name you specify in the
+daemon configuration file (see below for examples).
+You must not use the {\bf twist} option in your {\bf
+/etc/hosts.allow} or it will terminate the Bacula daemon when a
+connection is refused.
+
+The exact name of the package you need loaded to build with TCP wrappers
+depends on the system. For example,
+on SuSE, the TCP wrappers libraries needed to link Bacula are
+contained in the tcpd-devel package. On RedHat the package is named
+tcp\_wrappers.
Dan Langille has provided the following information on configuring and
testing TCP wrappers with Bacula.
but that test will not protect the first hosts\_access() call. This will
result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
if the first connection to their port results in the twist option being
-invoked. The potential, and I strees potential, exists for an attacker to
+invoked. The potential, and I stress potential, exists for an attacker to
prevent the daemons from running. This situation is eliminated if your
-/etc/hosts.allow file contains an appropriate ruleset. The following example
-is sufficent:
+/etc/hosts.allow file contains an appropriate rule set. The following example
+is sufficient:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-You must adjust the daemon names to those found in the respective daemon
-configuration files. In these examples, the Director is undef- dir, the
+You must adjust the names to be the same as the Name directives found
+in each of the daemon configuration files. They are, in general, not the
+same as the binary daemon names. It is not possible to use the
+daemon names because multiple daemons may be running on the same machine
+but with different configurations.
+
+In these examples, the Director is undef-dir, the
Storage Daemon is undef-sd, and the File Daemon is undef-fd. Adjust to suit
your situation. The above example rules assume that the SD, FD, and DIR all
reside on the same box. If you have a remote FD client, then the following
-ruleset on the remote client will suffice:
+rule set on the remote client will suffice:
\footnotesize
\begin{verbatim}
\footnotesize
\begin{verbatim}
-bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
+bacula:*:1002:1002::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
\end{verbatim}
\normalsize
projects / bacula / docs / blobdiff