From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Sun Sep 19 2004 - 19:10:56 GMT-3
Well, it could be but I guess it would be complicated.
If you asked "give me all images" to a site like cisco.com...
In any case, IMaGe tags have URLs for the image file, and the client
asks for them only knowing it is an image with a given URL.
Client asks for URL, gets content. Content type is one of the headers
that the client receives:
(request)
GET /swa/i/logo.gif HTTP/1.1
Host: www.cisco.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
Accept: video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
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/
Cookie: LastSpotlight=1; CP=*; CP_GUTC=128.107.241.137.30931060693597149
If-Modified-Since: Thu, 22 Aug 2002 17:15:30 GMT
If-None-Match: "2b1"
Cache-Control: max-age=0
(answer)
HTTP/1.1 200 OK
Date: Sun, 19 Sep 2004 22:09:17 GMT
Server: Apache/1.0 (Unix)
Last-Modified: Thu, 22 Aug 2002 17:15:30 GMT
ETag: "2b1"
Content-Length: 689
Content-Type: image/gif
Connection: keep-alive
...
none wrote:
> The client downloads a webpage and then download each jpg. So the client
> would request content. The webpage tells the client which image files to
> download. Therefore isn't it reasonable that the client could use "get"
> request for MIME type image, jpg, or plainly "anything.jpg"?
>
>
> Alsontra
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Carlos G Mendioroz
> Sent: Sunday, September 19, 2004 7:58 AM
> To: swm@emanon.com
> Cc: 'Joe Rothstein'; ccielab@groupstudy.com
> Subject: Re: MQC to filter MIME-types
>
> Just common sense says that the client has no way of knowing the type of
> the content the server has... and my ethereal did confirm this. :-)
> The client can specify type of content it is willing to accept from the
> server though...
>
> Scott Morris wrote:
>
>
>>"both" is referring to the URL information as well as the MIME type.
>>
>>And previously, I would have agreed with you about the content-type
>
> header,
>
>>however when I tested it with my trusty-rusty Ethereal packet capture, the
>>only place I saw a reference to the content header stuff and MIME types
>
> was
>
>>in the GET information from the client to the server.
>>
>>RFC 2045 which lays out the MIME stuff doesn't seem to indicate things one
>>way or the other... At least not on a quick skimming...
>>
>>
>>Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
>>JNCIP, et al.
>>IPExpert CCIE Program Manager
>>IPExpert Sr. Technical Instructor
>>swm@emanon.com/smorris@ipexpert.net
>>http://www.ipexpert.net
>>
>>
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>>Carlos G Mendioroz
>>Sent: Sunday, September 19, 2004 10:06 AM
>>To: Scott Morris
>>Cc: 'Joe Rothstein'; ccielab@groupstudy.com
>>Subject: Re: MQC to filter MIME-types
>>
>>Scott,
>>what is "both" referring to in your statement ?
>>URL goes from client to server (GET or POST request) But MIME type goes
>
> from
>
>>server to client (HTTP Content-Type header)
>>
>>Problem in the exam is that there is no web server, and it might be the
>
> case
>
>>that it is not clear where the server and the clients are regarding to the
>>filtering you are asked to perform... good time to resort to your helpful
>>proctor :-)
>>
>>Scott Morris wrote:
>>
>>
>>
>>>It depends on what way you are looking to filter the information....
>>>Both of these are designed to be filters going TO the web servers (so,
>>>in or out depends on whether you are the client or server system).
>>>HTTP GET requests will contain both pieces of information. The
>>>responses are simply labeled as "http data".
>>>
>>>This may have affected the functionality of your filtering!
>>>
>>>HTH,
>>>
>>>
>>>Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
>>>CISSP, JNCIP, et al.
>>>IPExpert CCIE Program Manager
>>>IPExpert Sr. Technical Instructor
>>>swm@emanon.com/smorris@ipexpert.net
>>>http://www.ipexpert.net
>>>
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>>>Of Joe Rothstein
>>>Sent: Sunday, September 19, 2004 5:08 AM
>>>To: ccielab@groupstudy.com
>>>Subject: Re: MQC to filter MIME-types
>>>
>>>I was just doing some testing with NBAR since I have been frustrated
>>>with the documentation, etc., and needed to see for myself how this really
>>
>>works.
>>
>>
>>>This config drops the .jpg and .gif files being sent by a web server:
>>>
>>>class-map match-any HTTP_IMAGES
>>> match protocol http url "*.gif"
>>> match protocol http url "*.jpg"
>>>!
>>>!
>>> policy-map HTTP_DROP
>>> class HTTP_IMAGES
>>> drop
>>>
>>>
>>>Applied to fa 0/1:
>>>
>>>interface FastEthernet0/1
>>> ip address 10.60.60.1 255.255.255.248
>>> service-policy output HTTP_DROP
>>> speed 100
>>> full-duplex
>>>end
>>>
>>>
>>>I also applied ip nbar protocol-disc on the opposite of the router
>>>where traffic was flowing just to verify the flows. But as Marvin said
>>>previously, this is NOT needed.
>>>
>>>I also got this variation to work with no problems:
>>>
>>> class-map match-any HTTP_IMAGES
>>> match protocol http mime "*gif"
>>> match protocol http mime "*jpg"
>>>!
>>>!
>>> policy-map HTTP_DROP
>>> class HTTP_IMAGES
>>> drop
>>>
>>>
>>>So it appears that both of these configurations work with no problems.
>>>I wonder if one is preferred over the other.
>>>
>>>Any comments?
>>>
>>>Joe
>>>
>>>
>>>
>>>
>>>On Sunday, Sep 19, 2004, at 02:57 Europe/Berlin, marvin greenlee wrote:
>>>
>>>
>>>
>>>
>>>>Example showing that matching traffic does NOT need protocol discovery
>>>>turned on:
>>>>
>>>>***Sample policy map to drop telnet, applied inbound on an interface.
>>>>
>>>>r13(config)#ip cef
>>>>r13(config)#class-map telnet
>>>>r13(config-cmap)#match protocol telnet r13(config-cmap)#exit
>>>>r13(config)#policy-map telnet r13(config-pmap)#class telnet
>>>>r13(config-pmap-c)#drop r13(config-pmap-c)#exit r13(config-pmap)#exit
>>>>r13(config)#int atm2/0 r13(config)#service-policy input telnet
>>>>
>>>>***Attempt telnet from another router. Telnet will be unsuccessful
>>>>because traffic is being dropped.
>>>>
>>>>r14#telnet 172.16.2.2
>>>>Trying 172.16.2.2 ...
>>>>% Connection timed out; remote host not responding
>>>>
>>>>r14#
>>>>
>>>>***Remove the policy from the interface.
>>>>
>>>>r13(config)#int atm2/0
>>>>r13(config-if)#no service-policy input telnet
>>>>
>>>>***Telnet is successful.
>>>>
>>>>r14#telnet 172.16.2.2
>>>>Trying 172.16.2.2 ... Open
>>>>
>>>>User Access Verification
>>>>
>>>>Password:
>>>>r13#
>>>>
>>>>
>>>>- Marvin Greenlee, CCIE#12237
>>>>Network Learning Inc
>>>>marvin@ccbootcamp.com
>>>>www.ccbootcamp.com (Cisco Training)
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Joe Rothstein [mailto:ziutek@mac.com]
>>>>Sent: Saturday, September 18, 2004 11:08 AM
>>>>To: ccielab@groupstudy.com
>>>>Subject: Re: MQC to filter MIME-types [bcc][faked-from]
>>>>Importance: Low
>>>>
>>>>Just a couple of things.
>>>>
>>>>It is pretty unclear as to whether the nbar protocol discovery command
>>>>is actually needed. I do not think that it is needed. But since you
>>>>have it configured, can you do a sh ip nbar discovery (or something
>>>>like that, exact syntax escapes me), and see if it actually seeing any
>>>>nbar traffic at all? If not, then there is nothing to match.:)
>>>>
>>>>
>>>
>>>--
>>>There is more to life than increasing its speed. - Mahatma Ghandi
>>>
>>>
>>>Joseph Rothstein
>>>Ridlerstr. 32
>>>80339 Munich
>>>Germany
>>>
>>>ziutek@mac.com
>>>http://www.geocities.com/jozek444
>>>http://www.rothstein.no-ip.org/
>>>http://waywardgenuses.blogspot.com/
>>>http://ziutek.journalspace.com/
>>>
>>>______________________________________________________________________
>>>_ Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>>______________________________________________________________________
>>>_ Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>
>>
>>--
>>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3