Hello and welcome. My name is Tyler McMinn, and this is the Aruba Network Security Basics video series Part 1 and video 12, where we are going to close out with this discussion on using DHCP snooping and ARP protection. In the last video, we had wrapped up with Securing our authenticated network time protocol, as well as some other best practices for protecting your network. In this one, we're going to dive in for a bit of a technical discussion on revisiting the idea of ARP poisoning, looking at a great solution for defending against spoofed IP addresses, spoofed mac addresses, and defending against this ARP poisoning and attack. So let's jump on it. How to use DHCP snooping and what it does with the feature ARP protection. Before we get into DHCP snooping we need to know how DHCP works. For those of you that have been using networking and know a bit about DHCP, Dynamic Host Configuration Protocol. What DHCP does is it allows your client devices to pull an IP address, a subnet mask, a gateway, any number of options that you want to give them, DNS address. We've got a couple of users in a certain subnet we'll call it a VLAN number 11 that are pulling addresses for 10.1.11 something, 11.1, 11.2, 11. We've got a router over here, and we have a DHCP server in another part of our network that's listening for this traffic. So the way DHCP would operate is first, a would-be Client down here, we'll call it Alice, our user. She would send out a broadcast and the swayed would flood that everywhere within our subnet and that would hit our gateway. Our server is not in our subnet, so how is Alice going to get the DHCP assignment? The way Alice would receive it is your server could forward that request using a command called IP helper address. The Router, I'm sorry, would forward that to the DHCP server, what we call the DHCP relay. When the server receives that DHCP relay, the server can respond back to the source of that relay, the subnet that this gateway is in, and offer an address, a DHCP offer. So this offer is going to be in the 10.1.11 range because that's where the gateway received it. The server responds back to the gateway, says here's an offer, the gateway then just passes the node along it access what we call a proxy. It just hands it off, and that goes back to the original requester Alice over here, who wants that address. If the address is valid, Alice will send a second broadcast saying, "Yes, I like that, I've been requesting that address." That would again flood everybody, hitting the core switch, the gateway. The gateway will again relay that to the server, and the server will accept it and send an acknowledgment saying, "Okay, that's your address." That again gets forwarded and relayed back to Alice. Alice now has their address. But one thing you might notice about this is that other users are getting a copy of this information, at least in the same subnet, and this can open us up to a few problems here. Some DHCP attacks that a malicious Mallory might take is things like address spoofing by a row DHCP server or doing what we call address exhaustion. Address spoofing is where an eligible user will attempt to flood bad addresses into your subnet to invalidate your user traffic or to do a Man In The Middle. If I flood in a bunch of 192, 168 addresses that have nothing to do with your 10. network, they're not the right addresses, you're not going to be able to surf the web, denial-of-service. Or maybe I send you the addresses you need in the right subnet, but I forward to them to point to me as your gateway, enforcing what we call a Man In The Middle. Or maybe I don't want anybody to get an IP address. I could just simply ask for all the addresses that the subnet has available, and after getting hundreds of addresses assigned to me, there's none left to hand out, effectively creating a denial-of-service. These types of attacks can be a bit of annoying. So the way that we defend against them using our trusty Aruba OS switch, not the newer Cx, but the older one and Cx supports this as well, is enabling a feature known as DHCP snooping. What DHCP snooping does on our switch is as soon as you enable it, it sets your ports in that VLAN to be untrusted. So the command here is DHCP snooping, VLAN whatever, and specify what ports I trust, because all my other ports are untrusted. An untrusted port will still accept valid DHCP client requests. It doesn't mean that Alice is suddenly out of luck, she can still send a request and those can still be forwarded to a DHCP server, all that's fine. The responses though, because again, this is flooded out. If they were flooded out to this rogue server, the rogue server then could send a response back and cause Alice to have a problem. So instead, one thing about these untrusted ports is that they're not forwarded to anybody else except for a trusted uplinks. You want to make sure you enable what's your trusted interface. We have an interface called trk or trunk 1. This interface would receive these client requests and forward them onto a DHCP server, and allow the server to respond back, and therefore handout the address that Alice needs. The whole time leaving a rogue attacker or just any other users in the dark about what Alice is doing. They don't need to know, so it's not a big deal. On top of that, it goes the extra mile here, so that when you have this DHCP Discover sent and this offer sent back, that a row server who sends their own offer acting as a DHCP server to spoof or to do a denial-of-service, that would be dropped and could trigger an alert. These invalid DHCP responses because this is not a DHCP server or nor should it be, then we would just simply drop those, those frames wouldn't be allowed. That's Part 1 of DHCP is snooping. But there's a second part to DHCP snooping that we're going to use as well, and it has to do with ARP or ARP snooping. Take Alice who sends ARP requests. If you remember this from a previous video we went through and we looked at Alice talking to Bob in Part 1, video 5, where Alice is sending a request to learn Bob's MAC address so she could build her ARP table since the cache timed out. So this flood went out, here we have malicious Mallory poisoning Alice's art table. Even though Bob responds, Alice continues to overwrite that with her own MAC address, and she's trying to trick Alice into thinking she's Bob's destination. Or sending gratuitous ARPs that if Bob wants to talk to Alice, that Bob should send it to the MAC address of Mallory. Effectively, Mallory is trying to be that man in the middle between the two users, Alice and Bob. So how do we solve this? Here it is. You enable IP-DHCP snooping, and this tied with ARP protection gives you the protection you need. Because what DHCP should be snooping does on the switch is it builds a table of what IP addresses have been matched to what requested MAC address. When Mallory got connected as a user in our network here, she got a DHCP address, and the switch now keeps track of that. Even if it's a Layer two switch that doesn't really pay attention to IP addresses, when you enable IP-DHCP snooping, you build this table on the switch. The switch automatically updates with Mallory's information here and Mallory's MAC address. So if later, Mallory sends a gratuitous ARP telling Bob that she has the address of 10.1.1.10, and Bob should send it to her, we would immediately be alerted and drop Mallory's traffic or drop that ARP poisoning attempt. This is where ARP protection can leverage that DHCP snooping table in order to have a legitimate binding table to verify the correct IP to MAC bindings. The switch drops responses with invalid bindings. Pretty cool way to defend against the wired attacks that you would see. We'll see something similar on the wireless side in part 2, but for part 1, this is not bad. So that is it. That's going to finish our discussion on part 1 where we were talking about hardening switching devices, talking about threats, different viruses, different standards when it comes to security at a very broad level. When we come back in the next video, I'm going to walk you through some hands-on labs where I'll actually go in and harden these Aruba OS and these are Aruba CX switches in our lab environment using real Aruba OS and real Aruba CX switches to demonstrate on. Again, thank you for your time. I will see you guys in the next video.
