Using Intrusion Detection to Detect Malicious Peer-to-Peer Network ...

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 [email protected]

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 clientserver 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, Intrusiondetection, Signature, Traffic and Malware

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.

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

2. 3.

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. How to enable peers that differ in physical characteristics to contribute the same type of resources to the P2P network. 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.

•

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 filesharing 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.

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 filesharing 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.

to control network traffic. Another appliance that thwarts P2P bandwidth consumption is Check Point Software’s Floodgate-1 ( http://www.check%20point.com/).

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.

•

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

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

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 higherend 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 aboverelated 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 multilayer 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 Host “A” IP address: 150.204.49.94 Memory:128 MB Disk: 8GB Operating System: Windows 2000 Purpose: Contains installed P2P applications

3.

Host “B” IP address: 150.204.49.93 49.93 Memory:128 MB Disk: 8GB Operating System: Windows 2000 Purpose: Contain Ethereal a Network Monitor [18] and Snort an IDS

Host A Host B Wide Area Network P2P Systems

Local Subnet

Figure1: Network Topology. P2P Tools The table below shows a list of P2P applications used for our experiments and their specific usage. P2P applications Usage Bearshare File Sharing Gnucleus File Sharing Imesh3.1 File Sharing Shareaza File Sharing Sidestep File Sharing Xolox File Sharing Table1: P2P Tools. 4.1 Phase-1 Analysis The objective of this phase is to capture P2P applications network traffic and analyse them for specific signatures. To accomplish this, each of the P2P applications were installed in Host “A” and then executed. In each case Ethereal the network analyser was used to capture network traffic. From analysing these network traffic the following inferences can be made. 1.

2.

P2P applications e.g. Imesh, when connecting to other peers may change their Transmission Control Protocol (TCP) network port several times, if persistent failure in network connection occurs. This

4.

makes actual determination of TCP source port difficult for blockage. See figure 2. P2P applications e.g. Bearshare, may connect to different peers using the same destination TCP port. This fact provides us with a means of determining a signature using the unique destination port but also discourages the usage of the P2P’s initiation network traffic as a signature, since these are different between peers. See figure 3 for network samples. P2P applications on connection, may alternate connection to different peers (servers) in no specific manner, this in turn makes determining a signature difficult. See figure 3 for network samples. All the P2P applications used in the experiment utilise the http in some form, with this in mind appropriate signatures can be derived via this protocol.

Source: SANDRA (150.204.49.94) Destination: 12-236-155-190.client.attbi.com (12.236.155.190) Transmission Control Protocol, Src Port: 2665 (2665), Dst Port: 6346 (6346) Source: SANDRA (150.204.49.94) Destination: 12-222-39-253.client.insightbb.com (12.222.39.253) Transmission Control Protocol, Src Port: 2666 (2666), Dst Port: 5365 (5365) Figure 2: Shareaza P2P applications Network Traffic. Source: SANDRA (150.204.49.94) Destination: ultra.bearshare.net (208.239.76.97) Transmission Control Protocol, Src Port: 4701 (4701), Dst Port: 6346 (6346) Source: SANDRA (150.204.49.94) Destination: syr-24-169-77-184.twcny.rr.com (24.169.77.184) Transmission Control Protocol, Src Port: 4702 (4702), Dst Port: 6346 (6346) Figure 3:Bearshare P2P applications Network Traffic. In the rest of this section, we single out Sidestep a P2P application to describe our experimental procedures; all conclusions drawn from this also applies to the rest of the P2P applications. The P2P application Sidestep was used to get travel details from several peers in the following ways. •

It was allowed to set-up initial communication.

•

Allowed to perform varied operations including getting airline ticket, retrieving hotels and tourist details.

Throughout these transactions, we collected network traffic samples via Ethereal. 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 & Protocol Bearshare ÆTCP Gnucleus ÆHTTP

Specific Pattern (Signatures) 18 Ca 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

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.

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.

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 Applications Bearshare Gnucleus Imesh3. Shareaza Xolox Msc-Cnet Sidestep

No: of Test Procedures

No: of True Positives 30 30 30 30 30 30 30 30 30 30 30 30 30 30 Table 3: Test Results

No: of False Positives 0 0 0 0 0 0 0

5. SUMMARY We have shown the advantages of using P2P applications in the current climate. These advantage include, file sharing, multimedia document exchange etc. With the introduction of these advantages, P2P applications exposes the host platform and network to security threats such as the consumption of network bandwidth, being a conduit for malware, information leakage etc. In this paper, we approach these security threats from the network perspective using P2P application’s distinctive network signature to identify their usage. To accomplish this task, we repeatedly monitored P2P network traffic using a network monitor to deduce their respective signatures. These signatures were then included into Snort IDS rule sets. To test our technique, we increased the network load using supporting applications like tcpdump and tried detecting P2P application usage via their network traffic using our designed Snort IDS rules set. The results of these experiments were documented. We are aware of the limitations of signature-based technique in IDS [19], and other techniques like abnormally [20] and immunisation [21] that provide a greater scope of detection, but believe the merit of speed and low false positive introduced by our technique makes it a valid methodology. REFERENCES [1]

[2]

[3]

[4]

[5]

Patrick Gerland, “Accessing and Using the Internet Accessing and Using the Internet”, Year (2003), http://www.undp.org /popin/ softproj/p a p e r s.htm. Dong Y, Li M, Chen M, Zheng S, “Research on Intellectual Property Right Problems of Peer-to-Peer Network, The Electronic Library”, V( 20), No(2), PP(143-150), Year (1 February 2002). David Duke, “Peer-to-Peer sharing” Cryptic Software, Network Security, V(1), No(7), PP( 4-4), Year (1 July 2002). Kwok S.H, Lang K. R., Tam K.Y, “Peer-to-peer Technology Business and Service Models: Risk and Opportunities, Electronic Markets”, V( 12), No(3), PP(175-183), Year (1 September 2002). Clay Shirky, “What is P2P..And What Isn’t”, O’Reilly’s Emerging Technology Conference

[6]

[7]

[8]

[9]

Proceedings: Year (11/12/2000).O'Reilly's Emerging Technology Conference: April 22-25, 2003. Edith Cohen and Haim Kaplan, “Prefetching the means for document transfer: a new approach for reducing Web latency”, Computer Networks, V( 39), Iss(4), PP( 437-455), Year(15 July 2002). Stefan Saroiu, P. Krishna Gummadi and Steven D. Gribble, “A Measurement Study of Peer-to-Peer File Sharing Systems”, Proceedings of Multimedia Computing and Networking 2002 (MMCN '02) January. Bonnie A Nardi, Steve Whittaker et al, “Interaction and Outteraction Insant Messaging in Action”, In the Proceeding of the 2000 ACM conference on Computer Supported Cooperative Work, PP(79-88), Year (2000). John Billingham, Pesek Lecture: “SETI and Societydecision trees”, Acta Astronantica, V( 51), Iss(10), PP (667-672) , Year (November 2002).

[10]

Abiola Abimbola, David Gresty and Qi Shi, “SubSeven’s Honey Pot Program”, Network Security ISSN 1353-4858 , PP(10-14), Year (July 2002).

[11]

Martin Roesch, “Snort-Lightweight Intrusion Detection for Networks” USENIX LISA Conference November, Year (1999). Clark J.A, Tsiaparas A., “ Bandwidth-On-Demand Networks –A Solution to Peer-To-Peer File Sharing”, BT Technology Journal, V(20), No(1), PP( 53-63). Marc Hedlund, “AudioGalaxy Flubs Security”, O’Reilly’s Emerging Technology Conference Proceedings: Year (11/12/2000). Al Berg,” P2P, or Not P2P”, Information Security Magazine, February 2001. Y.Yavwa, “The Firewall Technology”, Year ( May 2, 2000), Department. of computer science university of Cape Town, http://www.cs.uct.ac.za/. D.J.Parish and A.Larkum’s “Detection Fraudulent use in Packet Based Communication Networks”, Postgraduate Network Conference Year (2002), Liverpool John Moores University UK. Stefan Axelsson, “On a Different of Intrusion Detection”, Department of Computer Engineering Chalmers University of Technology Goteburg, Swenden, Year ( 1999). Ethereal, Year (2002) http://www. ethereal .com/. S.Kumar and E.Spafford, “A Pattern-Matching Model for Misuse Intrusion Detection”, In proceeding of the 17th National Computer Security Conference, PP(1112) , Year (1994). A. Seleznyous, “A Methodology to Detect Anomalies in user Behaviour Based on its Temporal Regularities”, In proceeding of the 16th International Conference on Information Security, Year (2001). S Forrest and S.Hofmeyr, “ Immunology as Information Processing”, In design Principles for Immune Systems and other Distributed Autonomous Systems, (Ed) Segal, L.A. & Cohen, I. R. eds., Oxford University Press, Year (2000)

[12]

[13]

[14] [15]

[16]

[17]

[18] [19]

[20]

[21]