Wireless Instruction Detection And Implementation In Java

 
 
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.
 

 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.
 

 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.
 
CHAPTER 2
 
LITERATURE SURVEY
 
 
2.1       REQUIREMENT ANALYSIS
 A mobile Ad-hoc network is a collection of nodes that is connected through a wireless medium forming rapidly changing topologies. The Dynamic topology of wireless Ad-Hoc network allows the node to join and leave the network at any point of time. This generic characteristic of wireless Ad-hoc network has rendered it vulnerable to security attacks. Attackers may be of any type. Identifying the attack type and providing the solution to the real time attacks can be done in real-time, by forming multiple numbers of wireless nodes in the cluster, cluster head, and implementing the Dynamic Source Routing (DSR) protocol, detection of attack types, prevention of attacks, etc.
 
 
There are several ways to categorize IDS

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

 The user can interact with the system through the user interface. There are different screens are available for the users to enter the details. Error messages are also generated.
 
 
Hardware Interfaces
Network cable, Network interface Card.
Software Interfaces
The operating system used Windows 2000. GA can be viewed as a tool to help generate knowledge for the Rule Based System (RBS).
Communications Interfaces
The Protocol to be used is TCP/IP.

The Software like Java is the important requirements for the performance improvement.
 
 2.4.2 Security Requirements
In the system, the IDS will check whether the chromosomes are match with dataset. If it is not match with the anomaly dataset, then the IDS will not allow the data to send. If it is match with the normal dataset, then the IDS will allow the data to send. So the intruder cannot be able to attack the system by the virus.         

2.5 ATTACKS IN AD-HOC NETWORKS
From the point of view of intrusion detection and response, we need to observe and analyze the anomalies due to both the consequence and technique of an attack. While the consequence gives evidence that an attack has succeeded or is unfolding, the technique can often help identify the attack type and even the identity of the attacker.
Attacks in MANET can be categorized according to their consequences as the following:
 
Blackhole: All traffic are redirected to a specific node, which may not forward any traffic at all.
Routing Loop: A loop is introduced in a route path.
Network Partition: A connected network is partitioned into k (k >= 2) sub networks where nodes in different sub networks cannot communicate even though a route between them actually does exist.
Selfishness: A node is not serving as a relay to other nodes.
Sleep Deprivation: A node is forced to exhaust its battery power.
Denial–of–Service: A node is prevented from receiving and sending data packets to its destinations
Some of the common attacking techniques are:
Cache Poisoning: Information stored in routing tables is either modified, deleted or injected with false information.
 Fabricated Route Messages: Route messages (route requests, route replies, route errors, etc.) with malicious contents are injected into the network.
Specific methods include:                         
a) False Source Route: An incorrect route is advertised into the network, e.g., setting the route length to be 1 regardless where the destination is.
b) Maximum Sequence: Modify the sequence held in control messages to the maximal allowed value. Due to some implementation issues, a few protocol implementations cannot effectively detect and purge these “polluted" messages timely so that they can invalidate all legitimate messages with a sequence number falling into normal ranges for a fairly long time
Rushing: This can be used to improve Fabricated Route Messages. In several routing protocols, some route message types have the property that only the message that arrives first is accepted by a recipient. The attacker simply disseminates a malicious control message quickly to block legitimate messages that arrive later.
 Wormhole: A tunnel is created between two nodes that can be utilized to secretly transmit packets.
 Packet dropping: A node drops data packets (conditionally or randomly) that it is supposed to forward.
 Spoofing: Inject data or control packets with modified source addresses.
Malicious Flooding: Deliver unusually large amount of data or control packets to the whole network or some target nodes.

