[Oisf-wg-configuration_language] Config Suggestions
Matt Jonkman
jonkman at jonkmans.com
Thu Jul 30 15:33:46 UTC 2009
Dave Remien wrote:
> 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?
Definitely NOT b. I think if we go with that we'd end up stuck with it.
Not C, similar reasons.
I think A is the best option. We can either define a new language, which
as noted in the last suggestion wouldn't be too difficult. Or use an
existing similar language that fits us well.
>
> 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.
>
True, but the snort config syntax is a mish mash of evolved crud that's
very complicated and non-sensical I think to a lot of folks.
> Does the config language also include the rules syntax?
No, separate working group and separate problems. :)
>
> 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?)
>
Victor would be best to comment here. Victor?
Matt
>
> On Thu, Jul 30, 2009 at 8:16 AM, Matt Jonkman <jonkman at jonkmans.com
> <mailto: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
> <mailto: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 <mailto:palmer at tybalt.caltech.edu>)
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oisf-wg-configuration_language mailing list
> Oisf-wg-configuration_language at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-wg-configuration_language
--
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
More information about the Oisf-wg-configuration_language
mailing list