ASD: ARP Spoofing Detector Using OpenWrt

The address resolution protocol (ARP) is one of the most important communication protocols in a local area network (LAN). However, since there is no authentication procedure, the ARP is vulnerable to cyberattack such as ARP spooﬁng. Since ARP spooﬁng can be connected to critical attacks, including a man-in-the-middle (MITM) attack, detecting ARP spooﬁng initially without returning false-positive alarms is important. In general, however, existing works for ARP spooﬁng are unable to distinguish between ARP spooﬁng and connections from virtual machine (VM) guests, which results in false-positive alarms. In this article, we propose an access point-based ARP Spooﬁng Detector (ASD) that can detect ARP spooﬁng attacks without returning a false-positive rate. Our proposed system distinguishes between ARP spooﬁng and connections from VM guests using three information tables, AssocList , ARP cache table , and DHCP table , which are commonly managed by the access point based on a Linux system. We evaluated the performance of ASD on ARP spooﬁng attack experiments.


Introduction
e address resolution protocol (ARP) is one of the most important communication protocols in a local area network (LAN). e MAC addresses of the client are required to communicate with said clients on a LAN, and the ARP is a procedure that determines the MAC address of a given IP address. For example, if Client A wants to communicate with Client B, Client A may send a broadcast ARP request, to which Client B, after receiving this broadcast, responds in kind to Client A with an ARP reply containing its MAC address.
However, there is no authentication procedure for ARP reply packets, meaning that the ARP is not equipped to handle malicious ARP reply packets. With knowledge of this fact, an attacker can perform an ARP spoofing attack on a target after modifying some ARP reply packets. ARP spoofing is particularly dangerous as it can easily lead to a variety of subsequent attacks such as sniffing, denial-ofservice (DoS), and man-in-the-middle (MITM) attacks [1].
Unfortunately, existing solutions to the above-mentioned ARP spoofing attacks require modification of the ARP itself or installation of expensive hardware equipment (e.g., costly switches and servers). ARP spoofing attempts can be easily detected by checking the IP/MAC address mapping of a suspected target's cache table. If there is a MAC address that is mapped to more than two IP addresses in the ARP cache table, it is reasonable to suspect that the MAC address is the target of at least one ARP spoofing attack. However, this approach can also generate false-positive alarms when there is a virtual machine (VM) guest on a bridged network. To handle this particular ARP spoofing detection issue regarding VM guests on a bridged network, we propose a new intrusion detection system called ARP Spoofing Detector (ASD) that, when installed on an access point (AP), can detect ARP spoofing attacks on a LAN managed by the ASD-enabled AP without any additional hardware equipment. In addition, ASD can distinguish fake MAC addresses forged by an attacker from benign MAC addresses of VM guests on a bridged network. To our knowledge, this problem has not yet been resolved by any existing ARP spoofing detection methods. For the evaluation, ASD was implemented in OpenWrt [2], a Linux-based, open-source operating system (OS), and ARP spoofing attack tests were performed several times to verify whether or not ASD could successfully and consistently detect ARP spoofing without returning false-positive alarms. e contributions of this article are described as follows: (i) e proposed system, ASD, can distinguish ARP spoofing attack attempts and network connections from a VM guest on a bridged network. In addition, compared to existing works, ASD does not require additional equipment or modification of ARP processes. (ii) ASD was implemented on an OpenWrt-based AP and its ability to handle ARP attacks without returning any false-positive rates. Additionally, ARP spoofing attack attempts can be monitored using a visualization tool provided in ASD.
is article is organized as follows. e background and related works are discussed in Section 2. Section 3 defines our attack model and attack scenario for ARP spoofing. Sections 4 and 5 describe the architecture of our proposed ARP Spoofing Detector (ASD) and corresponding evaluation results, respectively. Finally, Section 6 presents our conclusion.

Address Resolution Protocol (ARP).
e ARP is a protocol that maps logical addresses (i.e., IP addresses) to physical addresses (i.e., MAC addresses) on a network [3]. It is used to communicate between layer 2 and layer 3 in IPv4, and it stores the IP/MAC address pairings in a local ARP cache table. e ARP is constructed of requests and replies. When a client wants to know the MAC address for another specific client's IP address, it sends an ARP request packet to all clients on the same LAN. e client with the corresponding IP address responds using an ARP reply packet, which includes its MAC address. An attacker can easily launch any ARP spoofing attack with suites and tools such as Ettercap and Cain & Abel [4] and can likewise execute a MITM attack and intercept the communications between two clients and forge messages to each one [5]. Recently, MITM attacks have come under particular scrutiny as a security threat for not only PCs but also IoT devices [6]. Figure 1 shows an example of ARP spoofing-based MITM attacks.

Related Works.
Existing solutions for ARP spoofing can be divided into two types. One type involves preventing ARP spoofing (i.e., the prevention type), which requires modifying the ARP, while the other involves detecting ARP spoofing (i.e., the detection type). Table 1 represents the summary of existing research on preventing ARP spoofing attacks. All existing solutions face noteworthy limitations like the need to install an additional device, production of heavy network traffic, or addition of heavy computation overhead. We classify the existing solutions into four categories: (1) a hardware-based approach, (2) a cryptography-based approach, (3) a voting-based approach, (4) a central server-based approach, and (5) a dynamic host configuration protocol-based approach. In the hardwarebased approach [7], installation of additional devices is necessary, which results in several hardware management burdens for the user, like installation and management costs. In cryptography-based approaches [8][9][10], existing solutions unfortunately produce significant cryptographic operation overhead during operations like key exchange protocol and verification. Bruschi et al. [8] proposed a secure address resolution protocol (S-ARP). In this protocol, all hosts have a public/private key pair distributed by the authoritative key distributor (AKD), and messages are signed by a digital signature algorithm for the prevention of ARP spoofing. Lootah et al. [9] introduced ticket-based address resolution protocol (TARP) to reduce the computational resources of S-ARP using an additional entity called Local Ticket Agent (LTA). Likewise, Goyal and Tripathy [10] presented an enhanced S-ARP mechanism that adopts one-time passwords based on hash chains. In voting-based approaches [11,12], existing solutions create burdensome network traffic due to the high communication cost between voters. Nam et al. [11] presented a MITM-resistant address resolution protocol (MR-ARP) based on two key concepts, namely, long-term IP/MAC mapping table and voting. To overcome the limitation of MR-ARP, which requires far too much computational time, [12] suggested the Generalized MR-ARP (GMR-ARP), which increases the fairness of voting by dropping reply packets that appear too early. In the central server-based approaches [13][14][15], existing solutions have a single point of failure problem that could occur in the central server. Gouda and Huang [13] proposed a secure server that uses two protocols: an invite-accept protocol and a request-reply protocol. Demuth and Leitner [14] introduced a multiple server-based method that requires three additional servers for gateway protection, client protection, and server protection. Ortega et al. [15] presented a twopronged OpenWrt-based server and switch method. e server responds to an ARP request with IP/MAC address mapping, while the switch blocks all ARP responses.

Prevention Methods for ARP Spoofing.
In dynamic host configuration protocol-(DHCP-) based approaches [16][17][18], the existing solutions based on the DHCP table are limited by the VM connection. Masoud et al. [16] updated the ARP cache table based on DHCP. When the network's user receives any ARP reply, the ARP reply is dropped if the IP/MAC address mapping in the ARP reply is not the same as IP/MAC address in the DHCP reply. Since this approach analyzes all packets, this will increase the computational overhead of the network controller, that is, a server on which developers can write proprietary or customized topologies and algorithms in the software-defined network (SDN). Cox et al. [17] presented Network Flow Guard (NFG) as a modular application to detect and prevent ARP replies from unauthorized hosts by monitoring DHCP from valid DHCP servers. Sun et al. [18] took advantage of DHCP to obtain reliable IP/MAC address mapping in order to ensure the accuracy of ARP attack detection. However, ARP cache table management based on DHCP does give a VM guest on a bridged network an error.

Detection Methods for ARP Spoofing.
ere are several detection methods for ARP spoofing like ARP-Guard [19], snort [20], ARPDefender [21], and Arpwatch [22]. However, these methods can all suffer from false-positive detection [23] because they cannot distinguish between ARP spoofing attacks and connections from VM guests on a bridged network. In light of this, there is a clear need for an ARP spoofing detection algorithm that can effectively deal with connections from VM guests without returning unnecessary false alarms.

Adversary Model
In this section, we propose an adversary model for ARP spoofing attacks and the corresponding attack scenario. en, we discuss the problem statement addressed in this article.

Adversary Model.
In this model, we assume the presence of an attacker who can perform an ARP spoofing-based MITM attack. is adversary is assumed to be able to access the LAN, through which the attacker would be able to locate and connect to a target (i.e., a victim). Note that, due to the abundance of public places, such as cafeterias, where public AP services are provided, it is possible for an attacker to access the network where the attack target exists. Also, note that other types of spoofing attacks like DHCP or IP spoofing are out of the scope of this article. In addition, compromising attacks on the AP should be handled by other protection methods like remote attestation or control-flow integrity (CFI). Figure 1, a host (IP address: 192.168.1.20, MAC address: bb-bb-bb-bb-bb-bb) is assumed to have access to the AP (IP address: 192.168.1.1, MAC address: aa-aa-aa-aa-aa-aa). If an attacker (IP address: 192.168.1.30, MAC address: cc-cc-cc-cc-cc-cc) is on the same LAN, the attacker can perform an ARP spoofing-based MITM attack by modifying ARP packets between the AP and a user who has accessed the AP. As a result of the ARP spoofing-based MITM attack, the attacker's MAC address is assigned to both the AP and the attacker in the target's ARP cache tables.

Category
Research work Pros/cons Hardware-based Bhaiji [7] Only available in certain switches

Cryptography-based
Bruschi et al. [8] Heavy performance overhead due to the use of a public key algorithm Lootah et al. [9] It requires an additional entity called ticket agent Goyal et al. [10] e extended work of [8] Voting-based Nam et al. [11] Based on a voting system that is slower than a rule-based system Nam et al. [12] e extended work of [11] Central server-based Gouda and Huang [13] It requires modification of the ARP protocol used by all hosts Demuth and Leitner [14] It requires three additional servers and is, thus, not cost-effective Ortega et al. [15] It uses the OpenWrt

DHCP-based
Masoud et al. [16] It can create overhead at the SDN controller Cox et al. [17] It could install incorrect drop flow rules for genuine hosts in multiple switches scenario Sun et al. [18] It is used in SDN-based cloud computing environments To consider various attack scenarios, as shown in Table 2, we define five types of ARP spoofing attacks: Simple Attack 1, Simple Attack 2, Multi-Attack 1, Multi-Attack 2, and Complex Attack. While Simple Attacks 1 and 2 target only one victim, Multi-Attacks 1 and 2 are performed against two victims. Both the Simple Attacks 1 and 2 and Multi-Attacks 1 and 2 can be performed by a host OS or a VM guest OS. If both a host OS and a VM guest OS perform ARP spoofing attacks on a target at the same time, this case is defined as a Complex Attack.

Problem Statement.
Recently, it has been customary for machines to utilize virtualization strategies. In a virtualization environment, there are a host OS and a guest OS. e former is the actual software on a computer that interacts with the primary hardware, and the latter is the software installed on a VM. If a guest OS is created on a bridged network, the guest OS can be assigned an IP address from an AP as if it was directly connected to the AP. When the guest OS and the AP communicate with each other, the guest OS transmits and receives packets using the host OS's MAC address. is is shown in Figure 2. us, the guest OS's MAC address displays as the host OS's MAC address in the ARP cache table of the AP even though no ARP spoofing attack has occurred. It seems problematic that the states of the ARP cache tables are identical when there is an ARP spoofing attack and when there is simply a guest OS on a bridged network, as shown in Figure 3. As such, there needs to be an algorithm that can distinguish between these two scenarios in order to effectively and accurately handle both ARP spoofing attacks and innocuous VM connections. In this article, we propose an IDS that can distinguish VM connections from ARP spoofing attacks and detect ARP spoofing attacks. A detailed description of our proposed system and its architecture follow in the next section.

Proposed System
In this section, we describe the system design of our proposed ARP Spoofing Detector, ASD, in detail. ASD is composed of three phases and uses three key pieces of information-AssocList, ARP cache table, and DHCP table-to distinguish between an ARP spoofing attack and a guest OS connection.
(i) AssocList: AssocList shows client information (e.g., MAC address and signal strength) connected to the AP. However, in the case of VM connections, the guest OS's MAC address is not shown. Figure 4 shows an example of AssocList as seen on OpenWrt. (ii) ARP cache e proposed ASD can be installed on any Linux-based AP system and can detect all ARP spoofing attempts that occur on the AP network. Figure 5 shows the system overview of ASD. Next, we explain the three phases of our protocol. , it is concluded that the node using the MAC address is either an ARP spoofing attacker or a host OS. Otherwise, the node itself may be a victim of an ARP spoofing attack, or it may be a guest OS.

Phase 1: Comparison between AssocList and ARP Cache
After Phase 2, ASD proceeds with Phase 3 to determine its final decision. Table and AssocList. In Phase 3, ASD checks whether or not the MAC address extracted from the DHCP table is included in the AssocList. Remember that the MAC address used by a guest OS does not appear in AssocList. erefore, if the MAC address of a node determined to be a victim of ARP spoofing or to be a guest OS in Phase 2 is found in the AssocList, ASD considers the node itself as a victim of ARP spoofing. Otherwise, the node is a guest OS on a bridged network. As such, ASD is able to distinguish between an ARP spoofing attacker and a host OS. If there is a node using the same MAC address as the victim of ARP spoofing in the ARP cache table, ASD determines the node to be an ARP spoofing attacker. Likewise, if there is a node using the same MAC address as the guest OS in the ARP cache table, ASD determines the node to be a host OS. e detailed steps are described in Pseudo-algorithm 1.

Evaluation
In this section, we describe the monitoring system and the performance of the ASD in various attack scenarios. In addition, we evaluate the execution time of ASD and compare ASD with existing solutions. Figure 6 shows the experimental setup with Mi WiFi Mini, a monitoring tool, and Kali Linux for ARP spoofing attacks. We implemented the proposed system, ASD, on Xiaomi Mi WiFi Mini using OpenWrt firmware. OpenWrt is an embedded OS based on Linux and is primarily used on embedded devices to route network traffic. en, we simulated multiple ARP spoofing attacks and guest OS connections to evaluate whether ASD is able to distinguish ARP attacks from VM guest connections on a bridged network. To simulate ARP spoofing attacks, we used Ettercap provided by Kali Linux. Ettercap is an open-source network security tool for packet sniffing and staging MITM attacks on a LAN. In the ARP spoofing-based MITM test, we firstly scanned for hosts. e AP and victim were selected, and spoofed ARP messages were generated. As shown in Figure 7, when an ARP spoofing attack occurs, ASD shows the victim, ARP spoofing attacker, and VM connections. e victim is represented in red and the attacker and VM connections are represented in blue. Note that we released the source code for ASD as open-source on GitHub [24].

Performance Evaluation.
To evaluate the robustness of ASD, we performed experiments with the five types of ARP spoofing attacks identified in Section 3.2. As shown in Table 3, ASD can detect all types of ARP spoofing attacks with a 100% success rate and returns no false alarms.     Output: info including IP address, MAC address, and Status (1) info ⟵ Create an empty list; (2) client_list⟵ Extract all MAC addresses in Assoclist; (3) arp_table ⟵ Extract all IP addresses and MAC addresses in ARP Cache Table; (4) for mac in client_list do (5) arp_ip ⟵ IP addresses that match MAC addresses as mac in arp_table; (6) for ip in arp_ip do //Normal Status (7) if count of arp_ip < 2 then (8) Append \{ ip, mac, Normal\} in info; (9) else (10) dhcp_mac ⟵ MAC addresses that match IP addresses as ip in DHCP Table; (11) if dhcp_mac in client_list then //Attacker or Host OS Status (12) if mac � dhcp_mac then (13) Append \{ip, mac, Host OS\} in info; //Victim Status (14) else (15) Append\{ ip, mac, Victim\} in info; (16) end //Guest OS Status (17) else (18) Append\{ ip, mac, Guest OS\} in info; (19) end (20) end In addition, we measured the detection time of the ARP spoofing attacks to evaluate the performance of ASD. As shown in Figure 8, we confirmed that detection time depends on the number of devices. When there is one device connected to the AP and there is no ARP spoofing attack, ASD Phase 1 execution time was about 200 ms. When there were 10 devices, however, the Phase 1 execution time was about 1 second. If there is an ARP spoofing attack, ASD takes more time checking the ARP spoofing attack and VM connection than if there was no abnormality detected because it needs to undergo both Phases 2 and 3. e time difference between the normal case and the ARP spoofing attack case is around 60 milliseconds, and we found that ASD effectively detects the ARP spoofing attack without false alarms in a short amount of time.

Comparison of Existing Solutions.
In this section, we compare ASD with existing methods, which are DHCPbased solutions [16][17][18], as shown in Table 4. Even though three existing solutions do not require any protocol modification or additional equipment, they can return detection errors in regard to ARP spoofing attacks because it is impossible to distinguish between ARP spoofing attack attempts and normal VM connection attempts just by observing the DHCP table. In addition, these protocols do not provide a visualization function like a monitoring tool to further explain details about the abnormal status. On the other hand, ASD does not generate false alarms as it effectively distinguishes between ARP spoofing attacks and VM connections, and it additionally provides visualization of detection results through a monitoring tool.

Conclusion
In this article, we propose the ARP Spoofing Detector (ASD) that can detect ARP spoofing attacks using OpenWrt. ASD is notable because it can detect ARP spoofing without  additional equipment or protocol modification. In addition, ASD does not generate false alarms caused by VM connections on a bridged network, and ASD provides a monitoring tool to help visual analysis of any ARP attack attempts. e proposed system was evaluated through ARP spoofing attack experiments, and as a result, we confirmed that it detects ARP spoofing attacks without returning false alarms.

Conflicts of Interest
e authors declare that they have no conflicts of interest.