[Discussion] Non-tokenized preprocessor parameter lines

[Martin Holste]

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.

On Tue, Feb 10, 2009 at 10:12 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:

> I agree, I'm not enamored with the snort-style config. I'd much rather
> it be more dynamic, and possibly even real-time adjustable by the engine
> to suit it's resources.
>
> Or even better, one that would build a baseline of the box's
> capabilities and then config itself to suit. Such as choosing search
> methods that fit the ram available, # of threads based on cpu's
> available, etc. Take more of this out of black magic guesswork and into
> a more scientific method...
>
> Matt
>
> Victor Julien wrote:
> > Martin Fong wrote:
> >> Matt Jonkman wrote:
> >
> >>> Non-tokenized preprocessor parameter lines
> >> Let me rephrase this into what I'd like (versus definition by
> >> negation): It would be great if processor arguments could (optionally)
> >> _include_ newlines to permit line-oriented parameter definition.  For
> >> example, this would allow
> >
> >>     allow newlines
> >
> >>     preprocessor myPreprocessor:            \
> >>     threshold = 1.0        # a description        \
> >>     max_count = 10        # another description
> >
> >>     disallow newlines
> >
> >> where "[dis]allow newlines" would dictate the parameter token scanner
> >> behavior.
> >
> >>      As a side issue, I'd also like more functionality in the mSplit
> >> () replacement.  Specifically, it would be nice if it accepted 0
> >> (zero) for max_strs and then dynamically allocate the requisite
> >> members, particularly when the input is user-specified and thus
> >> causing the maximum to be relatively unpredictable (e.g., IP
> >> blacklists).
> >
> > I think we need to work out a rules syntax and configuration scheme
> > first. I'm not convinced we should have a snort compatible configuration
> > scheme... I haven't thought of alternatives though.
> >
> > Regards,
> > Victor
> >
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20090210/723b775f/attachment-0002.html>