Tripwire - The Only Way to Really Know - Page 3

By Jay Beale | Posted Oct 17, 2000
Page 3 of 3   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn


Initializing the Database

We need to take a "baseline" picture of the filesystem. We'll run Tripwire with our new configuration file in "Initialize" mode, to build up our database.

# cd /root/tw ; ./tripwire --initialize
Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
###
### Warning:   Database file placed in ./databases/tw.db_max.
###
###            Make sure to move this file and the configuration
###            to secure media!
###
###            (Tripwire expects to find it in '/root/tw/databases'.)

As suggested, we should move this to secure media. Actually, we should copy the Tripwire binary, the tw.config file and the database to secure media, like a writable CD-ROM, a tape backup, a SCSI drive in read-only mode, or even a read-only NFS mount. In any case, we should also use siggen to store signatures of these three files - write the signatures down, as you want to make sure no one has tampered with your digital versions.

"Tripwire detects intrusions by watching for changes in the filesystem. It also lets you know exactly what has changed, so you know which programs you can trust once you have been hacked."


Example: Detecting Intrusion

Tripwire detects intrusions by watching for changes in the filesystem. It also lets you know exactly what has changed, so you know which programs you can trust once you have been hacked. We can see an example of this by making our own (trivial) backdoors. First, let's copy /bin/sh to /sbin/sh, and make it Set-UID root. We'll make a second copy, just in case this is found out, in /sbin/su. Finally, we'll place a backdoor in place of /bin/su, which will now give root access to anyone logging in as "l33t", and will not require a password for the login.

# cp /bin/sh /sbin/su
# chmod 04755 /sbin/su
# cp /bin/sh /sbin/sh
# chmod 04755 /sbin/su
# cp -p /root/myrootkit/su-replacement /bin/su

Believe it or not, these are unlikely to be discovered by the system administrator, as simple as this trick (4) is. Now, let's see what happens when we re-run Tripwire in Integrity Checking mode. In this mode, Tripwire simply re-calculates the database and checks it against your stored version for differences. It should find these two pretty easily.

# ./tripwire
Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
### Phase 4:   Searching for inconsistencies
###
###                     Total files scanned:            69689
###                           Files added:              2
###                           Files deleted:            0
###                           Files changed:            0
###
###                     Total file violations:          2
###
added:   -rwxr-xr-x root       316848 Jul  2 17:11:55 2000 /sbin/sh
added:   -rwxr-xr-x root       316848 Jul  2 17:12:23 2000 /sbin/su
changed: -rwsr-sr-x root       316848 Jul  2 17:47:10 2000 /sbin/su
### Phase 5:   Generating observed/expected pairs for changed files
###
### Attr        Observed (what it is)         Expected (what it 
should be)
### =========== ============================= 
=============================
/bin/su
      st_size:  316848                        
14188                        
      st_mtime: Sun Jul  2 17:47:10 2000      Sun Jul  2 17:12:23 
2000      
      st_ctime: Sun Jul  2 17:47:22 2000      Sun Jul  2 17:12:23 2000
    md5 (sig1): 0nGKgbNQwrqtPUEnjX2YWl        3.w7.UtVCY8J8AyytPc5Gp
    sha (sig7): 33Vh72XyEIvKGPiOY1Tm8qu.KHU   
3MWvwVuy5iRBdHr7Y.lIzdljA1e


Reaction - A Quieter, Quicker Configuration:
The Audit Floppy

Notice that these runs are taking an awful long time. On my Celeron 466 test system, with a full install of Red Hat 6.2 on an IDE drive, each confirmation takes about 10 minutes! Further, the database was about 10 megabytes, which doesn't come close to fitting on a nice, easy to re-write floppy disk! On the other side of the spectrum from a very inclusive configuration, we have the Audit Floppy. We basically watch the system binaries, and the main /lib directory. This configuration is small enough to fit the database on a floppy, along with the tripwire binary and configuration file. It'll also be "quiet," in that it will register very few false positives, while catching rootkit replacements of programs, like ps or w... Since we can set the floppy to be read-only, the Tripwire files are quite safe! The downside is that this minimal configuration will miss changes in configuration files, libraries and other directories.

For now, here's what we do. We'll basically watch the binaries, programs and libraries.

# quieter tw.config for SecurityPortal.com article  jjb 06/30/2000

# This file is a sample configuration file that you can use for a 
stock
# Red Hat 6.2 system, using Tripwire 1.3.1.  This is a 
"quiet" version
# for an audit floppy.

#
# First, define a number of monitoring levels.
#

# Essential system binaries should be monitored on all attributes, 
with a
# high level of certainty.  We keep only md5 and SHA-1 for now.

@@define BIN E+pinugsmc17

# Monitor essential system binaries: libraries and programs

/bin            @@BIN
/lib            @@BIN
/sbin           @@BIN
/usr/bin        @@BIN
/usr/sbin       @@BIN

# Monitor the /boot directory, where the kernel et al. is stored.  
System.map
# changes inode and mod time on every reboot, so ignore these.

/boot                   @@BIN
/boot/System.map        @@BIN-mc

This configuration, by the way, ran on my test machine in 61 seconds! Its database was under 400k, leaving plenty of room on a floppy for the Tripwire binary. There are serious advantages to smaller configurations: for one, they run quickly enough that you can Tripwire once every hour! They are also much, much quieter - if you detect changes with this configuration, you can be fairly certain that you're in trouble5!


Afterword - The Tradeoffs

We had to make serious tradeoffs when crafting the Tripwire configuration file. The more inclusive we make it, the more false positives we'll see; the larger the database gets, the longer the runs will take. What purpose you have for Tripwire influences how you balance this. You might even make two configurations! You could have one config file/database pair that looks like our Audit Floppy, which runs automatically every hour and pages you if a single file changes. Your other config file/database pair could be very inclusive, which you use interactively when you suspect that you've been hacked.

Tripwire's recent Version 2.x mitigates some of these tradeoffs very well, with some really cool features. One such feature allows you to set priorities and mail alerts on different files, so that you get a page in the middle of the night when an essential binary changes, but only a gentle warning later when your log files get cycled. Their Tripwire HQ product lets you manage all this from a central console, making Tripwire much more scalable - in my opinion, the HQ product is the only good way to deploy this across an enterprise. The downsides to 2.0 are few: 1) Tripwire 2.x costs money for non-Linux machines. 2) You don't get the code anymore, for now, which stops you from making modifications to the program. I'll do a future article on Tripwire 2.x, though, so stay tuned. The folks over at Tripwire are doing some very interesting work!

Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille-linux.org). He is the author of several articles on Unix/Linux security, along with the upcoming book "Securing Linux the Bastille Way," to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes. You can learn more about his articles, talks and favorite security links via http://www.bastille- linux.org/jay.

1 Actually, most of them aren't stealthy. They just have nice tools, like log-wipers and rootkits!

2 Kurt Seifried's SecurityPortal.com Trojan horse article is a good read on this stuff.

3 For the mathematically inclined, one-way-hash-functions are generally thought to have few to no collisions, such that each hash value (signature) computed corresponds to about 1 possible file content set. (nearly 1-to-1)

4 su won't change behavior, because the real su is first in root's $PATH variable.

5 Unless you just patched your system...make sure that you run Tripwire before you patch, then re- initialize the database immediately after.


SecurityPortal is the world's foremost on-line resource and services provider for companies and individuals concerned about protecting their information systems and networks.
http://www.SecurityPortal.com
The Focal Point for Security on the Net (tm)

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter