[Oisf-users] Detect problem with http_header

[Anoop Saldanha]

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.

>> One thing to consider that would be a major improvement over Snort
>> would be to actually parse the headers (again, I'm assuming that
>> HTPlib already does this) so you could specify a normalized header is
>> present, like this:
>> content:"asdf"; http_user_agent;
>>
>
> If there's a need/request we sure can support this, but I think Victor
> had a format for checking app proto specific properties which was much
> better/neater.
>
> Till then we can achieve the same thing using http_header.
>
>> That would be a HUGE win, and I don't think it would be nearly as much
>> work as you'd think, since HTPlib should be doing that parsing
>> already.  The main work would be adding all the keywords in, but I
>> think we can all agree that it would be worth it because so many
>> signatures rely on searching specific header values.
>>
>
> heh, I haven't told you whether it is hard or easy to do this now,
> have I?  Don't worry about the implementation.  We'll get it done
> either ways.  There's no work involved in this feature and either ways
> we already work on normalized headers with http_header(libhtp does all
> the http work for the engine).  The only work would be adding support
> for a new keyword, which really is no biggie.  So getting the request
> across for a new keyword is the only task I see.
>
>> On Thu, Dec 29, 2011 at 10:00 AM, Anoop Saldanha <poonaatsoc at gmail.com> wrote:
>>> On Sat, Dec 24, 2011 at 9:32 PM, Martin Holste <mcholste at gmail.com> wrote:
>>>> Ok, opened 389.  Happy holidays to all as well!
>>>>
>>>> On Sat, Dec 24, 2011 at 8:31 AM, Victor Julien <victor at inliniac.net> wrote:
>>>>> On 12/23/2011 07:59 PM, Martin Holste wrote:
>>>>>> I'm trying to get a signature to work which is looking for a specific
>>>>>> server response HTTP header, namely:
>>>>>> content:"|0d 0a|Content-Disposition: attachment|3b| filename=";
>>>>>> If I add "http_header" as a modifier, it doesn't hit.  Client stuff
>>>>>> seems to work fine.  I'm using the default libhtp config.
>>>>>> Suggestions?
>>>>>
>>>>> A quick look at code shows what the problem is: in our implementation
>>>>> http_header currently only inspects the request headers. Please open a
>>>>> feature request!
>>>>>
>>>>> Happy holidays everyone!
>>>>>
>>>>> --
>>>>> ---------------------------------------------
>>>>> Victor Julien
>>>>> http://www.inliniac.net/
>>>>> PGP: http://www.inliniac.net/victorjulien.asc
>>>>> ---------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Oisf-users mailing list
>>>>> Oisf-users at openinfosecfoundation.org
>>>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>> _______________________________________________
>>>> Oisf-users mailing list
>>>> Oisf-users at openinfosecfoundation.org
>>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>
>>> Wondering if it makes sense to introduce explicit keyword based
>>> option for response header inspection,
>>>
>>> http_header<,type>;
>>> http_raw_header<,type>;
>>>
>>> where type - request;
>>>                   - response;
>>>
>>> if no type's specified we default to just request or both maybe.
>>>
>>> --OR--
>>>
>>> we inspect both request and response headers always.
>>>
>>> --
>>> Anoop Saldanha
>
>
>
> --
> Anoop Saldanha



-- 
Anoop Saldanha