Next: 2.14 What are CIDR
Up: 2 Getting Started
Previous: 2.12 Why does building
That depends. Lower the number of rules is a standard performance increase.
Disable rules that you don't need or care about. There have been many
discussions on 'tweaking performance' with lots of 'I handle XX mb with a ___
machine setup.' being said. Look at some of the discussions on the snort-users
mailing lists.
Here is an oft quoted bit on the subject from Marty:
``Hardware/OS recommendations''
Ok, here are the guidelines and some parameters. Intrusion detection is turning
into one of the most high performance production computing fields that is in
wide deployment today. If you think about the requirements of a NIDS sensor and
the constraints that they are required to operate within, you'll probably start
to realize that it's not too hard to find the performance wall with a NIDS
these days.
The things a NIDS needs are:
- MIPS (Fast CPU)
- RAM (More is *always* better)
- I/O (Wide, fast busses and high performance NIC)
- AODS (Acres Of Disk Space)
A NIDS also needs to be pretty quick internally at doing its job. Snort's seen
better days in that regard (when 1.5 came out the architecture was a lot
cleaner) but it's still considered to be one of the performance leaders
available.
As for OS selection, use what you like. When we implement Data Acquisition
Plugin's in Snort 2.0 this may become more of a factor, but for now I'm hearing
about a lot of people seeing alot of success using Snort on Solaris, Linux,
*BSD and Windows 2000. Personally, I develop Snort on FreeBSD and Sourcefire
uses OpenBSD for our sensor appliance OS, but I've been hearing some good
things about the RedHat Turbo Packet interface (which would require mods for
Snort to use, not to mention my general objection to RedHat's breaking stuff
all the time). (ed note: take a drink, see FAQ 7.2 -dr)
Next: 2.14 What are CIDR
Up: 2 Getting Started
Previous: 2.12 Why does building
|