Kings,

Look at this link, there is a really good explanation of http messages and arg 
name regex: 

https://supportforums.cisco.com/community/netpro/security/intrusion-prevention/blog/2010/12/23/introduction-to-regular-expressions-for-ips

Regards,
Meytal




-----Original Message-----
From: [email protected] on behalf of Meytal Mizrahi
Sent: Sat 4/9/2011 5:36 PM
To: Kingsley Charles
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] Service HTTP Signature
 
Hi Kings,

We need to lab it to be sure :-)

But i don't think we will be asked for something similar in the lab.

BTW - look on signature id 16296/0, its using the "Arg Name Regex" and the 
value is not field from the entity header.

Regards,
Meytal



-----Original Message-----
From: Kingsley Charles [mailto:[email protected]]
Sent: Sat 4/9/2011 8:57 AM
To: Meytal Mizrahi
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] Service HTTP Signature
 
I think, the link refers to arguments in the entity header.

Snippet from RFC 2616

4.2 Message Headers

   HTTP header fields, which include general-header (section 4.5),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section 7.1) fields, follow the same generic format as
   that given in Section 3.1 of RFC 822 [9]



7.1 Entity Header Fields

   Entity-header fields define metainformation about the entity-body or,
   if no body is present, about the resource identified by the request.
   Some of this metainformation is OPTIONAL; some might be REQUIRED by
   portions of this specification.

       entity-header  = Allow                    ; Section 14.7
                      | Content-Encoding         ; Section 14.11
                      | Content-Language         ; Section 14.12
                      | Content-Length           ; Section 14.13
                      | Content-Location         ; Section 14.14
                      | Content-MD5              ; Section 14.15
                      | Content-Range            ; Section 14.16
                      | Content-Type             ; Section 14.17
                      | Expires                  ; Section 14.21
                      | Last-Modified            ; Section 14.29
                      | extension-header

       extension-header = message-header

   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient and MUST be forwarded by
   transparent proxies.




With regards
Kings

On Sat, Apr 9, 2011 at 11:12 AM, Kingsley Charles <
[email protected]> wrote:

> True, I had the same thought.But will a HTTP message content have an
> argument name and value as the header do?
>
> In the wireshark screenshot that I have attached, there is a text
> http-equiv="contect type" in the content. Is this an argument name valu pair
> that we are looking for.
>
> With regards
> Kings
>
>
> On Fri, Apr 8, 2011 at 5:29 PM, Meytal Mizrahi <[email protected]>wrote:
>
>>  According to the link, "Arg Name Regex" its for matching argument in the
>> entity body
>> The entity body is obtained from the message body :
>>
>> RFC 2616 -
>> 4.3 Message Body
>>
>>    The message-body (if any) of an HTTP message is used to carry the
>>    entity-body associated with the request or response. The message-body
>>    differs from the entity-body only when a transfer-coding has been
>>    applied, as indicated by the Transfer-Encoding header field (section
>>    14.41).
>>
>>        message-body = entity-body
>>                     | <entity-body encoded as per Transfer-Encoding>
>>
>>
>>
>> So you cannot match Host field....
>>
>> Maybe i am wrong...i did not check it...
>>
>> Regards,
>> Meytal
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email protected] on behalf of Kingsley
>> Charles
>> Sent: Fri 4/8/2011 9:31 AM
>> To: [email protected]
>> Subject: [OSL | CCIE_Security] Service HTTP Signature
>>
>> Hi all
>>
>> I configured a service http signature with specify-arg-name-regex defined
>> as
>> following but it didn't fire.
>>
>> Arg Name Regex = Host:
>> Arg Value regex = 10.20.30.40
>>
>>
>> When I configure service http signature with "specify-request-regex" of
>> any
>> argument in the HTTP header, it fires.
>>
>>
>>  Can someone let me know, the use of "specify-arg-name-regex"?
>>
>>
>> Snippet from
>>
>> http://www.cisco.com/en/US/docs/security/ips/5.1/configuration/guide/idm/dmSgEng.html#wp1055656
>>
>>  specify-arg-name-regex
>>
>> (Optional) Enables searching the Arguments field for a specific regular
>> expression:
>>
>> .arg-name-regex-Regular expression to search for in the HTTP Arguments
>> field
>> (after the ? and in the Entity body as defined by Content-Length).
>>
>>
>> specify-request-regex
>>
>> (Optional) Enables searching the Request field for a specific regular
>> expression:
>>
>> .request-regex-Regular expression to search in both HTTP URI and HTTP
>> Argument fields.
>>
>> .specify-min-request-match-length-Enables setting a minimum request match
>> length.
>>
>>
>>
>>
>>
>> With regards
>> Kings
>>
>>
>


_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to