4 \chapter{Bacula Security Issues}
5 \label{SecurityChapter}
6 \index[general]{Bacula Security Issues}
7 \index[general]{Security}
8 \index[general]{Issues!Bacula Security}
11 \item Security means being able to restore your files, so read the
12 \ilink{Critical Items Chapter}{Critical} of this manual.
13 \item The Clients ({\bf bacula-fd}) must run as root to be able to access all
15 \item It is not necessary to run the Director as root.
16 \item It is not necessary to run the Storage daemon as root, but you must
17 ensure that it can open the tape drives, which are often restricted to root
18 access by default. In addition, if you do not run the Storage daemon as root,
19 it will not be able to automatically set your tape drive parameters on most
20 OSes since these functions, unfortunately require root access.
21 \item You should restrict access to the Bacula configuration files, so that
22 the passwords are not world-readable. The {\bf Bacula} daemons are password
23 protected using CRAM-MD5 (i.e. the password is not sent across the network).
24 This will ensure that not everyone can access the daemons. It is a reasonably
25 good protection, but can be cracked by experts.
26 \item If you are using the recommended ports 9101, 9102, and 9103, you will
27 probably want to protect these ports from external access using a firewall
28 and/or using tcp wrappers ({\bf etc/hosts.allow}).
29 \item By default, all data that is sent across the network is unencrypted.
30 However, Bacula does support TLS (transport layer security) and can
31 encrypt transmitted data. Please read the
32 \ilink{TLS (SSL) Communications Encryption}{CommEncryption}
33 section of this manual.
34 \item You should ensure that the Bacula working directories are readable and
35 writable only by the Bacula daemons.
36 \item If you are using {\bf MySQL} it is not necessary for it to run with
37 {\bf root} permission.
38 \item The default Bacula {\bf grant-mysql-permissions} script grants all
39 permissions to use the MySQL database without a password. If you want
40 security, please tighten this up!
41 \item Don't forget that Bacula is a network program, so anyone anywhere on
42 the network with the console program and the Director's password can access
43 Bacula and the backed up data.
44 \item You can restrict what IP addresses Bacula will bind to by using the
45 appropriate {\bf DirAddress}, {\bf FDAddress}, or {\bf SDAddress} records in
46 the respective daemon configuration files.
47 \item Be aware that if you are backing up your database using the default
48 script, if you have a password on your database, it will be passed as
49 a command line option to that script, and any user will be able to see
50 this information. If you want it to be secure, you will need to pass it
51 by an environment variable or a secure file.
55 \section{Backward Compatibility}
56 \index[general]{Backward Compatibility}
57 One of the major goals of Bacula is to ensure that you can restore
58 tapes (I'll use the word tape to include disk Volumes) that you wrote years
59 ago. This means that each new version of Bacula should be able to read old
60 format tapes. The first problem you will have is to ensure that the
61 hardware is still working some years down the road, and the second
62 problem will be to ensure that the media will still be good, then
63 your OS must be able to interface to the device, and finally Bacula
64 must be able to recognize old formats. All the problems except the
65 last are ones that we cannot solve, but by careful planning you can.
67 Since the very beginning of Bacula (January 2000) until today (December
68 2005), there have been two major Bacula tape formats. The second format
69 was introduced in version 1.27 in November of 2002, and it has not
70 changed since then. In principle, Bacula can still read the original
71 format, but I haven't tried it lately so who knows ...
73 Though the tape format is fixed, the kinds of data that we can put on the
74 tapes are extensible, and that is how we added new features
75 such as ACLs, Win32 data, encrypted data, ... Obviously, an older
76 version of Bacula would not know how to read these newer data streams,
77 but each newer version of Bacula should know how to read all the
80 If you want to be 100% sure that you can read old tapes, you
83 1. Try reading old tapes from time to time -- e.g. at least once
86 2. Keep statically linked copies of every version of Bacula that you use
87 in production then if for some reason, we botch up old tape compatibility, you
88 can always pull out an old copy of Bacula ...
90 The second point is probably overkill but if you want to be sure, it may
96 \section{Configuring and Testing TCP Wrappers}
97 \index[general]{Configuring and Testing TCP Wrappers}
98 \index[general]{TCP Wrappers}
99 \index[general]{Wrappers!TCP}
100 \index[general]{libwrappers}
102 TCP Wrappers are implemented if you turn them on when configuring
103 ({\bf ./configure \verb:--:with-tcp-wrappers}).
104 With this code enabled, you may control who may access your
105 daemons. This control is done by modifying the file: {\bf
106 /etc/hosts.allow}. The program name that {\bf Bacula} uses when
107 applying these access restrictions is the name you specify in the
108 daemon configuration file (see below for examples).
109 You must not use the {\bf twist} option in your {\bf
110 /etc/hosts.allow} or it will terminate the Bacula daemon when a
111 connection is refused.
113 The exact name of the package you need loaded to build with TCP wrappers
114 depends on the system. For example,
115 on SuSE, the TCP wrappers libraries needed to link Bacula are
116 contained in the tcpd-devel package. On Red Hat, the package is named
119 Dan Langille has provided the following information on configuring and
120 testing TCP wrappers with Bacula.
122 If you read hosts\_options(5), you will see an option called twist. This
123 option replaces the current process by an instance of the specified shell
124 command. Typically, something like this is used:
129 : severity auth.info \
130 : twist /bin/echo "You are not welcome to use %d from %h."
134 The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
135 but that test will not protect the first hosts\_access() call. This will
136 result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
137 if the first connection to their port results in the twist option being
138 invoked. The potential, and I stress potential, exists for an attacker to
139 prevent the daemons from running. This situation is eliminated if your
140 /etc/hosts.allow file contains an appropriate rule set. The following example
145 undef-fd : localhost : allow
146 undef-sd : localhost : allow
147 undef-dir : localhost : allow
148 undef-fd : ALL : deny
149 undef-sd : ALL : deny
150 undef-dir : ALL : deny
154 You must adjust the names to be the same as the Name directives found
155 in each of the daemon configuration files. They are, in general, not the
156 same as the binary daemon names. It is not possible to use the
157 daemon names because multiple daemons may be running on the same machine
158 but with different configurations.
160 In these examples, the Director is undef-dir, the
161 Storage Daemon is undef-sd, and the File Daemon is undef-fd. Adjust to suit
162 your situation. The above example rules assume that the SD, FD, and DIR all
163 reside on the same box. If you have a remote FD client, then the following
164 rule set on the remote client will suffice:
168 undef-fd : director.example.org : allow
169 undef-fd : ALL : deny
173 where director.example.org is the host which will be contacting the client
174 (ie. the box on which the Bacula Director daemon runs). The use of "ALL :
175 deny" ensures that the twist option (if present) is not invoked. To properly
176 test your configuration, start the daemon(s), then attempt to connect from an
177 IP address which should be able to connect. You should see something like
183 Trying 192.168.0.56...
184 Connected to undef.example.org.
185 Escape character is '^]'.
186 Connection closed by foreign host.
191 This is the correct response. If you see this:
196 Trying 192.168.0.56...
197 Connected to undef.example.org.
198 Escape character is '^]'.
199 You are not welcome to use undef-sd from xeon.example.org.
200 Connection closed by foreign host.
205 then twist has been invoked and your configuration is not correct and you need
206 to add the deny statement. It is important to note that your testing must
207 include restarting the daemons after each connection attempt. You can also
208 tcpdchk(8) and tcpdmatch(8) to validate your /etc/hosts.allow rules. Here is a
209 simple test using tcpdmatch:
213 $ tcpdmatch undef-dir xeon.example.org
214 warning: undef-dir: no such process name in /etc/inetd.conf
215 client: hostname xeon.example.org
216 client: address 192.168.0.18
217 server: process undef-dir
218 matched: /etc/hosts.allow line 40
224 If you are running Bacula as a standalone daemon, the warning above can be
225 safely ignored. Here is an example which indicates that your rules are missing
226 a deny statement and the twist option has been invoked.
230 $ tcpdmatch undef-dir 10.0.0.1
231 warning: undef-dir: no such process name in /etc/inetd.conf
232 client: address 10.0.0.1
233 server: process undef-dir
234 matched: /etc/hosts.allow line 91
235 option: severity auth.info
236 option: twist /bin/echo "You are not welcome to use
237 undef-dir from 10.0.0.1."
242 \section{Running as non-root}
243 \index[general]{Running as non-root }
245 Security advice from Dan Langille:
246 % TODO: don't use specific name
248 % TODO: don't be too specific on operating system
250 % TODO: maybe remove personalization?
252 It is a good idea to run daemons with the lowest possible privileges. In
253 other words, if you can, don't run applications as root which do not have to
254 be root. The Storage Daemon and the Director Daemon do not need to be root.
255 The File Daemon needs to be root in order to access all files on your system.
256 In order to run as non-root, you need to create a user and a group. Choosing
257 {\tt bacula} as both the user name and the group name sounds like a good idea
260 The FreeBSD port creates this user and group for you.
261 Here is what those entries looked like on my FreeBSD laptop:
265 bacula:*:1002:1002::0:0:Bacula Daemon:/var/db/bacula:/sbin/nologin
269 I used vipw to create this entry. I selected a User ID and Group ID of 1002
270 as they were unused on my system.
272 I also created a group in /etc/group:
280 The bacula user (as opposed to the Bacula daemon) will have a home directory
281 of {\tt /var/db/bacula} which is the default location for the Bacula
284 Now that you have both a bacula user and a bacula group, you can secure the
285 bacula home directory by issuing this command:
289 chown -R bacula:bacula /var/db/bacula/
293 This ensures that only the bacula user can access this directory. It also
294 means that if we run the Director and the Storage daemon as bacula, those
295 daemons also have restricted access. This would not be the case if they were
298 It is important to note that the storage daemon actually needs to be in the
299 operator group for normal access to tape drives etc (at least on a FreeBSD
300 system, that's how things are set up by default) Such devices are normally
301 chown root:operator. It is easier and less error prone to make Bacula a
302 member of that group than it is to play around with system permissions.
304 Starting the Bacula daemons
306 To start the bacula daemons on a FreeBSD system, issue the following command:
310 /usr/local/etc/rc.d/bacula.sh start
314 To confirm they are all running:
318 $ ps auwx | grep bacula
319 root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
320 /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
321 root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
322 /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
323 root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
324 /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf