RE: Snort as Gigabit Sensor

[Banniza Robert <Robert.Banniza () HCAhealthcare com>]

Here's a little more information I forgot to provide in the first post. The
machine is an IBM x335 Xeon with dual 2.6Ghz procs and 1GB RAM. As for the
logging portion, I am not using Barnyard (yet)....We were setup to log to
Postgres and to syslog. However, we did notice something interesting...With
all logging turned off and just sniffing with the default ruleset, we were
still dropping packets. Also, by placing 8 pass rules in local.rules, this
accounted for about 6-7% of the packet loss. Therefore, if we turned the
pass rules off (commented out local.rules), our packet loss would drop down
to 33% or so.

Robert

-----Original Message-----
From: Demetri Mouratis [mailto:dmourati () cm math uiuc edu]
Sent: Thursday, July 24, 2003 2:19 PM
To: Banniza Robert
Cc: 'snort-users () lists sourceforge net'
Subject: Re: [Snort-users] Snort as Gigabit Sensor


On Thu, 24 Jul 2003, Banniza Robert wrote:

> Anyone have any good pointers on tuning Linux (Redhat 9) as a gigabit
> sensor? Currently, we are using a Broadcom Corporation NetXtreme BCM5703
> Gigabit Ethernet (TG3 kernel module) Netgear card as the sniffing card. We
> have set up a span port so that we can see all traffic on a Cisco 6509.
The
> sad thing is we are encountering 40% packet loss. The network interfaces
> were statically compiled into the kernel and /etc/sysctl.conf was modified
> with the following to provide larger buffers:
<snip>
> We have not performed any rule tuning yet and the current sustained
> throughput we have seen through this connection is around  14Mb which is
> nowhere close to gigabit speeds. Any ideas?

Turn off all the pre-processors first, especially spp_conversation and
spp_portscan.  They tend to eat up memory.  Next thing I would look at is
throwing out uneeded traffic analysis for protocols/nets you aren't
concerned with.  The 6509 is probably a core switch right?  Consider
what you are willing to live without checking at that layer of your
network.  You can do this with BPF filters or pass rules.

Make sure you are logging in a sane fashion.  Best thing would probably be
barnyard to decouple the sensing from the analysis.

You didn't mention anything about the sensor itself (Processor(s), RAM,
Disks).

Those will undoubtedly affect your performance as well.

If you go through all these steps and still can't capture enough traffic,
you may have to re-architect the thing to use two sensors, each on half of
your network.  Again, use BPF to set this up.

You are going to have to pare down the default rule list no matter what.

Hope that helps.
---------------------------------------------------------------------
Demetri Mouratis
dmourati () linfactory com


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
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