Ensuring cybersecurity for industrial networks: A solution for ARP-based MITM attacks

Abstract

The increased adoption of the Internet Protocol (IP) in ICSs has made these systems vulnerable to the same security risks that are present in traditional IT environments. The legacy nature of ICSs and their unique operational requirements make them vulnerable to security threats that are different from those in IT environments. In this paper, we describe a protocol, named ArpON, which is able to wipe out in quasi real time any ARP cache poisoning attempt, thus making it ineffective. Contrarily to solutions presented in the literature for contrasting ARP cache poisoning, ArpON incurs in low operational costs, is backward compatible, transparent to the ARP protocol and does not use any HW feature nor cryptography functionality. We also model and validate ArpON in the OMNET $+ +$ network simulator. The simulation results show that ArpON is effective in avoiding ARP poisoning, and its communication overhead is negligible with respect to classical ARP protocol.

Keywords

Industry 4.0 ARP ARP poisoning Man-in-the-Middle attacks secure ARP

1. Introduction

Industrial Control Systems (ICSs) form the critical infrastructure backbone, ensuring the seamless operation of essential facilities, ranging from power plants to water treatment facilities. These systems serve as the industrial counterpart to Information and Communication Technologies (ICTs), playing a pivotal role in monitoring and controlling diverse processes through Supervisory Control and Data Acquisition (SCADA) systems. Historically, ICS components were interlinked using distinct serial fieldbus protocols like Controller Area Network (CAN-bus), Modbus, PROFIBUS, and CC-Link. Originally conceived for localized tasks devoid of external connectivity, these protocols operated in isolation. However, as the Internet matured and corporate operations expanded geographically, a pressing need emerged for ICS devices to communicate with external systems. This integration offered cost efficiencies and enhanced convenience, enabling remote control and monitoring from multiple locations. Nevertheless, this convergence came at a price: the isolation that once shielded ICSs from external threats was eroded, necessitating a profound reassessment of system security. The watershed moment came with the discovery of the Stuxnet worm [34], catapulting the security of ICSs to the forefront of research institutions, government agencies, security industries, and media organizations.

The increasing integration of the Internet Protocol (IP) into ICSs has exposed these systems to a range of security risks akin to those encountered in conventional IT environments. This paradigm shift underscores the imperative for ICSs to fortify their security measures to ward off potential cyber threats capable of causing significant disruptions to the critical processes they oversee. Regrettably, the prevalence of legacy ICSs, coupled with their distinct operational requirements, renders them susceptible to security challenges that are unique to their industrial setting. Consequently, it becomes paramount to confront these security intricacies to uphold the dependable and secure operation of ICSs.

Within the scope of this research, our primary focus centers on addressing the security challenges inherent in the deployment of the Ethernet protocol in communication components of ICSs. Ethernet, a foundational element of the TCP/IP stack, serves as the linchpin for device connectivity within localized networks. However, the original iteration of Ethernet falls short of meeting the stringent real-time demands typical of ICS environments. This limitation has spurred the evolution of various adapted versions collectively referred to as “Industrial Ethernet” [4,17,22,27,63]. Furthermore, industrial networks may involve heterogeneous technologies and they are often hybrid networks involving both wired and wireless links. The latter ones are more convenient for ICSs as they avoid a clutter of cables crowding industrial plants, but they are also more prone to security issues due to their intrinsic unshielded nature. A number of protocols for wireless industrial networks are either compatible or based on Ethernet too, such as Siemens IWLAN [54]. Widely used wireless protocols such as WiFi are typically used in conjunction with the IEEE 802.2 standard as the Logical Link Control protocol, so as to interwork seamlessly with Ethernet and to be able to carry IP traffic in hybrid networks. Notably, despite these adaptations, certain fundamental elements of the Ethernet protocol, such as the Address Resolution Protocol (ARP), remain unchanged. While ARP excels in terms of efficiency, it harbors a widely acknowledged vulnerability known as “ARP poisoning”. This vulnerability opens the door for potential attackers to execute Man-in-the-Middle (MITM) attacks, a concern substantiated by a body of recent research studies detailing successful MITM exploits targeting ICS and SCADA systems [6,23,28,36]. As a consequence, attacks conducted exploiting the ARP poisoning vulnerability represent a menace worth of discussion for wireless networks (included industrial ones) as well [56–58].

Our study delves into the performance evaluation of our defensive solution known as ArpON within the context of a specific ICS network. While our protocol has gained widespread acceptance across industry devices and is now effectively the norm, this marks the first time it has been thoroughly analyzed in a scientific research paper. ArpON is purpose-built to thwart ARP poisoning attacks by swiftly detecting and mitigating such attacks in near real-time. It accomplishes this task without imposing substantial resource overhead and operates without necessitating specialized hardware or cryptographic support. One key advantage of ArpON lies in its full compliance with all iterations of the ARP protocol as stipulated in the relevant Request for Comments (RFCs) [14,15,45], thereby ensuring its seamless integration into Local Area Network (LAN) environments. This adaptability makes it a valuable addition to modern SCADA systems and extends its applicability to some Programmable Logic Controllers (PLCs), particularly those based on platforms like OpenPLC [42].

To ascertain the practicality of integrating ArpON into ICS environments, we constructed a model of it within the OMNET $+ +$ network simulator. Specifically, we adhere to the standard network parameters commonly encountered in an ICS network, encompassing aspects like network topology, bandwidth allocation, and more. More details are included in Section 5. Our comprehensive evaluation honed in on critical metrics, encompassing the likelihood of successful ARP poisoning, resolution time, traffic overhead, and reaction time in direct comparison with a conventional ARP implementation. Our findings reveal the compelling efficacy of ArpON in thwarting ARP poisoning attempts. Furthermore, it is noteworthy that the additional network overhead introduced by ArpON proves to be minimal when juxtaposed with the standard ARP implementation. This underscores ArpON’s significance as an invaluable solution for enhancing the security of ICS network systems.

This paper presents the following contributions:

In-Depth Protocol Analysis: Conducted a thorough and rigorous analysis of the protocol, providing a comprehensive understanding of its functionality and security aspects.

Performance Assessment: Evaluated key performance metrics, including efficiency, security, and resource utilization, to provide insights into the protocol’s operational characteristics by using OMNET $+ +$ simulation framework, which revealed a low-overhead solution suitable for ICS network systems.

Security Analysis: we conduct a comprehensive security analysis of the proposed ArpON solution, evaluating its effectiveness in mitigating ARP poisoning attacks within ICS networks. Our analysis encompasses a detailed examination of the attack vectors, threat models, and potential impacts of ARP poisoning attacks.

2. Background

2.1. Distinctive challenges in industrial networks

Industrial networks diverge significantly from the classical Internet across several dimensions, profoundly influencing the prerequisites for the protocols in use. The array of connected devices can be numerous, necessitating robust scalability and minimal overhead in the adopted solutions. Additionally, a considerable portion of these devices may possess scarce resources, encompassing processing power, memory, and communication capabilities, which, once again, accentuates the preference for lightweight solutions. The devices themselves are highly specialized in executing specific tasks, making them inherently resistant to customizations beyond these tasks. Furthermore, the spectrum of devices extends beyond transmission technologies, as explored in Section 1, to encompass heterogeneous components, ranging from cloud-based servers to SCADA systems overseen by employees, as well as Remote Terminal Units (RTUs) and/or PLCs, responsible for managing actuators and monitoring sensors. Given this heterogeneity, solutions must be broadly applicable across all network technologies and system components, while also adhering to established standards. The intricacy inherent in ICS platforms mandates the adoption of autonomic solutions [51], equipped with the ability to self-heal in response to misbehavior, devoid of human intervention. Furthermore, when misbehavior is induced by security threats, the countermeasures must activate within a remarkably short time frame to safeguard the ICS platform. This challenge is exacerbated by devices that may lack the necessary resources or proficiency in swiftly executing complex tasks, including data encryption and machine learning.

2.2. Scheme in network communication

The Internet is a complex network comprising numerous LANs, each governed by its own set of protocols. These protocols, responsible for regulating the behavior of devices within a LAN, are situated within the Data Link Layer of the OSI model. In contrast, inter-network protocols like TCP/UDP and IP operate at the Network and Transport layers, as outlined in [5].

In this intricate ecosystem, two distinct addressing schemes come into play. Within the confines of a LAN, devices are uniquely identified by their 48-bit MAC (hardware) address. This MAC address, a permanent and manufacturer-assigned identifier, is embedded in the network interface card of each device. On the other hand, for communication across different LANs, a 32-bit IPv4 (network) address is employed. The allocation of IPv4 addresses can take one of two forms: either a network administrator manually assigns a static IP address, or a dynamic IP address is automatically assigned by a DHCP server, contingent on the specific network to which the device connects. Furthermore, devices also have the option to autonomously select a dynamic IPv4 address from the 169.254.0.0/16 range, as described in [15].

This intricate addressing system means that every device h connected to the Internet is uniquely identified by a paired set, denoted as $⟨ {MAC}_{h}, {IP}_{h} ⟩$ , where both the IP and MAC addresses of two devices are distinct from each other.

2.3. Address resolution protocol

The Address Resolution Protocol (ARP) is a data link layer protocol running on all devices of a LAN as well as on its routing elements. ARP main task is to learn the host’s MAC address associated to a certain IPv4 address. In order to perform such a task, every running instance of ARP maintains in the device’s memory a table containing the known mappings $⟨ MAC address, IPv4 address ⟩$ ; such a data structure is known as ARP cache.

Roughly speaking, ARP cache entries are either built through a static or a dynamic method. Static entries are manually added to the cache and never automatically removed, while dynamic entries are constructed as follows: consider two devices h and k on the same LAN. h needs to send a packet to k, but it only knows k’s IP address. To reach k in the local network, h must know k’s MAC address. First, h searches its own ARP cache for an entry $⟨ {MAC}_{k}, {IP}_{k} ⟩$ . If the entry is not found or has expired, h sends an ARP request message to all devices in the LAN asking for the MAC address of ${IP}_{k}$ . When k receives the message, it sends an ARP reply to h with its own MAC address. Once h receives the reply, it updates its cache with $⟨ {MAC}_{k}, {IP}_{k} ⟩$ , and similarly, k updates its cache with $⟨ {MAC}_{h}, {IP}_{h} ⟩$ . Dynamic entries in the ARP cache are frequently refreshed, with a lifetime that ranges from 30 seconds to 65535 seconds, after which the entry is automatically removed.

ARP also provides the option for a device to announce its IPv4 and MAC addresses upon boot or changes. This is useful, for example, when a device joins a LAN. Such an announcement, known as a gratuitous ARP message, is usually broadcast as an ARP request or an ARP reply. A gratuitous ARP sent as an ARP request is not intended to solicit a reply, but rather updates any cached entries for the sending device in the ARP tables of the packet receivers. This update is performed because of the implicit ARP assumption that all devices in a LAN are trustworthy.

2.4. ARP poisoning MITM attacks

The ARP protocol can be easily subverted by performing Man-in-the-Middle (MITM) attacks (see e.g. [10]), using a technique known as ARP poisoning or ARP spoofing, described in the following.

Let us consider three devices in a LAN x, w, z and their corresponding MAC and IP addresses $⟨ {MAC}_{x}, {IP}_{x} ⟩$ , $⟨ {MAC}_{w}, {IP}_{w} ⟩$ , $⟨ {MAC}_{z}, {IP}_{z} ⟩$ . If w convinces z that x’s MAC address is ${MAC}_{w}$ , all messages that z wants to send to x will be actually addressed to ${MAC}_{w}$ ; consequently, they will be received by w. In this way, the attacker w will hijack all the communications from z to x, acting as it sits in the middle of the communication, hence the name. More precisely, this is the case of a half-duplex MITM as the attacker is able to intercept only one traffic flow. We talk of full-duplex MITM when the attacker is able to monitor both traffic flows; this would imply that w is also able to convince x that z’s MAC address is ${MAC}_{w}$ . In the rest of the paper, we name victim the host that the attacker wants to impersonate and target the host whose ARP cache the attacker tries to poison.

The goal of MITM attacks is to take over a communication session between two devices in order to intercept and view the information being exchanged between them. ARP poisoning is not difficult to obtain by leveraging some of the features of the ARP protocol. Here there are some methods adopted to perform a MITM attack:

A malicious user h can craft a gratuitous ARP message by inserting in the packet header the pair $⟨ {MAC}_{h}, {IP}_{x} ⟩$ ;

A malicious user h can craft an ARP request by inserting in the packet header the pair $⟨ {MAC}_{h}, {IP}_{x} ⟩$ as source identifier;

A malicious user h can craft an unsolicited ARP reply by inserting in the packet header the pair $⟨ {MAC}_{h}, {IP}_{x} ⟩$ ;

In all cases, the ARP caches of the devices receiving the forged packets – and either being the packet destination or already having a cache entry for ${IP}_{x}$ – are poisoned with a wrong value, and the device h (attacker) will intercept all messages that those devices send to x. Note also that, since the non-static ARP cache entries are periodically refreshed, an attacker who is interested in maintaining a MITM attack for a long time has to continuously send forged ARP packets so as to maintain the target’s cache poisoned.

3. Threat model

A Man-in-the-Middle (MITM) ARP poisoning attack represents a serious security threat within ICS networks. This threat model outlines the key elements of this attack and its potential impact on ICS environments. The adversary in this threat model is an individual or entity with malicious intent. They may possess varying degrees of technical expertise, ranging from basic networking knowledge to advanced hacking skills. In particular, in our context the attacker operates at the network level and they can perform the following operations:

Spoofing MAC-IP Mappings: The malicious actor creates counterfeit ARP packets containing manipulated MAC-IP mappings. These false mappings associate the attacker’s MAC address with the IP address of a legitimate device already present within the LAN. Essentially, the attacker attempts to deceive network devices into associating their own hardware address with the IP address of a trusted device, thereby gaining unauthorized access and control over network traffic intended for the genuine device.

ARP Cache Corruption: In this phase of the attack, the assailant propagates the previously crafted and deceptive ARP packets throughout the network. These malicious ARP packets are designed to induce the targeted devices within the network to modify their ARP caches by incorporating the falsified MAC-IP mappings presented by the attacker. Essentially, the attacker’s goal is to trick the legitimate network devices into accepting and storing the counterfeit mappings in their ARP caches, leading them to believe that the attacker’s MAC address is associated with the IP address of a trusted device. This manipulation effectively enables the attacker to redirect, intercept, or control network traffic destined for the genuine device.

Traffic Redirection: Once the ARP cache has been successfully manipulated by the attacker, network traffic originally intended for the legitimate device is redirected to the attacker’s MAC address due to the erroneous associations in the ARP caches of other devices. This redirection results in the unintentional rerouting of network communication towards the attacker. As a consequence, the attacker gains the ability to intercept, manipulate, or redirect this network traffic as they see fit, potentially enabling them to eavesdrop on sensitive information, modify data packets, or reroute traffic to unauthorized destinations. This redirection of network traffic is a critical component of the attack, allowing the attacker to exploit the compromised ARP cache entries for their malicious purposes.

The motivation behind the MITM ARP poisoning attack could include data interception, network disruption, or unauthorized control over ICS components. More technical details about the attack scenario are reported in Background Section 2.4.

4. ArpON protocol

This section introduces ArpON, the innovative protocol designed to detect and mitigate MITM attacks through ARP poisoning in near real-time.

4.1. Overview

ArpON is a solution designed to work in parallel with the standard ARP protocol. It utilizes the same message formats and does not require cryptography, making it compatible with legacy ARP implementations. In a LAN environment, devices that use either the traditional ARP or the “ARP + ArpON” solution can coexist. The latter devices will have their ARP caches protected from man-in-the-middle ARP poisoning attacks.

The core idea behind ArpON is to supervise ARP cache management to detect and recover from ARP poisoning attacks. This is achieved by relying on its own cache, which is separate from the ARP cache. ArpON works in user space and cooperates with the ARP protocol in the kernel to manage Ethernet interfaces. An instance of the ArpON daemon exists for each Ethernet interface. The overall architecture is depicted in Fig. 1.

Fig. 1.

ArpON general architecture.

ArpON has the responsibility of overwriting the ARP cache based on its policies upon the reception of ARP messages. It tracks the outbound messages generated by the device in its cache, and classifies inbound messages that do not match previous outbound messages as “unsolicited.” This allows ArpON to detect ARP cache poisoning attacks such as ARP requests, unsolicited replies, or gratuitous messages.

At start-up, the ARP cache and ArpON cache are emptied, and the generation of ARP replies and creation of new ARP cache entries are disabled in the operating system (clean operation). To ensure the correctness of ArpON, all messages exchanged by it are broadcast in the LAN. If well-known static persistent addresses exist (HARPI mode, Flow Diagram in the Appendix), such as those of some servers, they are a-priori recorded in a config_file supplied to the devices by the network administrator, and used to perform an initial population of the ARP cache (update op). Furthermore, if a device x receives an ARP message from a device y claiming to own $⟨ {MAC}_{y}, {IP}_{y} ⟩$ as its address, and ${IP}_{y}$ is a persistent address, then x performs the following actions:

By contrast, messages concerning either unknown static addresses or dynamic addresses are managed with the support of state information maintained in the ArpON cache (DARPI mode). Specifically, the information carried by potentially dangerous messages (see Section 2.4) is checked using the following verification procedure: The value of $T_{D}$ equals 1 s; a daemon is run every second in order to remove from the ArpON cache the expired entries. The aim of the verification is to ask all devices – and thus the real owner of ${IP}_{y}$ too – the correspondence for ${IP}_{y}$ before inserting it into the ARP cache. The removal from the ARP cache is performed so as to delete the – potentially poisoned – correspondence just inserted by ARP on message reception (see Fig. 1). The reply of the honest ${IP}_{y}$ owner is waited for the short $T_{D}$ interval.

The verification procedure is used as follows:

If a host x has to resolve the IPv4 address of the destination of a locally generated UDP message, similarly to the operations above, it records an entry for that IP in the ArpON cache.

These procedures aim at preventing ARP cache poisoning of devices. Consider a device k which receives an ARP message (request, gratuitous, or unsolicited reply) from h: in order to verify the information contained in the message, k broadcasts an ARP request for ${IP}_{h}$ . At the same time, ArpON removes the $⟨ {MAC}_{h}, {IP}_{h} ⟩$ entry from k’s ARP cache and adds the $⟨ {IP}_{h}, T_{D} ⟩$ entry in k’s ArpON cache. In response to k’s message, h sends an ARP reply to k. When k receives the ARP reply from h, k removes the $⟨ {IP}_{h}, T_{D} ⟩$ entry from its ArpON cache, and inserts in its ARP cache the $⟨ {MAC}_{h}, {IP}_{h} ⟩$ information contained in h’s ARP reply.

