[Oisf-devel] http buffers

Victor Julien victor at inliniac.net
Tue Feb 14 13:41:21 UTC 2012


On 02/14/2012 01:12 PM, Chris Wakelin wrote:
> On 14/02/12 11:52, Victor Julien wrote:
>> Noticed quite a few ET rules match completely in HTTP buffers (uri,
>> headers, etc) except for the request and/or response protocol.
>>
>> What about adding http_proto (http request proto) and http_stat_proto
>> (http response proto) in Suricata? Any use for that?
>>
>> They would contain "HTTP/1.1" or "HTTP/1.0".
> 
> Sounds useful!
> 
> What about other common headers such as "Host:" and "Referer:"? Would we
> get a performance boost?

Preparing the buffer would require some cycles, we'd safe some on
inspection. My guess is a minor speedup, but hard to predict.

Adding more buffers is certainly possible. User-agent would be a good
candidate too I think.

> 
>> The HTTP/0.9 case is interesting, as it commits this field. We could
>> forge it, so you can match on "HTTP/0.9". Thoughts?
> 
> You mean "omits" rather than "commits" I think? Forging it makes sense,
> I guess.

Ya omits indeed :)

> 
> One thing I wondered about the HTTP engine is would it be possible to
> have single rule check both request and response headers, or even
> request headers and response body, or will we need to use flowbits?

Technically it's possible, and in some cases it may even already work.
We've been enforcing adding a direction on some keywords though.

I think we never really made a decision on where to go with this. The
rule language and current rule writers think in one direction I think.
But bidirectional, especially for HTTP, is possible since we inspect the
full HTTP state.

> e.g. I have a couple of rules using flowbits that look for an executable
> downloaded from "/" without a referrer.

Ya I can see the use. Have you tried a sig like this? I wonder about
performance too.

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




More information about the Oisf-devel mailing list