Section 16.10 Using Arpwatch to Catch ARP and MAC Attacks | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

16.10 Using Arpwatch to Catch ARP and MAC Attacks

graphics/threedangerlevel.gif

On any Ethernet-based Local Area Network (LAN), at the lowest level packet destinations are specified by the machine's Ethernet card's address, more commonly known as the Media Access Control (MAC) address. When a system wants to send a packet to a particular IP address, it sends out an Address Resolution Protocol (ARP) request saying "Who has IP 10.0.0.2?" for example. If everyone is playing fairly and is properly configured, the intended system will say "I do and my MAC address is 00:87:72:23:7F:AA. The source system then sends the packet to MAC address 00:87:72:23:7F:AA." This protocol was designed over 20 years ago, long before the modern Internet existed, when nobody worried about security and only experienced SysAdmins had administrative access to the systems on a LAN.

Now, anyone can plug a laptop into an organization's LAN and send false responses to the ARP requests and thoroughly attack the network. ARP issues also are discussed in "Understanding Address Resolution Protocol (ARP)" on page 145, "Preventing ARP Cache Poisoning" on page 146, "Countering System and Switch Hacking Caused by ARP Attacks" on page 151, and "Poisoned ARP Cache" on page 256. Once a network has grown beyond 10 or so systems, management becomes nontrivial. Even well-intentioned users can use conflicting IP addresses unintentionally, forget to change their laptops' IP addresses to the correct one for the organization, and so on.

Many networks use Dynamic Host Configuration Protocal (DHCP) or ZeroConf to assign IP addresses automatically, but the use of these programs does not completely prevent IP conflicts. There are many ways that a duplicate IP address could be caused by the DHCP server. The most common is system administrator error. However, if the lease file were to be corrupted or removed, duplicate DHCP leases could be handed out.

The best solution for both accidental and intentional problems is to monitor ARP traffic with Arpwatch. This Open Source program was developed by the U.S. government's Lawrence Berkeley Laboratories and runs on Linux and UNIX. In the spring of 2002, I made some major enhancements to it for better tracking of problems on large networks of hostile users with multiple subnets. This enhanced version is available on the CD-ROM or on request sent via e-mail to book@verysecurelinux.com.

Before going further, I need to introduce the term "bogon" (bo´-gon. noun). A packet with an IP address that is incorrect for the subnet that it came from is called a bogon.

To install the enchanced version of Arpwatch on your system, mount the CD-ROM and build from the tarball:

 cp /mnt/cdrom/book/arpwatch.bob.tar.gz zcat arpwatch.bob.tar.gz | tar -xovf- cd arpwatch-bob ./configure make make install make install-man man arpwatch man arpsnmp

Next, add commands similar to the following to the /etc/rc.d/rc.local file so that it will start automatically on reboot:

 # "-0"       Enhancement to suppress Apple 0.0.0.0 nonsense # "-m foo"   Enhancement to mail to foo instead of root # "-w from"  Enhancement to specify from address (include which office) # "-u MAC"   Enhancement to specify MAC of our upstream router #              to avoid false positives on bogon detection echo "Starting arpwatch on each Ethernet interface" ARPWATCH=/usr/local/sbin/arpwatch ARPARGS="-0 -m sysadmin@pentacorp.com" # Specify MAC address of upstream router, if any ARPUPS="-u 00:07:4C:96:72:68" killall arpwatch $ARPWATCH -f /var/log/eth0 -i eth0 -w "arpwatch (NYC:eth0)" \        $ARPARGS $ARPUPS $ARPWATCH -f /var/log/eth1 -i eth1 -w "arpwatch (NYC:eth1)" \        $ARPARGS $ARPWATCH -f /var/log/eth2 -i eth2 -w "arpwatch (NYC:eth2)" \        $ARPARGS

Finally, initialize its human-readable databases and start it for the first time:

 cd /var/log touch eth0 eth1 eth2 chmod 600 eth0 eth1 eth2 /etc/rc.d/rc.local

This firewall has both an internal network on eth1 and a DMZ on eth2. The argument to the -w flag will show as the "From" address. We indicate this as "arpwatch" and indicate which of our office's firewalls is generating the message and which NIC card the packet originated from. Each running Arpwatch process builds up an in-memory database of IP address MAC address pairs and backs this up to disk (/var/log/eth?) every 15 minutes. If your upstream router is connected to this system via Ethernet, its MAC address should be specified with the -u flag for smart bogon detection.

Normally, Arpwatch will fork itself into the background. When a noteworthy event occurs, it uses Syslog to generate a log entry and send an e-mail. A common "gotcha" is to forget to create the database file as a zero-length file. If it does not already exist when Arpwatch starts up, it generates a log file entry via Syslog and exits silently. To the casual observer, this behavior is indistinguishable from correct startup.

When initially configuring Arpwatch, do a ps -axlww | grep arpwatch to see if it stayed running. Also, keep in mind that it writes new entries to the database file (which is viewable with more only every 15 minutes or when sent an interrupt, kill, or HANGUP signal. If invoked with debugging (-d), it will instead run in foreground and write messages to standard error instead of generating log messages and e-mail. If you are starting it for the first time on a large network, you may want to run it with debugging until it has built up its database of commonly running systems.

When a new IP address is seen, it will generate e-mail saying that this is a new station. The e-mail includes the IP address, the host name if DNS is successful, the MAC address, the Ethernet card vendor name, and a time stamp. Machines generating bogons either are misconfigured or are hackers on your network. All of these messages warrant investigation, though many DHCP configurations will cause false positives.

When a packet comes in from the Internet through a router, the packet's source IP address will be that of the system on the Internet but will have the router's MAC address. The only way to distinguish it from a bogon is that bogon warnings are suppressed if the MAC address matches that of the router, as specified with the -u flag. The -u flag may be used more than once if one's network has multiple directly connected routers. If one's upstream router is not connected via Ethernet (for example, if the firewall is doing its own routing with an internal T1 card), -u should not be used. Arpwatch also recognizes that the system that it is running on may be a router and thus assumes that any packet with a MAC address that matches that of one of its own interfaces is being routed.

When a hacker takes over a system and is planning on using it for a while to cause trouble, it is common for him to change his IP address to one not already in use to make it harder for you to track him down. Most do not bother to change the Ethernet address, though. If you keep track of which system has which MAC address, these problem systems are easy to track down. Even if a hacker changes the MAC address of the NIC, Arpwatch will notify you that a new machine has been brought on the network (or that an existing machine has changed its MAC address). You then can investigate the cause.

A typical new station e-mail will look like:

 From: arpwatch@redshirt2 (ATL:eth1) To: bob@redshirt2 Subject: new station (redshirt)         hostname: redshirt (eth1)       ip address: 10.0.0.2 ethernet address: 00:87:72:23:7F:AA  ethernet vendor: INTEL CORPORATION        timestamp: Tuesday, June 11, 2002 6:11:52 -0400

If you use DHCP, you can make life easier on yourself by establishing static IP addresses for your users' systems and then either putting them in your internal DNS DB or, at least, in the /etc/hosts file on your firewall. If your firewall is a Linux or UNIX system then Arpwatch should run on it. The following is a typical static IP entry from the ISC DHCP server's configuration file:

 # Research host warpdevel {         hardware ethernet 00:27:37:24:36:69;         fixed-address 10.0.19.62;         option host-name "warpdevel"; }

By taking the time to do this, any bogus systems will show up on the network either as a new system without a host name or as a system that has changed its Ethernet address. Both are excellent and immediate warnings that there is a possible security breach. The following is a typical alert:

 From: arpwatch@redshirt2 (ATL:eth1) To: bob@redshirt2 Subject: changed ethernet address (10.0.0.3)             hostname: redshirt (eth1)           ip address: 10.0.0.2     ethernet address: 00:56:97:86:39:A7      ethernet vendor: A. Centauri Corp old ethernet address: 00:87:72:23:7F:AA  old ethernet vendor: APPLE CORP            timestamp: Tuesday, June 11, 2002 7:14:37 -0400   previous timestamp: Tuesday, June 11, 2002 6:42:34 -0400                delta: 32 minutes

As you have two different systems on the network with the same IP address, you definitely have a problem to contend with.

A system with an IP address that is incorrect for its subnet will show up as a bogon. The following is typical. In this case, someone has turned on a Windows system without bothering to configure it to use the organization's DHCP server. Networks with a lot of laptop users will see these frequently:

 From: arpwatch@redshirt2 (ATL:eth1) To: bob@redshirt2 Subject: bogon new station (169.254.173.57)         hostname: 169.254.173.57 (eth1)       ip address: 169.254.173.57 ethernet address: 00:71:67:23:13:17  ethernet vendor: 3COM CORPORATION        timestamp: Tuesday, June 11, 2002 7:31:48 -0400

Some Macs have the glitch that when they start up, they start sending packets out before the IP address is set. In this case, the IP address will be 0.0.0.0. Arpwatch's -0 flag causes it merely to note this in a Syslog entry and not treat it as anything to be concerned about. It only does this special treatment of a 0.0.0.0 IP address if the Ethernet vendor is Apple.

When a new machine using DHCP enters the network, its initial IP address may be 0.0.0.0 just long enough to receive a lease from the DHCP server. Another condition where this might happen is if a DHCP lease has expired and been given to another machine while a client computer was disconnected from the network. When that computer (commonly a laptop) rejoins the network, it will assume the characteristics of a new machine, again just long enough to get a new lease.

Top