Snort mailing list archives
Re: order of matching rules
From: Christopher Kruegel <chris () infosys tuwien ac at>
Date: Mon, 21 Oct 2002 17:07:19 +0200
As for snort-ng I'll admit I've not examined their software or site to any great degree, but I'd be very cautious of accepting that it's an improvement in the general case.
Actually, we have omitted any attempt to make our system appear faster. We did not measure some virtual time it takes to process a packet - instead we even sniffed live network traffic to simulate that load as well.
The graphs in the snort-ng site compare a percentage of matches as the "number of rules" increases, a reasonable evaluation, but no data is provided as to what rules were used. Obviously I can sit down and create my own set of rules which penalizes the existing structure of snort heavily, and then come up with an "optimization" which improves this case but does not improve a realistic setup.
True - but that has not happened. We have aggregated all available snort rules in a way similar to 'cat *.rules >> big_rules_file.rules'. And we used the standard rule set that is shipped with Snort-1.8.7. For our tests, we simply added more and more rules from that file - without any hand tuning. The order is simply determined by the position of a rule in a rule file (as it has been shipped) and the order of the rule files by the sorting obtained from 'cat *.rules'.
I'm not trying to accuse snort-ng of "rigging the test" but given the data present on the snort-ng site and in their whitepaper, it's hard to decide if their improvements are realistic, or if their test is somehow biased to
Thank you, but I suggest you simply download it and try it on your network traffic. Any information about your results would be appreciated.
I'm also skeptical of the stability of this code given that the original code did not handle ip fragments without a segfault. They've fixed that since, but does the additional check degrade the performance? what other sanity and stability checks have been skipped to get more impressive graphs?
That was a simply mistake when we copied parts of the original Snort code and changed it to call our functions. The checks that had to be inserted add up to 3 (!) lines of code that cause no performance impact at all. In addition, we rely on the original Snort code to do all sanity checking, so there is no omission of sanity and stability checks.
also love to see some memory consumption comparisons. If the new rule processor consumes significantly more memory in some scenarios this may wind up reducing the amount of memory available for disk buffering, causing a detriment to the logging end and possibly degrading the total performance of the system to be worse than the original.
This is a good point, we obviously consume more memory. Such graphs will be included in the next version of the paper.
I'd also susupect that the added log output of matching every packet against every rule will generate a considerably greater amount of log output, resulting in dramatically worse performance when using the default snort ruleset, negating the all the performance gain of the faster matching code until a new ruleset which is oriented towards the new snort-ng is written.
I really doubt that. Usually, the vast majority of packets should not generate any alarms at all and it is often the case that a single packet matches only one rule. Imho, the fact that Snort 2.0 changed this is clearly an indication of that. christopher kruegel ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote _______________________________________________ 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
Current thread:
- order of matching rules archana rao (Oct 16)
- Re: order of matching rules Chris Green (Oct 16)
- Re: order of matching rules archana rao (Oct 17)
- Re: order of matching rules Chris Green (Oct 22)
- Re: order of matching rules archana rao (Oct 17)
- Re: order of matching rules Matt Kettler (Oct 16)
- <Possible follow-ups>
- Re: order of matching rules Christopher Kruegel (Oct 22)
- Re: order of matching rules Christopher Kruegel (Oct 22)
- Re: order of matching rules Chris Green (Oct 22)
- Re: order of matching rules Chris Green (Oct 16)