How To Prevent Peer-to-Peer Network Abuse

With peer-to-peer traffic accounting for more bandwidth than any other group of applications on the Internet--even surpassing Web traffic--preventing network abuse by peer-to-peer users can be difficult. But once you explore and understand peer-to-peer protocols, securing them becomes much less daunting.

Most people automatically think of file sharing when they hear the term peer-to-peer. However, in the purest sense of the term, peer-to-peer is a system-design model in which a given individual can contact any other. The peer-to-peer model has been used for a variety of applications, including IM (instant messaging), VoIP (voice over IP) and, of course, file sharing. Certain implementations of grid computing and clustering could even be considered peer-to-peer. IM and VoIP are relatively simple to block, because they typically use well-known ports and usually don't have the resources to work around firewalls.

File-sharing applications, however, come in a variety of iterations. There's built-in file sharing in Windows and Mac OS; NFS (Network File System); AFS (Andrew File System, a worldwide file system); and peer-to-peer applications, such as Gnutella and Napster. Peer-to-peer differs from the typical client-server model because a node in a peer-to-peer system can be a client and a server. The client-server roles are not separated onto different nodes.

Some peer-to-peer models, such as FastTrack, which is used by Kazaa and Grokster, use encrypted communications, while others are completely unsecured. Some protocols are entirely decentralized, while others are fully centralized. Some even use a mix of centralized and decentralized setups by employing supernodes or group leaders. Finally, as with many protocols, some are open, letting more client applications be written for them, while others are closed, limiting who can create applications to access the network. The five most popular protocols are compared in the chart below. We'll discuss FastTrack, Gnutella and BitTorrent in more depth.Making the Connection

Since some peer-to-peer systems don't have easily defined servers, how do the networks form in the first place? Most applications have a small list of predefined well-known peers, along with their installers. When the applications run for the first time, they attempt to connect to this list of peers and download a new list. By continually updating these lists, the peers should always have a working connection. Gnutella clients also can fetch these lists from Web sites, so if they are completely unable to connect at first, they can try a fresh list of possible connections. Some Web sites also house updated lists for other protocols that users can download manually, if all else fails.

Once a list has been generated, the clients attempt to connect to the network. Several protocols, including Gnutella, BitTorrent and eDonkey, use a well-known range of ports by default. Unfortunately, FastTrack does not. FastTrack uses three different connection methods to work its way around firewalls, each progressively harder to detect.

FastTrack Connections

FastTrack's supernodes are essentially normal clients that have spare resources. "Spare" bandwidth, processor power and memory are examined, and if there are enough available resources, a node is promoted to a supernode. Once a client becomes a supernode, it uses more bandwidth by accepting other client connections and relaying queries for them. When clients connect, the supernode indexes any files they are providing, essentially caching the information for slower nodes in the network.

First, a FastTrack client will attempt to connect to its list of peers by sending a flood of UDP packets out as probes (see illustration at left). Each probe packet is identical, except for the destination. The destination IP and port are specified in the peer list obtained from the default installation or from another node during a previous connection to the network. This connection phase is a snap to identify--you just need to look for the duplicate packets. When a peer responds, the client will send another UDP packet to ask for an available TCP port. The port is selected automatically by the client by probing for an open port or chosen by the user. Once the node knows where to connect, an encrypted TCP connection is initiated, and the connection is complete.

If the client doesn't receive a UDP response, it eventually switches to the second connection mode, parallel TCP connections. The client sends TCP packets with SYN flags (the standard TCP initial connect flag) to its list of peers. If peers respond, a TCP session is established to request a port for the encrypted channel. Finally, a new encrypted session begins.

If the parallel TCP connection stage fails, the client will fall back to the final connection method, single TCP connections. The client will try each node on the list, one at a time, waiting for a connection or a time-out, and then moving on. This stage can be lengthy, but typically by this point, the client has a connection.

GnutellaBecause Gnutella is fully distributed, no node takes precedence over another. In other words, there are no supernodes. Gnutella, therefore, uses more bandwidth since its searches essentially flood the network.

A peer joining the Gnutella network first attempts to connect to many peers, which increases its chances of finding results (see illustration). Typically, a Gnutella client will have about 10 connected peers. As peers join and leave, the Web of connections changes. Although Gnutella clients typically connect on TCP Port 6346, the actual transfers can be on different ports.

First, let's look at how to find a file. When a client begins a search, a query packet is generated. In this packet is a TTL (Time To Live) field. When the query is submitted, the client sends this packet to each of its connected peers, which then decrements the TTL field and forwards the packet on to their peers. This continues until the TTL field reaches zero. If a peer finds a query match, it sends a match packet back to the original peer, following the reverse path of the query packet. The match packet contains all information required to make a direct connection to the file-owning peer. When the original client requests the file, it connects and directly downloads the file, if possible.

If the client cannot contact the peer with the file, perhaps because of a firewall blocking the traffic, it sends a push request that asks the file-owning peer to push the file through the Gnutella network back to the requester. Because the clients are connected to the network, the file can be transferred, but not reliably. Peers constantly connect and disconnect. Therefore, the path between any two nodes could change or be completely lost. Many push requests for large files fail.Gnutella is, simply put, a bandwidth hog. It is a completely decentralized network, so queries must be forwarded to all nodes, which are then forwarded again, creating an exponential bandwidth drain. Even if you are not searching or downloading, you still could be transferring a large amount of data for everyone else on the network, just by having the program open. More centralized protocols avoid this for all users, but some, such as supernodes in FastTrack, still use large amounts of bandwidth.

BitTorrent

BitTorrent is unique because unlike other peer-to-peer applications, it is not a "full desktop"-style program. Most other file-sharing programs have a search functionality built in, and are entirely self-sufficient. BitTorrent only transfers files while the user must independently search for torrents (the files that describe who else has the file you want) on Web sites or over e-mail. BitTorrent lets each person download files as well as upload, so the provider of the file does not consume nearly as much bandwidth.

The torrent files provided are clearly labeled with a MIME-type of application/x-bittorrent. They contain information about the file, such as a hash value for verification, and the tracker address. The tracker is a server that monitors who is downloading the file. When a client contacts the tracker, the tracker updates its list of who wants the file, and gives the client the list. The client can then contact other nodes to request small portions of the file. By distributing uploads and downloads to many nodes, there is a torrent of traffic flowing across the world, thus the name BitTorrent.

BitTorrent is relatively simple to identify because it uses HTTP/1.01 on TCP Ports 6881 through 6889. The packets contain specific strings such as /announce (for announcing where a tracker is). Since BitTorrent is an open protocol, anyone can visit its Web site to view the full range of strings that can identify this traffic.Share and Share Alike

File-sharing traffic is much easier to identify than to block. Intrusion-detection systems, such as Snort, can identify many different protocols (see "Nose Around With Snort", for more information). Although blocking can be difficult, you can enforce corporate policies by monitoring violations. Unfortunately, as more protocols implement encryption--even simple encryption--it'll be trickier to identify the protocols. And with more protocols implementing multiple connection methods, or using completely random ports, securing your network against these applications may become next to impossible. Thankfully, as long as there are people writing applications, there are security administrators working to prevent inappropriate use of those applications.

Jeremy Baumgartner is a network security administrator for the College of Engineering at the University of Wisconsin, Madison. Write to him at [email protected].