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

Wes Young wcyoung at ...2584...
Thu Jun 9 12:33:17 EDT 2005

Hash: SHA1

haha, I really hope your customers don't read this thread... you just
got a gold star... you told a hacker to stop being obnoxious....

....thats like telling Microsoft that IE is a security hole... there
just isn't a point to it anymore.

"Thats what the internet is for, slandering of other people anonymously,
stopping the movie isnt going to change any of it"

erik.. keep hack'n bud... keep hack'n ;-)

Eric Hines wrote:
> Erik,
> Are you physically unable to shut up and move on? I thought the rest of us
> had already done that. You seem to be a little slow so I'll address your
> individual statements below:
> #1) Go take a grammar school class:
>     - Customer's == possessive
>     - Customers == plural
> "Plural forms: The plural form of a noun indicates simply that there are
> more than one of the person or thing in question. For most nouns, the plural
> form includes the letter "s" at the end of the word (e.g. Dogs, Trees,
> Turtles)."
> "Possessive forms: A possessive form of a noun signifies that the noun owns
> something: A musician's talent, A woman's ambition, Customer's Snort Sensors
> Possessive forms call for a properly placed apostrophe. The placement is
> different for singular and plural nouns. For this reason, you must know the
> correct singular and possessive nouns before you can make them possessive." 
> #2) Don't make suppositions about products, particularly ours if you don't
> fully understand it. Otherwise, your just spreading FUD: "FUD is an
> abbreviation for Fear, Uncertainty, and Doubt, a sales or marketing strategy
> of disseminating negative but vague or inaccurate information on a
> competitor's product. The term originated to describe misinformation tactics
> in the computer software industry and has since been used more broadly."
> Squash this thread bud..
> 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: Erik Fichtner [mailto:emf at ...3056...] 
> Sent: Thursday, June 09, 2005 1:51 PM
> To: Eric Hines
> Cc: bleeding at ...2727...; snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] If You're Using Bleeding Snort Rules Read This!!
> On Thu, Jun 09, 2005 at 12:45:20PM -0500, Eric Hines wrote:
>>No apologies necessary -- this has been an overly long thread that 
>>people kept adding to. I can see where you might have thought we were 
>>a service provider rather than a product company.
> Actually, I thought you were an MSSP of some kind as well.  
> "These new SSH signatures brought down all of our customer's Snort
> installations";  a direct quote from your initial message in the thread.
> This statement has since been modified to "Let me preface my final email on
> this with the fact 
> that it was just one customer who brought his sensors down".    
> Heat of the moment get to you?
>>I just wanted to make sure I steered people away from trying to attack 
>>our product in this thread and instead address the original issue of 
>>people creating a new $variable every time they contribute a new sig.
> Frankly, I don't care one way or another about your product, or anyone
> else's for that matter.    Stuff like this is another reason why I avoid
> them in favor of my own hand-built junk, but if they're working for you, who
> am I to argue?  
> Adding a "new variable" shouldn't be a big deal for anyone's tool.  That it
> has become a big deal demonstrates that the tools are limiting themselves to
> the concept of "one config file" and "some rules files", when in fact, there
> is only "some configuration data that is parsed linearly at init time".
> (incidentally, how do you handle services on multiple ports?  The snort
> authors suggest var, include, var, include ... in their own example conf
> file.)
> Clearly it wasn't much of a big deal when these ssh sigs went out on the 3rd
> and contained the variable.. didn't seem to break the tools at all,
> but they also didn't seem to notice they were there.   Which means
> you're limiting yourselves by sticking to just the vars you knew about
> one day in the past.   I guess that's fine for the typical user.
> Whatever. Don't care.
> In this particular case, and in similar cases, it is probably wise to add
> the variable directly along with the rule, and leave it there with
> a sane default value.   Experienced users can alter this variable or
> move it into their own configuration file on their own, and others don't
> know the difference between hard coding it and not.   Which again gets
> back to the crash being caused by the removal of the variable, not the
> failure to import the variable in the first place, which was my
> original supposition of "buggy tools".   It works fine if "advanced 
> configuration" is hidden far from the end user.
> *****
> *****	I propose changing the offending rules to read 
> *****	$(SSH_PORTS:-22) and call it a day. Everybody wins.
> *****
>>This was
>>originally supposed to be a suggestion to the bleeding community to 
>>make sure the creation of the $ssh_ports variable was given enough 
>>thought. It was unfortunate that Erik then turned in to a flame war 
>>and began attacking our product,
> Again, I don't care about your product at all.  My "flame war" is entirely
> based on the presumption that you are a manager of some snort sensors for
> your customers in some capacity, that you obviously do not practice change
> control, lack of change control bit you in the ass,
> and that somehow it is not *YOUR* fault, but ours.   Same goes for
> that other guy that ditto-ed in on the thread about his 50 crashed
> sensors.   Yes, it was a mistake. It was a pretty big mistake.
> It's a mistake you all should have caught, though, and no sensor
> needed to go down because of it.   What part of that don't you get?
> It's not Bleeding-Snort's job to ensure the rules even compile right.
> Anyone using them is lucky enough that they load, and maybe even detect
> stuff, as they're usually just a proof-of-concept. 
> One of us has a flawed idea of the ultimate goal of Bleeding-Snort,
> and I'm still not entirely sure which one of us it is.   Really, only
> Matt Jonkman can answer that question.
> A) bleeding-snort exists entirely to provide faster response time signatures
> to snort users who do not subscribe to the VRT ruleset.
> B) bleeding-snort exists to publically experiment with new detection
> signatures, methods, and concepts.
> They're necessarily mutually exclusive.  option B will end up crashing your
> sensors or having lousy performance impacts from time to time. 
> If option B ends up simulating option A, fine, but one needs to recognize
> the difference.
> --
> Erik Fichtner; Unix Ronin
> "Mathematics is something best shared between consenting adults in the
> privacy of their own office" - Adam O'Donnell
> -------------------------------------------------------
> 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

- --
Wes Young
Title and Place of Employment removed as this might piss you off a little.
Version: GnuPG v1.4.1 (GNU/Linux)


More information about the Snort-sigs mailing list