
#include "bacula_template.inc" title="Using Bacula to Improve Computer Security" num=21

<h1>Using Bacula to Improve Computer Security</h1>
Since Bacula maintains a catalog of files, their attributes, and
either SHA1 or MD5 signatures, it can be an ideal tool for improving
computer security.  This is done by making a snapshot of your system
files with a <b>Verify</b> Job and then checking the current state of
your system against the snapshot, on a regular basis (e.g.  nightly).

<p>
The first step is to set up a <b>Verify</b> Job and to run it with:
<pre>Level = InitCatalog</pre>
The <b>InitCatalog</b> level tells <b>Bacula</b>
simply get the information on the specified files and to put it into
the catalog. That is your database is initialized and no comparison
is done. The <b>InitCatalog</b> is normally run one time manually. 
<p>Thereafter,
you will run a Verify Job on a daily (or whatever) basis with:
<pre>Level = Catalog
</pre>
The <b>Level = Catalog</b> level tells Bacula to compare
the current state of the files on the Client to the last <b>InitCatalog</b>
that is stored in the catalog and to report any differences. See the
example below for the format of the output.
<p>
You decide what files you want to form your &quot;snapshot&quot;
by specifying them  in a <b>FileSet</b> resource,
and normally, they will be system files that do not change, or that
only certain features change.
<p>
Then you decide what attributes of each file you want compared
by specifying comparison options on the <b>Include</b> statements
that you use in the <b>FileSet</b> resource of your <b>Catalog</b> Jobs.
<h2>The Details</h2>
In the discussion that follows, we will make reference to the 
Verify Configuration Example that is included below in the
<b>A Verify Configuration Example</b> section. 
You might want to look it over now to get an idea of
what it does.
<p>
The main elements consist of adding a schedule, which will normally
be run daily, or perhaps more often. This is provided by the
<b>VerifyCycle</b> Schedule, which runs at 5:05 in the morning
every day.
<p>
Then you must define a Job, much as is done below. We
recommend that the Job name contain the name of your machine
as well as the word <b>Verify</b> or <b>Check</b>. In our
example, we named it <b>MatouVerify</b>. This will
permit you to easily identify your job when running it from
the Console.
<p>
You will notice that most records of the Job are quite
standard, but that the <b>FileSet</b> resource contains
<b>verify=pins1</b> option in addition to the standard
<b>signature=SHA1</b> option.
If you don't want SHA1 signature comparison, and we
cannot imagine why not, you can drop the <b>signature=SHA1</b>
and none will be computed nor stored in the catalog. Or alternatively,
you can use <b>verify=pins5</b> and <b>signature=MD5</b>, which
will use the MD5 hash algorithm.  The MD5 hash computes faster
than SHA1, but is cryptographically less secure.

<p>
The <b>verify=pins1</b> is ignored during the <b>InitCatalog</b>
Job, but is used during the subsequent <b>Catalog</b> Jobs
to specify what attributes of the files should be compared to those
found in the catalog.  <b>pins1</b> is a reasonable set to
begin with, but you may want to look at the
details these and other options. They can be found in the
<a href="dirdconf.html#FileSetResource">FileSet Resource</a>
section of this manual. Briefly, however, the <b>p</b> of 
the <b>pins1</b> tells Verify to compare the permissions
bits, the <b>i</b> is to compare inodes, the <b>n</b> causes
comparison of the number of links, the <b>s</b> compares
the file size, and the <b>1</b> compares the SHA1 checksums
(this requires the <b>signature=SHA1</b> option to have
been set also).
<p>
You must also specify the <b>Client</b> and the <b>Catalog</b> resources
for your Verify job, 
but you probably already have them created for your client
and do not need to recreate them, they are included in
the example below for completeness. 

<p>As mentioned above, you will need to have a <b>FileSet</b> resource
for the Verify job, which will have the additional <b>verify=pins1</b>
option. You will want to take some care in defining the list of
files to be included in your <b>FileSet</b>. Basically, you will 
want to include all system (or other) files that should not change
on your system. If you select files, such as log files or mail files,
which are constantly changing, your automatic Verify job will be
constantly finding differences.  The objective in forming the FileSet
is to choose all unchanging important system files. Then if any of
those files has changed, you will be notified, and you can determine
if it changed because you loaded a new package, or because someone
has broken into your computer and modified your files.  The example
below shows a list of files that I use on my RedHat 7.3 system. Since
I didn't spend a lot of time working on it, it probably is missing
a few important files (if you find one, please send it to me). On the
other hand, as long as I don't load any new packages, none of
these files change during normal operation of the system.




