[Oisf-wg-configuration_language] Config Suggestions

[Matt Jonkman]

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