Tripwire: a sample policy file

Tripwire has become a standard in Linux security. In this Daily Drill Down, Jim McIntyre walks you through the critical process of setting up and configuring the Tripwire detection system.

Sometimes hackers just can't be stopped. When a hacker accesses your network undetected, you want the ability to detect any changes made to your file system. Tripwire provides the system administrator with that ability. When you are planning your system security policy, Tripwire should be the first tool installed on your system. This Daily Drill Down will provide system administrators with a systematic process for installing and configuring Tripwire on a Linux system. The steps involved are:

1. Obtaining the latest version of Tripwire.
2. Building the Tripwire configuration file.
3. Compiling the encrypted configuration file.
4. Editing the Tripwire policy file.
5. Compiling the encrypted policy file.
6. Securing the Tripwire database.
7. Installing Tripwire on a Linux system.
8. Establishing the local and site passphrases.

How Tripwire works
Tripwire uses the following procedures to protect the filesystem:

• The first time Tripwire is run after installation, it is run ininitialization mode.
• When run in initialization mode, Tripwire reads a policy file, which contains information about the files and directories Tripwire will monitor and the types of information to read from these files and directories.
• When the information in these files and directories has been read, Tripwire places the information in a secure database. The secure database is used as a ”snapshot'' of the filesystem.
• The next time Tripwire is run, it is run in compare mode.
• When run in compare mode, Tripwire reads the secure database created in the initialization mode and compares this information to the present state of the filesystem. Any changes made to the files Tripwire is monitoring will trigger a warning message to the administrator.
• If the changes are the result of a system intrusion, the administrator will have to change the files with versions that may be trusted.
• If the changes are the result of authorized activity, Tripwire is run inupdate mode.
• When run in update mode, Tripwire updates the secure databaseof filesystem information.
• Updating the database prevents Tripwire from reporting authorizedchanges to the filesystem as intrusions.

Step one: Obtaining Tripwire
Whenever security-related software is being installed, the best practice is to use the "latest and greatest" version. For this Daily Drill Down, we will use tripwire_2.2.1_for_linux.x86.tar.gz, which is available at the official Tripwire site. This ensures the latest patches to the program itself have been applied.

Once Tripwire has been downloaded, the first step is to uncompress and untar the file with the command:
tar -zxvf tripwire_2.2.1_for_Linux_x86.tar.gz

Table 1 lists the files that will be extracted from this file:

Table 1

File	Function
Install.cfg	A Bourne shell script used by the Tripwire installation to set configuration variables.
install.sh	The shell script used to install Tripwire. This file may use defaults values, or a customized installation may be specified in this file.
License.txt	The license for Tripwire. This license must be accepted to install Tripwire.
/pkg	This directory contains several files required to install Tripwire.

Contents of tripwire_221_for_linux_tar.gz

If a customized installation of Tripwire is required, any of the values in the install.cfg file may be edited.
Now that Tripwire is extracted, the next task is to build the Tripwire configuration file.

Step two: Building the Tripwire configuration file
The Tripwire installation script uses the install.cfg file to create the following two files:

• twcfg.txt
• tw.cfg

Twcfg.txt is a text file used by the install.sh shell script. The Tripwire installation process will create a default tw.cfg file for you. If you have used the defaults in the install.cfg file, the tw.cfg and twcfg.txt file will be located in /usr/TSS/bin. Run the following command as root to view the twcfg.txt file:
cd /usr/TSS/bin
cat twcfg.txt

Example 1 shows the output from these commands.

Example 1

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

The default Tripwire configuration file

This file is used to set values for the following parameters:

• The root directory of the Tripwire program
• The locations of the policy file, the Tripwire database file, the Tripwire report file, and the local key and site key files

These values must be set in the twcfg.txt before a valid configuration may be compiled. Other functions listed in twcfg.txt that are not mandatory to compile the configuration file but are still important are:

