Detecting Peer-to-Peer (P2P) Activity on Your Network

In order to dive deeper on how to detect peer to peer activity on your network, let's see the basics on peer to peer programs. There are two types of peer-to-peer programs: centralized and partially decentralized. Centralized P2P programs work with a typical client-server architecture. The server holds information about the files shared by the members of its service. A user downloads the client, chooses a username/password to identify itself to the service, connects to the service, searches for files and then downloads the ones that he selected. The best example to this services is Napster. Partially decentralized P2P programs, on the other hand, does not rely on a server. The user does not need to identify itself. He goes to a search engine, searched the file he requests and downloads a small file, which holds information about which users have the file he requests, plus connection information. Then, he opens that small file with a specialized program and the program automatically finds the users sharing the file and downloads it. The best examples to this partially decentralized network are Edonkey2K, FastTrack, Gnutella and Overnet.

There are many downsides to P2P file sharing programs, be them centralized or decentralized. The top two dangers are the spread of the infected files (these are especially found in high-priced programs offered freely for sharing, such as Photoshop, Windows and MacOS) and the immense traffic it puts on the network with their default configuration options.

We can talk about a couple of ways to identify the P2P activity on a network:

• Port-based analysis
• Protocol-based analysis
• Client-based analysis
• Behavioral analysis

Port-based analysis is a very direct and straightforward analysis, assuming that the P2P applications use the default ports to communicate with the servers or other clients. Following is a simple list of ports that some P2P applications use:

• Limewire: 6346 TCP/UDP
• Ares: 32285 TCP/UDP
• Edonkey: 4661 TCP/UDP to connect to servers, 4662 TCP to connect to other clients
• Emule: 4662 TCP, 4672 UDP

One may think that, a network administrator can block these known ports and this way disable access to P2P networks. If the solution were so clear-cut, then we would finish the article here. The situation is more complex than it seems, because the P2P programs use dynamic ports to connect to their servers or other clients, the same way as the instant messaging (IM) programs. If an administrator closes all the ports, then the P2P application will switch to port 80, which is used for HTTP traffic or port 25, used for sending e-mail, making port-based analysis very limited, and to some extent ineffective. However, personally, I have not seen any peer to peer application that defaults to these ports.

If your firewall administrator creates a default rule to restrict the users to ports 80, 8080, 25 and other well known and used ports, you can be very very safe to prevent the peer to peer use.

This approach assumes that P2P applications use a predefined application signatures and data packets to communicate with the servers and clients. The signatures are defined to the program monitoring the network or the equipment and set to alert the system administrator when it finds a match; a match between the predefined signature and the data packet. Many P2P network identification solutions such as Cisco's PDML (Packet Details Markup Language), Alteon Application Switches etc. rely on this protocol-based analysis. Although this type of analysis seems to be a step forward in P2P usage detection, it has its own shortcomings:

• The same way the IM programs evolve so the P2P programs. They change their signatures randomly, so a static signature match will not be effectively implemented unless the signatures are updated immediately as they are generated.
• P2P developers are working hard to disguise their applications with tunnelling. The most basic thing they do is to encrypt the traffic and thus make it very hard for the monitoring programs to detect the data packet contents.
• Protocol-based monitoring requires very high system resources on the server side. Each packet is stopped, inspected for signatures and sent back to the recipient. The bigger the network is, the higher the required resources.

Another method on how to detect p2p activity on your network is the client-based analysis, which, as the name suggests, depends on analyzing the changes in the client computers. When a user installs a P2P program on his computer, then various changes in his system are expected, such as changed/added registry keys, installed files, running processes etc.. In client-based analysis, a system administrator can prevent the use of the application and watch the traffic generated by it. This method can even detect anonymous P2P applications. However, there is a downside of this approach: if the user changes the name of the executable file or deletes the keys in the registry then the network administrator cannot know if a P2P program is running. There are also programs that this method proves to be ineffective, such as the ones that are not installed (therefore not changing anything in the registry) and encrypts the traffic.

Almost all P2P applications use data packets to communicate with the outside world in a pattern. The pattern is basically sending UDP packets to many UDP ports in random to many IP addresses. The logic behind this is very simple: the client has a single IP address in the network. If it is sending many UDP packets to many IP addresses periodically (note that the periods need not to be static, the time between sending the packets can be different) then the administrator has good chances to suspect a P2P activity on the network. To capture the information, the administrator will need to establish a logging system (possibly a database) and some shell scripts to process the information in the logs. Behavioral approach is also beneficial against the unknown or homebrew P2P programs that the users might have installed on their computers.

As we have seen in the above analysis methods, there is no single way to detect p2p activity on your network. System/network administrators shall set up their grounds to fight with the P2P traffic on their networks by using the tools at hand, or preferably, a combination of these tools. They can even consider supporting their grounds with commercial software that is developed to block P2P traffic.

Reference: Author's own experience.