On Wednesday 19 March 2008 14:05:42 [EMAIL PROTECTED] wrote: > On Wed, 19 Mar 2008 13:02:48 EDT, Steve Grubb said: > > files. In order for the IDS system to be able to distinguish an open of a > > watched file from an open of a *special* watched file that an alert > > should be sent for, I'd like to propose a standard way of alerting the > > IDS that this record needs additional scrutiny. > > Why do we need special handling for something the IDS should be able to do > for itself?
Something has to tell the IDS what to do for these 3 particular detections. It could come from a configuration file that it reads, or it could come from the event stream that it reads. Its just a matter of *where* the instructions come from. > If your IDS system doesn't already have a copy of the list of > "special" watched files, you have *bigger* problems. Not really, just think about the advantages of this approach. o You do not need to express host:file relationships if you are checking aggregate logs o You always have a matching audit rule to make sure you get the data you need o The event when recorded to disk has the meaning associated with it in case you wonder why something didn't get classified the way you thought it should o This technique is higher performance since you do not need iterate across a list of all files for each incoming event. o If the target file has a hardlink that is manipulated, the IDS won't be fooled because a different path showed up in the event stream. (This might even come into play for mount tricks that alter paths.) These are the easy ones that I can think up easily. While we are at it, the disadvantages to using the IDS configuration file approach: o The config file will become a mess when you get to this one entry that contains all file names one after another. Or you will have 2 config files one for the options and one for the files. You will of course need 2 more files for the other 2 detections, so now you have 4 config files to setup. o No guarantee that any audit rules exist to give you the events you need. o Lower performance o Uses more system memory o Susceptible to path name tricks o Code will be far more complicated and harder to read or understand due to size. o You have to be very careful to keep aggregate server rules in sync with remote system. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
