Re: Diagnosing MySQL server has gone away messages

[Jason <security () brvenik com>]

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?


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

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

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

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