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

Eric Hines eric.hines at ...1663...
Thu Jun 9 12:20:24 EDT 2005


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

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

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

More information about the Snort-sigs mailing list