[Snort-devel] xml thoughts
alambert at ...89...
Wed Feb 7 16:28:19 EST 2001
> > XML files induce a level of complexity that I, for one, do not
> > wish to deal with. More experienced developers/users will probably
> > disagree with me on the fact that XML is _more_ complicated than formatted
> > flat ASCII, but trust me, from the 'ignorant savage' point of view (which
> > I consider myself to be a good represenative of), a flat ASCII file is far
> > easier to work with (especially when using the hog.vim syntax highlighting
> > file :)
> I think that a lot of this thinking is just natural psychological
> resistance to change. The present format is easier to use not because
> it is better, but just because users are familiar with it.
Well, in a word, yes. :) I know what I'm doing with the current
files specifically, and flat ascii files in general. Anyone who's spent
any amount of time admistering a UNIX box knows the concepts involved in
flat ascii config files backwards and forwards, and can probably write you
a shell script to do anything you want to/with said flat ascii file in a
relatively short period of time. There's a knowledge base in flat ascii
files that I have, and I daresay most anyone who works in the UNIX world
has. I won't deny that aspect of my argument. :)
However, it's not entirely resistance to change that makes me make
the statements I've made. XML is a significantly more complicated format,
and adding complexity for the end result being that snort continues to do
what it already does for me, is not something that I consider to be in my
best interest as a 'non-programmer ; light scripter' of a snort user.
> > Automated file manipulation is trivial with the current file
> > format. I myself am probably one of the most clueless programmers on the
> > planet (really; I suck, trust me), and I can/have whipped up some simple
> > code without too much problem to do everything from add "react:" tags to
> > the appropo rules, change the "flags:" statments, snag the latest
> > snort.org and vision.conf rulesets, rip out the rules that have
> > historically caused an inordinate amount of false positives, combine the
> > two, rip out duplicates, and other such tasks.
> Sure, you can whip up scripts easily, but they break at the drop of
> a hat with the present format, as does snort's parser. Also, as is
> normally the case with hand-rolled formats, it's much easier to create
> the present format than it is to parse it.
Actually, none of the parsers I've written have ever broken with
the current rule format. My scripts leave unknown keywords alone, and
modify/work with the ones they know what to do with. Easy money.
I was not aware that the rules parser in snort broke frequently
either (although I would probably not be too aware of that kind of thing,
since I typically never mess with the CVS tree). I know snort will choke
if you mutz up the rule files, but I don't see that it's a problem that a
program refuses to run when I feed it bad input. I pretty much expect a
program to not do what I expect, when I can't give the program what it
expects in a language that program understands.
> Finally, the present format is very simple not because of any great
> design but rather because hacking snort's parser is so hard that it
> places a fundamental (and artificial) (and very unfortunate)
> restriction on the complexity that can be embodied in the rules.
> This is already constraining snort development and will do so even
> more as snort gets better.
See, this is part of my point; placing constraints on complexity
is something I consider a 'good thing', not a 'bad thing'. There is a
quote that originanted in the Engineering world, that later got adapted to
the Software world, that goes something like "Programmers/Engineers are so
enamoured with the idea that they _can_ do X, that they never stop to ask
if they _should_ do X". Having built in constraints as to how complex
things can be made, in my opinion lends itself to the enforced simplicity,
which is (IMHO), a good thing. And really, what is there that snort
doesn't do, that it so desperately needs to do? (rules-file wise, plugins
like SPADE, and tcp stream reassmebly and such are a whole other matter)
> > Writing the same kind of
> > code for XML is an order of magnitude more complicated (at least from my
> > point of view), and short of spending a lot of time improving my skills in
> > this area, I would become relegated to either manually making changes, or
> > hoping someone else writes a tool to accomplish what I want.
> I disagree that:
> print("$rnum $src $dest\n");
> is substantially easier than:
> print("<rule>$rnum</rule> <source>$src</source> <dest>$dest</dest>\n");
You're correct in your example, but that looks like format
conversion code to me, not what I'm talking about. I can print();, or
printf();, or echo whatever in the world, but the hangup comes in when I
need to write a program to read the XML (or other <Tag>blah</Tag> type
file), and break all that up into values that I can then manipulate.
It's very easy to split a line of ASCII into it's various parts, but it's
a whole other thing to split up XML files into parts. As I think I saw
mentioned elsewhere in this thread, you basically need a library that
already knows how, or you have to write some rather painful code yourself.
Being a shell scripter, I don't have a library that already understands
XML files, and I don't know of a good way to write a parser for that kind
of thing in Shell (or C for that matter, the only other language I have
any experience with (very little experience mind you, but I've actually
written some simple things in C that worked)).
> And I guarantee that if you take the existing format and my draft
> format and give it to someone who's never used snort, that my format
> is much more understandable than the existing format. (Again, this is
> not to advocate my format, which should be improved or replaced, but
> to emphasize XML's advantage.)
I can read and understand the format of both with equal ease.
However, I'm not talking about understanding the format, I'm talking about
practical day-to-day working with the format; writing little scripts to
alter stuff, that kind of thing. All of that kind of work gets an order
of magnitude harder with XML for guys like me (as I said, I'm not much of
> > I'm not disagreeing with any of the positive points made about XML
> > (from a technical perspective, they sound quite reasonable to me), just
> > saying that some of us farther down the scale of talent/experience will
> > not have our lives improved, and will probably have them complicated even
> > more than they already are, if we convert wholesale to XML.
> I agree that there will be work to do to convert. However, especially
> if snort continues to become more complicated, I don't think that your
> life will be especially pleasant with the existing format. I know
> that the people who have to maintain rules.c are not going to lead
> pleasant existences with the status quo.
Again, I'll disagree. There's nothing you can put in snort's
current format of flat ascii rules files, that I can't handle with
relative ease; both from the "can I read it and understand it" point of
view, and from the "can I write a quick shell script to make the following
generic changes" point of view. That second item is the part that will be
lost to us non-programmers out here who use Snort if we convert to XML
And again, I'll say that from your technical standpoint as a
developer, I think you're very right in your argument. I'm not saying
"you're wrong", I actually think you make a great case for what you
propose, from a _developers_ point of view. I'm just asking you to see
things from the point of view of me; an end user of Snort. To me (and
those like me) XML config files just add complexity, and remove
flexibility, without doing much to alter what I use snort for, and what
snort does for me. Cheers!
More information about the Snort-devel