[syslog-ng] [announce] patterndb project

[Martin Holste]

I prefer the dot notation just because it's what I'm used to.
However, an XML schema could represent this as repeated child
elements, like:
<rule><class>Net</class><class>NAT</class><class>Security</class></rule>.
 A user would see these three classes listed and know that the
respective required fields exist as name/value pairs within the
pattern.  Likewise, an author would only be able to put class="Net" if
his or her pattern does in fact provide name/value extractions for the
"Net" tuple.  That provides the guidance needed for deciding how to
classify the patterns.  I'm not sure if there would be any effective
difference between a "class" element and the existing tag element, so
maybe it's just a matter of stipulating that contributers need to
appropriately tag their signatures with the correct classes inherent
within them.

In fact, it probably wouldn't be hard at all to write a quick script
to auto-tag signatures as they are submitted, based on the name/value
pairs provided in the signature.  So the only real thing a contributer
would need to be aware of would be the official terms to use for the
names, e.g. standardizing on "srcport" versus "source_port."

So, that means that the community would be responsible for:
1. Creating a standard list of names to use, adhering to the data type
contained within (strings, ints, etc.).
2. Create a convention for which names are required (and optional) for
which classes or tags.
3. Maintain the officially approved and vetted list of signatures that
adhere to the above conventions.

This is basically what you've already stated you want to do, right?

One of the nice things about XML is that you can create schema
definition files (XSD's) which can validate a given XML file.  So, the
output of the naming conventions could be an XSD file that can be
distributed with Syslog-NG so that end users can quickly verify
signatures before they submit them.

On Sat, Jul 3, 2010 at 6:32 AM, Balazs Scheidler <bazsi at balabit.hu> wrote:
> On Thu, 2010-07-01 at 17:35 -0500, Martin Holste wrote:
>> I've read through them and I think they're definitely on the right
>> track.  One thing that might be good to consider would be a way to
>> store hierarchical information.  For example, the secevt class in the
>> schema doc is really a network class as it only requires the network
>> tuple.  So, you could have a hierarchy like this:
>>
>> class Net { required_fields: [ proto, srcip, dstip, srcport, dstport
>> ], optional_fields: [ in_iface, out_iface, details ] }
>> class NAT { required_fields: [ nat_srcip, nat_dstip, nat_srcport,
>> nat_dstport ] }
>> class Security { required_fields: [ verdict ], optional_fields: [ zone ] }
>>
>> This implies that the class Net.NAT.Security requires proto, srcip,
>> dstip, srcport, dstport, nat_srcip, nat_dstip, nat_srcport,
>> nat_dstport, and verdict, but Net.Security only requires proto, srcip,
>> dstip, srcport, dstport, and verdict.
>>
>> By that token, there's no difference between Security.NAT.Net and
>> Net.NAT.Security, so these are really more like tags than a hierarchy.
>
> Hmm.. interesting idea, making a hierarchy of schemas. Again some more
> food for thought.
>
> Is there a reason you want this behaviour implied, rather than being
> explicit? Maybe using a different syntax would make that more obvious.
> When combining schemas then instead of using '.' as a separator, use '+'
>
> Net+NAT+Security
>
> This would make it obvious that you can write the schema names in any
> order (since this is true for the mathematical '+' sign everyone knows).
>
> Also, how would you represent this in a pattern? Right now you can
> assign multiple tags and any number of name-value pairs. Combining these
> in the way you described would only be needed in case someone wants to
> use the same SQL/CSV table with the nonexisting columns skipped. Or?
>
> --
> Bazsi
>
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.campin.net/syslog-ng/faq.html
>
>