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