[Snort-devel] many bugs in config directives
roesch at ...402...
Mon Jul 23 10:26:40 EDT 2001
> I'm running snort Version 1.8.1-beta3 (Build 50), and I have been
> trying to use the config directives. They don't work very well. During
> the course of debug this I've found:
That's why they're still undocumented. :)
> Setting 'config no_promisc' in the config file does nothing by
> itself. This is because InitInterfaces is called before the rules file
> is parsed, because, according to the comments, some output plugins
> require it. If that's really the case, then shouldn't those output
> plugins check if ifr_count > 0 and call InitInterfaces themselves? The
> ordering constraints could then be documented. Or, InitInterfaces could
> be called when 'config no_promisc' is parsed.
Hmm, this is a definite ordering issue. I don't know if it's best to
remove this as a config option all together or try to delay the
interface initialization (or maybe reinitialize the interface) until
after the rules file has been parsed and all config information has been
> The "config interface:" option adds a second interface, which does not
> work unless USE_PTHREADS is on. Is this really what you want? I
> would think that if no interface is specified on the command line and
> only one is specified in the config file, then that is the only
> interface to be used. If you really wanted 'config interface' to add
> to the list of interfaces, it should throw up an error if used without
This is another problem with early interface initialization (i.e. before
the conf file has been read) and is another place where we should set
the code to re-initialize the interface if necessary.
> The call SetPktProcessors must be moved to after reading the config
> file for multiple interfaces to work.
> While looking through the code, I've found 2 fairly similar functions
> being used: SyslogAlert in log.c when the -s option is used, and
> AlertSyslog in spo_alert_syslog.c when 'output alert_syslog' is used.
Fixed and committed.
> The latter is obviously out of date, since it doesn't spew out the
> session info. There are also a bunch of other minor differences.
> It was pretty trivial to make them both use the same func. The same
> goes for the smb alerts.
SMB alerts == the tool of satan. I'll fix it anyway. ;)
> Also, what's the deal with otn_tmp? Is it ok to unconditionally set it
> to null before the anomsenor calls the alert functions. This would
> eliminate the random classifications that it throws up there. Or has
> this been eliminated by other means?
It's ok to clear it in a preprocessor, it doesn't really get to be
important until the detection engine has done its job. If the detection
engine gets a detection event, it sets a pointer to the OTN that the
engine fired on in otn_tmp, then some of the other post-detect functions
use that pointer. We're actually clearing it in the packet processing
loop now days, so it probably doesn't need to be explicitly cleared in
the SPADE code, but you'd have to ask the SPADE guys about that.
> Tony Lill, Tony.Lill at ...551...
> President, A. J. Lill Consultants fax/data (519) 650 3571
> 539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
> --------------- http://www.ajlc.waterloo.on.ca/ ----------------
> "Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
roesch at ...402...
http://www.sourcefire.com - http://www.snort.org
More information about the Snort-devel