Detecting an ARP Spoof

The best you can usually hope for is rapid detection followed by some form of intervention. When an anomaly is detected in the ARP protocol it may be legitimate, accidental, or a security breach. Policies and procedures should be in place to handle each type of incident.

Host-Level Passive Detection

As a basic precaution, when an operating system responds to an ARP broadcast, it should inspect both the sender IP address and the target IP address. It only needs to check the target address to see if the target IP address matches its own IP address. If so, it needs to send an ARP reply. However, once the operating system has been interrupted, it takes little extra work to check to see if the sender IP address matches its own. If so, another machine on the network is claiming to have the same IP address. Such an anomaly certainly indicates a serious  configuration problem and may be the result of a simplistic ARP spoof in which the attacker simply reset the IP address of the machine being used in the attack. Many Unix systems perform such a check.

Host-Level Active Detection

Another precaution to detect ARP spoofs is to arrange for hosts to send out an ARP request for their own IP address, both on system startup and periodically thereafter. If the host receives an ARP reply for its own IP address, the IP software should report the detection of an ARP spoof to the host user or administrator. Actively querying ARP with one’s own IP address will catch inadvertent IP address misconfigurations as well as an attacker who is simply using an ordinary operating system with a deliberately misassigned IP address. However, it is possible to mount a more sophisticated attack that will thwart the active query detection method.

In particular, a technically adept attacker might modify the operating system of the machine being used to mount the attack. A simple modification that thwarts the active query detection method is to not reply to ARP requests originating from the legitimate interface associated with the IP address being used. The availability of such sophisticated software may seem unlikely even to an advanced computer user.

However, freely distributed Unix-like operating systems with freely distributed source code are now very common. It is not particularly difficult for a determined attacker to obtain such an operating system. He or she could then modify its kernel at the source code level, and compile a modified kernel specifically for the purpose of mounting such an attack.

Server-Level Detection

Alternatively, a more elaborate precaution would be to verify an ARP reply by making an RARP request for the hardware address contained in the reply. RARP, the reverse address resolution protocol, uses the same format as ARP and also broadcasts requests. RARP requests ask the question “What is the IP address associated with the hardware address I have here?” Traditionally, the primary use of RARP is by diskless machines with no permanent modifiable memory. Such machines need to discover their own IP address at boot time. RARP relies on one or more RARP servers that maintain a database of hardware addresses and the corresponding IP addresses. Use of an RARP server is probably overly elaborate when an ARP server would do the same job.

Note The basic idea of checking the validity of the results to a query by making an inverse query is generically useful. That is, in many situations you are querying a system equivalent to a database. Suppose you use one value, X, as a key for a query with the database indexed on one field and get a second value, Y, from a second field as a result. Then, you can use Y as they key for a query with the database indexed on the second field and you should get X as a result. If you do not, then something is wrong with the database or its searching mechanism.

Network-Level Detection: The Motivation

The motivation for network-level detection is that host-level detection may be unable to effectively inform the network staff that a problem exists and that server-level detection probably requires modification of IP software of the operating system source code. When a host detects that it is being impersonated by another machine, it may be able to report the fact to its user, but once an attack is underway it may be unable to inform the network administrator who is presumably using another machine.

Some popular IP system software may very well take the precaution of occasionally making ARP requests for the hardware address associated with the IP address it believes is its own. The active querying precaution is well-known and is a common textbook exercise. Most corporate system staffs are unable to modify the IP software of most of the machines on their network. If that is your situation, you probably want a software detection system that can be deployed on a single machine on your network. Building the system using software already written by someone else is preferable.

Network-Level Detection via Periodic Polling

By periodically inspecting the ARP caches on machines, you should be able to detect changes in the IP address to hardware address association on those machines. It should be routine for the network staff to keep a database of hardware addresses, IP addresses, DNS names, machine types, locations, and responsible persons. At the very least, such an inspection can probably be done manually on most hosts. It could be done more often if hosts could be configured to periodically report the contents of their ARP caches to a centralized machine. A program on that machine could look for inconsistencies between hosts, changes from previous reports, and

conflicts between reported ARP cache information and the information in the manually maintained database—any of these may indicate a problem.

Standard mechanisms for periodic reporting of network configuration information from machines on an IP-based network to the network administration staff already exist. One such mechanism is SNMP—the Simple Network Management Protocol.

In SNMP, each machine using IP runs an SNMP agent which both responds to information and configuration requests as well as reports certain conditions to the network management staff. Virtually all current systems provide bundled SNMP agents. To take advantage of SNMP, the network management staff must have SNMP management software to query the agents and react to the agent reports. Finding good SNMP management software may be difficult and expensive to purchase and deploy.

If your network is already employing SNMP for other purposes, including a check on ARP caches may be simple and inexpensive depending on the sophistication of your SNMP management software. The standard SNMP MIB-I contains the address translation group that contains a single table named “at.atTable,” which contains the IP address and hardware address of each interface being monitored by the SNMP agent. The address translation group has to be deprecated in SNMP MIB-II to allow for greater flexibility because IP is now no longer the only protocol being controlled with SNMP. For SNMP agents that use MIB-II, you should look in the IP address translation table in the IP group named ip.ipNetToMediaTable.