Re: [performance] Question...

[Erek Adams <erek () snort org>]

On Thu, 13 Feb 2003, Emmanuel Dardaine wrote:

> I have a few questions regarding Snort and performance:
> - we would like to setup several Snort instances à separate places in order
> to sniff and log trafic (for lawful purpose); my concern is about bandwidth
> consumption and continuous data flow along the network; hoow Snort logs into
> the database: via a continuous flow, or batch after batch?
> - how big should be the database (disk space) and the database server (CPU,
> RAM); is the database size proportional to the amount of data sniffed from
> the network

This has been discussed more times than I could count, and probably will
again.  :)

Have a look at this link [0], as it has quite a few good things stated by
Marty.

A few things that you might want to consider:

        * Have a network used _only_ for backending the data.  If you
can't have a different net, use VLANs for seperating the traffic.
        * Use at least two NICs.  One for IPless sniffing, one for data to
DB and management.  If you can do more than two, split the data and
management.

As for DB's and Snort:

        The db output plugin just sends it over the wire.  Bad thing is,
if the network burps, and the connection between Snort and the DB goes
away, Snort stops logging to the DB, and you could lose alerts.
        The fix for that is called Barnyard [1].  BY is a daemon that
reads a special type of output file called 'unified', and then zips it off
to the DB.  BY is clueful of the network drops and simply waits till the
DB is alive again and then resumes sending.  Using it, you'll have a Snort
process writing to unified, and a BY process reading from that same file.
As long as you have disk space, they shouldn't break.

Unified logging is the way to go for any one concerned with speed and
reliability with the DB.  I'd suggest using it if you are building a
distributed net.

As for "How Big?":  As big as you can get it.  :)  Throw money at it until
it's a HUGE beast!  Lotsa memory, and plenty of disks.  You might want to
decide on the DB you'll use on the backend, and then check the DB
developers site(s) for a better idea of what you can get away with.

Hope that helps!

-----
Erek Adams

   "When things get weird, the weird turn pro."   H.S. Thompson


[0]     http://www.theadamsfamily.net/~erek/snort/perf.txt
[1]     http://www.snort.org/dl/barnyard/


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
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