Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

feature request: disablesid type functionality #35

kraigu opened this Issue Aug 27, 2012 · 4 comments


None yet
3 participants

kraigu commented Aug 27, 2012

I sometimes have occasion to rebuild my database from historical unified2 logs. It would be nice if I could tell barnyard2 to ignore particular SIDs which are present in the u2 logs but which I no longer wish to see as historical alerts from the database.

I think it would be possible to rewrite the u2 logs such that they simply do not contain alerts for these SIDs, but it would be more convenient if by2 could just ignore them for me.

I may try to submit a patch for this, although my C is terrible so I wouldn't expect it would be very good quality. :-)

kraigu commented Mar 11, 2013

/* patched by mpatters and eagerl :D */
    if( (sid >= 2500000) && (sid <= 2600000) )
      LogMessage("INFO: I'm not going to insert this event SID [%u]\n",
/* end patch */

does what I want it to, but possibly not what anybody else does. That goes into Database() in spo_database.c, about line 2415 or so, depending on versions etc. I'm putting the patch here since I nearly lost it from the last time beenph and I created it.


binf commented Mar 11, 2013

Well a better place for this would be to exist at the spooler level, so that as soon as the event is read from unified2 its not even cached and not sent to any output plugin.

This is something that could be usefull and will probably have extented configuration syntax.

To accomodate multiples ranges or single sid or lists.

But a quick and dirty if/elseif/else patch can do the job quickly without an issue also.


binf commented Mar 26, 2013

Well the guy (by the guy I meant you :P obviously referring as a 3rd party make it more interesting)
is gonna be happy.

I have prototyped something that I would like you to test ...if you ever have time.

Its still "experimental" thus it could crash even if I have stress tested it a bit and all, but adjustment could be made.

I will commit it to my branch pretty soon so lookup for my sidv2 https://github.com/binf/barnyard2/tree/sid-msgv2

In the configuration file you can do the following.
(The below are examples)

config sig_suppress: (GID):(SID) GID is optional
and SID can be a single sid or a range like below.

config sig_suppress: 10-40
is equivalent to
config sig_suppress: 1:10-40
but not equivalent to
config sig_suppress: 122:10-40

You can define overlapping interval and theorically from my tests
the interval will spread if possible.

If you have two range a large one and a small one the small one will not be inserted,
If you have a single entry and there is a range present that contain the single entry, the single entry will not be inserted since the range validate the single entry.

config sig_suppress: 1:10,20,1:30,2:90-102
config sig_suppress: 1:10,1:30-40,15,10-40,25
config sig_suppress: 1:10,50-55,15,10-20,80,51-52,31-35
config sig_suppress: 2:93,2:95,2:100-101,2:91-122,22-27,2008175,2657,2011766,9900009,2001972,2101623

So with the example above the final list is the following:

+[ Signature Suppress list ]+

-- Element type:[RANGE ] gid:[2] sid min:[90] sid max:[122]
-- Element type:[RANGE ] gid:[1] sid min:[30] sid max:[40]
-- Element type:[RANGE ] gid:[1] sid min:[50] sid max:[55]
-- Element type:[RANGE ] gid:[1] sid min:[10] sid max:[20]
-- Element type:[SINGLE] gid:[1] sid min:[80] sid max:[80]
-- Element type:[RANGE ] gid:[1] sid min:[22] sid max:[27]
-- Element type:[SINGLE] gid:[1] sid min:[2008175] sid max:[2008175]
-- Element type:[SINGLE] gid:[1] sid min:[2657] sid max:[2657]
-- Element type:[SINGLE] gid:[1] sid min:[2011766] sid max:[2011766]
-- Element type:[SINGLE] gid:[1] sid min:[9900009] sid max:[9900009]
-- Element type:[SINGLE] gid:[1] sid min:[2001972] sid max:[2001972]

-- Element type:[SINGLE] gid:[1] sid min:[2101623] sid max:[2101623]

+[ Signature Suppress list ]+

You can try to poke around hard, and let me know how it goes.

Right now the check happened in plugbase, the best place where I could quickly patch it without breaking the spooler, but in the future the hook would be somewhere in the spooler, since with a better event cache, if the event is tagged as suppressed it lookup in the suppress signature will not happen.



binf commented Apr 7, 2013

available in 2-1.13-beta

can close issue.

@firnsy firnsy closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment