Re: [RFC] programmatic IDS routing

[Steve Grubb <sgrubb@redhat.com>]

On Friday 21 March 2008 06:28:42 Klaus Heinrich Kiwi wrote:
> > > 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
>
> I agree with Steve's compromise with speed, but maybe there's no way out
> of using hashes or linked lists in the general case.
>
> What if a message is important not only for the IDS plugin but also to a
> fictional 'real-time compliance reporting' plugin - both wanting to use
> the key field to carry special things, and in the same event:
> type=USER_ACCT msg=... key=ids-file-high,sox-fault-med,actual_key

Thanks Klaus, this is the conversation I really wanted to have.  :)

I think this is a valid concern and we should work out how to standardize this 
usage. I wouldn't be surprised if people are already doing this in their own 
deployments with tools they wrote.


> The plug-ins would need to check if their specific identifier is present
> not only in the first 4 bytes, but after every comma.

Sure, strchr is cheap, or strtok if you prefer. But I agree with this 
observation.


> If it's desirable to support the general case, instead of putting
> everything in one single 'key' field, maybe having an index just like
> execve arguments:
> type=USER_ACCT msg=... key[0]=ids-file-high key[1]=sox-fault-med
> key[2]=actual_key

That's a thought. In a way, I'd rather stay in one key field so that we have a 
path forward right now. It won't complicate any existing kernel code. 
Besides, doing any kernel change means waiting about 3-4 months for 2.6.26 to 
be released. If we work out a standard that is backwards compatible, it 
should work all the way back to about 2.6.16.

I don't think every audit rule will get this treatment. In IDS, there are very 
few files that you'd want to have alerting on by default. So, maybe the best 
thing to do is bump up the key field size from 32 to 48 bytes to allow more 
room for this kind of thing? Or would 64 bytes be better? We should be able 
to make this change without too much worry. The kernel should truncate the 
key if we have new tools on old kernel and if old tools on new kernel, 
auditctl should complain if its too big. Either way, it should be apparent.

To improve support for this kind of usage, I was thinking that we could update 
auditctl so that it could selectively delete all by key and that it could 
list all rules by key. IOW,

auditctl -D -k ids-
auditctl -l -k ids-

Any other improvements/suggestions to aid support of this paradigm?


> Still need to iterate through all keys in the worst case, but the
> plugins could individually chose between having the rules hardcoded (for
> speed) or configurable.

Sure.

-Steve