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 Networ s 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. amages can include leaking secret information, message contamination, and node impersonation. !ll 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. #econd, mobile nodes are autonomous units that are capable of roaming independently. This means that nodes with inade$uate physical

protection are receptive to being captured, compromised, and hi%acked. #ince 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 decentrali&ed and some wireless network algorithms rely on the cooperative participation of all nodes and the infrastructure. The lack of centrali&ed authority means that the adversaries can exploit this vulnerability for new types of attacks designed to break the cooperative algorithms. To summari&e, a mobile wireless network is vulnerable due to its features of open medium, dynamic changing network topology, cooperative algorithms, lack of centrali&ed monitoring and management point, and lack of a clear line of defense. 1.!. T"e Nee# for Intrusion Dete$tion 'ntrusion 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. 'ntegrity 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 techni$ues, and further research is necessary to adapt these techni$ues to the new environment, from their

original applications in fixed wired network. 'n 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. RE%UIREMENT &PECI'ICATION

Har#ware &(e$ifi$ations *ard isk 0!1 5rocessor + ,-./ and !bove. + 2341/ and !bove. + 5entium ''' and !bove.

&oftware &(e$ifi$ations 6perating #ystem 5rogramming 5ackage used + Windows 3--- and !bove. + 7ava 2., and !bove, #wings.

).1MODU*E DE&CRIPTION The modules contained in this pro%ect are as follows+ istributed detection. a) 1ulticast the packet to detect the intruder. 1atching the 8ist of events. 1ulticast the intruder to the neighboring nodes. #ending data to destination.

).1.1 DI&TRI+UTED DETECTION The basic idea is to set up a monitor at each node in the network to produce e,i#en$es and to share them among all the nodes .!n evidence is a set of relevant information about the network state ! monitor can be thought of as an instance of the ethereal network packet sniffer+ 't captures the traffic and displays the detailed information on it.For each captured packet 9thereal displays a complete view of packet headers (i.e. from 9thernet to the application level) and payload and add some general statistics as the timestamp, frame number and length in bytes. For our purposes we:ll look at the 9thernet level header, and as we:re focusing on 4-3.22 frames we:ll consider source, destination and /##'d addresses, se$uence number, frame type and subtype and the 0etry 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 F;# (other papers<=> 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. 9vents 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 %amming attacks and channel failures, where packets are sent by one peer and never received by other peer. /oth the channel failure and a %amming attack make the F;# 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 3 cases is the amount of incorrectly received frames at the receiver. #uppose if the receiving station is under %amming network, where the packets which pass through the %amming area get scrambled. The monitor placed at the sender:s side will see the number of frames sent on the channel and the monitor at the receiver end won:t 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 receiver:s 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. 'f 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. 6n the other side, the transmitter cannot tell if the other peer is out of range given the retransmissions only.

).!.! 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. /efore 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 A2 in the source node. 0eceivers receive the packets which contain the timestamp and send appropriate !;B replies. 0eceivers store the received packets in their event list. !fter receiving all the packets from sourceCinitiator receiver sends the reply !;B by using multicast method. 'ntruder detection is done by checking the received !;B packets for anomalies. This is done by the matching algorithm. ).!.- MATCHIN. THE *I&T O' EVENT& 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. !s we don:t 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 (%amming or malfunctioning) happened. ;ontinuing the example above, we:d 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 %ammed), so we swap the 3 lists and run the matching algorithm again. The final output is a single list of events which combines the two. 7amming and channel failure have the same basic signature (which is packets transmitted and never received), but differentiate on their position in the event list. ! few packets disappearing here and there are index of channel failures, while a se$uence of disappearing packets is considered as %amming. ! large number of non"consecutive channel failures are index of bad Do#. #ince 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. 'n other words, we merge lists A2 and A3, and then we match the result with list AE, 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. ! single station alone cannot tell if it is experiencing an attack or %ust a temporary network failure, and cooperation among all nodes is re$uired for the nodes to understand what is going on. The event lists are shared among all nodes in the network. !ll nodes send their evidences to every other node in the network. 5art in the protocol. 9very 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.

).!./ MU*TICA&T THE INTRUDER TO THE NEI.H+OURIN. NODE& The matching algorithm will invoke after receiving reply events from the network. 't compares events from the other nodes with that of the initiator. 'f anyone from the received !;B packets is not matched, then that particular node is the intruder to be found. Fow that the intruder is detected the address of the intruder is sent to the entire network by multicasting. Feighbor nodes receive the '5 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. ).!.) &ENDIN. DATA TO THE DE&TINATION 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. 'n the case of %ammingCnetwork 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 ynamic #ource 0outing 5rotocol ( #0). The source sends the data directly to the destination through the Gsafe: path. estination 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 se$uence of events of the pro%ect is described in the diagram below.

'i0)./ Intrusion Detection System flow chart