Re: Diagnosing MySQL server has gone away messages

[bleh <mailbox.size.limit () gmail com>]

Your attacks aren't going to work. Your argument is flawed.

On 8/21/07, Jason <security () brvenik com> wrote:
> bleh wrote:
> > See comments inline.
> >
> > On 8/21/07, *Jason* <security () brvenik com <mailto:security () brvenik com>>
> > wrote:
> >
> >
> >
> >     bleh wrote:
> >     > This would seem to be dependent on a lot of factors.
> >     >
> >     > database event rate
> >     > snort alert rate
> >     > cpu/memory/io
> >     > system load
> >     > network kbps
> >     > type of traffic (protocols etc.)
> >     > enabled rules / quality of rules
> >     > enabled preprocessors
> >     > snort variable assignment
> >
> >     I think you are getting a bit pedantic. You are not concerned about
> "a
> >     user" you are concerned about the environment surrounding the
> sensor.
> >     Why would you needlessly add another risk factor to performance when
> >     there are clear solutions to it?
> >
> >
> > The job of any systems, network or ids administrator is to look at the
> > systems and network as a whole. Network and systems profiling is far
> > from being pedantic, this is called performing your job.
>
> Along with looking at it, you are supposed to make prudent decisions.
> Those decisions should be to not waste time arguing a point in which you
> are provably incorrect for the sake of being pedantic. The difference
> between what you represent and reality is that effectively performing
> that job begins with good decision making. In this case, a clear area
> for improvement regardless of the other possibilities, is to remove the
> potential of DB blocking from the engine.
>
> There is absolutely no advantage to writing to the DB directly from the
> engine. How are you doing your job effectively while wasting time being
> pedantic?


Who says I was wasting time? Again you make assumptions as not to only what
my environment is but also as to what hours I work.

> >     Do not let perfection be the enemy of good.
> >
> >     >
> >     > A user can do a lot more damage to a sensor with any combination
> >     of the
> >     > above items. For example I can make Snort stop inspecting any
> traffic
> >     > for quite a while with a single (badly written) pcre rule. There
> are a
> >     > number of preprocesors that can turn a sensor into a brick under
> the
> >     > right conditions as well. Does this mean all users should stop
> using
> >     > pcre and the smtp preprocessor? I do not believe so.
> >
> >     Do you have something in the preprocessors you care to share with
> the
> >     development team so it can be addressed or is this conjecture?
> >
> >
> > Portscan, SMTP, DNS and BO just to name a few.
>
> Ahh, it is in fact conjecture. Thanks for the clarification.


Nice try. This is a fact. There are performance issues with each of these
preprocessors that can be easily replicated. Your welcome.


> >     Just because you can write a poor rule does not invalidate that you
> >     should not do direct writes to the database. As always, there must
> be a
> >     car analogy.
> >
> >
> > I agree, a car analogy does work. Sure, I know that having on the A/C
> > has the potential to impact performance. However, there are still many
> > key factors involved such as the engine size, transmition, fuel and
> > weight. These factors are very similar in nature to those I addressed
> > above. You telling me I should *always* run with my A/C off is a blanket
> > statement and has very little bearing when you have no idea what kind of
> > car I drive and how I drive it.
>
> kinda, sorta, not really. I'm telling you that your car has both the
> traditional AC with a compressor that sucks 10 horse power and the car
> is also equipped with a solar powered thermal cooling inductor that uses
> a flux capacitor. When you utilize the thermal cooling inductor you also
> produce hydrogen that the engine will burn and provide an additional 10
> horse power and efficiency.
>
> You are choosing to use freon and a compressor instead of the more
> efficient and clearly advantageous thermal cooling inductor thingamabob.



Exactly. Your *trying* to tell me about my car, of which you know nothing
about, and are only making assumptions.

> >     Just because you can go faster than conditions warrant does not mean
> you
> >     should.
> >
> >     >
> >     > As with anything else on a sensor you need evaluate your situation
> and
> >     > set up the system accordingly. There is no one size fits all, and
> this
> >     > (IMHO) includes output plugins. For example, I have two sensors in
> my
> >     > lab (for validating new config options, new snort versions etc.)
> >     > watching the same traffic one with unified and one with db. I
> >     > continually receive the same number of alerts from both systems.
> >
> >     I humbly assert that you are incorrect in every sense of the word.
> There
> >     is absolutely no practical advantage to using direct DB writes from
> the
> >     engine compared to using unified output and there are certainly
> clear
> >     disadvantages to using them.
> >
> >
> > My statement states there is not a "one size fits all" solution. You
> > stating that I am "incorrect in every sense of the word"  asserts that
> > there is a "one size fits all" solution. Therefore, please tell me which
> > config, preprocessors, rules, hardware and OS everyone in the Snort
> > community should be running.
>
>
> When it comes to getting data out of the engine and into other things,
> there is in fact one size that clearly fits better than any other. Your
> indirection does not negate that fact. Your insistence on utilizing
> direct DB writes is incorrect in every sense of the word.
>
> There is absolutely no reason to persist using DB output from the
> engine. Any assertion to the contrary is irresponsible.
>
> And... to the chance of carrying on more useless banter, regarding this
> topic, I simply say "> -bleh"



The numbers speak for themselves. I have a large testbed with a nice mix of
traffic (from avalanche, reflector, smartbits, metasploit, canvas, threatx
and live traffic just to name a few) at hundreds of megs per second with no
issues writing to a DB, dropping packets or missing events (comparing
against an equivalent system using unified2 / flop watching the same
traffic) . So what am I going to believe? Physical proof or FUD? I'm going
with physical proof.

Since you did not provide what config, preprocessors, rules, hardware and OS
we should all be running on does this mean you don't think one size fits
all? Or ,is that the one thing you aren't willing to make an assumption
about?

-bleh

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users