• EDITOR—Used to set the path for the default editor on your system.
• LATEPROMPTING—Delays the prompt for the passphrase. This reduces the amount of time that the passphrase is present is memory. The default is false. This value should be set to true.
• LOOSEDIRECTORYCHECKING—This feature allows Tripwire to check for any properties of a directory that change when a file is added or deleted. Setting this value to true turns Loose Directory Checking on.
• MAILNOVIOLATIONS—Report messages will be mailed if no violations occurred. The default setting is true. The recommended setting is false. This allows the administrator to be assured when a scheduled Tripwire executes correctly.
• EMAILREPORTLEVELŸUsed to set the report level used by the command –check –email-report.  This level may be set from zero to four.
• REPORTLEVELŸUsed to set the default report level for the twprint –print-report mode. The default report level is three. This level may be set from zero to four.
• MAILMETHOD—Used to set the system's mail protocol. The only valid values for this variable are SMTP or SENDMAIL.
• SYSLOGREPORTING—Used to send information about integrity checks, Tripwire database and policy updates, and Tripwire initialization to the system logger daemon.
• MAILPROGRAM—Specifies the mail program used to send e-mail reports from Tripwire integrity checks.

Step three: Compiling the encrypted configuration file
After the settings for your system have been entered in the twcfg.txt file, the next step is to compile the tw.cfg file and to sign the compiled configuration file. This is accomplished with the command:
./twadmin--create-cfgfile --site-keyfile ../key/site.key twcfg.txt

Once the configuration file is compiled, delete the text version using the command:
rm ../twcfg.txt

Once the tw.cfg file has been compiled, the next step is to edit the Tripwire policy file.

Step four: Editing the Tripwire policy file
The policy file is used to establish which files and directories Tripwire will monitor, which properties of those files will be monitored, and what action to take if there is a violation of a rule. When Tripwire is installed, the default policy file, twpol.txt, is created in /usr/TSS/policy. This file is used to compile the policy file Tripwire will use when monitoring your system.

Tripwire refers to files and directories as system objects. Every system object has the following characteristics shown in Table 2:

Table 2

Characteristic	Function
Object name	Used to identify the object, e.g., /etc/hosts/allow
Property	A single characteristic of an object that Tripwire will monitor, e.g., file size
Rule	A set of properties to be monitored against a specific object
Directives	Used to control sets of rules in a policy file

Tripwire system object properties

Object properties
Object properties determine which characteristics of files or directories are monitored by Tripwire. Theobject properties in Table 3 may be monitored by Tripwire:

Table 3

Identifier	Function
a	access timestamp
c	inode change timestamp
g	Group Identifier (GID)
i	inode number
m	modification timestamp
n	link count
p	file permissions and file type
u	User Identifier (UID)
s	file size

Object properties used by Tripwire

Property masks
A property mask determines which object properties are ignored or monitored by Tripwire. A property mask may be used to monitor or ignore any of the object properties listed above. The following rules must be followed when establishing a property mask:

• An empty property mask may not be used. The property mask must contain one or more property characters.
• When property values are used in a property mask without the + or – sign, the plus sign (+) is assumed. This rule makes the three following rules equivalent:

1. 1. +p+n+s; #—Compares file permissions, number of links, and file size.
2. 2. +pns; #—Establishes the same mask as above.
3. 3. pns #—Without a plus (+), or minus (-), the plus sign is assumed.

The mask # establishes the same monitoring criteria as the first mask.

• The plus sign (+) enables monitoring for a property, the minus sign (-) disables monitoring.
• Not specifying a property in the property mask is the same as using the minus (-) sign.
• When a plus or minus sign appears in a property mask, it is in effect until the next plus or minus sign appears in the same mask.
• When two properties in the same mask contradict each other, only the last property is acted upon by Tripwire.
• A property mask may be used with no properties enabled. This type of mask is often used to monitor the deletion or addition of files to the system.

In the above list of object properties, lowercase letters represent attributes applied to files. Several attributes may be applied to a fingerprint by preceding the group of attributes with a + symbol. An example of grouped attributes would be:
/etc/passwd   +aipm

