[Snort-devel] a caveat to my rule system proposal
tlewis at ...255...
Sat Apr 7 03:18:26 EDT 2001
On Sat, 7 Apr 2001, Fyodor wrote:
> 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
Naah, it's a lot easier than this. Let them autoregister! Remember how
in the paengine structure, there's a name field? Same here:
pe_module_reg(pe->protocols, pe->name, f);
I have some code in my paengine patch which does this sort of module
discovery in a generic way. It's half-implemented, but the basics are
all there. A little cleanup and we can use the same system for paengines,
protocol engines, output plugins, matchers, everything. Hell, it even
supports static and dynamic modules.
> > 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. :))
I think that you almost have to give up ordered rules in order to
optimize matching. I probably should write up a polemic for doing away
with rule ordering and make my case. Protocol mappings, however, as I've
said, will have to be ordered or prioritized in some other way.
> > indicates that someone other than me thinks the idea is interesting and
> > is worth pursuing.
> it's coming.. it's coming... :)
Yay! I'm really looking forward to it, Fyodor.
tlewis at ...255...
More information about the Snort-devel