Hack66.Tame Tripwire

Hack 66. Tame Tripwire

The Tripwire program is a great intrusion-detection system, but it can also be a pain to configure. Save yourself time and trouble with these tips and tricks.

Do you ever wake up in a cold sweat at night, worrying about someone compromising your servers? Have you ever found yourself wondering if the ls binary that you execute on your machine is actually telling you the truth about the files in your home directory? If so, welcome to the wonderful world of system administrator paranoia. And here's a tip: you should look into the possibility of deploying an intrusion-detection system on your servers so that you can rest easy every night.

There are many different types of IDS out there. Some focus on analyzing incoming network connections, some simply monitor logs and send alerts to sleeping sysadmins, and others analyze the binaries, configuration files, and libraries on a system and notify sysadmins of any changes. Tripwire is an excellent example of the third type of IDS software. It creates a database of the characteristics of the files in your filesystem and can then monitor the integrity of every single file and directory on your server. But while such security can be massively reassuring to the paranoid sysadmin, it doesn't come without a cost. Tripwire can be a beast to set up and configure properly, and hours of tweaking may be required to tune it properly for your filesystem. However, with a little bit of help, you can have Tripwire running strong on your system without too much effort.

7.5.1. Installing Tripwire

Obviously, the first step is to obtain and install the software. You have two options for this. The first, and by far the easiest, is to use your package management software to install Tripwire. Alternatively, you can install from an RPM available on a third-party site. The procedure I'm going to go through is for installing Tripwire on Fedora Core 4 via the RPM available on an independent Fedora software site, but the procedure should be similar for any other RPM-based distribution.

First, download the RPM from http://rpm.chaz6.com/?p=fedora/tripwire/tripwire-2.3.1-18.fdr.3.1.fc4.i686.rpm. Install it as normal from the command line:

 # rpm -Uvh  tripwire-2.3.1-18.fdr.3.1.fc2.i686.rpm  

If you don't have any unsatisfied dependencies, the RPM will successfully load Tripwire onto your system.

Now that the application is installed, take a moment to become familiar with the configuration files that control Tripwire. There are two main files, and we'll cover each of them in detail.

7.5.2. Tripwire's Execution Configuration File

The file /etc/tripwire/twcfg.txt controls the environment and manner in which Tripwire operates. It is in this file that you can specify alternate installation directories, the location of the policy and database files, where to output reports, and where to find the site and local keys so that everything can be securely signed. The following is a sample twcfg.txt file:

 ROOT =/usr/sbin POLFILE =/etc/tripwire/tw.pol DBFILE =/var/lib/tripwire/$(HOSTNAME).twd REPORTFILE =/var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr SITEKEYFILE =/etc/tripwire/site.key LOCALKEYFILE =/etc/tripwire/$(HOSTNAME)-local.key EDITOR =/bin/vi LATEPROMPTING =false LOOSEDIRECTORYCHECKING =false MAILNOVIOLATIONS =true EMAILREPORTLEVEL =3 REPORTLEVEL =3 MAILMETHOD =SENDMAIL SYSLOGREPORTING =false MAILPROGRAM =/usr/sbin/sendmail -oi -t 

Most of the directives within this file are self-explanatory; however, there are a few that can be somewhat misleading. My favorites are:

LATEPROMPTING

Controls how long Tripwire will wait before asking for a password. If this option is set to true, Tripwire will wait as long as possible before prompting the user for a password. This limits the password's time of exposure within system memory, therefore keeping it more secure.

LOOSEDIRECTORYCHECKING

Used to configure Tripwire to notice how files change within directories that are modified. If this is set to false and a file within a watched directory changes, Tripwire will notify you that both the directory and the file have changed. When set to true, it will simply notify you that the file has changed. This option is present to prevent you from becoming inundated with redundant messages within the Tripwire reports.

MAILNOVIOLATIONS

Instructs Tripwire whether or not to email you even if everything has checked out okay. When set to true, tripwire will send you email just to let you know everything is okay. When set to false, only problem reports are sent.

EMAILREPORTLEVEL

Configures the level of detail that Tripwire should report. Experiment with this one and see how you prefer it. Alternatively, you may override this option when launching Tripwire from the command line.

MAILMETHOD

Enables you to identify how Tripwire reports are delivered via email. There are two possible values: SMTP, for using an open SMTP relay; and SENDMAIL, for using your own Sendmail server. This variable should be configured to reflect the configuration of your network and mail servers.

MAILPROGRAM

Tells Tripwire where to find the mail program you want it to use to send out email notifications.

SYSLOGREPORTING

Tells Tripwire whether or not it should report its findings to syslog. Working directly with syslog can help to configure this further.

Now that we've configured how Tripwire will execute and behave, let's examine the configuration file that controls how and what it analyzes.

7.5.3. Tripwire's Policy Configuration File

The file /etc/tripwire/twpol.txt tells Tripwire how you want your filesystem monitored. This file can seem overwhelming at first, but don't panic! It's actually quite straightforward once you know what you're looking at. Tripwire includes a sample configuration file on which you can base your configuration. In our case some tweaking will be needed, as this template file is geared toward a default Red Hat system.

The first part of the configuration file that you should pay attention to is the section labeled @@section FS. This section provides the details that should be taken into account when checking different types of files. For instance, SIG_HI is used to monitor files that are critical aspects of a system's overall vulnerability, including binaries devoted to kernel modification, IP and routing commands, and a host of other applications. Another good one to pay attention to is SEC_LOG, which notes ownership permissions, inodes, and other attributes. Files watched by this parameter will not trip the alarm if their file sizes change, as log files often do.

The best way to learn the syntax of the Tripwire policy file is by modifying an existing config file. We won't go into much detail hereTripwire is powerful and complex enough that a complete explanation of effective Tripwire policies deserves a book of its ownbut we will go through one simple modification.

Since this file is based on a default Red Hat installation, YaST would not be protected if we were to install it on a SUSE box. Let's make some minor changes to the twpol.txt file to fix that:

 #protect the yast binaries ( rulename = "Watch Yast Binaries" severity = $(SIG_CRIT) ) { /sbin/yast   -> $ (SEC_CRIT) ; /sbin/yast2   -> $ (SEC_CRIT) ; /sbin/zast        -> $ (SEC_CRIT) ; /sbin/zast2       -> $ (SEC_CRIT) ; } 

This is a very simple rule that doesn't take advantage of even a quarter of Tripwire's customization features. In this case, the entries between the opening parentheses define the name of the rule and its severity. The parentheses are followed by a list of binaries to check, enclosed within curly braces.

As you can imagine, creating a perfect Tripwire policy will take some trial and error. You'll need to take into account every application that you have installed and make sure that they're being adequately monitored. Start with the sample policy, and begin adding and modifying from there. It will take a few runs, but sooner or later you'll end up with a perfect policy for your system. For more information on generating a strong policy and a full explanation of the features, consult the man page for Tripwire and the official open source Tripwire documentation at http://sourceforge.net/project/shownotes.php?release_id=18142.

7.5.4. Preparing Tripwire for Use

Once you have Tripwire configured, you need to perform a couple of steps before you can run it. To begin, cd to /etc/tripwire and run the Tripwire installation script:

 # ./twinstall.sh 

Once you've done this, you'll need to accept the license agreement by typing accept at the prompt. After you've accepted the license terms, you'll then move on to generating the site and local keys. These are keys that Tripwire uses to sign your configuration files, policies, and the filesystem database. Be sure to use good, strong keys for this:

 ---------------------------------------------- Creating key files… (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the site keyfile passphrase: Verify the site keyfile passphrase: Generating key (this may take several minutes)…Key generation complete. 

Once the key files have been generated, you'll have to enter your site and local passphrases again so that Tripwire can sign your configuration files. Using your unique passphrase to generate a key to sign the important application files ensures that no one will be able to replace your configuration files with doctored ones that might ignore suspicious activity. Signing them also keeps them from being read in plain text.

Once everything is installed, the next step is to initialize your Tripwire database. Do this by running the following command:

 # /usr/sbin/tripwire init 

When you do this for the first time, you're likely to get a lot of errors. This is OK; you'll just need to note what errors come up and fix them in the policy file. It might take several minutes to fully initialize your Tripwire database, so don't worry if you think it's taking too long.

7.5.5. Running Your First Filesystem Integrity Check

Once the database has been initialized, you'll want to run your first integrity check:

 # /usr/sbin/tripwire check 

Again, this will take a few minutes, but when it's done you can examine the report that it generates on stdout for changes that have occurred within your filesystem.

Once you've done that, there's not much to do but fine-tune your policy file and add Tripwire to cron to run as often as you want. To add Tripwire to root's list of nightly cron jobs, run the following command as root:

 # crontab -e 

This will open root's crontab file in your default text editor. Add the following line, substituting the appropriate path:

 0 1 * * * /path/to/tripwire -check 

This will schedule Tripwire to run every night at 1 A.M. Running Tripwire once per night is usually sufficient (especially because, depending on the complexity of your Tripwire configuration file, it can take a long time to run).

As you make changes to your twpolicy.txt and twcfg.txt files, you'll need to use the twadmin tool to re-encrypt them with your passphrase. To recreate your policy, use the following syntax:

 # /usr/sbin/twadmin create-polfile S site.key /etc/tripwire/twpol.txt 

7.5.6. TripWire Tips

You should follow a few simple policies and procedures in order to keep your Tripwire installation secure. First, don't leave the twpol.txt and twcfg.txt files that you used to generate your Tripwire database on your hard drive. Instead, store them somewhere off the server. If your system's security is compromised, as long as these files aren't available the intruder will not be able to view them to identify any unmonitored parts of your filesystem. Second, it's a good idea to change the Tripwire configuration and policy files so that your database is stored on some form of read-only media, such as a CD. This prevents anyone from being able to recreate your database with modifications, thus hiding root-kits or other malware. And finally, don't wait until your machine has been exposed to the Internet to install and configure Tripwire. It will serve you best when it's been installed on a clean machine and is able to begin keeping track of your filesystem from a fresh install. This way, you can be assured that you're not monitoring a system that has already been compromised.

While it might seem at first that Tripwire is too overwhelming to bother with, this is not actually the case. The policy file is good at scaring people off, and the default settings and initial setup can generate a lot of noise and strange error messages. However, with a little bit of work and some exploration of your own filesystem, you can learn quite a bit about how your system operates while you configure Tripwire. In addition, Tripwire has many uses outside the security realm. For example, you can use Tripwire to ensure that an application uninstalls all of its components or to identify all the changes made when you install an RPM. The possible uses for Tripwire are endless, and after you've mastered it, it can be an incredibly powerful tool for monitoring and maintaining your systems.

Brian Warshawsky