[RFC] programmatic IDS routing

[Linda Knippers]

Steve Grubb wrote:
> 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.

To me, what's in the slides looks better.  There are lots of things
an IDS might care about, some of which can be expressed in audit
rules and some which can't.  I think the IDS should make sure that
the rules it cares about are there and it should react when there's
a change to the audit configuration.

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

Well, according to the slides its either layered or plugged in, which
I think is better than tightly integrated.  I don't think audit should
have special knowledge of the things that might be plugged into it.

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

If its a high alert, why wouldn't you also want it on the disk?  And
how would you specify that you do or don't want it written?  Isn't
the function of the auditd to "simply dequeue events from netlink
interface as fast and possible and log them to disk" (slide 17)?
I don't think it ought to be deciding which audit events go to disk
vs. go to specific dispatcher plug-ins.
> 
> 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.

I don't see why this has to progress into a mess.  If someone wants
to use the audit rules to drive what the IDS is looking at, then they
could use existing audit rules and specify, for example, that any audit
event with key "CFG_shadow" are of interest with a specific priority
of alert.  The IDS could even check to see if there's a rule that
has that key, and if not, flag some kind of warning.
> 
> 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.

I'm actually in favor of using the key, just in using it like its used
today.  All the capp watches have unique keys, and an admin could create
more/different rules with different keys.  I think that the IDS
should have different configuration information to tell it what to look
for and what to do with it, rather than embedding it into a short field
in the audit record.  What if other plug-ins also want to use that
field?

-- ljk
> 
> -Steve