WEBVTT

0:00:03.080000 --> 0:00:07.680000
 Hello and welcome to this video titled,
 Securing Network Access with Dynamic

0:00:07.680000 --> 0:00:13.840000
 ARP Inspection. In this video, I'm going
 to cover what problem is solved

0:00:13.840000 --> 0:00:17.940000
 by using this security feature
 of Dynamic ARP Inspection.

0:00:17.940000 --> 0:00:20.720000
 We're going to look at an overview of
 operation, how does actually work

0:00:20.720000 --> 0:00:21.960000
 to solve the problem.

0:00:21.960000 --> 0:00:26.660000
 We're going to look at some terminology
 associated with this feature.

0:00:26.660000 --> 0:00:29.040000
 So let's start with the problem.

0:00:29.040000 --> 0:00:31.120000
 Solved by Dynamic ARP Inspection.

0:00:31.120000 --> 0:00:36.840000
 Well, ARP traffic along with so many other
 types of network protocol traffic

0:00:36.840000 --> 0:00:39.240000
 is broadcast based.

0:00:39.240000 --> 0:00:44.320000
 Not all ARPs, but when you ARP for something,
 when you send an ARP request,

0:00:44.320000 --> 0:00:46.340000
 that goes out as a broadcast.

0:00:46.340000 --> 0:00:49.980000
 And we all know what switches do
 when they receive a broadcast.

0:00:49.980000 --> 0:00:52.300000
 They take it in and
 they flood it out.

0:00:52.300000 --> 0:00:55.600000
 All the other ports that are
 in the same ingress VLAN.

0:00:55.600000 --> 0:01:01.400000
 Because of that, people with mal intent
 can use that to their benefit

0:01:01.400000 --> 0:01:04.240000
 to try to do bad things.

0:01:04.240000 --> 0:01:07.160000
 For example, look at PCA on here.

0:01:07.160000 --> 0:01:10.340000
 He's simply trying to ARP for his default
 gateway so that he can reach

0:01:10.340000 --> 0:01:12.600000
 the rest of the internet.

0:01:12.600000 --> 0:01:15.960000
 So he sends the ARP
 request for 1113.

0:01:15.960000 --> 0:01:19.340000
 Clearly, he already learned that was
 his default gateway back when he

0:01:19.340000 --> 0:01:22.400000
 did DHCP. Now, that's
 a broadcast packet.

0:01:22.400000 --> 0:01:25.560000
 So the malicious evil
 person will see it.

0:01:25.560000 --> 0:01:28.660000
 We go ahead and let the
 router respond back.

0:01:28.660000 --> 0:01:30.700000
 Now, the ARP response
 is a unicast.

0:01:30.700000 --> 0:01:33.940000
 So that malicious person
 won't see the response.

0:01:33.940000 --> 0:01:36.120000
 But the malicious person
 doesn't have to.

0:01:36.120000 --> 0:01:39.920000
 Now, the malicious person knows there's
 somebody out there who's interested

0:01:39.920000 --> 0:01:42.920000
 in the IP address of 1113.

0:01:42.920000 --> 0:01:45.640000
 Now, it doesn't take a lot of intelligence
 to realize that that is the

0:01:45.640000 --> 0:01:48.900000
 default gateway of that network.

0:01:48.900000 --> 0:01:52.640000
 So right now, PCA has the
 correct information.

0:01:52.640000 --> 0:01:56.620000
 It has the correct IP address to MAC
 address binding that was learned

0:01:56.620000 --> 0:02:01.020000
 via ARP. But wait, now the
 malicious person jumps in.

0:02:01.020000 --> 0:02:06.200000
 He says, instead of being 1112, I'm going
 to change my IP address to spoof

0:02:06.200000 --> 0:02:09.920000
 that server. So now he's
 changed to 1113.

0:02:09.920000 --> 0:02:12.420000
 And then he says, I'm going
 to send an ARP response.

0:02:12.420000 --> 0:02:14.680000
 What's called an unsolicited
 ARP response.

0:02:14.680000 --> 0:02:17.720000
 So even though nobody asked for it, I'm
 going to say, hey, everybody just

