Re: [RFC] programmatic IDS routing
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