Before installing and configuring Tripwire, we create a sample script that performs a similar function. This script will help in gaining a better understanding of how Tripwire and similar tools function.
The script relies heavily on the md5sum program. The md5sum program is used to compute a 128-bit checksum (or "fingerprint") for a specified FILE.
The script functions’ as summarized below:
Right after the base system has been installed, it will back up some of the system configuration files in the /etc directory, into a directory called etc.bak in roots home directory.
In particular it will back up all the files under /etc with the suffix “*.conf”
It does this when run with the initialization option ( -- initialization| -i)
The script will then obtain the md5 checksums of the known suitable files (untainted files).
The list of MD5 sums will be stored in a file called “md5_good”.
When the script is run in a verify mode, the md5sum program will be called with the “ - -check” option to check the current MD5 sums against a given list (the md5_good file).
The script will print the verification output to the standard output and send a copy of the result via e-mail to the superuser.
Whenever changes are made (legal or illegal) to the configuration files under /etc the script can be called with the --rebuild| -r option to approve the changes and rebuild the baseline pseudo database.
You can periodically run the script manually or create a cron job to automatically run the script.
The script below can be fine-tuned and scaled to do much more than it does. It is left to you and your imagination to make it do whatever you want.
If you just want a quick and dirty way to get the job done the script will suffice but for everything else there is Tripwire.
Log in as root and launch your text editor of choice. Enter the text below:
#!/bin/sh# This script checks for changes in the MD5 sums of files named "/etc/*.conf"case$1in-i|--initialize)# This section will run if the script is run in an initialization mode# Delete old directory, make directory, backup good files, and change directory to /root/etc.bakrm-rf/root/etc.bak
mkdir/root/etc.bak
cp/etc/*.conf/root/etc.bak
cd/root/etc.bak
# Create our baseline file containing a list of good MD5 sumsforiin/etc/*.conf;domd5sum$i>>md5_good
doneecho-e"\nUntainted baseline file (~/etc.bak/md5_good) has been created !!\n";;-v|--verify)# This section will run if the script is called in a verify modecd/root/etc.bak
# Check if there is any file containing output from a previous runif[-fmd5_diffs];thenrm-fmd5_diffs# if it exists we delete itfi# We re-create the file with a pretty sub-heading and some adviceecho-e"\n **** Possibly tainted File(s) ****\n">md5_diffs
# Run the md5sum program against a known good list i.e. "md5_good" filemd5sum-cmd5_good2>/dev/null|grepFAILED>>md5_diffs
if[$?-ge1];thenecho"Nothing wrong here."else# Append some helpful text to the md5_diffs fileecho-e"\nUpdate the baseline file if you approve of the changes to the file(s) above \n">>md5_diffs
echo-e"Re-run the script with the re-build option (e.g. ./check.sh --rebuild) to approve \n">>md5_diffs
catmd5_diffs# print the md5_diffs file to the displayif[-x/usr/bin/mail];thenmail-s"Changed Files"root<md5_diffs# also e-mail the md5_diffs file to rootfifi;;-r|--rebuild)# This section is for re-building the Baseline file just in case# the changes to the configuration files are legal and sanctionedcd/root/etc.bak/
mvmd5_goodmd5_good.bak# make a backup copy of the current untainted baseline fileforjin/etc/*.conf;domd5sum$j>>md5_good
doneecho-e"\nBaseline file updated with approved changes !!!\n";;*)echo"This script accepts: only ( -i|--initialize or -v|--verify or -r|--rebuild ) parameters";;esac
Save the text above in a text file and name the file “check.sh”
Use the ls command to view contents of root’s home directory. You should have a new directory named etc.bak therein.
Use the cat command to view the /root/etc.bak/md5_good file.
Per the warning above, you should investigate further to see if the altered file meets your approval. If it does, you may run the script with a --rebuild option.
To view only the differences between the “tainted” file and the “untainted” file you could type:
One of the first things you should do after building any new system is to get a snapshot of a known good state of the system before the system is “contaminated” or before deploying the system into production.
Several tools exist for doing this. One such tool is Tripwire. Tripwire is an advanced tool, so brace yourself for many options, syntax, quirks, and switches.
Tripwire can be regarded as a form of a host-based intrusion detection system (IDS). It performs intrusion detection functions by taking a snapshot of a "healthy system" and later comparing this healthy state with any other suspect states. It provides a means of knowing/monitoring whether certain sensitive files have been altered illegally. The system administrator of course decides what files are to be monitored.
The authors of Tripwire describe it as an Open Source Security, Intrusion Detection, Damage Assessment and Recovery, and Forensics software.
Tripwire compares a file’s new signature with the one taken when the database was created.
The steps involved in installing and configuring Tripwire are as listed below:
Install the software from the source or binary
Run the configuration script: (twinstall.sh). This script is used to:
a) Create the site key, local key, and prompts for passphrases for both
b) Sign the policy file and configuration file with the site key
Initialize the Tripwire database
Run the first integrity check.
Edit the configuration file (twcfg.txt)
Edit the policy file (twpol.txt)
Tripwire accepts the following command line options:
The twadmin utility performs administrative functions related to Tripwire files and configuration options. Specifically, twadmin allows encoding, decoding, signing, and verification of Tripwire files, and provides a means to generate and change local and site keys.
Configuring Tripwire involves (if needed) customizing the Tripwire configuration file, the policy file, and then running the configuration script. The script will prompt you for a passphrase that will be used to sign/protect the configuration file, the policy file and the database file.
Change your pwd to Tripwire’s working directory: Type:
[root@localhostroot]# cd /etc/tripwire/
List the contents of the directory.
Use any pager or text editor to view/study the files in the directory.
We will accept the settings that come with the default configuration. file (twcfg.txt) and the provided default policy file (twpol.txt) for now.
Execute the Tripwire configuration utility as root. You will be prompted (twice) for site keyfile passphrase. Select any passphrase that you WILL NOT forget ( The site key is meant for the twcfg.txt file and the twpol.txt file) Type:
Next you will be prompted for a local key. Again select another password YOU WILL not forget. (The local key signs the Tripwire database files and the reports files)
After choosing your passphrases the tripwire-setup-keyfiles program will then proceed with the actual creation/signing of the encrypted versions of the original plain text files ( i.e tw.cfg and tw.pol will be created respectively). You will be prompted again for the passphrases you choose earlier. At this point just follow the prompts until the script exits.
List the new contents of the /etc/tripwire directory.
Per the warning you got while the tripwire-setup-keyfiles utility was running, you will now move the plain text versions of the configuration file and policy files away from the local system. You could store them on an external removal medium or encrypt them in place (using a tool like GPG for example) OR completely delete them if you are feeling particularly daring. Type:
It may be useful to keep the plain text versions in safe place incase you forget your passphrases. You can then always re-run the tripwire-setup-keyfiles based on the configurations and policies you have fine-tuned over time.
Initializing the database is the Tripwire terminology for, taking an initial “untainted” snapshot of the files you have decided to monitor (based on the policy file). This generates the database and also signs the database with the local key. The database serves as the baseline for all future integrity checks.
Running Tripwire in this mode (integrity check mode) compares the current file system objects with their properties in the Tripwire database. Discrepancies between the database and the current file system objects are printed to the standard output while Tripwire runs in this mode. After the check is complete Tripwire also generates a report file in the directory specified in the twcfg.txt file (/var/lib/tripwire/report/).
Run an integrity check. Type:
[root@localhosttripwire]# tripwire --check
You'll see some [expected] warnings stream by during this check.
Check under the /var/lib/tripwire/report directory to see if a report was also created in there for you.
Lab task:
Write down the name of the report file that was created.
FILE_NAME =
Run the integrity check again but manually specify a file name for the report file. Type:
[root@localhosttripwire]# tripwire -m c -r /root/tripwire_report.twr
Ensure that a new file was created under root’s home directory. Type:
[root@localhosttripwire]# ls -l /root/tripwire_report.twr
Tripwire’s report files, are a collection of rule violations discovered during an integrity check.
There are several ways to view a Tripwire report file:
during integrity check
in the form of an email automatically sent to you
using the twprint command provided with the Tripwire package
Note
You probably noticed from the earlier exercise that Tripwire uses a combination of the systems FQDN name, the date, and the time to name the report files by default.
First change to the default report’s directory and view the default report created for you in step 1 above ( FILE_NAME). Type:
[root@localhostreport]# cd /var/lib/tripwire/report && twprint --print-report -r <FILE_NAME>
Replace above with the value you noted earlier.
To use the short form of the above command type:
[root@localhostreport]# twprint -m r -r <FILE_NAME> | less
We pipe the output to the less command because the report scrolls by quickly.
Now view the other report you created manually, under root’s home directory. Type:
[root@localhostroot]# cd && twprint --print-report -r /root/tripwire_report.twr | less
Brace yourself and study the output of the report file carefully.
You should have noticed again that Tripwire created binary/data forms of the report files. Create a text only version of the report file under roots home directory. Type:
Here you will test the e-mail functionality of Tripwire. Tripwire’s e-mail notification system uses the setting specified in the Tripwire configuration file. (twcfg.txt).
First view the configuration file and note the variable(s), that control Tripwire’s e-mail notification system. To view the configuration file type:
[root@localhostreport]# twadmin -m f | less
Lab task:
Write down the relevant variable(s).
Next, ensure that your local mail system is up and running by checking the status of say postfix. Type:
[root@localhostreport]# systemctl -n 0 status postfix
.......
Active:active(running)sinceThu2023-08-3116:21:26UTC;3weeks6daysago
.......
Your output should be similar to the above. If your mailing system is not running, troubleshoot that first and get it up and running before continuing.
After installing Tripwire, taking a snapshot of the system and then running the first integrity check you will more likely than not need to fine-tune Tripwire to suit the needs of your particular environment.
This is mostly because the default configuration and policy file that comes bundled with Tripwire may not exactly fit your needs or reflect the actual objects on your file system.
You need to ascertain if the file system violations reported in the report file during the integrity check are actual violations or legitimate/authorized changes to your file system objects.
Again Tripwire offers several ways of doing this.
Using this method you will change or fine-tune what Tripwire considers violations to your file system objects by changing the rules in the policy file. The database can then be updated without a complete re-initialization. This saves time and preserves security by keeping the policy file synchronized with the database it uses.
You will use the report file you created earlier ( /root/tripwire_report.txt ) to fine-tune your policy file by first preventing Tripwire from reporting the absence of files that were never on the filesystem in the first place.
This will help to greatly reduce the length of the report file that you have to manage.
Use the grep command to filter out all lines in the report file that refers to missing files (i.e. Lines containing the word “Filename”). Redirect the output to another file - tripwire_diffs.txt. Type:
View the contents of the file you created above. Type:
[root@localhostroot]# less tripwire_diffs.txt207:Filename:/proc/scsi
210:Filename:/root/.esd_auth
213:Filename:/root/.gnome_private
216:Filename:/sbin/fsck.minix
219:Filename:/sbin/mkfs.bfs
..................................
Now you need to edit the Tripwire policy file and comment out or delete the entries in the file that should not be in there. For example, some files are not on your system, and some never will be. One of the files, for example, that the policy file is trying to monitor is the /proc/scsi file. If you do not have any SCSI devices on your system, then there is no sense in monitor this file.
Another debatable example of what to monitor or not to monitor is the various lock files under the /var/lock/subsys/ directory. Choosing to monitor these files should be a personal call.
Re-create a text version of the policy file - just in case you removed it (as advised ) from the local system. Type:
Edit the text file you created above using any text editor. Comment out references to objects that you do not want to monitor. You can use the tripwire_diffs.txt file you created earlier as a guideline. Type:
Running tripwire in the database update mode after an integrity check provides a quick and dirty way to fine tune Tripwire. This is because Database Update mode allows any differences between the database and the current system to be reconciled. This will prevent the violations from showing up in future reports.
This update process saves time by enabling you to update the database without having to re-initialize it.
Replace with the report file name you noted earlier.
The above command will also launch your default text editor (e.g. vi), which will present you with so-called “update ballot boxes”. You may need to scroll through the file.
The entries marked with an “[x]” implies that the database should be updated with that particular object.
Remove the "x" from the ballot box “[ ]” to prevent updating the database with the new values for that object.
Use your text editor’s usual key-strokes to save and exit the editor.
Next try using the database update mode in a non-interactive manner. i.e. you will accept all the entries in the report file will be accepted without prompting. Type:
[root@localhostreport]# tripwire --update -Z low -a -r <LATEST_REPORT>
You will begin these exercises by first fine-tuning your configuration file. In an earlier exercise you were advised to remove or delete all clear-text versions of Tripwire’s file from your system. You will create a slightly more secure Tripwire installation by editing some of the variables in the Tripwire configuration file. You will specify that Tripwire should always look for the binary versions of the policy and configuration files on removable media such as a floppy disk or CDROM.
Change your pwd to the /etc/tripwire directory.
Generate a clear-text version of the configuration file. Type:
The /etc/tripwire/tw.cfg file will be created for you.
Test your new set up. Un-mount the USB drive and eject it.
Try running one the tripwire commands that needs the files stored on the floppy drive. Type:
[root@localhosttripwire]# twadmin --print-polfile### Error: File could not be opened.### Filename: /mnt/usbdrive/tw.pol### No such file or directory###### Unable to print policy file.### Exiting...
You should get an error similar to the one above.
Mount the media where your Tripwire files are stored, and try the above command again.
Question
Did the command run successfully this time?
Search for and delete all the plain text versions of Tripwire’s configuration files you have created thus far from your system.
Having to mount and unmount a removable media each time you want to administer an aspect of Tripwire may end up being such a drag, but the payoff may be in the extra security. You definitely want to consider storing a pristine version of Tripwire’s database on a read-only media such as a DVD.
Configure your Tripwire installation run an integrity check every day at 2 A.M and send out a report of the integrity check via e-mail to the super user on the system.