Dynamic ARP Inspection

I covered DHCP snooping in my last post, and I skimmed over the high-level of Dynamic ARP Inspection.  Turns out there's a fair amount to DAI!

Our lab is as follows:

 



 

 

 

 

 

 

Basic DHCP snooping is already enabled and functional.  For more information on DHCP snooping, http://brbccie.blogspot.com/2013/03/dhcp-snooping-and-option-82.html

 

DAI's primary function is to prevent man-in-the-middle attacks via ARP.  DAI typically uses the DHCP snooping database to know what IPs belong with which MAC addresses on which ports.  If an ARP reply is generated on a port it shouldn't have happened on, the packet is logged and dropped.

 

The basic setup is simple:

 

SW1(config)#ip arp inspection vlan 100

R1 is statically assigned 192.168.100.1 and is acting as a DHCP server.  R3 has received 192.168.100.2.  192.168.100.2 is associated with 0012.43c1.6f20. 

 

First let's make sure R1 can ping R3.

 

R1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

 

That didn't take long to break!  Let's look at the switch.

 

SW1(config)#
*Mar  1 22:20:39.106: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/1, vlan 100.([0013.c460.2be0/192.168.100.1/0000.0000.0000/192.168.100.2/22:20:38 UTC Mon Mar 1 1993])
 

DAI not only looks at replies, it also looks to see if requests came from a valid source.  Talk about picky! 

 

We need to trust the port of the DHCP server to fix this.

 

SW1(config-if)#ip arp inspection trust

R1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Now we're getting somewhere.

 

R1#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.100.1           -   0013.c460.2be0  ARPA   FastEthernet0/0
Internet  192.168.100.2           0   0012.43c1.6f20  ARPA   FastEthernet0/0

We'll see this corresponds with the DHCP snooping database:

 

SW1#sh ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:12:43:C1:6F:20   192.168.100.2    84439       dhcp-snooping   100   FastEthernet0/3
Total number of bindings: 1

 

Now let's try and break this thing.

 

I've setup a default route on R1 towards Fa0/0:

R1(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

Note this isn't good design, but I'm just setting this up for a test.

 

I put an Lo7 on R3:

 

interface Loopback7
 ip address 7.7.7.7 255.255.255.255
 

This will cause R3 to proxy ARP for 7.7.7.7.

 

R1#ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
 

Not unsurprisingly, we don't get a response.  Let's check the switch:

 

SW1#
*Mar  1 22:35:55.813: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/3, vlan 100.([0012.43c1.6f20/7.7.7.7/0013.c460.2be0/192.168.100.1/22:35:55 UTC Mon Mar 1 1993])

As expected.

 

So, this system breaks proxy ARP.  How do we fix this?

We could trust the port, but we wouldn't learn anything that way. 

Let's try an ARP access list instead.

 

SW1:

arp access-list FIXPROXY
 permit ip host 7.7.7.7 mac host 0012.43c1.6f20 log

ip arp inspection filter FIXPROXY vlan  100

R1#ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

That's better.

 

The ARP access-list has a gigantic "gotcha" to be aware of: instead of an implicit deny, it has an implicit "check-the-dhcp-snooping-database".  So that access-list check comes in front of the DHCP snooping check, but it is followed by the DHCP snooping check.

 

If you want the access-list alone to be consulted for DAI (decoupling dhcp snooping and DAI), you can add a deny to the end of the ARP ACL manually:

 

arp access-list FIXPROXY
 permit ip host 7.7.7.7 mac host 0012.43c1.6f20 log
 deny ip any mac any

R1#clear arp
R1#ping 7.7.7.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Now only the access-list is consulted.  This is also points out that you can run DAI without DHCP snooping: put all the valid ARPs in an ARP access-list and turn of DHCP snooping.

 

Another way you can accomplish the same thing, rather than using the explicit "deny any" statement, is to put the "static" keyword at the end of the arp inspection filter statement:

 

arp access-list FIXPROXY
 permit ip host 7.7.7.7 mac host 0012.43c1.6f20 log

ip arp inspection filter FIXPROXY vlan  100 static

 

The "static" keyword instructs the ACL that it should use an implicit deny.

 

There are a lot of logging options in DAI.

 

If you want to log hits on the ACL, you must both use the log command on the ACL, and:

ip arp inspection vlan 100 logging acl-match matchlog

 

SW1(config)#
*Mar  2 01:07:55.480: %SW_DAI-6-ACL_PERMIT: 1 ARPs (Res) on Fa0/3, vlan 100.([0012.43c1.6f20/7.7.7.7/0013.c460.2be0/192.168.100.1/01:07:55 UTC Tue Mar 2 1993])

To log permits on the DHCP snooping database:

(I re-enabled matching on the DHCP snooping database first)

 

ip arp inspection vlan 100 logging dhcp-bindings all    ! "permit" and "none" are also option

 

R1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

SW1(config)#
*Mar  2 01:29:14.918: %SW_DAI-6-DHCP_SNOOPING_PERMIT: 1 ARPs (Res) on Fa0/3, vlan 100.([0012.43c1.6f20/192.168.100.2/0013.c460.2be0/192.168.100.1/01:29:14 UTC Tue Mar 2 1993])

 

Blocked attempts are logged by default, but clearly you don't want console output for every single attempt, especially if you were under attack.  The rate limiting is done via:

ip arp inspection log-buffer entries <number>

ip arp inspection log-buffer logs <number> <interval>

 

The first parameter specifies how many logs to hold, the second specifies how often to empty the buffer and how many to pull from it.

 

This covers the general concepts of DAI - as well as a great deal of logging. Now let's run through the laundry list of extra commands.

 

To instruct DAI to inspect the embedded source MAC address in the frame against the MAC address of the sender, use:

ip arp inspection validate src-mac

 

To instruct DAI to inspect the embedded destination MAC address in the frame against the MAC address of the intended receiver, use:

ip arp inspection validate dst-mac

 

To instruct DAI to look for binding 255.255.255.255, 0.0.0.0, and the multicast address range against a MAC address, use:

ip arp inspection validate ip

 

ARP rate limiting is on by default on untrusted ports.  The default number of ARPs-per-second permitted is 15.  To change the rate, use:

ip arp inspection limit rate <pps> [burst] <seconds> [none]

 

Hope you enjoyed!

 

Jeff