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

Gareth gisaac at ...239...
Wed Jan 9 19:10:04 EST 2002

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?

I can see several benefits to making the rules XML based:

1) Allows a large variety of languages to parse the rule set out of the box
2) Given (1) the number of rule editors will increase raising the profile of
Snort in the SOHO vertical
3) Each rule can contain more information than the alert rule itself. i.e.
Descriptive text of the attack, spoofability, suspectable machines etc.
4) Allows XSL(T) rendering of the rules for easy viewing in XML aware
5) Allows more standard technology (i.e. XMLSQL) to manipulate and merge
rule sets.
6) Standard XML schema/DTD validation could be used to check the rule sets.

Again no rocket science, but it removed the requirements to write a Snort
rule parser for developers/administrators.

The large con would be the fact that there are a large number of rules
already, and a migration mechanism would probably be required. Plus the fact
that Snort would in all likelyhood need a simple XML parser to be included.

Basically the reason to move to XML would not directly contribute to making
Snort technically better at detection, but would enable more rapid
development of addon products to help manage the Snort rule sets. In reality
the current rules sets would just be wrapped up into a XML structure.
[Obviously there could be a migration script to get from one rule set to

Anyway I've finished my piece, the question is this a possibily? I wanted to
throw this out as I hope all Snort development remains main-stream and
avoids any base fragmentation.



More information about the Snort-devel mailing list