This group of attributes would make Tripwire monitor the /etc/passwd file for any changes to the access timestamp, the inode number, the file permissions, or the modification timestamp.

If a group of attributes is preceded by the minus (-) sign, the attributes following the - symbol are ignored for the specified file. An example of this would be:
/etc/pam.d/passwd    -gns

This group of attributes would make Tripwire ignore any changes made to the Group Identifier (GID), the link count, and the file size of the /etc/pam.d/passwd file.

Using templates with Tripwire
Table 4 shows the available templates that are used to apply a default selection mask to a file or group of files or directories.

Table 4

Template	Function
+mask	The properties following the + sign are to be monitored for the file or directory.
-mask	The properties following the - sign are to be ignored for the specified file or directory.
R	Used with read-only files (+pingsum12-ac34546789)
L	Used with log files (+pinug-sacm123456789)
N	+pinugsamc123456789 Template is used to ignore nothing.
E	-pinugsamc123456789 Template is used to ignore everything.
>	Used for files that will increase in size. An alarm is tripped when the file size is smaller than it previously was.

Templates available to Tripwire

The > character may also be used by Tripwire to monitor log files. When this operator is used, Tripwire will monitor the specified log file for decreases in size, and Tripwire will ignore increases. Because log files are constantly being written to, they should never decrease in size.

A decrease in the size of a log file is a good indicator of a hacker trying to cover his tracks.

The default Tripwire configuration is tw.config.

Establishing rules for Tripwire
Tripwire uses rules contained in the policy file to determine how a file or directory will be monitored. There are two type of rules used with Tripwire: normal rules and stop points.

Normal rules
Normal rules are used to define which property or properties of a particular file or directory are monitored by Tripwire. Normal rules use the following syntax:
Object-name -> property-mask;

The following characteristics apply to all Tripwire policy rules:

• The object name is the fully qualified path to a directory or file.
• The -> character is used to separate the object name and the property mask.
• A space must precede the -> character.
• The line must be terminated with a semicolon (;).
• If the pathname refers to a directory, the directory and all of its subdirectories will be monitored by Tripwire.
• If the pathname refers to a file, the file will be monitored only for changes to properties contained in the property mask.
• Tripwire will not monitor any file that has more than one rule listed in the policy file.

Stop points
Stop points are used to exclude specific files or directories from monitoring by Tripwire. The correct syntax for a stop point is:
! object ;

An example of a stop point would be:
/etc $(ReadOnly) –ar;
!/etc/rc.d ;
!/etc/sysconfig ;

This stop point would prevent Tripwire from monitoring the /etc/sysconfig and /etc/ subdirectories.

Using attributes with Tripwire rules
Rule attributes are used to provide additional actions for Tripwire to perform when a rule is broken. Rule attributes use the syntax:
(attribute-name = attribute-value)

Extending the Tripwire policy file
The Tripwire policy file supports the use of syntax, which allows the policy to be extended. Some situations where this syntax is useful include:

• Using a policy across several servers.
• Customizing templates.
• Using conditional statements to match the Tripwire policy to the operating environment.

Table 5

Argument	Function
@@ifhost hostname	The output of uname –n or the hostname command must match the hostname used in this statement. If the hostname  Statement and before the next @@endif or @@else statement are executed.
@@ifnhost hostname	Same as the argument, except that the hostname must NOT match the hostname used in this argument.
@@ifdef variable-name	This argument is true if the variable is defined.
@@Ifndef variable-name	This argument is true if the variable is NOT defined.
@@else	This argument is used in conjunction with the four previous arguments.
@@endif	Used to close the preceding @@if statement.
@@define variable-string	Used to assign a string to a variable. If now string argument is used, the null string is assigned.
@@undef variable-name	Unassigns the named variable.
@@include pathname	Used to include the file specified in pathname into the policy file. Both files must use syntax readable by Tripwire.
@@variable	Used to make Tripwire perform an action when the named variable is encountered.
@@{variable-name}	Same as the previous syntax; normally used in conjunction with other strings.
||	Logical OR statement
&&	Logical AND statement
##	Used to indicate comments.

