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 {\bf Verify} Job
and then checking the current state of your system against the snapshot, on a
-regular basis (e.g. nightly).
+regular basis (e.g. nightly).
-The first step is to set up a {\bf Verify} Job and to run it with:
+The first step is to set up a {\bf Verify} Job and to run it with:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Level = InitCatalog
-\end{verbatim}
+\end{lstlisting}
\normalsize
The {\bf InitCatalog} level tells {\bf Bacula} simply to 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 {\bf InitCatalog} is normally run
-one time manually.
+one time manually.
-Thereafter, you will run a Verify Job on a daily (or whatever) basis with:
+Thereafter, you will run a Verify Job on a daily (or whatever) basis with:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Level = Catalog
-\end{verbatim}
+\end{lstlisting}
\normalsize
The {\bf Level = Catalog} level tells Bacula to compare the current state of
the files on the Client to the last {\bf InitCatalog} that is stored in the
catalog and to report any differences. See the example below for the format of
-the output.
+the output.
You decide what files you want to form your "snapshot" by specifying them in
a {\bf FileSet} resource, and normally, they will be system files that do not
-change, or that only certain features change.
+change, or that only certain features change.
Then you decide what attributes of each file you want compared by specifying
comparison options on the {\bf Include} statements that you use in the {\bf
-FileSet} resource of your {\bf Catalog} Jobs.
+FileSet} resource of your {\bf Catalog} Jobs.
\section{The Details}
\index[general]{Details }
In the discussion that follows, we will make reference to the Verify
Configuration Example that is included below in the {\bf A Verify
Configuration Example} section. You might want to look it over now to get an
-idea of what it does.
+idea of what it does.
The main elements consist of adding a schedule, which will normally be run
daily, or perhaps more often. This is provided by the {\bf VerifyCycle}
-Schedule, which runs at 5:05 in the morning every day.
+Schedule, which runs at 5:05 in the morning every day.
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 {\bf Verify} or {\bf
Check}. In our example, we named it {\bf MatouVerify}. This will permit you to
-easily identify your job when running it from the Console.
+easily identify your job when running it from the Console.
You will notice that most records of the Job are quite standard, but that the
{\bf FileSet} resource contains {\bf verify=pins1} option in addition to the
signature=SHA1} and none will be computed nor stored in the catalog. Or
alternatively, you can use {\bf verify=pins5} and {\bf signature=MD5}, which
will use the MD5 hash algorithm. The MD5 hash computes faster than SHA1, but
-is cryptographically less secure.
+is cryptographically less secure.
The {\bf verify=pins1} is ignored during the {\bf InitCatalog} Job, but is
used during the subsequent {\bf Catalog} Jobs to specify what attributes of
the files should be compared to those found in the catalog. {\bf pins1} is a
reasonable set to begin with, but you may want to look at the details of these
-and other options. They can be found in the
+and other options. They can be found in the
\ilink{FileSet Resource}{FileSetResource} section of this manual.
Briefly, however, the {\bf p} of the {\bf pins1} tells Verify to compare the
permissions bits, the {\bf i} is to compare inodes, the {\bf n} causes
comparison of the number of links, the {\bf s} compares the file size, and the
{\bf 1} compares the SHA1 checksums (this requires the {\bf signature=SHA1}
-option to have been set also).
+option to have been set also).
You must also specify the {\bf Client} and the {\bf Catalog} 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.
+completeness.
As mentioned above, you will need to have a {\bf FileSet} resource for the
Verify job, which will have the additional {\bf verify=pins1} option. You will
Red Hat 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.
+these files change during normal operation of the system.
\section{Running the Verify}
\index[general]{Running the Verify }
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).
+your system).
The easiest way to run the {\bf InitCatalog} is manually with the console
program by simply entering {\bf run}. 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, {\bf MatouVerify} in this example.
+Verify Job, {\bf MatouVerify} in this example.
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
The defined Job resources are:
1: MatouVerify
2: kernsrestore
3: Filetest
4: kernsave
Select Job resource (1-4): 1
-\end{verbatim}
+\end{lstlisting}
\normalsize
Next, the console program will show you the basic parameters of the Job and
-ask you:
+ask you:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Run Verify job
JobName: MatouVerify
FileSet: Verify Set
Level: Catalog
Client: MatouVerify
Storage: DLTDrive
+Verify Job:
+Verify List: /tmp/regress/working/MatouVerify.bsr
OK to run? (yes/mod/no): mod
-\end{verbatim}
+\end{lstlisting}
\normalsize
Here, you want to respond {\bf mod} to modify the parameters because the Level
is by default set to {\bf Catalog} and we want to run an {\bf InitCatalog}
-Job. After responding {\bf mod}, the console will ask:
+Job. After responding {\bf mod}, the console will ask:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Parameters to modify:
- 1: Job
- 2: Level
- 3: FileSet
- 4: Client
- 5: Storage
-Select parameter to modify (1-5): 2
-\end{verbatim}
+ 1: Level
+ 2: Storage
+ 3: Job
+ 4: FileSet
+ 5: Client
+ 6: When
+ 7: Priority
+ 8: Pool
+ 9: Verify Job
+Select parameter to modify (1-5): 1
+\end{lstlisting}
\normalsize
-you should select number 2 to modify the {\bf Level}, and it will display:
+you should select number 2 to modify the {\bf Level}, and it will display:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Levels:
1: Initialize Catalog
- 2: Verify from Catalog
- 3: Verify Volume
- 4: Verify Volume Data
+ 2: Verify Catalog
+ 3: Verify Volume to Catalog
+ 4: Verify Disk to Catalog
+ 5: Verify Volume Data (not yet implemented)
Select level (1-4): 1
-\end{verbatim}
+\end{lstlisting}
\normalsize
-Choose item 1, and you will see the final display:
+Choose item 1, and you will see the final display:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Run Verify job
JobName: MatouVerify
FileSet: Verify Set
Level: Initcatalog
Client: MatouVerify
Storage: DLTDrive
+Verify Job:
+Verify List: /tmp/regress/working/MatouVerify.bsr
OK to run? (yes/mod/no): yes
-\end{verbatim}
+\end{lstlisting}
\normalsize
-at which point you respond {\bf yes}, and the Job will begin.
+at which point you respond {\bf yes}, and the Job will begin.
Thereafter 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 {\bf Catalog} which will be the default. No differences should be
-found.
+found.
+
+To use a previous job, you can add \texttt{jobid=xxx} option in run command
+line. It will run the Verify job against the specified job.
+
+\begin{lstlisting}
+*run jobid=1 job=MatouVerify
+Run Verify job
+JobName: MatouVerify
+Level: Catalog
+Client: 127.0.0.1-fd
+FileSet: Full Set
+Pool: Default (From Job resource)
+Storage: File (From Job resource)
+Verify Job: MatouVerify.2010-09-08_15.33.33_03
+Verify List: /tmp/regress/working/MatouVerify.bsr
+When: 2010-09-08 15:35:32
+Priority: 10
+OK to run? (yes/mod/no):
+\end{lstlisting}
\section{What To Do When Differences Are Found}
\index[general]{What To Do When Differences Are Found }
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:
+received after doing an update of OpenSSH:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
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
End time: 25-Jun-2002 21:41
Files Examined: 4,258
Termination: Verify Differences
-\end{verbatim}
+\end{lstlisting}
\normalsize
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 {\bf
Verify Level=Catalog} immediately before installing new software to verify
that there are no differences, then run a {\bf Verify Level=InitCatalog}
-immediately after the installation.
+immediately after the installation.
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 {\bf InitCatalog} (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 {\bf InitCatalog} after someone has placed a Trojan horse on your
-system!
+system!
If you have included in your {\bf FileSet} a file that is changed by the
normal operation of your system, you will get false matches, and you will need
to modify the {\bf FileSet} to exclude that file (or not to Include it), and
-then re-run the {\bf InitCatalog}.
+then re-run the {\bf InitCatalog}.
The FileSet that is shown below is what I use on my Red Hat 7.3 system. With a
bit more thought, you can probably add quite a number of additional files that
-should be monitored.
+should be monitored.
\section{A Verify Configuration Example}
\index[general]{Verify Configuration Example }
\index[general]{Example!Verify Configuration }
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Schedule {
Name = "VerifyCycle"
Run = Level=Catalog sun-sat at 5:05
Name = Bacula
dbname = verify; user = bacula; password = ""
}
-\end{verbatim}
+\end{lstlisting}
\normalsize
projects / bacula / docs / blobdiff