Re: [security-onion-testing] Anyone else recently start receiving event-msg not passed to DB?

[beenph]

I just commited an updated barnyard2 version that support sig-msg.map(v1) as well as sid-msg.map(v2) format.

 

This is a minor change and it should go really smoothly but it still require some testing.

You can get it from : https://github.com/binf/barnyard2/tree/sid-msgv2

 

 

by2 should auto detect which version to use and behave accordingly.

 

People used to the new database output plugin could be surprised to see that most of the signature will now be inserted at startup if your

database is fresh, or if you where already using the plugin, alot of new signature could appear.

 

This is due to the fact that the new sid-msg.map file include signature revision, so

they are insertd at the initialization phase, if their not present in the database, instead

of keeping them in cache waiting for a matching event to update the revision and log its first version.

 

So if you upgrade from sid-msg.map(v1) to a sid-msg.map(v2) file using PP don't be surprised to see

alot more signatures in your favorite UI when its first starting.

 

WARNING:

The differences betwen a regular sid-msg.map file and a sid-msg.mapv2 file is mainly the

 

#v2 at the start of the file and the additional fields.

 

If you modify that file format (removing the #v2 from a sid-msg.mapv2)

the result when parsing could lead to a crash, you have been warned.

 

If you try to add a #v2 tag to a v1 file you could get unexpected result in some cases

 (if you have a signature with alot of reference field, they would count

 in the defined minmum number of field ([4] sid||gid||rev||msg)  for a valid v2 line which would obviously lead to funky result.

EOW

 

-elz

 

On Wed, Dec 12, 2012 at 9:43 AM, JJC <cumm...@gmail.com> wrote:

As an FYI, we are working on a new sid-msg.map format (say, v2) that will account for this type of behavior as well as rev mapping and the capability to add preproc sids.. ala:

gid || sid || rev || msg || ref1 || ref2 || etc...

expect an update to PP and By2 soon :-)

On Friday, October 26, 2012 8:35:02 AM UTC-6, Eric Lauzon wrote:

On Fri, Oct 26, 2012 at 10:26 AM, beenph <bee...@gmail.com> wrote:

> On Fri, Oct 26, 2012 at 10:22 AM, Doug Burks <doug....@gmail.com> wrote:
>> On Fri, Oct 26, 2012 at 10:08 AM, Gcracker <graham....@gmail.com> wrote:
>>> Eureka!
>>>
>>> Funny thing is, now it's showing gen_id=1 instead of 3. Is that good?
>>
>> Hi gcracker,
>>
>> Thanks for your bug report!  I can confirm this behavior.
>>
>> elz, looks like your code change just changed gid 3 to gid 1:
>> https://github.com/binf/barnyard2/commit/c3dc4b70c502796eaea5608c60f959a58bb1dab5
>>
>> Is there a way to keep gid 3 so that it displays in Snorby correctly?
>
> I clearly know what my change is, and its the intended objective if
> you take that SO rules definitions
> are inserted in sid-msg.map file instead of gen-msg.map file.
>
> So its like 2-1.9. :) The commit comment is kind of self explainatory.
>
> for me to use gid 3 SO objects should be inserted into gen-msg.map
> file instead of being inserted in rule file
>
> Go punch JJC and tell me if he fixes that for you.
>

I just wanted to add  sorry for the ways the previous mail was written
but i was writing a lenghty e-mail to r
eply to Graham and your poped, trashed what i did
and well when i read it back it can sound ackward.

<legacy existance of this in map.c>
<SNIP>
SigNode *GetSigByGidSid(u_int32_t gid, u_int32_t sid)
{
/* set temp node pointer to the Sid map list head */
SigNode *sn = sigTypes;
/* a snort general rule (gid=1) and a snort dynamic rule (gid=3) use the */
/* the same sids and thus can be considered one in the same. */
if (gid == 3)
gid = 1;
</SNIP>

But again if SO objects where in gen-msg.map file they would be logged
correctly with gid 3 sid XXX and rev XXX.

But , gen-msg.map does not support signature reference information.


-elz

--
You received this message because you are subscribed to the Google Groups "security-onion-testing" group.
To post to this group, send email to security-on...@googlegroups.com.
To unsubscribe from this group, send email to security-onion-te...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion-testing?hl=en-US.