<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 2008 (1.71)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Bacula Security Issues</TITLE>
<META NAME="description" CONTENT="Bacula Security Issues">
<META NAME="keywords" CONTENT="main">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="LaTeX2HTML v2008">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="main.css">
<LINK REL="next" HREF="Bootstrap_File.html">
<LINK REL="previous" HREF="Catalog_Maintenance.html">
<LINK REL="up" HREF="Bacula_Main_Reference.html">
<LINK REL="next" HREF="Bootstrap_File.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html2040"
HREF="Bootstrap_File.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html2034"
HREF="Bacula_Main_Reference.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html2028"
HREF="Catalog_Maintenance.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html2036"
HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html2038"
HREF="Thanks.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html2041"
HREF="Bootstrap_File.html">The Bootstrap File</A>
<B> Up:</B> <A NAME="tex2html2035"
HREF="Bacula_Main_Reference.html">Bacula Main Reference</A>
<B> Previous:</B> <A NAME="tex2html2029"
HREF="Catalog_Maintenance.html">Catalog Maintenance</A>
<B> <A NAME="tex2html2037"
HREF="Contents.html">Contents</A></B>
<B> <A NAME="tex2html2039"
HREF="Thanks.html">Index</A></B>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
<UL>
<LI><A NAME="tex2html2042"
HREF="Bacula_Security_Issues.html#SECTION004610000000000000000">Backward Compatibility</A>
<LI><A NAME="tex2html2043"
HREF="Bacula_Security_Issues.html#SECTION004620000000000000000">Configuring and Testing TCP Wrappers</A>
<LI><A NAME="tex2html2044"
HREF="Bacula_Security_Issues.html#SECTION004630000000000000000">Running as non-root</A>
</UL>
<!--End of Table of Child-Links-->
<HR>
<H1><A NAME="SECTION004600000000000000000"></A>
<A NAME="SecurityChapter"></A>
<BR>
Bacula Security Issues
</H1>
<A NAME="22064"></A>
<A NAME="22065"></A>
<A NAME="22066"></A>
<P>
<UL>
<LI>Security means being able to restore your files, so read the
Critical Items ChapterCritical of this manual.
</LI>
<LI>The Clients (<B>bacula-fd</B>) must run as root to be able to access all
the system files.
</LI>
<LI>It is not necessary to run the Director as root.
</LI>
<LI>It is not necessary to run the Storage daemon as root, but you must
ensure that it can open the tape drives, which are often restricted to root
access by default. In addition, if you do not run the Storage daemon as root,
it will not be able to automatically set your tape drive parameters on most
OSes since these functions, unfortunately require root access.
</LI>
<LI>You should restrict access to the Bacula configuration files, so that
the passwords are not world-readable. The <B>Bacula</B> daemons are password
protected using CRAM-MD5 (i.e. the password is not sent across the network).
This will ensure that not everyone can access the daemons. It is a reasonably
good protection, but can be cracked by experts.
</LI>
<LI>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 (<B>etc/hosts.allow</B>).
</LI>
<LI>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
TLS (SSL) Communications EncryptionCommEncryption
section of this manual.
</LI>
<LI>You should ensure that the Bacula working directories are readable and
writable only by the Bacula daemons.
</LI>
<LI>If you are using <B>MySQL</B> it is not necessary for it to run with
<B>root</B> permission.
</LI>
<LI>The default Bacula <B>grant-mysql-permissions</B> script grants all
permissions to use the MySQL database without a password. If you want
security, please tighten this up!
</LI>
<LI>Don't forget that Bacula is a network program, so anyone anywhere on
the network with the console program and the Director's password can access
Bacula and the backed up data.
</LI>
<LI>You can restrict what IP addresses Bacula will bind to by using the
appropriate <B>DirAddress</B>, <B>FDAddress</B>, or <B>SDAddress</B> records in
the respective daemon configuration files.
</LI>
<LI>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.
<P>
See also Backing Up Your Bacula
Database - Security Considerations BackingUpBaculaSecurityConsiderations
for more information.
</LI>
</UL>
<P>
<H1><A NAME="SECTION004610000000000000000">
Backward Compatibility</A>
</H1>
<A NAME="22085"></A>
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.
<P>
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 ...
<P>
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.
<P>
If you want to be 100should:
<P>
1. Try reading old tapes from time to time - e.g. at least once
a year.
<P>
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 ...
<P>
The second point is probably overkill but if you want to be sure, it may
save you someday.
<P>
<A NAME="wrappers"></A>
<H1><A NAME="SECTION004620000000000000000">
Configuring and Testing TCP Wrappers</A>
</H1>
<A NAME="22088"></A>
<A NAME="22089"></A>
<A NAME="22090"></A>
<A NAME="22091"></A>
<P>
TCP Wrappers are implemented if you turn them on when configuring
(<B>./configure <code>--</code>with-tcp-wrappers</B>).
With this code enabled, you may control who may access your
daemons. This control is done by modifying the file: <B>/etc/hosts.allow</B>. The program name that <B>Bacula</B> 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 <B>twist</B> option in your <B>/etc/hosts.allow</B> or it will terminate the Bacula daemon when a
connection is refused.
<P>
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 Red Hat, the package is named
tcp_wrappers.
<P>
Dan Langille has provided the following information on configuring and
testing TCP wrappers with Bacula.
<P>
If you read hosts_options(5), you will see an option called twist. This
option replaces the current process by an instance of the specified shell
command. Typically, something like this is used:
<P>
<PRE>
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."
</PRE>
<P>
The libwrap code tries to avoid <B>twist</B> if it runs in a resident process,
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 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 rule set. The following example
is sufficient:
<P>
<PRE>
undef-fd : localhost : allow
undef-sd : localhost : allow
undef-dir : localhost : allow
undef-fd : ALL : deny
undef-sd : ALL : deny
undef-dir : ALL : deny
</PRE>
<P>
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.
<P>
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
rule set on the remote client will suffice:
<P>
<PRE>
undef-fd : director.example.org : allow
undef-fd : ALL : deny
</PRE>
<P>
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
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:
<P>
<PRE>
$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
Connection closed by foreign host.
$
</PRE>
<P>
This is the correct response. If you see this:
<P>
<PRE>
$ telnet undef 9103
Trying 192.168.0.56...
Connected to undef.example.org.
Escape character is '^]'.
You are not welcome to use undef-sd from xeon.example.org.
Connection closed by foreign host.
$
</PRE>
<P>
then twist has been invoked and your configuration is not correct and you need
to add the deny statement. It is important to note that your testing must
include restarting the daemons after each connection attempt. You can also
tcpdchk(8) and tcpdmatch(8) to validate your /etc/hosts.allow rules. Here is a
simple test using tcpdmatch:
<P>
<PRE>
$ tcpdmatch undef-dir xeon.example.org
warning: undef-dir: no such process name in /etc/inetd.conf
client: hostname xeon.example.org
client: address 192.168.0.18
server: process undef-dir
matched: /etc/hosts.allow line 40
option: allow
access: granted
</PRE>
<P>
If you are running Bacula as a standalone daemon, the warning above can be
safely ignored. Here is an example which indicates that your rules are missing
a deny statement and the twist option has been invoked.
<P>
<PRE>
$ tcpdmatch undef-dir 10.0.0.1
warning: undef-dir: no such process name in /etc/inetd.conf
client: address 10.0.0.1
server: process undef-dir
matched: /etc/hosts.allow line 91
option: severity auth.info
option: twist /bin/echo "You are not welcome to use
undef-dir from 10.0.0.1."
access: delegated
</PRE>
<P>
<H1><A NAME="SECTION004630000000000000000">
Running as non-root</A>
</H1>
<A NAME="22113"></A>
<P>
Security advice from Dan Langille:
<P>
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
be root. The Storage Daemon and the Director Daemon do not need to be root.
The File Daemon needs to be root in order to access all files on your system.
In order to run as non-root, you need to create a user and a group. Choosing
<TT>bacula</TT> as both the user name and the group name sounds like a good idea
to me.
<P>
The FreeBSD port creates this user and group for you.
Here is what those entries looked like on my FreeBSD laptop:
<P>
<PRE>
bacula:*:1002:1002::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
</PRE>
<P>
I used vipw to create this entry. I selected a User ID and Group ID of 1002
as they were unused on my system.
<P>
I also created a group in /etc/group:
<P>
<PRE>
bacula:*:1002:
</PRE>
<P>
The bacula user (as opposed to the Bacula daemon) will have a home directory
of <TT>/var/db/bacula</TT> which is the default location for the Bacula
database.
<P>
Now that you have both a bacula user and a bacula group, you can secure the
bacula home directory by issuing this command:
<P>
<PRE>
chown -R bacula:bacula /var/db/bacula/
</PRE>
<P>
This ensures that only the bacula user can access this directory. It also
means that if we run the Director and the Storage daemon as bacula, those
daemons also have restricted access. This would not be the case if they were
running as root.
<P>
It is important to note that the storage daemon actually needs to be in the
operator group for normal access to tape drives etc (at least on a FreeBSD
system, that's how things are set up by default) Such devices are normally
chown root:operator. It is easier and less error prone to make Bacula a
member of that group than it is to play around with system permissions.
<P>
Starting the Bacula daemons
<P>
To start the bacula daemons on a FreeBSD system, issue the following command:
<P>
<PRE>
/usr/local/etc/rc.d/bacula-dir start
/usr/local/etc/rc.d/bacula-sd start
/usr/local/etc/rc.d/bacula-fd start
</PRE>
<P>
To confirm they are all running:
<P>
<PRE>
$ ps auwx | grep bacula
root 63418 0.0 0.3 1856 1036 ?? Ss 4:09PM 0:00.00
/usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
bacula 63416 0.0 0.3 2040 1172 ?? Ss 4:09PM 0:00.01
/usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
bacula 63422 0.0 0.4 2360 1440 ?? Ss 4:09PM 0:00.00
/usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf
</PRE>
<P>
<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html2040"
HREF="Bootstrap_File.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html2034"
HREF="Bacula_Main_Reference.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html2028"
HREF="Catalog_Maintenance.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html2036"
HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html2038"
HREF="Thanks.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html2041"
HREF="Bootstrap_File.html">The Bootstrap File</A>
<B> Up:</B> <A NAME="tex2html2035"
HREF="Bacula_Main_Reference.html">Bacula Main Reference</A>
<B> Previous:</B> <A NAME="tex2html2029"
HREF="Catalog_Maintenance.html">Catalog Maintenance</A>
<B> <A NAME="tex2html2037"
HREF="Contents.html">Contents</A></B>
<B> <A NAME="tex2html2039"
HREF="Thanks.html">Index</A></B>
<!--End of Navigation Panel-->
<ADDRESS>
2012-01-24
</ADDRESS>
</BODY>
</HTML>
