Re: [RFC] programmatic IDS routing

[Linda Knippers <linda.knippers@hp.com>]

Steve Grubb wrote:
> 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.

I'm not sure why all of the above apply.  If an IDS has a dependency on
audit and specific audit rules to get the information it needs, it can
use the information in its config file to construct the audit rules it
needs.  I don't think an IDS config file needs to be any more
complicated than an audit rules rules, and in fact should be simpler.
If the IDS is using the audit system, then I don't think the rest apply
either.

-- ljk
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit