[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] programmatic IDS routing



Steve Grubb wrote:
> On Wednesday 19 March 2008 19:00:41 Linda Knippers wrote:
>> 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?
> 
> I wouldn't call this overloading the key field. The key field's purpose is to 
> allow searches for groups of audit events. You've traditionally used this 
> from the command prompt with ausearch. Now with the auparse library, it can 
> be used programmatically for searching by more utilities.
> 
> The way that it helps is that I can tell yes/no in 4 byte compares and without 
> storing any linked lists, hashes, or binary trees.

This optimization for a user-space component doesn't seem worth the hack.
You are overloading the field.  The manpage says its an arbitrary string of
text.

>>> How do I make sure that the keys are there and correct?
>> That can be a startup check.
> 
> How do you do that remotely?

Same way you would check that audit is running remotely.  You can either
check the state of the target system or not, and if you can, you can look
for rules just as well as any other state - like whether the dispatcher
is configured.  If you can't verify that remotely, then maybe you should
run your IDS locally.

> 
>>>> 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?
> 
> That's not true. When it comes to IDS, the real question is how to effectively 
> escalate events of interest without overloading the decision makers. 
> Something that alerts once a second is of no use to anyone. You want it to 
> pick out the things you really care about for realtime and save everything 
> else for a daily report.

I think what Eric proposed will still let you do that.
> 
> 
>>> 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?
> 
> The IDS plugin.
> 
> 
>> Couldn't you hash the key?
> 
> Yes. Takes more time than strncmp and then you may still have collisions where 
> you walk a list of some kind. This also has the side effect of needing to set 
> aside a good chunk of memory for the hashes - used or not.

But this is user space, right?

> 
>>> 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.
> 
> -a always,exit -F perms=wa -F auid>=500 -F exit=-EPERM -F path=/etc/password
> 
> and
> 
> -w /etc/password
> 
> collect entirely different amounts of data.

So the admin would create the rule he wants, create a unique key and tell
the IDS what the key is and how it should react when it sees a record with
that key.

-- ljk
> 
> -Steve


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]