]> git.sur5r.net Git - bacula/docs/blob - docs/manual/security.tex
fix some doc bugs
[bacula/docs] / docs / manual / security.tex
1 %%
2 %%
3
4 \section*{Bacula Security Issues}
5 \label{_ChapterStart14}
6 \index[general]{Bacula Security Issues}
7 \index[general]{Security}
8 \index[general]{Issues!Bacula Security}
9 \addcontentsline{toc}{section}{Bacula Security Issues}
10
11 \begin{itemize}
12 \item Security means being able to restore your files, so read the 
13    \ilink{Critical Items Chapter}{Critical} of this manual.
14 \item The Clients ({\bf bacula-fd}) must run as root to be able to access  all
15    the system files. 
16 \item It is not necessary to run the Director as root. 
17 \item It is not necessary to run the Storage daemon as root, but you  must
18    ensure that it can open the tape drives, which are often restricted to root
19    access by default. In addition, if you do not run the Storage daemon as root,
20    it will not be able to automatically set your tape drive parameters on most
21    OSes since these functions, unfortunately require root access.
22 \item You should restrict access to the Bacula configuration files,  so that
23    the passwords are not world-readable. The {\bf Bacula}  daemons are password
24    protected using CRAM-MD5 (i.e. the password is not  sent across the network).
25    This will ensure that not everyone  can access the daemons. It is a reasonably
26    good protection, but  can be cracked by experts. 
27 \item If you are using the recommended ports 9101, 9102, and 9103, you  will
28    probably want to protect these ports from external access  using a firewall
29    and/or using tcp wrappers ({\bf etc/hosts.allow}).  
30 \item Currently all data that is sent across the network is unencrypted.  As a
31    consequence, unless you use {\bf ssh} or {\bf stunnel} for  port forwarding,
32    it is not recommended to do a backup across an  insecure network (e.g. the
33    Internet). In a future version, we plan  to have {\bf ssl} encryption
34    built-in. 
35 \item You should ensure that the Bacula working directories are  readable and
36    writable only by the Bacula daemons. 
37 \item If you are using {\bf MySQL} it is not necessary for it to  run with
38    {\bf root} permission. 
39 \item The default Bacula {\bf grant-mysql-permissions} script  grants all
40    permissions to use the MySQL database without a  password. If you want
41    security, please tighten this up! 
42 \item Don't forget that Bacula is a network program, so anyone anywhere  on
43    the network with the console program and the Director's password  can access
44    Bacula and the backed up data. 
45 \item You can restrict what IP addresses Bacula will bind to by using the 
46    appropriate {\bf DirAddress}, {\bf FDAddress}, or {\bf SDAddress}  records in
47    the respective daemon configuration files. 
48 \item Be aware that if you are backing up your database using the default
49    script, if you have a password on your database, it will be passed as
50    a command line option to that script, and any user will be able to see
51    this information. If you want it to be secure, you will need to pass it
52    by an environment variable or a secure file.
53 \end{itemize}
54
55
56 \subsection*{Backward Compatibility}
57 \index[general]{Backward Compatibility}
58 \addcontentsline{toc}{subsection}{Backward Compatibility}
59 One of the major goals of Bacula is to ensure that you can restore
60 tapes (I'll use the word tape to include disk Volumes) that you wrote years
61 ago.  This means that each new version of Bacula should be able to read old
62 format tapes. The first problem you will have is to ensure that the 
63 hardware is still working some years down the road, and the second
64 problem will be to ensure that the media will still be good, then 
65 your OS must be able to interface to the device, and finally Bacula
66 must be able to recogize old formats.  All the problems except the
67 last are ones that we cannot solve, but by careful planning you can.
68
69 Since the very beginning of Bacula (January 2000) until today (December
70 2005), there have been two major Bacula tape formats.  The second format
71 was introduced in version 1.27 in November of 2002, and it has not
72 changed since then.  In principle, Bacula can still read the original
73 format, but I haven't tried it lately so who knows ...
74
75 Though the tape format is fixed, the kinds of data that we can put on the
76 tapes are extensible, and that is how we added new features
77 such as ACLs, Win32 data, encrypted data, ...  Obviously, an older
78 version of Bacula would not know how to read these newer data streams,
79 but each newer version of Bacula should know how to read all the 
80 older streams.
81
82 If you want to be 100% sure that you can read old tapes, you
83 should:
84
85 1. Try reading old tapes from time to time -- e.g. at least once
86 a year.
87
88 2. Keep statically linked copies of every version of Bacula that you use
89 in production then if for some reason, we botch up old tape compatibility, you
90 can always pull out an old copy of Bacula ...
91
92 The second point is probably overkill but if you want to be sure, it may
93 save you someday.
94
95
96
97 \label{wrappers}
98 \subsection*{Configuring and Testing TCP Wrappers}
99 \index[general]{Configuring and Testing TCP Wrappers}
100 \index[general]{TCP Wrappers}
101 \index[general]{Wrappers!TCP}
102 \index[general]{libwrappers}
103 \addcontentsline{toc}{subsection}{Configuring and Testing TCP Wrappers}
104
105 TCP Wrappers are implemented if you turn them on when configuring
106 ({\bf ./configure \verb:--:with-tcp-wrappers}). 
107 With this code enabled, you may control who may access your
108 daemons.  This control is done by modifying the file: {\bf
109 /etc/hosts.allow}.  The program name that {\bf Bacula} uses when
110 applying these access restrictions is the name you specify in the
111 daemon configuration file (see below for examples).
112 You must not use the {\bf twist} option in your {\bf
113 /etc/hosts.allow} or it will terminate the Bacula daemon when a
114 connection is refused.
115
116 Dan Langille has provided the following information on configuring and
117 testing TCP wrappers with Bacula. 
118
119 If you read hosts\_options(5), you will see an option called twist. This
120 option replaces the current process by an instance of the specified shell
121 command. Typically, something like this is used: 
122
123 \footnotesize
124 \begin{verbatim}
125 ALL : ALL \
126  : severity auth.info \
127  : twist /bin/echo "You are not welcome to use %d from %h."
128 \end{verbatim}
129 \normalsize
130
131 The libwrap code tries to avoid {\bf twist} if it runs in a resident process,
132 but that test will not protect the first hosts\_access() call. This will
133 result in the process (e.g. bacula-fd, bacula-sd, bacula-dir) being terminated
134 if the first connection to their port results in the twist option being
135 invoked. The potential, and I strees potential, exists for an attacker to
136 prevent the daemons from running. This situation is eliminated if your
137 /etc/hosts.allow file contains an appropriate ruleset. The following example
138 is sufficent: 
139
140 \footnotesize
141 \begin{verbatim}
142 undef-fd : localhost : allow
143 undef-sd : localhost : allow
144 undef-dir : localhost : allow
145 undef-fd : ALL : deny
146 undef-sd : ALL : deny
147 undef-dir : ALL : deny
148 \end{verbatim}
149 \normalsize
150
151 You must adjust the names to be the same as the Name directives found
152 in each of the daemon configuration files. They are, in general, notthe
153 same as the binary daemon names. It is not possible to use the 
154 daemon names because multiple daemons may be running on the same machine
155 but with different configurations.
156
157 In these examples, the Director is undef-dir, the
158 Storage Daemon is undef-sd, and the File Daemon is undef-fd. Adjust to suit
159 your situation. The above example rules assume that the SD, FD, and DIR all
160 reside on the same box. If you have a remote FD client, then the following
161 ruleset on the remote client will suffice: 
162
163 \footnotesize
164 \begin{verbatim}
165 undef-fd : director.example.org : allow
166 undef-fd : ALL : deny
167 \end{verbatim}
168 \normalsize
169
170 where director.example.org is the host which will be contacting the client
171 (ie. the box on which the Bacula Director daemon runs). The use of "ALL :
172 deny" ensures that the twist option (if present) is not invoked. To properly
173 test your configuration, start the daemon(s), then attempt to connect from an
174 IP address which should be able to connect. You should see something like
175 this: 
176
177 \footnotesize
178 \begin{verbatim}
179 $ telnet undef 9103
180 Trying 192.168.0.56...
181 Connected to undef.example.org.
182 Escape character is '^]'.
183 Connection closed by foreign host.
184 $
185 \end{verbatim}
186 \normalsize
187
188 This is the correct response. If you see this: 
189
190 \footnotesize
191 \begin{verbatim}
192 $ telnet undef 9103
193 Trying 192.168.0.56...
194 Connected to undef.example.org.
195 Escape character is '^]'.
196 You are not welcome to use undef-sd from xeon.example.org.
197 Connection closed by foreign host.
198 $
199 \end{verbatim}
200 \normalsize
201
202 then twist has been invoked and your configuration is not correct and you need
203 to add the deny statement. It is important to note that your testing must
204 include restarting the daemons after each connection attempt. You can also
205 tcpdchk(8) and tcpdmatch(8) to validate your /etc/hosts.allow rules. Here is a
206 simple test using tcpdmatch: 
207
208 \footnotesize
209 \begin{verbatim}
210 $ tcpdmatch undef-dir xeon.example.org
211 warning: undef-dir: no such process name in /etc/inetd.conf
212 client: hostname xeon.example.org
213 client: address 192.168.0.18
214 server: process undef-dir
215 matched: /etc/hosts.allow line 40
216 option: allow
217 access: granted
218 \end{verbatim}
219 \normalsize
220
221 If you are running Bacula as a standalone daemon, the warning above can be
222 safely ignored. Here is an example which indicates that your rules are missing
223 a deny statement and the twist option has been invoked. 
224
225 \footnotesize
226 \begin{verbatim}
227 $ tcpdmatch undef-dir 10.0.0.1
228 warning: undef-dir: no such process name in /etc/inetd.conf
229 client: address 10.0.0.1
230 server: process undef-dir
231 matched: /etc/hosts.allow line 91
232 option: severity auth.info
233 option: twist /bin/echo "You are not welcome to use
234   undef-dir from 10.0.0.1."
235 access: delegated
236 \end{verbatim}
237 \normalsize
238
239 \subsection*{Running as non-root}
240 \index[general]{Running as non-root }
241 \addcontentsline{toc}{subsection}{Running as non-root}
242
243 Security advice from Dan Langille: 
244
245 It is a good idea to run daemons with the lowest possible privileges.  In
246 other words, if you can, don't run applications as root which do  not have to
247 be root.  The Storage Daemon and the Director Daemon do not need to be root.
248 The  File Daemon needs to be root in order to access all files on your system.
249 In order to run as non-root, you need to create a user and a group.  Choosing
250 {\tt bacula} as both the user name and the group name sounds like a good idea
251 to me.  
252
253 The FreeBSD port creates this user and group for you (actually, as I  write
254 this, the port doesn't do that, but it soon will). Here is what those  entries
255 looked like on my FreeBSD laptop: 
256
257 \footnotesize
258 \begin{verbatim}
259 bacula:*:1002:1002::0:0:Bacul Daemon:/var/db/bacula:/sbin/nologin
260 \end{verbatim}
261 \normalsize
262
263 I used vipw to create this entry. I selected a User ID and Group ID  of 1002
264 as they were unused on my system.  
265
266 I also created a group in /etc/group:  
267
268 \footnotesize
269 \begin{verbatim}
270 bacula:*:1002:
271 \end{verbatim}
272 \normalsize
273
274 The bacula user (as opposed to the Bacula daemon) will have a home  directory
275 of {\tt /var/db/bacula} which is the  default location for the Bacula
276 database.  
277
278 Now that you have both a bacula user and a bacula group, you can  secure the
279 bacula home directory by issuing this command: 
280
281 \footnotesize
282 \begin{verbatim}
283 chown -R bacula:bacula /var/db/bacula/
284 \end{verbatim}
285 \normalsize
286
287 This ensures that only the bacula user can access this directory.  It also
288 means that if we run the Director and the Storage daemon  as bacula, those
289 daemons also have restricted access. This would not be  the case if they were
290 running as root.  
291
292 It is important to note that the storage daemon actually needs  to be in the
293 operator group for normal access to tape drives etc (at  least on a FreeBSD
294 system, that's how things are set up by default)  Such devices are normally
295 chown root:operator. It is easier and less  error prone  to make Bacula a
296 member of that group than it is to play around  with system permissions. 
297
298 Starting the Bacula daemons 
299
300 To start the bacula daemons on a FreeBSD system, issue the following command: 
301
302 \footnotesize
303 \begin{verbatim}
304 /usr/local/etc/rc.d/bacula.sh start
305 \end{verbatim}
306 \normalsize
307
308 To confirm they are all running: 
309
310 \footnotesize
311 \begin{verbatim}
312 $ ps auwx | grep bacula
313 root\ 63416\ 0.0\ 0.3\ 2040 1172\ ??\ Ss\ 4:09PM 0:00.01
314     /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf
315 root\ 63418\ 0.0\ 0.3\ 1856 1036\ ??\ Ss\ 4:09PM 0:00.00
316     /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf
317 root\ 63422\ 0.0\ 0.4\ 2360 1440\ ??\ Ss\ 4:09PM 0:00.00
318     /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf
319 \end{verbatim}
320 \normalsize