Survey on Defenses Against the ARP Cache Poisoning

Man-in-the-middle Attack

Raquel Alvarez Daniel E. Krych*

rva5120@cse.psu.edu dek5156@cse.psu.edu

Introduction
Nowadays, wireless networks are available everywhere. One can connect to the internet in a
matter of seconds at home, at the airport, or even on an airplane. Although convenient, access
to the internet on a given network is not as safe as most like to believe. One of the simplest
attacks on a network is ARP Cache Poisoning, which allows the attacker to intercept the
communication between two devices. This means that the attacker can eavesdrop on the traffic
sent from the device to the router. This can be dangerous since even popular applications,
such as those used on mobile phones, have been shown to transmit sensitive information
unencrypted [1]. In this paper, we will compare the two main defense approaches to protect
against these type of attacks, Prevention Defenses and Detection Defenses. We survey
defenses from both of these categories, and classify them within each, discussing their
advantages and disadvantages. We then design and setup a testing environment to implement,
evaluate, and compare several of these defenses, as well as provide our code for the defenses
we implemented ourselves, and the detailed instructions on the setup for those available online.

What is ARP?
Address Resolution Protocol (ARP) is a protocol used among nodes on a Local Area Network
(LAN) to map IP addresses to MAC (Media Access Control) addresses [3]. A device must have
a network card installed to be able to connect to the LAN. Each card is assigned an unique
MAC address by the manufacturer, which is a physical serial number that does not change
throughout the life of the card, but could be spoofed through software. In order for a devices
network card to reach another devices network card, the originating device must address the
destination network card using its MAC address. ARP messages are used for devices to share
their MAC addresses with the rest of the nodes on the network.

Lets further explain how the ARP protocol works through an example. Lets assume we have a
wireless home network that has a router (Host B), a phone (Host C), and a laptop (Host A)
connected to it as shown on Figure 1.


Figure 1: ARP Broadcast and ARP Reply in basic ARP protocol (reproduced from [2])

Each of these devices was assigned an IP address to it (potentially through DHCP), which
happened when each device joined the network. At this point, devices can communicate with
each other by sending packets across the network using IP addresses. IP addresses are only
understood at the Network Layer on the network stack. For a packet to continue through the
wire/air to the physical device its destined to go to, we must use a physical address instead [3].
This physical address of a device is the MAC address.

In our example, we want our laptop to communicate with the router. When the laptop joins the
network, it has no previous record of the MAC addresses of the other devices. So when the
laptop first wants to communicate with the router, it sends an ARP broadcast message on the
LAN requesting the MAC address for the IP address of the router. If everything works as it was
designed to, the phone ignores the message, and the router sends a response back to the
laptop with its MAC address. Once the laptop receives the MAC address of the router, the
laptops network controller encapsulates IP packets to generate frames at the Data Link Layer,
and sends those out to the destination MAC address on the LAN. This happens through the
Physical Layer by sending a stream of bits through a medium (which could be a cable or a
wireless medium such as radio waves).

When the laptop received the message with the routers MAC address, the laptop added an
entry to its local ARP Cache table. This entry is a mapping of an IP address to a MAC address.
So the next time the laptop needs to communicate with the router, it can directly use its stored
MAC address to generate the frame.

The ARP protocol, however, was not designed to prevent anyone from answering to the
broadcast message, even if they are not owners of the requested IP. In the next section, we will
 Figure 2: ARP Cache Poisoning Man-in-the-middle Attack (reproduced from [2])

describe how to exploit the vulnerability of the ARP protocol that enables the attacker to perform
a Man-in-the-middle attack.

The Attack: What is ARP Cache Poisoning

Often times, an attacker will try to intercept network traffic travelling in between two hosts. To do
this, the attacker can exploit a vulnerability in the ARP protocol that allows them to perform a
Man-in-the-middle attack. This vulnerability resides on the fact that ARP messages are
independent from each other, and they are not authenticated by the receiving devices [2].
Therefore, any device on the LAN can send an ARP message to any other device.

Lets take the example from the previous section, in which the laptop and the router on the
same LAN were communicating. Assume an attacker, having access to the phone, decides to
perform a Man-in-the-middle attack. The attacker can send an ARP reply to the laptop with the
IP of the router and the phones MAC address. This will cause the laptop to update its ARP
Cache Table, and now think that the messages intended for the router will require the MAC
address of the phone. This is called ARP Cache Poisoning. At the same time, the attacker can
also send the ARP reply message with the IP of the laptop and the MAC address of the phone
to the router. The router then receives this message and updates its ARP Cache Table as well.
Figure 2 shows how the phone (Host C) performs the ARP Cache Poisoning attack described
on this example.
Now the attacker has successfully performed a Man-in-the-middle attack. It is worth to note that,
the attacker should also set up the phone to forward the messages from the router to the laptop,
and vice versa. Otherwise, the communication between the router and the laptop will not be
successful.

To be able to perform this attack on an actual device, there exists a set of tools that are open
source or described in research papers that are available to the attacker/researcher. In this
survey, we used Ettercap [4]. Ettercap is an open source versatile network manipulation tool
that allows anyone to perform Man-in-the-middle attacks [5]. Although other tools exist, such as
linuxs arpspoof [6], we decided to use Ettercap because it was easy to install and provided a
GUI that clearly showed the process. However, for the defenses against this attack, we will
highly consider solutions found in research papers and a few open source solutions. We
assume that solutions that appear on a journal or publication have been carefully designed
against a wide variety of attacks, and therefore are stronger defenses than open source
solutions. This, however, might not always be the case. For detailed instructions on setting up
an ARP Cache Poisoning attack using Ettercap, please refer to Appendix A.

In the following section, we will discuss available defenses for this type of attack, which is an
ongoing research problem.

Defenses: Tools and Techniques

Prevention Techniques and Enhancements to the Protocol
Throughout the years, researchers and members of the internet community have designed
software that is able to detect ARP Cache Poisoning attacks and, in some cases, prevent it or
defend against it. Below is a series of tools and techniques, which can be broken down into the
classifications shown in Figure 3. As we will discuss in the next sections, each of these classes
of defenses have their own advantages and drawbacks.

Prevention Defenses:
The Prevention Defenses surveyed include the Permissions-based solution Static-Arp,
and the Authentication-based solutions S-ARP and T-ARP. These solutions are aimed at
preventing the ARP Cache Poisoning MITM attack from occurring, which solves the
security issues with the basic ARP protocol, and puts users and security administrators
minds at ease. But, these solutions come at a cost, typically entailing a large amount of
overhead for the setup, maintenance, and use. For instance, several of these defenses
drastically alter or add onto the original ARP protocol, and these solutions would need to
be widely adopted to be successfully implemented. These costs are both in performance
of the protocol, time, and system resources and capabilities.
 Figure 3: Classification of Surveyed ARP Cache Poisoning Defenses

Permissions:
Static-ARP: Static ARP is the vanilla solution for this attack. This solution
involves the network administrator in charge of all the devices connected to the
network to manually enter and update the IP to MAC address mapping table for
every device. Thus, this is a permissions-based solution, where the underlying
ARP protocol is altered, and only the network administrator has the permissions
to modify the mapping tables. In this scenario, we find that the kernel will ignore
all ARP responses for the specific IP address used in the entry [8]. This prevents
any attacker from accessing the cache, and therefore prevents any poisoning.

Authentication:
S-ARP: Secure-ARP is an enhancement to the ARP protocol. In order to solve
the problem presented by the vulnerability in the ARP protocol, which allows
attackers to send ARP Reply messages to poison ARP caches, S-ARP adds
integrity and authentication techniques to the existing protocol. As described in
the original paper, an additional header is inserted at the end of the protocol
standard messages to carry the authentication information [9]. The
authentication is done using PKI certificates, where a trusted device acts as a
Certificate Authority and issues certificates to the rest of the devices on the
network.

T-ARP: Ticket-based ARP is another enhancement to the ARP protocol. The

TARP protocol has a Local Ticket Agent (LTA) that assigns a ticket to every
device in the network at the time of the device receiving an IP address (either
statically or via DHCP dynamically). When a device broadcasts an ARP request,
the device whose IP address matches the request, sends back an ARP reply as
 well as its ticket. The requesting device then validates the ticket using the public
key from the LTA, and if the signature is valid, the new binding is accepted.
Otherwise, its rejected [10].

Prevention and Detection Defenses:

One of our surveyed solutions, the ICMP-based Secondary Cache approach, is both a
Prevention and Detection Defense. The authors claim that the ARP Cache Poisoning
attack is prevented by removing any duplicate entries of MAC addresses or IP
addresses in the ARP table, using their technique [2]. Similar to the other Prevention
defenses discussed, this solution entails additional steps to the basic ARP protocol, and
thus the same pros and cons discussed earlier.

ICMP-based Secondary Cache: This solution involves every device on the LAN having
a secondary IP-MAC mapping cache. This cache is based on an ICMP (Internet Control
Message Protocol) echo/reply message communication in between devices. The ICMP
message is used to validate the new ARP reply received by a device. In this solution,
when the attacker sends an ARP reply to the victim, the victim responds with an ICMP
message to the attacker. The attacker receives the message up to the Data Link Layer,
since the MAC address in the reply corresponded to the attacker. However, the
attackers network layer will drop the packet, because the packets IP address
corresponds to the router, not the attacker. This assumes that the attacker has no
control over the network layer protocol and does drop a packet not meant for them.
When the victim doesnt get the echo reply, it doesnt update the secondary cache, and it
renews the previous static entry (if any) on the ARP cache for another 10 minutes [2]. Its
worth noting that, on this paper, its not clear the reasoning behind choosing 10 minutes
for the static entry to live in the cache. We further discuss this solution and our
implementation on the evaluation section.

