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