[RFC] programmatic IDS routing

[Steve Grubb]

On Wednesday 19 March 2008 17:41:07 Eric Paris wrote:
> So maybe all we need is for the ids config file needs to be of the form
>
> key type priority

And hostname. Remember that this could be run from an aggregator.


> so I can set up my audit rule however I want say
>
> -a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F dir=/etc -k
> 500EPERM -a always,exit -F perms=wa -F subj_role=webadmin_r -F exit=-EPERM
> -k webadminEPERM
>
> And my ids config file would look like:
>
> 500EPERM        file    med
> webadminEPERM   exec    high

This is pretty close to the idea that I started with. Then I thought, how do I 
make this engine run faster? How do I reduce memory consumption (since the 
keys have to be stored in memory)? How do I make sure that the keys are there 
and correct?


> And on startup the ids can easily look to see if 500EPERM and
> webadminEPERM are actually keys to real rules just for sanity sake.  

Sure...but audit rules are loaded after auditd starts so that we can record 
them being put into effect. So, you would have to wait for a a while after 
startup to do this.

> Is the reverse mapping from key to ids action really so expensive that this
> is unreasonable?

Consider a datacenter with many hosts that may want to run this off of the 
aggregator. There will be a high rate of incoming events and a bit of 
comparing to figure out if each event something we care about. 

With my proposal, I can tell with strncmp(key, "ids-", 4) if this is anything 
we need to pay attention to. So, inspection of 4 bytes let me decide yes/no. 
Its a finite amount of time and doesn't linearly slow down the system as more 
hosts and files of interest are configured. It scales well.


> I tend to also agree with the part of the discussion which says that it
> isn't audit's place to decide that some rules are meant for disk and
> some rules aren't. 

I agree and never proposed that.

-Steve