<h2>Running the Verify</h2>
The first thing you will want to do is to 
run an <b>InitCatalog</b> level Verify Job.
This will initialize the catalog to contain the
file information that will later be used as a basis
for comparisons with the actual file system, thus allowing you to
detect any changes (and possible intrusions into
your system). 
<p> 
The easiest way to run the <b>InitCatalog</b>
is manually with the console program by simply
entering <b>run</b>. You will be presented with
a list of Jobs that can be run, and you will choose
the one that corresponds to your Verify Job, <b>MatouVerify</b>
in this example. 
<pre>
The defined Job resources are:
     1: MatouVerify
     2: kernsrestore
     3: Filetest
     4: kernsave
Select Job resource (1-4): 1
</pre>

Next, the console program will show you
the basic parameters of the Job and ask you:
<pre>
Run Verify job
JobName:  MatouVerify
FileSet:  Verify Set
Level:    Catalog
Client:   MatouVerify
Storage:  DLTDrive
OK to run? (yes/mod/no): mod
</pre>
Here, you want to respond <b>mod</b> to modify
the parameters because the Level is by default
set to <b>Catalog</b> and we want to run an
<b>InitCatalog</b> Job.  After responding
<b>mod</b>, the console will ask:
<pre>
Parameters to modify:
     1: Job
     2: Level
     3: FileSet
     4: Client
     5: Storage
Select parameter to modify (1-5): 2
</pre>
you should select number 2 to modify the <b>Level</b>,
and it will display:
<pre>
Levels:
     1: Initialize Catalog
     2: Verify from Catalog
     3: Verify Volume
     4: Verify Volume Data
Select level (1-4): 1
</pre>
Choose item 1, and you will see the final display:
<pre>
Run Verify job
JobName:  MatouVerify
FileSet:  Verify Set
Level:    Initcatalog
Client:   MatouVerify
Storage:  DLTDrive
OK to run? (yes/mod/no): yes
</pre>
at which point you respond <b>yes</b>, and the Job will begin.
<p>
There after the Job will automatically start according to the
schedule you have defined. If you wish to immediately verify
it, you can simply run a Verify <b>Catalog</b> which will
be the default. No differences should be found.

<h2>What To Do When Differences Are Found</h2>
If you have setup your messages correctly, you should be notified
if there are any differences and exactly what they are.  
For example, below is the email received after doing
an update of OpenSSH:
<pre>
HeadMan: Start Verify JobId 83 Job=RufusVerify.2002-06-25.21:41:05
HeadMan: Verifying against Init JobId 70 run 2002-06-21 18:58:51
HeadMan: File: /etc/pam.d/sshd
HeadMan:       st_ino   differ. Cat: 4674b File: 46765
HeadMan: File: /etc/rc.d/init.d/sshd
HeadMan:       st_ino   differ. Cat: 56230 File: 56231
HeadMan: File: /etc/ssh/ssh_config
HeadMan:       st_ino   differ. Cat: 81317 File: 8131b
HeadMan:       st_size  differ. Cat: 1202 File: 1297
HeadMan:       SHA1 differs.
HeadMan: File: /etc/ssh/sshd_config
HeadMan:       st_ino   differ. Cat: 81398 File: 81325
HeadMan:       st_size  differ. Cat: 1182 File: 1579
HeadMan:       SHA1 differs.
HeadMan: File: /etc/ssh/ssh_config.rpmnew
HeadMan:       st_ino   differ. Cat: 812dd File: 812b3
HeadMan:       st_size  differ. Cat: 1167 File: 1114
HeadMan:       SHA1 differs.
HeadMan: File: /etc/ssh/sshd_config.rpmnew
HeadMan:       st_ino   differ. Cat: 81397 File: 812dd
HeadMan:       st_size  differ. Cat: 2528 File: 2407
HeadMan:       SHA1 differs.
HeadMan: File: /etc/ssh/moduli
HeadMan:       st_ino   differ. Cat: 812b3 File: 812ab
HeadMan: File: /usr/bin/scp
HeadMan:       st_ino   differ. Cat: 5e07e File: 5e343
HeadMan:       st_size  differ. Cat: 26728 File: 26952
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/ssh-keygen
HeadMan:       st_ino   differ. Cat: 5df1d File: 5e07e
HeadMan:       st_size  differ. Cat: 80488 File: 84648
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/sftp
HeadMan:       st_ino   differ. Cat: 5e2e8 File: 5df1d
HeadMan:       st_size  differ. Cat: 46952 File: 46984
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/slogin
HeadMan:       st_ino   differ. Cat: 5e359 File: 5e2e8
HeadMan: File: /usr/bin/ssh
HeadMan:       st_mode  differ. Cat: 89ed File: 81ed
HeadMan:       st_ino   differ. Cat: 5e35a File: 5e359
HeadMan:       st_size  differ. Cat: 219932 File: 234440
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/ssh-add
HeadMan:       st_ino   differ. Cat: 5e35b File: 5e35a
HeadMan:       st_size  differ. Cat: 76328 File: 81448
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/ssh-agent
HeadMan:       st_ino   differ. Cat: 5e35c File: 5e35b
HeadMan:       st_size  differ. Cat: 43208 File: 47368
HeadMan:       SHA1 differs.
HeadMan: File: /usr/bin/ssh-keyscan
HeadMan:       st_ino   differ. Cat: 5e35d File: 5e96a
HeadMan:       st_size  differ. Cat: 139272 File: 151560
HeadMan:       SHA1 differs.
HeadMan: 25-Jun-2002 21:41
JobId:                  83
Job:                    RufusVerify.2002-06-25.21:41:05
FileSet:                Verify Set
Verify Level:           Catalog
Client:                 RufusVerify
Start time:             25-Jun-2002 21:41
End time:               25-Jun-2002 21:41
Files Examined:         4,258
Termination:            Verify Differences
</pre>

