Technical Brief: Controlling P2P in the Enterprise

Controlling P2P in the Enterprise

Why control P2P traffic?
Whether you know it or not, P2P traffic is consuming valuable bandwidth on your network and can have an adverse impact on legitimate mission-critical applications. Additionally, P2P traffic opens the door for viruses and a host of legal concerns that can be counterproductive to any business. P2P may be contributing to some of the following issues in your company: Decreased bandwidth for mission critical applications Law suits stemming from music and motion picture copyright infringement Introduction of adware, spyware, viruses and worms to the enterprise Decreased user productivity when searching for files and listening/viewing Possible customer service delays due to network congestion Possible loss of revenue through poor response times

P2P file sharing services allow an employee to circumvent corporate security measures. The very nature of the P2P client design is to evade firewalls and general network security. Additionally, blocking P2P at the firewall has proved to be extremely difficult because port blocking, as a means to controlling P2P, is very limited. P2P port usage can be dynamic and P2P protocols are not standards-based, making them very difficult for administrators to detect much less control. P2P packets cannot be classified simply by looking at packet headers such as IP address and port number. Deeper packet inspection is required for effective P2P control. Controlling the use of P2P in the enterprise requires a solution that is as dynamic as the problem itself. This means that an administrator must be able to evaluate the P2P problem from their own network perspective and apply controls that relate to their companys policy needs. Blue Coat provides the architecture for immediate and dynamic P2P control. The ProxySG allows an administrator to log and control P2P traffic to the degree required at that company. Additionally, as P2P clients change, the ProxySG policy can be adjusted to capture new clients, blocking P2P communications to and from the Internet.

Controlling P2P Traffic with the ProxySG

This TechBrief outlines a strategy for controlling P2P communications through multiple configuration options. A sample policy is included at the end of this note that can be installed on your ProxySG to gain immediate control over P2P traffic. The policy can be expanded or modified at any time to meet the changing needs of your Web control policy. Numerous P2P clients are available for free download. However, some P2P vendors require the addition of Spyware on the client in lieu of a download charge. KaZaa, for example, provides a free option that includes Spyware with the users permission. The KaZaa (sans advertising) version sells for $29.95. For this TechBrief, Blue Coat has tested numerous free clients on the ProxySG to evaluate P2P characteristics. This is by no means an exhaustive list of P2P clients, but does help demonstrate that the Blue Coat solution for controlling P2P is extremely flexible and useful under many different conditions:

Technical Brief: Controlling P2P in the Enterprise

GNUCLEUS SWAPPER.NET PHEX SKYPE

KAZAA MORPHEUS SHAREAZA iMESH

Options for Controlling P2P

Blue Coat has identified the following options for controlling P2P in your enterprise with the ProxySG. Any or all of these options can be applied to the ProxySG to provide varying degrees of P2P control. 1 Block connections to any supernode 2 Create a request header deny list 3 Create a P2P category deny list 4 Create a numeric-host allow list

Option 1: Block connections to any supernode

P2P applications typically rely on communications with a central server or a group of nodes that provide information about the location of files. The concept of a supernode is a computer that stores a list of shared files and acts as a mediator between groups of peer computers. A KaZaaLite user, for example, will first attempt to connect to a supernode to find information about other nodes that contain copies of the requested (MP3) file. Out testing indicated that KaZaa will attempt to maintain only one supernode connection. Other P2P protocols such as iMesh attempt to maintain multiple supernode connections for faster file identification. The bottom line with most P2P protocols is that they must first initiate a connection with an outside supernode. This initial connection is vital because it establishes communication and allows file transfer to occur between two nodes. If the initial connection is blocked, P2P file transfer will not occur. The first step in blocking P2P user communications to is to route as much traffic as possible from the firewall through the ProxySG.

Internet User Requests CORPORATE LAN ProxySG

1 Block all ports at the firewall except the ProxySG and other known resources as required by your organization 2 With P2P traffic flowing through the ProxySG you can identify and log the protocols to gain a better understanding of the types of protocols traversing your enterprise 3 Once identified, P2P traffic can be controlled or blocked

Technical Brief: Controlling P2P in the Enterprise

The ProxySG will automatically block file transfers that occur when using a malformed HTTP packet. When testing KaZaa and KaZaaLite, the ProxySG blocked file transfers because the KaZaa file transfer protocol uses a malformed HTTP packet.

Option 2: Create a request header deny list

