CHAPTER 1 INTRODUCTION

The rapid proliferation of wireless networks and mobile computing applications has changed the landscape of network security. The nature of mobility creates new vulnerabilities that do not exist in a fixed wired network, and yet many of the proven security measures turn out to be ineffective. Therefore, the traditional way of protecting networks with firewalls and encryption software is no longer sufficient. We need to develop new architecture and mechanisms to protect the wireless networks and mobile computing applications. 1.1. Vulnerabilities of Mobile Wireless Networks The nature of mobile computing environment makes it very vulnerable to an adversary's malicious attacks. First of all, the use of wireless links renders the network susceptible to attacks ranging from passive eavesdropping to active interfering. Unlike wired networks where adversary must gain physical access to the network wires or pass through several lines of defense at firewalls and gateways, attacks on a wireless network can come from all directions and target at any node. Damages can include leaking secret information, message contamination, and node impersonation. All these mean that a wireless ad-hoc network will not have a clear line of defense, and every node must be prepared for encounters with an adversary directly or indirectly. Second, mobile nodes are autonomous units that are capable of roaming independently. This means that nodes with inadequate physical

protection are receptive to being captured, compromised, and hijacked. Since tracking down a particular mobile node in a global scale network cannot be done easily, attacks by a compromised node from within the network are far more damaging and much harder to detect. Therefore, mobile nodes and the infrastructure must be prepared to operate in a mode that trusts no peer. Third, decision-making in mobile computing environment is sometimes decentralized and some wireless network algorithms rely on the cooperative participation of all nodes and the infrastructure. The lack of centralized authority means that the adversaries can exploit this vulnerability for new types of attacks designed to break the cooperative algorithms. To summarize, a mobile wireless network is vulnerable due to its features of open medium, dynamic changing network topology, cooperative algorithms, lack of centralized monitoring and management point, and lack of a clear line of defense. 1.2. The Need for Intrusion Detection Intrusion prevention measures, such as encryption and

authentication, can be used in ad-hoc networks to reduce intrusions, but cannot eliminate them. For example, encryption and authentication cannot defend against compromised mobile nodes, which often carry the private keys. Integrity validation using redundant information (from different nodes), such as those being used in secure routing, also relies on the trustworthiness of other nodes, which could likewise be a weak link for sophisticated attacks. To secure mobile computing applications, we need to deploy intrusion detection and response techniques, and further research is necessary to adapt these techniques to the new environment, from their

original applications in fixed wired network. In this paper, we focus on a particular type of mobile computing environment called mobile ad-hoc networks and propose a new model for intrusion detection and response for this environment. We will first give a background on intrusion detection, and then present our new architecture. REQUIREMENT SPECIFICATION

Hardware Specifications Hard Disk RAM Processor : 40GB and Above. : 128MB and Above. : Pentium III and Above.

Software Specifications Operating System Programming Package used : Windows 2000 and Above. : Java 1.4 and Above, Swings.

5.1MODULE DESCRIPTION The modules contained in this project are as follows: Distributed detection. a) Multicast the packet to detect the intruder. Matching the List of events. Multicast the intruder to the neighboring nodes. Sending data to destination.

5.1.1 DISTRIBUTED DETECTION The basic idea is to set up a monitor at each node in the network to produce evidences and to share them among all the nodes .An evidence is a set of relevant information about the network state A monitor can be thought of as an instance of the ethereal network packet sniffer: It captures the traffic and displays the detailed information on it.For each captured packet Ethereal displays a complete view of packet headers (i.e. from Ethernet to the application level) and payload and add some general statistics as the timestamp, frame number and length in bytes. For our purposes well look at the Ethernet level header, and as were focusing on 802.11 frames well consider source, destination and BSSId addresses, sequence number, frame type and subtype and the Retry flag. Together with the captured packets, we add relevant statistics collected by the device driver, like counters for transmission retries and for frames received with wrong FCS (other papers[7] use different statistics as signal strength and carrier sensing time), and packet transmission time. We built in this way a list of events at each node. Events are the single transmitted

