Detection of Encrypted Traffic in eDonkey Network ... - Semantic Scholar

2009 First International Conference on Advances in P2P Systems

Detection of Encrypted Traffic in eDonkey Network Through Application Signatures Mário M. Freire, David A. Carvalho, and Manuela Pereira IT-Networks and Multimedia Group, Department of Computer Science, University of Beira Interior Rua Marquês d’Ávila e Bolama, 6201-001 Covilhã, Portugal {mario, david, mpereira}@di.ubi.pt to be infeasible, since the processing speed may not match the line speed and capturing every packet may pose severe requirements in terms of processing or caching capacity. As detection and classification mechanisms evolve, P2P evasive techniques also evolve making traffic detection and classification a very difficult task. Recently, several approaches have been proposed to detect P2P applications. These techniques may be classified into two main categories [8][11]: (i) based on payload inspection or signature-based detection, and (ii) based on flow traffic behaviour or classification in the dark. Deep packet inspection methods inspect the packet payload to locate specific string series, which are called signatures that identify a given characteristic, a given protocol or a given application, where as methods based on traffic behaviour attempt to detect and classify possible protocols or applications without looking into the payload contents. Some approaches have been proposed for traffic identification using behaviour-based methods. The method based on transport-level connection patterns relies on two heuristics for P2P traffic classification: 1) it involves the simultaneous use of TCP and UDP by a pair of communicating peers and 2) regarding the connection patterns for (IP, port) pairs, the number of distinct ports communicating with a P2P application on a given peer will likely match the number of distinct IP addresses communicating with it [8]. The behavioural method based on entropy reported in [11] requires the evaluation of the entropy of the packet sizes in a given time window and works on-the-fly. Several approaches requiring the analysis of some fields of the header of TCP or IP packets for flowbased P2P traffic detection have been proposed based on machine learning [10][12], support vector machines [13][14], and neural networks [15]. This kind of methods may be used for high-speed and real-time communications with encrypted traffic or unknown P2P protocols. The main drawback is the possible lack of accuracy in the identification of P2P traffic. Methods based on the payload inspection may be accurate, but may lead to network performance degradation under low latency or high-speed operations. Besides, they may not be useful when payload is encrypted or for new P2P protocols or in the cases where legal or privacy issues do not allow their use [8][9]. Nowadays, the main challenge regarding P2P file-sharing traffic detection is concerned with on-line detection of encrypted traffic under high-speed and real-time communications, where fast P2P traffic identification is required in order to avoid network performance degradation. To address this issue, we are developing an hybrid method for on-line P2P traffic

Abstract—Peer-to-peer file sharing applications became very popular, being responsible for a large percentage of the network traffic. However, peer-to-peer traffic may compromise the performance of enterprise critical networked applications or network-based tasks or may overload the network infrastructure of Internet Service Providers, being desirable that this traffic be blocked in some situations. However, this task may be difficult to achieve, namely for networks operating at very high-speed bit rates and low latency and/or when the traffic is encrypted. This paper addresses the problem of detecting and blocking encrypted traffic generated by eMule, which is one of the most difficult to detect among popular peer-to-peer file sharing applications. The proposed method is based on eMule signatures, which are coded as SNORT rules, this system being used to detect and block eMule traffic. Experiments have been carried out to evaluate the proposed method. The contribution of the paper falls within peer-to-peer security or within legal and regulatory issues. Keywords - peer-to-peer file sharing applications; eDonkey Network; traffic identification and classification; deep packet inspection; peer-to-peer security; legal and regulatory issues.

I. INTRODUCTION Recently, P2P file-sharing systems have received a great amount of interest as a promising scalable, reliable and costeffective solution for multimedia content sharing and distribution [1]. P2P file sharing applications, such as BitTorrent [2], Vuze [3], eMule [4], Limewire [5] and GTKGnutella [6], among others, have achieved a tremendous success in the past few years, being responsible for a large volume of global Internet traffic, which is estimated to be around 60-70% [7][8]. Without suitable network management, the traffic generated by this kind of applications may compromise the performance of critical networked applications or network-based tasks in institutions, or may overload the network of Internet Service Providers (ISPs). The traffic generated by first generation P2P applications was relatively easy to detect due to the fact that these applications used well-defined port numbers. However, nowadays, the traffic generated by P2P applications may be very difficult to detect because P2P applications may change the default service port or use port 80 assigned for HTTP traffic [9][10]. Besides, they may use obfuscation options, where the traffic is encrypted, making therefore very difficult its detection. On the other side, link speeds are reaching 1-10 Gbps in local area networks, which may make the detection

