inside the mind of a linux admin

tripwire intrusion detection


Getting Started with Tripwire (Open Source Linux Edition)

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

Download the source here:

tar xvzf tripwire-2.4.2-src.tar.gz

Note that all Tripwire associated files will be kept in the /usr/local/etc/ directory by default. Binaries will be installed in /usr/local/sbin. If you prefer your files in /sbin and /etc, append –prefix=/ to the configure command below.

make install

Note: If you receive an error during configure such as:

configure:9002: error: C++ preprocessor “/lib/cpp” fails sanity check

This means your system is missing g++ and it’s failing the sanity check. If you’re seeing this error, you’re likely running a debian/ubuntu box. In which case, simply run:

sudo apt-get install g++

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.

During the installation process, be sure you choose secure passphrases for your keyfiles and write them down and store them in a secure location.

The installation script creates default policy and configuration in plain text files stored in /usr/local/etc/ 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 encrypted versions of these are created in the steps below, and stored in /usr/local/etc/ as tw.pol and tw.cfg respectively.

Creating a Custom Policy (advanced)

You’ll want to custom tailor the twpol.txt file to your specific system environment. This allows you to monitor nearly any aspect of a file or directory, depending on the type of file. The types of files and monitoring strictness is defined using pre-defined variables as well as custom flags that you can add or remove per file or directory.

Here’s a list of pre-defined variables followed by their flag definitions:

Device = +pugsdr-intlbamcCMSH ;
Dynamic = +pinugtd-srlbamcCMSH ;
Growing = +pinugtdl-srbamcCMSH ;
IgnoreAll = -pinugtsdrlbamcCMSH ;
IgnoreNone = +pinugtsdrbamcCMSH-l ;
ReadOnly = +pinugtsdbmCM-rlacSH ;
Temporary = +pugt ;

So, for example, If you have a line in your policy file that says:

/etc/rc.d -> $(IgnoreNone) -SHa ;

You are actually telling tripwire to check the files in /etc/rc.d against the $(IgnoreNone) rule set, but exclude the SHa checks:

+pinugtsdrbamcCM-SHa ;

So, what do these actually mean? I thought you’d never ask:

Policy Examples and Demonstration

Installing your custom policy
After making your modifications to the .txt files, the default policy should be installed using the command as root:

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

Now, lets generate the initial database using the following command as root:

/usr/local/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. 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. To generate a listing of the discrepancies between the local system and the default policy, issue the following command as root:

/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, /usr/local/etc/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/local/sbin/twadmin -m P /usr/local/etc/twpol.txt

/usr/local/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 -f /usr/local/etc/twcfg.txt /usr/local/etc/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/local/sbin/twadmin -m p > /usr/local/etc/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 “” in the directory /usr/local/bin that has the following contents:


/usr/local/sbin/tripwire -m c | mail -s “Tripwire Report from $HOSTNAME” root@localhost

Feel free to change root@localhost to any e-mail address. Don’t forget to make the shell script executable by root:

chmod +x /usr/local/bin/

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

1 1 * * * /usr/local/bin/

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.

Resource Usage Optimization

The operations performed by Tripwire by nature are very resource intensive, both for CPU and I/O. The recommendation for nightly tripwire checking/reporting in this article runs at off peak hours (after 01:00). On highly populated machines or when manually regenerating the database this may cause resource issues. To help alleviate this, I recommend prefixing all /usr/local/sbin/tripwire commands with “nice” and “ionice“. This is outlined briefly below:

nice -n 19 ionice -c2 -n7 /usr/local/sbin/tripwire …

For details and more information on using nice and ionice, please see my article at


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.

Thanks to Linux Security, The central voice for Linux and Open Source security news for this very helpful information. Additionally, Yunliang Yu from Duke University has written a HOWTO on implementing this across an entire network. You can read his article here.


1 Comment

  • Grainier on Saturday, January 10, 2015

    Thank you very much. Helped me a lot. Best tutorial found on creating a Custom Policy using Tripwire.

Leave a Reply

Your email address will not be published. Required fields are marked *

Tweeter button Facebook button Myspace button