From: Scott Morris (swm@emanon.com)
Date: Sun Sep 19 2004 - 09:47:14 GMT-3
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 GhandiJoseph 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/
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3