Detection Defenses:
The Detection Defenses surveyed include Snort NIDS, and Arp_cop, as well as E-SDE
which additionally provides a Mitigation solution, to mitigate the attack. These solutions,
compared to the prevention solutions, do not alter the existing ARP protocol, but instead
aim at detecting attacks, and either providing enough information for the system
administrator to act and stop the attack, or mitigating the attack on its own. When the
system administrator is notified of a possible attack, information is provided, such as the
MAC address and IP of the attacker, and the MAC/IP of its target(s). A quick solution
researchers discussed was blocking the attackers MAC address to stop, and prevent
future (identical) attacks from occurring. These defenses dont require as much overhead
to setup, maintain, and use as the Prevention Defenses, but they do require some, and
additionally are ran often, or all the time in the background to detect attacks.
Additionally, some of these detection defenses may fail, leading to attacks going
undetected, and users being put at risk. This is unlike what would occur with Prevention
defenses, which would block the attack before it could begin.

Snort NIDS: Snort is a commonly used Network Intrusion Detection System (NIDS) /
Network Intrusion Prevention System (NIPS) ran on networks to monitor traffic by
filtering with a list of predetermined rules, and generating alerts when a match is found. It
is an open source tool that is capable of real-time traffic analysis, as well as packet
logging for later analysis. Snort has a built-in arpspoof preprocessor, with rules to detect
and alert on arp cache poisoning [14]. According to the Snort manual, the arpspoof
preprocessor decodes ARP packets and detects ARP attacks, unicast ARP requests,
and inconsistent Ethernet to IP mapping [15]. Thus Snort, ran in intrusion detection
mode, is capable of detecting ARP cache poisoning attacks, and provides an alert
system to notify the system administrator. When the system administrator learns of the
attack, they can block the MAC address of the attacker, and prevent that address from
transmitting any more packets on the network. This would then prevent the same exact
attack (from the same attacker) in the future, such as if they used scripts to execute the
attack [16]. Bijral et al. explain the setup of Snort NIDS for ARP cache poisoning
detection, and evaluate its detection capabilities, concluding that is successfully detected
and then mitigated the attack by blocking the mac address of the attacker. They also
tested the performance of Snorts detection capabilities by increasing the number of
hosts being spoofed at a time (up to 5 hosts), and found Snorts defenses to be
unaffected and still successful [16].

Arp_cop: ARP_cop is a plugin that can be used with Ettercap. ARP_cop is a

surveillance tool that allows the user to see any conflicts on IP-MAC mappings. Ettercap
displays the conflicts and gives the victim an opportunity to understand the conflict and
take action, if necessary. ARP_cop is not a research developed tool, it is an open source
tool that is available as a plugin with Ettercap [4]. More details will be discussed further
in the evaluation section.

Mitigation:
E-SDE: E-SDE, Enhanced Spoof Detection Engine, is an modified version of the
Spoof Detection System [11]. The author defines three possible classifications of
an attacker: weak, intermediate and strong. A weak attacker can send ARP
replies to the victim, but cannot modify its network layer protocol. An intermediate
attacker can send ARP replies to the victim, but it can also modify its network
layer protocol to respond to messages intended to other IP addresses. An
advanced attacker can do everything that an intermediate attacker can do, as
well as specify to which IPs it will send reply messages when the intended
receiving IP is not of the attacker. The solution proposed is able to use each type
of attackers characteristics to beat the attacker at their own game. Below is the
solution for each type of attacker:
 Weak Attacker: Assuming that the weak attacker cannot send ICMP echo
response messages back to the victim, the victim can simply send an
ICMP packet to the destination specified by the ARP reply of the attacker,
and wait for a response. Because the attacker can only respond to itself,
the victim wont receive a response and will drop the ARP reply.
Intermediate Attacker: In this case, the victim sends two ICMP packets to
the attacker. One requesting an echo response for the ARP reply
specified destination, and one requesting an echo response for the victim
itself. An intermediate attacker will send a response regardless of whether
or not the IP belongs to them. If the victim receives two responses, the
ARP reply is dropped.
Strong Attacker: The paper describes this scenario as one that can be
detected but not prevented. In this case, when the victim receives an ARP
reply, the victim sends a broadcast ARP request for that IP address. The
victim then expects to receive two replies, one from the legitimate host
and one from the attacker. However, at this point, its unknown to the
victim which is which. The victim then sends the same two ICMP
messages described earlier to both the attacker and the benign device. If
the victim receives a response, then the victim knows the attacker is
somewhere on the LAN, but the victim does not know where.
Its necessary to mention that it is not clear on the paper specifically which SDE
is being modified. Also, the author mentions that if we add more power to
attackers in terms of their ability to customize protocol stack, then in such cases
also our proposed technique is able to detect and identify the attacker, however,
in the case of the stronger attacker, the algorithm is can detect the attacker, but
not identify it. We discuss our implementation of this algorithm and our results in
the evaluation section.

