OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [snort] networks under different CIDR blocks
From: Martin Roesch (roeschhiverworld.com)
Date: Mon Mar 06 2000 - 14:44:02 CST

"Mullen, Patrick" wrote:
>
> > > Do I see a request for multiple network protection
> > > within SPP? Anyone? Anyone?
> >
> > That would be nice, but then again, people may be running two snorts
> > anyway instead of doubling/tripling the rules. It would be
> > nice to have
>
> Very true, but SPP would have to be modified to read in
> multiple networks for when the functionality to list
> multiple HOME_NETs anyway, so it's something that
> must be done.
>
> I haven't looked at code outside of SPP in a while, but
> the new IsHomenet() (or whatever) function should make
> multiple homenets easy to code. A single call to the
> [correctly named] function would do all checks through
> the list of networks. Has this work been done yet? I
> know it had been mentioned not to long ago, but
> unfortunately I'm a few versions behind at the moment.

Nope, that work hasn't been done yet. There are a few things that would
have to change within the detection engine to accomidate multiple subnet
definitions, and I haven't gotten around to thinking through the
conceptual framework that needs to be developed before that sort of
thing can happen.

Essentially, two things need to happen to have port & IP lists: I have
to implement "lists" in those fields for both the port and IP sections
of the RuleTreeNode's and I have to modify the port and IP space
analysis functions for the detection engine.

Additionally, this complicates the node chaining and collation system
that the rules tree uses. If you've got a list of three separate port
ranges on two rules, it becomes non-trivial to check all the possible
combinations those port sets can occur in to determine that rule A's
header is the same as rule B's.

Like I said, this is going to take a bit of thought to figure out....

I think this highlights a concept that a lot of people may not be
thinking about: it's a good idea to partition your Snort usage across
multiple subnets! For example, it's probably not a good idea to use a
single Snort box to monitor more than 3-5 class C subnets *tops*.
Really, I think 1 per class C is more appropriate. Larger networks (and
higher bandwidths) risk flooding the Snort box with too much traffic for
it to monitor. Snort's pretty good, but you have to be realistic about
expectations when you're deciding to monitor that class B with a single
400MHz Linux box. 

-- 
Martin Roesch                      <roeschhiverworld.com>
Director of Forensic Systems     http://www.hiverworld.com
Hiverworld, Inc.               Enterprise Network Security
Network Forensics, Intrusion Detection and Risk Assessment