\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
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 recogize old formats. All the problems except the
+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
\label{wrappers}
-subsection*{Configuring and Testing TCP Wrappers}
-index[general]{Configuring and Testing TCP Wrappers}
-addcontentsline{toc}{subsection}{Configuring and Testing TCP 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}).
/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