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

[Victor Julien]

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

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------