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

Mike Poor mike at ...2444...
Wed Jun 15 08:03:32 EDT 2005


Then I take it back, sorry.  I guess your product automatically pulls 
bleeding-snort rules and directly imports them into the snort sensors. 
Perhaps you could fix this by having your product run Snort -Tc snort.conf 
to test the config files and the snort rules for errors.

I noticed that you have a rules editor... can you edit the snort.conf file 
there too?

Personally, I like the idea of an ssh port var, but can see that this would 
mess people up if they did not read the announcement on bleedingsnort prior 
to applying the rules.


Mike

--On Thursday, June 9, 2005 9:08 AM -0500 Eric Hines 
<eric.hines at ...1663...> wrote:

> Mike,
>
> Applied Watch is not an MSSP, nor did we push them out to our customers.
>
>
>
> Best Regards,
>
> Eric Hines, GCIA, CISSP
> CEO, President, Chairman
> Applied Watch Technologies, LLC
> 1134 N. Main St.
> Algonquin, IL 60102
> Tel: (877) 262-7593 e:327
> Fax: (877) 262-7593
> Mob: (847) 456-6785
> Web: http://www.appliedwatch.com
> -------------------------------------------------------------------------
> --- -
> Enterprise Snort Management at http://www.appliedwatch.com.
> Security Information Management for the Open Source Enterprise.
> -------------------------------------------------------------------------
> --- -
> -----Original Message-----
> From: Mike Poor [mailto:mike at ...2444...]
> Sent: Thursday, June 09, 2005 8:54 AM
> To: eric.maheo at ...1663...; emf at ...3056...
> Cc: bleeding-sigs at ...2727...; 'snort-sigs mailinglist'
> Subject: Re: [Snort-sigs] If You're Using Bleeding Snort Rules Read This!!
>
> look, from an engineering point of you... you guys f*cked up.  At the very
> minimum, your clients deserve:
>
> - download new ruleset from wherever you do...
> - upload them to a test sensor
> - run rules against test data
> - compare the results
> - analyze the results
> - if positive, push rules out to customers
> - if negative, fix the problem, then push rules out to customers, push fix
> back to wherever you got your rules
>
>
> --On Wednesday, June 8, 2005 11:29 PM -0500 Eric Maheo
> <eric.maheo at ...1663...> wrote:
>
>> 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 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 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>
>
>
>
>
>
>








More information about the Snort-sigs mailing list