Re: [RFC] programmatic IDS routing
Steve Grubb wrote:
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 does overloading the key field help either of those?
How do I make sure that the keys are there and correct?
That can be a startup check.
> 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.
So the IDS starts after auditd, but it depends on auditd anyway.
> 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.
I think if someone is using audit as an IDS, they're going to care about
everything they're auditing or why are they auditing it?
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.
Who is doing this, the auditd, the dispatcher or the plugin?
Couldn't you hash the key?
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.
I guess Eric and I were both confused then by your comment about the
admin ending up with more audit events on disk than intended.
-- ljk
-Steve