05-05-2003 07:33 AM - edited 03-09-2019 03:09 AM
Could someone tell me the best way to block Kazaa (port 1214) on the PIX.
Thanks in advance
05-09-2003 10:47 AM
access-list Kaaza deny {ip|tcp|udp} {network ip of the internal network|any} {netmask} {any or ip
address of kaaza} {netmask} eq 1214
access-list Kaaza permit ip any any
access-group Kaaza in interface inside
The above access list would only deny traffic destined for port 1214 of either any of the ip address
of the server. It will then allow all other traffic through.
Here is a link that discusses the use of access-list and access-group.
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/cmd_ref/a.htm#xtocid5
05-12-2003 09:21 AM
The above example will work but only with the old versions of the file sharing software which usually transmits via ports 1214 and 2210.
I've been doing some research and found out that the latest version of the software assigns dinamically ports which makes harder to restrict it's traffic.
I'm still trying to find an effective way to restrict kazaa's traffic.
"does anybody know how to successfully acomplish that ???"
05-12-2003 10:15 AM
I have heard second hand that it might be possible to do that with NBAR if you have a IOS router capable of it in the path between the users and the internet
05-20-2003 02:52 AM
you can do it by the rate limit command. create an access list to permit the particular port from any IP. then just bind it to a rate limit command and out it on the interface. i had implemented this and it worked well.
cheers,
Ramesh
05-12-2003 11:44 AM
Well, I went the more restrive route in that I only allow certain ports such as WWW and FTP to exit our network. I would think that would effectively shut down Kazaa use because I don't think it will assign port 80 or 21 for traffic. Besides, if it's random, what are the odds it will hit one of the few active ports I have allowed?
05-12-2003 06:06 PM
Use NBAR -jason
class-map match-all gnutella
match protocol gnutella
policy-map gnutellain
class gnutella
police 8000 2500 2500 conform-action drop exceed-action drop
policy-map gnutellaout
class gnutella
police 8000 2500 2500 conform-action drop exceed-action drop
int fa0/0
service-policy input gnutellain
service-policy output gnutellaout
05-14-2003 06:56 AM
This has been effective for us on IOS based routers. We are still searching for a PIX soulution.
ip nbar pdlm flash://kazaa2.pdlm
class-map match-any P2P
match protocol kazaa2
match protocol gnutella
match protocol fasttrack
policy-map StopP2P
class P2P
police cir 8000
conform-action drop
Interface f0/0(inside)
service-policy input StopP2P
05-20-2003 05:13 AM
I'm a little confused about why you police the traffic. Why not just drop all traffic that matches the class-map?
Thanks in advance.
Cody Rowland
05-20-2003 06:32 AM
Unless I'm missing something you must define a limit(Police cir 8000) before an action (conform-action drop) can be taken. The logic behind it is to give the P2P traffic 8K and if it tries to use any of the 8K then drop it. It will never exceed 8K.
05-16-2003 04:51 AM
I have a quick question....Is the list of protocols/applications that NBAR recognizes updated with later versions of the IOS?
Thanks in advance.
05-19-2003 09:15 AM
I haven't found a way to do it on the PIX. The new versions of Kazaa have an option to use port 80 as an alternate. So I'm guessing this means that Kazaa can use the HTTP port for its traffic as well as the ports it dynamically assigns. I guess if you dont have NBAR, you would need to go with a filtering software like Websense to make sure you caught the traffic.
Back before Kazaa started dynamically assigning it's port numbers, I saw an implementation of rate limiting in a router that didnt block Kazaa ports, but limited the traffic on those ports to 1kb/sec. The effect being that the users could use Kazaa, but it only took them a year to download an MP3. =)
05-22-2003 04:26 AM
After reading this thread I did some testing and discovered a couple of things that I wanted to share. I initially configured it the way you suggested here:
class-map match-any P2P
match protocol kazaa2
match protocol gnutella
match protocol fasttrack
policy-map StopP2P
class P2P
police cir 8000
conform-action drop
Interface f0/0(inside)
service-policy input StopP2P
After doing this I launched Kazaa and a couple of things happened. First, it did block access to the main Kazaa site that appears when you first launch the app (this doesn't effect ability to use app because it tunnels over 80). When searching for content to download the searches were significantly delayed and the number of results seemed to be reduced by half. Unfortunately, once I started downloading content there didn't appear to be any limitations. I was able to download full throttle. While fiddling around with the class-map I noticed that there's an extension to the P2P protocol rules. This is what I tried next:
class-map match-any filesharing
match protocol kazaa2 file-transfer "*"
match protocol fasttrack file-transfer "*"
match protocol gnutella file-transfer "*"
policy-map deny_p2p
class filesharing
drop
I then applied this to the input of the inside interface as you suggested. This seemed to have the effect that I was looking for. I was able to search without any limitations but when I try to download content the download starts but then is instantly blocked and I can't download more than about 10k. This is VERY nice because from a users perspective it's extremely frustrating!
Just wanted to share my findings. Thanks for the suggestions.
Cody Rowland
Infrastructure Engineer
05-27-2003 11:39 AM
What IOS did you perform this on? I can't find those protocols in my current release.
05-28-2003 05:56 AM
When I first started looking into this I didn't have the protocols available either. I had to upgrade the IOS to version 12.2(13)T4.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: