Snort mailing list archives
Re: Diagnosing MySQL server has gone away messages
From: bleh <mailbox.size.limit () gmail com>
Date: Wed, 22 Aug 2007 10:00:28 -0400
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"auser" you are concerned about the environment surrounding thesensor.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 anytraffic> for quite a while with a single (badly written) pcre rule. Thereare a> number of preprocesors that can turn a sensor into a brick underthe> right conditions as well. Does this mean all users should stopusing> pcre and the smtp preprocessor? I do not believe so. Do you have something in the preprocessors you care to share withthedevelopment 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 mustbe acar 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 meanyoushould. > > As with anything else on a sensor you need evaluate your situationand> set up the system accordingly. There is no one size fits all, andthis> (IMHO) includes output plugins. For example, I have two sensors inmy> 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.Thereis absolutely no practical advantage to using direct DB writes fromtheengine compared to using unified output and there are certainlycleardisadvantages 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
Current thread:
- Barnyard for Windows?, (continued)
- Barnyard for Windows? Michael Steele (Aug 20)
- Re: Barnyard for Windows? Jason (Aug 22)
- Barnyard for Windows? Michael Steele (Aug 20)
- Re: Diagnosing MySQL server has gone away messages bleh (Aug 21)
- Re: Diagnosing MySQL server has gone away messages Dirk Geschke (Aug 21)
- Re: Diagnosing MySQL server has gone away messages Joel Esler (Aug 21)
- Re: Diagnosing MySQL server has gone away messages bleh (Aug 21)
- Re: Diagnosing MySQL server has gone away messages Jason (Aug 21)
- Re: Diagnosing MySQL server has gone away messages bleh (Aug 21)
- Re: Diagnosing MySQL server has gone away messages Michael Stone (Aug 21)
- Re: Diagnosing MySQL server has gone away messages Jason (Aug 21)
- Re: Diagnosing MySQL server has gone away messages bleh (Aug 22)
- Re: Diagnosing MySQL server has gone away messages Jason (Aug 22)
- Re: Diagnosing MySQL server has gone away messages Nerijus Krukauskas (Aug 21)