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

Todd Lewis 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=dlsyn("pe", m);
		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.

Todd Lewis
tlewis at ...255...

More information about the Snort-devel mailing list