Snort mailing list archives
Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?
From: Jason Wallace <jason.r.wallace () gmail com>
Date: Mon, 21 Mar 2011 15:14:32 -0400
+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!
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ 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? Joel Esler (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Nigel Houghton (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Joel Esler (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Nigel Houghton (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? waldo kitty (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Joel Esler (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Nigel Houghton (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Martin Roesch (Mar 21)
- 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)