The next step to controlling P2P is to create a request header deny list. Request header information is sent via a user agent when an existing P2P client on your network makes a request for a particular central server. The following steps will enable the ProxySG to deny outgoing request when these P2P user-agents are recognized: 1 Create a Web Access Layer using the Visual Policy Manager 2 From the Source tab, select Combined Source Object 3 Select user-agent from dropdown for header name 4 Fill in a value for header regex (i.e. KaZaa, Gator, MLDonkey, Topsearch) 5 Repeat process until all desired agents have been added. This list can be modified or extended at any time.

Adding request header source objects by name

Option 3: Create a P2P category deny list

This step will enable the ProxySG to maintain a list of P2P web sites and block them when a user attempts to access them. This step is intended to block users from attempting to download P2P clients from within your enterprise network. A new category (named P2P in our example) is created using the VPM. The category will contain a list of known P2P sites that will be denied access. This list can be modified or extended at any time as your needs change.

Technical Brief: Controlling P2P in the Enterprise

Select the Edit Categories option from the Configuration Tab, then highlight Policy and click Add to define the new P2P category. Once the P2P category is defined you can URLs to the list as needed. Some of the more common sites are listed below such as KaZaa.com, Gator.com, altnet.com, morpheus.com, fastclick.com, and advertising.com.

Add names to the P2P blocked list when necessary. An administrator can add to the list at any time. Once the names have been entered apply to changes and install the policy to implement. As shown in the following policy example, requests from current P2P clients will be denied and requests to destination P2P sites will be denied as well. This is a start to controlling P2P in your enterprise environment. Recognize that this type of approach to P2P control is implemented by creating an exclusion list. The list includes all sites for which you want to deny access.

Technical Brief: Controlling P2P in the Enterprise

Once the policy is installed, the background policy commands are generated. An example of the generated policy is shown here:
define category "p2p" gator.com altnet.com morpheus.com fastclick.com advertising.com end category "p2p" ; Description: define condition "CondList1p2p&adUserAgents" request.header.User-Agent="Gator" request.header.User-Agent="MLdonkey" request.header.User-Agent="TopSearch" end condition "CondList1p2p&adUserAgents" define condition "p2p&adUserAgents" condition="CondList1p2p&adUserAgents" end condition "p2p&adUserAgents" define condition p2p category="p2p" end condition p2p ; Tab: [p2p_control] <Proxy> condition="p2p&adUserAgents" Deny ; Rule 1 condition=p2p Deny ; Rule 2

Option 4: Create a numeric-host allow list

Keep in mind that the previous options discussed here address the dynamic nature of P2P clients. In other words, user agent names and Web site names are always changing. Therefore, your list of user agents and P2P sites will always be changing and growing as you discover that some (persistent) users will find a way to download a P2P client through some other means which isnt yet blocked by your policy. Once discovered, you can add to your list of blocked agents and blocked sites. A more aggressive approach, however, is to look at P2P blocking from a different angle. First, an important detour is necessary to understand how P2P files are transferred. Detour: P2P communications for file transfers use an actual numeric host address of the P2P node rather than a server name. The simple nature of P2P allows users to communicate with other users without the (total) aid of a file server. Therefore, P2P communications employ a numeric host address and a format of:
HTTP://<IP ADDRESS>:<PORT>/P2P vendor name/etc.

Technical Brief: Controlling P2P in the Enterprise

The port address may change and the P2P vendor name may change with different client versions, but the constant in P2P file transfers is the use of a numeric host address. Therefore, Blue Coats powerful policy engine can be used to configure a policy to identify the use of numeric host addresses and deny access, effectively blocking P2P file transfers. Using the ProxySG you can create a policy to block the use of numeric URL hosts while enabling an inclusion list where certain numeric hosts are included. For example, you may have a group of internal test devices that must be allowed to pass through the ProxySG. Everything other numeric host is denied access. This option requires some additional planning to make sure that the inclusion list includes all relevant numeric hosts for your enterprise. Clamping down access may inadvertently restrict valid hosts from going across your network. Therefore, Blue Coat recommends that careful logging of current traffic be performed to ensure that all legitimate and necessary hosts are part of the inclusion list. Once that determination is made, the ProxySG provides powerful capabilities to block all unknown traffic types. Follow these steps to get started: 1 Create a dedicated log file to store traffic information 2 Create a short list of allowable user agents to exclude from logging 3 Create a Web access rule to trigger collection of unknown traffic 4 Review log file, modify inclusion list and apply policy to block undesired URLs Using the Blue Coat management interface, select Logs and New to create a new log (named P2P_logging here). Use Main as the log format and click OK.

