If a hacker runs a sniffer (e.g., Wireshark) on a local network, they won’t see anything interesting besides their own broadcasts and other service information. Therefore, traffic interception usually exploits weaknesses in the ARP protocol itself. Let’s look at how these can be mitigated.

1480078958_e0da_arp.png

The ARP protocol is used to convert an IP address to a MAC address. Historically, ARP has no protection or even any form of request authentication. Let me repeat: absolutely none! Additionally, ARP responses can be sent without ARP requests — this is the so-called gratuitous ARP, which is of particular interest to us. To exploit this, you can use the tool Cain & Abel. I assume you’ve heard of it.

With Cain & Abel, an attacker can intercept traffic within a broadcast domain. To defend against this, the Dynamic ARP Inspection (Protection) mechanism can be used.

For Dynamic ARP Inspection to work correctly, you must specify which switch ports are trusted and which are not. An untrusted port refers to the port connected to client devices. ARP messages on untrusted ports undergo several checks. Trusted ports are those connected to other switches. ARP messages from trusted ports are not discarded.

The switch intercepts all ARP requests and replies on untrusted ports before forwarding them. It also checks the correspondence between the MAC address and IP address on these untrusted ports.

This MAC-to-IP address verification can be based on static entries or a DHCP binding database.

On Cisco switches, this mechanism is enabled in a VLAN using the following command:

Switch(config)# ip arp inspection vlan 1

Here’s what the configuration of a trusted port looks like:

Switch(config)# interface gigabitethernet1/0/1 
Switch(config-if)# ip arp inspection trust

If you don’t have a switch capable of defending against such attacks, you can install arpwatch: a daemon that monitors the correspondence between IP and MAC addresses, and logs anomalies in the system log when detected. You can check the documentation here.

As you might guess, the main downside of arpwatch, and similar tools in general, is that it must run on the hosts it is protecting, or at least on the router leading to the protected network. However, the router doesn’t always run on UNIX or Linux. More often, it’s a specialized hardware router or a Layer 3 switch.

To protect such a router, you need to obtain its ARP table via SNMP and analyze it on another machine. This is how the remarp tool, for example, operates.