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

[Nigel Houghton <nhoughton () sourcefire com>]

On Mon, 21 Mar 2011 13:48:51 -0400, Joel Esler wrote:
> Agree, that's our standard practice and suggestion.  The issue comes 
> up as Emerging Threats has taken the GPL sigs (3464 and below) and 
> has included them in their ruleset and made modifications.
>
> I've made the suggestion that ET please submit these changes back to 
> the VRT and if appropriate, we include the updates in the official 
> set.
>
> Basically, ET is using the same sids that we are.
>
> J
>
> On Mon, Mar 21, 2011 at 1:26 PM, Nigel Houghton 
> <nhoughton () sourcefire com> wrote:
> > On Mon, 21 Mar 2011 12:26:58 -0400, Joel Esler wrote:
> > > On Mon, Mar 21, 2011 at 12:25 PM, Nigel Houghton
> > > <nhoughton () sourcefire com> wrote:
> > > > On Mon, 21 Mar 2011 12:10:17 -0400, Joel Esler wrote:
> > > > > That makes sense.  That's basically Marty's #2 point.  I'd say the
> > > > > porn.rules files can be re-sid'ed (referencing Jason's problem) as
> > > > > VRT has dropped those completely, as well as other improved rules can
> > > > > be re-sid.
> > > >
> > > > Like I said earlier, there is no need to re-SID these rules. We won't
> > > > be re-using any of the SIDs from those rules. Any changes to them can
> > > > be better tracked by incrementing the rev number on them and leaving
> > > > the SIDs themselves well alone.
> > >
> > > Okay, but that's the porn rules, what about the rest?
> >
> > Changes to other GPL rules should be handled in a similar manner. Keep
> > the SID bump the rev. We will always modify a rule if there is a change
> > needed. Reasons for the change could be:
> >
> >  1. Improvement in detection functionality provided by new
> > functionality in Snort. In this instance, the rule will be modified for
> > that new version of Snort. Rules for older versions remain untouched
> > and just like it is right now, the rules are shipped on a per-Snort
> > version basis (so the rules still work for a particular version of
> > Snort). This means that rules for older versions do not get a revision
> > bump.
> >
> >  2. False positive/negative content match change or addition of content
> > match to improve detection. In this instance the rule gets modified for
> > all currently supported versions of Snort and the rev for each rule is
> > bumped. For folks who are running non-supported versions, this
> > modification should be done by whoever wants to maintain the rules for
> > those older sets and the rev bumped accordingly. Since rules for
> > specific versions of Snort should be shipped in separate packages, this
> > should not impose a problem.
> >
> >  3. A reference change or addition. Much like #2, the rev gets bumped
> > for all versions of the rule for all versions of Snort.
> >
> > Any reported instances of false positive/negative cases should be
> > reported to the VRT in the usual manner. Suggestions for improvement
> > are certainly welcomed and will be handled appropriately. i.e. consider
> > it a case that fits into #2.
> >
> > If a user makes changes to a rule for their particular environment, the
> > rule should be converted to a local rule and given a local SID. Then
> > the user can disable the original rule and make changes as appropriate
> > should the original rule be changed for some reason. This does of
> > course mean that the user should implement a tracking mechanism for
> > their local rules and the original rules they are based off.
> >
> > I do not see a case for copying rules and re-numbering for distribution
> > to the general populace. This just makes the job of managing rules
> > needlessly more complex for the end user. FWIW, we are more than
> > capable of incorporating changes to rules and re-distributing them in a
> > very short space of time if the need arises (as in, we can do this in a
> > matter of minutes if no QA, other than running the rule over test pcaps
> > for that vulnerability is required or full regression testing is not
> > needed). However, we are not inclined to issue rule changes at the drop
> > of a hat and then have to re-issue the rules shortly thereafter because
> > the change either did not work or introduced a false positive/negative
> > case. If anyone has suggested rule changes, our advice is to test your
> > change thoroughly in your environment first (i.e. go the local SID
> > route) to see if anything untoward or unexpected occurs.

I see. In that case, ET should act as an end-user, copy the rule to 
another file, give it a new SID and leave the original alone and 
disabled in the rule file. If the change is appropriate, send the 
suggested modification along to us and we will handle it. In the case 
of the modification being needed for a currently supported version of 
Snort, the rule will get the update for each version (see #2). In the 
case of older, non-supported versions, the rule can remain where it is 
and any modification distributed for that version of Snort as the 
maintainer sees fit. Since we do not maintain rules for outdated 
versions of Snort, there will be no SID conflict.

This is a pretty simple process that merely relies on feedback to 
incorporate suitable changes with minimal impact on the end-user.

--
Nigel Houghton
Head Mentalist
SF VRT Department of Intelligence Excellence
http://vrt-blog.snort.org/ && http://labs.snort.org/

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