|
|
| Previous | Table of Contents | Next |
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 the Simple Network Management Protocol (SNMP).
In SNMP, each machine using IP runs an SNMP agent that 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.
Warning: SNMPv1 requests use a “community name” to access a particular view of the MIB. Many SNMPv1 agents are configured with a community name of “public” to give a read-only view of all of the objects in the MIB. Writable views should not be used on an SNMPv1 agent if sniffing is a concern. A sniffer could determine the community name for the writable view and use it to alter the state of the device being controlled by the agent.
Network-Level Detection via Continuous Monitoring
A more robust and rapid mechanism for detecting ARP spoofing is to keep an interface on the network in promiscuous mode. A program on the promiscuous interface’s host can inspect every packet sent on the network and monitor the network load, the protocol mix—how much of the traffic is IP, how much is IPX, how much is other network-layer protocols—as well as look for anomalies including ARP spoofing. A network monitor can detect a change in the association between a hardware address and an IP address and report such changes immediately when they occur.
Brouters, transparent bridges, and switches are all logical places to locate the type of network monitor described in the previous paragraph. (Brouters are devices that are combination bridges and routers—a hybrid device such as the Cisco AGS that is often found in multi-protocol networks where non-routable protocols must be bridged.) All these devices have their interfaces in promiscuous mode all the time, so the monitor would not dramatically increase the load on one of these machines because they are all routinely examining each packet. Also, they all typically come with SNMP agents that can send a trap message to the network operations center to report the detection of a potential ARP spoof.
These kinds of systems have a reasonable chance of actually getting such a trap message all the way to the network operations center. However, none of these devices may be successful in doing so if the spoofer is masquerading as the network operations center itself. The trap also may be lost if the spoofer is masquerading as a router between the monitor that detects the spoof and the network operations center.
SNMP agents supporting the RMON protocol (as described in RFC 1757) are designed to do low-level monitoring involving sniffing. On a multisegment network, an RMON/SNMP agent needs to be placed on each segment to get full coverage of the network. Locating the RMON agent on devices that connect to more than one segment will reduce the number of agents that need to be fielded.
Note: I am unaware of any good, comprehensive, or affordable commercial packages to implement SNMP-based ARP spoofing monitors. However, building your own system using freeware packages such as BTNG and Tricklet provides an alternative to expensive commercial packages.RFC 1757 describes the RMON protocol.
BTNG (Beholder, The Next Generation) is an RMON agent available from the Delft University of Technology in the Netherlands via anonymous FTP to dnpap.et.tudelft.nl.
Tricklet, an SNMPv1 management system written in the PERL scripting language, was developed by the same group that developed BTNG. The two systems are integrated and are a good place to start to put together an ARP spoofing detection system in a network large enough to require SNMP management.
Both BTNG and Tricklet are available at http://ftp.sunet.se/ftp/put/network/monitoring/btng.
In smaller networks, simply placing monitoring software on a small number of secure hosts with interfaces in promiscuous mode all the time might be the only ARP spoofing detection you need. Such monitoring software includes “arpmon” and “netlog” from Ohio State University. These two programs are part of a larger set of programs to assist system and network administrators. Another program to do this kind of monitoring is ARPWatch, which is more narrowly focused on the issue of looking for anomalous behavior in the ARP protocol.
| Previous | Table of Contents | Next |