[Snort-users] Snort and high-traffic lines
flynngn at ...6811...
Wed Oct 2 10:22:12 EDT 2002
Jens Krabbenhoeft wrote:
> Are there any other hints for me, to get tweak the OS/snort so that I
> can cope with that amount of traffic? Has anybody tried to split up
> snort to sniff the same interface (with the same homenet etc.) but with
> the ruleset split into three parts - would/could that help?
I'm new at this so take what I say with a grain of salt.
Any rebuttal is welcome as I'm still working out a strategy.
I don't think multiple instances of snort on the same box
are going to help you much. If you're using a promiscuous
switch port like Cisco's SPAN, you could probably attach a
100Mb *hub* to the port and attach multiple commodity machines
each running snort with a subset of the rules. I've been
considering doing this to run separate ntop and snort machines
on our (full) 45Mb pipes. There is probably a way to make this
work if you're using a tap too.
If your high bandwidth is due to a large number of hosts on your
network, I'm not sure how effective the system will be as an
intrusion detection system with all the rules applied. Unless
you are exceptionally well staffed and have a lot of control over
the computers on your network, follow-up investigations for all
the false detections are going to be impractical. For such a
network I think it is necessary to get rid of rules that are
ineffective. If you don't do it in the collection process, you'll
end up doing it in the examination process anyway. The one
advantage of collecting false positives is that you may have
some helpful history to review if one of the detections later
turns out accurate. But a "log" action instead of an "alert"
action might be more appropriate for the less effective rules.
For example, why monitor all the incoming code red/nimda trash
unless you're using FlexResp to kill connections? Monitor it
outgoing which will tell you when one of your servers is infected
indicating a successful intrusion.
And you surely want to dump the rules that monitor ports that
don't make it through your border network access controls.
Don't allow incoming portmap? Why monitor it in the incoming
direction? I would think that a rule that isn't matched would
have very little effect on performance but every little bit
helps. One could argue that monitoring such ports serves
as an alarm if your network access controls fail but there
might be better ways to do that if your NIDS is already
I'll grant you, weeding out the ineffective rules is a tedious
process and not without some risk...but what isn't? :)
The other think to look for in the ruleset is the number of
duplications. For example, several rules may look for a
particular trojan or ddos tool in different ways. It may
be sufficient to look for them in just a couple ways.
And, of course, pay particular attention to those rules
of the form "alert tcp any any -> any any (content:"whatever")".
I'd think they'd suck up CPU cycles quickly.
OTOH, if your high bandwidth is related to a few busy hosts, then
your ability to followup is greatly enhanced. However, in that case,
it should be possible to narrow down the ruleset significantly
taking into account the services running on those machines and
possible outgoing patterns indicating a compromise. With just a
few hosts, a host based IDS combined with an integrity checking
mechanism like tripwire is probably more effective than a NIDS
anyway. Combine a highly focused NIDS with the HIDS and you'll
have a manageable, effective IDS. If you allocate enough horsepower
and storage to the NIDS, you also might end up with a useful
history log for forensic purposes but don't make the whole ruleset
your primary alerting mechanism.
The portscan or stream preprocessors seem to take significant
CPU when large numbers of hosts are involved. I haven't figured
out how to deal with that yet.
My $0.02 worth.
Security Engineer - Technical Services
James Madison University
More information about the Snort-users