4 % TODO: this chapter name is confusing ... maybe rename to
5 % TODO: "File Integrity Checking with Bacula"?
6 \chapter{Using Bacula to Improve Computer Security}
8 \index[general]{Security!Using Bacula to Improve Computer }
9 \index[general]{Using Bacula to Improve Computer Security }
11 % TODO: only those two digest algorithms?
12 % TODO: can it use multiple at a time? (record and use both SHA1 and MD5?)
13 Since Bacula maintains a catalog of files, their attributes, and either SHA1
14 or MD5 signatures, it can be an ideal tool for improving computer security.
15 This is done by making a snapshot of your system files with a {\bf Verify} Job
16 and then checking the current state of your system against the snapshot, on a
17 regular basis (e.g. nightly).
19 The first step is to set up a {\bf Verify} Job and to run it with:
27 The {\bf InitCatalog} level tells {\bf Bacula} simply to get the information on
28 the specified files and to put it into the catalog. That is your database is
29 initialized and no comparison is done. The {\bf InitCatalog} is normally run
32 Thereafter, you will run a Verify Job on a daily (or whatever) basis with:
40 The {\bf Level = Catalog} level tells Bacula to compare the current state of
41 the files on the Client to the last {\bf InitCatalog} that is stored in the
42 catalog and to report any differences. See the example below for the format of
45 You decide what files you want to form your "snapshot" by specifying them in
46 a {\bf FileSet} resource, and normally, they will be system files that do not
47 change, or that only certain features change.
49 Then you decide what attributes of each file you want compared by specifying
50 comparison options on the {\bf Include} statements that you use in the {\bf
51 FileSet} resource of your {\bf Catalog} Jobs.
54 \index[general]{Details }
56 In the discussion that follows, we will make reference to the Verify
57 Configuration Example that is included below in the {\bf A Verify
58 Configuration Example} section. You might want to look it over now to get an
61 The main elements consist of adding a schedule, which will normally be run
62 daily, or perhaps more often. This is provided by the {\bf VerifyCycle}
63 Schedule, which runs at 5:05 in the morning every day.
65 Then you must define a Job, much as is done below. We recommend that the Job
66 name contain the name of your machine as well as the word {\bf Verify} or {\bf
67 Check}. In our example, we named it {\bf MatouVerify}. This will permit you to
68 easily identify your job when running it from the Console.
70 You will notice that most records of the Job are quite standard, but that the
71 {\bf FileSet} resource contains {\bf verify=pins1} option in addition to the
72 standard {\bf signature=SHA1} option. If you don't want SHA1 signature
73 comparison, and we cannot imagine why not, you can drop the {\bf
74 signature=SHA1} and none will be computed nor stored in the catalog. Or
75 alternatively, you can use {\bf verify=pins5} and {\bf signature=MD5}, which
76 will use the MD5 hash algorithm. The MD5 hash computes faster than SHA1, but
77 is cryptographically less secure.
79 The {\bf verify=pins1} is ignored during the {\bf InitCatalog} Job, but is
80 used during the subsequent {\bf Catalog} Jobs to specify what attributes of
81 the files should be compared to those found in the catalog. {\bf pins1} is a
82 reasonable set to begin with, but you may want to look at the details of these
83 and other options. They can be found in the
84 \ilink{FileSet Resource}{FileSetResource} section of this manual.
85 Briefly, however, the {\bf p} of the {\bf pins1} tells Verify to compare the
86 permissions bits, the {\bf i} is to compare inodes, the {\bf n} causes
87 comparison of the number of links, the {\bf s} compares the file size, and the
88 {\bf 1} compares the SHA1 checksums (this requires the {\bf signature=SHA1}
89 option to have been set also).
91 You must also specify the {\bf Client} and the {\bf Catalog} resources for
92 your Verify job, but you probably already have them created for your client
93 and do not need to recreate them, they are included in the example below for
96 As mentioned above, you will need to have a {\bf FileSet} resource for the
97 Verify job, which will have the additional {\bf verify=pins1} option. You will
98 want to take some care in defining the list of files to be included in your
99 {\bf FileSet}. Basically, you will want to include all system (or other) files
100 that should not change on your system. If you select files, such as log files
101 or mail files, which are constantly changing, your automatic Verify job will
102 be constantly finding differences. The objective in forming the FileSet is to
103 choose all unchanging important system files. Then if any of those files has
104 changed, you will be notified, and you can determine if it changed because you
105 loaded a new package, or because someone has broken into your computer and
106 modified your files. The example below shows a list of files that I use on my
107 Red Hat 7.3 system. Since I didn't spend a lot of time working on it, it
108 probably is missing a few important files (if you find one, please send it to
109 me). On the other hand, as long as I don't load any new packages, none of
110 these files change during normal operation of the system.
112 \section{Running the Verify}
113 \index[general]{Running the Verify }
114 \index[general]{Verify!Running the }
116 The first thing you will want to do is to run an {\bf InitCatalog} level
117 Verify Job. This will initialize the catalog to contain the file information
118 that will later be used as a basis for comparisons with the actual file
119 system, thus allowing you to detect any changes (and possible intrusions into
122 The easiest way to run the {\bf InitCatalog} is manually with the console
123 program by simply entering {\bf run}. You will be presented with a list of
124 Jobs that can be run, and you will choose the one that corresponds to your
125 Verify Job, {\bf MatouVerify} in this example.
129 The defined Job resources are:
134 Select Job resource (1-4): 1
138 Next, the console program will show you the basic parameters of the Job and
149 OK to run? (yes/mod/no): mod
153 Here, you want to respond {\bf mod} to modify the parameters because the Level
154 is by default set to {\bf Catalog} and we want to run an {\bf InitCatalog}
155 Job. After responding {\bf mod}, the console will ask:
159 Parameters to modify:
165 Select parameter to modify (1-5): 2
169 you should select number 2 to modify the {\bf Level}, and it will display:
174 1: Initialize Catalog
175 2: Verify from Catalog
177 4: Verify Volume Data
178 Select level (1-4): 1
182 Choose item 1, and you will see the final display:
192 OK to run? (yes/mod/no): yes
196 at which point you respond {\bf yes}, and the Job will begin.
198 Thereafter the Job will automatically start according to the schedule you
199 have defined. If you wish to immediately verify it, you can simply run a
200 Verify {\bf Catalog} which will be the default. No differences should be
203 \section{What To Do When Differences Are Found}
204 \index[general]{What To Do When Differences Are Found }
205 \index[general]{Found!What To Do When Differences Are }
207 If you have setup your messages correctly, you should be notified if there are
208 any differences and exactly what they are. For example, below is the email
209 received after doing an update of OpenSSH:
213 HeadMan: Start Verify JobId 83 Job=RufusVerify.2002-06-25.21:41:05
214 HeadMan: Verifying against Init JobId 70 run 2002-06-21 18:58:51
215 HeadMan: File: /etc/pam.d/sshd
216 HeadMan: st_ino differ. Cat: 4674b File: 46765
217 HeadMan: File: /etc/rc.d/init.d/sshd
218 HeadMan: st_ino differ. Cat: 56230 File: 56231
219 HeadMan: File: /etc/ssh/ssh_config
220 HeadMan: st_ino differ. Cat: 81317 File: 8131b
221 HeadMan: st_size differ. Cat: 1202 File: 1297
222 HeadMan: SHA1 differs.
223 HeadMan: File: /etc/ssh/sshd_config
224 HeadMan: st_ino differ. Cat: 81398 File: 81325
225 HeadMan: st_size differ. Cat: 1182 File: 1579
226 HeadMan: SHA1 differs.
227 HeadMan: File: /etc/ssh/ssh_config.rpmnew
228 HeadMan: st_ino differ. Cat: 812dd File: 812b3
229 HeadMan: st_size differ. Cat: 1167 File: 1114
230 HeadMan: SHA1 differs.
231 HeadMan: File: /etc/ssh/sshd_config.rpmnew
232 HeadMan: st_ino differ. Cat: 81397 File: 812dd
233 HeadMan: st_size differ. Cat: 2528 File: 2407
234 HeadMan: SHA1 differs.
235 HeadMan: File: /etc/ssh/moduli
236 HeadMan: st_ino differ. Cat: 812b3 File: 812ab
237 HeadMan: File: /usr/bin/scp
238 HeadMan: st_ino differ. Cat: 5e07e File: 5e343
239 HeadMan: st_size differ. Cat: 26728 File: 26952
240 HeadMan: SHA1 differs.
241 HeadMan: File: /usr/bin/ssh-keygen
242 HeadMan: st_ino differ. Cat: 5df1d File: 5e07e
243 HeadMan: st_size differ. Cat: 80488 File: 84648
244 HeadMan: SHA1 differs.
245 HeadMan: File: /usr/bin/sftp
246 HeadMan: st_ino differ. Cat: 5e2e8 File: 5df1d
247 HeadMan: st_size differ. Cat: 46952 File: 46984
248 HeadMan: SHA1 differs.
249 HeadMan: File: /usr/bin/slogin
250 HeadMan: st_ino differ. Cat: 5e359 File: 5e2e8
251 HeadMan: File: /usr/bin/ssh
252 HeadMan: st_mode differ. Cat: 89ed File: 81ed
253 HeadMan: st_ino differ. Cat: 5e35a File: 5e359
254 HeadMan: st_size differ. Cat: 219932 File: 234440
255 HeadMan: SHA1 differs.
256 HeadMan: File: /usr/bin/ssh-add
257 HeadMan: st_ino differ. Cat: 5e35b File: 5e35a
258 HeadMan: st_size differ. Cat: 76328 File: 81448
259 HeadMan: SHA1 differs.
260 HeadMan: File: /usr/bin/ssh-agent
261 HeadMan: st_ino differ. Cat: 5e35c File: 5e35b
262 HeadMan: st_size differ. Cat: 43208 File: 47368
263 HeadMan: SHA1 differs.
264 HeadMan: File: /usr/bin/ssh-keyscan
265 HeadMan: st_ino differ. Cat: 5e35d File: 5e96a
266 HeadMan: st_size differ. Cat: 139272 File: 151560
267 HeadMan: SHA1 differs.
268 HeadMan: 25-Jun-2002 21:41
270 Job: RufusVerify.2002-06-25.21:41:05
272 Verify Level: Catalog
274 Start time: 25-Jun-2002 21:41
275 End time: 25-Jun-2002 21:41
276 Files Examined: 4,258
277 Termination: Verify Differences
281 At this point, it was obvious that these files were modified during
282 installation of the RPMs. If you want to be super safe, you should run a {\bf
283 Verify Level=Catalog} immediately before installing new software to verify
284 that there are no differences, then run a {\bf Verify Level=InitCatalog}
285 immediately after the installation.
287 To keep the above email from being sent every night when the Verify Job runs,
288 we simply re-run the Verify Job setting the level to {\bf InitCatalog} (as we
289 did above in the very beginning). This will re-establish the current state of
290 the system as your new basis for future comparisons. Take care that you don't
291 do an {\bf InitCatalog} after someone has placed a Trojan horse on your
294 If you have included in your {\bf FileSet} a file that is changed by the
295 normal operation of your system, you will get false matches, and you will need
296 to modify the {\bf FileSet} to exclude that file (or not to Include it), and
297 then re-run the {\bf InitCatalog}.
299 The FileSet that is shown below is what I use on my Red Hat 7.3 system. With a
300 bit more thought, you can probably add quite a number of additional files that
303 \section{A Verify Configuration Example}
304 \index[general]{Verify Configuration Example }
305 \index[general]{Example!Verify Configuration }
311 Run = Level=Catalog sun-sat at 5:05
316 Level = Catalog # default level
318 FileSet = "Verify Set"
322 Schedule = "VerifyCycle"
325 # The list of files in this FileSet should be carefully
326 # chosen. This is a good starting point.
341 File = /home/kern/.ssh
343 File = /etc/sysconfig
347 File = /etc/rc.d/init.d
348 File = /etc/sendmail.cf
349 File = /etc/sysctl.conf
352 File = /etc/hosts.allow
353 File = /etc/hosts.deny
355 File = /etc/modules.conf
356 File = /etc/named.conf
358 File = /etc/resolv.conf
367 File Retention = 80d # 80 days
368 Job Retention = 1y # one year
369 AutoPrune = yes # Prune expired Jobs/Files
373 dbname = verify; user = bacula; password = ""