First, a background on Peer to Peer (p2p) programs. Simply put, P2P networks are built up by many clients running software tailored to make it easy to locate files on any of the connected hosts. These clients then send commands to each other to request a copy of a shared file. As long as the clients remain connected to the network, they will share files back and forth - and it can all be unattended.
Because of media saturation, it's hard to find anybody that is not familiar with the name Napster. Napster was the first of many P2P programs to become a 'household name'. All Napster was before it got shut down, was a clearing house of client hosts with a list of files that host was willing to share with the internet community. Because Napster worked on a central clearing house, it was easy to block. However, the second generation of P2P programs are much more clever. Systems like Kazaa and Gnutella utilize a true peer network where no single machine is the clearing house. Also, the programmers made it harder to block the programs by allowing them to masquerade as common services, or choose any available open TCP port in which to communicate.
Putting aside any arguments regarding copyrights and royalties, why are P2P programs such a problem? First, for many organizations, it's a matter of controlling bandwidth growth. These programs can operate unattended, and can result in massive amounts of data being downloaded and uploaded over time. I have seen T1 lines pegged at full capacity for hours on end by a single user running one of these programs.
Second, they can pose a security risk. For starters, just because you may have a firewall, the files you are "sharing" aren't directly accessible, but as long as you published that list, a remote client can make requests to download a file. While the direct route through the firewall may be blocked, a request can be made via the connection from the internal client to a remote host. The internal client then sees that the remote host wants a file from it, and then sends it outbound.
Third, because most P2P programs don't care what kind of files they share (Napster was specific to audio and video media files), users may end up sharing a vast majority of potentially sensitive or confidential files. Any of those files may end up being downloaded by corporate spies, government spies, or worse, somebody looking to extort money from an organization simply because it's possible.
Fourth and last, P2P systems can become conduits for distribution of malware. Kazaa has been known to have distributed several recent worms, and also contain "spy-ware". All of this can go on without the user knowing what is happening.
With the techniques listed below, we have effectively limited our users from being able to usurp more bandwidth than we are willing to provide. I estimate that if these measures had not been implemented (this was all done incrementally over time, not all at once), that our current bandwidth utilization would probably be double that of today.
Now for the specifics
Host/Port based access lists can offer a basic level of filtering. For Kazaa, you would block requests from your internal clients to any host on the internet via port 1214. For Gnutella, you would block ports 5634, 6346, 6347, 6348, 6349, and 6355. However, the problem with simple port based lists, is that the P2P programs are sneaky. If the default port is not accessible, they can masquerade as any other service in the available pool. Hence, you may see an enormous volume of HTTP traffic flowing in and out of your network. A simple host/port based list is included below if you can not support NBAR in your configuration. It works - minimally - against most of the P2P services.
Cisco has provided a possible solution with their NBAR (Network Based Application Recognition) feature that's available in certain IOS versions (mostly the 12.2T train). Before you jump head first into this, NBAR is a CPU intensive process, and can bring even big routers to their knees in a hurry. First, determine if you have a high enough power to bandwidth ratio. We have a fractional OC3 (25mb burstable) where I work. Our 7500 series routers with RSP-4 processors could barely keep up at full capacity. We've since upgraded to RSP-8 processors and can breath easily. If all you have is a T1, then a 7200 class router and possibly a 3640 should work fine. Also, NBAR is not available on every router platform, so do your research first.
NBAR configuration begins with the enabling of CEF. This is required. Since we are running on 7500s with VIP2 and VIP4 modules, we went to using Distributed CEF. This automatically makes NBAR distributed as well. Again, the more horsepower you have to throw at the problem, the better it all works.
Next, once you have the appropriate IOS installed on your router you're ready to commence firing on P2P!
First, build your class-map to categorize the traffic we're going to police:
!
! Class-map and Policy-map to filter out P2P traffic
! Use at your own risk!
!
class-map match-any match-p2p-protocols
match protocol gnutella
match protocol napster
match protocol fasttrack
match protocol http url "*/.hash*
match protocol http url "*/.message*"
match protocol http url "*kmdstart*"
!
If the IOS you installed doesn't seem to recognize the gnutella, napster, and/or fasttrack protocols, you have to download and install the PDLM files. PDLM files enable you to add new NBAR protocols without installing a new IOS. They are available from Cisco to CCO users. The URL matching is merely extra, just incase the fasttrack submodule doesn't catch Kazaa. More on this later on.
Next, we can build our policy map:
!
! Policy map to police the P2P traffic to 0 bytes -
! If you wish to just limit P2P traffic, choose your own comfort
! level of bandwidth and change the conform-action from
! drop to transmit
!
policy-map block-all-p2p
class match-p2p-protocols
police 1000 conform-action drop exceed-action drop violate-action drop
!
Finally, you can install the policy map to your interface.
!
! Install policy on internet router, on the inside
! and outside interfaces. This will ensure that you
! get both your users attempting to use the software
! and machines outside trying to use your clients and
! or serve your clients.
Interface <Inside_Router_Interface>
service-policy block-all-p2p in
!
Interface <Outside_Router_Interface>
service-policy block-all-p2p in
!
To verify the action, use the 'show ip policy interface <interface_name>' command.
If it's working, you'll see the packet counts in the "police:" section increase as it matches, then denies the P2P packets. NBAR does have restrictions as far as the types of interfaces it can run on. Please read the documents that Cisco has (I have a link below to Cisco). NBAR is pretty slick with what it can do, but like anything complex, you must RTFM!
Easier P2P services to block
Some of the P2P services are actually easy to block since they follow the central clearing house design. This was actually the origin of my attempts to cull and limit P2P services in order to preserve our limited bandwidth. It's reasonably effective against most of them, but Kazaa and Gnutella were pretty persistent - not only with the software developers finding ways around restrictions, but also with the users.
The following is an excerpt from our main outbound access list we install on all border routers. It includes a few things that are not truly P2P, but are somewhat related - and could usurp anybody's bandwidth in a hurry if unchecked. Again, use this at your own risk. This list is installed on the internal interface of the Internet border router as an inbound access-list. This is to restrict inside users from accessing the P2P services in the first place.
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Discard the peer to peer
file sharing stuff ****
access-list 121 remark --------------------------------------------------------
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Kazaa
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any any eq 1214
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Gnutella
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any any eq 6346
access-list 121 deny tcp any any eq 6347
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Winzip Ad server
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any any eq 17027
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Audio galaxy - spoofs as
an FTP session ****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 64.245.58.0 0.0.1.255
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Napster
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 64.124.41.0 0.0.0.255
access-list 121 deny tcp any any eq 8875
access-list 121 deny tcp any any eq 6688
access-list 121 deny tcp any any eq 6700
access-list 121 deny tcp any any eq 6699
access-list 121 deny tcp any any eq 6697
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** WinMX (changed 11/27/01)
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any any eq 7729
access-list 121 deny tcp any any eq 7733
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** IMesh
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 209.225.26.0 0.0.0.255 eq 5000
access-list 121 deny tcp any host 216.35.208.151 eq 5000
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Morpheus (musiccity.com)
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 140.99.15.128 0.0.0.15
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Neo-Modus (new)
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any any eq 411
access-list 121 deny tcp any any eq 412
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Shoutcast and Spinner
****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 205.188.234.0 0.0.0.255
access-list 121 deny tcp any 205.188.245.0 0.0.0.255
access-list 121 remark --------------------------------------------------------
access-list 121 remark **** Madster/Aimster - file
sharing program ****
access-list 121 remark --------------------------------------------------------
access-list 121 deny tcp any 65.120.116.0 0.0.1.255
Addendum
The Basics on blocking KaZaA
KaZaA has multiple means of communicating with other peer clients. By default, it uses port 1214. The client also has a mini-http server embedded into it. Any peer clients can access this http daemon and submit requests. If even that fails, the client can then utilize any port open to itself.
However, since port 80 is almost defacto open everywhere you go (even if it's through a proxy), it's easy to catch the majority of your Kazaa traffic with the simpler list. Kazaa's commands are sent via HTTP GET commands, and can be filtered as such:
The class-map used in the example above includes these HTTP URL strings as an added precaution. Every little bit helps, right? If you can not get access to the updated PDLM files, but you do have NBAR support on your software, then you can at least do this much. It won't stop everything, but you can cut it back quite a bit.
If you're really interested and have a packet sniffer, hook it up to your internet connection and set it to capture all packets, then filter at offset 36 (hex) to look for the pattern "GET /.hash". I found a lot of users running the Kazaa software once I used this search method. Even users behind proxy servers are no longer hidden since the Kazaa client so graciously puts the originating IP address into the payload of the packet - all for you to see.
Some P2P links