From: none (alsontra@hotmail.com)
Date: Sun Sep 19 2004 - 14:50:48 GMT-3
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