Re: Snort and high-traffic lines

[Gary Flynn <flynngn () jmu edu>]

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 
overloaded.

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.

-- 
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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