978-0-7695-3831-0/09 $26.00 © 2009 IEEE DOI 10.1109/AP2PS.2009.35

174

identification, including encrypted traffic, based on a combination of the flow behaviour method using the evaluation of the entropy of the packet sizes in a given time window reported in [11], and deep packet inspection, to complement the first approach, in order to reduce false positives and false negatives. This paper is devoted to the development of signatures for the detection of encrypted traffic generated by eMule applications. The remainder of this paper is organised as follows. Section II is devoted to the method used for the detection of encrypted P2P traffic generated by eMule. Section III discusses relevant eMule characteristics for this work. Section IV describes lab experiments regarding the detection of eMule traffic when obfuscation is not used, whereas Section V is devoted to the detection of encrypted traffic generated by eMule using obfuscation. Main conclusions are presented in Section VI.

message if the protocol is UDP; make iptables drop the packet but do not log it), protocols (TCP, UDP, ICMP, IP), IP addresses, port numbers, the direction operator (source to destination, bi-directional), and activate/dynamic rules. Rule Options are the heart of the Snort intrusion detection engine. They can be divided into the following categories [16]: General (this kind of options provides information about the rule but do not have any effect during detection (examples: msg, rev, sid respectively for output message, rule revision id, rule internal id)), Payload (this kind of options looks for data inside the packet payload and can be interrelated), Non-payload (this kind of options looks for non-payload data), and Post-detection (these options are rule specific triggers that happen after a rule has fired.) The sid field is used to uniquely identify Snort rules. This information allows output plugins to easily identify rules, and should be used with the rev keyword to specify its version (revision). According to Snort specifications, it should be larger than 1,000,000 for user defined rules, and in the range 100-1,000,000 for rules included with the Snort distribution.

II. METHOD AND APPARATUS FOR DETECTION OF EDONKEY TRAFFIC The method used for the detection of P2P file sharing traffic makes use of an open source and widely used intrusion detection system, called Snort [16], which runs over Windows, Linux/Unix and MAC operating systems. Snort-2.8.3.1-1.i386 was built from the source code available for download at [16], after extracting it as a regular TarBall. As shown in Figure 1, the Snort architecture consists of the following components: Packet Decoder, Preprocessors, Detection Engine, Logging and Alerting System, and Output Modules. In its most basic form, Snort is a packet sniffer. However, it is also designed to analyse and process packets through the preprocessor, and to check those packets against a series of rules using the detection engine. If there is a rule that applies to a given packet, then an output will be generated through the configured output modules. Preprocessors check to see if a packet should be analysed. The detection engine is responsible for analysing every packet based on the Snort rules that are loaded at runtime. The detection engine separates the Snort rules into what is referred to as a chain header and chain options. The common attributes such as source/destination IP address and ports identify the chain header. The chain options are defined by details such as the TCP flags, ICMP code types, specific type of content, payload size, etc. The detection engine recursively analyses each and every packet based on the rules defined in the Snort rules file. Any rule that matches the decoded packet triggers the action specified in the rule definition. A packet that does not match any Snort rule set is simply ignored by the snort engine and follows its route towards the end system (user). Snort rules are formed by the Rule Header and Rule Options [16]. The Rule Header contains information about: rule actions, which define the actions that will be carried out as a consequence of a given rule (such as generate an alert; log the packet; ignore the packet; alert and then turn on another dynamic rule; remain idle until activated by an activate rule; make iptables drop a packet and log the packet; make iptables drop a packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable

Figure 1. Schematic representation of SNORT architecture.

The signatures of payloads of packets generated by eMule to be identified are expressed in terms of Snort rules. The method for specification of Snort rules for detection of packets generated by eMule requires the execution of the following steps: i) identification of signatures associated with eMule that can be revealed through the analysis of the payload of a corresponding IP packet; ii) writing Snort rules incorporating these signatures in order to detect all packets with that particular signatures. The identification of signatures associated with eMule packets was made manually through the observation of repetitive patterns in the sequence of packets generated by eMule application, even with obfuscation (encryption of the payload). Those common patterns (specific string series) observed in the payload were then used to manually write the rules for the detection engine, which allow the identification of a given packet that contains that particular pattern in a particular position or after a given offset in its payload. The system running Snort should be placed in a node with aggregation traffic at the input/output of a given local area network or in a node with client aggregation traffic within the network infrastructure of an ISP, at the access level.

