Tripwire - The Only Way to Really Know - Page 3
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'.) |
| "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)
