Tripwire: The next generation

Summary
Recent DoS attacks to major ecommerce sites have highlighted the ever growing challenge of maintaining a secure system. Network intrusion detection systems (IDSs) offer some comfort, but they are far from totally dependable. This month Carole Fennelly profiles Tripwire, which tells systems administrators if their servers' files have changed since the previous day. (2,350 words)

If you have ever discovered a system attack, you know that reloading the system and all its applications would be the first thing to do because you can't identify the files an intruder may have tampered with. Reloading from scratch is tedious and time consuming, and putting a firewall in front of each host on the network still wouldn't guarantee an uncompromised system.

Network intrusion detection systems (IDSs) can monitor and notify you of attacks, but how many IDSs do you really want to manage? An IDS relies on knowing a method of attack, and it can be bypassed if that method were to change with the help of an anti-IDS scanner, such as Whisker by Rain Forest Puppy (see Resources).

A layered, or "onion," approach to security is preferred because no single security mechanism is without its flaws. Previous Unix Insider articles (see Resources) have discussed hardening the host to minimize security exposures; this one covers Tripwire, a method for intrusion detection on a host level.

What is Tripwire?

Tripwire is an integrity assessment software package that maintains a database of file attributes and sends alerts when any of those attributes change. Essentially, it tells you if your servers' files have changed since the previous day. Because it works on the host level, it should be integrated with other security mechanisms such as firewalls and network intrusion detection. While Tripwire's primary purpose is to provide security, it provides the administrator with some source control as well.

Two versions of Tripwire are available: Tripwire 1.3.1 Academic Source Release (ASR) and the commercial version, Tripwire 2.2.1. Tripwire's ASR was developed at Purdue University in 1992 by Gene Kim and Gene Spafford. The release (it's still freely available; see Resources) is the most widely used piece of integrity assessment software in the world. However, the relatively static ASR isn't often upgraded. Tripwire does provide bug fixes and minor feature updates, but if you want support and the major new features, you'll have to pay for them ($495 per host).

Tripwire 2.2.1 for Solaris

I haven't used Tripwire 1.3 very much, mostly because it's a hassle to configure and it requires meticulous care to keep the database on a write-protected floppy. Although maintenance on a large installation would be a nightmare, I see good reason to use it on static systems such as firewalls.

Recently I took a critical look at the improvements made to Tripwire 2.2.1 for Sun Solaris. They include:

• Support for Windows NT
• Much more flexibility in policy definitions, which provide more granular checking and readability
• Improved reporting mechanisms, including a GUI report viewer that runs on Windows NT (it can view a Unix-generated report as well)
• Stronger protection of policy, configuration, and database files using cryptographic signatures
• Performance optimization
• Enterprise management features for large installations

Tripwire 2.2.1's installation guide is succinct, with useful examples and no gratuitous sales pitches. I strongly recommend that Tripwire be installed on a clean system that hasn't been on the network. The default policy file will get you started. You should prepare a phrase for a "site key" and a "local key" and store them in a safe place (not online!).

You may want to customize the install.cfg file before running the install script and check the installation before running it to see if it's been modified. Another security issue to be stressed: the installation generates clear text copies of the policy and configuration files for inspection (twcfg.txt, twpol.txt, and policyguide.txt). Those files are needed to generate the encrypted configuration and policy files but aren't required to run Tripwire. I recommend storing them with the pass phrases in a secure location such as a safe.

Note: You won't need to store clear text copies of the policy and configuration files, because they can be regenerated at any time. You may, however, want to have them available for comparison purposes. The initial database should be backed up and stored offline in a safe location, providing a baseline for later comparison.

The most significant changes in Tripwire 2.2.1 are enhancements to the policy file and the addition of cryptography to protect key files.

Cryptographic protection

One of the ASR's biggest weaknesses is its dependency on write protection for database file hardware. If a file is software-mounted read-only, it can be compromised (see "Tripwire Trips Up Technological Trespassers" in Resources). While it's still a good idea to have the database mounted read-only on a hardware level, the commercial version provides additional protection if that isn't done.

Tripwire 2.2.1 cryptographically signs key files, using a 1,024-bit El Gamal encryption algorithm. The cryptographic signature routines (hashes) used in Tripwire's commercial releases are stronger than those in the ASR.

The Tripwire policy file

The Tripwire policy file specifies the files, file characteristics, and directories that need to be checked. Both versions of Tripwire check all inode attributes, which include file permissions and signatures. Tripwire 2.2.1 has an expanded policy language that allows you to name and group rules, set severity levels, and provide email notification on a per-rule basis.

Aspects of the policy file include:

• Traversing mount points: Tripwire checks only the files and subdirectories on the device. For example, if you have a filesystem /usr/local and you tell Tripwire to check /usr, it won't check anything under /usr/local unless you explicitly tell it to do so.
• Property masks: These flags are turned off or on with a (-) or (+), respectively, and indicate the characteristics of the file you want to check. Property masks can be grouped under a variable name that can be used in a rule. The masks are:

  - (minus) -- Ignore the following property
  + (plus) -- Check the following property
  p -- File permissions
  i -- Inode number
  n -- Number of links
  u -- Userid of owner
  g -- Groupid of owner
  t -- File type
  s -- File size
  l -- Growing files (indicates that you expect the file to get bigger, not smaller; used for log files)
  d -- Device number of the disk where the inode is stored
  r -- Device number of devices
  b -- Number of blocks allocated
  a -- Access time stamp (indicates that the file has been read)
  m -- Modification time stamp
  c -- Inode creation/modification time stamp (indicates the last time the inode itself was modified)
  C -- CRC-32 cryptographic signature
  M -- MD5 cryptographic signature
  S -- SHA cryptographic signature
  H -- HAVAL cryptographic signature
  

• Stop points: The ability to ignore specific files in a directory tree. For example, you may want to check if any files in /etc were modified but may choose to disregard /etc/mnttab.
• Rulename: You can categorize file types by attaching labels to files. The Tripwire documentation suggests using rcfiles to group files run by root at system startup. As another example, the label localfiles could be associated with all locally developed files.
• Severity: You can associate a severity level with a rule and optionally run Tripwire with a specified severity level. Tripwire will check only the rules that meet or exceed the specified severity level. You can also attach a severity level to a block of rules.
• Emailto: You can send email notification on a rule-by-rule basis, directly from the policy file. This is useful if you're checking an application supported by another administrator.
• Recursion: Tripwire can be directed to scan only the contents of the inode directory, not all the subdirectories. This is useful if you want to make sure /export/home1 is not 777 (or owned by a user) but you don't care what users do to their own directories. You can also specify how many subdirectories you want to check.
• Directives: For large installations, it's more efficient to have one policy file that can be run on all systems. However, you may want different actions taken, depending on the system. If so, you can use directives to make conditional statements about the rules to run, depending on the specified host or hosts.
• Variable definitions: Tripwire 2.2.1 lets you put your own hooks into the rules by supporting variable definitions in any place a string would normally appear. This helps make the policy file more readable and efficient.

Tripwire trip-ups

Every software package has its weaknesses, and Tripwire is no exception. For example, its cryptographic signatures improve security, but they're not a panacea. If the keys aren't protected, says Rain Forest Puppy, the database can be decrypted, tampered with, and re-signed. If the application can do it, so can a person. However, a person would have to know how the database was encrypted in the first place.

While the keys live on disk, the portions of the keys that must be used to sign files (the private portion of the site and local key files) are themselves encrypted symmetrically with Triple-DES and aren't on disk. Someone would have to either brute-force the private portion of the 1,024-bit El Gamal key or force the triple-DES key to decrypt the same. It's not impossible, but it is difficult. Tripwire relies on some obfuscation in this regard, which isn't necessarily a bad thing. Simson Garfinkel pointed this out in his paper "Open Source: How Secure?" (see Resources):

...security through obscurity only breaks down if keeping the secret is difficult. It's pretty easy for a crook to look under your doormat and find the key. On the other hand, the orientation of the pins in your front door lock is simply another secret that provides security. That secret is better because you would have to try every possible key or [sic] to find the correct one.

Tripwire also experiences problems when it encounters applications that reset the access time stamp. For example, backup programs access files for reading, which modify the atime. That can be reset by the application, but it will modify ctime (change inode), which Tripwire will complain about (see the "Problem with NetBackup" discussion in Resources). You can configure Tripwire to ignore changes to ctime.

fsdb exploit

Although you can use fsdb (the file system debugger) to reset file system attributes such as ctime and fix a backup application problem, you will open up a security issue: Tripwire will not detect changes to the inode of the file.

An attacker could use this to mask the file access before Tripwire runs. However, the fsdb manual page even warns that "fsdb is intended for experienced users only." Unless you know what you're doing, don't experiment with fsdb because it's very powerful and doesn't have an undo feature.

Fin

Defeating Tripwire takes time and a lot of skill, which should slow an attacker down long enough to get caught (assuming a good IDS is in use). Are the improvements in the commercial Tripwire worth the cost? If a systems administrator's time is a limited resource, the improvements to the policy file alone are worth it.

Acknowledgments