Using Intrusion Detection to Detect Malicious Peer-to-Peer Network Traffic
Abiola Abimbola, Qi Shi and Madjid Merabti
Liverpool John Moores University,
School of Computing & Mathematical Sciences,
Byrom Street, Liverpool, L3 3AF
cmsaabim@livjm.ac.uk
Abstract- The concept of peer-to-peer (P2P) computing has
been around since the early days of networking when it
emerged as a result of, decentralising trends in software
engineering intersecting with available technology. A P2P
paradigm can be defined as one that moves away from the
centralised computing to a specialised version of client-
server computing. In this paper we described malicious P2P
applications as applications that threaten the security of
wired networks and network traffic from these applications
as malicious.
We justify the writing of this paper by:
• Examining the security threat exposed by the malicious
usage and security vulnerability associated with P2P
applications like clogging network links, being a conduit
for malware, information leakage etc.
• We then proceed to experiment and document the
feasibility of using Intrusion Detection System’s (IDS)
signature detection technique to detect P2P
application’s network traffic within a network, thus
controlling their usage.
Keywords: Peer-to-peer, Malicious, Client-server, Intrusion-
detection, Signature, Traffic and Malware
1. INTRODUCTION
The earliest application of peer-to-peer (P2P) was for
newsgroups (USENET) and to exchange messages
(FidoNet) [1]. In recent years P2P has gained public
attention mainly due to Napster’s popularity as a free
music sharing platform and its subsequent battle with the
big music corporations [2].
Initially P2P was the term given to a point-to-point
communications model, where both peers were equal and
either could initiate a communications session [3]. In
current day usage this term also refers to a class of
applications, systems or infrastructure that adapt this
communication model to perform critical functionalities.
P2P can be defined as the sharing of computer
resources and services by direct exchange between
systems. These resources and services include the
exchange of information, processing cycles, cache
desktop computing power and networking connectivity,
allowing economical clients to leverage their collective
power to benefit the entire enterprise” [4].
Other definitions have been proposed like, “P2P being a
class of applications that takes advantage of resources -
storage, cycles, content, human presence - available at the
ISBN: 1-9025-6009-4 © 2003 PGNet
edges of the Internet [5]. Because accessing these
decentralised resources means operating in an environment
of unstable connectivity and unpredictable Internet
Protocol (IP) addresses, P2P nodes must operate outside
the Domain Name Server (DNS) system and have
significant or total autonomy from central servers [6].
Current applications of P2P not only include file sharing
i.e. Napster, Gnutella and Freenet etc [7], but also instant
messaging i.e. American Online (AOL) Instant Messaging,
Yahoo Messenger and Mirabilis ICQ etc [8], distributed
computing i.e. Distributed.Net and SETI etc [9], web
search tools/engines and many more. Despite the usage of
the P2P systems, they are made of peers (entities that are
similar to each other) but not necessarily under the same
authority i.e. they do not all belong to the same user or are
not managed by the same entity, thus having different
priorities. For these systems to work efficiently, certain
research issues have to be tackled:
1. Since all peers are autonomous they cannot
necessarily trust each other as they are not
accountable for their actions, therefore the issues of
trust, scalability, penalising misbehaving peers and
redundancy have to be addressed.
2. How to enable peers that differ in physical
characteristics to contribute the same type of
resources to the P2P network.
3. Other issues like decentralisation, intermittent
connectivity, interoperability between different peer’s
platforms, security and anonymity.
In this paper we expand on issue “1” above by
describing malicious behaviours carried out by P2P users
intentional or unintentionally owing to security flaws in
P2P systems. Examples of malicious behaviour include:
• Consumption of network bandwidth by P2P users.
• Exploitation of P2P systems via Viruses and Trojan
horses [10] writers.
• Confidential information leakage.
We then proceed to outline a signature (unique
strings of words in network packet’s payload) based
security technique to address these malicious behaviours
using Snort IDS [11] by:
1. Monitoring P2P network traffic for specific
signatures and writing out detection rules and alerts
 using Snort rule sets, thus detecting P2P malicious
network traffic.
2. Test the validity of our signature rules by examining
true and false positive rates of
our signatures rule sets.
The rest of the paper is organised as follows, Section 2
describes the motivation of this paper in detail, Section 3
presents related work in this research area, Section 4
describes analysis of our experiments to justify our
technique and we conclude with a recap of our paper in
Section 5.
2. MOTIVATION
In this section we justify the writing of this paper by
describing security flaws introduced by P2P applications
in a network system.
Obviously, P2P applications hold a lot of promise for
the corporate world. After all, what’s wrong with making
it easier for employees to communicate and share files?
Using all of those spare central processing unit (CPU)
cycles on idle computers to solve large computational
problems is efficient, right? While the promise of P2P
technology is real; so are the problems and risk it
introduces to corporate networks. Some of these problems
and risks are described below:
• The most obvious and visible problem with P2P file-
sharing programs like Napster, Gnutella and FreeNet
concerns bandwidth utilization [12]. The rich media
audio and video files that P2P users share are big in
terms of memory usage. These multi-megabyte files
can clog corporate network links to the detriment of
business-related traffic. These traffic jams can affect
response times for internal users as well as e-business
customers- and that translate into lost revenue.
Even companies that do not use the Internet for
business with their customer can be affected by P2P
pileups. Many organizations have taken to using
Internet links to create virtual private networks
(VPN) between their officers or central office. If
legitimate traffic has to compete with non-business
file-sharing traffic, Virtual Private Network (VPN)
performance may suffer.
However, just because bandwidth-consumption
issues have received the most press does not mean
they are the biggest problem with P2P file sharing. In
fact, many organizations (especially colleges) have
successfully used traffic-shaping techniques to
allocate bandwidth so that P2P applications cannot
monopolize their Internet bandwidth. A number of
vendors offer bandwidth control applications that can
control unruly applications. Packeteer (http://www
.packeteer.com/) offers a hardware solution called
PacketShaper, and Check Point Software’s
FloodGate-1 (www.checkpoint.com) offers a
bandwidth-management solution that integrates well
with its popular Firewall-1 perimeter security
solution.
• Viruses and Trojan horses programs are a danger
owing to file sharing P2P applications. Yes, P2P
applications can provide a conduit for malicious code
to enter your network, but properly deployed
antivirus (AV) software can greatly reduce the risk.
“Properly deployed” in this case means two primary
things. First, desktop-and server-based AV scanning
definitions must be kept up to date. And second,
gateways servers (such as e-mail servers) must be
configured to block or sandbox suspicious
executables before they are transmitted and activated
by client applications.
• P2P file sharing applications require client software
to be installed on each node exposing the network to
a number of risks. What if the P2P applications are
badly written? It may cause the system to crash or
conflict with business applications. Security flaws in
the P2P applications may provide attackers with ways
to crash computers or access confidential
information. An attacker could also convince a naïve
user to download and install a booby-trapped P2P
client that does damage or allows them to access
more information than they should have.
• Another, perhaps more serious, risk with file-sharing
P2P applications is information leakage, the loss of
control over what data is shared outside of the
organization. When a user launches Napster or
Gnutella, they are also able to share information on
any of their local or network accessible disk drives
with people outside of the organization. A user can
easily on-configure their client to expose the
organization’s “crown jewel” or purposely expose
confidential information for gain or revenge.
• If an authorized user of your systems is trying to
clandestinely move information outside the corporate
network, P2P applications like Wrapster
(www.members.fortunecity.com/) can provide them
with ideal cover, by disguising the data as an MP3
file. Today, network administrators’ options for
preventing this type of abuse are limited; block file-
sharing applications entirely and/or scan for and
monitor MP3 files passing through the firewall in
either direction. We will return to these and other
preventive measures in the next section.
• Instant message (IM) clients like those provided by
AOL, Microsoft and Yahoo also pose an information
leakage threat to the organization. All of the
messages sent back and forth by users travel across
your network and the Internet in plaintext and can
easily be captured and read using network monitors.
Even the user’s username and password required for
IM are often transmitted in plaintext over the network
[13] as shown below using AudioGalaxy Satellite
P2P applications as an illustration.
 http://www.audiogalaxy.com/satellitelogin?loginUser
