[Snort-users] Snort Performance
erek at ...577...
Tue Sep 10 12:18:19 EDT 2002
On Tue, 10 Sep 2002, Matt Kettler wrote:
> At 09:40 AM 9/10/2002 -0700, Erek Adams wrote:
> >Why is it not optimal? Care to elaborate?
> I'd agree.. I'd like to see someone suggest a structure which handles the
> "lots of any's" case in a noticeably better manner than the existing system
> without completely ruining performance for well specified systems. Your
> existing statement strikes me as a bit like calling a compression algorithm
> "not optimal" because it fails in the worst-case input (ie: true random
> data, which ALL compression algorithms must fail on).
To clarify my position a bit: I know snort can be improved in the way it
deals with its rules and such. I just have _NO_ idea of how. :-) I can
code (sorta), but things like that are out of my leauge.
I can say that I've seen at least a 10% speed increase by using the
1.9-current CVS version. It could be more, but I'm trying to be minimaly
> As for the "lots of any's".. I don't seem to have very many myself. But
> then again, I define EXTERNAL_NET as !HOME_NET instead of ''any" and I've
> also tweaked a few rules to use specific IP's or subnets instead of any.
> But these tweaks need to be done in light of my particular network. Hence
> this is really a "optimize your ruleset for your network" problem rather
> than a "optimize snort to handle all cases, including the one which cannot
> be optimized".
Preach to us brother! Preach! <-- gratuitous Kentucky Fried Movie reference.
> I would agree however that perhaps "some of the rules need to be better
> thought out and use HOME_NET and EXTERNAL_NET where appropriate" is a fair
> statement. ie: virus rules might consider having "LOCAL_POP_CLIENTS"
> instead of 'any' in them.
> any 110 -> any any
> any 110 -> $LOCAL_POP_CLIENTS any
> and default LOCAL_POP_CLIENTS to any, and suggest $HOME_NET as a good
> But that's not really a whole lot of an optimization, since you're not
> likely to see port 110 in any kind of traffic other than that specific
> case. This weeds out very few packets in most real networks.
That's one of the things that has been happening to the rules. More and more
rules are making use of variables instead of using 'any'. IMHO, if a rule
uses 'any' in it, then it deserves some review by the IDS operator. In a tiny
low trafficed net using 'any' rules is ok, since you don't have too much
traffic. On a high speed net, it's murder.
One other point: One thing you can do to really speed things up, is to limit
the use of "lists" of IPs. If you have 2 /25's listed in HOME_NET instead of
1 /24, snort has to do twice the work. If you can aggragate as much as you
can into HOME_NET it will _really_ make things better. If you can't
aggragate, you _might_ want to try running one instance for each sub/super net
that you have in HOME_NET.
More information about the Snort-users