From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>, Valdis.Kletnieks@vt.edu
Subject: Re: [RFC] programmatic IDS routing
Date: Wed, 19 Mar 2008 19:00:41 -0400 [thread overview]
Message-ID: <47E19B19.1020803@hp.com> (raw)
In-Reply-To: <200803191842.50206.sgrubb@redhat.com>
Steve Grubb wrote:
> On Wednesday 19 March 2008 17:41:07 Eric Paris wrote:
>> So maybe all we need is for the ids config file needs to be of the form
>>
>> key type priority
>
> And hostname. Remember that this could be run from an aggregator.
>
>
>> so I can set up my audit rule however I want say
>>
>> -a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F dir=/etc -k
>> 500EPERM -a always,exit -F perms=wa -F subj_role=webadmin_r -F exit=-EPERM
>> -k webadminEPERM
>>
>> And my ids config file would look like:
>>
>> 500EPERM file med
>> webadminEPERM exec high
>
> This is pretty close to the idea that I started with. Then I thought, how do I
> make this engine run faster? How do I reduce memory consumption (since the
> keys have to be stored in memory)?
How does overloading the key field help either of those?
> How do I make sure that the keys are there and correct?
That can be a startup check.
>
>> And on startup the ids can easily look to see if 500EPERM and
>> webadminEPERM are actually keys to real rules just for sanity sake.
>
> Sure...but audit rules are loaded after auditd starts so that we can record
> them being put into effect. So, you would have to wait for a a while after
> startup to do this.
So the IDS starts after auditd, but it depends on auditd anyway.
>
>> Is the reverse mapping from key to ids action really so expensive that this
>> is unreasonable?
>
> Consider a datacenter with many hosts that may want to run this off of the
> aggregator. There will be a high rate of incoming events and a bit of
> comparing to figure out if each event something we care about.
I think if someone is using audit as an IDS, they're going to care about
everything they're auditing or why are they auditing it?
>
> With my proposal, I can tell with strncmp(key, "ids-", 4) if this is anything
> we need to pay attention to. So, inspection of 4 bytes let me decide yes/no.
Who is doing this, the auditd, the dispatcher or the plugin?
Couldn't you hash the key?
> Its a finite amount of time and doesn't linearly slow down the system as more
> hosts and files of interest are configured. It scales well.
>
>
>> I tend to also agree with the part of the discussion which says that it
>> isn't audit's place to decide that some rules are meant for disk and
>> some rules aren't.
>
> I agree and never proposed that.
I guess Eric and I were both confused then by your comment about the
admin ending up with more audit events on disk than intended.
-- ljk
>
> -Steve
next prev parent reply other threads:[~2008-03-19 23:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 17:02 [RFC] programmatic IDS routing Steve Grubb
2008-03-19 17:12 ` Linda Knippers
2008-03-19 17:40 ` Steve Grubb
2008-03-19 17:55 ` Steve Grubb
2008-03-19 18:18 ` Valdis.Kletnieks
2008-03-19 18:54 ` Steve Grubb
2008-03-19 20:09 ` Valdis.Kletnieks
2008-03-19 18:05 ` Valdis.Kletnieks
2008-03-19 18:40 ` Steve Grubb
2008-03-19 19:04 ` Linda Knippers
2008-03-19 19:28 ` Steve Grubb
2008-03-19 19:48 ` Eric Paris
2008-03-19 20:48 ` Steve Grubb
2008-03-19 19:55 ` Linda Knippers
2008-03-19 21:01 ` Steve Grubb
2008-03-19 21:31 ` Linda Knippers
2008-03-19 21:41 ` Eric Paris
2008-03-19 22:42 ` Steve Grubb
2008-03-19 23:00 ` Linda Knippers [this message]
2008-03-19 23:44 ` Steve Grubb
2008-03-20 13:32 ` Linda Knippers
2008-03-20 13:53 ` Steve Grubb
2008-03-21 10:28 ` Klaus Heinrich Kiwi
2008-03-21 12:50 ` Steve Grubb
2008-03-21 14:14 ` LC Bruzenak
2008-03-21 15:01 ` Steve Grubb
2008-03-21 16:32 ` LC Bruzenak
2008-03-24 13:13 ` Klaus Heinrich Kiwi
2008-03-20 12:19 ` Steve Grubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E19B19.1020803@hp.com \
--to=linda.knippers@hp.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.