Securing Your Network against Kazaa
Kazaa is the most popular file-sharing application in use today. Applications like it are known as peer-to-peer, or P2P, and allow users to search for and download files from each other. Kazaa apparently is used most often for sharing audio files in violation of copyright law.
Kazaa's proprietary network protocol, known as FastTrack, has been licensed to the developers of a number of similar products, including iMesh and Grokster. A stripped-down version of Kazaa called KazaaLite also is available. Plenty of other P2P applications exist, but the FastTrack family is by far the most popular, as well as the most difficult to block with packet-filtering firewalls, such as Linux's iptables.
Many network managers would like to block P2P traffic at their firewalls because of its high bandwidth usage, the security implications of uncontrolled file exchanges and potential legal action by copyright holders. This is not as easy as it might sound. A search on the Internet for information on blocking FastTrack traffic using iptables yields answers like “block port 1214”, “write a policy and discipline miscreants” or “it can't be done”. Blocking port 1214 used to work with early versions of FastTrack but doesn't with recent ones. Something more sophisticated is required. Although some “proxying” firewalls are able to block FastTrack traffic, iptables-based firewalls have issues that need resolving.
This article introduces a new open-source project called P2Pwall that develops software for preventing P2P clients on your network from making contact with peers on the outside. Its ftwall component blocks FastTrack traffic. More components will be written in due course to control other P2P protocols, and we invite you to become involved as a developer. The software has been tested with the following FastTrack clients: Kazaa 2.1.1, Kazaa 2.5, KazaaLite 2.0.2, iMesh 4.1 (build 132) and Grokster 1.7.
Modern Linux distributions include Netfilter and the iptables utilities. These components work together to allow Linux systems to be used as simple but effective firewalls; however, the FastTrack network protocol presents them with some interesting challenges:
It doesn't use fixed port numbers.
It is not limited to conversing with a small number of peers. It holds a cache of 200 peer addresses and tries to connect to all of them when it starts. The list changes regularly and is different on every machine.
The peer-finding logic is not dependent on a central directory.
Key parts of the protocol employ strong encryption.
Firewalls traditionally use one of two philosophies. The first is strict and blocks all ports except specific ones as required. The second is permissive and asymmetric and allows almost unlimited outbound connections while blocking almost all inbound ones. With both of these approaches, the port-agile FastTrack seeks out and exploits legitimately open ports. It can even exploit port 80. The strict paradigm plus a port-80 proxy is required to block FastTrack, but this approach is too restrictive for networks that want to retain a permissive paradigm while blocking P2P traffic.
The P2Pwall Project aims to address these issues by providing a number of tools and documents that enable the filtering of P2P traffic. The FastTrack filter ftwall is the first such tool and is available for download under the GPL from p2pwall.sourceforge.net. ftwall interacts with iptables using the QUEUE target. It analyses the packets being forwarded through the firewall and decides whether they should be forwarded or discarded, based on an understanding of the characteristics of the FastTrack protocol. It tries to prevent any FastTrack traffic from leaving, and hence entering, the network.
ftwall's role is to block outbound FastTrack connections only on the assumption that inbound connections are already blocked by iptables rules. Many firewalls already use blanket blocks on inbound connections with a limited number of server connections enabled. However, if a FastTrack client on the inside connects to a peer on the outside, the outsider can call back in to the insider over the established connection. So, if we can rely on the firewall to block inbound connections and on ftwall to block outbound ones, we have a solution; however, we need to have both bits in place.
Installing and configuring ftwall is a matter of downloading the sources, compiling them and writing a few iptables rules. A possible complication is that one optional enhancement to the logic requires the ip_string module to be present in the kernel. The module currently is considered experimental and therefore is not included in many Linux distributions. You probably will have to add it yourself if you want to use it. See the P2Pwall Web site for more information.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development