[Snort-users] [Snort-Sigs] Re: [Emerging-Sigs] [Snort-sigs] Snort 2.8.6.1 EOL Reminder

Matthew Jonkman jonkman at ...11827...
Fri Dec 2 14:35:11 EST 2011


On Dec 2, 2011, at 2:20 PM, Joel Esler wrote:
>> I don't believe any of those are in the VRT tarball, so if you want those be sure to use the GPL stuff from our side and filter them out of VRT.
> 
> There is a difference between what you are calling the "GPL" sigs (3464 and below) and "Community" (our old GPL community ruleset that was in the 100,000,000 range).
> 

Ya, there is a difference. We just tag both sets GPL though for simplicity as they're both licensed that way. We haven't changed the sid range on the community rules though (100mil+). That's a pretty small set though, we need to probably make sure we're ok there though.

> Both of those sid ranges are still maintained by us, and we frequently update the 3464 and below sigs.  Updating detection, adding references, adding keywords to be able to use the newest functionality.  That's why the objection was made to move your copy of our sigs up to a different range to eliminate conflict.
> 

Ya, we went through all this for a while, and for a number of reasons (of which I recall a few I'll put below) we decided itd be easier to fork. I did not realize though that you maintain the old community rules in the vrt tarball. Is that really so?

Reasons I recall for the fork though:

1. Any changes vrt makes aren't public for 30 days. We don't want to wait there, or have to be pulling and picking apart the vrt tarball every release to find them.

2. We support many more versions of snort, and we have to maintain the older versions as they were, which makes all sorts of admin headaches when they change to new versions only in the vrt version

3. We support suricata, which does many of those sigs very differently, so again similar admin headache as above

4. I can't recall an example at the moment, but there may be cases where we want to set a flowbit for an ET rule in a gpl sig, which I imagine VRT wouldn't want to maintain if they didn't have the rule which checks it


It isn't any insult that we moved them, don't take it that way. Just too much a burden of admin and room for human error trying to stay in sync. The sig teams on both rulesets and the et community have different philosophies on many things and trying to mesh those isn't all that useful. :)

Additionally, we don't run a cvs or text based backend to track and generate the rules anymore, so merging changes from another source is a manual effort. That alone makes the fork very much more efficient for us. 

They're good sigs, but they have to mesh into the ruleset they're a part of as a whole. Nothing really stands alone anymore.

Make sense?

Thanks Joel

Matt


> --
> Joel Esler
> Senior Research Engineer, VRT
> OpenSource Community Manager
> Sourcefire
> 
> -- 
> To unsubscribe from this group, send email to
> snortsigs+unsubscribe at ...14071...
> 
> 
> Please visit http://blog.snort.org for the latest news about Snort!





More information about the Snort-users mailing list