See also Backing Up Your Bacula Database - Security Considerations BackingUpBaculaSecurityConsiderations for more information.
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 100should:
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 ...
The second point is probably overkill but if you want to be sure, it may save you someday.
TCP Wrappers are implemented if you turn them on when configuring
With this code enabled, you may control who may access your
daemons. This control is done by modifying the file: /etc/hosts.allow. The program name that 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 twist option in your /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 Red Hat, 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 option replaces the current process by an instance of the specified shell command. Typically, something like this is used:
ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h."
The libwrap code tries to avoid twist 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:
undef-fd : localhost : allow undef-sd : localhost : allow undef-dir : localhost : allow undef-fd : ALL : deny undef-sd : ALL : deny undef-dir : ALL : deny
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 rule set on the remote client will suffice:
undef-fd : director.example.org : allow undef-fd : ALL : deny
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:
$ telnet undef 9103 Trying 192.168.0.56... Connected to undef.example.org. Escape character is '^]'. Connection closed by foreign host. $
This is the correct response. If you see this:
$ 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. $
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:
$ 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
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.
$ 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
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 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 bacula as both the user name and the group name sounds like a good idea to me.
The FreeBSD port creates this user and group for you. Here is what those entries looked like on my FreeBSD laptop:
I used vipw to create this entry. I selected a User ID and Group ID of 1002 as they were unused on my system.
I also created a group in /etc/group:
The bacula user (as opposed to the Bacula daemon) will have a home directory of /var/db/bacula which is the default location for the Bacula database.
Now that you have both a bacula user and a bacula group, you can secure the bacula home directory by issuing this command:
chown -R bacula:bacula /var/db/bacula/
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.
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.
Starting the Bacula daemons
To start the bacula daemons on a FreeBSD system, issue the following command:
/usr/local/etc/rc.d/bacula-dir start /usr/local/etc/rc.d/bacula-sd start /usr/local/etc/rc.d/bacula-fd start
To confirm they are all running:
$ 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
Kern Sibbald 2013-05-14