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

Jaramillo, Paul D [CC] Paul.D.Jaramillo at ...2992...
Thu Jun 9 12:33:34 EDT 2005


Can you guys please take the flamewar offline, this list is supposed to
be for signature discussion.

Thank You,
Paul D. Jaramillo
Security Event Management
Sprint Corporate Security
913-315-7465


-----Original Message-----
From: snort-sigs-admin at lists.sourceforge.net
[mailto:snort-sigs-admin at lists.sourceforge.net] On Behalf Of Eric Hines
Sent: Thursday, June 09, 2005 2:17 PM
To: emf at ...3056...
Cc: bleeding at ...2727...; snort-sigs at lists.sourceforge.net
Subject: RE: [Snort-sigs] If You're Using Bleeding Snort Rules Read
This!!


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