Active response command issue + solution

[Robert]

Greetings.

We've deployed OSSEC into an environment with the primary purpose of
parsing large amounts of log data on a centralized syslog-ng server.
This deployment has been successful, but we ran into some fairly
annoying limitations that was causing us significant headache with
passing relevant decoded alert data into an external script which
handles passing the alert into our existing internal monitoring
systems. Our expectation (and requirement) is to have some of the
decoded data passed into the command, so that the fields can either
have either further automated analysis done, or simply to forward the
decoded fields into a ticket.

http://www.ossec.net/wiki/Decoder_rules_relation

At the bottom of this document, it specifies a list of fields that can
be used with the <expect> tag in the active-response. Unfortunately,
when we tried to use these fields, it didn't work. Looking at the
source code, we discovered that IP, USER are hard-coded as the only
two fields that OSSEC allows <expect> to be used for.

We've created a patch for 2.6 to allow for all of the fields listed in
your wiki. We've also made the required changes to allow for OSSEC to
pass spaces properly in these fields, as we noticed that any field
passed with expect with a space in it would break our scripts. We've
tested this internally, and everything appears to work perfectly.
We're more than happy to provide this back to you guys to integrate
into a future release.

Let me know if there is a more preferred way of providing this patch.
Here are the changes:

http://pastebin.com/qUBthUGb

[dan (ddp)]

On Tue, Sep 20, 2011 at 10:10 AM, Robert <spe...@custodela.com> wrote:
> Greetings.
>
> We've deployed OSSEC into an environment with the primary purpose of
> parsing large amounts of log data on a centralized syslog-ng server.
> This deployment has been successful, but we ran into some fairly
> annoying limitations that was causing us significant headache with
> passing relevant decoded alert data into an external script which
> handles passing the alert into our existing internal monitoring
> systems. Our expectation (and requirement) is to have some of the
> decoded data passed into the command, so that the fields can either
> have either further automated analysis done, or simply to forward the
> decoded fields into a ticket.
>
> http://www.ossec.net/wiki/Decoder_rules_relation
>

The wiki is mostly un-maintained at the moment (I'll have to look at
the docs though to see if they're any better).

> At the bottom of this document, it specifies a list of fields that can
> be used with the <expect> tag in the active-response. Unfortunately,
> when we tried to use these fields, it didn't work. Looking at the
> source code, we discovered that IP, USER are hard-coded as the only
> two fields that OSSEC allows <expect> to be used for.
>
> We've created a patch for 2.6 to allow for all of the fields listed in
> your wiki. We've also made the required changes to allow for OSSEC to
> pass spaces properly in these fields, as we noticed that any field
> passed with expect with a space in it would break our scripts. We've
> tested this internally, and everything appears to work perfectly.
> We're more than happy to provide this back to you guys to integrate
> into a future release.
>
> Let me know if there is a more preferred way of providing this patch.
> Here are the changes:
>
> http://pastebin.com/qUBthUGb
>

Sending the patch, or creating a pull request on bitbucket
(https://bitbucket.org/dcid/ossec-hids) is usually easier.

I do like the idea, hopefully it can be included!

[dan (ddp)]

Oops, forgot to ask:
Did you need to make any changes to any of the active response scripts?

On Tue, Sep 20, 2011 at 10:10 AM, Robert <spe...@custodela.com> wrote:

[dan (ddp)]

There's a '^M' at the end of every line in the diff. Removing those
gave the following results:
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -aurBbE src/ossec-hids-2.6/src/analysisd/alerts/exec.c
src/analysisd/alerts/exec.c
|--- src/ossec-hids-2.6/src/analysisd/alerts/exec.c 2011-07-11
15:36:58.000000000 -0400
|+++ src/analysisd/alerts/exec.c 2011-09-01 11:57:59.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/analysisd/alerts/exec.c using Plan A...
Hunk #1 failed at 25.
Hunk #2 succeeded at 50.
Hunk #3 failed at 66.
Hunk #4 failed at 242.
Hunk #5 failed at 275.
4 out of 5 hunks failed--saving rejects to
ossec-hids-2.6/src/analysisd/alerts/exec.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|diff -aurBbE src/ossec-hids-2.6/src/analysisd/analysisd.c
src/analysisd/analysisd.c
|--- src/ossec-hids-2.6/src/analysisd/analysisd.c 2011-07-11
15:36:58.000000000 -0400
|+++ src/analysisd/analysisd.c 2011-09-01 11:57:59.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/analysisd/analysisd.c using Plan A...
Hunk #1 succeeded at 1038 with fuzz 2.
Hunk #2 succeeded at 1059.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|diff -aurBbE src/ossec-hids-2.6/src/config/active-response.c
src/config/active-response.c
|--- src/ossec-hids-2.6/src/config/active-response.c 2011-07-11
15:36:58.000000000 -0400
|+++ src/config/active-response.c 2011-09-01 11:57:59.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/config/active-response.c using Plan A...
Hunk #1 succeeded at 410.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|diff -aurBbE src/ossec-hids-2.6/src/headers/ar.h src/headers/ar.h
|--- src/ossec-hids-2.6/src/headers/ar.h 2011-07-11 15:36:58.000000000 -0400
|+++ src/headers/ar.h 2011-09-01 11:57:59.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/headers/ar.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 38.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|diff -aurBbE src/ossec-hids-2.6/src/os_execd/execd.c src/os_execd/execd.c
|--- src/ossec-hids-2.6/src/os_execd/execd.c 2011-07-11
15:36:59.000000000 -0400
|+++ src/os_execd/execd.c 2011-09-01 15:06:06.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/os_execd/execd.c using Plan A...
Hunk #1 succeeded at 396 with fuzz 2.
Hunk #2 succeeded at 439.
Hunk #3 succeeded at 447.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -aurBbE src/ossec-hids-2.6/src/os_execd/execd.h src/os_execd/execd.h
|--- src/ossec-hids-2.6/src/os_execd/execd.h 2011-07-11
15:36:59.000000000 -0400
|+++ src/os_execd/execd.h 2011-09-01 11:57:59.000000000 -0400
--------------------------
Patching file ossec-hids-2.6/src/os_execd/execd.h using Plan A...
Hunk #1 succeeded at 37.
done

I even downloaded 2.6 and got similar results.

On Tue, Sep 20, 2011 at 10:10 AM, Robert <spe...@custodela.com> wrote:

[Exploding Fist]

Nothing needs to change for the scripts. The first 6 fields that are passed today remain the same. What changes is, additional fields will be provided for the additional expects.

I took a look at bitbucket and it looked like quite a bit of effort just to post a patch. I might sign up later if we end up making frequent changes to the code.

For now, I've put up the patch/source here:

http://www.custodela.com/ossec/

This change is on the published 2.6 source. Let me know if you run into additional problems.

[dan (ddp)]

I was actually just looking into it. If I can get it updated I'll post
something to the list.
Thanks for the info and the patch, I Think this could come in really handy.