Re: Intel X520 and Multi-Queue Snort

[Mike Lococo <mikelococo () gmail com>]

On 05/13/2011 01:53 PM, beenph wrote:
> On Fri, May 13, 2011 at 11:56 AM, Martin Holste <mcholste () gmail com> wrote:
> > > 16!??!  I currently monitor a link that has a daily peak of about 1.5
> > > gigabits per second of actual traffic with 4 snort-processes, and I run
> > > about 7000 rules selected from VRT and ET with close to zero
> > > packet-loss.
> >
> > Ha, that's what I thought until a few months ago.  Then I started
> > running heartbeat signatures and found out just how much packet drop
> > stats lie (from all sources, really).  I outlined basics on how to do
> > this on my last blog post at ossectools.blogspot.com.  In addition to
> > performance validation, heartbeat sigs are also a great method for
> > hooking Snort up to Nagios (or whatever monitoring setup you're using)
> > to verify that the entire alert reporting chain is working (i.e.
> > Nagios alert if you haven't seen the heartbeat).
>
> I honestly still think that a "heartbeat" signature is not a real solution.

Not a real solution to what problem?  I don't think anyone is
positioning heartbeats as a complete solution for monitoring snort
performance that is superior in every way when compared to every other
possible alternative.  It can be a useful data-point, though.  It can be
especially useful, if as Martin suggests, you observe drops of a
large-fraction of heartbeats in spite of monitoring a variety of other
metrics that all appear healthy.

Heartbeats won't tell you where the problem is or what it is, but an
end-to-end test that includes all the infrastructure that snort depends
on but can't be aware of could be a great indicator for problems that
would otherwise be very difficult to reliably observe.

> For example, if someone pull's the wire from your monitoring station
> and plug it back 10 minutes later, the only thing you would know is that mabey you
> missed one of your heartbeat signature and if your heartbeat signature passed right before that, then you
> would think everything was all right when it fact you where not monitoring for 10 minutes.
>
> It could also be an issue more upstream like your trunk that get's
> disconnected etc etc. And those wouldn't add up in the
> "droped packets" since whats not seen is not counted thus is not missed.

Snort has lots of other instrumentation that would make the first-case
obvious, but the second case could be difficult to detect if you don't
have control of the upstream devices feeding snort and heartbeats would
help you know that you should be looking for a problem.

Cheers,
Mike Lococo

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
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