WEBVTT 0:00:03.240000 --> 0:00:07.120000 Hello and welcome to this video where we're going to do a refresh on dynamic 0:00:07.120000 --> 0:00:11.020000 ARP inspection and talk about what it's useful for, how to configure it, 0:00:11.020000 --> 0:00:14.140000 and how to monitor it. 0:00:14.140000 --> 0:00:20.100000 All right, so what problem is solved with dynamic ARP inspection? 0:00:20.100000 --> 0:00:27.460000 Well, at its basis, a lot of the same fundamental reasons why DHCP could 0:00:27.460000 --> 0:00:32.740000 provide an attack surface for us is also why ARPs could provide an attack 0:00:32.740000 --> 0:00:35.280000 surface. Let me explain. 0:00:35.280000 --> 0:00:39.840000 We know that an ARP request goes out as a broadcast. 0:00:39.840000 --> 0:00:43.380000 So once again, as a switch receives an ARP request, it will normally just 0:00:43.380000 --> 0:00:47.080000 flood that to everybody, which means if someone's running a wire shark 0:00:47.080000 --> 0:00:50.980000 stiffer capture or something like that, they now know who you're interested 0:00:50.980000 --> 0:00:54.680000 in. You know, if you're ARPing for somebody, they know what your IP address 0:00:54.680000 --> 0:00:57.880000 is, they know the IP address or the thing you're ARPing for that you have 0:00:57.880000 --> 0:01:01.420000 interest for that, and they know your MAC address, and they can use that 0:01:01.420000 --> 0:01:06.120000 against you. For example, here we have a situation where PCA is ARPing 0:01:06.120000 --> 0:01:07.900000 for his default gateway. 0:01:07.900000 --> 0:01:11.880000 The malicious evil person sees that and says, okay, now there's nothing 0:01:11.880000 --> 0:01:15.200000 that the person can do to stop the ARP response. 0:01:15.200000 --> 0:01:20.240000 That is a unicast packet, so right now PCA has the correct entry. 0:01:20.240000 --> 0:01:22.500000 113 equals MAC address CC. 0:01:22.500000 --> 0:01:23.880000 That is correct. 0:01:23.880000 --> 0:01:30.060000 But that person there, that malicious evil person, is aware that PCA exists, 0:01:30.060000 --> 0:01:32.760000 and PCA is interested in his default gateway. 0:01:32.760000 --> 0:01:36.000000 So now that person can do, that malicious person can change their own 0:01:36.000000 --> 0:01:40.620000 IP address to match the default gateway, leaving their own MAC address 0:01:40.620000 --> 0:01:45.000000 alone as MAC address BB, and now that person can send an unsolicited ARP 0:01:45.000000 --> 0:01:49.300000 response and say, hey, PCA, just want you to know I'm your router, but 0:01:49.300000 --> 0:01:50.580000 my MAC address has changed. 0:01:50.580000 --> 0:01:55.060000 I'm still 1113, just like your ARP for, but now my MAC address is BB, 0:01:55.060000 --> 0:01:57.080000 which is clearly wrong. 0:01:57.080000 --> 0:02:00.760000 So we have now poisoned the ARP cache of PCA. 0:02:00.760000 --> 0:02:01.700000 So what's this going to mean? 0:02:01.700000 --> 0:02:05.720000 Well, now when PCA needs to send any packets that are off network, which 0:02:05.720000 --> 0:02:10.880000 let's face it, that's like 99% of what you do is off your own subnet, 0:02:10.880000 --> 0:02:15.100000 those packets are going to be directed via ethernet to the MAC address 0:02:15.100000 --> 0:02:18.880000 of the malicious rogue person. 0:02:18.880000 --> 0:02:21.240000 They're going to get your packets because it's going to their MAC address 0:02:21.240000 --> 0:02:26.940000 BB. Now, if they're smart, they will forward your traffic to the actual 0:02:26.940000 --> 0:02:29.840000 router so it can get to the outside world, but now they have visibility 0:02:29.840000 --> 0:02:33.820000 of everything you're doing, all outbound packets you're sending that you 0:02:33.820000 --> 0:02:36.900000 think you're sending to your default gateway are going to this man in 0:02:36.900000 --> 0:02:39.360000 the middle instead. 0:02:39.360000 --> 0:02:45.280000 So dynamic ARP inspection is very simple how it works. 0:02:45.280000 --> 0:02:50.600000 First of all, like it says here, it works hand in hand with the DHCP snooping 0:02:50.600000 --> 0:02:52.460000 binding database. 0:02:52.460000 --> 0:02:53.840000 So here's how it works. 0:02:53.840000 --> 0:03:00.800000 When dynamic ARP inspection is enabled for a particular VLAN, then every 0:03:00.800000 --> 0:03:06.740000 ARP packet, whether it be an ARP request or an ARP reply that comes into 0:03:06.740000 --> 0:03:10.940000 that VLAN is going to be stopped, and we're going to inspect it against 0:03:10.940000 --> 0:03:13.020000 the DHCP snooping binding database. 0:03:13.020000 --> 0:03:20.320000 So for example, if PC 1111 on port 1 sends an ARP request, that's going 0:03:20.320000 --> 0:03:21.200000 to come into the switch. 0:03:21.200000 --> 0:03:23.040000 The switch is going to say, hold on a second. 0:03:23.040000 --> 0:03:26.700000 Before I transmit your ARP request, before I forward it, let me verify 0:03:26.700000 --> 0:03:28.120000 that you are who you say you are. 0:03:28.120000 --> 0:03:32.920000 So you say you're 1111 and you're on port 01 and you say this is your 0:03:32.920000 --> 0:03:35.640000 MAC address. Let me see if that's true. 0:03:35.640000 --> 0:03:38.740000 I'm going to go into the DHCP snooping binding database because after 0:03:38.740000 --> 0:03:43.260000 all, you got that IP address via DHCP. 0:03:43.260000 --> 0:03:46.300000 And oh, yep, there you are right in the DHCP snooping database. 0:03:46.300000 --> 0:03:50.120000 It does say you're 1111, that does match with the MAC address that you 0:03:50.120000 --> 0:03:54.480000 say you are, and apparently that was learned on port number one. 0:03:54.480000 --> 0:03:55.240000 You're good to go. 0:03:55.240000 --> 0:03:58.020000 I'll go ahead and forward your ARP request. 0:03:58.020000 --> 0:04:00.540000 And the same thing happens when the ARP reply comes back. 0:04:00.540000 --> 0:04:05.940000 It'll be stopped, paused, and inspected against the DHCP snooping binding 0:04:05.940000 --> 0:04:11.160000 database. If there is no match, we will drop that ARP packet. 0:04:11.160000 --> 0:04:13.960000 Now, here's a challenge with this. 0:04:13.960000 --> 0:04:20.100000 This is all well and good if the ARP requests and the ARP responses are 0:04:20.100000 --> 0:04:25.740000 coming from devices that obtain their IP address via DHCP because their 0:04:25.740000 --> 0:04:30.520000 information, their binding, is in the DHCP snooping binding database. 0:04:30.520000 --> 0:04:35.500000 But what if we have a device with a static IP address like a router, like 0:04:35.500000 --> 0:04:39.960000 a server? Well, that's not going to be in your DHCP binding tail because 0:04:39.960000 --> 0:04:45.880000 they don't do DHCP, which means that ARP requests going to them will make 0:04:45.880000 --> 0:04:50.060000 it there. But then when they send their ARP reply, the switch will not 0:04:50.060000 --> 0:04:53.180000 be able to validate their ARP reply because there will be no entry in 0:04:53.180000 --> 0:04:56.360000 the binding database to validate that they are who they say they are, 0:04:56.360000 --> 0:04:59.680000 or if they try to ARP something themselves, like they're trying to ARP 0:04:59.680000 --> 0:05:01.300000 their default gateway. 0:05:01.300000 --> 0:05:03.760000 Once again, those ARPs will be dropped. 0:05:03.760000 --> 0:05:05.080000 So how do we deal with that? 0:05:05.080000 --> 0:05:06.320000 Well, there's two ways. 0:05:06.320000 --> 0:05:12.160000 Just like DHCP snooping has a concept of untrusted and trusted interfaces, 0:05:12.160000 --> 0:05:15.000000 so does dynamic ARP inspection. 0:05:15.000000 --> 0:05:19.860000 This validation of ARPs, whether they be requests or replies, only takes 0:05:19.860000 --> 0:05:22.720000 place on untrusted interfaces. 0:05:22.720000 --> 0:05:26.820000 If you make an interface trusted, well, like it sounds, then we trust 0:05:26.820000 --> 0:05:31.680000 any ARP requests or replies that are received on that interface. 0:05:31.680000 --> 0:05:34.840000 So if you have an interface that's directly connected to an end host like 0:05:34.840000 --> 0:05:39.100000 a server or router, that has a static IP address, that's probably what 0:05:39.100000 --> 0:05:43.440000 you want to do is make that interface on the switch a dynamic ARP inspection 0:05:43.440000 --> 0:05:46.160000 trusted interface. 0:05:46.160000 --> 0:05:50.640000 But what if you have something like this? 0:05:50.640000 --> 0:05:56.440000 What if we had our switch right here? 0:05:56.440000 --> 0:06:02.440000 And maybe it was connected to a server, but this isn't any old server. 0:06:02.440000 --> 0:06:06.520000 This is a server running maybe VMware or something. 0:06:06.520000 --> 0:06:14.400000 And inside this VMware server, we have a whole bunch of VMs. 0:06:14.400000 --> 0:06:18.420000 So we have one physical link going there, but then we have a bunch of 0:06:18.420000 --> 0:06:23.620000 VMs with static IP addresses. 0:06:23.620000 --> 0:06:30.340000 All right, maybe this is 1111, 1112, 1113. 0:06:30.340000 --> 0:06:33.120000 Now those are known VMs that we put in there. 0:06:33.120000 --> 0:06:33.960000 Those are authorized. 0:06:33.960000 --> 0:06:37.400000 So you say, okay, well, I'll just make this interface on the switch trusted 0:06:37.400000 --> 0:06:40.680000 from the perspective of dynamic ARP inspection. 0:06:40.680000 --> 0:06:41.780000 But here's the problem. 0:06:41.780000 --> 0:06:45.780000 If somebody is able to gain access to that switch, what's to prevent them 0:06:45.780000 --> 0:06:51.500000 from configuring a rogue virtual machine with some other IP address? 0:06:51.500000 --> 0:06:58.020000 And now that rogue device has pure freedom to do some sort of ARP attack, 0:06:58.020000 --> 0:07:00.860000 because it's coming in on a trusted interface. 0:07:00.860000 --> 0:07:02.100000 What do we do then? 0:07:02.100000 --> 0:07:05.240000 Because trusted interface is not going to work in the situation. 0:07:05.240000 --> 0:07:09.540000 Well, in this case, what we would want to do is on that switch, we will 0:07:09.540000 --> 0:07:13.180000 want to leave that interface as untrusted, and we're going to want to 0:07:13.180000 --> 0:07:16.160000 configure an ARP access list. 0:07:16.160000 --> 0:07:19.560000 So for the known VMs or for those known static things, we'll configure 0:07:19.560000 --> 0:07:23.580000 an ARP access list saying this IP address and this MAC address, we know 0:07:23.580000 --> 0:07:25.740000 about them. Those are permitted. 0:07:25.740000 --> 0:07:30.120000 And then if something comes in that untrusted port that matches that ACL 0:07:30.120000 --> 0:07:32.500000 that's permitted, we let it through. 0:07:32.500000 --> 0:07:40.160000 If something comes in that does not match that ACL, then we drop it. 0:07:40.160000 --> 0:07:43.900000 So dynamic ARP inspection, just like DHCP snooping has the concept of 0:07:43.900000 --> 0:07:49.320000 untrusted and trusted interfaces, and it relies on the DHCP snooping binding 0:07:49.320000 --> 0:07:55.240000 database to do the validation of ARP requests and replies. 0:07:55.240000 --> 0:07:59.740000 Thank you so much for watching this video on a review of the theory and 0:07:59.740000 --> 0:08:01.900000 operation of dynamic ARP inspection.