From: mahmoud genidy (ccie.mahmoud@gmail.com)
Date: Mon Feb 23 2009 - 20:51:39 ARST
In fact guys this is confusing. So the conclusion regarding NBAR to match
HTTP traffic:
- We can ONLY match HOST and URL in the GET request from the web-server
(Client->Server) session.
- We can use MIME matching on the reply from server (Server->Client)
direction.
Up to this point, every body agree on the above info?
Ok, now how we can match the traffic coming from SPECIFIC web-server
(Server->Client) if I can't match based on HOST and URL?
Of course assuming I don't have the IP address of the web-server.
Thanks,
M Genidy
On Thu, Feb 19, 2009 at 10:24 AM, Dale Shaw <dale.shaw@gmail.com> wrote:
> Hi,
>
> On Thu, Feb 19, 2009 at 7:04 AM, Jared Scrivener
> <jscrivener@ipexpert.com> wrote:
> >
> > If we match the host that'll apply to all packets from the host. If we
> match
> > MIME that'll apply to the MIME session. If we match both as a match-all
> (as
> > I described) we'll only be filtering for packets from that host that
> match
> > the specified MIME type and that filter will apply on a per MIME
> transaction
> > basis.
>
> Sorry to nitpick (hey, being pedantic is a CCIE candidate's life!),
> but there's no such thing as a "MIME session" -- the MIME type is
> simply specified in server -> client communication using the
> "Content-Type:" header.
>
> Here's a simplified example:
>
> 1. client sends HTTP GET for a .jpg image (client -> server):
>
> GET /en/US/home/images/fp-network-storage.jpg HTTP/1.1 <-- see that?
> Host: www.cisco.com
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
> Accept: image/png,image/*;q=0.8,*/*;q=0.5
> Accept-Language: en-au,en-us;q=0.7,en;q=0.3
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.cisco.com/
>
> NOTE: this is the only time IOS will be able to "see" a request for a
> URL containing a ".jpg" string.
>
> 2. server acknowledges request and returns the requested content
> (server -> client):
>
> HTTP/1.1 200 OK
> Date: Wed, 18 Feb 2009 23:08:01 GMT
> Server: Apache/2.0
> Last-Modified: Tue, 17 Feb 2009 21:45:47 GMT
> ETag: "1073"
> Accept-Ranges: bytes
> Content-Length: 4211
> LCFHOST: ccows-sj-103
> Content-Type: image/jpeg <-- see that?
> Connection: Keep-Alive
> [... image data stripped ...]
>
> NOTE: this is the only time IOS will be able to "see" a MIME type
> specified.
>
> I agree with Ivan in that MIME type (Content-Type) can only be matched
> in the server -> client direction.
>
> Similarly, matching on the HTTP Host (something which I believes
> requires HTTP/1.1 as the Host: header is not sent from the client in
> HTTP/1.0) can only be matched in the client -> server direction. Again
> this matches Ivan's experience.
>
> I reckon the best solution (noting that it's gonna make for a pretty
> miserable web browsing experience :-)) is to match on the web server's
> IP (woops, more agreeing with Ivan). Matching on MIME type would be
> the way to meet the second requirement (drop images), but the thing
> about MIME types is they're completely arbitrary and set by the
> server. I could set up my web server to send you a .txt file with a
> MIME type of image/jpeg. Though I guess that's no less arbitrary than
> the name and extension you give to a file.. anyway, going off on a
> tangent there.
>
> Disclaimer: I haven't labbed this myself but have a reasonable amount
> of experience with HTTP as an application layer protocol. Happy to be
> corrected.
>
> cheers,
> Dale
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:12 ARST