Friday, December 30, 2011

DHCP Based Security Part 3: Dynamic ARP Inspection

This post closes out a 3 post series on DHCP based security technologies for the Cat3560 (among others) switching platform. We first took a look at DHCP Snooping, and then we built upon that with IP Source Guard. Finally, we've come to Dynamic ARP Inspection, or just DAI.
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.

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).

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

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).

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...

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.

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