Re: [RFC] programmatic IDS routing

[Steve Grubb <sgrubb@redhat.com>]

On Wednesday 19 March 2008 14:05:42 Valdis.Kletnieks@vt.edu 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