name=myusername& loginPassword=mypassword
The reader should be aware that most Internet users
used the same username and password for most
authentication website, thereby increasing possible
compromisation.
A common denominator of these problems is that P2P
applications can use well-known open ports protocols on
the corporate firewall, such as http, https, and ftp etc. P2P
applications can automatically switch between these ports
if they are closed to find an open one and can even pass
proxy servers, thereby making a blocking of any specific
network port a fruitless exercise.
3. RELATED WORK
In this section we describe current research work being
carried out to thwart the problems described in section 2.
So, what is a security professional to do in the face of
the popularity and threat of P2P applications? A few basic
actions and technologies that can help reduce these risks
are:
• In order to block Napster and similar P2P
applications, we need to block traffic to and from the
servers that broker the connections between peers.
Napster servers can be found at Internet Protocol (IP)
addresses in the 64.124.41.0 subnet, as well as at a
number of collocation facilities (for a list, visit
http://david.weekly.org/%20code/napster.php3).
However, there are also a number of independently
run servers that are Napster-compatible (some of the
more popular ones can be found at
www.napigator.com.list.php). Depending on your
security posture, either block connections from these
servers or scan your logs traffic to and from them.
New servers are always being added, so it is wise to
monitor these pages on a regular basis.
It is also possible for users to connect to Napster
and other P2P applications via making SOCKS proxy
connection [14] to a server outside your network that
has been set up to allow Napster bound traffic
through it. Since a proxy can be at any port and at
any address, there is no way to prevent this from
happening-you just need to monitor your firewall
logs.
• Bandwidth consumption owing to P2P applications is
usually due to the continuous serving or playing of
MP3 files. This is a common practice in Universities
and difficult to prevent. Using Packeteer’s
PacketShaper appliance, system administrators are
able to restrict Napster’s and other P2P services to
only a fraction of the network’s bandwidth capacity.
PacketShaper accomplishes this by classifying
network traffic into application and location based,
then analyses them and finally applying bandwidth
partitioning and per-session rate policies as a means
to control network traffic. Another appliance that
thwarts P2P bandwidth consumption is Check Point
Software’s Floodgate-1 (
http://www.check%20point.com/).
• While restriction bandwidth solves network
congestion problems, it does not address other
security threats posed by most P2P applications.
Essentially, P2P client services are nothing more than
locator systems, which identify the location of
specific files residing on the machines of registered
members. Not only can users access other people’s
files, but they can also open up their computer-and
everything to which it is connected-to the entire
Internet. Some commercial research has been done
on detecting P2P applications while being
downloaded on a network host
(soundjudgement:http://apreo.com/ products /), but
no paper has yet been published.
• When it comes to locking down P2P connections,
real-time switches
(www.%20whalecommunications.com) and firewalls
[15] suffer from similar problems. The reason for this
is that P2P traffic is easily masked as regular,
permissible traffic. They can even hide as regular http
with the use of simple programs that are readily
available on the Internet.
While the embedded content inspection in most air
gaps (http://www sphd.com) may help weed out
malicious content, they are incapable of detecting
P2P traffic in general. Some of the advanced air gap
solutions, such as the AG 300 from Spearhead
technologies (http://www.sphd.com/), can be used to
block P2P sources in the same way that firewalls can
–but that is not to say they are more effective than
firewalls.
Other real-time switches, such as the e-Gap from
Whale Communications, are designed to isolate only
one or two business-critical servers per gap device. In
this case, your organization’s user base would not be
working behind a-gab in its day-to-day activities.
While this is not an optimal solution, it does mean
that your business-critical application will be
protected should a P2P-injected virus enter your
“user” network.
Network switchers, such as the 2-in-1 Net from
Voltaire (http://www.voltaire.com/) and the
SecureSwitch from Market Central
(http://www.mctech.com/), can act as “P2P
deterrents” by making P2P applications tedious to
use. By their very nature, network switchers are
never connected to the source and destination
network at the same time, and system resources are
distinctly segmented between the two networks. A
system reboot is usually required to switch network,
at which point only information designed for that
network is accessible. This means that once a user
 connects to the Internet, they will no longer have
access to their internal information.
Network switchers do an adequate, if not
exceptional, job of addressing the threat of malicious
content through P2P connections. Unlike the higher-
end real-time switches, most network switchers do
not perform content inspection, leaving you open to a
P2P-based malware attack. However, the damage is
limited to the “Internet-connected” resources on that
machine. Network switchers also prevent
unauthorized information leakage by disabling access
to internal information while on the Internet.
Unfortunately, network switchers simply do not
address the risk of lost productivity, unauthorized use
of your organization’s resources or malicious content
in a meaningful way.
• D.J.Parish and A.Larkum’s “Detection Fraudulent
use in Packet Based Communication Networks”
paper [16], considers the problem of detecting illegal
use of an Internet type network where the
communication resource is used by non authorised
applications. A two-stage approach is presented.
Initially a novel approach to application detection is
used to enable stream of IP packets to be considered
as a single application “transaction” in an analogous
manner to a credit card purchase. The second stage
then uses Case Based Reasoning (CBR) to determine
if the communication “transaction” is consistent with
normal use, or otherwise. The application detector
analyses the packet size distribution of the
application in order to make its prediction. This
approach allows the detection of applications that do
not use registered port numbers, or are encrypted.
D.J.Parish et al’s technique has been successful
mainly due to CBR, which attempts to compare the
current “case” with a series of previously held cases
within a case base to find the nearest match. In doing
so various parameter are considered in the search
operation (such as application type, time of day,
duration of connection) and a nearest neighbour
analysis is used to find similar cases.
In comparison with our IDS’s signature based
technique that employs direct pattern matching
signatures, D.J.Parish’s methodologies would likely
results in a high false positive/negative rate and
consume larger processing time due to the scope of
parameters used for computation.
The use of P2P applications introduces security flaws into
the network; these security flaws are not specific in any
manner, hence a generic solution will have to be adopted
to remedy the problem. Possible generic
recommendations, which are common from the above-
related work, are described below.
• Establish, distribute and enforce written security
policies. These policies should reflect which P2P
applications should be installed on a desktop PCs and
define the acceptable uses for corporate computers.
• Update all AV applications. The proliferation of P2P
applications makes this a good time to ensure that all
gateways, servers and desktop are protected against
malware, and that procedures for timely update are
set-up.
• Figure out what subset of the network uses P2P
applications, then employ IDS both host and network
base [17] to isolate possible threats.
4. EXPERIMENT
In section 2 we described the potential problems caused
by P2P applications within a network. In section 3 we
describe current research work in thwarting these
problems and their flaws.
In this section, we first describe our novel approach to
solving these problems, then proceed to carry out an
experiment testing the feasibility of implementing this
approach and finally we validate our methodology.
P2P systems are not designed to be intrusive or
malicious applications, but become malicious owing to
their usage. This makes it difficult for software vendors to
design security systems to protect co-operation against
these applications since their usage varies.
Owing to the different functionality of most P2P
applications, any attempt to secure network host from P2P
applications vulnerability would have to involve multi-
layer technique. Examples of multi-layer technique are,
detecting the initial download, detecting the intrusive
usage of P2P applications within the host itself i.e. using
system processes or calls.
Our approach neglects the network host and focuses on
the network traffic pattern being made by communicating
P2P applications. As any client to server (C2S) or clients
to client (C2C) applications communicate, specific
protocols are required for transactions. These protocols
are unique to each network, thus can be used to detect the
C2C or C2S applications.
We divided our experimental analysis into two phases:
• The first phase was to monitor P2P applications
network traffic and analyse their protocol for unique
signatures.
• While the second phase involve writing IDS rules
that will detect these signatures in network traffic,
using snort IDS.
In order to test this hypothesis, experiments set-up and
P2P tools described below were required.
Experimental Set-Up
The following computer configuration, network topology
shown in figure 1 were used
in the experiment.
Local Subnet System makes actual determination of TCP source port
difficult for blockage. See figure 2.
Host “A” 2. P2P applications e.g. Bearshare, may connect to
IP address: 150.204.49.94 different peers using the same destination TCP port.
Memory:128 MB This fact provides us with a means of determining a
Disk: 8GB signature using the unique destination port but also
Operating System: Windows 2000 discourages the usage of the P2P’s initiation network
Purpose: Contains installed P2P applications traffic as a signature, since these are different
between peers. See figure 3 for network samples.
Host “B” 3. P2P applications on connection, may alternate
connection to different peers (servers) in no specific
IP address: 150.204.49.93
49.93
manner, this in turn makes determining a signature
Memory:128 MB
difficult. See figure 3 for network samples.
Disk: 8GB
4. All the P2P applications used in the experiment
Operating System: Windows 2000
utilise the http in some form, with this in mind
Purpose: Contain Ethereal a Network Monitor [18] and
appropriate signatures can be derived via this
Snort an IDS
protocol.
Source: SANDRA (150.204.49.94)
Destination: 12-236-155-190.client.attbi.com
Host A (12.236.155.190)
Transmission Control Protocol, Src Port: 2665 (2665),
Host B Dst Port: 6346 (6346)
Source: SANDRA (150.204.49.94)
Destination: 12-222-39-253.client.insightbb.com
Wide Area Network Local Subnet (12.222.39.253)
P2P Systems Transmission Control Protocol, Src Port: 2666 (2666),
Figure1: Network Topology. Dst Port: 5365 (5365)

P2P Tools Figure 2: Shareaza P2P applications Network Traffic.

The table below shows a list of P2P applications used Source: SANDRA (150.204.49.94)
for our experiments and their specific usage. Destination: ultra.bearshare.net (208.239.76.97)
Transmission Control Protocol, Src Port: 4701 (4701),
P2P applications Usage
Dst Port: 6346 (6346)
Bearshare File Sharing
Gnucleus File Sharing Source: SANDRA (150.204.49.94)
Imesh3.1 File Sharing Destination: syr-24-169-77-184.twcny.rr.com
Shareaza File Sharing (24.169.77.184)
Sidestep File Sharing Transmission Control Protocol, Src Port: 4702 (4702),
Xolox File Sharing Dst Port: 6346 (6346)
Table1: P2P Tools.
Figure 3:Bearshare P2P applications Network Traffic.
4.1 Phase-1 Analysis In the rest of this section, we single out Sidestep a P2P
application to describe our experimental procedures; all
The objective of this phase is to capture P2P conclusions drawn from this also applies to the rest of the
applications network traffic and analyse them for specific P2P applications.
signatures. The P2P application Sidestep was used to get travel
To accomplish this, each of the P2P applications were details from several peers in the following ways.
installed in Host “A” and then executed. In each case
Ethereal the network analyser was used to capture • It was allowed to set-up initial communication.
network traffic. From analysing these network traffic the • Allowed to perform varied operations including
following inferences can be made. getting airline ticket, retrieving hotels and tourist
details.
1. P2P applications e.g. Imesh, when connecting to
other peers may change their Transmission Control Throughout these transactions, we collected network
Protocol (TCP) network port several times, if traffic samples via Ethereal.
persistent failure in network connection occurs. This From each sample, we determined specific pattern that
occurred consistently when that particular operation was
requested. Table 2 below shows the signature samples
selected for each P2P application. The reader should note
that these samples are in hexadecimal numbers and can be
easily translated into decimals via a conversion table.
P2P Applications & Specific Pattern
Protocol (Signatures)
Bearshare ÆTCP 18 Ca
Gnucleus ÆHTTP 48 6f 73 74 3a 20 6f 6e
75 63 6c 65 75 73 2e 67
6e 75 74 65 6c 6c 69 75
6d 73 2e 63 6F 0d 0a
Imesh3.ÆHTTP 45 00 01 7e 0d f8 40 80
06 00 00 96 cc fe 31
ShareazaÆHTTP 48 6f 73 74 3a 20 77 77
77 2e 73 68 61 72 65 61
7a 61 2e 63 6f 6d 0d 0a
XoloxÆ HTTP 48 6f 73 74 3a 20 77 77
77 2e 78 6f 6c 6f 78 2e
6e 6c 0d 0a
SidestepÆHTTP 48 6F 73 74 3a 0180 20
73 74 61 72 74 36 30 2e
69 64 65 73 74 65 70 2e
63 6F 0d 0a.
Table2: P2P and their Signatures
4.2 Phase-2 Writing of Signature Rules & Testing
In this section we describe the writing of signature rules
using Snort IDS rule sets. The objective is to use these
rules to capture associated network traffic. Snort IDS uses
a simple, lightweight rule description language that is
flexible. There are a number of sample guidelines to
remember when developing Snort rules.
Most Snort rules are written in a single line. This was
required in version prior to 1.8. In current versions of
Snort, rules may span multiple lines by adding a
backslash to the end of the line.
Snort rules are divided into two logical sections, the
rule header and the rule options. The rule header contains
the rule’s action, protocol, source and destination IP
addresses and netmasks, and the source and destination
ports information. The rule option section contains alert
messages and information on which parts of the packets
should be inspected to determine if the rule action should
be taken.
Using figure 4 below as an illustration, the text up to
the first parenthesis is the rule header and the section
enclosed in parenthesis is the rule options. The words
before the colons in the rule options section are called
option keywords. Note that the rule options section is not
specifically required by any rule, they are just used for
making tighter definitions of packets for collection or
alert on (or drop, for that matter). All of the elements that
make up a rule must be true for the indicated rule action
to be taken. When taken together, the elements can be
considered to form a logical AND statement. At the same
time, the various rules in a Snort rules library file can be
considered to form a large logical OR statement.
Alert tcp any any Æ 192.168.1.0 (content: “|00 01 86
a5|”; msg: “mounted access”;)
Figure4: Sample of Snort Rule
Using Sidestep signature pattern derived in phase 1, we
wrote a Snort rule as shown in figure 5. The rule allows
the detection of any host within a network transmitting
Sidestep network signature to any outside host. We
designed Snort IDS response to be an alert saying
(“Sidestep P2P applications being used”).
Alert http any any Æ any any (content: “|48 6F 73 3a
0180 20 73 74 61 72 74 36 30 2e 69 64 65 73 74 65 70 2e
63 6F 6d 0d 0a|”; msg: “Sidestep P2P applications being
used”;)
Figure5: Sidestep Snort Rule
To test the rule sets of the P2P applications used in our
experiments, we went through the following procedures:
1. We executed other supporting applications (tcpdump)
within the same network to increase the network
traffic, thus simulating a real life network and
enabling us to test for false and true positive rates and
of our P2P application’s signatures.
2 While these supporting applications were executing,
we executed our P2P application and used Snort IDS
to detect their usage via alerts. See figure 6 for a
sample of Snort IDS’s Sidestep alert.
We carried out these procedures several times using
different supporting applications.
Our test showed conclusively for each time we carried
out the testing procedure, all P2P applications were
detected via Snort IDS and appropriate alert displayed.
The designed Snort rule sets for the P2P applications,
while carrying out the test procedures, did not generate
any false positives. See table 3.
[**]Sidestep P2P applications being used [**]
01/18-22:39:04.482419 0:A0:24:A6:51:6F ->
0:10:5A:2E:8E:BF type:0x800 len:0x3C
150.204.49.94 :3474 -> 150.204.254.49: 8080 HTTP
TTL:128 TOS:0x0 ID:64489 IpLen:20 DgmLen:46
Len: 26
.c......9....uK...
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
+=+=+=+=+=+=+=+=+=+=
Figure 6: Snort IDS alerts to Sidestep P2P
P2P No: of Test No: of No: of Proceedings: Year (11/12/2000).O'Reilly's Emerging
Applications Procedures True False Technology Conference: April 22-25, 2003.
Positives Positives [6] Edith Cohen and Haim Kaplan, “Prefetching the
Bearshare 30 30 0 means for document transfer: a new approach for
reducing Web latency”, Computer Networks, V( 39),
Gnucleus 30 30 0
Iss(4), PP( 437-455), Year(15 July 2002).
Imesh3. 30 30 0
[7] Stefan Saroiu, P. Krishna Gummadi and Steven D.
Shareaza 30 30 0 Gribble, “A Measurement Study of Peer-to-Peer File
Xolox 30 30 0 Sharing Systems”, Proceedings of Multimedia
Msc-Cnet 30 30 0 Computing and Networking 2002 (MMCN '02)
Sidestep 30 30 0 January.
Table 3: Test Results [8] Bonnie A Nardi, Steve Whittaker et al, “Interaction
and Outteraction Insant Messaging in Action”, In the
5. SUMMARY Proceeding of the 2000 ACM conference on Computer
Supported Cooperative Work, PP(79-88), Year
We have shown the advantages of using P2P (2000).
applications in the current climate. These advantage [9] John Billingham, Pesek Lecture: “SETI and Society-
include, file sharing, multimedia document exchange etc. decision trees”, Acta Astronantica, V( 51), Iss(10), PP
With the introduction of these advantages, P2P (667-672) , Year (November 2002).
applications exposes the host platform and network to
security threats such as the consumption of network [10] Abiola Abimbola, David Gresty and Qi Shi,
bandwidth, being a conduit for malware, information “SubSeven’s Honey Pot Program”, Network Security
leakage etc. ISSN 1353-4858 , PP(10-14), Year (July 2002).
In this paper, we approach these security threats from
the network perspective using P2P application’s [11] Martin Roesch, “Snort-Lightweight Intrusion
distinctive network signature to identify their usage. Detection for Networks” USENIX LISA Conference
To accomplish this task, we repeatedly monitored P2P November, Year (1999).
network traffic using a network monitor to deduce their [12] Clark J.A, Tsiaparas A., “ Bandwidth-On-Demand
respective signatures. These signatures were then Networks –A Solution to Peer-To-Peer File Sharing”,
included into Snort IDS rule sets. BT Technology Journal, V(20), No(1), PP( 53-63).
To test our technique, we increased the network load [13] Marc Hedlund, “AudioGalaxy Flubs Security”,
using supporting applications like tcpdump and tried O’Reilly’s Emerging Technology Conference
detecting P2P application usage via their network traffic Proceedings: Year (11/12/2000).
using our designed Snort IDS rules set. The results of [14] Al Berg,” P2P, or Not P2P”, Information Security
these experiments were documented. Magazine, February 2001.
We are aware of the limitations of signature-based [15] Y.Yavwa, “The Firewall Technology”, Year ( May 2,
technique in IDS [19], and other techniques like 2000), Department. of computer science university of
abnormally [20] and immunisation [21] that provide a Cape Town, http://www.cs.uct.ac.za/.
greater scope of detection, but believe the merit of speed [16] D.J.Parish and A.Larkum’s “Detection Fraudulent use
and low false positive introduced by our technique makes in Packet Based Communication Networks”,
Postgraduate Network Conference Year (2002),
it a valid methodology. Liverpool John Moores University UK.
[17] Stefan Axelsson, “On a Different of Intrusion
REFERENCES Detection”, Department of Computer Engineering
[1] Patrick Gerland, “Accessing and Using the Internet Chalmers University of Technology Goteburg,
Accessing and Using the Internet”, Year (2003), Swenden, Year ( 1999).
http://www.undp.org /popin/ softproj/p a p e r s.htm. [18] Ethereal, Year (2002) http://www. ethereal .com/.
[2] Dong Y, Li M, Chen M, Zheng S, “Research on [19] S.Kumar and E.Spafford, “A Pattern-Matching Model
Intellectual Property Right Problems of Peer-to-Peer for Misuse Intrusion Detection”, In proceeding of the
Network, The Electronic Library”, V( 20), No(2), 17th National Computer Security Conference, PP(11-
PP(143-150), Year (1 February 2002). 12) , Year (1994).
[3] David Duke, “Peer-to-Peer sharing” Cryptic Software, [20] A. Seleznyous, “A Methodology to Detect Anomalies
Network Security, V(1), No(7), PP( 4-4), Year (1 July in user Behaviour Based on its Temporal
2002). Regularities”, In proceeding of the 16th International
[4] Kwok S.H, Lang K. R., Tam K.Y, “Peer-to-peer Conference on Information Security, Year (2001).
Technology Business and Service Models: Risk and [21] S Forrest and S.Hofmeyr, “ Immunology as
Opportunities, Electronic Markets”, V( 12), No(3), Information Processing”, In design Principles for
PP(175-183), Year (1 September 2002). Immune Systems and other Distributed Autonomous
[5] Clay Shirky, “What is P2P..And What Isn’t”, Systems, (Ed) Segal, L.A. & Cohen, I. R. eds., Oxford
O’Reilly’s Emerging Technology Conference University Press, Year (2000)