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@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