175

became unavailable in September 2005, after receiving a cease and desist order by the Recording Industry Association of America (RIAA). Currently, the website [20] shows only the following message: “The eDonkey2000 Network is no longer available [...] Your IP address is xxx.xxx.xxx.xxx and has been logged. Respect the music, download legally”. Nevertheless, the eDonkey network is still up by using other clients such as eMule, aMule, Shareaza or MLDonkey, just to cite a few, being perhaps eMule the most well known client for the eDonkey network. Recent versions also support the structured P2P network Kademlia, enabling eMule to reduce its server dependency and by this way avoid a complete network shutdown. Disabling it can reduce traceability, but also resource availability. The most important feature of eMule for this work is its protocol obfuscation option. This characteristic makes the task of detecting eMule traffic much harder, but not completely impossible, according to [21]. By default, each eMule client (versions higher or equal to 0.47b) supports obfuscated connections to other clients, but does not actively request them [4]. eMule version 0.49b was used along this work. In eMule, one can use the first or both of the following settings:

TABLE I. CHARACTERISTICS OF HARDWARE AND SOFTWARE USED IN THE TESTBED FOR EM ULE TRAFFIC DETECTION . Type

Operating System

CPU

Workstation

Fedora 9

Core 2 Duo 2.66 GHz

RAM

Software

1 GB Snort, Wireshark, BASE, Barnyard, Gtk-Gnutella Workstation Windows XP SP3 Pentium III 512 MB eMule, Limewire 800 MHz Laptop Windows Vista Core 2 Duo 3 GB Wireshark, eMule SP1 / Fedora 10 2.4 GHz Laptop MAC OS X (10.5) Power PC G4 769 MB Livestation, TVUPlayer 1GHz

Using the proposed method for obtaining the Snort rules for identification of encrypted eMule traffic and to perform its validation, an experimental setup was built in our research lab. A description of this experimental setup follows. The experimental testbed includes several machines with different characteristics and running different operating systems at our research lab (NMCG Lab). All outgoing and incoming traffic for servers, workstations and laptops used at this lab are controlled by a computer running Smoothwall Express 3.0, which is a network administration specific Linux distribution [17], providing Internet security and Web filtering products. This Lab has 24 8P8C sockets connecting to an Enterasys C2H128-48 switch. The switch then connects to the building switch of the Department of Computer Science, an Enterasys E7, via an optical fibre uplink, which in turn, connects to the rest of University. All external communication with the University is made using an Enterasys SSR main router, located at the Informatics Center of the University. To run P2P software, usually the most important feature is the size of the hard disk. When dealing with P2P file sharing programs, transferred files can easily reach a few gigabytes, since they are mostly movies, videos, music albums, games, etc. Real time network monitoring requires a lot more of memory and CPU. Therefore there were used more recent machines for the most critical applications, such as Snort [16], the analysis engine BASE [18] or even the packet analyser Wireshark [19]. For running P2P application, pretty old machines were used, since they were mainly used for this purpose. Main characteristics of the hardware and the software used for the experiments are shown in Table I. In all lab experiences reported here, Snort was forced to analyse other network traffic than P2P, like HTTP, Windows Remote Desktop Connection (RDC), SSH, etc. In fact, this was quite worthy, since it enabled the testbed to run in similar circumstances of those of deployed P2P classifiers, which also have to deal with network traffic generated by a vast number of applications and then to correctly identify P2P among it.

• “Enable protocol obfuscation” • “Allow obfuscated connections only (not recommended)” The first option allows eMule to use obfuscated connections whenever possible and will ask other clients to do the same when responding. When connecting to the eDonkey network, through a server, non obfuscated connections will only be used if an attempt to establish an obfuscated one fails. Enabling the second option will force eMule to only establish and accept obfuscated connections. Any other eDonkey client that does not use or support obfuscation will be ignored and only obfuscated connections will be allowed through automatic server connect. If most of the peers that share an intended resource are using it and one uses it too, faster downloads will be achieved since many connections can be established. But if one uses this setting and most of the peers do not uses it, non obfuscated connections will be ignored causing less available peers and consequently slower downloads. Nowadays, most eMule users opt to only use obfuscated connections. IV. EXPERIMENTS WHEN OBFUSCATION IS NOT USED Using “The eMule Protocol Specification”, available at [22], it was possible do adapt the well known eDonkey and extended eDonkey (eMule, aMule) message patterns defined on that document into Snort rules. As for the Kademlia protocol used by eMule, the source code of IPP2P [23] was used for the same purpose. There is also a variation of the latter protocol called Kadmelia AdunanzA (Kadu). It is part of the eMule AdunanzA P2P client, developed by italian programmers, to overcome some limitations with their internet connection provided by a major Italian ISP, Fastweb. To create Snort rules that allow identifying this protocol the Tstat source code was used as a reference.

III. E MULE CHARACTERISTICS eDonkey is a Hub Based Hybrid Decentralized P2P network. It was created by the MetaMachine Corporation in 2000 and became popular mainly in Europe. eDonkey2000 was the original client software for this P2P network, but it

176

Snort Distribution Rule for eDonkey. alert tcp $HOME_NET any -> $EXTERNAL_NET 4242 (msg:"P2P eDonkey transfer"; flow:to_server,established; content:"|E3|"; depth:1; metadata:policy security-ips drop; reference:url,www.kom.e-technik.tudarmstadt.de/publications/abstracts/HB02-1.html; classtype:policy-violation; sid:2586; rev:3;)

Snort Rule 1000001. Rule for detection of traffic generated through eDonkey. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"LocalRule:P2P eDonkey outbound - Login Request"; flow:to_server,established; content:"|E3|"; depth:1; content:"|01|"; distance:4; depth:1; classtype:policy-violation; sid:1000001; rev:1;)

Snort Rule 1000065. Rule for detection of traffic generated through eDonkey. alert tcp any any -> any any (msg:"LocalRule:P2P eMule - Client to Client - Sources Request"; content:"|C5|"; depth:1; content:"|81|"; distance:4; depth:1; classtype:policy-violation; sid:1000065; rev:1;)

Snort Rule 1000067. Rule for detection of traffic generated through eDonkey. alert tcp any any -> any any (msg:"LocalRule:P2P eMule - Client to Client - Secure identification"; content:"|C5|"; depth:1; content:"|87|"; distance:4; depth:1; classtype:policy-violation; sid:1000067; rev:1;)

Snort Rule 1000068. Rule for detection of traffic generated through eDonkey. alert tcp any any -> any any (msg:"LocalRule:P2P eMule - Client to Client - Public Key"; content:"|C5|"; depth:1; content:"|85|"; distance:4; depth:1; classtype:policy-violation; sid:1000068; rev:1;)

Snort Rule 1000069. Rule for detection of traffic generated through eDonkey. alert tcp any any -> any any (msg:"LocalRule:P2P eMule - Client to Client - Signature"; content:"|C5|"; depth:1; content:"|86|"; distance:4; depth:1; classtype:policy-violation; sid:1000069; rev:1;)

Snort Rule 1000088. Rule for detection of traffic generated through eDonkey. alert udp any any -> any any (msg:"LocalRule:P2P eMule KAD UDP - KAD Hello Request"; content:"|E4 10|"; depth:2; classtype:policy-violation; sid:1000088; rev:1;)

Snort Rule 1000090. Rule for detection of traffic generated through eDonkey. alert udp any any -> any any (msg:"LocalRule:P2P eMule KAD UDP - KAD2 Hello Request"; content:"|E4 11|"; depth:2; classtype:policy-violation; sid:1000090; rev:1;)

Snort Rule 1000098. Rule for detection of traffic generated through eDonkey. alert udp any any -> any any (msg:"LocalRule:P2P eMule KAD UDP - KAD2 Request"; content:"|E4 21|"; depth:2; classtype:policy-violation; sid:1000098; rev:1;)

for this work according to the specifications mentioned in [22] and is more specific than the first one. It is only useful when using non obfuscated connections and if it occurs out of this scenario, it is certainly a false positive. This rule was not triggered often for non eDonkey traffic. Most of the times it was triggered as eDonkey traffic, while in fact, it was part of Windows RDC flow. Among created eDonkey, eMule and Kad snort rules, only those with higher number of occurrences are listed above. The reason for this is due to the high probability of low occurrences might represent false positives. It is important to notice that the patterns, on which the Snort rules reside, can also occur for other network applications, since they are not very complex by nature. One is RDC, but false positives can also be originated by other applications that, for instance, use some kind of encryption feature that would generate random like traffic. The rules presented at the end of the last page were triggered for eDonkey or Kad networks when obfuscation is not used. They are presented to allow the comparison with the occurrence of rules for obfuscation. These rules were the

Although there have been created a considerable number of Snort rules for eDonkey traffic, their use is meant for non obfuscated connections. Besides, the results obtained during the tests at EANTC [24] and also published in InformationWeek [25] were, at least, discouraging, so the number of expected triggered alerts using the known patterns was quite low or even null. Nevertheless, some alerts were still triggered, specially when using the Kad network, as it does not provide Kademlia UDP obfuscation yet. “Obfuscation is currently available for ED2k TCP and UDP, Server TCP and UDP and Kad TCP communication. Kad UDP packets are not yet obfuscatable” [4]. Regarding the first two Snort rules presented below for eDonkey traffic, the first one is already included in the Snort distribution and although it is quite generic, since only analyses the first byte of the packet content, it was not triggered a single time, not even for non obfuscated traffic. The reason for this is that it only analyses outgoing TCP traffic having port 4242 as destination, which is not usual nowadays, since application port numbers are randomly generated at installation time. The second rule was created

177

V. EXPERIMENTS USING OBFUSCATION After the conclusion of the previous tests, it is time to see how the same set of rules behaves for obfuscated connections. eMule application was configured using the already mentioned settings Enable protocol obfuscation and Allow obfuscated connections only (not recommended), to guarantee the maximum stealthiness possible. Even though many rules were triggered, once again those were mainly rules already developed for DHT BitTorrent traffic. Nevertheless, no .torrent file was ever used during these tests. Since Kad UDP obfuscation was not yet supported, most of the rules for this traffic were triggered. In order to avoid a very large set of test results due to the large amount of Kad rules created, only eDonkey network support was used in the following tests. The first test used both TCP and UDP protocols, while in the second, UDP support was disabled but even still UDP rules were still being detected. The results for the most triggered rules during the download of the documentary “Inside the Space Shuttle” are presented in Table III, showing the effectiveness of the proposed Snort rules to detect encrypted traffic generated by eMule. Again, the appearance of rules 1000306, 1000307, and 1000308 was somewhat unexpected, since they were written to detect encrypted DHT BitTorrent traffic, albeit the first two were the ones that generate the largest number of alerts. Statistics collected by Snort, as a response to the stats command, have shown that no packets were lost in the queue due to the packet inspection in all experiments (with or without obfuscation), with the exception of the two-packet loss every time the statistics are collected, independently of the Snort load.

most triggered when not using obfuscation. Rule 1000001 appears often because of a greater difficulty to connect to the eDonkey network with this setting. The appearance of rules 1000306, 1000307, 1000308 and 2008581 was somewhat unexpected, since they were written to detect encrypted DHT BitTorrent traffic, which was also studied, but not addressed in this paper. Table II shows the occurrence of the previous rules during some experiments. Information in the first and third rows of this table refers to the use of eDonkey network only, while the second is relative to Kad only. Although the rules 1000317 and 2008581 occurred only once in the tests, their patterns are much more complex than those for eDonkey, extended eDonkey, and Kad. So, it is not likely at all that these were false positives. TABLE II.

CHARACTERISTICS OF EXPERIENCES AND THEIR DETECTION RESULTS FOR E MULE TRAFFIC WITHOUT OBFUSCATION .

Date

Starting Ending Number of Volume Alert Time Time Packets in Bytes 07-03-2009 14:15 14:23 8876 1096078 1000001 1000065 1000317 07-03-2009 14:31 14:33 2725 487614 1000001 1000067 1000068 1000069 1000088 1000090 1000098 08-03-2009 10:05 10:11 14452 1875946 1000001 1000306 1000307 1000308 2008581

Count 166 2 1 13 2 2 3 3 6 18 486 581 287 6 1

Snort Rule 1000005. Rule for detection of traffic generated through eDonkey with obfuscation. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"LocalRule:P2P eDonkey outbound - Get List of Servers"; flow:to_server,established; content:"|E3|"; depth:1; content:"|14|"; distance:4: depth:1; classtype:policy-violation; sid:1000005; rev:1;)

Snort Rule 1000019. Rule for detection of traffic generated through eDonkey with obfuscation. alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"LocalRule:P2P eDonkey UDP outbound - Status Request"; flow:to_server; content:"|E3 96|"; depth:2; classtype:policy-violation; sid:1000019; rev:1;)

Snort Rule 1000020. Rule for detection of traffic generated through eDonkey with obfuscation. alert udp $EXTERNAL_NET any -> $HOME_NET any (msg:"LocalRule:P2P eDonkey UDP inbound - Status Response"; flow:to_client; content:"|E3 97|"; depth:2; classtype:policy-violation; sid:1000020; rev:1;)

Snort Rule 1000024. Rule for detection of traffic generated through eDonkey with obfuscation. alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"LocalRule:P2P eDonkey UDP outbound - Server Description Request"; flow:to_server; content:"|E3 A2|"; depth:2; classtype:policyviolation; sid:1000024; rev:1;)

Snort Rule 1000025. Rule for detection of traffic generated through eDonkey with obfuscation. alert udp $EXTERNAL_NET Description Response"; sid:1000025; rev:1;)

any -> $HOME_NET any (msg:"LocalRule:P2P eDonkey UDP inbound - Server flow:to_client; content:"|E3 A3|"; depth:2; classtype:policyviolation;

Snort Rule 1000096. Rule for detection of traffic generated through eDonkey with obfuscation. alert udp any any -> any any (msg:"LocalRule:P2P eMule KAD UDP - KAD Request"; content:"|E4 20|"; depth:2; classtype:policy-violation; sid:1000096; rev:1;)

178

TABLE III. CHARACTERISTICS OF EXPERIENCES AND THEIR DETECTION RESULTS FOR E MULE TRAFFIC WITH OBFUSCATION. Date

Starting Time

Ending Time

Number of Packets

Volume in Bytes

eMule Traffic Downloaded

eMule Traffic Uploaded

Alert

Count

08-03-2009

11:04

11:24

46138

28618596

10.83MB

133.94KB

08-03-2009

12:01

13:37

392168

211286503

60.73MB

22.86MB

1000019 1000020 1000024 1000025 1000090 1000096 1000098 1000306 1000307 1000308 1000005 1000019 1000020 1000024 1000025 1000030 1000068 1000306 1000307 1000308 1000309 1000090

4 4 4 3 5 18 12 638 303 11 58 29 21 21 21 3 4 3489 1711 36 6 4

VI. CONCLUSION

Networking, Architecture, and Storage (NAS 2007), IEEE Press, pp.155-160. [11] J. Gomes, P. Inacio, M. Freire, M. Pereira, and P. Monteiro, “Analysis of Peer-to-Peer Traffic Using a Behavioural Method Based on Entropy”. Proc. IEEE Int. Performance, Computing and Communications Conf. (IPCCC 2008), IEEE Press, pp. 201 – 208. [12] M. Soysal and E.G. Schmidt, “An Accurate Evaluation of Machine Learning Algorithms for Flow-based P2P Traffic Detection”, Proc. Int. Symp. Computer and Information Sciences (ISCIS 2007), IEEE Press, pp. 1 - 6. [13] F.J. Gonzalez-Castano, P.S. Rodriguez-Hernandez, R.P. MartinezAlvarez, A. Gomez, I. Lopez-Cabido, and J. Villasuso-Barreiro, “Support Vector Machine Detection of Peer-to-Peer Traffic” Proc. IEEE Int. Conf. Computational Intelligence for Measurement Systems and Applications, 2006, IEEE Press, pp. 103 – 108. [14] Z. Gao, G. Lu, and D. Gu, “A Novel P2P Traffic Identification Scheme Based on Support Vector Machine Fuzzy Network”. Proc. 2nd Int. Workshop on Knowledge Discovery and Data Mining (WKDD 2009), IEEE Press, pp. 909 – 912. [15] B. Raahemi, A. Kouznetsov, A. Hayajneh, and P. Rabinovitch, “Classification of Peer-to-Peer traffic using incremental neural networks (Fuzzy ARTMAP)”, Proc. Canadian Conf. Electrical and Computer Engineering (CCECE 2008), IEEE Press, pp. 719 – 724. [16] Snort, http://www.snort.org. [Accessed, June 24, 2009]. [17] Smoothwall open source project, http://www.smoothwall.org. [Accessed, June 24, 2009]. [18] Basic analysis and security engine (base), http://base.secureideas.net. [Accessed, June 24, 2009]. [19] Wireshark, http://www.wireshark.org. [Accessed, June 24, 2009]. [20] http://www.edonkey2000.com. [Accessed, June 24, 2009]. [21] emule protocol obfuscation, http://wiki.emuleweb.de/index.php/Protocol_obfuscation. [Accessed, June 24, 2009]. [22] Danny Bickson and Yoram Kulbak, “The emule protocol specification”, The Hebrew University of Jerusalem, Israel, 2005. [23] Ipp2p. http://www.ipp2p.org. [Accessed, June 24, 2009] [24] European advanced networking test center; presentations 2006-2008. http://www.eantc.com/test_reports_presentations/presentations/2006_ 2008.html. [Accessed, June 24, 2009] [25] Paul McDougall, “Informationweek - business technology news, reviews and blogs”, http:/http://www.informationweek.com/801/peer.htm, August 2000. [Accessed, June 24, 2009]

This paper describes a method for detection of encrypted traffic generated by eMule based on signatures, which were coded as SNORT rules. Several lab experiments were carried out to validate the proposed method and to evaluate its accuracy. As a future work, we intend to generate the rules in an autonomic fashion and to integrate this method as part of a hybrid method that also considers a flow-based method based on entropy [11] to work under high speed and low latency environments. ACKNOWLEDGMENTS This work has been partially funded by Portuguese Fundação para a Ciência e a Tecnologia through TRAMANET Project contract PTDC/EIA/73072/2006. REFERENCES [1]

M. Pereira, “Peer-to-Peer Computing”, Encyclopedia of Information Science and Technology, IGI Global, Hershey, 2008, Vol. VI, 6 pages. [2] BitTorrent, http://www.bittorrent.com. [Accessed, June 24, 2009]. [3] Vuze, http://www.vuze.com. [Accessed, June 24, 2009]. [4] eMule project, http://www.emule-project.net. [Accessed, June 24, 2009]. [5] Limewire, http://www.limewire.com. [Accessed, June 24, 2009]. [6] GTK-Gnutella, http://www.gtk-gnutella.sourceforge.net. [Accessed, June 24, 2009]. [7] PeerApp: Comparing P2P Solutions, 2007, http://www.peerapp.com/docs/ComparingP2P.pdf. [Accessed, June 24, 2009]. [8] A. Madhukar and C.Williamson, “A Longitudinal Study of P2P Traffic Classification”, Proc. 14th IEEE Int. Symp. Modeling, Analysis, and Simulation of Computer and Telecommunication Systems ( MASCOTS 2006), IEEE Press, pp. 179 – 188. [9] Z. Guo and Z.Qiu, “Identification Peer-to-Peer Traffic for High Speed Networks Using Packet Sampling and Application Signatures”, Proc. 9th Int. Conf. Signal Processing (ICSP 2008), IEEE Press, pp. 2013-2019. [10] H. Liu, W. Feng, Y. Huang, and X. Li, “A Peer-To-Peer Traffic Identification Method Using Machine Learning”. Proc. Int. Conf.

179