Part of the "cheap replacements" series.
The suite of scripts described herein are intended to be a fairly inexpensive alternative to the Tripwire filesystem auditing tool. They allow you to configurably build a database of filesystem information and file checksums that can be used to detect changes to your system, such as those caused by unintended or unauthorized software updates, not to mention cracker intrusions. In particular they are designed to do automated audits and change reports, and as shell scripts using fairly standard utilities they are also easy to customize for your purposes.
Get your copy of tracker.tar here, which includes these four scripts:
These scripts work best with GNU find from ftp://ftp.gnu.org/gnu/findutils/ and GNU sha1sum from ftp://ftp.gnu.org/gnu/coreutils/. In particular GNU find has extended options for printing more complete information about a file, such as its inode change time. You can use a typical vendor-distributed find program and sum instead of sha1sum and give up some ability to detect subtle changes. Note in particular that many cracker toolkits include programs which modify files to match plain sum output, so you're really better off to use sha1sum if at all possible. Previous versions of these scripts used md5sum instead of sha1sum, but now that generating MD5 collisions has become computationally feasible use of md5sum is no longer recommended.
GNU gzip from ftp://ftp.gnu.org/gnu/gzip/ is also used to compress data files to save space when they are not being used. Note that you may need substantial temporary space on a large system to hold the temporary files used during footstep runs and store the data used in tracker runs. For example, on one of our large systems approximately 25 megabytes is needed to keep compressed archived data, and an additional 30 megabytes is used temporarily by tracker when comparing filesystem state information.
If you are using a Linux system, you probably already have all of these utilities.
By default these are set up to be copied into /usr/local/sbin (the common location for such things in Solaris and Digital UNIX, where I've done the most work on them) but by editing the PATH in the scripts you can place them anywhere you want. Make sure that the PATH you use will locate GNU find before your system default find, the other utilities mentioned above, and the other scripts in this suite. The default location for files used and generated by the scripts is /var/local/security.
You'll probably want to set up cron jobs to run tracker and footstep regularly as well. Here are example crontab lines that run tracker daily and footstep weekly; note that you don't need to run tracker on the days that you run footstep:
05 3 * * 1-6 /usr/local/sbin/tracker `cat /var/local/security/fp.last` | mailx -s "daily tracker report" root@host
05 3 * * 0 /usr/local/sbin/footstep | mailx -s "weekly footstep report" root@host
The file fp.last referred to by the tracker cron job contains the date code of the last footstep run.
For best protection, it's a good idea to mail these reports off-system. If a cracker does break into your machine, he may tamper with the data generated by the scripts and the reports in your mailbox -- and I have really seen this happen. Some tamper-detection ability is included in these scripts (see below). If convenient, scheduling footstep runs so that they complete soon before automated system backups will also reduce the damage done by tampering, since you may be able to recover untampered files from backups.
For the most part you configure these scripts by editing them. There are some comments to guide you on which items to edit. filelist and footprint use an external configuration file to specify which filesystems to audit, by default /var/local/security/fp.list, which can be overridden by the -C command-line option. fp.list file consists of find command-line arguments. An example which audits a typical Digital UNIX system is:
/ -xdev -path /tmp -prune -o /usr -path /usr/var -prune -o -xdev
In constructing fp.list, you typically want to include as many filesystems as possible that contain binaries, scripts, and configuration files, but not filesystems and files whose contents change frequently. Here is a more complex configuration for a Solaris system showing how to use more advanced find options:
/kernel /platform /sbin /dev -type f /etc ! -path /etc/passwd ! -path /etc/shadow ! -path /etc/group ! -path /etc/opasswd ! -path /etc/oshadow ! -path /etc/ftpusers ! -path /etc/cron.d/cron.deny ! -path /etc/ssh_random_seed ! -path /etc/mail/sendmail.st /usr -xdev /usr/openwin /usr/local /var/sadm /var/spool/cron/crontabs /opt
It's usually better to start with too much than too little, and narrow down the scope of filesystems or subdirectories to audit as you see which contain less relevant changes. You should almost always audit /usr and /etc as fully as possible.
Once you have installed (and maybe edited) the scripts and created an initial fp.list, run footstep once to create the initial filelist and footprint databases.
By this point you should be able to sit back and watch your tracker reports roll in, and maybe marvel at how much stuff is changing on your system.
Here is a sample report from tracker which will be explained in further detail below.
sha1sum of fp.20051113 (before compression):
5288ca2bb939fef7582fb2f73137631c6d48e079 -
Files that have changed contents since footprint run of 20051113:
/var/lib/ntp/ntp.drift: FAILED
sha1sum: WARNING: 1 of 66844 computed checksums did NOT match
sha1sum of fl.20051113 (before compression):
2df7afa6a51e1f4adb17f2c210dc3b6dead75178 -
Filesystem differences between 20051113 ('<') and now ('>'):
inum blocks ln mode user group bytes ctime mtime name (-> symlink)
------- ------- -- ---- -------- -------- ---------- ------------------------ ------------------------ -----------------
< 143274 0 1 666 root tty 0 Tue Feb 15 06:40:08 2005 Sun Nov 13 00:24:46 2005 /dev/ptmx
> 143274 0 1 666 root tty 0 Tue Feb 15 06:40:08 2005 Tue Nov 15 13:56:53 2005 /dev/ptmx
< 144416 0 1 666 root tty 0 Sun Mar 20 14:26:30 2005 Sat Nov 12 21:17:25 2005 /dev/tty
> 144416 0 1 666 root tty 0 Sun Mar 20 14:26:30 2005 Sun Mar 20 14:26:30 2005 /dev/tty
< 144660 0 1 640 root adm 0 Sun Nov 13 06:55:03 2005 Sun Nov 13 06:55:03 2005 /dev/xconsole
> 144660 0 1 640 root adm 0 Tue Nov 15 10:28:18 2005 Tue Nov 15 10:28:18 2005 /dev/xconsole
< 1 0 108 555 root root 0 Mon Oct 24 12:52:13 2005 Mon Oct 24 12:52:13 2005 /proc
> 1 0 140 555 root root 0 Mon Oct 24 12:52:13 2005 Mon Oct 24 12:52:13 2005 /proc
< 1369 0 7 1777 root root 200 Sun Nov 13 06:55:01 2005 Sun Nov 13 06:55:01 2005 /tmp
> 1369 0 8 1777 root root 260 Tue Nov 15 13:54:08 2005 Tue Nov 15 13:54:08 2005 /tmp
< 416985 2 1 644 root root 378 Sun Nov 13 06:25:13 2005 Sun Nov 13 06:25:13 2005 /var/lib/logrotate/status
> 416985 2 1 644 root root 378 Tue Nov 15 06:25:12 2005 Tue Nov 15 06:25:12 2005 /var/lib/logrotate/status
< 8221 2 2 755 root root 1024 Sun Nov 13 06:11:31 2005 Sun Nov 13 06:11:31 2005 /var/lib/ntp
< 8232 2 1 644 root root 7 Sun Nov 13 06:11:31 2005 Sun Nov 13 06:11:31 2005 /var/lib/ntp/ntp.drift
> 8221 2 2 755 root root 1024 Tue Nov 15 13:17:37 2005 Tue Nov 15 13:17:37 2005 /var/lib/ntp
> 8235 2 1 644 root root 7 Tue Nov 15 13:17:37 2005 Tue Nov 15 13:17:37 2005 /var/lib/ntp/ntp.drift
Note that the report includes checksums of the footprint (fp.*) and filelist (fl.*) files that were used to generate this report. This is a fairly simple tamper-detection mechanism; you can compare these checksums with those issued by the most recent footstep run when it created those files. Any difference in the checksums indicates an attempt to tamper with those files.
The report has two main parts: a listing of files whose contents have changed, as detected by sha1sum -c, and a diff report showing changes to filesystem state, such as changed file sizes, permissions, ownerships, or timestamps. The GNU find output shown consists of these fields, left-to-right:
If you are using your system's vendor-supplied find, consult its manpage for the format of output given by find -ls.
A footstep report contains this same data, but also states the checksums of the new fp.* and fl.* files it just created.
You can run tracker at any time to check which files have been changed on your system. tracker datecode will compare your current system state against the state generated by footstep on that date; tracker datecode1 datecode2 will compare two previously-generated states.