DETECTION OF SPECIFIC ATTACKS

So far we have focused on the concept of intrusion detection in general. Potential general approaches that can be used in a MANET environment have also been discussed. In this section we focus on intrusion detection techniques for detecting attacks of specific types. We focus on two types of attacks:

. packet dropping; and . attacks against routing.

We focus on these specific attacks because they are representative attacks for MANET. Due to space constraints we cannot discuss all possible attacks.

5.6.1 Detection of Packet Dropping Attacks

One of the attacks of interest in a MANET environment is the packet dropping attack. In a MANET, nodes typically participate in the routing process and are then responsible for forwarding packets as necessary. In the packet dropping attack, a node does not forward packets that it is supposed to. This is potentially a very damaging attack. Routing protocols in MANET rely on each node to forward packets based on the routes that the node has advertised. If the nodes do not forward the packets, the operation of the network can be significantly disrupted. The impact can be exacerbated when misbe- having nodes are in key locations. Subtle variations of such attacks include the following:

. a node dropping packets randomly with some probability smaller than 1;

. a node dropping packets destined for a specific node (for example a key server) while

forwarding packets destined for other nodes;

. a node dropping packets of a specific type (e.g. high priority traffic or traffic from some key application or packets of a certain protocol) while forwarding other types of traffic.

Such subtle variations of the attack may be particularly difficult to detect. This is because packets may be dropped as they travel the network not only due to malicious reasons but also for valid reasons. For example, when the network gets overloaded, con- gestion may result in dropping of packets. In other cases, the lossy nature of wireless links might result in intermittent packet drops. Random dropping of packets by a node can be easily confused for natural losses thus allowing the misbehaving node to evade detection. Certain techniques have been proposed for detecting packet dropping attacks. The simplest of those approaches relies on the use of promiscuous monitoring. It assumes that some nodes in the network monitor their one-hop neighbors using promiscuous monitoring. Through their monitoring, these nodes can observe whether other nodes are behaving as expected. Statistical detection techniques have to be used to detect malicious packet dropping behavior. This is because some amount of packet dropping may not be due to malicious behavior but rather due to normal (nonmalicious) conditions. Such conditions include the packet losses due to the vagaries of the wireless links, congestion as well as due to node mobility. The limitations of the promiscuous monitoring approach as discussed in Section 5.5.2 can also be addressed by such statistical techniques. The thresholds used in the statistical techniques, however, would be important. If thresholds in the statistical detection scheme are set too low, this technique may result in a large number of false positives. If the thresholds are set too high, malicious users may be able to exploit the detection scheme by dropping packets intermittently while ensuring that the thresholds are not crossed, thereby evading detection.

We now discuss some more elaborate schemes for detecting packet dropping attacks. Rao and Kesidis [101] consider the fact that a node may drop a packet not out of mali- ciousness but because of congestion. The congestion happens because more packets arrive at that node than can be stored in its buffers before they are forwarded. They define a traffic model that can be used for calculating the expected rate of packet dropping due to congestion. A node monitors a suspicious node through promiscuous monitoring and can observe whether the rate at which a suspicious node is dropping packets is con- sistent with the expected drop rate due to congestion as calculated. The calculation assumes a Poisson traffic model and a nonoverloaded network. The reason for the latter assumption is to ensure that the statistics of the interpacket arrival times do not change from hop to hop. In order for the monitoring node to accurately assess the behavior of the suspicious node, it also needs to know the total traffic arriving at the suspicious node. The monitoring node achieves that by asking all the neighbors of the suspicious node to provide the current transmission rate towards the suspicious node. This scheme is shown to perform reasonably well. Unfortunately the applicability of the scheme is very limited due to the assumptions of the traffic model (e.g. Poisson arrival times, underloaded network). The scheme also suffers from the limitations of the promiscuous monitoring as discussed earlier.

The limitations of promiscuous monitoring in detecting packet dropping in this and other schemes can be alleviated by requiring multiple nodes to monitor every node. Each node can coordinate with direct neighbors of a node exhibiting suspicious behavior to crosscheck on the behavior of the suspicious node. Such an approach that compares observation from multiple nodes would make it difficult if not impossible for a node to

exploit the limitations of promiscuous monitoring for evading detection. Allowing nodes to compare their observations also reduces false alarms because multiple nodes will compare their view of the suspicious node’s behavior. Sterneet al.[85] describes such a scheme where reports from nodes monitoring their neighbors promiscuously are propa- gated and consolidated throughout the intrusion detection hierarchy. This results in much more precise intrusion detection with fewer false positives. However, this also causes increased communication overheads.

Anjum and Talpade [102] have proposed a technique that overcomes the limitations of promiscuous monitoring altogether. That technique is called LiPaD (lightweight packet drop detection for ad hoc networks). In this scheme, every node keeps track of each flow that is either originating or terminating, or passing through that node. A flow is defined by the source and destination IP address tuple in the IP header. For each such flow, the node keeps track of the packets the node sends and receives. Periodically, every node reports flow statistics to a coordinator that combines those statistics. The coordinator can then run detection algorithms that take advantage of the exact and actual information about the number of packets each node is forwarding. This is instead of the indirect information based on promiscuous monitoring. The coordinator examines all the data provided by every node and looks for flows where a node is not forwarding as many packets as expected. This can be achieved because the coordinator has knowledge about the number of packets forwarded by each hop.

Figure 5.11 shows one simple such example. In this case, a flow originates on node A and is destined for node D. Packets for this flow are routed through nodes B and C. Each node that is part of the flow (in this case nodes A, B, C, and D), report periodically (let us say every 5 s) to the coordinator (node E) the number of packets they received and trans- mitted for this flow. Node A will only report the packets originating from it (the flow is assumed to be unidirectional), node B will report the number of packets it received from node A and the number of packets it forwarded to node C, and so on.

The coordinator plays a key role in this architecture because it is the one that correlates the statistics provided by the other nodes. Anjum and Talpade [102] conclude that a single coordinator can handle potentially a few hundred nodes. Larger networks would need multiple coordinators.

This scheme has also been shown to work even if some of the nodes are lying (in their reports to the coordinator). For example, let us assume node C in Figure 5.11 received 20 packets but only forwarded 15. It will either need to report to the coordinator that it

Figure 5.11. Simple packet dropping example.

received 20 packets from node B and forwarded 20 packets to node D (even though it only forwarded 15), or it will need to report that it received 15 packets from node B (even though it actually received 20) and forwarded 15 packets to node D. In the first case Node D’s report will contradict node C’s report because node D will report that it only received 15 packets. In the second case node B’s report will contradict node C’s report because node B will report that it sent 20 packets to node C. In either case the coordinator can detect that there is a malicious node and also the pair of nodes in which one is mal- icious. The coordinator may not necessarily be able to detect which of this pair of nodes is malicious. Assuming that there are enough flows in the network and that the number of well-behaved nodes is sufficiently high, the coordinator can figure out which nodes are malicious because there will be multiple pairs of suspicious nodes. The nodes that are common across multiple pairs will be the malicious nodes. For example, let us assume in our previous example that there is another flow originating in node F, traveling through node C and terminating at node G (see Figure 5.12). If node C starts lying in its reports, contradictions will arise with the reports of multiple nodes. Therefore the coordi- nator will be able to clearly identify the malicious node. The scheme is not necessarily foolproof because the coordinator may not have sufficient information in all cases to decide about the lying node. Some such cases are when there are not enough flows, when there are no other nodes in the neighborhood, or when a node decides to drop packets only from a subset of nodes. For example, if node C only drops packets destined for node D and tries to contradict only node D’s reports, then the coordinator will not be able to decide whether node C or node D is lying.

The advantage of this technique is that the detection algorithm does not rely on promiscuous monitoring. The algorithm has its own significant limitations, however. Reports of nodes to the coordinator may contradict each other on account of the lossy nature of the links rather than malicious behavior. In the example discussed earlier, node A may report the correct number of packet that it forwarded to node B, and node B may report the packets it actually received from node A, but the reports may differ. Node B may not receive all of the packets sent by node A. Some of the packets may be lost due to the lossy link between the two nodes. In that case reports from nodes A and B will be inconsistent and may result in a false positive. The scheme tolerates such

losses by allowing for some level of inconsistencies between the reports of nodes based on the expected behavior (i.e. losses) of the wireless link. However, a malicious node may take advantage of such an approach by dropping packets intermittently at a rate below the expected packet loss rate of the link. Of course, this will limit the potential harm that can be caused by that node assuming a reasonably small normal packet loss rate.

Another challenge to the algorithm stems from the fact that nodes in a MANET are not static. The nodes that a flow traverses change constantly. For example node C may tem- porarily move out of range from node B, forcing the flow to traverse a different path. This can create temporary inconsistencies in the reports of nodes. Another limitation of the algorithm occurs when a coordinator becomes a malicious node itself. The current scheme as explained cannot withstand this potentially dangerous attack. Basically, an adversary can defeat this scheme by taking over a single node namely the coordinator. A potential solution is to assign multiple redundant coordinators and require nodes to report to multiple coordinators so that misbehavior of a single coordinator can be detected by a back-up coordinator. Multiple back-up coordinators can increase the resistance of the scheme against coordinators being taken over, but such an approach will also increase the communication overhead of the scheme as nodes have to provide reports to multiple coordinators.

Another limitation of his algorithm is its communication overhead. Each node in the network is required to report to the coordinator at periodic intervals. This results in a fairly significant amount of data being transmitted by the network. This overhead is generated regardless of whether there is an attack or not. For each flow, the flow id, and the number of received and forwarded packets need to be reported. Anjum and Talpade [102] report that for a 100 node network 1450 bytes of reporting data are generated per reporting period. A long reporting period results in lower overhead but causes increased detection latency. The level of overhead could result in potentially con- gesting the coordinator since it receives reports from multiple nodes. As a result, short reporting periods not only increase the overhead but potentially require a larger number of coordinators in the network. Assigning subsets of nodes to each coordinator can reduce the effectiveness of the approach because mobility will often result in a node reporting to a different coordinator creating discrepancies in reports. This also points to the need to design schemes for ensuring that the multiple coordinators work in a synchronized fashion.

Some of the limitations of this scheme can be improved by requiring the full reporting mechanism only if there is a suspicion of the presence of malicious nodes. For example only a subset of nodes (let us say only originating and terminating node on the flow) or a small percentage of well-placed nodes may be required to provide such reports. Once discrepancies start to appear, indicating suspicious behavior, the coordinator may request additional nodes to start providing reports on the flows they participate in. This approach can significantly reduce overhead, especially when no malicious nodes are present.

5.6.2 Detection of Attacks Against Routing Protocols

In this section we focus on detection of attacks against routing protocols. Routing is a key component of MANET and therefore it is important to focus on these types of attacks. Routing protocols in general are prone to attacks from malicious nodes, as discussed in Chapter 4. These protocols are usually not designed with security in mind and are often

very vulnerable to node misbehavior. This is particularly true for MANET routing proto- cols because they are dependent on every node participating in the routing process. Making routing protocols efficient often increases the security risk of the protocol and allows a single node to significantly impact the operation of the protocol because of the lack of protocol redundancy.

In Chapter 4 we discussed some potential approaches for modifying routing protocols (or in some cases proposing new routing protocols) to make them more resistant against attacks. In this chapter we discuss approaches for detecting attacks against traditional routing protocols (that may not have the added security features). Some of the detection schemes discussed are also applicable to secure routing protocols. This is because the secure routing protocols do not offer protection against all possible attacks (as discussed in Chapter 4). In this section we focus on how the typical detection techniques, namely anomaly-based detection, signature-based detection, and specification-based detection (as defined in Section 5.1.1.2) can be used for detecting routing attacks. Although our dis- cussion of attacks and detection schemes are fairly general, we provide examples specifi- cally for OLSR and AODV because they represent two different classes of MANET routing protocols, namely proactive and reactive routing protocols.

5.6.2.1 Detection of Routing Attacks A large number of attacks can be detected (or even prevented) by requiring that routing messages be signed, i.e. authenticated (through individual keys) by each node. Attacks in which nodes send routing messages pretending to be a different node (spoofing) can be easily detected this way. Attacks in which nodes modify routing messages in transit with the intention of misleading other nodes can also be detected easily if all routing messages are signed. The identification of the malicious node(s), however, might not be easy in these cases.

Modifying the routing protocols to require node authentication (as discussed in Chapter 4) is a viable approach but has some limitations. Firstly, it increases the overhead since it increases the size of routing messages and the amount of processing needed to process each routing message. This is because every node needs to sign every routing message it transmits. Further, every node needs to verify the authenticity of the incoming routing messages. Another very significant hurdle with requiring that each node authenticate each routing message is due to the requirement of a public key infrastructure when using asymmetric key-based schemes. As seen earlier, this is not easy on account of the features of a MANET. Hence we need to investigate other approaches to detecting routing attacks. Several techniques can be applied for the detection of attacks against routing protocols. These techniques can be divided into the main categories of anomaly detection, signature detection and specification-based detection. We will discuss next how each of these tech- niques can be applied to the problem of detecting attacks against the routing protocols. These techniques apply to each of the routing protocols such as OLSR, AODV and DSR and potentially other infrastructure protocols used in MANET (e.g. multicast, session management). Our discussion will be general with some examples of how these techniques can be applied to specific protocols. Each of the techniques is of course most effective when it is modified to suit each protocol since it can then leverage the unique characteristics of the protocol.

5.6.2.2 Anomaly-Based Detection As explained earlier, detectors based on this technique try to detect attacks by looking at activities that vary from the normal expected behavior, usually by utilizing statistical techniques. Usually these techniques utilize

thresholds determined during training to detect abnormal activity. In the case of routing there are several measures that can be used for detecting abnormal behaviors. Some examples are as follows:

. Rate of Routing Updates—a node may attempt to send routing updates much more often than required by the routing protocol. This may cause instability in the routes, and may drain other nodes’ batteries and CPU since the nodes have to