Re: [RFC] programmatic IDS routing
On Fri, 2008-03-21 at 11:01 -0400, Steve Grubb wrote:
On Friday 21 March 2008 10:14:04 LC Bruzenak wrote:
> 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.
What if it were the duty of the plugins or even log analysis tools to be order
independent? IOW, you can put things in any order you wish?
Works for me! As I said, I doubt that our system will add anything at
all to the key, since I believe there will be enough information already
in the key and the event. The less we (end-user administrators) need to
specify/enforce the better.
As far as the analysis tools, since the event is an IDS event, and
currently the prewikka tool is used to view, will there be enough text
viewable in that event to make sense of the severity & action to someone
not intimately familiar with the plugin?
If that answer is yes, I'm satisfied there as well.
> 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.
I'd rather treat this like the -S option where it can be given multiple times
if we go this route. Given the code in the kernel, having multiple key fields
will require some significant patching.
If we felt like we wanted to keep this in one field, but thought 32 bytes was
to restrictive we could easily extend the size.
struct audit_context {
...
char * filterkey; /* key for rule that triggered record */
So, it is virtually unlimited in size since its allocated. The only
restriction is a check in auditfilter.c.
if (entry->rule.filterkey || f->val > AUDIT_MAX_KEY_LEN)
goto exit_free;
So, it would be a simple matter of just changing the define from 32 to 48 or
whatever.
IMHO, the free-form key info is only useful when there is no plugin. I
cannot see using both a plugin key and our own key.
To me, if there is a plugin involved, it should provide all the key
information it needs relevant to the plugin, and so far I think it will.
When we use various keys now for watch events, the reason is because we
have no IDS plugin. The file watches, exec or mkexe events replace our
current ones, and are preferred since they are mainstream and part of
the IDS/audit package.
If you allow for some user space inside the plugin key, well, that is
generous and it may be used but honestly right now I cannot think of a
reason why.
> But the important part to me is that the auditctl take care of any
> ordering issues, rather than faulty people.
I could even fix auditctl to allow multiple -k fields, but glue them together
with commas if that were helpful. I could event fix auditctl to split them
back out for rule listing purposes. We could also fix auparse to be able to
do the splitting in the key field too so that this paradigm is supported and
enforced by the whole toolchain.
So, I could give the illusion of multiple key fields but without making any
drastic kernel changes. Would this be acceptable?
Yep, it would be acceptable and preferred.
In this case you would stretch the key size and warn/enforce size limits
right? Too many commas (or any 1-byte delimiter) start to matter with
~31-47 bytes. As it becomes crowded we start thinking about encoding the
entries, which is OK but opens up more issues. Again, if it is your (the
OS) part doing the work I'm happy! :)
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com