2.5.1 IDENTIFYING THE ATTACKS                                                
For each attack, we call the node that runs the corresponding detection rule the “monitoring" node, and the node whose behavior is being analyzed (i.e., the possible attacking or misbehaving node) the “monitored" node. For attacks related to Packet Dropping, the monitoring node is a 1-hop Neighborhood of the “monitored" node. Both the attack type and the attacker can be identified because the monitoring node can overhear traffic within its 1-hop neighborhood. For Blackhole attacks, the monitoring node is also the monitored node because the detection rule relies on information that is available only on the node (obviously, if an attacker has full control of the node, then the detection modules can be disabled unless they run on some tamper-resistant device). For Flooding and Maximum Sequence attacks, only the attack type, but not the attacker, can be identified by a monitoring node. We now describe some notations of statistics (features) used in these rules. We use M to represent the monitoring node and m the monitored node.[1]
 
#(*;m): the number of incoming packets on the monitored node m.
 #(m;*): the number of outgoing packets from the monitored node m.
#([m];*): the number of outgoing packets of which the monitored node m is the source.
 #(*;[m]): the number of incoming packets of which the monitored node m is the destination.
 #([s];m): the number of incoming packets on m of which node s is the source.
 #(m;[d]): the number of outgoing packets from m of which node d is the destination.
 #(m;n): the number of outgoing packets from m of  which n is the next hop.
 #([s];M;m), the number of packets that are originated from s and transmitted from M to m.
 #([s];M;[m]), the number of packets that are originated from s and transmitted from M to m, of which m is the final destination.
 #([s];[d]), the number of packets received on the monitored node (m) which is originated from s and destined to d.
These statistics are computed over a feature sampling interval, denoted as Ls. In addition, we often need the same set of statistics that are computed over a longer period. These longer-term statistics can be computed directly from basic features by aggregating them in multiple feature sampling intervals. We use FEATUREL to denote the aggregated FEATURE over a long period L. We always assume that time interval L is multiples of Ls, for simplicity. For example, the notion,
#L(*;m) are computed by summing up all  #(*;m) in L=Ls rounds of feature sampling intervals.
We also need finer-grained statistics on specific types of packets, e.g., the number of certain route control messages. These specific statistics are denoted by appending a predicate to the corresponding feature. For instance, #(*;m)(TYPE=RREQ) represents the number of incoming RREQ (route request) packets on the monitored node m.
The other common problem with this system is one where the operator or the users start cheating. In either way, the misuse of the system cannot be detected by the system proposed so far. The system misuse problem is clearly discussed below.
2.6 SYSTEM MISUSE
The system presented so far works as long as cheaters stay out of the game. Why should a user cheat? The main reason is to get an advantage over other users. As stated in before, nodes can alter their network card random back off times and get an advantage over unmodified ones. In detail, a modified node will win the contention for the channel more often, getting a higher bandwidth share. Other techniques to do so are to launch DoS attacks against other nodes, like jamming or Deauthentication. Another possible reason would be to get the fee from the operator when the QoS is good in the commercial scenario we outlined above. For the following, we’ll consider this later case. Cheaters modify their lists of events to pretend to have bad QoS while it is good to get the fee from the operator. We’ll explain how to treat the other case later on .Cheaters will make the matching of the event list fail. In fact, a cheater will provide a list which is (at least in part) incompatible with the correct ones provided by the other honest nodes.
 For example, let’s imagine that a node receives a packet X and claims not to have received it. The sender will of course report that it sent the packet. The receiver will alter his event list by marking packet X+1 from the sender as X, packet X+2 as X+1 and so on. When the matching will take place, it will show this difference. We modify then our algorithm, and for every event we keep track of which node reported it and of clashing and incompatible events. In the example above, assuming A as the sender and B as the receiver, the list will report “channel free (reported by node B) AND packet X from A to B (reported by node A)” ”packet X from A to B (B) AND packet X+1 from A to B (A)”,”packet X+1 from A to B (B) AND packet X+2 from A to B (A)”. Under the hypotheses that all nodes are in range of each other, and that each node is either honest or cheater, when we try to build an aggregated list of events we’ll end up with all honest users agreeing on a list, and cheaters disagreeing from it (eventually agreeing among themselves). What we are doing is building clusters from the different lists of events. Under an optimistic assumption that most nodes are honest we’ll end up with a big cluster of honest nodes and a small number of outliers, representing the cheaters.
