Dynamic ARP Inspection in DHCP Environment

In ARP Spoofing Attack article, we provided a Python script that an attacker can use to poison the ARP cache of any IPv4 device on the network. We demonstrated the functionality of the script launching a successful Man-in-the-middle (Mitm) attack against a router R1 and PC1 (Figure 1).

In this tutorial, we will discuss how to mitigate an ARP poisoning attack on a network where a DHCP server is used. We will configure and  test Dynamic ARP Inspection (DAI) in our lab network with a DHCP server.

Picture 1 - Network Topology

Dynamic ARP Inspection (DAI)
Dynamic ARP inspection is security feature of the switches that is used to filter invalid ARP messages received on untrusted ports. Non-ARP messages are not affected.

DAI inspects the sender MAC and sender IP fields of ARP messages received on untrusted ports and check if they match the entry in DHCP snooping binding table. If there is a matching entry, the ARP message is forwarded normally. If there is not, ARP message is discarded.

DAI does not inspects ARP messages received on trusted ports.

If DHCP server is not used in a network and ARP inspection is enabled, ARP ACLs must be configured to map IP addresses to MAC for DAI to check. Otherwise the switch shuts down all the host because all ARP entries in the ARP table will be checked against nonexistent DHCP database.

Trusted vs Untrusted Ports
Trusted ports are typically connected to a network device such as routers or switches. Interfaces connected to end hosts should be configured as untrusted. All ports are untrusted by default.

DHCP snooping
DHCP snooping feature dynamically creates and maintains a database of IPs and their corresponding MAC addresses using information obtained from captured DHCP messages. For dynamic ARP inspection to work, DHCP snooping must be enabled on the switches and the DHCP server must be running on the network.

The DHCP snooping feature updates the database when the switch receives specific DHCP messages. For example, the feature adds an entry to the database when the switch receives a DHCPACK message from the server. The feature removes the entry in the database when the IP address lease expires or the switch receives a DHCPRELEASE message from the host.

If a switch detects DHCPOFFER and DHCPACK messages on untrusted ports, it discards the DHCP packets. Only DHCP DISCOVER and DHCP REQUEST are expected on untrusted ports as DHCPOFFER and DHCPACK are expected to be received on the trusted ports of the switch. The DHCP snooping database does not contain entries for hosts connected through trusted interfaces.

Configuration ARP Spoofing Prevention on Cisco Devices with DHCP Server

1. DHCP Server Configuration

First, we configure the DHCP server on R1. We will configure DHCP to reserve IP address 192.168.10.1 for PC and 192.168.10.50 for Kali.

R1(config)# ip dhcp pool VLAN1
R1(dhcp-config)# network 192.168.10.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.10.254

We need a dedicated pool for each reserved IP address. The client-identifier option prepends a 01 (for Ethernet) to the MAC address.

Reservation for PC1:
R1(config)# ip dhcp excluded-address 192.168.10.1

R1(config)# ip dhcp pool PC1
R1(dhcp-config)# client-identifier 010c.3bf2.b100.00
R1(dhcp-config)# host 192.168.10.1 255.255.255.0

Reservation for Kali:
R1(config)# ip dhcp excluded-address 192.168.10.50

R1(config)# ip dhcp pool Kali
R1(dhcp-config)# host 192.168.10.50 255.255.255.0
R1(dhcp-config)# client-identifier 010c.c01e.ee00.00

Once we finish DHCP configuration, we can check manual binding of IP addresses (Figure 2).

Figure 2 - Checking DHCP Binding on Router R1

2. DHCP Snoopping Configuration

DHCP Snooping must be enabled on switches prior to enabling DAI. If DHCP Snooping is not enabled or in non-DHCP environment, use ARP ACLS to permit or deny packets on a per-vlan basis.

2.1 S1 DHCP Snooping Binding

First, we need to define trusted ports. Ports that are not configured as trusted become untrusted by default.

S1(config)# interface range GigabitEthernet 0/0, GigabitEthernet 0/2
S1(config-if-range)# ip dhcp snooping trust

DHCP snooping must be enable globally and for each VLAN. We must also disable DHCP option-82 data insertion.

S1(config)# ip dhcp snooping
S1(config)# ip dhcp snooping vlan 1
S1(config)# no ip dhcp snooping information option

Each entry in the DHCP snooping binding database includes (Figure 3):

  • the MAC address of the host
  • the leased IP address
  • the lease time
  • the binding type
  • the VLAN number and interface information associated with the host.

Figure  3 - S1 DHCP Snooping Binding Table

2.2 S2 DHCP Snooping Binding

S2(config)# interface gigabitEthernet 0/2
S2(config-if)# ip dhcp snooping trust

S2(config)# ip dhcp snooping
S2(config)# ip dhcp snooping vlan 1
S2(config)# no ip dhcp snooping information option

Figure 4 - S2 DHCP Snooping Binding Table

3. Dynamic ARP Inspection Configuration

First, we need to define trusted ports. Ports that are not configured as trusted are untrusted by default.

S1:
S1(config)# interface range GigabitEthernet 0/0, GigabitEthernet 0/2
S1(config-if-range)# ip arp inspection trust

S1(config)# ip arp inspection vlan 1

S2:
S2(config)# interface gigabitEthernet 0/2
S2(config-if)# ip arp inspection trust

S2(config)# ip arp inspection vlan 1

4. Dynamic ARP Inspection Testing

We perform a ping from Kali to R1 and check the ARP table of Kali before the ARP spoofing attack (Figure 5). As expected, the ARP buffer of Kali contains the MAC address of R1 along with the IP address of default gateway - R1.

Figure 5 - ARP Cache on Kali Linux Before Attack

There are no discarded ARP messages on S2 (Figure 6).

Figure 6 - S2 ARP Inspection Statistics Before Attack

Now, start the ARP poisoning attack using the script arp_mitm.py with the following options:

$ sudo python3 ./arp_mitm.py eth0 192.168.10.1 192.168.10.254

Immediately, we got error message in the output of the console of S2 (Figure 7). Invalid ARP messages sent from Kali are filtered by S2 but other network traffic and valid ARP messages are forwarded. Thus, if the Kali device's ARP cache is flushed after the timeout, S2 does not filter ARP requests from the device.

Figure 7 - S2 Console Output During Attack

PC1 and R1 ARP caches are not poisoned by the MAC of Kali during the attack. The ARP cache of PC1 contains a correct MAC - IP entry for R1 (Figure 8).

Figure 8 - PC1 ARP Cache

When we stop the script with Ctrl-c, the will script send 20 continuous ARP gratuitous messages to broadcast Ethernet address in order to recover ARP cache of victim and the default gw. This triggers ARP packet rate limit and the interface Gi0/1 is put into err-disable state (Figure 9).

Figure 9 - S2 Console 

Note: A gratuitous ARP messages is an ARP reply that is sent without receiving an ARP request. It is sent to broadcast address and it allows other devices to learn MAC address of the sending devices without having to send ARP requests.

In general, a gratuitous ARP message does not have to have a malicious character. It may be sent when interface is enabled, IP or MAC addresses are changed.

Figure 10 shows the ARP inspection statistics after the attack; there are 82 discarded invalid ARP messages that are dropped based on DHCP snooping binding table.

Figure 10 - S2 ARP Inspection Statistics After Attack

To restore the Gi0/1 interface from the err-disabled state, we need to turn it off and on.

S2(config)# interface gigabitEthernet 0/1
S2(config-if)# shutdown
S2(config-if)# no shutdown

End.

2 thoughts on “Dynamic ARP Inspection in DHCP Environment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.