[RFC] programmatic IDS routing

[Steve Grubb]

On Wednesday 19 March 2008 19:00:41 Linda Knippers wrote:
> 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?

I wouldn't call this overloading the key field. The key field's purpose is to 
allow searches for groups of audit events. You've traditionally used this 
from the command prompt with ausearch. Now with the auparse library, it can 
be used programmatically for searching by more utilities.

The way that it helps is that I can tell yes/no in 4 byte compares and without 
storing any linked lists, hashes, or binary trees.


> > How do I make sure that the keys are there and correct?
>
> That can be a startup check.

How do you do that remotely?


> >> 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?

That's not true. When it comes to IDS, the real question is how to effectively 
escalate events of interest without overloading the decision makers. 
Something that alerts once a second is of no use to anyone. You want it to 
pick out the things you really care about for realtime and save everything 
else for a daily report.


> > 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?

The IDS plugin.


> Couldn't you hash the key?

Yes. Takes more time than strncmp and then you may still have collisions where 
you walk a list of some kind. This also has the side effect of needing to set 
aside a good chunk of memory for the hashes - used or not.


> > 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.

-a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F path=/etc/password

and

-w /etc/password

collect entirely different amounts of data.

-Steve