0:02:17.720000 --> 0:02:21.740000
 want you to know I'm 1113 and, oh,
 hey, my MAC address changed.

0:02:21.740000 --> 0:02:24.220000
 I'm now BB. Well, guess what?

0:02:24.220000 --> 0:02:28.060000
 That's going to poison or modify
 the ARP cache in PCA.

0:02:28.060000 --> 0:02:32.460000
 And so instead of now pointing at the
 correct MAC address of CC, he's

0:02:32.460000 --> 0:02:34.980000
 now pointing at the
 MAC address of BB.

0:02:34.980000 --> 0:02:39.220000
 Now, at this point, any time that PC
 sends anything to what he thinks

0:02:39.220000 --> 0:02:44.460000
 is his default gateway at layer two,
 it's going to our malicious evil

0:02:44.460000 --> 0:02:50.520000
 person. Now, if that malicious evil person
 is smart, they will then replay

0:02:50.520000 --> 0:02:54.500000
 that traffic out to the
 correct default gateway.

0:02:54.500000 --> 0:02:58.000000
 So PCA can actually get responses to
 the web lookups and everything else

0:02:58.000000 --> 0:02:58.800000
 he or she is doing.

0:02:58.800000 --> 0:03:04.240000
 And never even know the person in the
 middle is monitoring the traffic.

0:03:04.240000 --> 0:03:08.960000
 That's just one way of having an ARP
 attack is by injecting a man in the

0:03:08.960000 --> 0:03:10.120000
 middle of attack.

0:03:10.120000 --> 0:03:11.580000
 There's other attacks as well.

0:03:11.580000 --> 0:03:16.960000
 For example, a very common form of attack
 is called an ARP denial of service

0:03:16.960000 --> 0:03:22.080000
 attack, where, for example, let's say
 that I find out that I get sort

0:03:22.080000 --> 0:03:26.540000
 of wind that later on this afternoon,
 I'm going to be let go from the

0:03:26.540000 --> 0:03:29.880000
 company. I hear my boss say, hey, Keith,
 could you come in at four o'clock

0:03:29.880000 --> 0:03:32.260000
 so we can reevaluate your role?

0:03:32.260000 --> 0:03:34.820000
 And why don't you bring a
 support person with you?

0:03:34.820000 --> 0:03:37.160000
 Ah, OK, good, great.

0:03:37.160000 --> 0:03:38.320000
 Now I know what's going to happen.


0:03:38.320000 --> 0:03:39.940000
 So I decide, you know what?

0:03:39.940000 --> 0:03:42.720000
 I'm not going to go into
 that good night quietly.

0:03:42.720000 --> 0:03:46.260000
 So I decide before I go, I'm going
 to take a few people with me.

0:03:46.260000 --> 0:03:49.700000
 So I know that in this network,
 we're all in the 111 network.

0:03:49.700000 --> 0:03:53.260000
 I know the default gateway that everybody
 in this company uses is 1113

0:03:53.260000 --> 0:03:54.940000
 because this is a small company.

0:03:54.940000 --> 0:03:59.800000
 So why don't I just start pounding that
 router with thousands of ARP requests

0:03:59.800000 --> 0:04:03.880000
 every second? Every second, I'll send
 thousands of, hey, 1113, what's

0:04:03.880000 --> 0:04:05.420000
 your Mac? Hey, 1113,
 what's your Mac?

0:04:05.420000 --> 0:04:10.300000
 Well, because these are all broadcasts,
 the router has to pick these up.

0:04:10.300000 --> 0:04:15.660000
 His CPU has to answer these ARPs and
 his CPU is not designed to handle

0:04:15.660000 --> 0:04:18.760000
 thousands of ARP requests
 every single second.

0:04:18.760000 --> 0:04:20.940000
 That will crash that
 router and die.

0:04:20.940000 --> 0:04:24.580000
 And now before I leave the company,
 everybody on my floor has lost their

0:04:24.580000 --> 0:04:29.200000
 internet access, which might translate
 to billions and trillions of dollars

