Arp Spoofing
Arp Spoofing
Group 1
Researched Work
At the beginning, we did some research about the ARP spoofing to let us understand the
technic of ARP spoofing. “Mitigating ARP Spoofing Attacks in Software-Defined Networks” gives
us some basic information about the ARP Spoofing. ARP spoofing may be used to launch either
one of the following attacks [1].
• DoS attacks: the attacker will prevent the two communicating hosts from getting
connected to each other.
• Host impersonation attack: the attacker will receive packets intended to the victim and
can reply to these packets on behalf of the victim.
• Man-In-The-Middle (MITM) attack: the attacker will be able to monitor all the traffic
between two communicating hosts.
After introduce ARP spoofing, it provides several techniques used to figure out ARP spoofing.
• ARP authentication
• Operating system patching
• Dynamic ARP Inspection
• ARP mitigation tools
• Static ARP mappings
After we get familiar with the ARP spoofing, we can not find any resources about the simulation
of ARP spoofing using ns-3.
Next, we would like to find a prevention method to avoid ARP spoofing. A paper called “A
Proposal for a Schema for ARP Spoofing Protection” from Jin-Cherng Lin, Men-Jue Koo, and
Cheng-Sheng Wang give us a lot of ideas. In this paper, it points that ARP Spoofing attack mainly
interferes with the correctness of the IP/MAC mapping correlation in the ARP table of the host.
[3] It has four characteristics:
• Targeted attacks
• Does not generate suspicious traffics
• Difficult to detect
• Difficult to be prevented in mind
ARP Overview
In this section, we will go over the basic information about the ARP and ARP spoofing. The OSI
model divides the network into seven layers. OSI model is a conceptual model that
characterizes and standardizes the communication functions of a telecommunication or
computing system without regard to its underlying internal structure and technology [4]The IP
address is in the third layer (network layer) of the OSI model, and the MAC address is in the
second layer (link layer). They do not deal with each other directly. When sending IP packet
over Ethernet, you need to encapsulate the header of network layer and link layer first but only
the destination IP address is known at the time of sending, and the MAC address is unknown.
However, it cannot cross the network layer and link layer, so it needs to use the Address
Resolution Protocol (ARP). After using the ARP, the MAC address information can be parsed
according to the IP address information in the IP header of the network layer.
ARP History
The problem of address resolution was apparent from the very start in the development of the
TCP/IP protocol suite. Much of the early development of IP was performed on the then-
fledgling Ethernet local area networking technology; this was even before Ethernet had been
officially standardized as IEEE 802.3. It was necessary to define a way to map IP addresses to
Ethernet addresses to allow communication over Ethernet networks.
There are two basic methods that resolution could have been used to accomplish this
correlation of addresses: direct mapping or dynamic resolution. However, Ethernet addresses
are 48 bits long while IP addresses are only 32 bits, which immediately rules out direct mapping.
Furthermore, the designers of IP wanted the flexibility that results from using the dynamic
resolution model. To this end, they developed the TCP/IP Address Resolution Protocol (ARP).
This protocol is described in one of the earliest of the Internet RFCs still in common use: RFC
826, An Ethernet Address Resolution Protocol, published in 1982 [5].
The name makes clear that ARP was originally developed for Ethernet. Thus, it represents a
nexus between the most popular layer two LAN protocol and the most popular layer three
internetworking protocol—this is true even two decades later. However, it was also obvious
from the beginning that even if Ethernet was a very common way of transporting IP, it would
not be the only one. Therefore, ARP was made a general protocol capable of resolving
addresses from IP to not just Ethernet but numerous other data link layer technologies.
From the above figure, there are three clients in a LAN. The IP address and MAC address of the
first client are 10.1.1.1 and 00.00.00.00.00.00 respectively. For the second user, the IP address
is 10.1.1.2 and MAC address is 00.00.00.00.00.01. And IP address and MAC address of the last
client are 10.1.1.3 and 00.00.00.00.00.02 respectively. In this scenario, the first user is looking
for the other client in this LAN who has the IP address 10.1.1.2. The procedure of “Broadcast:
Does anyone have IP 10.1.1.2” is called ARP Request.
After every client in this LAN received the broadcasting message from Client#1. The user who
has the required IP will send a response back to the Client#1. It also contains the MAC address
of Client#2 to let Client#1 update his memory.
ARP Cache
Each host should have an ARP cache, which contains the mapping table of IP addresses to MAC
addresses of hosts and clients on the LAN. If we do not use ARP cache, any host must send an
ARP request packet on the network as long as it communicates once. This increase the traffic
on the network. ARP saves the obtained address map in the cache so that when the host
communicates with the same destination next time, it can directly find the required MAC
address from the cache without broadcast ARP request packet. In fact, the ARP cache sounds
like look up tables that map the IP addresses with MAC addresses. For example, the ARP Cache
of the Client#1 after getting the response from the second client is shown below.
ARP Spoofing
The ARP is based on the mutual trust of each host in the network. The birth of the ARP makes
the network run more efficiently, but it also has its own flaws. In conclusion, there are several
properties of ARP.
▪ Keep locally to minimize number of ARP requests being broadcast
▪ Update the cache when the new IP/MAC associate for each reply successfully
▪ Stateless Protocol: will update the cache when a reply is received without any
confirmation
Because the ARP is a stateless protocol. It always will update the cache whenever a new
response is received. This gives the attacker an opportunity to hack the ARP. The ARP request is
sent as a broadcast message. Hosts on the network can send ARP response messages
autonomously. And when other hosts receive the response packets, they will be detected in the
authenticity of the packets and they will be recorded in the ARP cache. In this way, an attacker
can send a fake ARP response packet to the destination host to tamper with his ARP cache.
For example, there are still 3 hosts in a LAN. Host who has IP address 10.1.1.3 plays the role of
an attacker in this scenario. The attacker will send a spurious ARP response. However, in this
ARP response the sender IP address is 10.1.1.2 (IP address of Client#2) and the MAC address is
00.00.00.00.00.02 (MAC address of Client#3). When Client#1 receives this fake ARP response, it
updates his local ARP cache immediately. At this time, Client#1 does not recognise that this ARP
response has been forged. Meanwhile, Client#1 is unaware that this ARP response was sent
from Client#3 and use attacker’s MAC address.
The ARP cache table of Client#1 is shown in the Table 2. Comparing with Table 1, the MAC
address of the Client#2 is already wrong. So, if Client#1 would like to communicate with
Client#2 later, the IP address of the 10.1.1.2 will be incorrectly parsed by ARP into the MAC
address 00.00.00.00.00.02. This will cause the two clients to be unable to communicate with
each other.
Simulation
Goals
Prove the vulnerability of ARP protocol by simulating valid ARP replies and ARP spoofing,
comparing the results and analyzing the behaviours of each node in both cases.
Environment
The operating system we used to set up our simulation is Ubuntu. And the simulation tool we
used is ns-3.
Ns3 is a discrete-event network simulator for Internet systems, targeted primarily for research
and educational use.
Unlike industrial simulation software such as Riverbed, ns3 is an open source project whose
source code can be read and modified. Ns-3 helps us understand how the configurations
change the behaviour of nodes by reading its source code rather than reading high-level
behavioural descriptions, giving us access to the vulnerability of the protocols. If it is necessary,
we can also modify ns3’s source code locally which we can never do with industrial tools.
Problems
Ns-3 does not provide interface for sending request:
Ns3 has classes that implement the procedures of ARP requests and replies. However, these
methods are usually called implicitly because ARP protocol is usually occurred to assist
transportation protocols such as UDP and TCP. In this case, we modified the source code to
provide external interface to invoke ARP requests.
As we have introduced before, Arp protocol is a stateless protocol. However, ns3 has added
states to ARP cache entries that provide some protection against ARP attacks. The states and
corresponding behaviour are defined as following:
If the entry is not on isWaitingReply state, any Arp replies rejected as spoofing messages.
In most cases, the states and kept and handled by the operating system. To make the attack
successful, we need to flood the ARP replies and there will be a chance one reply gets accepted
right after the victim makes the request.
Topology
Scenario 1
Figure 8 Scenario1
In this scenario, we set up the LAN by defining the nodes as CSMA devices and assigning them
same subnet IP addresses using CSMA helper class defined in ns3. Just as the graph show, there
are three hosts in the LAN. The first node with IP address 10.1.1.1 and MAC address
00.00.00.00.00.00 is installed with UdpClientApp acting as a UDP server. The second node with
11 Simulation | ENSC 427 FINAL PROJECT: ARP SPOOFING
IP address 10.1.1.2 and MAC address 00.00.00.00.00.01 is installed with UdpServerApp acting
as a UDP client who accepts the UDP packets. The UdpClientApp and UdpServerApp are the
classes defined in ns3. The client app class periodically makes a UDP packet, adds headers to it
and sends it to the server app. The details are configured as following:
In this case, the third node with IP address 10.1.1.3 is not doing anything in the simulation.
Scenario 2
Figure 9 Scenario 2
In this scenario, the LAN, the first and the second node are set up and configured same way as
they are in scenario 1. In addition to that, the third node with IP address 10.1.1.3 and Mac
address 00.00.00.00.00.02 is installed with ARP attacker application we designed. With this
application, the node sends a fake ARP reply periodically. If the victim picks up the reply
Results
We output the results of the simulation in Pcap files.
Scenario 1
UDP client:
As it is shown in the Pcap file, there UDP packets was properly sent to the server.
UDP server:
After the server replies with the correct MAC-IP mapping, it received three pickets normally.
Attacker:
In the first scenario, the attacker is not involved. It only sees the broadcasted ARP request and
the reply. It doesn’t have knowledge of the 3 UDP packets sent from the UDP client.
Scenario 2
UDP client:
In this case, the first UDP packet is sent immediately after the first broadcasted fake ARP reply.
Indicating the client accepted the fake ARP reply and sent a packet to the attacker.
UDP server:
The server is still getting the packets from the client. This will be explained later.
Attacker:
The three Pcap files show result here. Because the hosts are by nature ns-3 objects, their
behaviours are set by ns3. It looks like the attacker becomes the ARP proxy for the UDP client
and the UDP server. After it received the first UDP packet, it broadcasts a request to ask for the
correct MAC address of the UDP server and redirected the packet to the server. The two
sequential UDP packets are also redirected by the attacker to the server. That explains why the
server is still getting the packets and why the attacker has Pcap messages for each UDP packets.
The following graph shows the topology from the simulation results.
Becoming an ARP proxy, the attacker will be able to examine or modify the content of the UDP
packet and redirected to the server.
15 Simulation | ENSC 427 FINAL PROJECT: ARP SPOOFING
Conclusion
Based on simulation of ARP spoofing, we can conclude.
• ARP is vulnerable
• Even with state ARP, it is harder to poison the ARP cache
• Most attacks are launched in the same LAN
• Attacker can be man in the middle
Industry Work
To avoid the ARP spoofing, not only the individual users come with some ideas to solve ARP
spoofing, but also companies provide some solutions about ARP spoofing. We will focus on the
Dynamic ARP Inspection method provided by Cisco. Cisco has already provided software
solution on their switch such as Catalyst 6500, Catalyst 4500, etc.
We add a DHCP server in LAN as shown in the above figure. DAI determine the validity of ARP
packets based on valid IP-to-MAC address bindings stored in the trusted database. In above
figure, the trusted database is the DHCP server. If the ARP packet is received from a trusted
port, the Ethernet switch forward the packets without any activities. On the other hand, if the
As shown in the above figure, there are three clients and a DHCP server in this LAN. Client#1.
Future Plan
At present, the most effective way to protect ARP spoofing in LANs is through bidirectional
binding of IP and MAC addresses between clients. However, this method still cannot effectively
prevent ARP attacks on LANs. The most significant reason is that when we discovered the ARP
spoofing and set up two-way binding, it had already changed the MAC address of the local
computer resulting in invalid binding. On the other hand, it is human-made destruction. For
Conclusion
ARP spoofing and attack problems are the culprits of enterprise networks. The discussion on
this issue has been very thorough. After our simulation, the mechanism of ARP attacks has been
thoroughly understood and various preventive precautions have been introduced. But the
question is that is it really bothering you to get rid of ARP problems now. As we known,
although various methods have been tried, this problem has not been fundamentally solved.
There are three reasons that we conclude. First, the preventive ability of the solution measures
is limited, and it is not the most fundamental method. The second is that the network
management is very constrained, inconvenient and impractical, and has no operability. Third,
some measures have a loss in the efficiency of network transmission, slower network speed,
and wasteful bandwidth which is also undesirable.
[1] S. Bhirud and V. Katkar, "Light weight approach for IP-ARP spoofing detection and
prevention," Second Asian Himalayas International Conference on Internet (AH-ICI),
Kathmandu, 2011.
[2] M. Ahmed, B.-S. Ashraf and R. K. Vamshi , "Mitigating ARP Spoofing Attacks in Software-
Defined Networks," ICCTA, Alexandria, Egypt, 2015.
[3] J.-C. Lin, M.-J. Koo and C.-S. Wang, "A Proposal for a Schema for ARP Spoofing Protection,"
ICETI, Taiwan, 2012.
#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/csma-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"
#include "ns3/ipv4-global-routing-helper.h"
#include <sstream>
#include <iostream>
NS_LOG_COMPONENT_DEFINE ("arp1");
AttackApp ();
virtual ~AttackApp();
private:
virtual void StartApplication (void);
virtual void StopApplication (void);
void ScheduleTx (void);
Ptr<Node> m_node;
Ptr<NetDevice> m_device;
Ptr<Ipv4Interface> m_iface;
Ipv4Address m_fakeAddr;
// victim info
Ipv4Address m_vAddr;
Address m_vMac;
EventId m_sendEvent;
bool m_running;
ArpL3Protocol m_attacker;
Ptr<ArpCache> m_arpCache;
};
AttackApp::AttackApp ()
:m_node(),
m_device(),
m_iface(),
m_fakeAddr(),
m_vAddr(),
m_vMac(),
m_sendEvent (),
m_running (false)
{
}
AttackApp::~AttackApp()
{
}
void
AttackApp::Setup (Ptr<Node> aNode, Ptr<NetDevice> aDev, Ptr<Ipv4Interface>
iface, Ipv4Address addr, Ipv4Address vAddr, Address vMac)
{
m_node = aNode;
m_device = aDev;
m_iface = iface;
m_fakeAddr = addr;
m_vAddr = vAddr;
m_vMac = vMac;
}
void
AttackApp::StartApplication (void)
{
// initialize the attacker
m_attacker.SetNode(m_node);
m_arpCache = m_attacker.CreateCache(m_device, m_iface);
22 Appendix | ENSC 427 FINAL PROJECT: ARP SPOOFING
m_running = true;
SendPacket();
}
void
AttackApp::StopApplication (void)
{
m_running = false;
if (m_sendEvent.IsRunning ())
{
Simulator::Cancel (m_sendEvent);
}
}
void
AttackApp::SendPacket (void)
{
m_attacker.SendArpReply(m_arpCache, m_fakeAddr, m_vAddr, m_vMac);
std::cout << "stucked here" << std::endl;
ScheduleTx ();
}
void
AttackApp::ScheduleTx (void)
{
if (m_running)
{
Time tNext (MilliSeconds(1000));
m_sendEvent = Simulator::Schedule (tNext, &AttackApp::SendPacket, this);
}
}
int
main ()
{
LogComponentEnable ("UdpClient", LOG_LEVEL_INFO);
LogComponentEnable ("UdpServer", LOG_LEVEL_INFO);
LogComponentEnable ("ArpL3Protocol", LOG_LEVEL_INFO);
LogComponentEnable ("ArpHeader", LOG_LEVEL_INFO);
LogComponentEnable("arp1", LOG_LEVEL_INFO);
uint32_t nPackets = 3;
uint32_t packetInt = 1000;
uint32_t propDelay = 200;
uint32_t delayT = 0;
uint32_t serverStart = 5; // Server start time in ms
uint32_t clientStart = 50; // Client start time in ms
uint32_t stopTime = (clientStart) + (nPackets*packetInt) + (10*propDelay) +
delayT; // Stop the simulation once all packets have been received
Address victimAddr;
NodeContainer csmaNodes;
csmaNodes.Create (nCsma);
CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));
InternetStackHelper stack;
stack.Install (csmaNodes);
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer csmaInterfaces;
csmaInterfaces = address.Assign (csmaDevices);
Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
csma.EnablePcapAll("arp1");
Simulator::Run ();
Simulator::Destroy ();
return 0;
}