If you do a wireshark capture of HTTP and then read the following snippets
from RFC 2616, you can get a picture of what is an URI.

The Header Header as an URI field that identifies the resource and hostname
that is IP address or FQDN of the server. The request URI can be absolute or
non-absolute URI.

The absolute URI is seen when the request is sent to a proxy server.

If it is an absolute URI, then the complete URI which is the hostname plus
URI should taken into account by the server.

If it is an non-absolute URI, then hostname is taken from the host field by
the server.

*

Snippets from RFC 2616*

Uniform Resource IdentifiersURIs have been known by many names: WWW
addresses, Universal Document Identifiers, Universal Resource Identifiers
[3], and finally the combination of Uniform Resource Locators (URL)
[4]<http://www.w3.org/Protocols/rfc2616/rfc2616-sec17.html#bib4>and
Names (URN)
[20] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec17.html#bib20>. As far
as HTTP is concerned, Uniform Resource Identifiers are simply formatted
strings which identify--via name, location, or any other characteristic--a
resource.

Request-URI

The Request-URI is a Uniform Resource Identifier (section
3.2<http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2>)
and identifies the resource upon which to apply the request.

       Request-URI    = "*" | absoluteURI | abs_path | authority

The absoluteURI form is REQUIRED when the request is being made to a proxy. The
proxy is requested to forward the request or service it from a valid cache,
and return the response. Note that the proxy MAY forward the request on to
another proxy or directly to the server

specified by the absoluteURI. In order to avoid request loops, a proxy MUST
be able to recognize all of its server names, including any aliases, local
variations, and the numeric IP address. An example Request-Line would be:

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1



The Resource Identified by a Request

The exact resource identified by an Internet request is determined by
examining both the Request-URI and the Host header field.

An origin server that does not allow resources to differ by the requested
host MAY ignore the Host header field value when determining the resource
identified by an HTTP/1.1 request. (But see section
19.6.1.1<http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.6.1.1>for
other requirements on Host support in HTTP/1.1.)

An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host names) MUST
use the following rules for determining the requested resource on an
HTTP/1.1 request:

1. If Request-URI is an absoluteURI, the host is part of the Request-URI.
Any Host header field value in the request MUST be ignored.

2. If the Request-URI is not an absoluteURI, and the request includes a Host
header field, the host is determined by the Host header field value.

3. If the host as determined by rule 1 or 2 is not a valid host on the
server, the response MUST be a 400 (Bad Request) error message.

Now let's apply the above the ASA, IOS and IPS sensor where HTTP analysis is
done.



*ASA HTTP class-map*

asa2(config-cmap)# match request ?

mpf-class-map mode commands/options:
  args    Apply the regular expression class-map to the arguments
  body    Apply the regular expression class-map to the message body
  header  Apply the regular expression class-map to the message header
  method  Apply the regular expression class-map to the method
  uri     Apply the regular expression class-map to the URI

asa2(config)# class-map type inspect http match-any king

asa2(config-cmap)# match request header host

asa2(config-cmap)# match request uri ?

mpf-class-map mode commands/options:
  length  Specify that the match is a length check
  regex   Specify that this is a regex match

*IOS HTTP class-map*

router1(config-cmap)#match ?
  req-resp  HTTP request or response
  request   HTTP request
  response  HTTP response

router1(config-cmap)#match request uri ?
  length  length
  regex   Regular expression

router1(config-cmap)#match request header  host ?
  count   Number of header fields
  length  length
  regex   Regular expression
  <cr>

*IPS Sensor Service HTTP Signature*

sensor(config-sig-sig-ser-reg)# ?
default                               Set the value back to the system
default setting.
exit                                     Exit regex configuration submode
show                                   Display system settings and/or
history information.
specify-arg-name-regex     arg-name-regex is an optional parameter. Use
                                          specify-arg-name-regex yes to
enable arg-name-regex
                                          for use.
specify-header-regex         header-regex is an optional parameter. Use
                                           specify-header-regex yes to
enable header-regex for
                                           use.
specify-request-regex         request-regex is an optional parameter. Use
                                            specify-request-regex yes to
enable request-regex for
                                            use.
specify-uri-regex                 uri-regex is an optional parameter. Use
                                           specify-uri-regex yes to enable
uri-regex for use.

sensor(config-sig-sig-ser-reg-yes)# request-regex ?
<request-regex>     Regular Expression to search in both HTTP URI and HTTP
                    Argument Fields.

sensor(config-sig-sig-ser-reg-yes)# uri-regex ?
<uri-regex>     Regular Expression to search in the HTTP URI Field. The URI
                field is defined to be after the HTTP method (i.e. GET) and
                before the first CRLF.


sensor(config-sig-sig-ser-reg-yes)# header-regex ?
<header-regex>     Regular Expression to search in the HTTP Header Field.
The
                   Header is defined after the first CRLF and continues
until
                   CRLFCRLF

With regards
Kings



On Thu, Dec 9, 2010 at 3:38 PM, Kingsley Charles <[email protected]
> wrote:

> Hi all
>
> With respect to CCIE, we use URL and URI at many places like Firewall,  IPS
> sig etc. It is a known fact that there is no clear definition for these
> three including the RFCs
>
> As per my understanding
>
> URI is the scheme protocol of transfer plus the network location and then
> resource
>
> http://www.king.com/security/vpn.html
>
> URN is the resource itself
>
> vpn.html
>
>
> URL is scheme plus the location
>
> http://www.king.com/security
>
>
>
> So we can say URI = URL + URN
>
>
> Please let me know your thoughts.
>
>
>
> With regards
> Kings
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to