Using ARPWATCH

Find out if there's a "man in the middle" impersonating your server.

One of the biggest threats to a computer network is a rogue system pretending to be a trusted host. Once someone has successfully impersonated another host, they can do a number of nefarious things. For example, they can intercept and log traffic destined for the real host, or lay in wait for clients to connect and begin sending the rogue host confidential information. Spoofing a host has especially severe consequences in IP networks, as this opens many other avenues of attack. One technique for spoofing a host on an IP network is Address Resolution Protocol (ARP) spoofing. ARP spoofing is limited only to local segments and works by exploiting the way IP addresses are translated to hardware Ethernet addresses.

When an IP datagram is sent from one host to another on the same physical segment, the IP address of the destination host must be translated into a MAC address. This is the hardware address of the Ethernet card that is physically connected to the network. To accomplish this, the Address Resolution Protocol is used.

When a host needs to know another host's Ethernet address, it sends out a broadcast frame that looks like this:

01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62

This is called an ARP request. Since this is sent to the broadcast address, all Ethernet devices on the local segment should see the request. The machine that matches the requests responds by sending an ARP reply:

01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1

Since the ARP request already contained the MAC address of the sender in the Ethernet frame, the receiver can send this response without making yet another ARP request. Unfortunately, ARP's biggest weakness is that it is a stateless protocol . This means that it does not track responses to the requests that are sent out, and therefore will accept responses without having sent a request. If someone wanted to receive traffic destined for another host, they could send forged ARP responses matching any chosen IP address to their MAC address. The machines that receive these spoofed ARP responses can't distinguish them from legitimate ARP responses, and will begin sending packets to the attacker's MAC address.

Another side effect of ARP being stateless is that a system's ARP tables usually only use the results of the last response. In order for someone to continue to spoof an IP address, it is necessary to flood the host with ARP responses that overwrite legitimate ARP responses from the original host. This particular kind of attack is commonly known as ARP cache poisoning .

Several tools—such as Ettercap (http://ettercap.sourceforge.net), Dsniff (http://www.monkey.org/~dugsong/dsniff/), and Hunt (http://lin.fsid.cvut.cz/~kra/)—employ techniques like this to both sniff on switched networks and perform man-in-the-middle attacks. This technique can of course be used between any two hosts on a switched segment, including the local default gateway. To intercept traffic bidirectionally between hosts A and B, the attacking host C will poison host A's ARP cache, making it think that host B's IP address matches host C's MAC address. C will then poison B's cache, to make it think A's IP address corresponds to C's MAC address.

Luckily, there are methods to detect just this kind of behavior, whether you're using a shared or switched Ethernet segment. One program that can help accomplish this is Arpwatch (ftp://ftp.ee.lbl.gov/arpwatch.tar.gz). It works by monitoring an interface in promiscuous mode and recording MAC/IP address pairings over a period of time. When it sees anomalous behavior, such as a change to one of the MAC/IP pairs that it has learned, it will send an alert to the syslog. This can be very effective in a shared network using a hub, since a single machine can monitor all ARP traffic. However, due to the unicast nature of ARP responses, this program will not work as well on a switched network.

To achieve the same level of detection coverage in a switched environment, Arpwatch should be installed on as many machines as possible. After all, you can't know with 100% certainty what hosts an attacker will decide to target. If you're lucky enough to own one, many high-end switches allow you to designate a monitor port that can see the traffic of all other ports. If you have such a switch, you can install a server on that port for network monitoring, and simply run Arpwatch on it.

After downloading Arpwatch, you can compile and install it in the usual manner by running:

# ./configure && make && make install

When running Arpwatch on a machine with multiple interfaces, you'll probably want to specify the interface on the command line. This can be done by using the -i command-line option:

arpwatch -i iface

As Arpwatch begins to learn the MAC/IP pairings on your network, you'll see log entries similar to this:

Nov  1 00:39:08 zul arpwatch: new station 192.168.0.65 0:50:ba:85:85:ca

When a MAC/IP address pair changes, you should see something like this:

Nov  1 01:03:23 zul arpwatch: changed ethernet address 192.168.0.65 0:e0:81:3:d8:8e 

(0:50:ba:85:85:ca)

Nov  1 01:03:23 zul arpwatch: flip flop 192.168.0.65 0:50:ba:85:85:ca (0:e0:81:3:d8:8e)

Nov  1 01:03:25 zul arpwatch: flip flop 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca)

In this case, the initial entry is from the first fraudulent ARP response that was received, and the subsequent two are from a race condition between the fraudulent and authentic responses.

To make it easier to deal with multiple Arpwatch installs on a switched environment, you can send the log messages to a central syslogd [Hack #54], aggregating all the output into one place. However, due to the fact that your machines can be manipulated by the same attacks that Arpwatch is looking for, it would be wise to use static ARP table entries [Hack #32] on your syslog server, as well as all the hosts running Arpwatch.