Note, however, that the above protocol has a transient flaw which happens when a malicious device m anticipates h’s ARP reply, with a packet containing the $⟨ {MAC}_{m}, {IP}_{h} ⟩$ pair. This race condition is unavoidable, as explained in Section 6 and formally proved in [11] whose findings are summarized in Section 4.2. In such a case, a match is found in ArpON cache and these data are inserted in k’s ARP cache thus poisoning it. Fortunately, the poisoning will last only until k receives the correct ARP reply by device h, which at this point is detected as an unsolicited reply. When this happens, ArpON removes the $⟨ {MAC}_{m}, {IP}_{h} ⟩$ entry from the ARP cache and activates the verifying procedure. As we will show in Section 5, this procedure takes a very short time interval in which it is not possible to perpetrate any attack.

4.2. Formal analysis

In our previous work, outlined in [11], we conducted a comprehensive analysis of both the ARP poisoning problem and the ArpON algorithm. In this subsection, we provide a concise summary of the key findings from [11]. Regarding the ARP poisoning problem, [11] furnishes a formal proof utilizing logical and algebraic formalisms, establishing the inherent challenge of preventing ARP cache poisoning within a network with one or more malicious attackers, especially in the absence of cryptography. In essence, the proof demonstrates that the only address resolution algorithm capable of thwarting ARP cache poisoning is a simplistic one, whereby, for each IP address, it maintains an undefined MAC address in the cache. While this algorithm ensures safety by never associating an incorrect MAC address, it renders network communication effectively impossible. The crux of this proof hinges on the absence of a reliable authenticator, which could verify the source of a message.

Regarding the ArpON algorithm, when implemented across hosts within a LAN, it can be formally represented as an infinite-state reactive parameterized system. In [11], we employed model checking, utilizing the MCMT tool [24], to model both the actions performed by a process employing the algorithm and potential malicious behaviors exhibited by attackers. The safety property, verified by MCMT for any number of hosts within the LAN, guarantees that in the event of cache poisoning (as indicated by the aforementioned impossibility result), ArpON consistently and successfully eradicates it. This property aligns with the concept of ‘self-healing’ seen in industrial networks, as discussed in Section 2. Furthermore, the performance evaluation discussed in Section 5 reveals that the elimination of poisonings occurs in less than a millisecond, ensuring the requisite “promptness”, another crucial requirement in the context of industrial networks, as elaborated in Section 2.

4.3. Implementation aspects

The ARP protocol, as defined in the network kernel subsystem, consists of two main components: (1) ARP cache management and (2) I/O ARP functions (Fig. 1). The first component updates the ARP cache based on ARP network traffic observations, while the second component manages ARP packet transmission operations for each network interface present in the host machine.

For ArpON to function properly, it needs to handle the ARP requests/replies associated with a specific network interface and apply its own policies rules. To achieve this, ArpON modifies the arp_ignore and arp_accept parameters in the proc filesystem. These parameters enable ArpON to exclusively operate on ARP packets for a specific network interface and are configured by the sysadmin to dictate ARP behavior in response to ARP requests and ARP gratuitous announces.

By setting arp_ignore, ArpON is capable of intercepting any ARP request and preventing the kernel from answering these packets. In this manner, ArpON can apply its own detection rules without any kernel interference and respond to ARP packets as dictated by its policies. All other ARP operations and protocol features are handled by the network kernel subsystem, in accordance with the ARP protocol standard.

For each network interface, the system spawns an ArpON instance (e.g., a user space application) that is responsible for sending and receiving ARP packets. Specifically, ArpON exclusively handles the sending of ARP reply packets when a request ARP packet has been received. The ARP cache is handled by both ArpON and the network kernel subsystem, based on the detection rules previously described.

It is important to note that ArpON only modifies some network function calls related to interception and leaves all other operations to the kernel subsystem. This design allows for easy deployment of ArpON on a vast majority of operating systems and permits coexistence with other detection systems without requiring complex authentication among network devices.

5. Experimental evaluation

To assess the applicability of ArpON within ICSs, we conduct a comprehensive evaluation, scrutinizing both its effectiveness and efficiency when compared to the original ARP protocol. Our evaluation specifically emphasizes the unique characteristics and requisites of industrial networks, as detailed in Section 2.1. There are two potential approaches for conducting this evaluation:

Emulated Network using Virtual Machines (VMs): This approach involves testing the considered protocols within an emulated network environment created using multiple virtual machines running on a few physical hosts. However, this method falls short when it comes to replicating the behavior of large LANs typical of ICS environments, which often comprise tens or even hundreds of devices. Additionally, the elevated resource contention among multiple VMs sharing the same physical host may introduce variability in the measured performance metrics, particularly concerning protocol-induced overhead and delays.

Network Simulation: Given these considerations, we have chosen the latter approach, utilizing OMNET $+ +$ , a well-established and consistently maintained network simulator widely recognized for its reliability and extensive use in research. In this section, we present the outcomes of our performance evaluation, which involves modeling ArpON within the OMNET $+ +$ network simulator (version 5.1.1) in conjunction with the INET Framework (version 3.6.4) [65].

We commence by delineating the network topologies considered and the protocol stack employed in our models. Subsequently, we delve into the examination of various attack scenarios. We introduce a set of performance metrics, aligning with the specific attributes of industrial networks outlined in Section 2.1. Finally, we provide a comprehensive analysis of the simulation results.

5.1. Network and protocols configuration

The network under consideration consists of N identical hosts connected in a network. Looking at the documentation of industrial network equipment producers [19,20,66,67], three topologies are usually adopted: star, ring, or linear. The star topology (that may also represent wireless networks with thin devices communicating via an access point) has the central point usually settled in the PLC; it supplies greater reliability, resilience, real time timeliness and lower probability of bottlenecks than the other two schemes. The linear topology, for cabled networks, is less expensive than the star but less performant under the other aspects. The ring topology is intermediate between the other two.

In most of the presented simulations, a star topology was considered with a central switch; but we also considered a linear topology in some experiments. Each host implements a protocol stack consisting of UDP, IP, ARP, and Fast Ethernet (100 Mbps) at the MAC layer. Each host runs two applications as it may act as both a source and destination for UDP messages.

The simulations run for 3600 seconds of simulated time with varying number of hosts N, ranging from 10 to 150. As a source, a host generates a new message with an exponential distribution with a parameter of 15 s, and selects a random destination according to a uniform distribution. If an ARP cache entry for the message destination does not exist, then either ARP or ArpON is run to find out the correspondence. During the initialization phase, each node uploads the correct correspondence between IP and MAC addresses of all nodes from a file. This information is used throughout the simulation for measurement purposes only, so as to detect the start and end of poisonings (if a correct information overwrites a poisoned one). In this phase, one of the nodes is randomly selected to act as the attacker for the entire simulation. All updates to the ARP caches are performed either according to ARP (modeled as per RFC 826 [45]) or ArpON. Each ARP cache entry has a lifetime of 120 seconds before it expires.

Table 1 summarises the configuration parameters used in the simulations.

Table 1
Configuration parameters used in the simulations

Topologies Star, linear

Number of hosts $N \in {10, 25, 50, 75, 100, 125, 150}$

Number of message sources N

Message generation rate Exponential distribution with $λ =$ 15 s

Message destination choice Uniform distribution over ${1, N}$

Number of attackers 1, randomly chosen over the N nodes

Attack strategies Unsolicited reply, gratuitous announce

Attack rate Exponential distribution with parameter $τ \in {\infty, 900, 600, 300, 90}$ s

Victim and target choice Uniform distribution over ${1, N}$

Attack duration 6–7 minutes

ARP cache lifetime 120 s

Simulated time 3600 s

5.2. MITM attack modelling

As explained in Section 2.4, there are two ways to perform ARP cache poisoning:

poisoning a single cache, by crafting either an ARP request or reply containing a mistaken correspondence $⟨ {MAC}_{y}, {IP}_{x} ⟩$ apparently generated by a host with network address ${IP}_{x}$ ;

poisoning the caches of all hosts already owning a correspondence for ${IP}_{x}$ , by crafting a gratuitous ARP message containing a mistaken correspondence $⟨ {MAC}_{y}, {IP}_{x} ⟩$ apparently generated by host with network address ${IP}_{x}$ .

The latter way can trivially achieve a much more disruptive effect than the former, increasing with time and the consequent population of the ARP tables.

Both ways were modeled in the simulated networks, for both ARP and ArpON. In each simulation, just one strategy of attack is considered in order not to mix up their effects and ease the interpretation of the results. In case (a), a full MITM attack is perpetrated via unsolicited replies: the two selected hosts are simultaneously victims and targets, and the attacker generates an unsolicited reply to both of them; renewals are as well sent to both nodes at the same time. In case (b), a half MITM attack is perpetrated via gratuitous announces.

When an attack is started, the attacker randomly extracts – with uniform distribution – and records the identity of both a target node and a victim, and repeats the attack every 110 s so as to avoid the removal of the poisoned information from the ARP cache of the target(s); this is repeated three times, thus achieving an attempted attack duration of around 6–7 minutes. When an attack finishes, the attacker schedules the time to start the next attack according to an exponential distribution with variable parameter τ. For both kinds of attacks, the aggressiveness of the attacker was determined by changing the value of τ in between 60 s and 900 s. The value $τ = \infty$ represents the case of no attacks, used as a benchmark.

