[RFC] programmatic IDS routing

[Steve Grubb]

On Wednesday 19 March 2008 15:55:23 Linda Knippers wrote:
> > Because this IDS is part of the audit system.
>
> Is there something that describes what you're building so we can
> have the right context to comment on this?

I presented this:

http://people.redhat.com/sgrubb/audit/summit07_audit_ids.odp

at last year's Red Hat Summit. The idea is roughly the same, but the 
configuration is slightly different.

> I assumed you were building something that would be a dispatcher plug-in or
> something rather than building something new into the core audit subsystem.

It is. Its tightly integrated.

> >> If an IDS has a dependency on audit and specific audit rules to get the
> >> information it needs, it can use the information in its config file to
> >> construct the audit rules it needs.
> >
> > Then you surely have duplicate rules controlled by 2 systems. The first
> > rule in the audit.rules file is -D which would delete not only the audit
> > event rules for archival purposes, but any IDS placed rules. There is not
> > a simple way of deleting the rules placed by auditctl vs the ones placed
> > by the IDS. The IDS system would also need to be prodded to reload its
> > set of rules again.
>
> An IDS should be able to be prodded to reload its rules.

Sure, but you have the audit system loading CAPP rules with all those watches 
and then maybe the admin wants any write to shadow to be a high alert since 
he's the only user and won't be changing his password. We would either need 
to analyze the rules and make sure they are simplistic enough for the IDS to 
be guaranteed an event, or just add more rules to make sure we got 'em. In 
this case, we may windup creating records that the admin did not want on the 
disk. 

i just see this as progressing into a mess. We have 2 things that have 
different ideas about what needs to be tracked. Neither understanding why the 
other is doing something and not happy because either too much data is going 
to disk or not enough events to trap something important.

By using the key field, its in plain sight and done with purpose. Not enough 
events to trap something important, widen it in audit.rules and you also know 
that this will send more to disk. No suprises there.

-Steve