4 \section*{Bacula Security Issues}
5 \label{_ChapterStart14}
6 \index[general]{Bacula Security Issues }
7 \index[general]{Issues!Bacula Security }
8 \addcontentsline{toc}{section}{Bacula Security Issues}
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 Currently all data that is sent across the network is unencrypted. As a
30 consequence, unless you use {\bf ssh} or {\bf stunnel} for port forwarding,
31 it is not recommended to do a backup across an insecure network (e.g. the
32 Internet). In a future version, we plan to have {\bf ssl} encryption
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.
51 \subsection*{Configuring and Testing TCP Wrappers with Bacula}
52 \index[general]{Configuring and Testing TCP Wrappers with Bacula }
53 \addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers with
56 TCP Wrappers are implemented if you turn them on when configuring ({\bf
57 ./configure \verb:--:with-libwrap}). With this code enabled, you may control who may
58 access your daemons. This control is done by modifying the file: {\bf
59 /etc/hosts.allow}. The program name that {\bf Bacula} uses when applying these
60 access restrictions is the name you specify in the daemon configuration file.
61 You must not use the {\bf twist} option in your {\bf /etc/hosts.allow} or it
62 will terminate the Bacula daemon when a connection is refused.
64 Dan Langille has provided the following information on configuring and
65 testing TCP wrappers with Bacula.
67 If you read hosts\_options(5), you will see an option called twist. This
68 option replaces the current process by an instance of the specified shell
69 command. Typically, something like this is used:
74 : severity auth.info \
75 : twist /bin/echo "You are not welcome to use %d from %h."
79 The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
80 but that test will not protect the first hosts\_access() call. This will
81 result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
82 if the first connection to their port results in the twist option being
83 invoked. The potential, and I strees potential, exists for an attacker to
84 prevent the daemons from running. This situation is eliminated if your
85 /etc/hosts.allow file contains an appropriate ruleset. The following example
90 undef-fd : localhost : allow
91 undef-sd : localhost : allow
92 undef-dir : localhost : allow
95 undef-dir : ALL : deny
99 You must adjust the daemon names to those found in the respective daemon
100 configuration files. In these examples, the Director is undef- dir, the
101 Storage Daemon is undef-sd, and the File Daemon is undef-fd. Adjust to suit
102 your situation. The above example rules assume that the SD, FD, and DIR all
103 reside on the same box. If you have a remote FD client, then the following
104 ruleset on the remote client will suffice:
108 undef-fd : director.example.org : allow
109 undef-fd : ALL : deny
113 where director.example.org is the host which will be contacting the client
114 (ie. the box on which the Bacula Director daemon runs). The use of ``ALL :
115 deny'' ensures that the twist option (if present) is not invoked. To properly
116 test your configuration, start the daemon(s), then attempt to connect from an
117 IP address which should be able to connect. You should see something like
123 Trying 192.168.0.56...
124 Connected to undef.example.org.
125 Escape character is '^]'.
126 Connection closed by foreign host.
131 This is the correct response. If you see this:
136 Trying 192.168.0.56...
137 Connected to undef.example.org.
138 Escape character is '^]'.
139 You are not welcome to use undef-sd from xeon.example.org.
140 Connection closed by foreign host.
145 then twist has been invoked and your configuration is not correct and you need
146 to add the deny statement. It is important to note that your testing must
147 include restarting the daemons after each connection attempt. You can also
148 tcpdchk(8) and tcpdmatch(8) to validate your /etc/hosts.allow rules. Here is a
149 simple test using tcpdmatch:
153 $ tcpdmatch undef-dir xeon.example.org
154 warning: undef-dir: no such process name in /etc/inetd.conf
155 client: hostname xeon.example.org
156 client: address 192.168.0.18
157 server: process undef-dir
158 matched: /etc/hosts.allow line 40
164 If you are running Bacula as a standalone daemon, the warning above can be
165 safely ignored. Here is an example which indicates that your rules are missing
166 a deny statement and the twist option has been invoked.
170 $ tcpdmatch undef-dir 10.0.0.1
171 warning: undef-dir: no such process name in /etc/inetd.conf
172 client: address 10.0.0.1
173 server: process undef-dir
174 matched: /etc/hosts.allow line 91
175 option: severity auth.info
176 option: twist /bin/echo "You are not welcome to use
177 undef-dir from 10.0.0.1."
182 \subsection*{Running as non-root}
183 \index[general]{Running as non-root }
184 \addcontentsline{toc}{subsection}{Running as non-root}
186 Security advice from Dan Langille:
188 It is a good idea to run daemons with the lowest possible privileges. In
189 other words, if you can, don't run applications as root which do not have to
190 be root. The Storage Daemon and the Director Daemon do not need to be root.
191 The File Daemon needs to be root in order to access all files on your system.
192 In order to run as non-root, you need to create a user and a group. Choosing
193 {\tt bacula} as both the user name and the group name sounds like a good idea
196 The FreeBSD port creates this user and group for you (actually, as I write
197 this, the port doesn't do that, but it soon will). Here is what those entries
198 looked like on my FreeBSD laptop:
202 bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
206 I used vipw to create this entry. I selected a User ID and Group ID of 1002
207 as they were unused on my system.
209 I also created a group in /etc/group:
217 The bacula user (as opposed to the Bacula daemon) will have a home directory
218 of {\tt /var/db/bacula} which is the default location for the Bacula
221 Now that you have both a bacula user and a bacula group, you can secure the
222 bacula home directory by issuing this command:
226 chown -R bacula:bacula /var/db/bacula/
230 This ensures that only the bacula user can access this directory. It also
231 means that if we run the Director and the Storage daemon as bacula, those
232 daemons also have restricted access. This would not be the case if they were
235 It is important to note that the storage daemon actually needs to be in the
236 operator group for normal access to tape drives etc (at least on a FreeBSD
237 system, that's how things are set up by default) Such devices are normally
238 chown root:operator. It is easier and less error prone to make Bacula a
239 member of that group than it is to play around with system permissions.
241 Starting the Bacula daemons
243 To start the bacula daemons on a FreeBSD system, issue the following command:
247 /usr/local/etc/rc.d/bacula.sh start
251 To confirm they are all running:
255 $ ps auwx | grep bacula
256 root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
257 /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
258 root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
259 /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
260 root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
261 /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf