[EMAIL PROTECTED] wrote:
Since I'm always installing updates on my Debian box, Tripwire IDS is daily reminding me of changes to my PC that require updating Tripwire box.
And therein lies the problem: tripwire does a great job at what it does.
I'm thinking of bailing on Tripwire.
Unless you have machines that require a static configuration (like, say, a router/firewall box) tripwire is more of a pain in the ass than it is really worth.
Anyone else find it useful and managed to make it practical?
Well, sure, i can make it practical. And useful. It's just that its useful applications are few. You just have to ask and answer a few questions: On how many systems do you need to monitor filesystem-level changes? Of those systems, what files should be monitored? What is the impact of system maintenance to the monitoring system?
A lot of times, monitoring system binary directories is silly at best, and pointless at worst. If you have a regular user with rights to modify system-level binaries, then your system is set up wrong. Same goes with system-level configuration files. If that's not the case, then root has been compromised, and there isn't a damned thing tripwire can do to prevent or help with that. Besides, if you're root, why do you need a trojaned binary? OK, if you want to steal application-level data, like user passwords or something, maybe it's useful. Even with a rootkit, you can have it monitor for specific file changes (/usr/bin/ps, et al).
It's difficult to have a file auditing tool take into account system updates. Unless that tool is provided with a list of files updated and their checksums, it's *always* going to give false positives. With the plethora of system update utilities out there, this seems like a daunting task ... Even then, this isn't a "good" solution, as an attacker can forge an update list.
IMO, if you're using tripwire to monitor something other than a machine which is to stay in a static configuration, you probably need to rethink your monitoring strategem.
Just my $0.02... -Kelsey -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
