Linux Security Cookbook

Chapter 1. System Snapshots with Tripwire

Suppose your system is infiltrated by the infamous Jack the Cracker. Being a conscientious evildoer, he quickly modifies some system files to create back doors and cover his tracks. For instance, he might substitute a hacked version of /bin/login to admit him without a password, and a bogus /bin/ls could skip over and hide traces of his evil deeds. If these changes go unnoticed, your system could remain secretly compromised for a long time. How can this situation be avoided?

Break-ins of this kind can be detected by an integrity checker : a program that periodically inspects important system files for unexpected changes. The very first security measure you should take when creating a new Linux machine, before you make it available to networks and other users, is to “snapshot” (record) the initial state of your system files with an integrity checker. If you don’t, you cannot reliably detect alterations to these files later. This is vitally important!

Tripwire is the best known open source integrity checker. It stores a snapshot of your files in a known state, so you can periodically compare the files against the snapshot to discover discrepancies. In our example, if /bin/login and /bin/ls were in Tripwire’s snapshot, then any changes in their size, inode number, permissions, or other attributes would catch Tripwire’s attention. Notably, Tripwire detects changes in a file’s content, even a single character, by verifying its checksum.

Tip

tripwire Version 1.2, supplied in SuSE 8.0, is positively ancient and supports an outdated syntax. Before attempting any recipes in this chapter, upgrade to the latest tripwire (2.3 or higher) at http://sourceforge.org/projects/tripwire or http://www.tripwire.org.

Tripwire is driven by two main components: a policy and a database. The policy lists all files and directories that Tripwire should snapshot, along with rules for identifying violations (unexpected changes). For example, a simple policy could treat any changes in /root, /bin, and /lib as violations. The Tripwire database contains the snapshot itself, created by evaluating the policy against your filesystems. Once setup is complete, you can compare filesystems against the snapshot at any time, and Tripwire will report any discrepancies. This is a Tripwire integrity check, and it generates an integrity check report , as in Figure 1-1.

Figure 1-1. Creating a Tripwire snapshot, and performing an integrity check

Along with the policy and database, Tripwire also has a configuration, stored in a configuration file, that controls global aspects of its behavior. For example, the configuration specifies the locations of the database, policy file, and tripwire executable.

Important Tripwire-related files are encrypted and signed to prevent tampering. Two cryptographic keys are responsible for this protection. The site key protects the policy file and the configuration file, and the local key protects the database and generated reports. Multiple machines with the same policy and configuration may share a site key, whereas each machine must have its own local key for its database and reports.

Although Tripwire is a security tool, it can be compromised itself if you are not careful to protect its sensitive files. The most secret, quadruple-hyper-encrypted Tripwire database is useless if Jack the Cracker simply deletes it! Likewise, Jack could hack the tripwire executable (/usr/sbin/tripwire) or interfere with its notifications to the system administrator. Our recipes will describe several configurations—at increasing levels of paranoia and expense—to thwart such attacks.

Tripwire has several weaknesses:

• Its lengthy output can make your eyes glaze over, not the most helpful state for finding security violations.

• If you update your critical files frequently, then you must update the database frequently, which can be tiresome.

• Its batch-oriented approach (periodic checks, not real-time) leaves a window of opportunity. Suppose you modify a file, and then a cracker modifies it again before the next integrity check. Tripwire will rightfully flag the file, but you’ll wrongly blame the discrepancy on your change instead of the cracker’s. Your Tripwire database will be “poisoned” (contain invalid data) on the next update.

• It doesn’t compile easily in some Linux and Unix environments.

Regardless, Tripwire can be a valuable security tool if used carefully and methodically.

Warning

Before connecting any Linux computer to a network, or making the machine available to other users in any way, TAKE A SNAPSHOT. We cannot stress this enough. A machine’s first snapshot MUST capture a legitimate, uncompromised state or it is worthless. (That’s why this topic is the first chapter in the book.)

In addition to Tripwire, we also present a few non-Tripwire techniques for integrity checking, involving rpm [Recipe 1.15], rsync [Recipe 1.16], and find. [Recipe 1.17]

There are other integrity checkers around, such as Aide (http://www.cs.tut.fi/~rammer/aide.html) and Samhain (http://la-samhna.de/samhain), though we do not cover them. Finally, you might also check out runtime kernel integrity checkers, like kstat (http://www.s0ftpj.org) and prosum (http://prosum.sourceforge.net).