Snort mailing list archives

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


From: Matthew Jonkman <jonkman () gmail com>
Date: Fri, 2 Dec 2011 14:35:11 -0500

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 () googlegroups com


Please visit http://blog.snort.org for the latest news about Snort!


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!


Current thread: