Key Pages: [ Rope Home Page | Basics (tutorial) | Language Reference | Download ]

Blocking EDonkey 2000 With A Linux Firewall

It is possible to identify the "hello" (log in) packet of the eDonkey 2000 network protocol using a Rope match rule, allowing the protocol to be controlled using IpTables / Netfilter on a Linux firewall. This allows QoS, blocking or other policies to be applied to eDonkey 2000 traffic with ease.

This page presents the logic used, and describes how deploy it in a Linux/IpTables based firewall.

The Rope module for IpTables and the ed2k_hello.rope script are both available for download (from http://www.digitage.co.uk/rope) and use under the terms of the GPL (GNU GENERAL PUBLIC LICENSE, Version 2, June 1991).

Introduction To EDonkey 2000

[ from the article "EDonkey Network" on WikiPedia ]

The eDonkey network (also called eDonkey2000 network or ed2k) is a file sharing network used primarily to exchange music, films and software. Like most file sharing networks, it is decentralized; files are not stored on a central server but are exchanged directly between users based on the peer to peer principle.

eDonkey client programs connect to the network and to share files. eDonkey servers act as communication hubs for the clients and allow users to locate files within the network. Both eDonkey clients and servers are available for for Windows, Macintosh, and Linux and other UNIX variants. Anyone can add a server to the network. Because of constant changes to the server network, clients update their server lists regularly.

eDonkey uses a compound MD4 hash checksum to identify files which permits identification of identical files with different filenames. Another feature of eDonkey is that it shares file segments before the download completes; this speeds up file distribution throughout the network. To ease file searching, some websites list the checksums of sought-after files in the form of an ed2k link. Some of those websites also have lists of active servers for users to update.

A simple description of the eDonkey 2000 network protocol can be found in Oliver Heckmann and Alex Bock's paper The eDonkey 2000 Protocol (Version 0.8, December 2002.

EDonkey clients include the popular EMule and others.

Why Blocking E-Donkey Ports Is Not Enough

When TCP/IP was first developed, it was generally assumed that services (like ftp, telnet, http - etc) made use of well-known ports. So mail servers always ran on port 25, web servers on port 80 - and so on. This made traffic identification with firewalls very easy: if you want to block the web, all you have to do is block port 80. Packet filtering firewall software (like Linux's IpTables / Netfilter) allows rules to be built up easily, provided that you want to check these basic packet header fields; such as IP addresses and port numbers. IpTables also provides a number of interesting extensions (patches) that allow traffic to be identified and controlled in a stateful way.

Sadly for network administrators, Peer-to-peer protocols have typically moved away from the concept of fixed ports. Users are able to select the port to use at random, and the software is able to detect and use the correct port when connections are established. In order to identify protocols that do this, firewalls need to resort to inspecting the packet data in order to recognise the protocol. One simple way this can be achieved is by searching for known combinations of characters in the packets. There is a patch for IpTables that allows this to be done. The module is called "string" and it simply matches on the presence or otherwise of a specified string in the packet. This is enough for some protocols, although the method has the issue that it can easily be over-zealous and identify (and hence reject) packets that are not part of the intended protocol, simply because they include the "magic string".

The eDonkey 2000 protocol is one of these protocols, and can't be identified by looking at packet headers. Sadly, the protocol doesn't tend to include easily recognisable strings either, but makes use of a structured binary format.

Take the "HELLO" packet, for example...

Recognising EDonkey 2000's Hello Packet

This is the packet sent by the client to the server in order to initiate the connection. Here's an example of such a packet.

 00000000  45 00 00 70 e1 0d 40 00  80 06 5f b7 c0 a8 00 14  |E..p..@..._.....|
 00000010  8c 7b 6c 8b 04 65 1d e6  00 25 85 1c cc 6a 78 71  |.{l..e...%...jxq|
 00000020  50 18 22 38 6d 48 00 00  e3 43 00 00 00 01 2e 29  |P."8mH...C.....)|
 00000030  f1 55 70 0e 36 7b 64 24  8f 5a 6a ac 6f a8 a8 32  |.Up.6{d$.Zj.o..2|
 00000040  9f 00 36 12 05 00 00 00  02 01 00 01 02 00 63 6c  |..6...........cl|
 00000050  03 01 00 11 3c 00 00 00  03 01 00 0f 36 12 00 00  |....<.......6...|
 00000060  03 01 00 20 19 00 00 00  03 01 00 fb 80 b1 00 00  |... ............|

IpTables' "string" module can?t help us identify this; but "Rope" can.

In order to reliably identify this packet, we can write a Rope rule that attempts to parse it using the same logic that the eDonkey 2000 software itself does. This logic is embedded in the ed2k_hello.rope script that forms part of the Rope release from 20050611 onwards.

The script works by inspecting the data portion of the packet, which starts at the "e3" byte in the middle of the third line of the dump, above. The script logic then verifies that all the following are true...

  • The first data byte is E3
  • The next four bytes are a little-endian 32bit integer that gives the length of the remainder of the packet.
  • The sixth byte is 01 - meaning "HELLO".
  • The next 22 bytes are ignored. These contain the hash key, IP address and port number.
  • The next 4 bytes are a little-endian 32bit integer that gives the number of eDonkey tags in the remainder of the packet.

Having checked that the packet matches these assumptions, the script then continues to parse the tags. It expects that one of them will contain the name of the user, and it notes the name when it finds it.

Finally, when all tags have been parsed, the script checks that a user name has been supplied. If ALL these tests are passed, then the packet is pretty certainly an ED2K Hello packet. If any of the tests fail at any point, then the packet is not an ED2K packet. The results of the test (i.e.: "yes" or "no") are passed back to Netfilter which then accepts or drops the packet in response.

The script described can be downloaded here: ed2k_hello.rope .

Installing The Logic In Netfilter

In order to use the mechanism described here you need to...

  • Download the Rope software. Make sure you download a release dated on or after 20050611.
  • Compile and install the Linux kernel code for the Rope module ( ManualBuilding ).
  • Compile the ed2k_hello.rope script ( Compiling ) and place the compile file in /etc/rope.d/scripts/ed2k_hello.rp.
  • Add a rule to the relevant Netfilter chain. For example, I use the following...
    • iptables -A FORWARD -p tcp -i eth0 -m rope --rope-script ed2k_hello.rope -j DROP

Customising The Script

Since you have the source code of the script available to you, you can make changes to it to taste. For example, there are a couple of commented places near the end of the script that allow you to...

  • Turn on syslog logging of identified packets.
  • Allow specific users to connect while denying all others.

Take some time to get to grips with the very simple programming language to find what else is possible (see Basics for a tutorial overview).

Downloading The Software

  • Visit the Download page for the latest version of Rope (including the most recent version of the script).
  • Download the script directly here: ed2k_hello.rope . But bear in mind that the one in the main Rope release may be more up to date.

History

  • The ed2k_hello.rope script was updated in the 20051212 release to prevent benign messages being written to syslog for some types of packet that did not match.

Scroll to Top