Arguments used with Tripwire

We've covered a lot of ground so before we go any further, let's take a look at a Tripwire policy file and at how the configuration options are employed to provide filesystem integrity.

Fingerprinting files with Tripwire
The most important question for the administrator to ask is Which files do I fingerprint with Tripwire? The point to remember when using Tripwire is to capture information on any file or directory that could cause administrative problems or worse, system downtime, if compromised. This is a big task on even the simplest network, so here are some guidelines to use when you set your Tripwire policy:

• Protect all system binaries, especially those in /sbin and /lib.
• Protect all system log files in /var/log. The first goal of a good hacker is to hide his activities.
• Protect all security tolls, along with their associated binaries, configuration files, and libraries.
• Protect all system configuration files contained in /etc and its subdirectories.

Establishing the Tripwire policy
Which files are critical will depend on your own networking environment. Assess this environment to determine your requirements. Here are some points to remember when establishing templates for Tripwire:

• If a file is most often used as read-only, try the R template, and add or remove attributes from it as necessary.
• If a file has information written to it frequently and its size increases regularly, try the mask +pinug>-samc0123456789.
• If a file has information written to it frequently and its size is unpredictable, try the mask: +pinug-samc0123456789.
• If you can't decide on a policy, use the R template and modify it as required.
• Tripwire will let you know when changes are required to the policy, based on the large amount of information it will generate.

Example 2 shows a typical Tripwire policy file for a Red Hat Linux system, although the file is abbreviated for this Daily Drill Down.
## Tripwire policy file
## First, define the templates used for this policy. This is the template for binary files
@@define BIN E+pnugsci17
## the @@define statement above will establish the template BIN. The BIN template will
## monitor binary files for file permissions, link count, user ID, group ID, and file size. Binary ##files will then be hashed using the MD5, and the SHA1 algorithms.
##The next template will be used to monitor read-only files.
@@define READ E+pingsum17
##this template will use the default READ template, but will include monitoring for the file permission, inode number, link count, file size, User ID, and the modification timestamp. This template will then hash the affected files using the MD5 and the SHA1 algorithms.

##Now, we will define a template for log files
@@define LOGS E+pugn
##this template will monitor log files for file permissions, User ID, Group ID, and link count.
##The next template will be the default template applied to directories.

@@define DIR E+pnugi
##This template will monitor directories for file permissions, link count, user ID, Group ID, and inode number.

##This is a template used to monitor configuration files.
@@define CONFIG E+pinugc
##This template will monitor configuration files with the Ignore Everything template, but will
##monitor configuration files for file permissions, inode number, link count, user ID, Group ID, and changes to the inode number.

##The last template we will establish is the DEV template, used to protect device files.

@@define DEV          E+pnugsci

##Now, we select the files and directories for Tripwire to monitor, and apply a specific template.
##First, establish which template will be used against the root directory (/).
##The (=) sign tells Tripwire not to monitor this directory recursively. Otherwise, Tripwire
##would scan every file and directory on the system. We will use the DIR template to monitor ##the root directory
=/      @@DIR

##All of the directories in this group will be monitored using the DIR template
=/tmp @@DIR
=/mnt @@DIR
=/mnt/floppy @@DIR
=/ @@DIR
##The ROOT user's home directory won't change much, so we use the READ template here.
/root   @@READ

##Next, protect the kernel and other resources used when the system boots. We will use the READ template for this
/boot  @@READ

##Now, we capture the information we need from configuration files and directories.
/etc                            @@CONFIG
/etc/mtab                   @@LOGS
/etc/passwd                @@LOGS
/etc/shadow                @@LOGS
/etc/inetd.conf @@READ
/etc/rc.d                     @@READ
/etc/pam.d                  @@READ       
/etc/ftpusers               @@READ
/etc/hosts                   @@READ
/etc/hosts.allow          @@READ
/etc/hosts/deny           @@READ       

