[Snort-devel] questions coming out of my paengine work
roesch at ...48...
Mon Dec 11 17:15:42 EST 2000
Todd Lewis wrote:
> Some of these questions are in the README.paengine which was part of
> my patch, but I figured that they probably wouldn't get answered unless
> I asked them here.
> I am really excited about the work that I'm doing on snort, and I hope
> that it turns out well. The more feedback that I can get from other
> developers, the better of a job I can do integrating my work smoothly.
> So, I really urge all the other devs out there to consider these questions
> and post their thoughts on them. (See, I can prod without yelling!)
> 1) Any thoughts on how to pass configuration information into the
> paengines? If the config file were an XML doc, which I would really
> like, then we could just pass the DOM node into the paengine, or tell
> it the name of the paengine-specific xml config file in the snort
> config directory, and then that be that. I am thinking that, given
> how varied the configurations of these paengines' are going to be,
> they will pretty much have to be in the config file. I.e., passing
> in their configuration on the command line won't really be possible.
> If command-line configuration is chosen, then we'll see stuff like this:
> snort -E pcap -e "mode=readfile infile=/tmp/bpffile outfile=/tmp/bpffile.filtered"
> I can't really see us doing this, but I'm open.
I can't see us doing this either. :) Going with something like XML
configuration files we've got to be very careful not to make it too difficult
for people to use. One of the big things about Snort is that it's relatively
easy to use if you're used to using other UNIX programs. It doesn't have a
big complicated rules language, it doesn't take a PHd and a gigahertz machine
to compile, it "makes sense" to a great number of people. Going to something
with a non-obvious language like XML could potentially be a problem from a
usability standpoint, which is something that I'm very wary of. KISS, unless
> 2) Any volunteers to separate out the pcap-specific stuff from the
> general configuration struct? If you look at how much paengine_pcap
> reaches back into the global snort configuration in my patch, you'll
> see that the separation is far from complete. I would really like
> to see those options that are pcap-specific moved to the paengine_pcap
> configuration and away from the global snort config. I can do this work,
> but someone with some more experience than I have with snort would be a
> better choice to do this work, I think, since I'll probably misunderstand
> parts of it and make the wrong decision. However, if no one volunteers,
> then I will do it.
We need to abstract the interaction between the packet grabber code and the
rest of the system. I'll probably want to do that, but it's going to have to
wait until 1.7 comes out. That's really the big sticking point right now. I
know that you want to get things going ASAP and you're really motivated to get
this working, but right now we're in something of a code freeze trying to get
version 1.7 tested and shipped. Until that happens, I'm not going to be able
to spend a lot of time working on the pa_engine stuff.
> 3) OpenPcap() doesn't really use intf except for opening files. It should
> use it for all pcap opens, right?
Nope, just for opening a file if I remember correctly.
> 4) I was thinking that pcap's readfile support should be a pcap
> configuration option, however we decide to do that (see 1, 2, above).
> This means removing it from the general command-line options. Objections?
The pcap readfile support should be used as part of its pa_engine, but having
a generic switch that allows people to specify that they want to read data
from a file shouldn't be removed. Just because we're not using libpcap
doesn't mean we won't be able to read back packet files with some other
> 5) pcap_dump is a tough feature for me to incorporate into the new system.
> May I discard it? If someone wants to keep it, then do you have
> any suggestions for how it should integrate into the paengine setup?
> Maybe some sort of modularised output code that logging and dumping
> could both plug into?
Theoretically you shouldn't have to worry about the output mechanisms at all,
just initializing the interface and providing the rest of the systems with a
packet stream. There are other modifications that will have to be made to
make something like pcap_dump() work, but as we go to this level of
abstraction it's not a big deal to add them.
> 6) Use of printf, fprintf, #ifdef DEBUG, ErrorMessage, exit and
> FatalMessage seems haphazard. Would anyone mind if I clean them up?
> As more code is modularised, this problem will get worse. Marty, if
> you could write up some guidelines for how this is all supposed to work,
> then it would make life much easier for new developers like myself.
> Even crappy, hastily-written standards are preferrable to no standards
> on stuff like this.
Ok, here's how it should work.
#ifdef DEBUG: should be left in there and use fprintf with a global specified
as the output FILE stream (default: stdout). Alternatively, there's a really
cool mechanism that Mike Stolarchuck showed me to turn output on and off in
different modules, which I may implement. For the time being the #ifdef DEBUG
stuff should stay in there
prinf & fprintf: These are somewhat context sensitive. Many error and warning
messages still use printf/fprintf, and they should probably be changed to
ErrorMessage() calls. Status messages should maybe have some sort of
Message() or Info() function defined that would centralize the output function
and make it easier to send messages to syslog, etc.
ErrorMessage: This should probably be converted to just plain Message() and
used throughout the program.
FatalError: This gets used when the program is going to output an error
message and exit due to some problem.
> 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
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
roesch at ...48...
More information about the Snort-devel