[RFC] programmatic IDS routing

[LC Bruzenak]

On Fri, 2008-03-21 at 08:50 -0400, Steve Grubb wrote:
> On Friday 21 March 2008 06:28:42 Klaus Heinrich Kiwi wrote:
...
> 
> 
> > 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 prefer this approach - NOT putting more than 1 key item in the key
field. I see order issues. I see myself repeating this phrase many
times, "No - the IDS part is first, then the comma, then the optional
extra part."
And given the data already proposed for the key in the IDS instance, I'd
say that I cannot think of what else we'd need in the key anyway.

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

Rather than make it a bigger monolithic size I'd prefer more keys
somehow. My first thought was to overload the key field based on the
event. For IDS events one would specify "-K" (for example) and the IDS
triple Steve proposed as appropriate in the 31-byte text area. For
another plugin need, choose a different constant - "-I" - or whatever.

This would make it not possible to have multiple plugin keys per event,
unless the overall key size were large enough to accommodate multiples.
But the important part to me is that the auditctl take care of any
ordering issues, rather than faulty people.

If many key-needing plugins are proposed, that to me suggests a dynamic
key length, which I doubt is preferable.

> 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-
> 
This sounds like a good idea.

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

I'd vote hardcoded not for speed because IIUC I believe it would
simplify administration.

Thanks,
LCB.

-- 
LC (Lenny) Bruzenak
lenny at magitekltd.com