Re: Diagnosing MySQL server has gone away messages

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

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

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.

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.


-bleh

On 8/21/07, Joel Esler <joel.esler () sourcefire com> wrote:
> When snort logs to db, it takes resources away from inspecting traffic.
> Missing packets.
>
> --
> Joel Esler
> Sent from the road.
>
> On Aug 21, 2007, at 10:33 AM, bleh <mailbox.size.limit () gmail com> wrote:
>
> Can you explain what you mean by Snort "has to stop being an IDS"? If
> Snort is no longer an IDS when logging directly to a DB what is it?
>
> > In order for Snort to do an insert, it has to stop being an IDS.
> > Personally, I don't want my IDS to miss any packets, regardless of the
> > extremely short amount of time it takes to do a DB insert.  (Unless you
> > have a very busy DB).
> >
> > Still would rather you use Barnyard and Unified.
> >
> > Joel
> >
> > Jason Haar wrote:
> > > Joel Esler wrote:
> > > > As a general recommendation for everyone on the list, Snort should
> never be logging directly to the DB.
> > > >
> > > Can you tell me why that is? I mean, surely directly accessing a DB
> > > doesn't introduce much latency/load *unless* it continually generates
> > > events?
> > >
> > > i.e. if a particular installation of snort only generates 1 event per
> > > minute, is there really any difference between snort->mysql and
> > > snort->barnyard?
> > >
> > > I could understand it being a problem if snort is having to queue up
> > > events while INSERTs are going on, but if that are spaced many seconds
> > > apart...?
> >
> > --
> >
> >
> > --
> > joel esler | security consultant | Sourcefire | pgp is public
>  <http://www.geocrawler.com/redir-sf.php3?list=snort-users>
>
> -------------------------------------------------------------------------
> 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/>
> 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
-------------------------------------------------------------------------
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