The document describes a proposed wireless intrusion detection system and new attack model. It begins by outlining vulnerabilities in mobile wireless networks like susceptibility to eavesdropping and interfering attacks. It then discusses the need for intrusion detection as prevention measures alone are insufficient. The proposed system uses a matching algorithm to compare observed network behaviors and detect anomalies indicative of intrusions. It analyzes evidence from multiple nodes to identify intruders, multicasts intruder addresses to neighbors, and routes data along paths free of detected intruders.

1. A wireless Intrusion detection system and a new
attack model
(Synopsis)
1

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

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

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

5. EXISTING SYSTEM
 Traditional systems in place for intrusion detection
primarily use a method known as “Finger Printing” to
identify malicious users. They are complex.
 They are rule dependent. The behavior of packets
flowing in the network is new, then the system cannot
take any decision. So they purely work in the basis of
initial rules provided.
 The rules in the database are static unless the network
administrator manually enters the rules. It does not
provide any option for generating dynamic rule set.
 It cannot create its own rule depending on the current
situation.
 It requires manual energy to monitor the inflowing
packets and analyze their behavior.
 It cannot take decision in runtime.
5

6.  If the pattern of the packet is new and not present in
the records, then it allows the packets to flow without
analyzing whether it is an intruder or not.
 The packet with a new behavior can easily pass without
being filtered.
PROPOSED SYSTEM
 It uses matching algorithm, which is an artificial
intelligence problem-solving model.
 IDS compare learned user characteristics from an
empirical to all users of a system.
 It includes temporal and spatial information of the
network traffic.
 It is both network based and host based system.
 It can take decision in runtime.
6

7. ADVANTAGES
 It eliminates the need for an attack to be previously
known to be detected because malicious behavior is
different from normal behavior by nature.
 Using a generalized behavioral model is theoretically
more accurate, efficient and easier to maintain than a
finger printing system.
 It uses constant amount of computer resources per
user, drastically reducing the possibility of depleting
available resources.
 Once installed, there is no need for any manual energy
to monitor the system.
 It promotes high detection rate of malicious behavior
and a low false positive rate of normal behavior
classified as malicious.
7

8. MODULE 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.
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 we’ll look at the
Ethernet level header, and as we’re focusing on 802.11
frames
we’ll
consider
source,
destination
and
BSSId
addresses, sequence number, frame type and subtype and
8

9. 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 sender’s side will see
9

10. 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. 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.
DETECT THE INTRUDER
The initial process is the training process where the
source sends the packet with events to all the nodes in the
10

11. 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.
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 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
(jamming
or
malfunctioning) happened. Continuing 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
11

12. 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 nonconsecutive 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,
12

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

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

15. Intrusion Detection System flow chart
15

16. REQUIREMENT SPECIFICATION
Hardware Specifications
Hard Disk
: 40GB and Above.
RAM
: 128MB and Above.
Processor
: Pentium III and Above.
Software Specifications
Operating System
: Windows 2000 and
Above.
Programming Package used
Swings.
16
: Java 1.4 and Above,