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

Alex Kirk alex.kirk at ...435...
Thu Jun 9 12:32:44 EDT 2005


Let he who is without sin cast the first stone:

> Otherwise, your just spreading FUD:


Your == thing which belongs to you
You're == contraction of "you are"

:-)

Alex Kirk
Grammar Police
Sourcefire, Inc.

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





More information about the Snort-sigs mailing list