prelude events

prelude events

[LC Bruzenak]

I don't think file watch events are reported to prelude...right?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: prelude events

[LC Bruzenak]

I think I just saw the answer in the audisp-prelude man page:

...
-w /etc/shadow -p wa

       and you want idmef alerts on this, you need to add -k
ids-file-med  or something appropriate to signal  to  the  plugin
       that  this  message is for it.
...

LCB.

On Mon, 2008-08-25 at 15:20 -0500, LC Bruzenak wrote:
> I don't think file watch events are reported to prelude...right?
> 
> Thx,
> LCB.
> 
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: prelude events

[Steve Grubb]

On Monday 25 August 2008 16:24:35 LC Bruzenak wrote:
> I think I just saw the answer in the audisp-prelude man page:
> ...
> -w /etc/shadow -p wa
>
>        and you want idmef alerts on this, you need to add -k
> ids-file-med  or something appropriate to signal  to  the  plugin
>        that  this  message is for it.

Yes, you'd add  -k ids-file-  and the one of: info, low, med, or high 
depending on how severe you consider this access.

-Steve

Re: prelude events

[LC Bruzenak]

On Mon, 2008-08-25 at 16:41 -0400, Steve Grubb wrote:
> On Monday 25 August 2008 16:24:35 LC Bruzenak wrote:
> > I think I just saw the answer in the audisp-prelude man page:
> > ...
> > -w /etc/shadow -p wa
> >
> >        and you want idmef alerts on this, you need to add -k
> > ids-file-med  or something appropriate to signal  to  the  plugin
> >        that  this  message is for it.
> 
> Yes, you'd add  -k ids-file-  and the one of: info, low, med, or high 
> depending on how severe you consider this access.
> 
> -Steve

...and of course then that made me think if we can do this for the file
watches, why not for user-submitted events also? Some of these I am
already sending into the prelude system via patched audisp-prelude.c
code, but I'd prefer to rip out this hack and instead just have a
matching key identified.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: prelude events

[LC Bruzenak]

On Mon, 2008-08-25 at 15:47 -0500, LC Bruzenak wrote:
> On Mon, 2008-08-25 at 16:41 -0400, Steve Grubb wrote:
> > On Monday 25 August 2008 16:24:35 LC Bruzenak wrote:
> > > I think I just saw the answer in the audisp-prelude man page:
> > > ...
> > > -w /etc/shadow -p wa
> > >
> > >        and you want idmef alerts on this, you need to add -k
> > > ids-file-med  or something appropriate to signal  to  the  plugin
> > >        that  this  message is for it.
> > 
> > Yes, you'd add  -k ids-file-  and the one of: info, low, med, or high 
> > depending on how severe you consider this access.
> > 
> > -Steve
> 
> ...and of course then that made me think if we can do this for the file
> watches, why not for user-submitted events also? Some of these I am
> already sending into the prelude system via patched audisp-prelude.c
> code, but I'd prefer to rip out this hack and instead just have a
> matching key identified.


I don't know why I cannot think until after I hit the "send" button...
:)

The problem there is that I still want to build the prelude event with
some added name=value information I stuck in to the audit event text,
which I'd like to see in the prewikka viewer.

LCB.
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: prelude events

[Steve Grubb]

On Monday 25 August 2008 16:47:38 LC Bruzenak wrote:
> > Yes, you'd add  -k ids-file-  and the one of: info, low, med, or high
> > depending on how severe you consider this access.
>
> ...and of course then that made me think if we can do this for the file
> watches, why not for user-submitted events also? 

The problem is that user space originating events do not have keys. So, there 
is no way to setup audit policy from the audit configuration. You could try 
adding them in the message being sent to the kernel. But this then means its 
hardcoded and no one can change it to something lower if they don't like it.


> Some of these I am already sending into the prelude system via patched
> audisp-prelude.c code, but I'd prefer to rip out this hack and instead just
> have a matching key identified.

There is a lot of specialized information aside from the key that must go into 
an alert. Source and target of attack must be clearly identified, impact, 
severity, category, etc. Not sure how to get that from a generic key. Any 
ideas along this line?

-Steve

Re: prelude events

[LC Bruzenak]

On Mon, 2008-08-25 at 17:09 -0400, Steve Grubb wrote:
> On Monday 25 August 2008 16:47:38 LC Bruzenak wrote:
> > > Yes, you'd add  -k ids-file-  and the one of: info, low, med, or high
> > > depending on how severe you consider this access.
> >
> > ...and of course then that made me think if we can do this for the file
> > watches, why not for user-submitted events also? 
> 
> The problem is that user space originating events do not have keys. So, there 
> is no way to setup audit policy from the audit configuration. You could try 
> adding them in the message being sent to the kernel. But this then means its 
> hardcoded and no one can change it to something lower if they don't like it.

Yes.

> 
> 
> > Some of these I am already sending into the prelude system via patched
> > audisp-prelude.c code, but I'd prefer to rip out this hack and instead just
> > have a matching key identified.
> 
> There is a lot of specialized information aside from the key that must go into 
> an alert. Source and target of attack must be clearly identified, impact, 
> severity, category, etc. Not sure how to get that from a generic key. Any 
> ideas along this line?

I think it would be quite difficult to figure out how to get that
information into/out of a key...

I only really care about the source (UID/GID/PID/processname) and the
audit text and serial number (added as additional data), assuming the
severity is high enough, to go into the prelude event. 

I guess the option still exists for users to just add their own
customized prelude plugin; essentially emulating all the same things
your code already does. But I didn't relish having to duplicate all the
administration and the code.

Along those lines, I was thinking that another option would be a
separate pass-through event, meant only for the plugin(s). If the event
was free-form from the audit perspective (maybe a structure with length
+ buffer), but its format was part of the audisp-plugins RPM, it would
probably work. 

In the end, this is what I'm really doing - sending a pass-through to
the established audit->prelude connection. I'm probably misusing the
intent to my own ends...

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com