Snort mailing list archives
Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?
From: Jason Brvenik <jason () sourcefire com>
Date: Mon, 21 Mar 2011 16:32:59 -0400
or using a reference tag referring to the previous rules? On Mon, Mar 21, 2011 at 4:05 PM, Jason Wallace <jason.r.wallace () gmail com> wrote:
What is the issue with tagging them in the msg? On Mon, Mar 21, 2011 at 3:58 PM, Matthew Jonkman <jonkman () emergingthreatspro com> wrote:If we re-sid though it'll be very difficult to manage them or identify the duplicated rules if you pull in the vrt rules as well. We won't have them all in one file, or likely with a unique tag in the title. They'll be distributed as they are now in their respective categories. If we plan well and bring some extra manpower online for the re-sid we could conceivably get them into a contiguous sid range to help with automated enabling/disabling. That'll be a challenge though. Matt On Mar 21, 2011, at 3:46 PM, Jason Wallace wrote:No, it makes it easier to combine them, in my opinion, because then we could pick and chose between the ET distributed GPL rules and the VRT distributed rules. That is not possible today, because they use the same SID and most rule management tools are SID driven so you can't enable/disable a SID without SID duplication. The no-gpl model requires a user to either use VRT+ET-no-gpl, just the VRT, or just the ET set. We can't chose to use one gpl rule from the VRT and another gpl rule from ET, because the two can't exist at the same time. Like Mike said, the whole idea of coverage duplication being an issue is a completely invalid, because that is already a nightmare now. There is no valid reason to not fork and re-SID. That act will finally put and end to this problem and let US, the end user, make our own desiccation about where we get rules from without being forced down some predetermined path. Thx, Wally On Mon, Mar 21, 2011 at 3:23 PM, Matthew Jonkman <jonkman () emergingthreatspro com> wrote:But fork and re-sid makes it tough for folks to combine the open ruleset with VRT. That'd be easiest for us long term, but doesn't make it easy for us to do the no-gpl rulesets. If folks are happy with not being able to easily combine with VRT then we can go that direction. Matt On Mar 21, 2011, at 3:14 PM, Jason Wallace wrote:+1 Well stated, Mike. That is, point-for-point, exactly my opinion as well. Thx, Wally On Mon, Mar 21, 2011 at 2:18 PM, Mike Lococo <mike.lococo () nyu edu> wrote:Matt,So staying in sync will be an issue if VRT is the master record of the rules. So perhaps our only option is to completely fork. But then I still don't feel we need to re-sid since the original intent will still be the same for each signature. So the references will still apply, and I don't think we'll have collision issues as we distribute rulesets with and without.This proposal appears to be an extension and formalization of what's been happening already. Please recall that this thread was started because of the problems this solution is causing today in the ET community (from my previous message):1- Loss of rule-selection control by the snort-admin. In a sid-overlap world, it's not possible to run VRT + ET with the ET-GPL variants. It's also not possible to pick-and-choose individual GPL rules between the projects or test both in parallel. Re-sid'ing puts rule-selection control in the hands of the snort-admin where it belongs, not in the hands of the rules- projects that have little incentive to cooperate on producing a compatible combined-ruleset. 2- Confusion about who to submit patches to, especially as the rulesets diverge (which they are already doing). 3- Snort-admins now have a confusing choice to make as to whether to download the gpl or no-gpl versions of ET/ETPro. The choice can't be avoided or delayed, and there's no documentation at rules.emergingthreats.net that helps inform you how to make the decision. In a re-sid'ed world, the GPL choice becomes an optional performance-optimization or rule-tuning activity, not a blocker to acquiring your first ruleset. 4- Pulled pork required patching to allow duplicate sids, which means that admins are now much more likely to ignore real/broken duplicate sid-instances in their setups resulting in missed-detections and unnecessary troubleshooting.The arguments against re-sidding appear to be: a- "It's against the spirit of the GPL." The purpose of the GPL is to ensure Freedoms are preserved up-and-down the consumption chain, not to enforce cooperation between any two specific groups or prevent snort-rules from changing sids. Forking when projects disagree is well-within the spirit of the GPL, and engineering the fork to minimize cross-project dependencies (eg rule-sync of duplicated sids) ensures that the projects can operate without stepping on each other's feet and causing bad blood. b- "Duplicated rule-functionality will cause poor performance." This ship has definitively sailed, there is already an *ENORMOUS* amount of rule duplication between the ET and VRT, and even more between ETPro and VRT. The amount of redundancy *IS* going to increase as ETPro expands. The "nogpl" download-variants do not eliminate redundancy, and such a scheme cannot scale to do so. Users who choose to run both rulesets either have the sophistication to pick-and-choose, or want multi-vendor redundancy in some areas as a sanity-check. See (1). c- "Re-sidding is unnecessary." It's only unnecessary if the projects can function cooperatively to stay in sync. It could not be more clear that the projects are NOT doing so right now. See (2) and every message in this thread. d- "You don't need to run both rulesets anyway." This decision should be in the hands of the on-site admins, the rules-projects should not force them to abandon one of the rulesets. See (1). e- "Nogpl variants solve this problem." They don't, you can't pick and choose on a sid-by-sid basis, and you can't use the "improved" ET-GPL variants if you run any VRT rules at all. See (1). Please fork and re-sid, it's better for your community and for your customers. Best Regards, Mike Lococo _______________________________________________ Emerging-sigs mailing list Emerging-sigs () emergingthreats net http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!_______________________________________________ Emerging-sigs mailing list Emerging-sigs () emergingthreats net http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!---------------------------------------------------- Matthew Jonkman Emergingthreats.net Emerging Threats Pro Open Information Security Foundation (OISF) Phone 765-807-8630 x110 Fax 312-264-0205 http://www.emergingthreatspro.com http://www.openinfosecfoundation.org ---------------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc---------------------------------------------------- Matthew Jonkman Emergingthreats.net Emerging Threats Pro Open Information Security Foundation (OISF) Phone 765-807-8630 x110 Fax 312-264-0205 http://www.emergingthreatspro.com http://www.openinfosecfoundation.org ---------------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc_______________________________________________ Emerging-sigs mailing list Emerging-sigs () emergingthreats net http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!
------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ 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
Current thread:
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?, (continued)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Joel Esler (Mar 21)
- Message not available
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Wallace (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Weir, Jason (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Wallace (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Weir, Jason (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jeff Kell (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Wallace (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Brvenik (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Joel Esler (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? waldo kitty (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? NA (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Mike Lococo (Mar 23)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Joel Esler (Mar 21)