From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: [RFC] programmatic IDS routing Date: Wed, 19 Mar 2008 17:31:49 -0400 Message-ID: <47E18645.5060005@hp.com> References: <200803191302.48434.sgrubb@redhat.com> <200803191528.55805.sgrubb@redhat.com> <47E16FAB.4010601@hp.com> <200803191701.35669.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200803191701.35669.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Linux Audit , Valdis.Kletnieks@vt.edu List-Id: linux-audit@redhat.com 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