Shutting out ARP poisoning and spoofing with ArpON

Based on the series of articles that I wrote about ARP poisoning (I, II and III), I would like to put forward a great tool, ArpON (Arp handler inspectiON), aimed at protecting us against ARP poisoning, spoofing and routing, by preventing attacks as the Man in the Middle (MitM). It also avoids from derived attacks such as DNS and WEB spoofing, and session and SSL/TLS hijacking.

This is the typical program that I always install on any Linux computer, since it is essential in order to shut out any type of attack commented above. And furthermore, it is really meaningful when you get around and have to connect your laptop to some untrusted network, such as inside a library, pub, airport and so on.

ArpON uses two kinds of methods: DARPI (Dynamic Arp Inspection) and SARPI (Static Arp Inspection). With the second technique, you have to register into a configuration file, the MAC and IP address of each computer which you rely. This may be a hard task when you have got lots of devices in your network. In return, DARPI follows up all incoming and outgoing ARP packets.

In this article, I am going to set up DARPI on Ubuntu 11.10. I will install ArpON from the official repository (version 2.0). It is a pity because this version came out last year and I cannot understand why it has not been updated in the last release of Ubuntu. The current version which you can download from the ArpON web site is 2.7.

In PCs or laptops, I prefer to install it from the Ubuntu repositories, due to it will be automatically upgraded (in theory) with each new release of Ubuntu. Instead, on production servers, it pays off to compile it from its source code so as to have the latest version.

Ok, so we are going to install ArpON and put it into DARPI mode. In addition, ArpON will be automatically started during the boot.

root@victim:~# aptitude install arpon

root@victim:~# cat /etc/default/arpon
...
# For DARPI uncomment the following line
DAEMON_OPTS="-q -f /var/log/arpon/arpon.log -g -d"

# Modify to RUN="yes" when you are ready
RUN="yes"

root@victim:~# /etc/init.d/arpon start

First up, we are going to take a look at the ARP table of the victim (remember the involved computers were presented in the first article about ARP poisoning). As you can pick out, the dependable addresses are tagged as PERM (permanent).

root@victim:~# arp -a
? (192.168.1.150) at 00:80:5a:54:32:67 [ether] PERM on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] PERM on eth0
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] PERM on eth0

If we observe the log turned out by ArpON at the beginning, it first of all cleans up the ARP cache by removing all entries, in order to avoid that the table is poisoned.

root@victim:~# tail -f /var/log/arpon/arpon.log
  17:55:00 - Wait link connection on eth0...
  17:55:12 - DARPI on dev(eth0) inet(192.168.1.10) hw(0:c:29:69:81:47)
  17:55:12 - Deletes these Arp Cache entries:
  17:55:12 - 1)   192.168.1.150 ->  0:80:5a:54:32:67
  17:55:12 - 2)     192.168.1.1 ->  0:60:b3:50:ab:45
  17:55:12 - 3)    192.168.1.11 ->   0:c:29:18:36:e6
  17:55:12 - Cache entry timeout: 500 milliseconds.
  17:55:12 - Realtime Protect actived!
  17:55:46 - Request >> Add entry 192.168.1.150
  17:55:46 - Reply   << Refresh entry 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:47 - Request >> Add entry 192.168.1.1
  17:55:47 - Reply   << Refresh entry 192.168.1.1 -> 0:60:b3:50:ab:45
  17:55:58 - Request << Delete entry 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:58 - Reply   >> Send to 192.168.1.150 -> 0:80:5a:54:32:67
  17:55:58 - Request >> Add entry 192.168.1.150
  17:55:58 - Reply   << Refresh entry 192.168.1.150 -> 0:80:5a:54:32:67
...

To sum up the running of ArpON into DARPI mode, first point out that ArpON handles its own ARP table called DARPI cache, by applying several rules to different kinds of packets.

ARP request

For the outbound traffic (packets generated by us), ArpON lets them pass, by adding an entry with the target into the DARPI cache. For the inbound traffic (packets which come to us from the network), ArpON refuses the packet, by deleting the entry of the source address written down into the ARP cache, because that packet could be poisoned. Later, the kernel will send out an ARP request so as to make sure the origin.

ARP reply

For the outgoing traffic, ArpON just lets them pass. For the incoming traffic, ArpON verifies whether the source address matches an entry in the DARPI cache. If so, it lets the packet get in, by adding an entry into the ARP cache. Otherwise, it denies the packet, by removing the entry from the ARP cache.

To begin with the test, we are going to run a MitM attack between the router and the victim.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/

If we review the ArpON log again, we can see that the poisoning attempts from the attacker are correctly rejected.

root@victim:~# tail -f /var/log/arpon/arpon.log
...
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:16 - Reply   << Delete entry
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:17 - Reply   << Delete entry
192.168.1.1 -> 0:c:29:20:9f:9b
  18:13:18 - Reply   << Delete entry
...

You may likewise check out this situation by activating the chk_poison plugin through the same ettercap.

root@attacker:~# ettercap -TqM arp:remote /192.168.1.1/ /192.168.1.10/
...
Plugin name (0 to quit): chk_poison
Activating chk_poison plugin...

chk_poison: Checking poisoning status...
chk_poison: No poisoning between 192.168.1.10 -> 192.168.1.1

Another way is to print the ARP cache again. As you can distinguish, a new entry relative to the attacker has been added, and the other ones keep in the same state.

root@victim:~# arp -a
? (192.168.1.11) at 00:0c:29:18:36:e6 [ether] PERM on eth0
? (192.168.1.20) at 00:0c:29:20:9f:9b [ether] PERM on eth0
? (192.168.1.1) at 00:60:b3:50:ab:45 [ether] PERM on eth0
? (192.168.1.150) at 00:80:5a:54:32:67 [ether] PERM on eth0