[syslog-ng] [announce] patterndb project

Martin Holste mcholste at gmail.com
Fri Jul 2 00:35:44 CEST 2010


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.


On Thu, Jul 1, 2010 at 3:23 PM, Balazs Scheidler <bazsi at balabit.hu> wrote:
> On Thu, 2010-07-01 at 11:03 -0500, Martin Holste wrote:
>> Shouldn't that go under the provider attribute?  My point with the
>> ID's vs UUID was that I prefer a numeric ID.  Just as with IP space,
>> we could provide a "number space" for local signatures.  For instance,
>> 0 through 2,000,000,000 would be public space, and 2,000,000,000
>> through 2^32 would be private space.
>>
>> I think the "opensshd" component would be assigned to the "name"
>> attribute, or something similar, or maybe would be the "class"
>> attribute.
>
> let me think this through and also discuss with the guys who originally
> designed the XML format and come up with a consistent recommendation on
> IDs.
>
> Any other comments on the "patterndb" policy document at
>
> http://git.balabit.hu/?p=bazsi/syslog-ng-patterndb.git;a=blob;f=README.txt;h=9bbfeaead0c21dcf6171e12e311ae8612f572bfc;hb=6061e22221a72d35238b35f82b04afd436341b5c
>
> Perhaps about the two schemas I've described at the same location in
> SCHEMAS.txt<
>
> --
> 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
>
>


More information about the syslog-ng mailing list