\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.
-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.
+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 ...
-Dan Languille has provided the following information on configuring and
+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.
If you read hosts\_options(5), you will see an option called twist. This
The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
but that test will not protect the first hosts\_access() call. This will
-result in the prcess (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
+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}
\normalsize
where director.example.org is the host which will be contacting the client
-(ie. the box on which the Bacula Director daemon runs). The use of ``ALL :
-deny'' ensures that the twist option (if present) is not invoked. To properly
+(ie. the box on which the Bacula Director daemon runs). The use of "ALL :
+deny" ensures that the twist option (if present) is not invoked. To properly
test your configuration, start the daemon(s), then attempt to connect from an
IP address which should be able to connect. You should see something like
this:
\index[general]{Running as non-root }
\addcontentsline{toc}{subsection}{Running as non-root}
-Security advice from Dan Languille:
+Security advice from Dan Langille:
It is a good idea to run daemons with the lowest possible privileges. In
other words, if you can, don't run applications as root which do not have to
\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