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