##The /home directory is always changing, so we can use the READ template for the root ##of the directory only.
=/home                      @@READ

##the LOGS template will be used for the /var directory.

=/var/spool                 @@LOGS
/var/log                       @@LOGS
/var/spool/cron            @@LOGS
/var/spool/mqueue       @@LOGS
/var/spool/mail            @@LOGS

##Next, we use the READ template to protect binary files
/sbin                          @@READ       
/bin                            @@READ
/usr                            @@READ
/lib                             @@READ
Step five: Compiling the Tripwire policy file
Once you’ve established the templates for Tripwire and applied these templates to the appropriate files and directories, the next step is to compile the Tripwire policy file. Remember, the policy file you create is simply a text file that Tripwire will use to create the encrypted policy file used when system monitoring begins. The command to compile the Tripwire policy file is:
./twadmin –create-profile ../policy/twpol.txt

Once the policy file is compiled, delete the text version using the command:
Rm ../policy/twpol.txt

Depending on the speed of your system, and especially the size of your filesystem, this might take several minutes.

Step six: Secure the Tripwire database
There is one simple rule to follow to secure the Tripwire database: Don't leave the Tripwire database on your system!!!

As long as the database is stored on offline media, a hacker can't change the database to cover his activity on your system.

When the database has been created, copy it to an offline storage device, preferably a CD or a floppy, and remove the local copy from your system. This ensures that a hacker will not be able to alter the database if your system is compromised. When the database is secured, remove the local copy with the command:
rm /usr/TSS/db/(hostname.twd)

where hostname is replaced with the hostname for your system. Once you have completed that step, Tripwire is installed and running on your system.

Step seven: Installing Tripwire
At this point, the following steps should have been completed on your system:

• Tripwire has been downloaded and extracted on your system.
• The Tripwire configuration and policy files have been edited to meet your system requirements.
• Binary versions of these files have been compiled from the default text versions.
• The original text versions of these files have been removed from your system, avoiding an easy security compromise.

The next step is to run the Tripwire installation program. To install Tripwire, run the following command as root:
./install.sh

When this command is run, the install.sh script reads the install.cfg file, and Tripwire is installed according to the values set in the install.cfg file.
The most effective use of Tripwire is to install the program immediately after the operating system itself has been installed, and before the server is placed in a production environment. This ensures that system files are being monitored by Tripwire before any access to the system is possible.
Step eight: Establish the Tripwire passphrases
During the installation process, you will be prompted to supply two passphrases: the site passphrase and the local passphrase. Passphrases are used to remove encryption from files. The site passphrase is used to remove encryption from the site key. The site key is used to provide encryption for the Tripwire configuration and policy files. These files may be shared among several servers on a network or site.

The local key is used to remove encryption from Tripwire database files. Tripwire report files are also signed with the local key.

Using two passphrases means that if a hacker gains access to the local key on one server, he is not automatically granted access to other servers on the network.

The Tripwire passphrases should be given the same importance as the root password. The following procedures should be used when choosing passphrases:

• Use a combination of at least eight alphanumeric and symbolic characters for each passphrase.
• Assign a separate passphrase for both the site and local passphrase.
• Make sure that all phrases are kept in a secure location. Tripwire cannot restore a lost passphrase, and it is not possible to remove encryption from a signed file without the passphrase.
• If the passphrase is lost, the entire database must be reinitialized.

Conclusion
This Daily Drill Down has introduced Tripwire. We have covered the installation process, editing the configuration and policy files, and establishing templates to provide Tripwire coverage for specific areas of the Linux filesystem. We also discussed the process for creating the initial Tripwire database and looked at ways of securing the database. The next Daily Drill Down in this series will discuss procedures involved in running Tripwire on a production Linux server, and we will examine other uses for this very flexible program.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.