|
|
|
|
|
|
|
|
Tripwire is a program designed to help you discover if someone is tampering with your system.
by Kevin Fenzi
You run the latest Linux kernel, read the Linux-security-alert mailing list, install security patches as soon as they come out. Your Linux machine is secure. Right?
Alas, it's not very likely. Even if you install the newest patch, someone might have already compromised your machine and replaced your system binaries without your knowing it. In that case, fixing the hole which allowed them entrance is just part of your problem. Even with quick turn around in the Linux community (we have the source code after all) for security vulnerabilities being spotted and someone coming out with a fix for it, there will always be a window of opportunity for someone to compromise your machine.
What more can you do to close this window? How can you know when some intruder has broken it? Enter Tripwire. Tripwire has a pretty simple concept. It takes checksums of all your important files; then later, you can check your files against the Tripwire database and determine if any change or tampering has occurred. The current version of Tripwire (1.2.2) has not been updated since 08/94, so it is a very stable program. There is not much that can go wrong with it.
Some cracker tools have been designed to modify or replace system binaries (login, telnetd, vmlinuz, ps, ls, etc) and then make them appear to be the same as before. Usually the methods are crude, consisting of just the modification of the date and size of the file (back to their original values). A casual glance shows all to be fine. Some intruder tools even try to get the modified or replaced binary to match a simple checksum. For instance, change the binary so it will pass a simple test such as:
cmp /bin/login /cdrom/untouched/bin/loginIn order to make sure this doesn't happen, Tripwire is capable of using all sorts of checksumming algorithms. Tripwire comes with: The RSA Data Security, Inc. MD5, MD4 and MD2 Message Digest Algorithms, Snefru (the Xerox Secure Hash Function), SHA (the Secure Hash Algorithm) and Haval code. The authors of Tripwire suggest that MD5 is sufficient for most checksumming, and critical files might also be checked with Snefru. Checking with one checksum like MD5 is pretty good, but imagine the difficulty of creating a binary or file that passes 2 or 3 (or more) different checksums. Few system intruders have the time/resources to even make the attempt.
Using the Tripwire database, you can check all your critical files for tampering. Now, how do you know if someone has tampered with your Tripwire binary or Tripwire database? After all, if the intruder can modify your Tripwire database, you are back to square one.
Several different methods exist. The easiest, and I think the best for most security conscious Linux users, is to place Tripwire and the Tripwire database on a read-only floppy disk. Since most Linux machines have a floppy drive and few are in use all the time, it's a good match. The Tripwire authors also suggest that if you are very concerned, you can print out the Tripwire database. It's hard to imagine an intruder being able to modify documents printed before they broke in. Other possible schemes include: remote mounting the Tripwire binary and database from another more secure machine read-only, putting it on a write-protected Zip disk, or even getting an old, small hard drive that has been jumpered to hardware enable read-only and put it on that. The idea is to put it on some media that you can make read-only in hardware. It does you no good to place Tripwire where an intruder can mess with it. If the machine you want to check is in a place accessible to many people, keep your Tripwire floppy in a safe location and bring it to the machine only when you want to check your files. You can also NFS mount it from a remote, more secure machine with a floppy.
Okay, you've decided to install it. How do you go about that? Well, grab the latest Tripwire source (Tripwire 1.2 patch level 2). It should compile just fine under most Linux distributions. I had no problems compiling it under a Red Hat 4.0 system out of the box. Read through the README file for a quick overview, and if you want more details, take a look at the PostScript design paper. There is also a Tripwire RPM available, but I would recommend against using it, as you can't specify where it should be installed.
Make the choice of the directory where your Tripwire binary and Tripwire database will reside before you compile. Tripwire hard codes these paths to prevent tampering.
Once Tripwire is compiled, take your machine down to single-user mode. I know, you don't want to lose that many months uptime, but you must make sure you are the only one on the system and no one has a remote connection to your machine that can be used for tampering. If you are particularly concerned, you might consider a clean install of your system before installing Tripwire in order to be sure all your binaries are clean. In single-user mode, mount the media on which to place Tripwire and the Tripwire database. (Mount it read/write this time, so you can copy Tripwire onto it.)
Install Tripwire. Next, determine what binaries are important for Tripwire to check. It is almost useless to check files that change a lot (user files). Tripwire is mainly for your important system binaries. My Tripwire configuration checks: /etc, /sbin, /bin, /usr/bin, /lib and /vmlinuz; it also checks some files in /dev. Even these are going to change more than you might think. If you select too much, your Tripwire reports are going to be too full of hits for you to notice a real break-in.
After you get your tw.config file set up for the directories you want to change, it's time to make your new, clean Tripwire database. Type:
tripwire -initRelax for a while. It takes Tripwire a fair amount of time to generate all the checksums. Using just the default MD5 checksum on all the directories I mentioned above takes my dual 166MHz Pentium about 5 minutes (faster disks would help).
After Tripwire has finished creating the database, remove your Tripwire media and make it read-only (jumper, write-protect notch, etc). Then, bring your machine back up to full multiuser mode and mount your Tripwire media.
Now, to make sure things are working, try changing a file in one of the directories listed in the Tripwire database. Run Tripwire and make sure it catches it. It will output a very nice, verbose report showing which files have changed and in what way they have changed (modify time, checksum, etc).
I have my Tripwire set up to run each night in a cron job and mail the results to me. You can have yours do the same or just run it when you suspect something is wrong. I would recommend you run it pretty often. You never can tell when you might be compromised. Checking a short Tripwire report every day is a small investment in security that can really pay off. You can still rerun Tripwire whenever you think there might be a reason for it. (Keep in mind that an intruder might modify your mail from the cron job to make it look like nothing happened.) For that reason, I also run Tripwire periodically when I have nothing else going on (while ``on hold'' for those long tech support calls, etc).
You will find that as you update packages and config files, your Tripwire database flags more and more files; periodically, you need to take your machine back down to single-user mode, remount your Tripwire media read/write and update your database with a different command:
tripwire -interactiveMake sure you know why each file is different now. If you are at all unsure, don't update that file in the database; instead, replace it with a fresh copy off your distribution site or CD-ROM and then rerun Tripwire.
It's that simple. You now have a nice detector capable of telling you when someone has been tampering with your files, and the peace of mind that comes with knowing your Linux box is the most secure one on your network.
Kevin Fenzi has been fascinated with Unix security since he saw his first crack program. He currently does programming and consulting on many flavors of Unix, but his Linux machine at home is his favorite. He can be reached via e-mail at kevin@scrye.com.