Configuring Tripwire

In order to use Tripwire, you must configure it much as you do many other programs. The most conventional part of this process is setting Tripwire options in its configuration file and in the policy Hie. The configuration file lists ancillary programs, additional configuration file locations, and the like. The policy file lists files and directories that Tripwire is to check and lists the methods Tripwire is to use to check these files and directories. After you've set up the Tripwire policy file, you must initialize the Tripwire database. Subsequent runs of Tripwire can check the installed files or update the database.

Tip Ideally, you should install and configure Tripwire after setting up the Linux system but before connecting it to a network. This practice will ensure that Tripwire's initial check of your system reflects a computer that has not been compromised. If you delay configuring Tripwire, it could record an already-compromised system as its baseline, thereby making it worthless.

Tripwire Packages and Configuration Files

Unfortunately, not all Linux distributions ship with Tripwire. As I write, the current version of Tripwire is 2.3-47. Debian, Mandrake, and Red Hat all ship with recent versions of the program or make them available in a reasonable way. (For Debian, you must install it from the Non-U.S. package group.) SuSE makes an old 1.2 version of the program available, but this version doesn't support encryption, and its configuration file format is substantially different than described in this chapter. Slackware doesn't ship with Tripwire at all. For both SuSE and Slackware, I recommend that you download a Tripwire package from the main Tripwire website ( The RPM package works well for SuSE.

Most modern Tripwire installations place configuration files in /etc/tripwire. You're likely to find at least two files here initially: twcfg.txt and twpol.txt. These files are unencrypted versions of the main configuration file and the policy file, respectively. Subsequent configuration steps create files called tw.cfg and tw.pol from these plain-text files. Tripwire will use these encrypted files in operation.

Most Tripwire RPMs include a file called in the/etc/tripwire directory. The binary tarball available on the Tripwire website includes a similar file called Whatever the name, this file is a shell script that runs through many one-time configuration requirements. Its use is described in the next section, "Setting Tripwire Options." Instead of providing this file explicitly, Debian's Tripwire package runs a custom Tripwire configuration script when you install the package.

Setting Tripwire Options

You may need to edit one or both of two Tripwire configuration files. The first, which is usually called twcfg.txt, sets global configuration options, such as the location of the database file and various defaults. Chances are you don't need to edit this file, but you may want to look at it to verify that its options are reasonable. Some options you may want to modify or add include GLOBALEMAIL, a list of e-mail addresses to which reports should be sent; MAILNOVIOLATIONS, whether or not to send e-mail reports if no security problems are found; and EDITOR, the complete path and filename of the text editor you want Tripwire to use for certain operations.

The second Tripwire configuration file is usually called twpol.txt. This configuration file defines the files and directories that Tripwire should monitor, and which features of these files and directories it should use to do this monitoring. The Tripwire policy file format may seem confusing at first. At its core, this file consists of a handful of major elements. Most lines define directories that Tripwire is to scan, and have the following format:

The optional exclamation mark (!) symbol represents a stop point—if present, Tripwire stops scanning a directory tree at this point. For instance, you might want to tell Tripwire to scan /usr/local but to ignore /usr/local/fonts. You'd create an entry for /usr/local and another, preceded by an exclamation mark, for/usr/local/fonts.

The object-name is the name of the file or directory you want to be scanned. You can also use a variable, as described shortly, to stand in for a directory name.

The select-flags are methods of specifying what sorts of tests you want performed on a file or directory. The select-flags take the form of a plus sign (+) or minus sign (-) followed by one or more of the codes specified in Table 21.1. For instance, you might specify +tpug to check the file type, permissions, UID, and GID. Using a plus sign means to check the feature, and a minus sign indicates that the specified feature is not to be checked. The lowercase options are all quick and easy to check; information for these checks is accessible in the files' inodes, so the file itself doesn't need to be accessed. The uppercase options perform various types of checksums, which require reading the entire contents of the file. These checks, therefore, take much longer to perform, particularly on large files. Such tests are appropriate for the most critical configuration and executable files, but you might want to forgo them for many ordinary executables.

Table 21.1: Tripwire Flags for Checking Files and Directories




Last access time stamp


File size in blocks


Create/modify time stamp


Disk device number on which the inode resides


Group ID (GID) of file


Inode number


Modification time stamp


Inode reference count


File permissions




Device number


File size in bytes


File type (ordinary file, directory, etc.)


User ID (UID) of file


File is increasing in size


Cyclic Redundancy Check (CRC) 32-bit hash


Message Digest 5 (MD5) hash


Secure Hash Algorithm (SHA) hash


Haval signature

You can optionally include attributes within parentheses after the select-flags. For instance, recurse=false causes scanning of a directory but not its subdirectories, and rulename=/7ame sets a name for the rule, which can help you identify it in Tripwire's reports.

Although many lines define how Tripwire is to handle directories and files, other lines perform other functions. These other lines include:

Comments Lines beginning with hash marks (#) are comments and are ignored. Comments can also appear after an otherwise valid entry on one line.

Directives These are keywords preceded by a pair of at signs (@), as in @@section to define a section of the policy file or @@ifhost to test whether Tripwire is running on a particular host. (You might use the latter to create one policy file that you can move easily across several hosts.)

Variable Definitions You can assign and use variables much as you do in a shell script. One difference is that variables are enclosed in parentheses when used. Tripwire variable definitions also end in a semicolon (;) character. For instance, some default scripts use a line reading SECJNVARIANT = +tpug ; to set a variable, and then refer to $(SEC_INVARIANT) later in the file. Some variables are preset to reasonable flag values for particular directory types. Specifically, $lgnoreNone tests everything, $ReadOnly is good for read-only files and directories, $Dynamic works well for configuration files that are accessed often, and $Growing is good for files such as log files that grow in size.

Preceding Attribute Rules You can define attributes in parentheses before a group of Tripwire rules, which are then enclosed in curly braces ({}). This approach can help you to define common attributes for a set of directories.

As an example of a Tripwire policy file, consider Listing 21.1. This file is a simple configuration that uses many of the features just described. A variable is defined on the first line ($TWBIN), and it is used in a set of rules given the name Tripwire Binaries using a preceding attribute section. Following this section, several rules define checks for specific directories—/usr/bin and /etc.

Listing 21.1: Sample Tripwire Policy File TWBIN = /usr/sbin ;

# Tripwire binaries

rulename = "Tripwire Binaries",

/usr/bin -> $(ReadOnly) ; /etc -> $(Dynamic) ;

In practice, your Tripwire policy file is likely to be much longer and more complex than Listing 21.1. Most Tripwire packages ship with a sample policy file that's several hundred lines long, if not over a thousand lines. These lines specify the files and directories that Tripwire is to monitor in excruciating detail. You should back up this file, then go through it carefully. Remove references to files and directories that don't exist on your system. If you've added important packages that aren't reflected in the default file, create entries for them. You may want to do so by copying an existing entry set and modifying it to fit the new package's needs. Tripwire notifies you of files that are specified in the policy file but that don't exist on the system when you initialize the database, so you may end up revising this information after you initialize the database for the first time.

Tip Don't delete lines from the policy file; instead, comment them out by adding a hash mark to the start of the line. This practice enables you to easily add a line back should the need arise in the future. Warning The unencrypted versions of both the configuration and the policy file could conceivably be useful to an intruder. For instance, the policy file could tell the intruder which directories and files are monitored, so an intruder could try hiding extra programs in unprotected directories. For this reason, after you convert these files to their encrypted formats, you should move the originals to a removable disk and delete them from the hard disk.

Initializing the Database

If your Tripwire installation didn't run its setup script when you installed the system, run it now. (This script is often called /etc/tripwire/ The script will ask for two passphrases, which are like passwords but are frequently longer. Create these passphrases carefully and protect them, as described in Chapter 18. The script will then ask for the site passphrase twice, as it creates encrypted versions of the configuration and policy files from your clear-text versions. If the script reports that it's failed, check the error messages. Chances are they'll report a bad line in the original configuration or policy file. For instance, you might have mistyped a variable name or specified an invalid flag. Correct the error and try again. (Subsequent runs of won't require you to generate new passphrases, but you will have to enter the passphrases you created initially.)

If your Tripwire installation doesn't include a script, you can create encrypted configuration and policy files by using twadmin, as described in the upcoming section, "Modifying the Tripwire Configuration." Before you do this, though, you must manually create key files. Type twadmin -generate-keys -S /etc/tripwire/site.key to generate the site key. Use the same command, but substitute

-L hostname-\oca\.key, where hostname is your hostname, for-S site.key, to generate the local key file. These filenames are referenced as SITEKEYFILE and LOCALKEYFILE in twcfg.txt, so check there if you're in doubt about the filenames.

Once you've finished initializing these configuration files, you can proceed to initializing the database. You do this by typing tripwire —init. The program will ask for your local passphrase. After you enter it, Tripwire will scan the directories specified in the policy file and generate the encrypted database file. This process can take a long time, particularly if you've configured Tripwire to perform MD5 sum scans or similar hashes on directories that contain very many or very large files. Even the minimal Listing 21.1 may take several seconds to initialize. Be patient. When it's finished, with any luck the system will respond that it has generated a database file. It will also report on files specified in the policy file but not found on the system. You may want to remove references to these files, re-create the encrypted policy file, and reinitialize the database to be rid of these notifications.

0 0

Post a comment