[Oisf-users] Detect problem with http_header

[Victor Julien]

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.

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