[Discussion] Non-tokenized preprocessor parameter lines

[Matt Jonkman]

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