[Snort-devel] RFC - XML Rules definition question?

Gareth gisaac at ...239...
Wed Jan 9 20:13:02 EST 2002


[Andrew & Chris]

I honestly tried to search the archive (and the web) for such a discussion
:-/

But as is has been discussed already and vitoed then I'm fine with that.
Consider the topic closed, but thanks for the quick feedback :-)

Gareth

PS I'm not a commercial IDS anything, not to say the others were not! I'm
just playing with a new GPL firewall that has Snort built in - but am a
developer who likes to keep things simple :-)


----- Original Message -----
From: "Andrew R. Baker" <andrewb at ...835...>
To: "Gareth" <gisaac at ...239...>
Cc: <snort-devel at lists.sourceforge.net>
Sent: Wednesday, January 09, 2002 10:55 PM
Subject: Re: [Snort-devel] RFC - XML Rules definition question?


> Gareth wrote:
> >
> > Ok - I may be in the wrong place, but no-doubt someone will tell me :-)
> >
> > How would I go about proposing a change to the rule set definitions?
I'll
> > make my case now - please shoot me down if this is the wrong place etc.
> >
> > Snort currently uses a rule set that is configured as a set of flat
files.
> > However to externally parse and update these files means that custom
code
> > needs to be written to read/generate the rule sets. I know its not
rocket
> > science, but as there are a number of XML parsers out there already
could
> > that be a better option?
>
> This has been discussed before.  The consensus then was (and I don't
> think that it has changed) that an XML based rules language will make
> writing and reading rules rely entirely on external applications.  I
> will no longer be able to write a new rule by just opening up the rules
> file with vi.
>
> The current rules language is designed to rules to be easily understood
> and written.  An XML based language would require the use of a seperate
> program for reading and writing new rules.  This will cause a decrease
> in the number of new rules being added.  It will also cause maintenance
> of the existing rules more cumbersome.  I will no longer be able to
> quickly scan the ruleset and disable rules that I don't want running.
>
> With the addition of the signature IDs, it becomes fairly easy to track
> meta data about rules (such as an in-depth description, affected
> systems, etc.) without cluttering up the rules files themselves with
> such information.
>
> -A
>
> Sometimes I wonder if these requests for an XML based rules language
> really originate with commercial IDS vendors who want to use snort
> rules, but don't want to write a custom parser for them.





More information about the Snort-devel mailing list