0:04:29.200000 --> 0:04:32.420000
 lost in those few hours.

0:04:32.420000 --> 0:04:36.400000
 So this is another thing that ARPs can
 be used for among many things to

0:04:36.400000 --> 0:04:41.000000
 perpetuate an attack, not that I would
 ever do that, but just so you know,

0:04:41.000000 --> 0:04:45.720000
 so how does dynamic ARP inspection
 prevent these types of things from

0:04:45.720000 --> 0:04:52.380000
 happening? Well, dynamic ARP inspection
 works hand in hand with DHCP snooping.

0:04:52.380000 --> 0:04:56.020000
 Now, if you haven't already learned about
 DHCP snooping, I would recommend

0:04:56.020000 --> 0:04:58.020000
 you find some of our videos
 that talk about that.

0:04:58.020000 --> 0:05:01.660000
 We have several videos that do read
 about it somewhere, but you really

0:05:01.660000 --> 0:05:05.960000
 need to know about DHCP snooping and
 how it builds its own separate table,

0:05:05.960000 --> 0:05:09.660000
 which is called, as you can see right
 here, the DHCP snooping binding

0:05:09.660000 --> 0:05:13.260000
 database. You need to know what that
 table is, how it's built, because

0:05:13.260000 --> 0:05:17.820000
 dynamic ARP inspection
 relies on that table.

0:05:17.820000 --> 0:05:20.360000
 So what dynamic ARP inspection
 does is very simple.

0:05:20.360000 --> 0:05:24.760000
 It says, hey, when an ARP comes in,
 whether it's an ARP request or an

0:05:24.760000 --> 0:05:26.580000
 ARP response, it doesn't matter.

0:05:26.580000 --> 0:05:30.260000
 When any kind of an ARP packet hits the
 switch, it says, first, I'm going

0:05:30.260000 --> 0:05:32.940000
 to pause it and I'm
 going to inspect it.

0:05:32.940000 --> 0:05:38.420000
 So it might say, oh, ARP request, it's
 coming from 1111, whose MAC address

0:05:38.420000 --> 0:05:41.720000
 AA, and it just came
 in on port 0 slash 1.

0:05:41.720000 --> 0:05:43.720000
 Hmm, is that legitimate?

0:05:43.720000 --> 0:05:49.000000
 So it will go into the DHCP snooping
 binding table and verify if 1111

0:05:49.000000 --> 0:05:55.220000
 with MAC address AA actually truly
 lives on port 0 slash 1.

0:05:55.220000 --> 0:05:59.360000
 If dynamic ARP inspection is able to
 validate that in the DHCP snooping

0:05:59.360000 --> 0:06:03.020000
 binding database, then we'll
 let the ARP pass on through.

0:06:03.020000 --> 0:06:07.300000
 And the exact same thing will happen
 in reverse when the ARP reply comes

0:06:07.300000 --> 0:06:10.660000
 back. We'll pause it, inspect
 it against the database.

0:06:10.660000 --> 0:06:14.020000
 Now, if it's not in there, or if it's
 in there, but there's something

0:06:14.020000 --> 0:06:19.220000
 wrong, like what if the ARP request
 came in from 1111 on port 0 slash

0:06:19.220000 --> 0:06:24.620000
 1, but the DHCP snooping binding table
 says, well, yeah, we know about

0:06:24.620000 --> 0:06:29.360000
 1111, but when he did his DHCP transaction,
 last time we heard from him,

0:06:29.360000 --> 0:06:31.560000
 he was on port 0 slash 5.

0:06:31.560000 --> 0:06:35.260000
 Well, now dynamic ARP inspection will
 say, I can't trust the source of

0:06:35.260000 --> 0:06:35.980000
 that ARP request.

0:06:35.980000 --> 0:06:37.140000
 I can't validate it.

0:06:37.140000 --> 0:06:41.180000
 As you can see here, if there's no
 match, we will drop the ARP and log

0:06:41.180000 --> 0:06:45.960000
 a message. Now, you might also be
 wondering, well, that's okay.

0:06:45.960000 --> 0:06:50.260000
 So, Keith, you're telling me that dynamic
 ARP inspection is able to validate

