[Snort-sigs] If You're Using Bleeding Snort Rules Read This!!

Eric Maheo eric.maheo at ...1663...
Wed Jun 8 21:32:56 EDT 2005

well.. confronted with the absurdity of Erik Fichtner's comments it is
hard to find arguments since he is spinning the facts..

Now that said, let's try to be constructive..

2 or 3 months ago Sourcefire and Bleeding Edge created the OSSRC. it is
a very nice idea to avoid duplication of rules, overlapping of sids
I think OSSRC should also be the provider of VARIABLES.

This will assure everybody we can use the latest snort version and some
OSSRC rules (bleeding edge for example) without breaking a snort

Actually if you download snort with bleeding edge, snort won't start.
You need to edit your snort.conf and add a variable.

Now I see 2 solutions:
	-a solution is to remove this variable.
	-an other solution is to ask Sourcefire to add this variable in the


Eric Maheo
Vice President of Engineering,

Applied Watch Technologies, LLC
1134 N. Main St.
Algonquin, IL 60102

Tel: (877) 262-7593 x324
Fax: (877) 262-7593

Email: eric.maheo at ...1663...
Web: http://www.appliedwatch.com

On Wed, 2005-06-08 at 13:45 -0700, Erik Fichtner wrote: 
> On Wed, Jun 08, 2005 at 03:26:44PM -0500, Eric Hines wrote:
> > We're Bleeding-edge sponsors and I personally as an admin contribute to the
> > project as well. No need to remind me of the Bleeding-edge Mantra or
> > disclaimers. 
> ...Says the guy that set up his paying customers to automatically download
> a pile of rules from the bleeding-edge repository.    Do we have to go
> off and rename it "This-Will-Tear-Your-Sensor-A-New-SnortHole-sigs" ?
> C'mon.  Don't blame us for your design decisions.
> > The fact of the matter is, going off and creating a bunch of custom
> > variables outside of the standard variables declared in the default
> > snort.conf should be up to the individual user. Imagine what would happen if
> > every person out there who contributes a Bleeding-edge snort rule decided to
> > go off and make their own variables for all their sigs -- that would be
> > thousands of new variables people would need to add to their snort.conf -- I
> > mean come on.
> > 
> > You misspoke regarding your statement on buggy tools. Software isn't buggy
> > because it doesn't go in to a rules file for the user and add custom
> > variables that you conjure up.
> # this is my crazy rule, watch out!
> var HTTP_PORTS [4323:5000]
> alert tcp any any -> any $HTTP_PORTS (msg:"crazy rule"; sid: 111111111; ... )
> var HTTP_PORTS 9999
> alert tcp any any -> any $HTTP_PORTS (msg:"crazy rule"; sid: 111111111; ... )
> # okay, the craziness is done.
> ..is perfectly valid snort configuration syntax.  the ONLY difference
> between snort.conf and $mumble.rules is *CONVENTION*.    You ignore this
> at your peril.
> Allowing variables near rules is desirable. 
> Boy, are your customers going to be pissed off when I leak a rule that
> comes with its own ruletype specifier and have a compelling enough
> reason that everyone agrees to publish it. 

More information about the Snort-sigs mailing list