[Oisf-devel] alerts from modules and status of global variables

David Mandelberg dmandelb at bbn.com
Fri Jun 17 19:15:17 UTC 2011


Thanks!

On Fri, 2011-06-17 at 11:59 +0200, Victor Julien wrote:
> On 06/16/2011 05:42 PM, David Mandelberg wrote:
> > Since the error comes from network traffic rather than administrator
> > input or code malfunction, it seems like it would make sense to send it
> > as an alert instead of logging. I grepped the code for
> > PacketAlertAppend, which as far as I can tell is the function that sends
> > alerts, but the only calls to it look like they stem from rules
> > activating. Are there any reasons it couldn't be called from e.g.
> > app-layer-htp.c to alert on errors in protocol formats?
> 
> Yes, the reason is that the http parser is only given access to a
> flow/http state, not to a packet. This is significant because the alerts
> are stored and then further processed on a packet basis. The detection
> engine takes care of that normally. In this case the appropriate
> solution would be to allow a detection keyword to retrieve errors from
> the flow/http state. Like I wrote in my reply to Martin's email, that is
> planned and I'm making sure it happens soon.
> 
> > Also, according to the website, global variables aren't implemented yet
> > and rule variables are local to each flow. It looks like flow variables
> > are implemented in detect-tag.*, but detect-tag.h has an enum with both
> > DETECT_TAG_TYPE_SESSION and DETECT_TAG_TYPE_HOST. Does that mean that
> > Suricata supports variables that are local to either each flow or each
> > host? Is there any road map for support for fully global variables?
> 
> The flowvars/bits/ints live in different code: flow-var.[ch]
> flow-bit.[ch] and in detect-flowint.[ch], detect-flowvar.[ch] and
> detect-flowbit.[ch].
> 
> The tag code is only used to support the "tag" signature keyword. It
> does have more global data structures, but it's use it limited to
> tagging currently.
> 
> Cheers,
> Victor
> 

-- 
David Mandelberg
Fri Jun 17 15:14:56 EDT 2011




More information about the Oisf-devel mailing list