0:06:50.260000 --> 0:06:56.800000
 ARPs based on what was previously learned
 with DHCP and DHCP snooping.

0:06:56.800000 --> 0:07:03.740000
 Got it. But what about ARPs coming
 from or going to devices that have

0:07:03.740000 --> 0:07:06.000000
 static IP addresses?

0:07:06.000000 --> 0:07:10.760000
 They never did DHCP, so they're not going
 to be in the DHCP binding database.

0:07:10.760000 --> 0:07:12.360000
 Won't they be dropped?

0:07:12.360000 --> 0:07:15.980000
 Well, yes, by default they would be
 dropped, but there's two ways around

0:07:15.980000 --> 0:07:19.800000
 it. The more complicated way around
 that is to create something called

0:07:19.800000 --> 0:07:24.520000
 an ARP access list, permitting that
 host and that MAC address that has

0:07:24.520000 --> 0:07:29.200000
 a static IP address, and then telling
 the dynamic ARP inspection feature,

0:07:29.200000 --> 0:07:31.640000
 look at this access
 list I've created.

0:07:31.640000 --> 0:07:36.000000
 A simpler way would be to go to the interface
 where that host is connected,

0:07:36.000000 --> 0:07:40.420000
 like that router with a static IP address
 or that server with a static

0:07:40.420000 --> 0:07:44.080000
 IP address and configure that
 port as a trusted port.

0:07:44.080000 --> 0:07:46.180000
 What do you mean a trusted port?

0:07:46.180000 --> 0:07:50.420000
 Well, that gets us into dynamic
 ARP inspection terminology.

0:07:50.420000 --> 0:07:55.160000
 So, when you turn on dynamic ARP inspection
 for a VLAN, by default, all

0:07:55.160000 --> 0:07:59.160000
 the interfaces in that VLAN
 become untrusted interfaces.

0:07:59.160000 --> 0:08:05.480000
 So, what this means is that if an ARP
 request or an ARP reply is received

0:08:05.480000 --> 0:08:10.640000
 on an untrusted interface, we are not
 going to let it pass unless we can

0:08:10.640000 --> 0:08:14.660000
 validate it, unless we can go into the
 DHCP snooping binary database and

0:08:14.660000 --> 0:08:18.780000
 validate that that came
 from the correct person.

0:08:18.780000 --> 0:08:23.040000
 Now, for those situations where that
 ARP request or reply is coming from

0:08:23.040000 --> 0:08:27.120000
 a device with a static IP address, like
 that router we see there on the

0:08:27.120000 --> 0:08:31.120000
 right, the default gateway, we don't want
 to leave his port as an untrusted

0:08:31.120000 --> 0:08:34.660000
 port because there will be no way to
 validate him unless we take the extra

0:08:34.660000 --> 0:08:39.380000
 steps of creating an ARP access list,
 which in this case, you wouldn't

0:08:39.380000 --> 0:08:40.120000
 need to do that.

0:08:40.120000 --> 0:08:43.240000
 So, then we're going to want to go to
 that interface port 3 in this case

0:08:43.240000 --> 0:08:48.460000
 and manually configure that as a dynamic
 ARP inspection trusted port.

0:08:48.460000 --> 0:08:52.880000
 And just like it sounds, an ARP request
 or an ARP reply being received

0:08:52.880000 --> 0:08:55.780000
 on a trusted port
 is not validated.

0:08:55.780000 --> 0:08:59.160000
 We just trust it and we let
 it through the switch.

0:08:59.160000 --> 0:09:02.640000
 And here we can see how dynamic ARP
 inspection works hand in hand with

0:09:02.640000 --> 0:09:06.880000
 a DHCP snooping binding database to
 validate everything all the ARPs it

0:09:06.880000 --> 0:09:09.460000
 receives on untrusted interfaces.

0:09:09.460000 --> 0:09:13.220000
 So, it's pretty simple
 in its operation.

0:09:13.220000 --> 0:09:16.680000
 Thank you for watching this video on
 the theory of dynamic ARP inspection.