Section 17.2 Tripwire

---

17.2 Tripwire

Tripwire is a powerful tool that computes a hard-to-fake MD5 checksum^[1] of each file on your system that you are interested in monitoring for tampering (Trojan horses, altered or deleted data, etc.). These would include your system configuration files in /etc, system programs in /bin and /usr/bin, applications, and user accounts. At any subsequent time, you can ask Tripwire to recompute these checksums and inform you of any changes from the previously computed baseline. By knowing usage patterns in your system, you easily can decide which changed files are likely to be legitimate, such as /home/joe/mbox, and which are not, such as /bin/su. At any time you may ask Tripwire to update the baseline. Typically, this is done after you analyze the differences and determine that they are okay.

^[1] The output of the md5sum program more properly is called a message digest, hence md5sum. The intent of a checksum is just to detect if data was unintentionally garbled and it is not guaranteed to detect deliberate tampering with the message. A message digest, such as that generated by md5sum, makes it very hard to alter the message without also altering the message digest output.

SuSEauditdisk, an open source alternative to Tripwire, is under development at

www.suse.de/~marc/

It might be available by the time you read this. Also, Tripwire for Linux is open source.

You may configure Tripwire to store the checksum data (and itself) on a floppy. You then can set the floppy to be Read/Only to prevent tampering and, of course, arrange for cron to check the results periodically and e-mail them to you. You might want this e-mail to be sent to a different system to resist tampering in case this system is cracked. What if the cracker is really good and he alters your shell or your kernel so that when you instruct the system to run Tripwire, it instead runs a fake Tripwire? Because it is Linux, if you have not already created a set of rescue disks, now is a fine time and the Linux Administrators Guide explains this.

Rescue disks are a set of floppies with the first one being a self-contained bootable kernel and the second one being a root file system that gets copied into a RAMDISK, typically containing tools for repairing a corrupt root file system. Its principal intent is to repair a hard disk root file system that is so badly damaged that it will not boot.

Many SysAdmins do not take advantage of the ease of creating their own custom rescue root disk. They are quite easy to create; the steps are described in "Custom Rescue Disks" on page 600. Many systems will boot from CD-ROM, allowing their use in this way too.

I must be honest here. Although Tripwire is powerful, I found the documentation misleading and incomplete at best and it seemed incorrect in its explanations of how different flags are used to do even the most basic operations, such as "determine what has changed and e-mail root." It failed to mention even something as basic as "if a specified file does not exist, you cannot tell Tripwire that the change is normal so accept the new condition of the file not being there; you must update the policy file." Many flags did not operate or interact in the ways I expect from a Linux or UNIX program. I found it to be the most painful and unpleasant program on Linux to date. Still, Tripwire can be helpful.

17.2.1 Installing Tripwire

First, download the latest free version (or buy the commercial version). The free version may be downloaded from the following site after giving some contact information to Tripwire, Inc. Although this version has some restrictions, the company has released the Tripwire source for Linux under the GPL. It cannot be put on the CD-ROM or Web site due to U.S. export restrictions and license restrictions. Note that you will be offered binaries only. They claim to support Red Hat only. It does not require RPM and should work on other distributions. You will want to operate in a newly created empty directory for this purpose, such as tripwire, after downloading from

www.tripwire.com/downloads/

The download will leave a gziped tar file in your directory. Unzip it and extract it with the usual

 gunzip Tripwire_221.tar.gz tar -xovf Tripwire_221.tar 

or

 tar -xzovf Tripwire_221.tar.gz 

As root, issue the command

 ./install.sh 

It will check for needed programs on the system, such as tar, awk, and vi that should be on every normal Linux system. It will ask you to read the license and accept it. Then it will ask you for site and local Tripwire passphrases. They may be up to 1024 characters each. Tripwire does not reject easy-to-crack passwords. Pick good passwords that are hard to break, as discussed in "Passwords A Key Point for Good Security" on page 41. You will be asked to re-enter your passphrases several times during configuration as it invokes various Tripwire programs that require the passphrases to ensure security. By default, it creates the Tripwire system under /usr/TSS. It will suggest that you inspect and remove the clear-text version of the Tripwire configuration file.

 /usr/TSS/bin/twcfg.txt 

