Sentinel File System Integrity Checker

Overview:

The Sentinel "suite" (sorry--I just think that sounds terribly pretentious :) currently consists of five bash scripts (InitSentineldb.sh, CheckSentineldb.sh, traverse.sh and KillSentinel.sh and Sentinel.sh), one perl script (MailSentinelViolations.pl), three config files (agent.conf, agent.includes and agent.excludes) and one md5sum flat file database (db.txt).

InitSentineldb.sh:

• InitSentineldb.sh takes an md5sum "snapshot" of the files specified in the configuration file. The time it takes to run varies on the size of your filesystem and the speed of your hard drives.

CheckSentineldb.sh:

• CheckSentineldb.sh calculates an md5sum on the specified files in your file system and compares the sum with the archived md5sums. CheckSentineldb.sh takes a little longer to run than InitSentineldb.sh and can drive the load on a 1GHz PIII to 6 or 7, so it's best to run CheckSentineldb.sh when no one is on the system.

Sentinel.sh

• Sentinel.sh is a wrapper around CheckSentinelDb.sh that handles writing data to the log files and calling the Perl script that e-mails the output to you.

traverse.sh:

• traverse.sh is used to populate your configuration file. Baically, it reads every file under the specified directory, compares the file to a list of hardcoded excludes (/dev, /proc, /var/log, etc. -- see the README for the full list of hardcoded excludes) and writes the path and file name to the configuration file. It is a recursive Bash script and yes, I know there are probably better, easier, and faster ways to implement this (like "find"), but until I get around to writing a more efficient/simpler script, it works and I like it :) Feel free to ignore traverse.sh, if you'd like.

KillSentinel.sh

• KillSentinel.sh does exactly that. It was written in response to a problem I had with Sentinel. Sentinel includes a Perl script that e-mails the names of any files that failed the integrity check to an e-mail address of your choice -- in my case, my pager. Unfortunately, the change alarms I received were usually just files I had edited and forgotten to update -- except once, when I busted a coworker who had been mucking around with one of my servers >:) So, when my pager starts ringing, I usually just want to update a few md5sums and restart. However, CheckSentinel *really* freaks out if you try to edit db.txt while it is running an integrity check, so it's best to end the running Sentinel processes before editing the md5sums. Unfortunately, there are usually a lot of processes to end. Being lazy by nature, I created KillSentinel to make it easier to terminate the integrity check when I've found problems.

MailSentinelViolations.pl

• MailSentinelViolations.pl is a script to e-mail violations to the recipient of your choice. Don't send them to me, though, because 1) I have no access to your system, and therefore don't really want to know what files have changed, and 2) if you do, I'll blacklist your mail server >:) There are tweaks in the works for this script right now, since it is still very much a beta.

agent.conf

• agent.conf is a list of each file on the file system that you want integrity checked. While I usually use the traverse.sh script to populate agent.conf, it is possible to manually edit/populate the file.

db.txt

• This is the md5sum archive database. The file essentially is the output of an md5sum command on each file listed in agent.conf. This file is generated automatically by InitSentineldb.sh, and typically shouldn't be edited by hand. However, if you have removed a file from the file system and don't feel like rerunning InitSentineldb.sh to remove one or two md5sums from db.txt, or if you know a change on a monitored file is legitimate, and you want to update the md5sum for that one (or however many) file(s), it is okay to manually edit db.txt by hand. NOTE: if you edit /etc/Sentinel/agent.conf by hand, don't forget to recalculate the md5sum for that file and replace the existing md5sum in db.txt for agent.conf with the manually calculated sum.

Installation:

I'm not real proficient with many of the cool *nix compilation features, so I've kept this about as basic as possible. Installation in a nutshell:

• download the tarball -- I'll assume you are downloading to /usr/local/src/Sentinel-current.tar.gz for this documentation; if you download the file to another location, you will have to mentally substitute /usr/local/src/ for whatever your destination was.
• su to root (must be root to install)
• cd /
• tar -xvzf /usr/local/src/Sentinel-current.tar.gz
• Edit /usr/sbin/MailSentinelViolations.pl to set the appropriate configuration variables (typically, these will be $Hostname, $Recipient, $Sender, $SmtpHost and $TimeZones). No other changes should be necessary.
• At this point, you will probably want to exclude some files that change on regular occasions from being checked by Sentinel. For example, if /home or /root change frequently, you might wish to exclude them, and you will probably want to exclude log files. Add any such exclusions to /etc/Sentinel/agent.excludes. Also make sure that db.txt is in the list, or you will get errors every time you update the database!
• Now edit /etc/Sentinel/agent.includes to include those files (if any) that you want to monitor that reside inside excluded directories. For example, my mail spool -- which I don't want to monitor -- is located in /var/spool/ but so are my crontab entries -- which I do want to monitor. So I exclude /var/spool in agent.excludes and then I include my root crontab file in agent.includes. agent.includes *always* trumps agent.excludes.
• Run "/usr/local/sbin/traverse.sh / /etc/Sentinel/agent.conf" to populate agent.conf.
• Edit cron to run /usr/local/sbin/Sentinel.sh as often as needed (I recommend once a day).
• Run /usr/local/sbin/InitSentineldb.sh to populate /etc/Sentinel/db.txt.
• That's it--you're done!