[Oisf-users] Detect problem with http_header

Victor Julien victor at inliniac.net
Wed Jan 4 08:46:09 UTC 2012

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

More information about the Oisf-users mailing list