3:20 p.m.
I don't think file watch events are reported to prelude...right?
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
3:24 p.m.
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(a)magitekltd.com
3:41 p.m.
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
3:47 p.m.
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(a)magitekltd.com
4:03 p.m.
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(a)magitekltd.com
4:09 p.m.
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
6:41 p.m.
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(a)magitekltd.com
5962
days inactive
5962
days old
linux-audit@lists.linux-audit.osci.io
6 comments
2 participants
participants (2)
-
LC Bruzenak -
Steve Grubb