The Answer Gang

By Jim Dennis, Karl-Heinz Herrmann, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

Tripwire

From Greg Bell

Answered By Barry

[Heather] An honorary answerbubble for Greg Bell. Good stuff here, and thanks to article auther Barry O'Donovan for forwarding the thread to us.

One thing that I've been suspicious of with tripwire is: if the hacker is "in", aren't there all sorts of things he can do to neuter tripwire?

To save an argument I could simple say yes... but I won't! First of all, running tripwire (or another intrusion detection system (IDS)) is immeasurably better than running no IDS at all.

thanks for the dialog. no arguments here, although my counter-points to your points may appear argumentative

a lot of things that seem burdensome for a hacker to do can be wrapped up nicely in a script and bam - 1000s of intruders now have the capability.

These scripts usually take advantage of an existing exploit to place a root kit, backdoor, etc. If your tripwire set-up is unique (i.e. place the tripwire binary somewhere besides the defualt, use a different configuration file name and directory, place the db on a floppy, remote site, etc) then the script won't affect tripwire or if it does it'll be immediately noticed. Most of these scipt-kiddies go for the "easy hack" - the poor fools who take no preventative measures. There's so many of these guys that the script-kiddies are unlikely to invest the time in created a "be-all and end-all" script to do everything including disable tripwire in a way that it's not noticed.

He can remove the cron/anacron job, and send you fake mail every day saying everything checked "OK".

That's a lot more difficult than it sounds. First of all, he'd need to know what the usual "all is okay e-mail" looks like for YOUR system. When you're running tripwire and checking the e-mails you'll get used to seeing and recognising a lot of numbers such as the total objects scanned, etc. If you're sending these daily e-mails to another server then he won't have access to an existing report and he won't be able to view the saved report files in /var/lib/tripwire without your passphrase.

i am admittedly paranoid about this sort of thing, thanks to reading about how clever these guys can be, and how it seems to be a never-ending escalation and arms race (leading towards EVERYTHING being encrypted, and EVERYTHING being authenticated with biometrics). a lot of things that seem burdensome for a hacker to do can be wrapped up nicely in a script and bam - 1000s of intruders now have the capability.

Secondly whether you're running tripwire on a server or a desktop machine, you're liable to have to update at least one package at least once a week. When you do this you'll expect a problem from tripwire and if he's sending fake e-mails you'll start to question whther tripwire is working or not.

some things i think would be appropriate for tripwire to watch would be /etc/passwd and /etc/crontab - two things that can change often, but that are also prime candidates for a hacker to change.

Most distributions default tripwire config will check these - especially passwd. If it doesn't, then ammend the policy file so that it does.

so it seems to me than whenever one of these needs to be changed, you've got to run tripwire on the file to make sure its unchanged, unplug your net connection, change it, update tripwire, reconnect to the net. sounds bizarre but its not improbably that in the hours between your update and tripwire's next run, a break-in occurs, changing the same file.

Again, it's all a matter of just how paranoid you are or how far you're willing to go.

he can replace the tripwire binary itself.

Tripwire checks itself too! The stats for the tripwire binary will reside in the database which an intruder cannot change unless he has your local passphrase. I suppose an intruder could replace the binary with one that's programmed to not check itself but if you're really this paranoid you can put the binary on a remote HTTP server and have your cronjob download it with wget before checking.

the "in" hacker would just disable the wget and have the local one be used.

He'd also have to asscertain that you use wget to download a fresh binary and simulate the output from your wget cronjob so you wouldn't miss it.

Some servers will mount /usr as read-only to increase access speeds and security. This would help out here too.

if he's got root, he can just remount r/w.

he can update the database

He can't. He'll have to have your local passphrase to do this.

which an "in" hacker can get with a keycatcher.

But he'd probably have been spotted by a run of tripwire before hand as you'd need a reason to input your tripwire passphrase.

(especially if its on a CD-RW like you suggest).

I never said leave the CD-RW in a CD-RW drive. I said "a re-writable CD in a CD-ROM drive (read-only drive)." i.e. only place the CD in the CD-RW drive when updating, then put it back in the CD-ROM drive.

got it. smart.

The bottom line is that tripwire will probably catch an intruder 99 out of a 100 times. If not more. You'll NEVER be 100% secure. That's just a simple fact of life. But you can strive to be as secure as possible and using tripwire will be a huge help here.

absolutely.

seems to me we might be moving towards a world where an off-site system does the security check for a particular machine - sort of a checks and balances setup. it would host the tripwire binaries, database, signatures, etc. and while its there, it should receive the mails from tripwire, as well as host the syslog remotely. even so, rootkit hunters would still have to be run on the secure machine, and some amount of manual checking would have to be done to make sure any number of checks hadn't been faked or disabled.

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

---