It then suggests, abruptly, that you read the release notes and have a nice life. Policies are stored under /usr/TSS/policies. The twpol.txt file controls what files Tripwire will watch and what to expect from each. It is well commented, it claims to understand that designated log files will grow, and it understands what device files are. It is a good idea to spend some time editing this file at this point. The alternative is significant bother later. Install the documentation with the following commands:

 cd /usr/TSS/man cp man4/* /usr/local/man/man4/. cp man5/* /usr/local/man/man5/. cp man8/* /usr/local/man/man8/. 

17.2.2 Using Tripwire

Once the twpol.txt file has been edited, it is time to create the secure version of this file. The Tripwire documentation says to "Make sure that the integrity of the system you are running has not been compromised." It further suggests that the operating system (Linux) and application files should be installed from original media (CD-ROM) to get a clean baseline; that is, be guaranteed not to have any Trojans. Well, it is a bit late for that unless you want to reformat your disk and start again. However, "Speeding Up the Check with RPM" on page 700 discusses how to use Red Hat's RPM program to validate that the installed packages have not been tampered with.

Issue the command

 cd /usr/TSS/bin ./twadmin --create-polfile ../policy/twpol.txt 

to create the cryptographically safe version of this file, which is signed cryptographically to prevent tampering, and placed in

 /usr/TSS/policy/tw.pol 

Now, initialize the database with the following command:

 ./tripwire --init 

Test e-mail with this command:

 ./tripwire --test --email root 

To run a file system integrity check (check the file system for changes), issue the command

 ./tripwire -m c 

or

 ./tripwire --check 

It will take a few minutes to check every file on your system, output a report to standard output, and store a report in /usr/TSS/report/hostname-date.twr. A copy of this report can be generated to standard output at any later time with

 twprint --print-report -r ../report/report_file.twr 

The amount of detail may be specified with the -t flag, which takes an argument of between 0 and 4. Increasing numbers mean increasing detail. The following would make a good entry to root's crontab, to be invoked shortly before you normally arrive at the office (or before the day's heavy load starts):

 ./tripwire -m c -r /usr/TSS/report/nightly.twr \   2>&1 | mailx -s TRIPWIRE root 

After you review it in the morning (if any changes other than the usual log file babble occurs), you then could issue the command

 ./tripwire -m u -r /usr/TSS/report/nightly.twr 

It will "pop" you into the editor where each changed entry has an [x] entry to indicate the default of updating the database to expect the newly altered version. If you replace the "x" with a space, it will not update the database for that entry. You would change the [x] to [ ] for a change that either is unauthorized or which requires further research. If your configuration is such that you have not allowed for log files changing, this "update" report makes the previous "check" report redundant.

A text version of the secure and encoded policy (rules) file may be generated with

 ./twadmin --print-polfile > ../policy/policy.txt 

If Tripwire complained about missing files, edit them out of this file. Then update the default policy with this new edited policy thusly:

 ./tripwire -m p --secure-mode low ../policy/policy.txt 

The /bin/date program is supposed to be mode 755. If you issue the command

 chmod 711 /bin/date 

the program will be altered but not broken. A subsequent

 ./tripwire -m c 

will include the following in its reports.

 Rule Name            Severity Level  Added  Removed  Modified ---------            --------------  -----  -------  -------- * OS execs and libs  100             0      0        1 Modified: "/bin/date" 

Note that Tripwire did not bother to report what changed about the /bin/date file even though it knows. Even my "one liners" in the previous section provided more useful information.

17.2.3 What Tripwire Cannot Protect From

Earlier versions of Tripwire talked about the necessity of keeping the program and database on Read/Only media to prevent tampering by crackers. It now proudly states that because the database and trusted files are cryptographically signed, this no longer is necessary. This author disagrees. If a cracker is sophisticated enough to tamper with Tripwire's database by "updating" it to not notice her Trojans, she could be sophisticated enough to install a Trojaned version of Tripwire. This Trojan version could prompt the SysAdmin for the passphrases in the usual places and proceed to alter the database and re-sign it or pretend that nothing has been altered.

A very sophisticated cracker could add Trojan horses to tripwire, /bin/sh, and even the kernel. This situation would not be detected by the standard usage of Tripwire (trusting the on-disk copies). When you have reason to believe that a sophisticated cracker has attacked, or periodically "just in case," the following is suggested. Create Tripwire-specific rescue disks, using "Custom Rescue Disks" on page 600 as a guide. Boot the rescue disks and run that absolutely trusted Tripwire executables and database. Clearly, this trusted database must be updated periodically and it is not acceptable simply to copy it from the "regular" one on hard disk because that one is not completely trustworthy.

17.2.4 Replacements for Tripwire

There are several open source competitors to Tripwire. AIDE may be downloaded from

ftp://ftp.linux.hr/pub/aide/

The current version is

 aide-0.7.tar.gz 

The sparse manual is available from

www.cs.tut.fi/~rammer/aide/manual.html

Trojan horses do not have a ghost of a chance if you use the samhain file integrity checker from the CD-ROM or from

www.la-samhna.de/samhain.index.html

Also, there is Gog&Magog, which may be downloaded from

www.multimania.com/cparisel/gog/

and Sentinel, which has a nice optional GUI front end, at

http://zurk.sourceforge.net/zfile.html

SuSEauditdisk operates from a bootable disk to provide very secure integrity checking. It is standard with SuSE and can be ported easily to other distributions. Download it from

www.suse.de/~marc/

---

Top