[Snort-devel] xml thoughts
tlewis at ...255...
Wed Feb 7 11:42:31 EST 2001
Some random ideas in support of XML.
1) As I mentioned in my previous message, for modular systems like the
paengine, snort can have rich config file support for the modules in
an extensible way, with no knowledge required in snort's core, using
XML's namespace system. This could also be applicable, e.g., to such
plugins as logging systems, adaptive response engines (i.e., adaptive
controllers for snort's newfound GIDS functionality), etc. Marty, if
you ever want your dream to come true of snort being 100 lines of code
with 100,000 lines of plugins, then this is a great way to help.
2) It is much easier to modify the form of the config file with XML
than with the present format because items' meaning is explicit via
tags rather than implicit via position. Just come up with a new tag
name for the new format and include handlers for both the old and new
tags in your XML receiver in snort. Bang, easy upwards compatibility.
Contrast this with the fact that format changes today are either totally
incompatible or really gross (like multiple network support, with either
Marty's or my syntax.)
2a) The present syntax is very creepable. It's easy to modify the
parser in such a way that the files become subtlely incompatible and
not even realize that you're doing it. XML is a formalized document
system riding SGML's decades of work in building structured documents
with unambiguous meaning.
3) XML is validatable. Contrast this with the present "Snort segfaulted;
I wonder if I have a syntax error?" technique of config file validation.
4) It is hyper-easy to write programs to generate these XML files.
Perl, python, java, C, Visual Basic, ECMA script, PHP, every language
known to man and then some have XML suppport. Ergo, it's very easy to
write GUI tools, web interfaces, automatic converters or anything else
you want to generate a rule file. Contrast this with how hard it would
be to generate config files for the present format and be able to rely
on their correctness.
5) Think of all of the little features that XML has that a home-grown
format will never support. Namespaces is the classic example here of
how jumping on the bandwagon will take us a lot farther than we'll walk
on our own. As snort evolves, our needs for a config file are going
to become a lot more demanding. Whatever our needs are, though, I can
promise that we'll never be in the front ranks of demanding XML users; we
can just ride the wave with already-developed solutions to our problems.
Sticking with the present format means both a lot of work in the future
and a lot of cramping of new ideas because no one wants to code up config
file support for it.
6) It'd be super easy to display rule files in XML. Just whip up a
style sheet and throw it into mozilla. 8^)
7) Managing XML is doable. Viz. all of the XML database integration
that's happening today. For people like SecureWorks who have to manage
rule files in a rigorous way, XML's databasificationability is a real
win. (That's the best neologism I've come up with in a while!)
Todd Lewis tlewis at ...120...
God grant me the courage not to give up what I think is right, even
though I think it is hopeless. - Admiral Chester W. Nimitz
More information about the Snort-devel