[Snort-sigs] If You're Using Bleeding Snort Rules Read This!!
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"
>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,
>"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..
>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
>Enterprise Snort Management at http://www.appliedwatch.com.
>Security Information Management for the Open Source Enterprise.
>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
>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.
>>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
>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
More information about the Snort-sigs