Active DES based detection of ARP related attacks
PS 3:PRSP IP(B) MAC(B) IP(E) MAC(E) PS 4:PRSP IP(B) MAC(D) IP(E) MAC(E)
Sequence of ARP traffic if the request packet (sequence 1) is genuine, (i.e., IP(B)-MAC(B) is sent to A by B) is given as follows. For the ARP probe sent by E to verify IP(B)-MAC(B) (packet sequence 2) only B will respond to E with IP(B)-MAC(B) (packet sequence 3). Till Treqtime the IDS will receive only onePRSP(unlike two in case of attack). The IDS finds the response to be genuine (by virtue of only onePRSP).
2.5.2 Detection Rate, Accuracy and Resource Overhead
The metrics for determining efficiency of an IDS are accuracy, detection rate and resource consumption. In case of passive IDSs, resource consumption is in terms of memory and CPU utilization of the system executing the IDS. On the other hand, in case of active IDSs, as extra messages are generated due to probing, bandwidth utilization is another metric of resource consumption.
A test bed (as shown in Figure2.8) has been created for experimental analysis of the proposed IDS. The testbed consists of 6 machines running different operating systems–
Windows Xp, Fedora 16 (as router), Windows 7, Backtrack 5, Ubuntu and Windows 2008.
Machine with Backtrack 5 is the attacker and machine with Ubuntu is configured as the IDS. These machines are connected using a CISCO catalyst 3560 G series switch with port mirroring enabled for the IDS.
The IDS is implemented in C++. For each ARP request or response packet received in the mirrored port, an event is generated by the supervisory controller, which in turn spawns an instance of the detector (Figure2.6) at states1and is added to an active list. On the arrival of the next event (i.e.,RQP,PRQP,PRSP1,PRSP2), it is given to all instances of detectors in the active list to their corresponding present state. Each of them can make a transition on these events, if possible (based on the condition mentioned in Subsection
2.5. Experimentation and Result 51
2.4.2.4). If at any (non-terminal) state, transition to a next state is not possible, attack is declared and the instance of the detector is deleted from the active list (thus releasing memory). Also, all detector instances reaching the terminal state are deleted. In other words, for detecting ARP spoofing, we create many instances of the detector machine. Each machine checks if the trace generated by the ARP event sequence belongs to the language generated by the diagnoser. By deploying attack generation tools Ettercap, Cain and Abel in host D and several scenarios of spoofing MAC addresses are attempted. Different amounts of attack packets (up to 2000) per second are injected in the test bed.
Table 2.6: ARP spoofing statistics
% of packets probed
no. of attacks launched
Detection rate (%)
100 2000 95.12
90 2000 89.76
80 2000 84.47
70 2000 79.08
60 2000 72.43
50 2000 67.91
40 2000 63.55
30 2000 60.36
20 2000 56.29
10 2000 52.57
Table 2.6 illustrates detection rate and accuracy versus percentage of ARP packets for which probe is sent. Obviously, with reduction in the number of probe packets sent, there is compromise in detection rate. Fall in detection rate with reduction in probing occurs because determining spoofed IP-MAC pair (which is not in Spoofed table) can be made only by sending a probe and receiving a response with non-matching MAC address.
However, interestingly the rate of fall in detection rate is lower than the rate of reduction of probing. Specifically, with merely 10% of probe packets, the detection rate is still above 50%. The reason is, over a period of time Authenticated and Spoofed tables are built, where all the genuine and spoofed IP-MAC pairs are stored. These tables can detect attacks using the history and do not require sending of probes; this corresponds to eventDTD. It may be noted that even for 100% probing, detection rate in not 100%, i.e., some false negatives are present. This is because of the cases like attacker spoofing itself etc., which cannot be detected. Among the different attack scenarios generated, 5% are the ones where the
attacker spoofs itself. This number is intentionally kept low, because the scenario where attacker spoofs itself does not have any impact.
0.6 0.7 0.8 0.9
(Mbps)
Bandwidth Utilization
100% Probe 90% Probe 80% Probe
0 0.1 0.2 0.3 0.4 0.5
100 300 500 700 900 1100 1300 1500 1700 1900 2100
Bandwidth (
Number of Attack Packets
70% Probe 60% Probe 50% Probe 40% Probe 30% Probe 20% Probe 10% Probe
Figure 2.10: Bandwidth utilization at different percentage of probing
0 0.5 1 1.5 2 2.5 3
0 200 400 600 800 1000 1200 1400 1600 1800 2000
CPU Utilization in %
Number of Packets
CPU Utilization in %: Proposed IDS versus IDS of Hubbali et. al.
IDS of Hubbali et.al Proposed IDS
Figure 2.11: Comparison of CPU Utilization with IDS of Neminath et. al.
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Memory Utilization in MB
Number of Packets
Memory Utilization(MB): Proposed IDS versus IDS of Hubbali et. al.
IDS of Hubbali et.al.
Proposed IDS
Figure 2.12: Comparison of Memory Utilization with IDS of Neminath et. al.
The accuracy is 100% (i.e., false positives are 0) under all cases because ARP spoofing is detected when (i) the IP-MAC pair being verified is found in spoofed table or (ii) for a probe,
2.6. Conclusion 53
a response arrives with non-matching MAC address. Case (i) comprises IP-MAC pairs already detected to be spoofed and Case (ii) can never happen under normal condition. So, the scheme never sends an alarm for a normal case, resulting in accuracy of 100%.
Figure2.10shows bandwidth utilization due to ARP traffic under different percentages of probing. As probes generate extra ARP traffic (due to probe itself and replies), bandwidth decreases with reduction in percentage of probing.
Figure 2.11 and Figure 2.12 (red line) show CPU and memory utilization (at 100%
probing), respectively when running the IDS in Intel Core-2-Duo host with 2 GB RAM. In these cases also, CPU utilization and memory utilization fall with reduction in percentage of probing; as the trends are similar to that of bandwidth, we do not present them explicitly.
Figure2.11and Figure2.12also compare CPU and memory utilization of the proposed IDS with that of [17]. As many instances of the detector may be spawned, memory and CPU utilization of the host executing the IDS is in tolerable limit and does not over burden the host. This fact is illustrated in Figure2.11and Figure2.12.
Bandwidth utilization of both [17] and the proposed IDS is similar. This is because both the IDSs are active thereby sending probes for IP-MAC pairs whose genuineness is not known. For each probe there is one or two responses based on attack or normal condition.
So extra ARP traffic is similar for both the IDSs i.e., similar bandwidth requirement.
Regarding resource overhead of the proposed scheme, it may be noted that CPU utilization, memory utilization and bandwidth utilization, even at 100% probing, is minimal compared to resource available in modern infrastructure.
2.6 Conclusion
ARP spoofing is a major attack using which other attacks like MiTM, DoS etc. can be launched. In this chapter we proposed an active mechanism to detect ARP based attack using active DES based IDS. The scheme uses an active probing mechanism based on ARP requests and responses, so it does not violate the principles of network layering architecture.
Further, this being a software based approach, does not require any additional hardware or software patching in the hosts. The scheme being based on formal state-transition modeling, it is verifiable.
This active DES technique is useful in detecting attacks where normal and attack traces
can always be differentiated using network events (ARP requests probes in this case) which are controllable. However, there are certain attacks where some of the network events required to distinguish normal traces from attack traces may be uncontrollable. For example, in ICMP based attacks, sending of probes and receiving their responses depend on congestion in the network. As congestion is an uncontrollable event, so sometimes traces under attack condition cannot be differentiated from the normal condition. This leads to the DES detector to reach some attack/normal uncertain state.
This motivated us to explore the possibilities of detecting ICMP based attacks by diagnosing only those traces where the detector leads to some attack/normal certain states, leaving out the paths where it is uncertain; this is termed as partial diagnosis. In the next chapter we propose a partial DES diagnosability approach for developing an IDS for ICMP attacks.