RE: Gigabit NIC's and snort hardware required??

["Zach Forsyth" <Zach.Forsyth () kiandra com>]

Bennet,

You are a legend.
That is a fantastic reply and answered my questions nicely.

I will not create any more noise on the list but will take all of that
on board and go and play with snort.
Might event report back some of my findings if they are intersting
enough.

Cheers

Zach

-----Original Message-----
From: Bennett Todd [mailto:bet () rahul net] 
Sent: Friday, 6 June 2003 22:58 PM
To: Zach Forsyth
Cc: snort-users () lists sourceforge net
Subject: Re: [Snort-users] Gigabit NIC's and snort hardware required??


2003-06-05T23:42:03 Zach Forsyth:
> When I use the command :> snort -vi2, shouldn't that be a very fast 
> running version of snort?

When I check the man page, it says:

       -v     Be verbose.  Prints packets out to the console.   There
is  one
              big  problem with verbose mode: it's slow.  If you are
doing IDS
              work with Snort, don't use the '-v' switch, you WILL drop
pack-
              ets.

That's for snort-2.0.0, but I really don't think this has changed. It's
very basic.

> It is only logging to the dos window I run it in. Is it using any 
> rules when run in this way?

No, to get snort to run rules as an IDS you use "-c" to aim it at a
snort.conf. And in the snort manual (available at
<URL:http://www.snort.org/docs/writing_rules/>), right in the top, at
"1.4  Network Intrusion Detection Mode" it says:

        [...] if Snort is going to be used in a long term way as an
        IDS, the -v switch should be left off the command line for
        the sake of speed.  The screen is a slow place to write data
        to, and packets can be dropped while writing to the display.

> I was under the impression that if it could not keep up with that 
> command when I tell it to log or alert to a DB it would be even worse.

No, the other way around, if you're telling snort to log every packet to
the screen, it'll be one slow little piggy. The starting point command
you want is something along the lines of "snort -b -A fast -c
.../snort.conf", modulo the differences between Unix and Windows
commandlines.

If you want to cram your alerts into a DB, and you also care about
performance, you will positively want to use the unified binary output
format feeding Barnyard. Or else to craft up something custom, using
either -A fast or syslog to another machine, and feeding the DB on
another machine with a file-tailer.

> P4 Xeon - does Xeon make a big difference? does it matter if it is 
> dual or not?

If you only run snort on that machine, and do the DB feeding somewhere
else, dual should make less difference. If you tune to the point where
you don't have too many alerts dual will certainly not make a
difference. Snort itself is one single-threaded process.

> 512mb or 1gb ddr ram - ram speed help, or just amount?

I'm not up to date on different flavours and speeds of RAM. Slower can't
be better, though. With even the least bit of tuning 512M can be fine,
but if it's not too dear to expend 1gb that completely removes any worry
that snort might want a little more memory than it can get (==> _slow_).

> SATA or SCSI raid? Does disk speed make a huge difference?

I built hot little snorters with simple plain IDE drives. You get speed
by ensuring snort doesn't need to write much. If snort is having to
write so much that disk speed matters, you'll have a slow snorter; high
alert volumes force snort to spend too much time whinging and too little
time analyzing. Now if you're cramming alerts into a DB, the _separate_
machine the DB runs on should have fast disks.

Windows instead of Linux may change this picture in some way, I don't
know.

> In order if importance to snort speed:
>
> Tuning
> Pci bus and gb card speed
> memory
> Processor

I'd rank those

        Memory + Tuning
        Processor
        bus & card speed

Memory is mandatory. If snort doesn't fit in real memory, you're doomed.
Tuning is mandatory if you want to keep up with more than roughly 50Mbps
(in my experience, possibly newer hardware has moved that point, I
dunno). When I saw my little piggies starting to drop packets for real,
the processor utilization was right on up there, so once the mandatory
memory+tuning have been addressed I'd guess CPU might come next. Bus and
NIC performance would make more difference on where the ceiling lies,
I'd expect --- assuming you've got a NIC with a good OS driver that
doesn't chew the system up just watching the net, before snort even
starts looking at the packets.

Another factor would be the quality of the pcap lib. I don't know about
Windows there. On Linux I've heard that the ring-buffered varient
libpcap can be a win, although I've not used it myself (I designed our
snort deployment to avoid needing to handle more than c. 50Mbps per
box).

-Bennett


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.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