Next, create a short list of allowable agents on your network. These are agents that you already know about and want to permit access through the ProxySG. By creating this list you will log only unknown traffic, keeping the log shorter and easier to sift through later on.

Technical Brief: Controlling P2P in the Enterprise

In the Web access layer, right click and select Set. From the Set Source Objects page, select New. You will be presented with the following screen where you can select known agent types by clicking on each one.

Now, right click on the Source and click Negate. The Negate command will not include these agents in the logging option. The negate option is highlighted here with a red dash when set by the administrator.

Technical Brief: Controlling P2P in the Enterprise

The last step in the log setup process is to set the action to enable logging. The policy is defined to negate (not include) any agent found in the acceptable list. Otherwise, log the traffic to the log file defined as P2P_Logging. After enabling the ProxySG with the logging policy, let the device run for up to a week, depending on the size of your enterprise. Large organizations will want to gather as much data as possible to see which P2P agents and other traffic is traversing the enterprise. Review the log file carefully to identify unknown numeric URL hosts and other unknown traffic. Be sure to research unknown hosts with your network staff to determine whether or not they should be blocked. As mentioned previously, you may have a block of devices using IP addresses internally that cannot be blocked. Now, you are ready to create your Good Categories numeric host list. This is a list of every category or individual URL that you will allow users to access. Follow the steps found in Option 3 to create a Good Categories list by creating a new URL filtering category. The last step is to define the policy to block the communication of all numeric hosts not included in the Good Categories list. Because this policy definition is not yet available in the Visual Policy Manager (VPM), it will be necessary to paste the Content Policy Language (CPL) code into the policy editor and then apply the policy. Using the Blue Coat management interface select Policy, Policy Files. From the drop down menu, select Text Editor as shown below.

Paste the following CPL into the editor and save your changes. The following code will block communications to any numeric URL host not found in the Good Categories list.
url.host.is.numeric=yes condition=!good_categories DENY

Technical Brief: Controlling P2P in the Enterprise

Sample P2P Blocking Policy

The following sample P2P blocking policy can be downloaded and installed for immediate use or testing on your ProxySG appliance. This P2P policy can be modified or expanded to meet your particular needs. 1 Download and save the pre-defined Blue Coat Policy 2 Modify the policy to meet your requirements 3 Open the Blue Coat management console to the archive page 4 Install the policy and review results

Step 1
Copy the following pre-defined Blue Coat policy on to your local PC. The policy can be obtained by going to the following link: http://techlabs.bluecoat.com/policy/config_p2p.zip (You will need to unzip file after downloading)

Step 2
You may need to modify some parameters in the copied policy to customize the desired effect for your environment. For example, you may want to modify the warning screen to use your own message.

Step 3
To load the policy to your ProxySG, open the web management interface. Go into Configuration | General | Archive

Then click on the button Install from Installation Configuration from Local File. You will see the following screen.

Technical Brief: Controlling P2P in the Enterprise

Then select the policy file that you previously saved to your PC. WARNING: Using the archive configuration will eliminate any existing local policy stored on the ProxySG.

Step 4
Click on Install at the bottom of the above screen to save and install the policy. Check for any installation errors and correct. Once the policy is installed, you are ready to review the results by attempting to download a P2P client or download music using a currently installed P2P client.

Technical Brief: Controlling P2P in the Enterprise

Conclusion
P2P protocols and communications are ever changing. However, the Blue Coat ProxySG provides numerous means for controlling P2P in the enterprise. The solutions identified here will deter the majority of users on your enterprise from using P2P. These solutions are: Block connections to any supernode Create a request header deny list Create a P2P category deny list Create a numeric-host allow list

Bandwidth gain should be a noticeable benefit through the implementation of the ProxySG and the P2P solution. Companies may also need to (or want to) implement a more restrictive solution based on blocking the use of unknown numeric URL hosts since P2P file transfers incorporate the use of numeric hosts. This requires the creation of an inclusion list of URLs (numeric hosts that you would like to allow such as 10.2.3.4) so that known host will be permitted and all others will be blocked. Each of the previously outlined options can also be combined to meet a particular policy need. The Blue Coat ProxySG keeps good employees from doing bad things on the Internet.

Blue Coat Systems, Inc. 1.866.30.BCOAT // 1.408.220.2200 Direct // 1.408.220.2250 Fax // www.bluecoat.com
Copyright 2008 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications are subject to change without notice. Information contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use, Blue Coat is a registered trademark of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their respective owners. v.TB-CONTROL_P2P-v2-0408