[Oisf-users] Detect problem with http_header

[Victor Julien]

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
detect.c:DetectEngineLookupFlowAddSig).

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
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------