Re: [RFC] programmatic IDS routing

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 20 March 2008 09:32:29 Linda Knippers wrote:
> Steve Grubb wrote:
> > 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.
>
> This optimization for a user-space component doesn't seem worth the hack.
> You are overloading the field

How is this overloading the field? What is your definition of the field? What 
are its legitimate uses? Is the admin not allowed to put anything they want 
in it, include text they'd like picked out in realtime?

> > How do you do that remotely?
>
> Same way you would check that audit is running remotely.  You can either
> check the state of the target system or not, 

The answer is not. So, given that you can't probe the other end, you have no 
way to check the rules.


> >> 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.
>
> So the admin would create the rule he wants, create a unique key and tell
> the IDS what the key is and how it should react when it sees a record with
> that key.

Yes. What I want to do is also say that if you create your unique key a 
certain way, you get this additional benefit of realtime alerting or 
correlation. if you choose not to, then its treated as any other event.

-Steve