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
pgptv1I9HFDrG.pgp
Description: PGP signature
