A crude yet effective intrusion detection system such as Tripwire can alert systems administrators to possible intrusion attempts by periodically verifying the integrity of a server's file systems. Systems intruders will often use trojan binaries for login, su, ps, and ls, etc. to cover their tracks and keep a low profile on the system. Under normal circumstances even astute systems administrators may not observe the intrusion because the trojan binaries mimic the system binaries so well.

One tried and true method to alert systems administrators of unexpected file system alterations is to use a software package such as Tripwire to keep a database of checksums on the file sizes of critical system files. Depending on the configuration, Tripwire can notify appropriate personnel if a critical file or directory is modified or deleted.

By using a strong checksum method similar to MD5, Tripwire can identify with absolute certainty whether or not a file has been modified, unlike similar programs that use weaker algorithms such as CRC to calculate checksums.

Also, for maximum effectiveness Tripwire should be installed at the time the operating system is installed to ensure that the system does not already have any trojan binaries. Tripwire is only as reliable as the initial file system its database is based upon. If the file system has already been attacked, then Tripwire can only identify further damage to the filesystem, if that.

The Linux Open Source Edition

Recently, Tripwire, Inc. has decided to open the source for a more recent version of the Tripwire package specifically for the Linux OS. Previously, a binary only version of the software had been made available to the Linux community and another version of the software with and an older, less featured academic source license had been available to the public. The Linux open source edition includes most of the newer features of the software, such as the ability to alert specific administrators for different areas of alterations, while remaining compatible with the commercial version of the software.

Getting the Software

Binary packages are available at tripwire.org for use with the Red Hat 7.0 distribution of Linux, though the binaries work fine on similar RPM based distributions such as Mandrake. For other types of Linux distributions, Tripwire will need to be compiled from the source tarballs located on the same page. For Red Hat 7.0, the RPM binaries are also available on the second binary CD of the distribution.

Installing Tripwire

Although it isn't a difficult procedure to compile Tripwire from source, this article will be limited to describing the installation process from the binary RPM.

If Tripwire is downloaded from the website listed above, please be aware that the RPM is also tar/gzipped. Thus, to install the Tripwire RPM, issue the following commands as root:

  tar xvzf tripwire-2.3-47.i386.tar.gz

  rpm -ivh tripwire-2.3-47.i386.rpm

Once the software is installed with rpm, the installation shell script will need to be executed to finish the Tripwire installation. This is done by issuing the command:

  /etc/tripwire/twinstall.sh

as root. Note that all Tripwire associated files are kept in the /etc/tripwire directory.

Initial Tripwire Configuration

Because very few Linux installations are identical, Tripwire will need a fair amount of configuration to adequately protect the system. Configuration begins during the installation script launched above with the selection of site and local passphrases. These passphrases are the key to preventing intruders from modifying your Tripwire installation and circumventing its protection so strong passphrases are essential!

The site key is used to sign Tripwire's policy and configuration files while the local key is used for signing the database files. For enterprise wide installations, the use of multiple levels of passwords makes Tripwire more manageable by allowing a site to split administration functions across by a number of system administrators.

The installation script creates default policy and configuration files stored in /etc/tripwire as twpol.txt and twcfg.txt. These files are in cleartext and need to be removed from the system as soon as the encrypted versions are in place for obvious security reasons.

The default policy probably includes monitoring for a number of files not present on the local system, so it's important to trim these files out of policy. The following procedures will illustrate exactly how this is done.

The default policy should be installed using the command as root:

  /usr/sbin/twadmin -m P /etc/tripwire/twpol.txt

Next, generate the initial database using the following command as root:

  /usr/sbin/tripwire -m i

Note that the -m switch identifies the mode in which Tripwire is being executed, which is "i" for "initialization" in this case. Later, the "c" mode for "check" will be used. Expect the initialization to take quite a long time, even on a fast machine.

Customizing Tripwire's Configuration

Once and initial database is created, some customization is necessary to prevent the issuance of a large number of false alarms. These false alarms occur any time there is a discrepancy in the default policy and the local system's current configuration. To generate a listing of the discrepancies between the local system and the default policy, issue the following command as root:

  /usr/sbin/tripwire -m c | grep Filename >> twtest.txt

Note that this command will also take several minutes to complete. Once this listing has been generated, edit the policy file, /etc/tripwire/twpol.txt, and comment out or delete each of the filenames listed in twtest.txt.

Additionally, there are other files in the default policy that may not make sense to monitor on the local system. These include lock files (which identify that some process is in use) and pid files (which identify the process ID of some daemons). Since the files are likely to change often, if not at every system boot, they can cause Tripwire to generate false positives. To avoid such problems, comment out all of the /var/lock/subsys entries as well as the entry for /var/run.

Finalizing the Tripwire Configuration

Any time the tripwire policy file is edited, the policy needs to be reinstalled and the database will need to be recreated. As before, these tasks are accomplished by issuing the following commands as root:

  /usr/sbin/twadmin -m P /etc/tripwire/twpol.txt

  /usr/sbin/tripwire -m i

At this point it wouldn't be a bad idea to repeat the customization procedures just to ensure that none of the unnecessary files listed in twtest.txt were omitted.

It's now safe to delete the clear text versions of the Tripwire policy and configuration files, which can be performed by issuing the following command as root:

  rm /etc/tripwire/twcfg.txt /etc/tripwire/twpol.txt

If they need to be restored cleartext versions of these files can be created from the encrypted versions by issuing the command (and providing the appropriate passphrases):

  /usr/sbin/twadmin -m p > /etc/tripwire/twpol.txt

Note that unlike before, the "p" in this command is lowercase.

Finally, it is desirable to save a copy of the database at least initially and periodically if possible to read-only media such as CD-R. Having read-only copies of the database file is the only way to guarantee 100% that Tripwire's database is authentic.

Scheduling a Nightly Tripwire Analysis

Without regular checks of the filesystem, Tripwire is effectively useless, so this section will identify how to schedule Nightly Tripwire Analyses that are e-mail to the system administrator.

First, one needs to create a shell script for generating the Tripwire reports. Creating the shell script can be more useful than just placing the command in the crontab because it allows the administrator to perform a filesystem check without needing to remember the exact syntax necessary for doing so.

Create the file "runtw.sh" in the directory /usr/local/bin that has the following contents:

#!/bin/sh

/usr/sbin/tripwire -m c | mail -s "Tripwire Report from HOST" root@localhost

Of course, HOST should be changed to the hostname of the system. Don't forget to make the shell script executable by root.

Then, schedule the script to execute nightly at 1:01am by adding the line:

  1 1 * * *     /usr/local/bin/runtw.sh

to root's crontab using the command:

  crontab -e

Tripwire will now submit nightly reports to the system administrator on the status of the file system's integrity.

Conclusion

With the help of this walkthrough, one should be able to prepare a fully functional Tripwire installation. However, this article has barely scratched the surface of Tripwire's feature set, which also includes determining the level of seriousness of an affected file or directory, reporting to syslog, and many other advanced features. Some other sources of information include the fine man pages (tripwire, twadmin, twintro, twfiles, twpolicy and twconfig), Red Hat Documentation, and Tripwire, Inc.

About the Author

Write Comment
Please keep the topic of messages relevant to the subject of the article. Personal verbal attacks will be deleted. Please don't use comments to plug your web site.. Such material will be removed.
Name:
Title:
Comment:
Code:*

Powered by AkoComment!