Just like that last two posts I'm using this simple topology. The basic config and what's enabled up to this point is in the prevous two posts mentioned.
I suppose it is fitting to start this off with a description of DAI, and what problem it solves.
DAI was designed to mitigate the threat of ARP cache poisoning which in turn can lead to Man-in-the-Middle attacks. DAI allows the switch to monitor the ARP traffic that passes though it and determine if a given ARP frame is valid. What constitutes a valid ARP frame? I'm glad you asked! A valid ARP frame is one that has ARP information within that corresponds to how the switch thinks a device is connected. Or put another way, a valid ARP frame in originated from where it should be originated from.
And how does the switch know where an ARP frame should be coming from? Really? You have to ask that?
Go back to the beginning of this series and read from there :P
Yes, it knows because the switch already has a database of all this information: The DHCP Snooping binding database.
If we recall, we have DHCP Snooping already configured, and we have a (small) snooping database already.
Cat2#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:0A:B8:19:AB:78 10.6.7.5 81056 dhcp-snooping 67 FastEthernet0/6
Total number of bindings: 1
In there we have a MAC, and IP, and a port that both addresses is known to be connected to.
Perfect.
To apply this to ARP let's first take a quick look at an ARP frame's format. Here's a screen capture of an ARP frame I captured from my laptop using Wireshark.
This is a ARP Request frame. We know this because it has a destination of FF:FF:FF:FF:FF:FF and the target MAC field is all zeros while the target IP field is a valid IP. This is what we commonly think of as "Who has 192.168.1.1? Tell 192.168.1.10".
And just to be complete, here's the ARP Reply for the ARP Request above.
Naturally the sender and target fields are reversed, and now all four fields are populated. This is the "192.168.1.1. is at H.H.H" response we all know and love.
If you're interested in learning more about ARP I encourage you to read RFC 826.
In examining the ARP frames we see there is a lot of information in common with what we already have stored in our DHCP snooping binding database. Mainly, MACs and IPs. So if we know what port a MAC and IP are connected to, it should be a simple matter to inspect ARP frames and ensure that the information in that ARP frame, primarily the sender MAC and IP, match the information in our snooping binding database.
And that's what DAI does.
So let's configure DAI then. Again, on Cat2, we first enable DAI on specific VLANs, and we then define which ports are to be trusted (by default all ports are untrusted).
Cat2(config)#ip arp inspection vlan 67
Cat2(config)#int f0/7
Cat2(config-if)#ip arp inspection trust
In this case we're going to trust our gateway facing port since we know that's where our router is connected, and we trust our router. As well, the router has a static IP so there will never be a snooping binding entry for it (unless we create a static entry).
What does 'trusted' mean? It means that ARP frames received on that port will not be compared to the snooping binding DB and will instead be forwarded normally.
To verify there's a few show commands we can look at. But for right now I'm just going to look at the two ports we're using specifically (you'll see more in a moment).
Cat2#sh ip arp inspection int f0/6
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Fa0/6 Untrusted 15 1
Cat2#sh ip arp inspection int f0/7
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Fa0/7 Trusted None N/A
Nothing fancy here. f0/6 is untrusted (default) and f0/7 is trusted. You'll also notice some columns relating to rate and burst. DAI also allows you to control the rate at which ARP frames are accepted from a port. You can explore that aspect of DAI further with the following command (I'm not going to look at it further).
Cat2(config-if)#ip arp inspection limit ?
none No limit
rate Rate Limit
So this is all fine and dandy, but how can we prove that this is working? Well, since I'm on a vRack out on the Internet somewhere I don't have the luxury of connecting up my laptop and spoofing some ARP traffic to try and perform a MitM attack on the devices. But, what I can do is go back to our old friend R2 that we used in the DHCP Snooping post and spoof the MAC of R6. What we should see is Cat2 drop any ARP frames that R2 generates...
Let's take a baseline before we begin.
Cat2#sh ip arp inspection stat vlan 67
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
67 0 0 0 0
Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
67 0 0 0 0
Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data
---- ----------------- ---------------------- ---------------------
67 0 0 0
And if we look at DAI in general (for VLAN 67) we see the following settings.
Cat2#sh ip arp inspection vlan 67
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
---- ------------- --------- --------- ----------
67 Enabled Active
Vlan ACL Logging DHCP Logging Probe Logging
---- ----------- ------------ -------------
67 Deny Deny Off
DAI IS enabled and active on VLAN 67.
Let's add R2 and configure it accordingly. Then a ping to R7 to generate some ARP traffic.
R2(config)#int g0/1
R2(config-if)#ip add 10.6.7.2 255.255.255.0
R2(config-if)#mac-address 000a.b819.ab78
R2(config-if)#no shut
R2(config-if)#
*Dec 31 00:31:18.583: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Dec 31 00:31:19.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
R2(config-if)#do ping 10.6.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.7.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2(config-if)#do sh ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.6.7.2 - 000a.b819.ab78 ARPA GigabitEthernet0/1
Internet 10.6.7.7 0 Incomplete ARPA
Nothing. And if we're keeping an eye on Cat2's console we'll see the following.
*Mar 1 03:37:57.814: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa0/2, vlan 67.([000a.b819.ab78/10.6.7.2/0000.0000.0000/10.6.7.7/03:37:57 UTC Mon Mar 1 1993])
That's what we want to see! Looking carefully at that debug message we see the four main fields in an ARP frame, and their values.
If we look at the DAI stats again we see:
Cat2#sh ip arp inspection stat vlan 67
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
67 0 5 5 0
Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
67 0 0 0 0
Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data
---- ----------------- ---------------------- ---------------------
67 0 0 0
5 dropped ARPs. One for each attempted ping. Success!
And again, just like the other two posts, let's conclude this with a look at creating some static bindings we can use with DAI.
I hope you're not too surprised, but again we have yet another way to configure the static bindings. DHCP Snooping was an EXEC mode command. IP Source Guard was a Config mode command. And now DAI we're going to create an ARP access-list and apply it as an ARP Inspection filter.
Yeh... I know...
Well here we go anyway. I'm going to create a static binding for our R2 that we added.
Cat2(config)#arp access-list My_DAI
Cat2(config-arp-nacl)#permit ip 10.6.7.2 0.0.0.0 mac 0011.9369.1481 0.0.0
Cat2(config)#ip arp inspection filter MyDAIFilter vlan 67 ?
static Apply the ACL statically
Cat2(config)#ip arp inspection filter My_DAI vlan 67
Cat2(config)#
You'll notice the optional 'static' keyword that I didn't use in the DAI filter command. If you add that keyword it actually disallows the use of dynamic bindings from DHCP completely. I chose not to do that here as I want R6 to continue to function, and also allow R2.
So now we should be able to ping from R2.
R2(config-if)#do ping 10.6.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.6.7.7, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
R2(config-if)#
Yes sir! We sure can.
Quick show commands, we now see ACL permits in our DAI stats.
Cat2#sh ip arp inspection stat vlan 67
Vlan Forwarded Dropped DHCP Drops ACL Drops
---- --------- ------- ---------- ---------
67 2 6 6 0
Vlan DHCP Permits ACL Permits Probe Permits Source MAC Failures
---- ------------ ----------- ------------- -------------------
67 0 1 0 0
Vlan Dest MAC Failures IP Validation Failures Invalid Protocol Data
---- ----------------- ---------------------- ---------------------
67 0 0 0
And we also see that we have an ACL (not static) on VLAN 67.
Cat2#sh ip arp inspection vlan 67
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
---- ------------- --------- --------- ----------
67 Enabled Active My_DAI No
Vlan ACL Logging DHCP Logging Probe Logging
---- ----------- ------------ -------------
67 Deny Deny Off
And that concludes my series on DHCP based Security for Cisco 3560 and other switches. As always I welcome comments, questions, corrections, or criticism. You'll find the comments section below. :)
References:
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst3560/software/release/12.2_58_se/configuration/guide/swdynarp.html
No comments:
Post a Comment