Who's Got Root? Installing and Configuring Tripwire

By Carla Schroder | Dec 31, 2002 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/1562771/Whos-Got-Root-Installing-and-Configuring-Tripwire.htm

In a previous article we introduced you to Tripwire, a very useful security tool for your network installation. In this article, we'll move to the specifics of installing and configuring Tripwire -- and more specifically, we'll tell you how to install it a sensible policy file, which is really the heart of Tripwire.

This article is based on the free version of Tripwire for Linux. Some differences between the free and commercial versions: The commercial version has more features, runs on many platforms, and comes with support. The free Tripwire conforms to the Filesystem Hierarchy Standard (FHS), the commercial one does not. There are good management tools available only in the commercial editions, and those running any highly critical applications should consider using the commercial Tripwire.

Both source tarballs and RPMs are available. It's best to build from source. This must go on a guaranteed clean system to do any good -- start from a clean system installation, before connecting to any network. Be sure to verify checksums and read INSTALL, README, and the release notes. The current version is 2.3.1.

The source files should go in /usr/src/tripwire-2.3.1, so unpack the tarball there. As there are some potential pitfalls right off the bat, we'll cover installation in some detail.

Review /install/install.cfg to make sure installation options are suitable. The default file locations should be fine, but you'll want to pay attention to the Mail Options section and edit it to use the correct MTA for mailing reports. Two methods are described: using a local MTA (for a local user or group) or specifying an SMTP server and port. Use the second option when the mail server is a remote machine or you're sending messages to a remote location. Comment out the one not used.

Next, review the Makefile, located in /src. The SYSPRE variable in the Configuration Section must be set for your architecture. The default is SYSPRE = i686-pc-linux. Simply choose from the available selections, and uncomment the correct one. When that's done, run:

# make release

and go have a nice healthy walk outside, as the build will take a few minutes. This will build all four Tripwire binaries: siggen, tripwire, twadmin, and twprint. There are also options for building them separately. If you get a gmake: command not found error, fret not, as the fix is simple. The makefile explicitly looks for gmake, so create a soft link to make:

# ln -s /usr/bin/make /usr/bin/gmake

Once install.cfg is to your liking, copy it and install.sh to the top of the Tripwire source tree, /usr/src/tripwire-2.3.1. Run the installation script:

# ./install.sh

During installation you cannot go out for another healthy walk, as input is needed. Two passwords are set:

  • the site keyfile
  • local keyfile

Tripwire uses El Gamal asymmetric cryptography and key pairs. Keys are generated after setting passwords. Remember your passwords -- there is no way to retrieve them if they are lost. The site keyfile protects configuration and policy files, which can be used sitewide. The local keyfile protects Tripwire databases and reports; this structure enables the boss admin to control the important parts while delegating the mundane chores. Tripwire files can be read by anyone with access to the public key, but only elite individuals with passwords can use the private key to edit files.

Config files exist in two versions: plain text, and encrypted, and are stored in /etc/tripwire. Open the sample policy file, twpol.txt, and have a look. It is designed around a Red Hat 7.0 installation that may or may not look like yours, so don't use the defaults! At this point you can edit and use the sample file or create a totally new one. We'll get to how to do that in a minute. Once the text policy file is edited, run:

# twadmin --create-polfile twpol.txt

Changes can also be made to twcfg.txt if necessary. Then reencrypt it:

# twadmin --create-cfgfile --site-keyfile sitekey twpol.txt

twadmin compiles text files into the the binary files used by Tripwire. The text files can be named anything. Never leave these text files on your system -- delete them after making changes. Keep copies, or they can be recreated from the encrypted files:

# twadmin --print-cfgfile > filename.txt

Obviously, leaving twadmin and twprint on the system isn't a good idea, either. Next, you'll create your baseline data using the following command line:

# tripwire --init

Use init only once, when the baseline database is first created. When updates are needed, edit the policy file and then run:

# tripwire --update-policy twpol.txt
# twadmin --create-cfgfile --site-keyfile sitekey twpol.txt

Once the policy file is set up, an integrity check can be run. We'll get to that in a minute.

Page 2: Rulesets

Rulesets
At last we come to the heart of Tripwire: the rulesets that go in the policy file. twpol.txt and policyguide.txt are good models to study. The basic syntax is:

objectname -> property mask;

Objectname is a file or directory name. If a directory is specified, everything in the directory will be scanned and the property mask applied to everything. If it's a file, then the rule will apply only to that file. Tripwire provides rules and tools to create as many variations on these basic themes as needed. For a complete reference, download the User's Guide from the Tripwire Project page (see Resources); look for 2.3.0-docs-pdf, or 2.3.0-docs-src.

Here are some samples:

/usr/sbin -> $(ReadOnly) ; # defines everything in /usr/bin
!/usr/bin/dictd            # do not scan this file
/var/log/tuxracer_scores -> $(Growing)            # this file should grow
/dev -> $(Device)          # devices and other files whose attributes, not contents, should be scanned
/. -> $(IgnoreAll)         # check only if this file exists

These are canned property mask variables are supplied to handle common needs. Finer tuning can be done with more precise attributes. These are preceded with + (to turn on a property) or - (to turn it off). The equivalent of ReadOnly is +pinugtsdbmCM-rlacSH. +pinug is commonly used, it means file permissions, inode number, inode reference count, user ID, and group ID.

Property masks can be user-defined:

mask1 = +pinug ; 

What to do if a scan reports violations? It undoubtedly will, most likely the result of overstrict rules. There are several options for running an integrity check. This command runs a basic integrity check; results are displayed on the screen, and a binary copy of the report saved to the file location specified in tw.cfg

#tripwire --check 

Run an integrity check, and specify the report file destination:

#tripwire --check --twrfile /filename 

Run an integrity check, and email reports to recipients as specified in tw.pol:

#tripwire --check --email-report

This does a live check, and each violation is listed as it's found, with a checkbox. All are checked by default. Uncheck the items you do not want future alarms for. When you're finished, close the file; Tripwire will ask for your password, and automatically update the database. Use:

# tripwire --twrfile /var/lib/report/reportname.twr

to use a report that has already been generated.

Conclusion
Give yourself a test machine and a couple of weeks to get up to speed. Tripwire is very flexible and powerful. It takes a little experimentation to get a handle on its abilities and to become familiar with the command options. It's an essential utility, the tool of choice to watch the watchers.

Resources
Tripwire, Inc.
Tripwire.org
Filesystem Hierarchy Standard
Tripwire project page


» See All Articles by Columnist Carla Shroder