[Snort-devel] a caveat to my rule system proposal

Fyodor fygrave at ...1...
Fri Apr 6 15:07:55 EDT 2001


> may not be the best way.  Instead, users may want to specify protocol
> mappings with multi-layered criteria, much the same way that they
> specify rules.  (Think of something like this:
> 
> 	map-protocol ((ip src=192.168.16.0/22) && (tcp sport=80)) http
> 	map-protocol ((ip src=192.168.16.15/32) && (tcp sport=80)) IPSEC

Additionally I think it might be good to have basic protocols designed
in modules as well, so you could have something like

map-protocol (module /snort/modules/ip.so) ip
map-protocol (module /snort/modules/tcp.so) tcp
map-protocol (module /snort/modules/udp.so) udp


map-protocol (module /snort/modules/ipx.so) ipx

or even:

map-protocol (module /snort/modules/bsm.so) bsm_traps

(althrough in later case it might be questionable whether it is still right to call it 'protocol' in common sense).

This would give snort an extreme flexibility but on the other hand looks like
should be a way painful to implement.. lest design the best and try to do the rest :P

> For this reason, I think perhaps the matcher should handle determining
> which protocol engine should receive the dispatch at each stage
> of decomposition.  However, I had been hoping to keep all rules as
> an unordered set in order to benefit matching optimization, and the

There are pluses and minutes in having ordered rules, pluses are that
(as with ipfilter) you can layout the rules and have 'quicks' to do quick
matches or having the other rules to keep the 'most-matched' rule happy. 
The drawback of this scheme is that you'd have to look through the whole
rulelist from the top to the bottom in the worst case to validate a match... 
should be quite CPU consuming... Another thing which looks good in ipf
is heads of rulechains and groups...

Anyway if we sort out the rules and place them into a searchable tree,
(kind of the way it is done now), we definetely improve the performance
but it makes the rules design kinda painful.. (the reason why we have -o switch
f.e. :))


> indicates that someone other than me thinks the idea is interesting and
> is worth pursuing.
> 

it's coming.. it's coming...  :)

-- 
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1




More information about the Snort-devel mailing list