On Fri, 19 Oct 2001 peff-loganalat_private wrote: > > On Fri, 19 Oct 2001, Ralf Hildebrandt wrote: > > > Well, one has to walk over and put in the floppy with the DB, then check it. > > Do you do this every day? Or do you wait for something in the logs to > clue you in that something might be up? > > Tripwire is really only useful (above standard log reviewing) if you keep > the executables and the DB on removable (or read-only) media. Which > includes its own operating system (you don't want a trojaned kernel, > right?). And it would require a reboot for every check, since tripwire > only checks the persistent state of the machine; you want to make sure > there are no evil kernel modules loaded, either that you fail to check > for, or that are obscuring tripwire data. > > Perhaps I'm overstating my case...but my point is that rigorously using > tripwire can be a royal pain in the ass. Using it in a non-rigorous > fashion can leave some holes open (however unlikely). Reviewing > reasonably secured logs along with daily (non-rigorous) tripwire checks > increases the likelihood that an attacker will fail to hide his presence. > > I'd rather have both as rigorous as possible without putting too much > burden on the sysadmin; IMHO, doing tripwire "right" is too much > trouble. I'd rather have the logging provide an additional, independent > check from the tripwire check; if it relies on the tripwire check, then > tripwire is a single point of failure. Correct. This was a problem I though about for quite some time over the last few years. One of the main solutions I came up with is simple. It has some problems along the same lines but is designed more as a general alert option that also interfaces with the IDS and related logging systems. I am heavily ino managing secure networks after they have been installed, which is an activity I suspect is prat of the whole log analysis structure methodology. To that end I am also a big promoter/user of SNMP. We make extensive use of SNMPv3 in many of our managed security structures. This is the framework behind the following technique: We have a defined MIB for file management. This MIB specifies files to watch for lack of a better description. Through regular queries these files are monitored by using various hashes. The actual hash generator is a binary that is called as an agent extension on this particular MIB subtree. It returns the hash of the file in question. Yes - if the box is compromized then this mechanism may be directly attacked. However - the SNMP management platform check these hashes on all critical machines on a regular basis. If a hash is missing or changed then alarms are sounded ala standard SNMP management. This provides us almost all of the tripwire functionality over a authenticated and secured channel in a manner that enhances Defense-in-Depth. Long story short: You have to crack one of these systems within 5 minutes in such a manner as to change the OOB logging, AND disable the SNMP trapping mechanism, AND disable the host IDS mechanism, AND finally make sure that you send back appropriately spoofed hashes. Nothing is perfect but experience teaches that several short barbed wire fences separated by moats is much much better than one large fence... > -Jeff > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: loganalysis-unsubscribeat_private > For additional commands, e-mail: loganalysis-helpat_private This list is really great. Thanks! -------------------------------------------------- Matthew G. Marsh, President Paktronix Systems LLC 1506 North 59th Street Omaha NE 68104 Phone: (402) 932-7250 x101 Email: mgmat_private WWW: http://www.paktronix.com -------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Fri Oct 19 2001 - 09:59:14 PDT