It is worth to notice that the identity of node y is not relevant, be it either the attacker itself or a further node different from both victims and targets. In the simulation, y is the attacker itself. Though, there is no loss of generality with this setting, as ArpON is – unavoidably – blind to the identities of the involved nodes; it simply reacts to the insertion of a non-requested correspondence into the cache. In the experiments, we were just interested in observing whether and how long a poisoning occurs.

5.3. Performance indexes

The performance evaluation centers around the unique characteristics of industrial networks detailed in Section 2.1. Specifically, we scrutinize three critical aspects:

Scalability and Minimal Overhead: We assess the system’s ability to handle increasing loads while maintaining low computational and resource demands.

Resilience to Poisoning Attacks: We examine the system’s capacity to withstand and recover from ARP poisoning attempts, ensuring network integrity.

Autonomic and Self-Healing Capabilities with Prompt Response: We evaluate the system’s self-correction abilities and its speed in mitigating disruptions, aligning with the requirement for swift healing in industrial network environments.

As far as robustness to poisonings is concerned, the following indexes are analysed in Section 5.4:

number of either poisoned gratuitous announces or unsolicited replies sent: these messages carry an attack, but in ArpON this does not necessarily lead to a cache poisoning, as explained in Section 4. This index gauges the virulence of the attacks;

number of cache poisonings: it measures the probability of success of the attacks.

As far as autonomic and self-healing capabilities and healing promptness are concerned, the following index is analysed in Section 5.5: duration of cache poisonings.

As far as scalability and system overhead are concerned, the following indexes are analysed in Section 5.6:

number of sent ARP requests and replies, which in ArpON include those generated for verification of a certain IP address, which measures the network communication overhead;

load on the switch, in terms of sent/received bits per second, which measures the switch communication overhead;

length of the switch queues on the network interfaces, which accounts for the switch memory overhead.

As far as the promptness is concerned, the following index is analysed in Section 5.7: address resolution latency.

Fig. 2.

ARP: average number of cache poisoning suffered by a host (a) with variable number of hosts and $τ = 300$ , and (b) with variable τ and 75 hosts.

5.4. Robustness to poisonings

As far as ArpON is concerned, in the performed simulations with the star topology no cache poisoning has ever been observed. By contrast, ARP was heavily affected. Figure 2 shows the number of ARP cache poisonings suffered by a host running ARP,1

¹
Three renewals of the same attack are counted as 3 poisonings, of roughly 2 minutes each.

averaged on all hosts and for both types of attacks. It can be appreciated the virulence of attacks carried out with gratuitous announces with respect to unsolicited replies. The number of generated gratuitous announces was in between 17 and 23 with fixed τ and variable N, and in between 9 and 25 for decreasing τ and

N = 75

. When the average approaches the number of attacks – as shown in the graphs – it means that most nodes undergo a cache poisoning with almost every attack. The virulence obviously grows with the frequency of the attacks (decreasing τ), while it decreases in larger networks because there is a higher probability that some hosts remain unaffected since they do not own a correspondence for the victim in their caches.

In Fig. 3(a), the percentage of targets poisoned by a gratuitous announce is shown in a sample case (125 hosts and $τ = 300$ s), as a function of the simulation time. In spite of being different attacks, the growth is stable and depends on the progressive population of the caches as time progresses.

Fig. 3.

(a) ARP: percentage of hosts poisoned via gratuitous announces, in case of 125 hosts in the LAN and $τ = 300$ s. (b) Occurrence of cache poisonings with ArpON and emulated linear topology.

In the case of attacks carried out with unsolicited replies, the lowest average for fixed τ and $N = 150$ hosts equals 0.24 attacks, while with fixed N it is included between 0.71 (with $τ = 90$ s) and 0.27 (with $τ = 900$ s). The average is very low because many nodes are never chosen as the target throughout the simulation, in particular with large networks where the target is extracted from a larger set. In this scheme, the attacker generates between 30 and 36 poisoned unsolicited replies in case of $τ = 300$ and variable N: since we model full MITM and three renewals for each attack, this means that 5–6 different pairs of target/victim hosts are subject of an attack throughout a simulation. Figure 2(a) also shows the maximum number of attacks suffered by nodes (dotted line) throughout the simulation, which is higher for smaller N as a node has a greater probability of being selected as target. In the case of variable τ, the attacker generates between 20 and 52 poisoned unsolicited replies (3 to 9 pairs attacked throughout a simulation).

In Section 4, the possibility of a transient flaw of ArpON has been explained. In order to be able to evaluate the impact of this event, an ad-hoc setting was reproduced, emulating a linear topology with connected in order target ⇆ attacker ⇆ victim, that is, the victim is further away than the attacker from the target. In the emulation, the 3 hosts are connected to the same switch; yet, both the target and the attacker are connected to the switch via FastEthernet (100 Mbps) links, while – in order to artificially magnify the distance between the victim and the target – the victim is connected to the switch via an Ethernet (10 Mbps) link. Hence, the victim receives ARP requests after the attacker, and its replies take more time to go back to the target, essentially reproducing the race condition described in Section 4.1. For the sake of clarity, in this case attacks are not renewed. With this scheme, also ArpON is affected by the occurrences of ARP cache poisonings, as shown by Fig. 3(b) along the simulation time.

Fig. 4.

(a) Zoom of a single poisoning event with ArpON in the emulated linear topology. (b) Cumulative distribution of the duration of ARP cache poisoning in case of unsolicited replies, with variable τ and 75 hosts.

5.5. Autonomic and self-healing capabilities

As anticipated in Section 4.2 and formally proved in [11], ArpON is able to remove cache poisonings and self-heal. In Fig. 4(a), a zoom of a particular attack affecting ArpON hosts in the emulated linear topology shows that the observed cache poisonings last 0.10548 ms, which account for the difference in transmission times of a packet of around 50 bytes along links with the considered heterogeneous bit rates. Since ARP cache poisoning is removed in less than milliseconds, the capability of an attacker of stealing sensitive information in the meantime is limited to a very large extent.

By contrast, standard ARP is not able to remove poisonings, thus paving the way to attacks that can last a long time and therefore potentially cause severe damage to the infrastructure. In case of full MITM attacks perpetrated using unsolicited replies, Fig. 4(b) shows the cumulative distribution of the duration of the poisonings that affected ARP caches, in case of 75 hosts in the LAN and variable τ. The graph shows that 60–80% of the poisonings are resolved before the expiration of the cache entry, due to the reception of an ARP message from the victim of the poisoning, which generates a UDP message and broadcasts a request trying to resolve the IP address of the message destination. In average, these poisonings last 38.99 s (five orders of magnitude more than with ArpON); all the UDP traffic addressed to the victim and generated by the target in the meanwhile is actually intercepted by the attacker. Moreover, 20–40% of the attacks last more than or equal to 120 s; they correspond to either attacks successfully renewed by the attacker, or to entries removed only when the target generates a UDP message for the victim after the cache entry expiration, invalidates the entry, and generates a new request to refresh the entry. The average duration of those poisonings equals 224.1 s.

Figure 5(a) reports a similar behaviour in case of unsolicited replies, $τ = 300$ s and variable number of hosts. Short poisonings last in average 41.5 s, while long poisonings have an average duration of 215.4 s.

A similar behavior is observed with attacks perpetrated via gratuitous announces (Fig. 5(b)). In this case, all measures are averaged over a greater number of affected nodes, which as a consequence (i) lowers the result for short poisonings removed by several nodes at a time when the victim of the attack generates a UDP message, and its request to resolve the message destination IP address arrives to the (multiple) poisoned hosts; while (ii) increases the result in case of poisonings not removed by multiple nodes. In fact, the difference between the two values is magnified with respect to the previous cases: short poisonings last 36.9 s in average, while long poisonings last 232.2 s.

Fig. 5.

(a) Cumulative distribution of the duration of ARP cache poisoning in case of full MITM attack via unsolicited replies with $τ = 300$ s and variable number of hosts. (b) Cumulative distribution of the duration of ARP cache poisoning in case of gratuitous announces, with variable τ and 75 hosts.

Table 2

Number of sent ARP replies for both protocols, with $τ = 300$ , $N = 75$ hosts, and attacks perpetrated via unsolicited replies

Protocol	Hosts	Mean	σ	Max	Min	Range	IQR
ARP	Attacked	65.8	14.25	88	42	46	21
ARP	Not attacked	68.3	11.19	93	48	45	14
ArpON	Attacked	393.8	8.49	410	379	31	9
ArpON	Not attacked	395.1	15.13	434	368	66	20

5.6. Scalability and system overhead

Communication overhead. Since the choice of both UDP message sources and destinations is uniform, the need of resolving IP addresses is evenly distributed across nodes, and for each host the number of sent ARP requests and replies is always almost equal.

In case of full MITM perpetrated through unsolicited replies, load balancing is also observed among the nodes with both protocols. Table 2 shows – for both protocols and for both attacked and non-attacked hosts – the average number of replies sent by a node throughout the simulation, the standard deviation σ, the max and min values, the range (difference between max and min), and the interquartile range (IQR). These indexes prove the scarce variability among hosts. In all cases, 6 pairs of nodes were involved in the attacks. Yet, ArpON generates more traffic since every potentially dangerous message – be it actually poisoned or not – raises a verification. The indexes do not differ too much when considering the number of sent requests, nor – for what we just said – when changing τ.

Fig. 6.

Average number of both sent replies and requests for both ARP and ArpON, with variable number of nodes and full MITM attack via unsolicited replies and $τ = 300$ s.

Fig. 7.

Number of both sent requests and replies for ArpON, in case of attacks perpetrated using gratuitous announces, (a) with variable number of hosts and $τ = 300$ s; (b) with variable τ and 75 hosts in the LAN.

By contrast, the performance is affected by the variable number of hosts, as each host can generate UDP messages that may raise an address resolution. In Fig. 6, the number of both sent requests and sent replies is shown for both protocols, in case of full MITM attacks via unsolicited replies and $τ = 300$ s. Yet, the traffic due to the verification requests sent by ArpON does not grow exponentially; on the contrary the ratio between ArpON and ARP is roughly constant between 4 and 6 as shown by the secondary curves in the plot. Moreover, the traffic load is easily disposed; indeed, the maximum observed length of ArpON queues of outpending messages in the hosts is 2: one for a possible UDP message sent by the node (for which the destination address is under resolution) and one for a contemporary ARP message carrying a correspondence to be verified.

Things change when malicious gratuitous announces are sent. While the behavior of ARP obviously stays comparable, the fact that gratuitous announces simultaneously try to poison the ARP cache of several hosts, and all of them broadcast verification requests to avoid this event, make ArpON performance depend on both the number of hosts (Fig. 7(a)) and the arrival of messages, which is more frequent for more frequent attacks (lower τ, Fig. 7(b)). The generated traffic for the highest frequency of attack is 10.6% greater than without any attack. Moreover, the generation of ARP messages is unfairly distributed on nodes, differently from the previous case, as shown in Table 3: the hosts chosen as victims (6 in our simulations) generate $50 %$ ARP messages more than non-attacked hosts due to the verification requests generated by other hosts (up to N) and to which they have to reply.

Table 3

Number of sent ARP replies for both protocols, with $τ = 300$ , $N = 75$ hosts, and attacks perpetrated via gratuitous announces

Protocol	Hosts	Mean	σ	Max	Min	Range	IQR
ARP	Attacked	68.8	17.58	99	50	49	25.5
ARP	Not attacked	68.1	12.85	95	37	58	18
ArpON	Attacked	609.5	15.06	629	584	45	19
ArpON	Not attacked	406.6	13.03	444	373	71	18

Memory and computation overhead in the switch / PLC. As a consequence of the higher traffic generated by ArpON, the central switch of the star topology – which often is also the PLC of the industrial network – might become a bottleneck. Moreover, as every message in ArpON is broadcast, the switch replicates it to all its interfaces. In Fig. 8, the length of the queue associated to a switch interface is shown along simulation time, in case of attacks via gratuitous announces with $N = 50$ hosts and $τ = 300$ s. In the graph, spikes reach the number of hosts in the network; they are grouped in sets of three due to the renewal of an attack against a certain victim for three times (Section 5.2).

Fig. 8.

Length of the queue associated to a switch interface, along time.

Actually, in the considered schemes the switch never experiences overload. In Fig. 9(a), the amount of traffic either received or sent by the switch, averaged on all its interfaces, is shown in case of attacks perpetrated via gratuitous announces, $τ = 300$ s, and variable number of hosts. The outbound traffic in the switch interfaces is always less than 20 Kbps also with the largest network and in spite of the re-broadcasting of ArpON messages; it is thus perfectly supported also with a conservative estimate of available bandwidth limited to 100 Mbps. With ARP, the slight increase in outbound messages for larger networks is an effect of the cold start phase when the switch has yet to populate its routing table and initially broadcasts every data till it learns what destination is attached to each interface. For both protocols, the inbound traffic is always very low. The difference between the two protocols accounts for the verification requests sent by ArpON.

Fig. 9.

(a) Amount of traffic in the switch for both ARP and ArpON; (b) End-to-end delay for both ARP and ArpON, with variable number of nodes, $τ = 300$ s and attacks perpetrated via gratuitous announces.

Table 4

Switch performance with ArpON, in case of 75 hosts, and gratuitous announces attack with variable τ

τ	∞	900 s.	600 s.	300 s.	90 s.
Queue length	0.50	3.47	5.36	6.25	8.26
Bits/s received	153.4	157.6	159.9	161.6	165.2
Bits/s sent	8333.5	8645.2	8823.2	8946.9	9211.0

The queue length and the amount of traffic is almost constant with ARP when varying τ for fixed number of nodes, for both unsolicited replies and gratuitous announces: the average length of the switch queues is always slightly lower than 0.5 with ARP. With the analyzed values of τ, this also holds with ArpON when unsolicited replies are generated, indicating that queues are emptied before the next attack occurs. In case of gratuitous announces, the queues grow but not dramatically, as shown in Table 4 where all results are averaged over all the switch interfaces.

5.7. Promptness

Despite the higher amount of traffic generated by ArpON compared to ARP, message latency is not affected and therefore neither is the timeliness of the industrial network communications. Figure 9(b) shows the end-to-end latency, measured as time elapsed from the generation of a UDP message requiring an address resolution till its transmission when the resolution as been accomplished; results refer to a variable number of hosts in the LAN, $τ = 300$ s and attacks perpetrated via gratuitous announces. The latency of ArpON is of the order of 20 μs greater than that of ARP for the largest considered LAN.

6. Related work

Numerous defensive mechanisms have been put forth in the literature to counter cache poisoning attacks, primarily falling into two categories: (1) static and (2) dynamic.

Static approaches, as exemplified in works such as [1] and [31], prove to be effective by relying on predetermined, unalterable entries in the ARP cache. These entries, immune to updates via ARP replies, can solely be modified through manual intervention by the system administrator. Nonetheless, this method faces scalability challenges, particularly in networks with a substantial number of hosts, such as those found in industrial environments. In such cases, the manual insertion of entries on each host or device becomes impractical.

Another well-established static defense method is known as “Port Security” [50]. This technique leverages features present in many modern network devices, allowing them to recognize and authorize only a single MAC address on a specific physical port. While this protection can prove effective against certain attack vectors, it may fall short in countering specific variants of ARP poisoning attacks where the attacker abstains from spoofing their own MAC address, opting instead to poison the ARP caches of two targets. Consequently, such defensive mechanisms may exhibit inefficacy in these scenarios. However, ArpON addresses this limitation by implementing cache entry validation through a stateful prevention protocol, thereby enhancing its capability to thwart these types of attacks.

Additional defenses that deviate from relying solely on ARP behavior are integrated into Intrusion Detection Systems (IDSs) [25,40] and personal firewalls [48]. These protective mechanisms operate by continuously monitoring network traffic and typically notify the user when an ARP cache entry undergoes alteration. Although such systems can offer value in specific scenarios, they often place the ultimate decision-making responsibility on the user, who may lack awareness of intricate network security issues, resulting in suboptimal responses to potential threats.

In the realm of dynamic defenses, proactive mechanisms aim to identify irregularities gleaned from protocol observations. Solutions like Arpwatch [35] and ARPalert [7] are examples of such tools designed to mitigate ARP poisoning attacks. However, a notable limitation of these approaches is their inability to preemptively prevent attacks. This becomes particularly critical in expansive networks, where an abundance of false positives can overwhelm network administrators, necessitating the arduous task of sifting through numerous messages to distinguish genuine threats from false alarms [43]. In stark contrast, ArpON sets itself apart by operating without the need for pre-configurations or manual intervention, effectively thwarting ARP spoofing attacks. This unique feature renders it highly suitable for large-scale networks, including those housing devices with minimal or no user interaction, such as sensors within industrial infrastructures.

Alternative solutions harness kernel patches and network traffic monitoring to bolster their defenses. For instance, Anticap [9] adopts a strategy that refrains from updating the ARP cache when an ARP reply carries a MAC address diverging from the one already stored for a given IP. It further triggers a kernel alert to notify of potential ARP cache poisoning attempts. Notably, this approach contrasts with ARP specifications, as it discards legitimate gratuitous ARP messages. In contrast, Antidote [60] offers a more intricate defense mechanism. Upon receiving a new ARP reply indicating a change in a <IP, MAC> pair, it endeavors to ascertain whether the previous MAC address remains active. If the prior MAC address responds to the query, the update is rejected, and the new MAC address is blacklisted. However, it is worth noting that Antidote’s susceptibility to MAC address spoofing could allow a host to coerce another host into blacklisting a target. Finally, in [64], a solution featuring two distinct queues – one for requested addresses and the other for received replies – is proposed. This system discards ARP replies if the corresponding request was never dispatched (absent from the queue). Additionally, in the received queue, replies with IP addresses already associated with different MAC addresses are also rejected, enhancing security through rigorous address validation.

All these solutions share a common limitation, as anticipated in Section 4.1: if a malicious ARP reply arrives before the legitimate one, as can happen in a real request scenario, the target’s cache may inadvertently store the incorrect reply, allowing the attack to succeed. This situation essentially creates a race condition, with the attacker and victim vying to influence the cache contents. When the initial ARP request is broadcast, both the victim and the attacker receive the message. The party that responds first gains control until the cache entry expires. Moreover, the attacker can employ a tactic involving the spoofing of an ICMP echo request message, swiftly followed by a counterfeit ARP reply. When the target, denoted as t, receives the ICMP echo request, it triggers an ARP request. However, the spurious ARP reply is already present in its received packet queue, causing t to accept it as a valid response. Cisco switches introduced a security feature called Dynamic ARP Inspection [16], utilizing a local pairing table established through DHCP snooping to identify and block invalid $⟨ IP, MAC ⟩$ bindings. Nevertheless, this method carries a significant drawback in terms of the high cost of switches, rendering it an ineffective solution in many cases. In contrast, ArpON operates without dependence on specific device features and employs a stateful protocol to circumvent race conditions and unsafe states, thereby providing a robust defense mechanism.

XArp [68] stands as a robust defense mechanism offering highly adaptable ARP spoofing detection capabilities. It incorporates both active and passive techniques to identify potential hackers within the network. However, a drawback of this method lies in its reliance on continuous traffic monitoring, leading to a substantial computational overhead. In contrast, ArpON operates more efficiently, as it merely intercepts ARP update packets rather than continuously scrutinizing the entirety of network traffic, making it a less resource-intensive and more streamlined solution

S-ARP [12] and TARP [37] adopt asymmetric cryptography and an Authoritative Key Distributor to establish the authenticity of ARP messages. TARP [37] introduces a signed attestation, attaching addresses to a public key or ticket, and digitally signs messages at the sender’s end, thereby thwarting attempts to inject spoofed information. Nevertheless, implementing key management at the data link layer can be intricate, and S-ARP’s incompatibility with legacy code due to a divergent packet format from the ARP-Packet format defined in [45] adds to its challenges. Conversely, Arpsec [61] relies on Trusted Platform Module (TPM) attestation to ensure trust in remote hosts. However, this system necessitates both TPM hardware features on each host and robust key management support, features that may be absent in ICSs and embedded systems characterized by limited computational resources. As highlighted earlier, ArpON operates independently of these features, rendering it a suitable choice for safeguarding platforms where such capabilities may be lacking.

Nam et al. introduced an advanced ARP detection mechanism known as MR-ARP [39], which offers protection against ARP poisoning Man-in-the-Middle (MITM) attacks through a voting-based approach. When ARP request or reply messages contain a MAC address mismatched with the one recorded in the ARP cache for a specific IP address, MR-ARP solicits neighboring nodes to cast votes in favor of the new IP address, facilitating the determination of the corresponding MAC address. However, the effectiveness of this voting mechanism relies on the condition that the voting traffic rates among the responsive nodes are nearly identical. This requirement may not hold true in wireless networks due to traffic rate adaptations influenced by signal-to-noise ratio (SNR), specifically auto rate fallback (ARF). In contrast, our proposed approach operates independently of the underlying data-transmitting medium, making it a versatile solution applicable across various network configurations.

Recent studies have explored the potential of harnessing machine learning (ML) techniques for the detection of ARP poisoning attacks, as evidenced in works like [8,30,33]. This approach can yield commendable accuracy performance contingent upon the selected ML algorithm. However, its practical implementation on real devices may entail significant computational overhead, as observed with CPU utilization reaching 97% in [3]. Furthermore, the detection latency in such ML-based solutions can extend to the order of tens of milliseconds, as demonstrated by detection times within 63 ms in [3]. Consequently, these solutions may not be viable for resource-constrained industrial devices and may fall short in meeting the stringent latency requirements of Industry 4.0 communications. In contrast, our proposed solution excels in swiftly addressing ARP poisoning, with removal occurring in less than a millisecond when prevention measures are not in place.

Classical attacks, including ARP spoofing, are emerging as growing concerns with the deployment of novel infrastructures that embrace IoT and Industry 4.0 paradigms [13,29,47]. While the literature has seen several works dedicated to addressing the vulnerabilities of SCADA systems [18,21,49], traditional remedies such as cryptography [13,59,62] and IDSs [32,44,46] have been proposed. For instance, in [41], an IDS was implemented on an edge node (sensor) within an ICS infrastructure, successfully detecting ARP poisonings but not preventing them. However, this approach incurred a significant increase in latency, tripling the latency while reducing throughput to less than one-sixth with the IDS. In contrast, the solution presented in this work imposes minimal overhead and performance degradation on the communication network. Moreover, it effectively prevents and rectifies ARP cache poisonings, all without the need for human intervention.

This recent paper [38] shows a comprehensive exploration of ARP spoofing attacks and related research is undertaken. The article introduces an effective method based on the ICMP protocol to identify malicious hosts involved in ARP spoofing attacks. This technique involves the collection and analysis of ARP packets, followed by the injection of ICMP echo request packets to detect malicious hosts based on their response packets. Importantly, this method operates without disrupting the normal network operations of other hosts and can even identify the true address mappings during an attack. However, the associated increase in bandwidth costs renders this approach impractical for ICS networks.

Within the realm of SDN, various innovative solutions have emerged. For example in [26], a novel ARP enhancement is introduced to thwart MITM attacks, even in both wired and wireless LAN environments. The study employs computer simulations to showcase the exceptional performance of this proposed method. This research emphasizes the potential for enhancing overall network security through the incorporation of SDN, highlighting the importance of considering an SDN-based security strategy and conducting a thorough analysis of security factors.

Additionally, the paper [52] evaluates the existing security landscape and outlines strategies for enhancing it using SDN technology. Furthermore, [53] conducts a performance analysis of SDN using the Mininet emulator, where the centralized controller makes routing decisions while switches handle packet forwarding. The benefits of SDN, particularly in addressing ARP spoofing and ARP cache poisoning attacks commonly found in LAN networks, are emphasized in [2], underlining how SDN can mitigate these issues without requiring extensive modifications to the network. Despite such interesting results, the suitability of SDN for ICS depends on factors such as network size, criticality of operations, and specific security and performance requirements that cannot be always satisfied.

7. Security analysis

Fig. 10.

HARPI-mode dynamic defense against a MITM attack.

To assess the effectiveness of our approach, we utilize the widely recognized penetration test suite [55], referred to as Dsniff, for conducting MITM attacks using the ARP protocol with various configurations. Initially, we replicate a scenario where Dsniff is installed on an attacker machine (IP: 10.0.0.10/16), while two benign machines (IPs: 10.0.1.1/16 and 10.0.10.1/16) do not have our tool (ArpON) activated. In this particular setup, the attacker machine effectively hijacks communication between the two hosts and monitors all network packets associated with their communication. Subsequently, we proceed to install and execute ArpON on each machine, after which we recommence the MITM attack.

Figure 10 visually illustrates the response of ArpON in the HARPI mode when subjected to an attack. The network configuration comprises two hosts: machine A (IP: 10.0.1.1, MAC: 58:ac:78:88:1a:bb) and machine B (IP: 10.0.10.1, MAC: 90:94:e4:7e:f4:59), an attacker-host C (IP: 10.0.0.10, MAC: d4:be:d9:fe:8b:45), and a default gateway D (IP: 10.0.10.254, MAC: c8:f7:33:dd:8b:c9) serving as the gateway to the Internet. Machines A and B are equipped with ArpON configured in HARPI mode. Specifically, machine A has statically inserted the address of machine D into its ARP cache, treating the address of machine B as dynamic. Subsequently, it initiates the execution of ArpON, as evidenced by the following log:

The same operations are performed by machine B that runs ArpON in HARPI mode.

Subsequently, the attacker host (machine C) initiates a full-duplex MITM attack to intercept both communication channels: A-C-B and B-C-A.2

Various publicly available tools can be employed for this attack; in our case, we utilize arpspoof.

Detailed information regarding this attack is documented in the following log.

The attack initiates the generation of two ARP reply packets directed towards 10.0.1.1 and 10.0.10.1, intended to update the ARP cache of the victim hosts, as depicted in Fig. 10. Upon receiving the ARP reply packet from machine A, ArpON takes control and follows the protocol outlined in Section 4.

To elaborate further, if the ArpON cache is found to be empty (as is the case here), host A dispatches an ARP request to 10.0.10.1. It then removes the corresponding entry from the ARP cache (utilizing the deny operation) and logs the association (10.0.10.1, timestamp) in the ArpON cache. Parallel operations are carried out on machine B, using the IP address 10.0.1.1, mirroring the process outlined in Fig. 10 (second step). Subsequently, both machines receive ARP requests from each other. Given that the ArpON cache contains an entry linked to the sender, host A transmits an ARP reply packet to machine B and enforces the deny operation on the ARP cache. Machine B follows suit with identical operations, as demonstrated in Fig. 10 (third step).

Finally, both machines receive ARP reply packets. At this juncture, with the ArpON cache containing an entry associated with the sender’s address, ArpON removes the entry from the ArpON cache and records the new association between MAC address and IP address in the ARP cache (utilizing the allow operation). Such an entry is then validated by the legitimate host, thereby superseding the frames, we present the attack detection logs for both machine A and machine B.

8. Conclusions

In our research, we confront the persistent challenge of ARP cache poisoning attacks within Industry 4.0 Ethernet networks, a longstanding threat that persists due to the gradual transition to all-IPv6 networks and the expanding adoption of Industry 4.0 applications employing variations of the Ethernet protocol. To address this issue, we introduce ArpON, an innovative suite of protocols designed to seamlessly integrate with traditional ARP implementations while circumventing the need for costly or impractical cryptographic techniques. We rigorously assess ArpON’s performance through extensive simulations conducted across diverse scenarios. Our findings reveal that ArpON effectively mitigates ARP poisoning attacks with a high degree of success. In the rare instances where attacks manage to breach the defenses, ArpON swiftly rectifies ARP cache poisoning in less than a millisecond. This achievement comes with a reasonable uptick in host and network device loads, all without compromising network latency – a pivotal factor in the context of industrial networks. As part of our future endeavors, we aim to implement a prototype of ArpON tailored for PLCs and delve deeper into exploring potential security challenges that may impact industrial Ethernet protocols.

