[Oisf-wg-configuration_language] Config Suggestions

Thu Jul 30 15:26:10 UTC 2009

Questions-n-alleged thoughts:

Given that the plan is to release a production ready OISF Engine by the end
of the year, is the intent of this group to a) define a new config language
for that release, b) use the existing snort config language (with
enhancements) up to some point, then fork to a new language, or c) enhance
the existing language for the foreseeable future?

I'd suspect that the majority of the future users of the OISF Engine have
more than a passing familiarity with the snort config syntax. From my point
of view, it would be easier to start from there and migrate than attempt to
leap to a complete new language.

Does the config language also include the rules syntax?

If someone from the dev team could chime in on where the current state is,
and how they feel about this issue (i.e., impact), that would be useful.
(Victor? Matt?)

Cheers!

Dave

On Thu, Jul 30, 2009 at 8:16 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:

> Some comments submitted anonymously to be included in the discussion
> here. I think this is a good way to spark the discussion, and thanks to
> the submitter! Very well thought out!
>
> ----------
>
> For the non-rule  oriented aspects  of a configuration
> language I favor a simple key value pairing, and yeah it could be used
> for rules, it would just be more verbose than the snort language - and
> that may or may not be acceptable to folks.  Here is the key
> rationale:
>
> The bulk IDS configuration is static data, not script or programming
> language oriented input.  If some aspects requires a programming
> language perhaps that would be the rule language turf, thats less than
> clear.  A few key issues we want to accomplish with any configuration,
> at least this is my opinion:
>
> - should be clear as to what the configuration is, this probably has
> more to do with planning and enforcing consistency
>
> - should require an absolute minimum effort on the part of a
> programmer to access the config data, and add new config data items -
> easily extended
>
> - should not require a recompilation of the configuration parser to
> add configuration for new features/processors/plugins - dynamic typed.
> -
>
> So, I recommend using a simple configuration data language made of
> name value primitive pairs and data structures.  Its important to have
> a rich set of primitives,  arrays of primitives, and structures to
> group data. It could be in flex and bison, whitespace/newlines
> are meaningless as everything is a name value pair. For example values
> may be booleans, numbers/integers, floats, strings (quoted),
> identifiers (unquoted text without spaces), ip addresses and cidr
> blocks and ranges, ports and port ranges , or a structure  may be the
> value following a name. Nesting is supported, and the language is
> dynamically typed.  Therefore the parser identifies values. The parser
> loads all of the configuration into memory but its not been type
> checked to ensure each name has data of the correct type.  The
> programmer uses API's to access the data for instance  i.e. get_bool(
> name, &value, default-value, required-flag ), this api does the
> validation. For example:
>
> config-file:
> --------------
> tcp
> {
>   max-sessions 300K  # session table size
>   session-on-syn on   # boolean
>   checksums on
> }
>
> accessor api:
> --------------
> cfg_get_bool( "tcp.session_on_syn", &tcp->session_on_syn,  1, 0 );
> cfg_get_bool( "tcp.checksums", &tcp->checksums,  1, 0 );
> cfg_get_number( "tcp.max_sessions", &tcp->max_sessions,  128*1024, 0 );
>
> A few points:
>  - default values are set
>  - parameters may be required or not
>  - if parameters are required and not found in the config data, the
> program fails configuraton
>
> Array examples:
>
> http-ports [ 80 8080 8138 ]
> home-net [ 192.168.1/24   192.168.3/24  ]
>
> Arrays like this should be promotable to be useful for rules or any
> other port or IP need.  This can be done using a casting such as:
>
> <port> http-ports [ 80 8080 8138 ]
> <ip> home-net [ 192.168.1/24   192.168.3/24  ]
>
> Thats the basic idea, the rule language - ugh, depends on what you
> really think your going to implement in terms of new features.
>
> Also, google release a code piece that does a static name value pair
> language.  I do not believe static typing is good, as you have to
> recompile the parser whenever new data is added.  Once of the
> weaknesses of the snort code is that you have to recompile the code
> the add a new preprocessor.  I do not have to that that with my IDS
> efforts any more.  It has allowed a lot more code work to be done at
> the inspection stage by various people without messing with the core
> framework of the IDS.  It also forces a strong set of API's to evolve
> as the plugins only access what the APIs provide, as it should be in
> my opinion.
>
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
>
> _______________________________________________
> Oisf-wg-configuration_language mailing list
> Oisf-wg-configuration_language at openinfosecfoundation.org
>
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-wg-configuration_language
>

-- 
"Of course, someone who knows more about this will correct me if I'm
wrong, and someone who knows less will correct me if I'm right."
David Palmer (palmer at tybalt.caltech.edu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-wg-configuration_language/attachments/20090730/17fe8370/attachment-0002.html>