In this section, we described some of the most common defenses against ARP Cache
Poisoning discussed in literature, as well as open-source tools used by the network security
community each and every day. Prevention Defenses require additional overhead up front since
they alter the basic ARP protocol, and must be widely accepted and adopted to be successfully
implemented. But if one of these defenses is adopted, it would secure the ARP protocol and
just require some additional setup and maintenance. Detection Defenses require additional
overhead since they are most likely ran in the background 24/7, but are much easier to deploy,
and have been shown to be successful at identifying attacks and aiding in the mitigation of
them. Since research into Prevention and Detection systems is ongoing, it seems that all of the
proposed solutions are not completely satisfactory in some way or another, but are getting
better, and we are working towards a future where ARP, or a future protocol isnt ridden with
security issues. In the next section, we will discuss our evaluation of the last four mentioned
defenses.
Bonus: Evaluation of Defenses

Metric Point Description

Attack detected 0 for not detected, 40 for detected

Time to detect Starting at 10, -1 per 30sec to detect, rounding up

Provides an alert system 0-5 scale with 0 being no system, 5 being detailed

Attack mitigated 0 for not capable, 10 for successful

Capable of helping prevent repeated attacks 0 for no, 10 for yes

Ease of implementation/maintenance 0-10 scale with 10 being simple

Cross-platform support 5 per OS supported

Overall Score 100

Table 1: Defense Evaluation Metrics and Point Descriptions (Highest score = 100)

We will now proceed to show the evaluation of the defenses discussed in the previous section.
Out of the seven different solutions described, we will focus on the bottom four: ICMP based
Secondary Cache, E-SDE, Snort NIDS and ARP_cop. We were unable to evaluate S-ARP or
T-ARP, due to the fact that both solutions required access to hardware and code that was not
available to us at the time of evaluation. These solutions were both heavily tested and
compared in the T-ARP paper [10]. Additionally, we did not evaluate Static ARP because it has
been integrated into the implementations of ICMP based Secondary Cache and E-SDE. For
instructions on how to implement these solutions, please refer to A
ppendix B.

Our testbed environment seen in Figure 4 consists of two laptops running MAC OSX, and a
router. Each device has their own IP/MAC addresses. We decided to run real experiments in a
testbed environment, instead of running simulations, in order to achieve the most realistic
results and learn the most from the project. In each experiment, one laptop acted as the
attacker, while the other acted as the victim/target. Additionally, the attacker used Ettercap for
the ARP Cache Poisoning MITM attack, and the victim/target laptop ran the defense solution.

For our evaluation of these defenses, we developed the weighted criteria system seen in
Table 1. The higher the overall score, the better the defense system, with the highest possible
score being 100. First, we will present an individual detailed discussion for each of the solutions
 Figure 4: Our Testbed Environment Consisting of Two
Laptops running MAC OSX and a Router

and how they performed. Then, we will compare the solutions and discuss their strengths and
weaknesses.

ICMP-based Secondary Cache

To implement this solution, we used the Scapy python module [12]13][19]. We set up a
mapping structure that functioned as a cache, and we manually added the IP-MAC
bindings corresponding to our ARP cache table at the time of the experiment. Due to
time constraints we implemented the above, deciding against dynamically initializing the
secondary cache using arp -a results, but this improvement would be future work. Once
the secondary cache is initialized, we listen for packets incoming into our devices
network card. If the packet is an ARP Reply, we send an ICMP echo message to the
IP/MAC address that sent us the ARP Reply. If we dont receive a reply, we assume its
an attacker, and we update the ARP cache table with the previous mapping (that we had
stored in the secondary cache). Otherwise, we treat the ARP Reply as a legitimate
mapping, and we update the secondary cache instead.

Unlike the E-SDE solution, the authors of this paper do not mention the assumption that
the attacker falls under the weak category. This means that, only attackers that drop
the ICMP echo packet sent back to them and dont produce a response, can be detected
and prevented. This turned out to be a limitation when using Ettercap, which was not
detected. Unless the attacker is weak, this solution does not perform well.

Because of the limitations and setbacks mentioned, the ICMP-based Secondary Cache
 solution was unable to detect the attack. If an attack had been detected, a detailed alert
system would have provided the necessary information for the user to mitigate the
attack, such as blocking the attacker from the network. Overall, the ICMP-based
Secondary Cache defense received a score of 34/100.

E-SDE
Similarly to the previous solution, we also used the Scapy python module for this
implementation [12][13][19]. Following the description of the paper, we listen for packets
on the network addressed to our device. When the packet is an ARP Reply, we send an
ICMP echo message to the IP/MAC address combination on the ARP Reply. If we dont
receive a response, we alert the user that a weak attacker has been detected.
Otherwise, we send another ICMP echo message, but this time we use the MAC
address of the ARP Reply and the IP address of our own device. If we receive a reply,
we know that the ARP Reply came from an intermediate attacker. If we do receive a
reply, we take one more step. We send an ARP Request broadcast message to the
LAN. According to the paper, if we get multiple responses, we can say that the attack is
taking place but we cannot say which MAC corresponds to the attacker. In our
implementation, however, we had to adapt to the limitations of Scapy. Scapys ARP
messaging might receive more than one answer, but it only keeps one. We noticed that
the answer taken as a response to the request was the answer sent from the router, not
the attacker. Therefore, by comparing the original MAC address from the original ARP
Reply received and the MAC address from this last ARP Reply, we were able to detect
the attacker. Accidentally and due to Scapys inner workings, we are able to determine
who the attacker was, but this is not part of the papers description of the solution.

The described mitigation technique on the paper is as follows: whenever confusion

arises related to IP addresses to MAC mapping then ARP Request packet is sent to
respective MAC address and mapping gets resolved using the response of the probe
packet. However, this assumes that the implementation intercepts the ARP Reply. For
our experiment, we were not able to intercept the ARP Reply packets, only detect them.
Therefore, because we were not able to implement the mitigation part of the solution, we
added an alerting system for the user instead.

E-SDE was able to detect that Ettercap was attacking the machine as a strong
attacker, in a reasonable amount of time between 30 seconds and 1 minute. The alert
system provided is detailed, but we were unable to mitigate the attack due to the inability
of intercepting the ARP Reply packets. Enough information is provided to an end user to
mitigate the attack. E-SDE received an overall score of 81/100.
 Snort NIDS
Setting up Snort on Mac OSX was more complicated than expected. The tool depends
on a multitude of directories and files which the user must create in their system, as well
as environment variables which must be configured. We leveraged two guides to setup
Snort properly in Mac OSX [17][18]. Once the basic system was setup, we configured
Snort to process and alert on ARP Cache Poisoning attacks following the instructions
laid out by Bijral et al. [16]. Snort immediately detected the attacks within a second,
which was very impressive. The alert system outputted a timestamp along with the alert:
[**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**].

According to Bijral et al., after the user observes this alert, they can view the Snort log
file outputted during this time to find more detailed information, such as which MAC
address is claiming to own an IP already belonging to another [16]. In our experiment,
the Snort log file did not provide this detailed of information, but we could clearly see the
ARP messages transmitted on the network, and the attacker (by MAC Address and IP)
which was repeatedly sending them. Thus a user could use this information to block the
MAC address of the attacker, and update their ARP tables, preventing an identical attack
from occurring in the future. Snort received an overall score of 84/100.

ARP_cop
ARP_cop is an Ettercap plugin. This plugin comes installed with Ettercap and it is ready
to use after loading Ettercap, starting unified sniffing, and generating a list of scanned
hosts. Immediately after ARP_cop starts running, it identifies the attacker and the IP that
it is pretending to be.

ARP_cop was able to detect Ettercap as a source of attacks, which leads us to believe
that it can detect the three types of attackers mentioned previously. The alert system
provided was very detailed and informative, and would similarly provide a user with
enough information to mitigate the attack as discussed in our evaluation of Snort NIDS.
Although it is possible to run Ettercap on Windows, it is not supported. Even with this
limitation, Arp_cop had an overall score of 85/100.

Comparison of Evaluated Defenses

Overall, all of the defenses performed well other than ICMP-based Secondary Cache. This
defense assumes that the attacker will drop an ICMP packet that arrives to them (to PHY and
DLL via MAC) but has the IP address of someone else in the packet. This defense was unable
to detect the attack, and thus performed poorly. The other three defenses, E-SDE, Snort NIDS,
and Arp_cop all had overall scores within 4 points of each other, and all performed very well
based on our criteria. Each of them detected the attack within a minute, with Snort NIDS and
Arp_cop detecting in less than 30 seconds. When a Detection Defense can identify and report
and threat in such little time as this, it provides adequate time for the user to take action. These
actions could also be scripted, which would allow the attacks to be mitigated almost immediately
after detection, thus making a Detection Defense perform closer to a Prevention defense, within
the additional disadvantages which come along with this class of defenses.

Both the ICMP-based Secondary Cache and E-SDE defenses did not provided code for their
approaches. Therefore, we had to implement these ourselves, which greatly reduced their Ease
of Implementation / Maintenance scores. Similarly, although Snort NIDS is a downloadable tool,
it was a bit challenging to get running on MAC OS X, which is reflected in its scores. Every
defense except for Arp_cop provided Cross-Platform support (Linux/OSX/Windows) across
each of the three main operating systems. Arp_cop only missed this due to its lack of support on
the Windows Operating System, although it is possible to implement it on Windows. Thus, both
Snort NIDS and Arp_cop are widely available to users.

In Table 2 we provide our overall results for each of the four defenses tested and their scores
according to our evaluation metrics and the experiments we conducted in our testbed
environment. We then provide a visualization of the overall score comparison in F igure 5.

ICMP-based Secondary Cache Snort NIDS

Attack detected: 0 Attack detected: 40
Time to detect: 0 Time to detect: 10
Provides an alert system: 5 Provides an alert system: 3
Attack mitigated: 0 Attack mitigated: 0
Capable of helping prevent repeated attacks: 10 Capable of helping prevent repeated attacks: 10
Ease of Implementation / Maintenance: 4 Ease of Implementation / Maintenance: 6
Cross-Platform support (Linux/OSX/Windows): 15 Cross-Platform support (Linux/OSX/Windows): 15
Overall Score: 34 Overall Score: 84

E-SDE Arp_cop
Attack detected: 40 Attack detected: 40
Time to detect: 9 Time to detect: 10
Provides an alert system: 5 Provides an alert system: 5
Attack mitigated: 0 Attack mitigated: 0
Capable of helping prevent repeated attacks: 10 Capable of helping prevent repeated attacks: 10
Ease of Implementation / Maintenance: 2 Ease of Implementation / Maintenance: 10
Cross-Platform support (Linux/OSX/Windows): 15 Cross-Platform support (Linux/OSX/Windows): 10
Overall Score: 81 Overall Score: 85

Table 2: Defense Evaluation Results

Overall, Arp_cop performed the best with a score of 85/100. Snort NIDS placed second with a
close score of 84/100. Next, E-SDE placed third with 81/100. Finally, in last place ICMP-based
Secondary Cache scored 34/100. Next, in Figure 6, we provide a comparison in the usability of
the defense, which we define as accounting for (1) Ease of Implementation / Maintenance, (2)
Cross-Platform support, and (3) Provides alert system. We find each defense to be very close
in this comparison, with Arp_cop providing the best usability of 25/30, followed by Snort NIDS
tied with ICMP-based Secondary Cache with 24/30, and finally E-SDE with 22/30.

Figure 5: Overall Scores of Defenses Evaluated

Figure 6: Usability Scores of Defenses Evaluated

Conclusion
In this report we explained and discussed the vulnerabilities of ARP, how it can be exploited,
and the top defenses proposed throughout the research and open source communities in recent
years. We detailed and implemented a variety of defense solutions to ARP vulnerabilities, each
with their own strengths and weaknesses. We also classified these defense solutions based on
their approaches. We discussed three Prevention Defenses: Static-Arp, S-ARP, and T-ARP,
one Prevention/Detection Defense: ICMP-based Secondary Cache, and three Detection
Defenses: Snort NIDS, Arp_cop, and E-SDE. Several of these defenses require a large amount
of overhead to setup and maintain, as well as contain limitations in their capabilities. In general,
the Prevention Defenses alter the basic ARP protocol, whereas Detection Defenses sit on the
network in the background aiming to identify and help mitigate attacks. We implemented four
defenses and tested them in our real testbed environment of two laptops and a router. We
developed evaluation metrics in order to grade each defense and compare them to each other.
Three of the four defenses implemented successfully detected the ARP Cache Poisoning MITM
attack, and provided enough information to help mitigate it and defend against future identical
attacks. Overall Arp_cop performed the best with a score of 85/100, followed by Snort NIDS
with 84/100, then E-SDE with 81/100, and finally ICMP-based Secondary Cache with 34/100.
These results show the efficacy of these tools in detecting and helping mitigate real-world
attacks on ARP, and thus aiding in network defense as a whole.

Despite ARP being used by networks for over three decades, ARP Cache Poisoning is still a
vulnerability today, and a practical, permanent defense for this is attack is still an open problem.
The protocol, developed in the early 1980s, was not intended to handle nefarious devices on the
network. ARP is a standard across networks throughout the world, and even though the protocol
has a huge vulnerability, it would be nearly impossible to replace. As Lootah et al. point out,
resource constrained devices and already computationally loaded hosts cannot afford to
budget large amounts of resources for ARP security. Additionally, any solution that would
demonstrably change the performance profile of ARP will not be adopted [10].

Fortunately, over the past decade advancements in ARP security have been developed and
proposed in both the research and open-source communities. Although we have yet to identify
a clear-cut solution, more interest into the topic can be seen in recent years, and networks have
been managing these insecurities in the meantime. A variety of open-source tools are
available online for systems to detect and help mitigate ARP Cache Poisoning, and researchers
have compared these tools, as well as developed their own. We believe that a combination of
both a Prevention Defense and a Detection Defense could be the best way to tackle the
vulnerabilities still present in ARP today. The Prevention Defense needs to be simple, and able
to be widely adopted and implemented with minimal alterations to ARP. If this system itself is
attacked or fails, the additional Detection Defense would be able to detect and mitigate the
attack before it escalates. Although its taken a long time, both researchers and the open
source communities are moving in the right direction, and a perfect solution to ARPs
insecurities, whether a Prevention Defense, Detection Defense, or combination, may be just
right around the corner.
References

[1] D.E. Krych. An Exposure of Android Social Media Applications and the Data ISPs can
Collect. Diss. The Pennsylvania State University, 2017.
[2] N. Tripathi, B.M. Mehtre. An ICMP based secondary cache approach for the detection and
prevention of ARP poisoning. 4th IEEE ICCIC, 2013.
[3] D. Plummer. An Ethernet Address Resolution Protocol, RFC 826. Internet Engineering Task
Force, November 1982.
[4] A. Ornaghi and M. Valleri. Ettercap. http://ettercap.sourceforge.net (March 31, 2004)
[5] D. Norton. https://www.sans.org/reading-room/whitepapers/tools/ettercap-primer-1406 (April
14, 2004)
[6] D. Song. https://linux.die.net/man/8/arpspoof
[7] C. Leres. https://linux.die.net/man/8/arpwatch
[8] A. Lockhart (2007). Network security hacks. O'Reilly. p. 186. ISBN 978-0-596-52763-1.
[9] D. Bruschi, A. Ornaghi, and E. Rosti. S-ARP: A Secure Address Resolution Protocol.
ACSAC, 2003.
[10] W. Lootah, W. Enck, and P. McDaniel, TARP: Ticket based Address Resolution Protocol.
ACSAC, 2005.
[11] P. Pandey. Prevention of ARP spoofing: A probe packet based technique. IEEE IACC,
2013.
[12] Biondi, Philippe. "Scapy." http://www.secdev.org/projects/scapy/
[13] J. Seitz (2014). Python Programming for Hackers and Pentesters. No Starch Press.
ISBN-13: 978-1-59327-590-7
[14] Snort. https://www.snort.org/
[15] SNORT Users Manual 2.9. Martin Roesch; c19982003. Chris Green; c2001 2003.
Sourcefire, Inc.; c20032013. Cisco and/or its affiliates. All rights reserved; c20142016.
http://manual-snort-org.s3-website-us-east-1.amazonaws.com/
[16] Bijral, Rajneet Kaur, Alka Gupta, and Lalit Sen Sharma. "Study of Vulnerabilities of ARP
Spoofing and its detection using SNORT." International Journal 8.5 (2017).
[17] Amber. Install snort on Mac OSX. http://macappstore.org/snort/
[18] Arkowitz. macosx_snort_install. http://deepnode.us/apps/macosx_snort_install.pdf
[19] Woods. Building Network Tools with Scapy.
https://thepacketgeek.com/series/building-network-tools-with-scapy/
[20] B. Carrera Ettercap https://openmaniak.com/ettercap.php
Appendix A: ARP Cache Poisoning Tutorial

In this section, we will give a step-by-step tutorial on how to setup a scenario in which one of
your devices on your own personal LAN fools another one of your devices on the same network.
The victim device now believes that the attacker is the router, and sends all its traffic through
the attacker instead of sending it directly to the router. Then, we will implement two monitoring
techniques (one from an open source tool available online, and another one presented by a
group of researchers).
Even though we do not describe it here, one (as the attacker) could also capture this traffic and
further analyze it or perform other types of attacks. We highly encourage the reader to perform
other experiments beyond this one.

Disclaimer:
ARP Poisoning should never be performed on a network where owners of devices connected to
it are not aware of the fact that the experiment is taking place. You must not ARP Poison
anyone without their consent. Please use the information in this document at your own risk.
This information is provided for educational purposes only.

Requirements:
1. Two laptops
2. A router
3. LAN where all three devices can connect
4. Internet access for downloads

Setting up ARP Cache Poisoning Scenario

To setup the ARP Cache Poisoning attack, we will use Ettercap [20]. Below are the instructions
on how to install it and use it for this purpose.

Installing Ettercap
We will be performing this experiment on a Unix machine, which allows us to install Ettercap.
However, if you would like to do this in other operating systems, you should find the equivalent
tool for your OS.

Ettercap is a tool that allows us to perform MITM attacks. It also has extensive support to
perform ARP Poisoning attacks directly, which works very well for our experiment.

To install Ettercap, you may use MacPorts or Homebrew. In this example we used Homebrew:
> brew install ettercap --with-gtk+
In order to be able to launch the graphical user interface, it is necessary to add the additional
flag --with-gtk+ at the end of the command; otherwise, the default version does not include the
graphical interface support.

Once Ettercap is properly installed, we can move on to the next step.

Discovering Connected End-Points and the Router

Now that Ettercap is ready, we need to gather a list of hosts currently connected on our
network. Ettercap has an easy way of doing this. First, run the following command to start
Ettercap. Make sure you add "sudo", as Ettercap requires superuser privileges to perform its
duty. If you forget to add sudo, Ettercap won't have access to the different ethernet interfaces,
and you won't be able to continue to the next step.
> sudo ettercap -G

Now you should have available a user interface. Go to File > Unified Sniffing, and select the
interface that corresponds to the network we are interested in. More often than not, en0 will be
the proper selection. However, feel free to run the following command to check and make sure
that it is the correct interface:
> ifconfig

Once the correct network interface has been selected, we can start scanning for hosts on the
network. To do this, go to:
Hosts > Scan for Hosts

When you see the message "# hosts added to the hosts list...", where # is any number of hosts
found by Ettercap, then go to:
Hosts > Hosts List

This will display the list of hosts connected to the network. Note that the machine that hosts
Ettercap (a.k.a the attacker) is not listed on the Hosts List.

ARP Poisoning your Victim

The next step is to poison the victim's ARP cache to match the attacker's MAC address instead
of the router's. To do this, we now choose the victim's IP address, we select it, and click on Add
To Target 1. The host victim should be a second machine available to you, where you can run
commands on the terminal/cli, since you will need to access it to check that the poisoning was
dd To Target 2.
successful. We then select the router's IP address, and click on A
After selecting the target hosts, go to Mitm > ARP Poisoning..., which will prompt you with two
parameters. Select "Only poison one-way".

