[Oisf-users] Detect problem with http_header

Victor Julien victor at inliniac.net
Wed Jan 4 09:04:00 UTC 2012

On 01/04/2012 09:56 AM, Anoop Saldanha wrote:
> On Wed, Jan 4, 2012 at 2:16 PM, Victor Julien <victor at inliniac.net> wrote:
>> On 01/04/2012 09:40 AM, Anoop Saldanha wrote:
>>> On Fri, Dec 30, 2011 at 1:04 AM, Anoop Saldanha <poonaatsoc at gmail.com> wrote:
>>>> On Thu, Dec 29, 2011 at 10:46 PM, Martin Holste <mcholste at gmail.com> wrote:
>>>>> Are request headers completely unparsed at the moment with HTPlib?  I
>>>>> would think that the intensive work is already done anyway by HTPlib,
>>>>> regardless of pattern matching.  I think that the keyword should work
>>>>> the same way it does in Snort,
>>>>> as I see little advantage to verbosely
>>>>> specifying the direction, since the stream direction already does
>>>>> that.
>>>> Right.  The stream direction takes care of that
>>> Coming to think about it, looks like we might need a direction
>>> specifier for http_header on "any -> any" rule if I am not wrong.
>>> With rules that needs inspection on both request and response headers,
>>> we have an issue.
>>> alert tcp any any -> any any (content:request_header_only;
>>> http_header; content:respone_header_only; http_header; sid:1;)
>>> The only way we can match these rules is to see that at the end of a
>>> tx inspection, all the content header keywords in the rule should
>>> match when both the request and response parts are inspected, which is
>>> really not suggested as it's unclean and adds unnecessary complexity
>>> to our detection engine to satisfy a specific ANY use case.
>>> Separation wrt direction at the http_header level is suggested like
>>> how we have with client_body and server_body keywords.
>> We can just inspect both directions for sigs like that. For to_server
>> packets we can do the request header inspection, for to_client the
>> response header inspection.
> How would we know that the rule writer meant one header inspection is
> on the request part only and the other header on the response part?
> We still store the headers under one smlist.

The signature contains direction info, or not. In the latter case we
already assume both. We currently use this in the init stage (see

The logic is that with flow:toserver; a http_header would be inspecting
request headers, with flow:toclient; a http_header would be inspecting
response headers, with no flow direction set it would inspect both.

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

More information about the Oisf-users mailing list