However, if we don’t assume the general goodwill of the users, cheaters can coordinate their attack and become the bigger cluster. In this case, since there are no trust mechanisms we cannot decide which cluster represents the honest users and which one the cheaters. As we note that each node can trust only itself, we modify the matching algorithm: each node runs the basic 2-list matching algorithm between its own event list and each of the other nodes’ lists. For each event, we mark if it’s shared among the two nodes or not. At the end, the number of matched events will be a measure of similarity between the two lists. When all the matching will be done, each node will know how many other nodes share the same opinion as itself and thus how many other nodes are honest users or cheaters. This system will just tell how many nodes agree or disagree with a given node.
To make every node know the opinion of all the other nodes, each node repeats the matching algorithm using the list of events of another node (instead of its own) as starting point, and iterates on all nodes. This modified algorithm will require n − 1 iterations to match a list of events with all the other ones. To match every list with all the other ones, if we do not repeat the already made matching’s (for example, when matching node #1 with every other one we match #1 with #2, #3 etc.
 
CHAPTER 3
SYSTEM DESIGN
 
3.1       EXISTING SYSTEM
 

 
3.2       PROPOSED SYSTEM
          It uses matching algorithm, which is an artificial intelligence problem-solving model.

 
3.2.1    ADVANTAGES
 

 

 
The rapid growth of WiFi networks over the past years is due primarily to the fact that they solve several of the intrinsic drawbacks of cellular data services such as GSM/GPRS. These drawbacks are mainly the relatively low offered bit rates and the slow deployment of new features due to several factors such as the large size and the oligopolistic behavior of the operators,
Their willingness to provide homogeneous service, and the huge upfront investment. [2]
 
Therefore, the deployment of wireless networks such as WiFi in unlicensed frequencies makes it possible to envision a substantial paradigm shift, with very significant benefits: much higher bandwidth, deployment based possibly on local initiative, higher competition, and much shorter time-to-market for new features. This may, in turn, pave the way for new types of services. In recent years, wireless Internet service providers (WISPs) have established thousands of WiFi hot spots notably in cafes, hotels and airports. powever, two major problems still need to be solved.
 
The first problem is the provision of a seamless roaming1 scheme that would encourage small operators to enter into the market. This is a fundamental issue for the future of mobile communications.[3]
 
 

Indeed, without an appropriate scheme, only large stakeholders would be able to operate their network in a profitable way, and would impose a market organization very similar to the one observed today for cellular networks; one of the greatest opportunities to fuel innovation in wireless communications would be missed. The second problem is the lack of a good quality of service guarantee for the users.
 
3.3.1  Adding a new node to the network
Node addition to the network can best be explained by use of an example. Consider a building with an existing wireless network maintained by an already present maintenance team. During an intervention, a rescue team enters a building, and, to maintain connectivity, regularly deploys new nodes. Because of the nature of this procedure, the network will have a relaying character. We assume that each node has a maximum of two wireless interfaces [5]. Based on this scenario, the dynamic channel selection algorithm, assigns channels to each link, in such way that, for each node the uplink and downlink connections are configured at different channels.

 
Fig.3.2 Adding a node to the network
 
To reduce interference between non-adjacent links, each newly deployed node will scan the environment and will assign a channel that is not yet in use, to one of its interfaces [4]. The other interface is set to the default channel, as seen in Figure 1. While the underlying character of the network is a mesh topology, due to channel assignment, a relaying network is created. To dynamically assign the channels when a new node is deployed, several messages are exchanged
 
 
 

Fig 3.3 Packet Flow
 
3.4       MODULE DESCRIPTION
The modules contained in this project are as follows:

 
3.4.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 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 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.[6]
 
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 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.
 
3.4.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. 
 

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

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.
 
3.4.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.
 
 
Fig 3.4 Intrusion Detection System flow chart
 
3.5 PROTOCOLS USED      
3.5.1 DYNAMIC SOURCE ROUTING (DSR) PROTOCOL
 
Dynamic Source Routing Protocol is a simple and efficient, reactive
On-demand routing protocol used in multihop wireless adhoc network. DSR makes the network self-organizing and self configuring. Two important mechanisms in DSR are Route discovery and Route maintenance. Nodes discover and maintain routes through the net work using these mechanisms. DSR uses source routing, which allows routing of packets to be loop free and allows caching of routes in nodes for future use.
 
Route discovery is the mechanism by which a node S wishing to send a packet to destination node D obtains a source route to D. Route discovery is used only when S attempts to send a packet to D and does not already know a route to D.
 
Route maintenance is the mechanism by which node S is able to detect, while using a source route to D, if the network topology has changed such that it can no longer use its route to D because a link along the route no longer works. When route maintenance indicates a source route is broken S can attempt to use any other route it happens to know to D, or can invoke route discovery again to find a new route. Route maintenance is used only when S is actually sending packets to D.
 
CHAPTER 4
SYSTEM IMPLEMENTATION
 
The system design components are described below.
4.1       GUI Components
The GUI components are JButton, JLabel, JTextField, JTextArea, JTabbedPane, JScrollPane, and Container. JButton is used to send, clear, hopcount, process, store, back, generate to dataset, receive, Add IDS Entry and More Systems. JLabel is used to display the To, From, Port, Intermediate System No., Intermediate System Names, Send data, Received Data, source IP, Destination IP, Enter new rules in dataset. JTextField, it gets the IP addresses, Port number, Intermediate System No., Intermediate System Names from the user. JTextArea, it is used to send the data and to receive the data. JTabbedPane, in the development environment, there are two JTabbedPane are used. One is anomalous tab and normal tab.
 

Table 6.1 Java Swing class description
4.2 Detailed Description
In the user screen, the user enters the Destination host name. The screen contains five buttons. The buttons are resort, browse, close and two clear buttons.
 
While clicking the browse button, it will open another frame. In this, enter the text file to be sent. In this frame, there are two buttons. The buttons are open and cancel. The Open button is used to select the text file. The Cancel button is used to exit the file selection process. The Entire frame is a Open File Dialog box.
While clicking the send button, the Source name is displayed in the routing table and the destination Host name is verified and displayed as destination in the routing table. While clicking the clear button, it is used to clear the JTextField and the JTextArea.
After the Training process, the resort button will change to the Send button and the coherent nodes message box will display the coherent/neighboring nodes of the source. It displays the source IP address, Destination IP address, the port number, the message and the intermediate system names also.
 
In the Data send process, it contains Routing table with role play of each node. Browse button is used to add the text files to the data send process. The Intruder is already detected by the Training process and the alternate intruder free path is detected by the matching algorithm.
 
The Path display box displays the correct intruder free ‘safe’ paths after the training process. The user can select the appropriate safe path for sending the data if multiple safe paths are available.
 
The Intruder Text field highlights once an intruder is found and this is done by checking the no. of packets received from the coherent nodes. If any node reduces the no. of reply packets below the required limit it is automatically flagged as the intruder as malicious behavior always consumes or swallows up packets. The intruder field displays that specific node which is the intruder and this is multicast to all nodes in the network.
The data flows within the modules are illustrated in the following data flow diagram.

            STEP 1:          
 
 
STEP 2:

 
 
 
 

           
 
 
 
 
 

Fig 4.1 Data Flow for Training process
 

 
 STEP:1 
 

STEP: 2

 
 
 
 
 
 
 
 
 

Fig 4.2 Data Flow Diagram for Data Send process.
 
CHAPTER 5
SYSTEM TESTING
 
Testing is a process, in which software must be tested to uncover as many errors as possible before delivery to the customer. Goal of the testing process is to design a series of test cases that have a high likelihood of finding errors.
 
The main objective of testing in software development cycle includes the following things. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications.

5.1 TESTING TYPES
Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. The data collected through testing can also provide an indication of the software’s reliability and quality. But, testing cannot show absence of defect—it can only show that software defects are present.
 
 Testing is of different types and each one has its impact on the developed software in a different way. They are unit testing, integration testing, system testing and acceptance testing.
 
UNIT TESTING:  It comprises o f a set of tests performed by an individual programmer prior to integration of unit into larger system. Each and every module is tested for its correctness. Finally, all the modules are linked and tested for its integration.
 
INTEGRATION TESTING:  It is a systematic technique for constructing the program structure while conducting tests and detecting errors concerned with the program interface. The object is to take unit tested modules and build a program structure that has been dictated by design.
 
SYSTEM TESTING:  It is conducted at the stage of implementation, which is aimed at ensuring that the system works accurately and efficiently before live operation comments. It makes a logical assumption that if all parts of the system are correct, the goal will be achieved successfully.
 
ACCEPTANCE TESTING:  It is the formal testing that is conducted to determine whether or not the system satisfies its acceptance criteria.
 
5.2       SAMPLE TEST CASE
5.2.1    User Interface testing

 
Table 5.1 User Interface testing
 
5.2.2 Module Testing
 

 
Table 5.2 Module  testing
 
 
CHAPTER 6
CONCLUSION AND FUTURE WORK
 

            
The Distributed Intrusion detection system proposed here detects intrusion by distributed collection of relevant information from the nodes and is also capable of detecting jamming attacks. We also suggested a commercial use of the system, in order to provide a better service to customers: however, this use allows cheaters to come into play. Anyway, their impact is limited: we showed that the operator cannot lower the quality of service under a certain threshold (as without such a system), otherwise unhappy users will take over and get a pay back. We also showed that cheating users cannot push too much; otherwise the system will go towards the total shutdown. We achieve two goals: we detect more attacks and force the operator to give a decent service. We allow cheaters to come into play, but their impact is self-limiting as a working network is needed for them to play. One interesting scenario to analyze would be with cheaters who don’t care about the service, thus don’t stop cheating when QoS gets too low. This might be a sabotage attack from a rival provider to get more market shares. It would also be interesting to add trust and user reputation mechanisms to the system, to improve the matching algorithm
 
6.2       FUTURE WORK
 
Tomorrow's IDS
Due to the inability of NIDS to see all the traffic on switched Ethernet, many companies are now turning to Host-based IDS (second generation). These products can use far more efficient intrusion detection techniques such as heuristic rules and analysis. Depending on the sophistication of the sensor, it may also learn and establish user profiles as part of its behavioral database. Charting what is normal behavior on the network would be accomplished over a period of time.
Strength

 
                                                                       
APPENDIX 1
 
SCREEN SHOTS
    
 
The basic GUI of IDS-Monitor
                                          
 
Multicasting to detect intruder
 

 
Intruder detected by the sender       
 

 
Intruder detected by the receiver    
 

 
Sending data to the destination
 

 
                                                    
REFERENCES                
 
 
1.        Aime M and Calandriello G (2005). “Distributed monitoring of   
           WiFi Channel”.
 
2.        Bellardo J and Savage S (2003). “ 802.11 denial of service                                          attacks:realVulnerabilities and practical solutions”. In proceedings of the 11^th  USENIX security symposium, pages15-18, Washington D.C, USA.
 
3.        Herbert Schildt “Java 2 the Complete Reference”.
 
4.        Raya M and Jacobson M . “Reputation based WiFi deployment”.
           SIGMOBILE Mob.comput.commun.
 
5.        Shannon C.E. and W. Weaver “A system to Detect greedy behavior
           In IEEE 802.11”.
 
6.        Steven Holzner “The Java 2 Black Book”.
 
7.        Zhang Y, Lee W and Huang Y. “Intrusion detection techniques for
           Mobile wireless networks”.
 
Web resources: