Linux Security Cookbook [Electronic resources] نسخه متنی

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.

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 configurationsat increasing levels of paranoia and
expenseto 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.

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/aidel) 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).