Footnotes

Acknowledgment

This work was supported in part by Spoke 08 – Risk Management & Governance and Spoke 10 – Data Governance and Protection of Project “SEcurity and RIghts in the CyberSpace – SERICS” (PE00000014) under the National Recovery and Resilience Plan MUR Program funded by the European Union – NextGenerationEU.

Appendix

References

A.M.

Abdel Salam,

W.S.

Elkilani and

K.M.

Amin, An automated approach for preventing ARP spoofing attack using static ARP entries, International Journal of Advanced Computer Science and Applications(IJACSA) 5(1) (2014).

A.M.

AbdelSalam,

A.B.

El-Sisi and

Reddy, Mitigating ARP spoofing attacks in software-defined networks, in: 2015 25th International Conference on Computer Theory and Applications (ICCTA), IEEE, 2015, pp. 126–131. doi:10.1109/ICCTA37466.2015.9513433.

Ahuja,

Singal,

Mukhopadhyay and

Nehra, Ascertain the efficient machine learning approach to detect different ARP attacks, Computers and Electrical Engineering 99 (2022), 107757, https://www-sciencedirect-com-443.web.bisu.edu.cn/science/article/pii/S0045790622000647 . doi:10.1016/j.compeleceng.2022.107757.

Ainsworth,

Brake,

Gonzalez,

Toma and

A.F.

Browne, A comprehensive survey of industry 4.0, IIoT and areas of implementation, in: Proc. SoutheastCon, 2021, pp. 1–6, https://ieeexplore.ieee.org/abstract/document/9401860 . doi:10.1109/SoutheastCon45413.2021.9401860.

M.M.

Alani, Guide to OSI and TCP/IP Models, Springer, 2014. doi:10.1007/978-3-319-05152-9.

Arote and

K.V.

Arya, Detection and prevention against ARP poisoning attack using modified ICMP and voting, in: 2015 International Conference on Computational Intelligence and Networks, IEEE, 2015, pp. 136–141. doi:10.1109/CINE.2015.34.

Arpalert, ARP spoofing detector, www.arpalert.org.

D.J.

Atul,

Kamalraj,

Ramesh,

Sakthidasan Sankaran,

Sharma and

Khasim, A machine learning based IoT for providing an intrusion detection system for security, Microprocessors and Microsystems 82 (2021), 103741, https://www-sciencedirect-com-443.web.bisu.edu.cn/science/article/pii/S0141933120308863 . doi:10.1016/j.micpro.2020.103741.

Barnaba , Anticap, 2003, http://cvs.antifork.org/cvsweb.cgi/anticap.

10.

Bruschi,

Di Pasquale,

Ghilardi,

Lanzi and

Pagani, Formal verification of ARP (address resolution protocol) through SMT-based model checking-a case study, in: International Conference on Integrated Formal Methods, Springer, 2017, pp. 391–406. doi:10.1007/978-3-319-66845-1_26.

11.

Bruschi,

Di Pasquale,

Ghilardi,

Lanzi and

Pagani, A formal verification of ARPON – a tool for avoiding Man-in-the-Middle attacks in ethernet networks, IEEE Transactions on Dependable and Secure Computing (2022). doi:10.1109/TDSC.2021.3118448.

12.

Bruschi,

Ornaghi and

Rosti, S-ARP: A secure address resolution protocol, in: Computer Security Applications Conference, 2003. Proceedings. 19th Annual, IEEE, 2003, pp. 66–74. doi:10.1109/CSAC.2003.1254311.

13.

Chaudhary and

Prasad, IoT in healthcare sector – a comprehensive analysis of threats and privacy issues, 2022. doi:10.1063/5.0110596.

14.

Cheshire, IPv4 address conflict detection, RFC 5227, IETF, 2008, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc5227.txt.

15.

Cheshire,

Aboba and

Guttman, Dynamic configuration of IPv4 link-local addresses, RFC 3927, RFC Editor, 2005, https://rfc-editor.org/rfc/rfc3927.txt. doi:10.17487/rfc3927.

16.

CISCO, Cisco systems. “Configuring Dynamic Arp Inspection”. Catalyst 6500 Series Switch Cisco IOS Software Configuration guide, release 12.2SX. Chapter 39, 2003, http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/dynarp.html.

17.

Danielis,

Skodzik,

Altmann,

E.B.

Schweissguth,

Golatowski,

Timmermann and

Schacht, Survey on real-time communication via ethernet in industrial automation environments, in: Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), 2014, pp. 1–8. doi:10.1109/ETFA.2014.7005074.

18.

Deb,

S.R.

Chakraborty,

Lagineni and

Singh, Security analysis of MITM attack on SCADA network, in: Machine Learning, Image Processing, Network Security and Data Sciences, Springer, 2020, pp. 501–512. ISBN 978-981-15-6318-8.

19.

Djiev, Industrial network for communication and control (Ch. 5), Academia, last visited: 7 May 2022, https://www.academia.edu/8865431/Industrial_Networks.

20.

Emerson Electric Co., PACSystems RSTi-EP quick start guide, 2021, Last visited: 12 Sep., 2023, https://emerson-mas.my.site.com/communities/en_US/Documentation/PACSystems-RSTi-EP-EPSCPE115-CPU-Quick-Start-Guide-GFK-3039.

21.

Erdődi,

Kaliyar,

S.H.

Houmb,

Akbarzadeh and

A.J.

Waltoft-Olsen, Attacking power grid substations: An experiment demonstrating how to attack the SCADA protocol IEC 60870-5-104, in: Proc. 17th Int. Conf. Availability, Reliability and Security (AReS), ACM, 2022. ISBN 9781450396707. doi:10.1145/3538969.3544475.

22.

Fuchs,

H.-P.

Schmidt and

Witte, Test and on-line monitoring of real-time ethernet with mixed pysical layer for industry 4.0, in: 2016 IEEE 21st International Conference on Emerging Technologies and Factory Automation (ETFA), IEEE, 2016, pp. 1–4.

23.

Ghaleb,

Zhioua and

Almulhem, On PLC network security, International Journal of Critical Infrastructure Protection 22 (2018), 62–69. doi:10.1016/j.ijcip.2018.05.004.

24.

Ghilardi and

Ranise, MCMT: A model checker modulo theories, in: Proc. Int. Joint Conf. Automat. Reasoning, 2010, pp. 22–29. doi:10.1007/978-3-642-14203-1_3.

25.

Girdler and

V.G.

Vassilakis, Implementing an intrusion detection and prevention system using software-defined networking: Defending against ARP spoofing attacks and blacklisted MAC addresses, Computers and Electrical Engineering J. 90 (2021).

26.

H.Y.

Ibrahim,

P.M.

Ismael,

A.A.

Albabawat and

A.B.

Al-Khalil, A secure mechanism to prevent ARP spoofing and ARP broadcasting in SDN, in: 2020 International Conference on Computer Science and Software Engineering (CSASE), IEEE, 2020, pp. 13–19. doi:10.1109/CSASE48920.2020.9142092.

27.

Jasperneite,

Imtiaz,

Schumacher and

Weber, A proposal for a generic real-time ethernet system, IEEE Transactions on Industrial Informatics 5(2) (2009), 75–85. doi:10.1109/TII.2009.2017259.

28.

Kang,

Maynard,

McLaughlin,

Sezer,

Andrén,

Seitl,

Kupzog and

Strasser, Investigating cyber-physical attacks against IEC 61850 photovoltaic inverter installations, in: 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA), IEEE, 2015, pp. 1–8.

29.

N.M.

Karie,

N.M.

Sahri and

Haskell-Dowland, IoT threat detection advances, challenges and future directions, in: 2020 Workshop on Emerging Technologies for Security in IoT (ETSecIoT), 2020, pp. 22–29. doi:10.1109/ETSecIoT50046.2020.00009.

30.

Kaur, Wired LAN and wireless LAN attack detection using signature based and machine learning tools, in: Networking Communication and Data Knowledge Engineering, Springer, Singapore, 2018, pp. 15–24. ISBN 978-981-10-4585-1. doi:10.1007/978-981-10-4585-1_2.

31.

Kaur,

E.G.

Singh and

Khurana, A security approach to prevent ARP poisoning and defensive tools, International Journal of Computer and Communication System Engineering (IJCCSE) 2(3) (2015), 431–437.

32.

Kharitonov and

Zimmermann, WiP: Distributed intrusion detection system for TCP/IP-based connections in industrial environments using self-organizing maps, in: Applied Cryptography and Network Security Workshops, Springer International Publishing, 2021, pp. 231–251. ISBN 978-3-030-81645-2. doi:10.1007/978-3-030-81645-2_14.

33.

K.V.V.N.L.S.

Kiran,

R.N.K.

Devisetty,

N.P.

Kalyan,

Mukundini and

Karthi, Building a intrusion detection system for IoT environment using machine learning techniques, Procedia Computer Science 171 (2020), 2372–2379, https://www-sciencedirect-com-443.web.bisu.edu.cn/science/article/pii/S1877050920312497 . doi:10.1016/j.procs.2020.04.257.

34.

Kushner, The real story of Stuxnet, IEEE Spectrum (2013), https://spectrum.ieee.org/the-real-story-of-stuxnet.

35.

