I think a fair amount of auto-configuration for the super-techy details would really help.  To complement that, I'd also really like to see a focus on performance metrics.  Too often we are in situations where we have to try to infer something based on rules that _didn't_ fire.  When you're not confident in a sensor, that's basically impossible.  Some sort of real-time non-libpcap-based drop statistic or load-shedding would be a huge leap forward.  For bonus points, a system for providing a 100% objective performance baseline of a given signature or module would also really help.  I know that each rule performs differently depending on the traffic at hand, but a metric detailing worst-case/best-case scenario performance would provide a really nice guideline to aid in making decisions about which rules should make the cut into the ruleset.  This could be crudely calculated by, say, the number of PCRE's used, length of content searches, etc.<br>
<br><div class="gmail_quote">On Tue, Feb 10, 2009 at 10:12 AM, Matt Jonkman <span dir="ltr"><<a href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree, I'm not enamored with the snort-style config. I'd much rather<br>
it be more dynamic, and possibly even real-time adjustable by the engine<br>
to suit it's resources.<br>
<br>
Or even better, one that would build a baseline of the box's<br>
capabilities and then config itself to suit. Such as choosing search<br>
methods that fit the ram available, # of threads based on cpu's<br>
available, etc. Take more of this out of black magic guesswork and into<br>
a more scientific method...<br>
<font color="#888888"><br>
Matt<br>
</font><div><div></div><div class="Wj3C7c"><br>
Victor Julien wrote:<br>
> Martin Fong wrote:<br>
>> Matt Jonkman wrote:<br>
><br>
>>> Non-tokenized preprocessor parameter lines<br>
>> Let me rephrase this into what I'd like (versus definition by<br>
>> negation): It would be great if processor arguments could (optionally)<br>
>> _include_ newlines to permit line-oriented parameter definition.  For<br>
>> example, this would allow<br>
><br>
>>     allow newlines<br>
><br>
>>     preprocessor myPreprocessor:            \<br>
>>     threshold = 1.0        # a description        \<br>
>>     max_count = 10        # another description<br>
><br>
>>     disallow newlines<br>
><br>
>> where "[dis]allow newlines" would dictate the parameter token scanner<br>
>> behavior.<br>
><br>
>>      As a side issue, I'd also like more functionality in the mSplit<br>
>> () replacement.  Specifically, it would be nice if it accepted 0<br>
>> (zero) for max_strs and then dynamically allocate the requisite<br>
>> members, particularly when the input is user-specified and thus<br>
>> causing the maximum to be relatively unpredictable (e.g., IP<br>
>> blacklists).<br>
><br>
> I think we need to work out a rules syntax and configuration scheme<br>
> first. I'm not convinced we should have a snort compatible configuration<br>
> scheme... I haven't thought of alternatives though.<br>
><br>
> Regards,<br>
> Victor<br>
><br>
<br>
--<br>
--------------------------------------------<br>
</div></div><div class="Ih2E3d">Matthew Jonkman<br>
Emerging Threats<br>
Phone 765-429-0398<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreats.net" target="_blank">http://www.emergingthreats.net</a><br>
--------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>