At this point, it was obvious that these files were modified
during installation of the RPMs. If you want to be super safe,
you should run a <b>Verify Level=Catalog</b> immediately before
installing new software to verify that there are no differences,
then run a <b>Verify Level=InitCatalog</b> immediately after
the installation.

<p>To keep the above email from being sent every night when
the Verify Job runs, we simply re-run the Verify Job setting
the level to <b>InitCatalog</b> (as we did above in the very
beginning). This will re-establish the current state of the
system as your new basis for future comparisons. Take care
that you don't do an <b>InitCatalog</b> after someone has
placed a Trojan horse on your system!

<p>If you have included in your <b>FileSet</b> a file that is
changed by the normal operation of your system, you will get 
false matches, and you will need to modify the <b>FileSet</b>
to exclude that file (or not to Include it), and then re-run
the <b>InitCatalog</b>.

<p>The FileSet that is show below is what I use on
my RedHat 7.3 system. With a bit more thought, you can probably
add quite a number of additional files that should be monitored.

<h2>A Verify Configuration Example</h2>
<pre>
Schedule {
  Name = "VerifyCycle"
  Run = Level=Catalog sun-sat at 5:05
}

Job {
  Name = "MatouVerify"
  Type = Verify
  Level = Catalog                     # default level
  Client = MatouVerify 
  FileSet = "Verify Set"
  Messages = Standard
  Storage = DLTDrive
  Pool = Default
  Schedule = "VerifyCycle"
}
\#
\# The list of files in this FileSet should be carefully
\# chosen. This is a good starting point.
\#
FileSet {
  Name = "Verify Set"
  Include = verify=pins1 signature=SHA1 { 
     /boot
     /bin
     /sbin
     /usr/bin
     /lib
     /root/.ssh
     /home/kern/.ssh
     /var/named
     /etc/sysconfig
     /etc/ssh
     /etc/security
     /etc/exports
     /etc/rc.d/init.d
     /etc/sendmail.cf
     /etc/sysctl.conf
     /etc/services
     /etc/xinetd.d
     /etc/hosts.allow
     /etc/hosts.deny
     /etc/hosts
     /etc/modules.conf
     /etc/named.conf
     /etc/pam.d
     /etc/resolv.conf
  }
  Exclude = { }
}

Client {
  Name = MatouVerify
  Address = lmatou
  Catalog = Bacula
  Password = ""
  File Retention = 80d                # 80 days
  Job Retention = 1y                  # one year
  AutoPrune = yes                     # Prune expired Jobs/Files
}

Catalog {
  Name = Bacula
  dbname = verify; user = bacula; password = ""
}

</pre>
                 
                        
<page_prev name="Using stunnel to Encrypt Communications to Clients" url="stunnel.html">
<page_next name="The Bootstrap File" url="bootstrap.html">
