CCIE Security V4 Technology Labs  Section 5:

Perimeter Security and Services - ASA Firewalls


ARP Inspection
Last updated: May 15, 2013

Task
The ASA1 should enforce consistency in ARP requests and responses.
Manually configure the IP to MAC address mappings for R1 and R2 Ethernet interfaces to
accomplish this.
Do not flood unmatched ARP requests between the security levels.

Overview
ARP traffic is permitted to flow across the transparent firewall to facilitate in IP address resolution.
However, certain types of network attacks utilize ARP and might compromise your network
security. The most common attack is known as ARP spoofing, in which a malicious user sends
crafted ARP packets to poison another host's ARP cache and pretend it is operating under a
different IP address. This allows an attacker to attract traffic not intended for it, such as by taking
over the default gateway’s IP.

ARP inspection prevents this type of attack by looking inside the ARP replies/responses and
verifying that the IP to MAC address bindings inside match the preconfigured table. To activate this
feature, you must first populate the static bindings table using the command
arp {iface} <IP> <MAC>, which binds the IP to the MAC on the particular interface. To enable
ARP inspection for ARP packets entering a particular interface, use the command
arp-inspection {iface} enable [flood|no-flood].The flood option permits ARP packets
that contains IP addresses not matching the static table to be flooded out on other interfaces. The
no-flood option will permit only valid ARP packets for IP addresses in the inspection table.

Unlike ARP inspection in the Catalyst switches, the ASA firewall cannot use DHCP snooping to
populate the ARP bindings table. Therefore, the configuration burden lies with the system
administrator.

Configuration
 arp inside 10.0.0.1 0007.7d3d.94e8
arp outside 10.0.0.2 0007.7dce.0f00
!
arp-inspection outside enable no-flood
arp-inspection inside enable no-flood

Verification
First, make sure you can ping from R1 to R2.

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

Next change the Mac address on R2.

Rack1R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R2(config)#int g0/0
Rack1R2(config-if)#mac-address 000f.90fb.2d22
Rack1R2(config-if)#

At this point the ping would fail, because the ARP packets from R2 are no longer valid and the
firewall drops them.

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

Enable logging on the ASA to see the drops.

 %ASA-3-322002: ARP inspection check failed for arp request received from host 000
f.90fb.2d22 on interface outside. This host is advertising MAC Address 000f.90fb.
2d22 for IP Address 10.0.0.2, which is statically bound to MAC Address 0007.7dce.
0f00

Change the IP address of R2 to something not covered by the inspection table.

Rack1R2(config-if)#int g0/0
Rack1R2(config-if)#ip add 10.0.0.5 255.255.255.0
Rack1R2(config-if)#

Enable the flood option with ARP inspection.

Rack1ASA1(config)# arp-inspection inside enable flood

Rack1ASA1(config)# arp-inspection outside enable flood

This time, the ping operation will work fine.

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

Additionally, you can see the OSPF relationship establish.

Rack1R1#
Apr 9 20:07:14.671: %OSPF-5-ADJCHG: Process 1, Nbr 150.51.0.2 on GigabitEthernet
0/0 from LOADING to FULL, Loading Done