Now you successfully poisoned the host and the router!

Testing the Environment

To make sure the ARP poisoning was successful, go to your victim host machine. Run the
following command:
> ifconfig

In the output, look for the "inet" address on the network interface en0. This should be the IP
address for your victim inside of the network. Next to it, you will find a "broadcast" address. This
address can be used to send a message to be broadcasted to all members of the network. We
will use this to scan all hosts from the victim machine. Run the following command, where
broadcast IP address is in x.x.x.x format:
> ping [broadcast IP address]

Feel free to press "control+c" to stop the process after a few seconds, as it only takes one
response from each node to update the ARP table of the victim. After this is done, run the
following command to see the current ARP table:
> arp -a

This will display a few IP addresses and the corresponding MAC address. From this table, find
the router's IP address. The router's IP address should have a corresponding MAC address of
the Ettercap machine. If this is true, ARP poisoning was successful.

If you need to stop the poisoning, go to Mitm > Stop mitm attack(s).... This will stop the attack
and update the ARP tables for both the victim and the router. If you run "arp -a" again after this,
you should see the router's MAC address updated to the correct one.
Appendix B: ARP Cache Poisoning Defense Tutorial

Here, we will provide with a step-by-step tutorial on how to set up four monitoring techniques to
be able to detect the ARP Cache Poisoning Attack.

ARP_cop
In order to run ARP_cop, please refer to the instructions above to install Ettercap. ARP_cop is a
plugin that comes loaded with the Ettercap installation. To activate it, follow these steps:
1. Go to File > Unified Sniffing, and select the interface that corresponds to the network we
are interested in. For more details on this, please refer to Appendix A.
2. Go to Hosts > Scan for Hosts.
3. Go to Plugins > Manage the Plugins. A list of plugins will appear.
4. Double click on the first plugin, which should be a rp_cop.
This will start running arp_cop, which will detect the attacker almost instantaneously.

ICMP based Secondary Cache

Please refer to our code written and published on Github:
https://github.com/rva5120/arp_def_tools
Scapy used for packet crafting [12][13][19].

Probe Packet based

Please refer to our code written and published on Github:
https://github.com/rva5120/arp_def_tools
Scapy used for packet crafting [12][13][19].

Snort NIDS on Mac OSX [14][15][16][17][18]

In order to setup Snort NIDS on Mac OSX please follow the instructions below, and see the
Snort manual [15], and the two guides used to setup this tool [17][18].
1. Download xcode from Mac App store, and download and update/upgrade homebrew
brew update
brew upgrade
2. Download and setup Snort directories and files
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" <
/dev/null 2> /dev/null
$ brew install snort
For snort to be functional, you need to update the permissions for /dev/bpf*
so that they can be read by non-root users:
sudo chmod o+r /dev/bpf* [17]
sudo mkdir /etc/snort
sudo mkdir /etc/snort/rules
sudo mkdir /etc/snort/preproc_rules
 sudo mkdir /var/log/snort
sudo touch /etc/snort/rules/local.rules
sudo touch /etc/snort/rules/white_list.rules
sudo touch /etc/snort/rules/black_list.rules
sudo cp /usr/local/Cellar/snort/2.9.11/.bottle/etc/snort/* /etc/snort/
sudo vim /etc/snort/snort.conf
- Comment out all rule files except for local.rules
- Fix paths for RULES files [18]
var RULE_PATH /etc/snort/rules
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
var WHITE_LIST_PATH /etc/snort/rules
var BLACK_LIST_PATH /etc/snort/rules
- Fix paths for dynamic libraries / engine
# path to dynamic preprocessor libraries
dynamicpreprocessor directory /usr/local/Cellar/snort/2.9.11/lib/snort_dynamicpreprocessor/
# path to base preprocessor engine
dynamicengine /usr/local/Cellar/snort/2.9.11/lib/snort_dynamicengine/libsf_engine.so
- Comment out path to dynamic rules libraries
- Uncomment the Unified2 output line and removed "nostamp" from the
comma-delimited options list:
output unified2: filename merged.log, limit 128, mpls_event_types,vlan_event_types
- Change HOME_NET to the network your devices are on (in this example, 10.0.0.0/24)
ipvar HOME_NET 10.0.0.0/24
- Uncomment [include $PREPROC_RULE_PATH/preprocessor.rules]
- Uncomment preprocessor arpspoof, set host_ip, host_mac to monitored devices [16]
preprocessor arpspoof
preprocessor arpspoof_detect_host: host_ip host_mac
# Multiple hosts can be monitored, by repeating the above line
preprocessor arpspoof_detect_host: host_ip2 host_mac2

3. Downloaded the latest snort.tar from snort.org for the preproc_rules files
sudo cp snort-2.9.11/preproc_rules/* /etc/snort/preproc_rules/

4. Monitor the snort alert file

tail -F /var/log/snort/alert

5. Run snort with the snort.conf file (see snort manpage for additional flags)
sudo snort -c /etc/snort/snort.conf
OR specify the interface to listen on (interface en0 used here):
sudo snort -i en0 -c /etc/snort/snort.conf