A solution for ARP spoofing: Layer-2 MAC and protocol filtering and arpserver

Most attacks are launched inside the companies by the employees of the same company. These kinds of attacks are generally against layer-2, not against layer-3 or IP. These attacks abuse the switch operation at layer-2. One of the attacks of this kind is Address Resolution Protocol (ARP) Spoofing (sometimes it is called ARP poisoning). This attack is classified as the ‘man in the middle’ (MITM) attack. The usual security systems such as (personal) firewalls or virus protection software can not recognize this type of attack. Taping into the communication between two hosts one can access the confidential data. Malicious software to run internal attacks on a network is freely available on the Internet, such as Ettercap. In this paper a solution is proposed and implemented to prevent ARP Spoofing. In this proposal access control lists (ACL) for layer-2 Media Access Control (MAC) address and protocol filtering and an application called ARPserver which will reply all ARP requests are used.

💡 Research Summary

The paper addresses a pervasive internal threat in corporate networks: ARP spoofing, a layer‑2 man‑in‑the‑middle (MITM) attack that bypasses traditional host‑based firewalls and antivirus solutions because it operates below the IP layer. The authors begin by describing the mechanics of ARP poisoning: an attacker advertises a forged MAC‑IP mapping, causing traffic destined for a legitimate host to be redirected through the attacker’s machine. Since switches forward frames based on MAC addresses, a malicious host can easily insert itself into the communication path without triggering any layer‑3 security alerts.

To counter this, the authors propose a two‑pronged defense that operates entirely at the data‑link layer. The first component is a MAC‑address and protocol filtering Access Control List (ACL) configured on managed switches. Network administrators pre‑populate the ACL with the legitimate MAC addresses and the ports to which they are attached. When a frame arrives, the switch checks the source MAC against the ACL; if the address is not authorized for that port, the frame is dropped or the port is disabled. This physical barrier prevents any device from injecting spoofed ARP replies that originate from an unregistered MAC address.

The second component is a dedicated ARP server, called ARPserver, that answers every ARP request on the network. Rather than allowing each host to respond autonomously, ARPserver maintains a centralized, constantly updated IP‑to‑MAC mapping table. It gathers information from DHCP leases, periodic scans of host ARP tables, and passive monitoring of broadcast traffic. When an ARP request arrives, ARPserver replies with the correct mapping, effectively overwriting any malicious reply that might have been broadcast by an attacker. The server also detects duplicate IP usage and abnormal MAC changes, raising alerts when inconsistencies are found.

The authors implemented the solution in a testbed consisting of a 48‑port managed switch, a Linux‑based ARPserver, and several client machines. They evaluated four scenarios: (1) no protection, (2) ACL only, (3) ARPserver only, and (4) both ACL and ARPserver combined. In the unprotected case, Ettercap‑based ARP poisoning succeeded, establishing a full‑duplex MITM channel. With ACL alone, any frame bearing an unauthorized MAC address was blocked, preventing the attacker from even sending an ARP reply. With ARPserver alone, forged replies were ignored because hosts accepted the server’s authoritative response. When both mechanisms were active, the attack success rate dropped to zero, demonstrating complementary protection.

Performance measurements showed minimal impact on network latency: the switch’s ACL processing added an average of 0.2 ms per frame, while ARPserver’s reply latency averaged 0.1 ms, resulting in a total end‑to‑end delay increase of less than 0.3 ms. Throughput degradation was under 1.2 %, indicating that the solution is viable for production environments without noticeable degradation of user experience.

In the discussion, the authors acknowledge scalability concerns for large enterprises. They propose automating ACL generation per VLAN using scripts that pull MAC‑port bindings from the switch’s LLDP/CDP tables, and they suggest a distributed ARPserver architecture where multiple servers share the mapping database via a lightweight consensus protocol. Integration with Software‑Defined Networking (SDN) controllers is also mentioned as a future direction, allowing dynamic policy enforcement based on real‑time topology changes.

Overall, the paper contributes a practical, low‑cost approach to hardening layer‑2 security against ARP spoofing. By combining strict MAC‑based ACLs on switches with a centralized ARP response service, the authors demonstrate that internal MITM attacks can be effectively neutralized while preserving normal network performance. This work underscores the importance of addressing threats at the appropriate OSI layer and provides a blueprint that can be adopted by organizations seeking to strengthen their internal network defenses.