Lawrence Berkeley National Laboratory, ARPWATCH: ARP spoofing detector, ftp://ftp.ee.lbl.gov/ARPwatch.tar.gz.

36.

Lee,

Kim,

Kim and

P.D.

Yoo, Simulated attack on dnp3 protocol in scada system, in: Proceedings of the 31th Symposium on Cryptography and Information Security, Kagoshima, Japan, 2014, pp. 21–24.

37.

Lootah,

Enck and

McDaniel, TARP: Ticket-based address resolution protocol, Computer Networks 51(15) (2007), 4322–4337. doi:10.1016/j.comnet.2007.05.007.

38.

S.M.

Morsy and

Nashat, D-ARP: An efficient scheme to detect and prevent ARP spoofing, IEEE Access 10 (2022), 49142–49153. doi:10.1109/ACCESS.2022.3172329.

39.

S.Y.

Nam,

Djuraev and

Park, Collaborative approach to mitigating ARP poisoning-based man-in-the-middle attacks, Comput. Netw. 57(18) (2013), 3866–3884. doi:10.1016/j.comnet.2013.09.011.

40.

Neminath,

Biswas,

Roopa,

Ratti,

Nandi,

F.A.

Barbhuiya,

Sur and

Ramachandran, A DES approach to intrusion detection system for ARP spoofing attacks, in: Proc. 18th Mediterranean Conference on Control and Automation, 2010, pp. 695–700. doi:10.1109/MED.2010.5547790.

41.

Niedermaier,

Striegel,

Sauer,

Merli and

Sigl, Efficient intrusion detection on low-performance industrial IoT edge node devices, 2019. doi:10.48550/ARXIV.1908.03964.

42.

OpenPLC, OpenPLC documentation, 2022, Last visited: 5 July 2022, https://openplcproject.com/docs/openplc-overview/.

43.

A.P.

Ortega,

X.E.

Marcos,

L.D.

Chiang and

C.L.

Abad, Preventing ARP cache poisoning attacks: A proof of concept using OpenWrt, in: Network Operations and Management Symposium, 2009. LANOMS 2009. Latin American, IEEE, 2009, pp. 1–9.

44.

R.P.

Parameswarath,

C.Y.

Eugene,

N.V.

Abhishek,

T.J.

Lim and

Sikdar, Detecting selective forwarding using sentinels in clustered IoT networks, in: GLOBECOM 2020 – 2020 IEEE Global Communications Conference, 2020, pp. 1–6. doi:10.1109/GLOBECOM42002.2020.9322295.

45.

D.C.

Plummer, Ethernet address resolution protocol: Or converting network protocol addresses to 48.bit ethernet address for transmission on ethernet hardware, RFC 826, RFC Editor, 1982, https://rfc-editor.org/rfc/rfc826.txt. doi:10.17487/rfc826.

46.

Radoglou-Grammatikis,

Siniosoglou,

Liatifis,

Kourouniadis,

Rompolos and

Sarigiannidis, Implementation and detection of Modbus cyberattacks, in: 2020 9th International Conference on Modern Circuits and Systems Technologies (MOCAST), 2020, pp. 1–4. doi:10.1109/MOCAST49295.2020.9200287.

47.

Rajendran,

R.S.

Ragul Nivash,

P.P.

Parthy and

Balamurugan, Modern security threats in the Internet of Things (IoT): Attacks and countermeasures, in: 2019 International Carnahan Conference on Security Technology (ICCST), 2019, pp. 1–6. doi:10.1109/CCST.2019.8888399.

48.

Rash, Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort, No Starch Press, 2007.

49.

N.R.

Rodofile,

Radke and

Foo, Extending the cyber-attack landscape for SCADA-based critical infrastructure, International Journal of Critical Infrastructure Protection 25 (2019), 14–35. doi:10.1016/j.ijcip.2019.01.002.

50.

Schluting, Configure your Catalyst for a more secure layer 2, 2005, Last accessed: Nov. 9, 2022, https://www.enterprisenetworkingplanet.com/security/configure-your-catalyst-for-a-more-secure-layer-2/.

51.

Sharma,

Shamkuwar and

Ramdasi, Digital dimensions of industry 4.0: Opportunities for autonomic computing and applications, in: Autonomic Computing in Cloud Resource Management in Industry 4.0,

Choudhury,

B.K.

Dewangan,

Tomar,

B.K.

Singh,

T.T.

Toe and

N.G.

Nhu, eds, Springer International Publishing, 2021, pp. 347–383. ISBN 978-3-030-71756-8. doi:10.1007/978-3-030-71756-8_19.

52.

P.K.

Sharma and

Tyagi, Improving security through software defined networking (SDN): An SDN based model, IJRTE 8 (2019), 295–300. doi:10.35940/ijrte.D6814.118419.

53.

C.N.

Shivayogimath and

Uma Reddy, Performance analysis of a software defined network using mininet, in: Artificial Intelligence and Evolutionary Computations in Engineering Systems: Proceedings of ICAIECES 2015, Springer, 2016, pp. 391–398. doi:10.1007/978-81-322-2656-7_35.

54.

Siemens, IWLAN – the wireless LAN for demanding industrial applications, Last visited: 5 Sep. 2023, https://www.siemens.com/global/en/products/automation/industrial-communication/industrial-wireless-lan.html.

55.

Song, 2003, http://www.monkey.org/~dugsong/dsniff.

56.

StackExchange, Is there any point of arp spoofing on a wifi network?, Last visited: 5 Sep. 2023, https://security.stackexchange.com/questions/225985/is-there-any-point-of-arp-spoofing-on-a-wifi-network.

57.

StackExchange, ARP spoofing over WLAN, Last visited: 5 Sep. 2023, https://networkengineering.stackexchange.com/questions/60697/arp-spoofing-over-wlan.

58.

StackExchange, ARP poisoning between a wired and wireless network, Last visited: 5 Sep. 2023, https://security.stackexchange.com/questions/41961/arp-poisoning-between-a-wired-and-wireless-network.

59.

Stranahan,

Soni,

Carpenter and

Heydari, SCADA testbed implementation, attacks, and security solutions, in: Advances in Information and Communication, Springer, 2021, pp. 736–755. ISBN 978-3-030-73100-7. doi:10.1007/978-3-030-73100-7_53.

60.

Tetrin, Antidote, 2003, http://online.securityfocus.com/archive/1/299929.

61.

J.D.

Tian,

K.R.B.

Butler,

P.D.

McDaniel and

Krishnaswamy, Securing ARP from the ground up, in: Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, CODASPY ’15, ACM, New York, NY, USA, 2015, pp. 305–312. ISBN 978-1-4503-3191-3. doi:10.1145/2699026.2699123.

62.

Tidrea,

Korodi and

Silea, Cryptographic considerations for automation and SCADA systems using trusted platform modules, MDPI Sensors 19(19) (2019). doi:10.3390/s19194191.

63.

Tramarin and

Vitturi, Strategies and services for energy efficiency in real-time ethernet networks, IEEE Transactions on Industrial Informatics 11(3) (2015), 841–852. doi:10.1109/TII.2015.2426953.

64.

M.V.

Tripunitara and

Dutta, Middle approach to asynchronous and backward-compatible detection and prevention of ARP cache poisoning, Google Patents, 2004, Patent 6,771,649.

65.

Varga and

Hornig, An overview of the OMNET++ simulation environment, in: Proc. 1st Intl. ICST Conf. SIMUTOOLS, 2010. doi:10.4108/ICST.SIMUTOOLS2008.3027.

66.

Voss, Industrial ethernet guide – network topologies, in: A Comprehensible Guide to Industrial Ethernet, Copperhill Technologies, 2019, Online book, last visited: 7 Sep. 2023, https://copperhilltech.com/blog/industrial-ethernet-guide-network-topologies/.

67.

Voss, Industrial ethernet guide – topology and communication features, in: A Comprehensible Guide to Industrial Ethernet, Copperhill Technologies, 2019, Online book, last visited: 7 Sep. 2023, https://copperhilltech.com/blog/industrial-ethernet-guide-topology-and-communication-features/.

68.

Xarp, Advanced ARP spoofing detection, 2011, http://www.xarp.net.

Topologies	Star, linear
Number of hosts	$N \in {10, 25, 50, 75, 100, 125, 150}$
Number of message sources	N
Message generation rate	Exponential distribution with $λ =$ 15 s
Message destination choice	Uniform distribution over ${1, N}$
Number of attackers	1, randomly chosen over the N nodes
Attack strategies	Unsolicited reply, gratuitous announce
Attack rate	Exponential distribution with parameter $τ \in {\infty, 900, 600, 300, 90}$ s
Victim and target choice	Uniform distribution over ${1, N}$
Attack duration	6–7 minutes
ARP cache lifetime	120 s
Simulated time	3600 s

Ensuring cybersecurity for industrial networks: A solution for ARP-based MITM attacks

Abstract

Keywords

1. Introduction

2. Background

2.1. Distinctive challenges in industrial networks

2.2. Scheme in network communication

2.3. Address resolution protocol

2.4. ARP poisoning MITM attacks

3. Threat model

4. ArpON protocol

4.1. Overview

4.3. Implementation aspects

5. Experimental evaluation

5.1. Network and protocols configuration

5.3. Performance indexes

1 Three renewals of the same attack are counted as 3 poisonings, of roughly 2 minutes each.

6. Related work

7. Security analysis

Footnotes

Acknowledgment

Appendix

References

¹
Three renewals of the same attack are counted as 3 poisonings, of roughly 2 minutes each.