Even the most fledgling of network administrators are familiar with the ARP protocol and the role it plays in helping operators manage their networks. Indeed, ARP, or “Address Resolution Protocol,” is a stateless communication protocol critical to enabling basic packet transmission in every ethernet network. Its job is quite simple: ARP inspects incoming packets to discover the IP addresses of their destinations and then maps those addresses to the MAC (or Media Access Control) addresses specific to the correct physical devices (e.g. PC or Server) that exist within that same physical network. In so doing it makes it possible for incoming network traffic to reach its proper destination via the data link layer.
For this process to succeed, all devices must broadcast their MAC addresses on their local network. This information is then maintained by network switches in an “ARP table” or “ARP cache,” as specified by IETF RFC 826 (1982). Likewise, this table also retains the relationship between MAC addresses and devices’ corresponding IP addresses. IP and MAC address conversion is thus possible in both directions. In the event that an incoming packet is not able to find the destination MAC address in question in the local ARP table, the ARP protocol mandates that an “ARP request” be broadcast across the local network. All devices on that network then compare that IP address to their local ARP cache (each desktop or laptop, in addition to network switches, maintains its own, individual ARP table). Any device identifying the requested address will respond accordingly with both its IP and MAC addresses. This information will in turn be stored in the now-updated table on the local switch.
It’s important to note that the ARP protocol supports Layer 2 communications only. ARP requests and address resolution do not occur at Layer 3, that is, between networks connected via L3 routing.
ARP’s Inherent Vulnerability
The ARP protocol thus makes network traffic communications a relatively simple and straightforward affair. However, ARP is also inherently vulnerable from a security perspective. ARP requires no authentication whatsoever of the addressing information it receives from any network peer. All ARP replies are cached in the ARP table as described above; existing table entries are automatically overwritten by the most recent information received. This lack of authentication makes ARP an easy target for cyber-security exploitation.
In particular, ARP is highly vulnerable to attacks such as “ARP Spoofing” and “ARP Poisoning.” The point of such attacks, the nature of which will be discussed further below, and which can be initiated from some compromised network device or from the hacker themselves if they have acquired physical access to the network in question, is to compromise the integrity of a local network’s ARP table by associating an attacker’s MAC address with the IP address of a particular target host. In this way, network traffic intended for a particular destination will instead be forwarded on to the attacker’s host location. That traffic can them be modified, stolen, or simply observed in order to support some additional cyberattack purpose in an on-demand fashion. ARP-related security breaches are very difficult to detect and defend against precisely because the ARP information is maintained and transmitted only within the L2 broadcast domain. Vigilant network administrators cannot tell, simply by looking at an ARP table, whether it’s been compromised or not, unless they have established some manual system to keep track of the expected IP-to-MAC address relationships. As a result, over the years, this inherent ARP vulnerability has led to innumerable “man-in-the-middle” and “denial-of-service” type attacks.
How Genians Leverages ARP for Better Security
While some organizations do attempt to prevent ARP-related security problems through the implementation of just this sort of static IP-to-MAC address mapping, maintaining such a system requires enormous administrative overhead – and thus tends to complicate network management further, while not necessarily truly improving network security. It also reduces management flexibility significantly as it removes the benefit of DHCP IP addressing and does not scale well. Maintaining such a burdensome system in a large enterprise would be unthinkable.
Genians, however, offers a compelling, automated solution to this longstanding vulnerability. Because Genian NAC performs its network access control functionality through the use of layer 2-based network sensors, it is able to monitor ARP effectively within each broadcast domain. It can therefore detect any abnormal ARP-related behavior and block suspicious activity.
Compared to other NAC solutions, it provides a very robust ARP vulnerability defense security framework. It does so through the following means.
- The detection of all new IP enabled devices
- ARP-based activity checks
- Network Access Control using ARP Poisoning
- The detection of ARP spoofing
- The detection of MAC/IP cloning
- The detection of ARP bombing
- Reserving specific IP addresses for specific MAC addresses
- Blocking of IP address changes
Let’s look at each of these functionalities in turn:
The Detection of All New IP-enabled Devices
Genian NAC monitors all broadcast packets. If an unknown IP-to-MAC address combination is found, it is registered as a new node and the device management process is begun. This provides real-time and accurate results compared to other NAC solutions that register nodes through SNMP or CLI integration with the switch.
ARP-Based Activity Checks
Monitoring the correct operating status of network devices is very important to the effective investigation of security incidents. Genian NAC provides highly accurate device operating status information. This is because ARP-based operation status-checking is provided through the layer 2 network sensor. In remote networks, the operational status check using ICMP is often blocked due to the enhancement of the security of the latest devices. Especially, in case of IoT devices, ICMP service itself is not even available in many cases. Nor is it possible necessarily to collect operational status information through switch integration. Also, only passive operation status monitoring is possible, so that the operation status can be recognized incorrectly when no packet is generated in the device. Genian NAC periodically sends ARP requests to the devices to monitor whether they are responding or not.
Network Access Control using ARP Poisoning
Controlling network access according to the status of devices in the internal network has always been a challenge. Setting ACLs on routers or firewalls to control access between internal networks can provide only simple access control. ACLs can be difficult to enforce especially in a DHCP environment where devices move frequently or devices that use IP change frequently. Moreover, access control between multiple devices connected to the same subnet is the most challenging task and there are not many solutions. One possible choice is to apply the port-based access control function using 802.1x on the switch port to which the device is connected. However, 802.1x can be expensive, requiring large network configuration changes, such as replacing it with a supported device and replacing it with the same manufacturer’s product for ease of management. In addition, because all network devices do not support 802.1x, manual configuration is frequently required for each switchport connected. In a large enterprise network, setting an exception or MAC address for 802.1x for each switchport can lead to equally large network management headaches, which will increase time-to-deploy and manage.
Yet another option is to use network access control with ARP Poisoning. ARP Poisoning uses the characteristics of the ARP protocol to allow a device to perform access control by intercepting packets generated by impersonating the other party when the other party obtains the MAC through an ARP request. Genian NAC performs ARP Poisoning using the following procedures:
- The device to be blocked generates an ARP request
- The response to the request provides the MAC of the network sensor
- The device to be blocked transmits the packet to the network sensor
- The network sensor drops according to the access control policy or delivers it to the actual destination
In order to prevent the bypassing of ARP poisoning by setting static ARP on the blocked target device, bidirectional poisoning function is provided to control the reply packet generated from the communication target, such as a gateway, and static ARP setting can be blocked through the NAC Agent.
Genian NAC also possesses a built-in RADIUS server for 802.1x and ARP poisoning via network sensor, so users can select and use it according to their network environment.
The Detection of ARP Spoofing
While ARP Poisoning is a technology used to block communication of network devices, ARP Spoofing is mainly used in conjunction with malicious code and is typically used for eavesdropping on the communications of the breached party. Genian NAC can detect ARP packets through a network sensor to detect devices attempting to be spoofed. In addition, it provides a function to block devices that attempted spoofing and return to the correct MAC addressing through ARP cache detox.
The Detection of MAC/IP Cloning
The IP protocol uses IP and MAC addresses to identify the destination of the communication. Since there is no ARP verification procedure at this time, as we noted above, it is easy to steal. If the cloned MAC-IP addressing of the malicious device is present on the network in question, it is very difficult to check both the normal system and the stolen system at the packet level. However, Genian NAC can detect MAC / IP theft in a variety of ways. The network sensor periodically sends an ARP request to check the operational status of the device. If two replies are received at the same time, the MAC / IP clone is suspended and the device node is designated as critical. In addition, if the user changes the MAC on the endpoint where the Agent has been installed and the MAC is already being used by another device, the device is designated as a critical node. Genian also provides industry-leading platform detection to detect when a node has been changed to a different platform, allowing administrators to see when changes have been made, and to block devices when unauthorized platform changes are detected.
The Detection of ARP Bombing
While the network sensor is monitoring ARP, it detects a device that generates excessive ARP packets and designates it as a critical node. It detects abnormal ARP behavior and prevents attempts to disable network access or disable network access control.
Reserving specific IP addresses for specific MAC addresses
Certain IP addresses on the network are limited in their use for fixed devices. A typical example is a gateway address. Genian NAC can provide the functionality needed to restrict this fixed device to use IP. When the MAC address of a device that can use IP is set in Genian NAC, the device with the other MAC will block the communication of the node when the IP is used. In addition, ARP cache detox (broadcast ARP packets with the correct MAC address to the network) prevents network devices from setting the ARP cache to the wrong MAC address.
For example, if a specific user generates ARP by setting his terminal IP address as the gateway address, other devices on the network will be unable to communicate with the actual gateway. At this time, Genian NAC transmits the ARP cache detox packet to switch to the MAC of the real gateway to enable normal communication. The network sensor responds to GARP (Gratuitous Address Resolution Protocol) packets that are generated when other devices want to use IP for the reserved IP. Prevents setting even if the actual IP-enabled device is not connected to the network.
Blocking of IP Address Changes
If you want to restrict the use of a fixed IP to a device with a specific MAC address, you can set an authorized MAC-IP combination. The network sensor then responds to GARP and blocks the terminal from changing to unauthorized IP.
Conclusion
The ARP protocol is a very old protocol – first made available in 1982! – and possesses many security holes. Because of the nature of using L2 broadcasts, it is not possible to manage them in a remote network, which is a problem that must be managed separately for every broadcast domain. Many organizations accordingly do not possess countermeasures against the ARP problem. Although there are attempts to solve problems through expensive switches with enhanced security features, they are not practical because of cost, configuration complexities, and difficulties in updating firmware for the latest security issues. Genian NAC provides the most effective Layer 2 network sensors, with Layer 2 security that is immediately applicable without network changes or configuration changes.
Multi-Layered Access Control
-
Part I: Secure your network by leveraging ARP
-
Part II: Rethinking 802.1x