Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?

[Joel Esler <jesler () sourcefire com>]

Would probably be smarter to put them in a gpl.rules or something that way
any tool can easily disable them.

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!



-- 
Joel Esler | http://blog.snort.org | http://vrt-blog.snort.org |
http://blog.clamav.net

------------------------------------------------------------------------------
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