My earlier question about HTTP_PORTS and needing to use...
var HTTP_PORTS 80
include somefile.rules
var HTTP_PORTS 8080
include somefile.rules
...to define multiple ports. Mr. Ward's response about rule processing
and the doc's I've been reading has got me thinking.
I understand that it is a good idea to disable sigs that have nothing
to do with your network environment from a false positive perspective,
but from a performance perspective does the shear number of sigs
dramatically affect performance?
If it were feasible, from a management perspective, to take a given
set of rules, duplicate that set for each IP address on a network,
edit them and tailer each sig in a set specifically for that
ip/port...would this drastically affect performance?
From the ruleop.pdf it looks like the this process is kind of what the
optimizer does to some extent when trying to create a set that "allows
each packet to be classified into
one rule subset using the packet's characteristics." But it would seem
to me that it can't do this completely because of generic vars like
HTTP_SERVERS. Typically someone would define both IIS and Apache
servers in this var. It appears to me that a sig like
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 <some Apache vuln>
The payload of this sig would still be analyzed to some extent even if
the destination server in question were an IIS server.
So if you could do something like this...
Given:
small network of 3 server to be monitored...
Steps:
1. Create directories like...
/etc/snort/rules/server1
/etc/snort/rules/server2
/etc/snort/rules/server3, etc...
2. In each directory place a copy of say the full VRT ruleset
3. Disable any rules in a particular server specific rule directory
that is not needed (typical tuning)
4. Change the $HOME_NET/$DNS_SERVERS/<whatever var is used in that
sig> to be the actual IP of the server that set is used for.
5. Do the same for vars like HTTP_PORTS.
In the end you would end up with a lot of duplicate (especially if two
of the servers were very similar say Linux/Apache servers) but highly
targeted sigs, and no vars in the conf file. I would think that this
might provide the optimiser better info to create it's sets.
So, ignoring the nightmare related to sig management, the question is,
Is there a performance issue related to the shear numbers of sigs that
keeps this from being a viable solution?
Would the highly targeted nature of the sigs outway this performance hit?
Would this concept be scalable to large environments, meaning yea it
might work with 3 servers but would it work with 300 or 3000?
All thoughts welcome.
Wally
_______________________________________________
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
