Of the many ways that a network can be infiltrated, one of the most difficult to detect and manage is ARP spoofing. This is due to the fact that ARP does not take security into account in its design. Fortunately, there are tools available to assist in monitoring for and detecting ARP spoofing attempts. Obviously, the first steps in addressing a security incident is knowing that there IS an incident, so let’s look at how we can proactively watch for these incidents on our network.
Understanding Address Resolution
In order to address this issue, we must first have an understanding of why ARP is a soft point in security.
Address Resolution Protocol is defined in RFC 826, published in 1982. The protocol is stateless, and was designed using the trust model. While this may seem at first look to be a bad design, you must take into account the consideration that the protocol is a “first contact protocol” in that it is designed to be utilized during the initial configuration of the network interface itself.
The IP Protocol is designed to be a routed protocol and, therefore, works at layer 3 of the OSI Network Model. While this is very effective for routing packets over the internet, local delivery on a subnet requires use of the Data-Link addressing provided by MAC addressed in Ethernet networks. ARP was borrowed from the Ethernet standards and generalized in order to provide a standardized link between Layer 3 IP addresses and various Layer 2 addressing mechanisms.
ARP works by sending a multicast packet with destination address FF:FF:FF:FF:FF:FF requesting an answer for an unmapped IP address. Optimally, the machine which holds the requested address responds with its MAC address, and the initiator places this IP address to MAC address map in its ARP Cache. This map will be set with a timeout to prevent stale entries from building in the table, and to ease maintenance.
A would be intruder can take advantage of this process to replace a destination server, or insert themselves in between for a man in the middle attack. The target machine can be immobilized by flooding it with ARP requests to keep it from responding to the ARP request for a man in the middle attack. It can also be taken off the network to be replaced by a Trojan system by using ARP Poisoning, which sends a continual stream of packets to the target to inform it that the address of the victim machine maps to its own mac address. Referring to these two howto articles will demonstrate just how easy this is to accomplish:
What is ARP Spoofing ? and How to Implement it
Addressing the Issue
Addressing the issue requires us to monitor requests on the network and alert on changes. The optimum method for handling the monitoring process on a switched network is to configure a port on your switch as a monitor port, and installing the monitoring services on a computer connected to that port. If your switching equipment does not support monitor port configuration, then the alternate method would be to install these utilities on as many machines as possible. It is critical that you do not skimp on monitoring saturation as it is impossible to know which computer would be targeted by an address spoofing attack.
Arpwatch was developed by Berkely Labs, and is available for most Posix Systems. Arpwatch uses libpcap to capture and analyze IPv4 arp traffic for changes, which it can report via syslog and email.
Most Linux distributions have a packaged version of arpwatch, and this would be the recommended method of installation. for this, we would simply type (for Debian-based distros):
apt-get install arpwatch
If your distro does not include this package, you can use:
cd /usr/src && wget ftp://ftp.ee.lbl.gov/arpwatch.tar.gz && tar -xvf arpwatch.tar.gz
then cd to the newly created arpwatch directory created and run:
./install-sh
you may need to meet some dependencies in order to complete the installation.
With good network planning, you hopefully have an idea of what servers you are looking to monitor. If you have panned specific address space for these servers, you can limit arp watch to monitor these by editing /etc/arpwatch.conf to include the corrected scope:
eth0 -a -n 192.168.15.0/24 -m admin-mailbox@example.com
I, personally, prefer to forgo the -m mail switch and to just write to Syslog.
These steps should get you stated with ARP monitoring. The next step is to configure a Syslog server to simplify the process monitoring the logs themselves. For that step, please refer to my post “Centralize Your System Logging Using Syslog.”
