Re: [RFC] programmatic IDS routing
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