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
and....
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
process..
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
snort.conf..
Thanks,
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@appliedwatch.com
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 STASH $HTTP_PORTS
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;
... ) var HTTP_PORTS $STASH
# 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.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
shotput a projector? How fast can you ride your desk chair down the
office luge track? If you want to score the big prize, get to know the
little guy. Play to win an NEC 61" plasma display:
http://www.necitguy.com/?r=20
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