packet or the times in which the channel is idle, which can be inferred from the timestamp of the packets and the packet transmission times. The combination of different list of events leads to the better understanding of what happened in the network, in particular in distinguishing the jamming attacks and channel failures, where packets are sent by one peer and never received by other peer. Both the channel failure and a jamming attack make the FCS check of the packet fail, thus the packet in transit will be incorrectly received and dropped, incrementing the dropped frames counter in the device driver at the receiver. The difference between the 2 cases is the amount of incorrectly received frames at the receiver. Suppose if the receiving station is under jamming network, where the packets which pass through the jamming area get scrambled. The monitor placed at the senders side will see the number of frames sent on the channel and the monitor at the receiver end wont see anything received correctly, and will keep on increasing the incorrectly received frames counter. The sender will retry the transmission a number of times and all these retransmissions will be dropped as well, incrementing the counter. We are able to detect the attack by combining what both monitors saw, as a single one is not able to do the same: the receivers evidences (no packets received and counter updated) are in fact not enough to distinguish the attack. For the receiver, receiving incorrect frames can happen for various reasons: frames from stations at the limit of the radio range, frames from neighbor networks or noisy channel are all examples of this. If the

counter is not updated, then staying idle without having transmissions aimed at it or experiencing a device failure is undistinguished from being under attack. On the other side, the transmitter cannot tell if the other peer is out of range given the retransmissions only.

5.2.2 DETECT THE INTRUDER The initial process is the training process where the source sends the packet with events to all the nodes in the network to detect the intruder. This process is known as multicasting. Before sending the packets to all nodes, the source node initiates the timestamp for the packets. This training process is stored as an initial event list #1 in the source node. Receivers receive the packets which contain the timestamp and send appropriate ACK replies. Receivers store the received packets in their event list. After receiving all the packets from source/initiator receiver sends the reply ACK by using multicast method. Intruder detection is done by checking the received ACK packets for anomalies. This is done by the matching algorithm. 5.2.3 MATCHING THE LIST OF EVENTS The basic algorithm to match two lists of events is as follows: we start from the first list and for every event (packet or channel idle) we try to find a matching event on the second list that is, given a packet we look for it on the second list. As we dont have cheaters into play for now, what we find is that for every packet on the first list we find it on the second one if the network worked fine, else we find a channel idle event if some problem (jamming or malfunctioning) happened. Continuing the example above, wed have transmitted packets on the first event list and channel idle (together with a

high number of dropped packets) on the second one. We can find unmatched events on the second list at the end (for example if the first node was jammed), so we swap the 2 lists and run the matching algorithm again. The final output is a single list of events which combines the two. Jamming and channel failure have the same basic signature (which is packets transmitted and never received), but differentiate on their position in the event list. A few packets disappearing here and there are index of channel failures, while a sequence of disappearing packets is considered as jamming. A large number of non-consecutive channel failures are index of bad QoS. Since all nodes participate in the detection process, we extend it in order to match multiple lists. The idea is to merge one list at a time with the result of the previous merge. In other words, we merge lists #1 and #2, and then we match the result with list #3, until we processed every list. We obtain in this way an aggregated list of all events which happened in the network in a given time frame. We have to notice here that a node might not overhear the traffic of every other node because of range. We supposed that each node has relevant information to offer, but this is not always true. The key feature here is that the monitoring system is distributed. A single station alone cannot tell if it is experiencing an attack or just a temporary network failure, and cooperation among all nodes is required for the nodes to understand what is going on. The event lists are shared among all nodes in the network. All nodes send their evidences to every other node in the network. Part in the protocol. Every node executes the matching algorithm to generate the aggregated event list to have a clear view of what happened in the network in the given time frame.

5.2.4 MULTICAST THE INTRUDER TO THE NEIGHBOURING NODES The matching algorithm will invoke after receiving reply events from the network. It compares events from the other nodes with that of the initiator. If anyone from the received ACK packets is not matched, then that particular node is the intruder to be found. Now that the intruder is detected the address of the intruder is sent to the entire network by multicasting. Neighbor nodes receive the IP address of the intruder and store it in the event lists to prevent future attacks from that node in the network. The multicasting of the intruder address is done source. 5.2.5 SENDING DATA TO THE DESTINATION The data send process is done by splitting the chosen text file into packets for transmission. The data send process is invoked after the source finds out an intruder free path. In the case of jamming/network malfunction, the source waits till the network is restored, starts the training process to find the intruders and if any detected, selects a path free from intrusion. The path selection is done by the Dynamic Source Routing Protocol (DSR). The source sends the data directly to the destination through the safe path. Destination receives the data in the form of packets and checks for anomalies to detect any loss of data in the data due to intrusion.

The control flow and sequence of events of the project is described in the diagram below.

Fig5.4 Intrusion Detection System flow chart