|
0:00:13
|
In our next section for Layer 2 security, we're going to
|
|
0:00:16
|
talk about the DHCP snooping, dynamic ARP inspection and
|
|
0:00:21
|
IP source guard features that are designed to
|
|
0:00:23
|
prevent against Layer 2 spoofing attacks on the LAN.
|
|
0:00:29
|
Now the potential issue that we could run into on the
|
|
0:00:32
|
access segment that is going down to the end hosts
|
|
0:00:35
|
is that the IP version 4 ARP protocol
|
|
0:00:38
|
and the BOOTP server and client which is going to be used
|
|
0:00:43
|
for DHCP has no protection mechanisms built into the
|
|
0:00:46
|
protocol itself to validate if the sender of either the
|
|
0:00:52
|
DHCP offer or the ARP response is actually
|
|
0:00:56
|
the legitimate user.
|
|
0:00:59
|
And the attack that could be implemented in the Layer 2
|
|
0:01:03
|
LAN is typically known as a Layer 2 man in the middle attack
|
|
0:01:07
|
or an MIM attack.
|
|
0:01:11
|
Now the way that this works is that on the LAN we have
|
|
0:01:17
|
a victim host that's the legitimate user
|
|
0:01:21
|
and we have the attacker
|
|
0:01:23
|
that are on the same Layer 2 segment.
|
|
0:01:27
|
Now typically this segment is then going to attach to
|
|
0:01:29
|
a router
|
|
0:01:31
|
which somehow is going to connect to the DHCP server.
|
|
0:01:37
|
What is supposed to happen is that when
|
|
0:01:39
|
the host sends the DHCP request
|
|
0:01:48
|
the router's going to forward this to the server
|
|
0:01:50
|
the server is going to reply back with the DHCP offer.
|
|
0:01:56
|
And this is going to contain whatever the pool information
|
|
0:02:00
|
is for the particular segment the IP address, the default gateway,
|
|
0:02:04
|
the DNS server etc.
|
|
0:02:08
|
Now once the DHCP request goes out onto the LAN
|
|
0:02:11
|
there's nothing preventing someone else from sending
|
|
0:02:15
|
a DHCP offer which potentially could have a legitimate pool
|
|
0:02:21
|
address, so it's the correct subnet that is for that link
|
|
0:02:25
|
but it would change the default gateway from the router's
|
|
0:02:30
|
address to the attacker.
|
|
0:02:41
|
Now when this occurs, the final result is that the victim is
|
|
0:02:45
|
going to say that my default gateway for this particular
|
|
0:02:48
|
segment is going this way as opposed to the
|
|
0:02:52
|
the legitimate path which is supposed to go to the router.
|
|
0:02:56
|
But once the attacker receives the traffic in, it's going to transparently
|
|
0:03:01
|
forward it onto the router, so the traffic does actually forward
|
|
0:03:05
|
out to the rest of the network correctly and it's transparent
|
|
0:03:10
|
to the victim.
|
|
0:03:12
|
So this is why it's considered a man in the middle attack
|
|
0:03:15
|
because essentially the attacker is running some sort of packet
|
|
0:03:18
|
analyzer or some sort of sniffer in order to grab the
|
|
0:03:21
|
traffic off of the wire, but it still eventually gets to the
|
|
0:03:25
|
destination so the victim doesn't know that there's a problem
|
|
0:03:28
|
to begin with.
|
|
0:03:30
|
Now there's a couple of different ways that this can be implemented.
|
|
0:03:33
|
One way would be to configure a rouge DHCP server or basically
|
|
0:03:38
|
a wrong DHCP server onto the LAN where the attacker
|
|
0:03:42
|
is sending out leases instead of what the DHCP
|
|
0:03:45
|
server is supposed to do.
|
|
0:03:48
|
So the switches that are in the Layer 2 network
|
|
0:03:52
|
they then need to protect against this case. To make sure
|
|
0:03:54
|
that when the DHCP request comes in that the DHCP
|
|
0:04:00
|
offer is coming in the correct Layer 2 port.
|
|
0:04:03
|
And this is what the DHCP snooping feature is
|
|
0:04:06
|
designed to do.
|
|
0:04:09
|
So with DHCP snooping, the switch is going to know
|
|
0:04:12
|
where the DHCP server is supposed to be located
|
|
0:04:16
|
and where the DHCP clients are located.
|
|
0:04:20
|
The link that is connecting to the server where it's directly --
|
|
0:04:22
|
whether it is directly attached or whether
|
|
0:04:25
|
it's through a Layer 2 trunk link, this is going to be
|
|
0:04:28
|
the interface that is trusted.
|
|
0:04:32
|
So the only thing we need to configure for the feature
|
|
0:04:35
|
is just to enable it globally and then on the link that is
|
|
0:04:39
|
pointing towards the server this should be the trusted interface.
|
|
0:04:44
|
So the end result of this is that when the DHCP
|
|
0:04:49
|
offer comes in, it's only going to be coming from the interface that is
|
|
0:04:55
|
trusted, so in this case if the attacker sends
|
|
0:04:58
|
the offer, the Layer 2 switch that receives this in
|
|
0:05:04
|
it's going to block this response because it
|
|
0:05:08
|
says that this is my trusted port going this way
|
|
0:05:11
|
as opposed to the other interfaces which are actually facing downstream.
|
|
0:05:18
|
Now once the switch knows where the DHCP is located
|
|
0:05:22
|
and where the client's requests are coming in
|
|
0:05:24
|
from, it's going to build a mapping table that is
|
|
0:05:29
|
constructed of the IP address that was allocated
|
|
0:05:33
|
the Mac address of the client and the port that it is associated with.
|
|
0:05:39
|
So this is known as the DHCP snooping binding database.
|
|
0:05:44
|
It's similar to the ARP cache on the router
|
|
0:05:47
|
where we're binding an IP address to a Mac address.
|
|
0:05:50
|
Now with this information, the switch can then run
|
|
0:05:53
|
two additional features which are known as
|
|
0:05:56
|
the dynamic ARP inspection
|
|
0:06:00
|
and the IP source guard feature
|
|
0:06:02
|
which are to actually filter Layer 3 packets
|
|
0:06:07
|
as they're received in the interfaces or Layer 3
|
|
0:06:10
|
ARP packets.
|
|
0:06:13
|
So the other potential spoofing problem
|
|
0:06:16
|
is that on this LAN segment we can prevent against the
|
|
0:06:19
|
DHCP request coming in or the DHCP response coming
|
|
0:06:23
|
in the wrong interface, but it doesn't necessarily protect
|
|
0:06:27
|
against the case where the attacker basically says
|
|
0:06:32
|
that the Mac address of the router, so let's say the
|
|
0:06:36
|
Mac address A maps to the IP address 1
|
|
0:06:43
|
If the attacker sends an ARP reply
|
|
0:06:48
|
which is known as a gratuitous ARP, so it's
|
|
0:06:50
|
an ARP reply without an ARP request coming in
|
|
0:06:53
|
that says IP address 1 is bound to Mac address
|
|
0:06:58
|
B which is the one that's assigned on the attacker's interface.
|
|
0:07:04
|
It then again means transparently the Layer 2 is going to go from the
|
|
0:07:08
|
victim to the attacker, the attacker to the router and
|
|
0:07:11
|
then out, so even though the attack is not against the DHCP server
|
|
0:07:17
|
in this case, we're using the ARP protocol, we end up in the
|
|
0:07:21
|
same result. There's a man in the middle attack going
|
|
0:07:25
|
through the attacking host.
|
|
0:07:29
|
Now to prevent against this, the switch can take
|
|
0:07:33
|
that DHCP snooping database that was built based on the
|
|
0:07:37
|
requests and the offer and use this to inspect
|
|
0:07:42
|
the ARP packets.
|
|
0:07:46
|
So based on the mappings that were created in that binding table
|
|
0:07:50
|
the switch is already going to know what particular
|
|
0:07:52
|
IP addresses correspond to which particular Mac addresses
|
|
0:07:56
|
and what are the interfaces that they're located on.
|
|
0:08:00
|
So in order to enable this, we only need to say
|
|
0:08:02
|
ip arp inspection and the particular VLAN
|
|
0:08:05
|
then for any interfaces that we do not have
|
|
0:08:08
|
the manual -- or excuse me, that we do not have the automatic
|
|
0:08:11
|
bindings on like the a Layer 2 trunk link that
|
|
0:08:15
|
goes to another switch, that would be the trusted
|
|
0:08:19
|
interface.
|
|
0:08:21
|
Now the problem with this is that it's possible that
|
|
0:08:25
|
DHCP is not going to be used for all allocations
|
|
0:08:29
|
which typically is going to be the case for the router's
|
|
0:08:32
|
address on the segment, so if the router's address is
|
|
0:08:35
|
assigned statically, we need to tell the switch what is the
|
|
0:08:39
|
IP address to Mac address binding for the router.
|
|
0:08:43
|
And this is going to be applied as an ARP access list
|
|
0:08:48
|
that has both the IP address and the Mac address binding.
|
|
0:08:52
|
So in this particular case, if this was VLAN 10
|
|
0:08:58
|
we would create an ARP access list that says Mac address
|
|
0:09:01
|
A is associated with IP address 1
|
|
0:09:05
|
so if a gratuitous ARP or again essentially an ARP
|
|
0:09:09
|
reply comes in from the attacker, the switch is
|
|
0:09:13
|
automatically going to drop that on the interface.
|
|
0:09:16
|
Then lastly, the third feature we can use this for is the
|
|
0:09:18
|
IP source guard which is actual filtering of the data plain packets.
|
|
0:09:25
|
So we're taking the DHCP snooping and the dynamic ARP
|
|
0:09:27
|
inspection logic one step further that says if I already
|
|
0:09:31
|
know what the IP address and the Mac address binding
|
|
0:09:34
|
is supposed to be on a per port basis
|
|
0:09:37
|
I can simply turn on IP source guard, the IP verify
|
|
0:09:41
|
source command that says for every packet I receive inbound
|
|
0:09:46
|
I'm going to check the IP address against the Mac address.
|
|
0:09:49
|
If that matches what is in my DHCP snooping database
|
|
0:09:54
|
then I'm going to allow the packet inbound.
|
|
0:09:57
|
If it doesn't match it, then that is going to be dropped.
|
|
0:10:02
|
So typically these three features you would run
|
|
0:10:04
|
them all in conjunction on the LAN. DHCP snooping,
|
|
0:10:08
|
dynamic ARP inspection and IP source guard.
|
|
0:10:13
|
Now some of the potential issues that you need to be aware
|
|
0:10:15
|
of that with DHCP snooping
|
|
0:10:17
|
you need to make sure that you're trusting whatever
|
|
0:10:20
|
port is connecting to the DHCP server even if it is
|
|
0:10:24
|
a Layer 2 trunk link.
|
|
0:10:27
|
So whatever faces upstream towards the server, those have to be the
|
|
0:10:30
|
trusted interfaces.
|
|
0:10:33
|
Now additionally, when the Layer 2 switch does this
|
|
0:10:36
|
snooping, it's going to add an information option
|
|
0:10:40
|
which is known as DHCP option 82
|
|
0:10:45
|
that some DHCP servers do not support.
|
|
0:10:50
|
So when the actual request gets from the client to the
|
|
0:10:53
|
server, if the server doesn't support this type of formatting
|
|
0:10:56
|
of the packet, they could reject it.
|
|
0:10:59
|
Now if you actually test this on the command line, you'll
|
|
0:11:01
|
see that the IOS DHCP server implementation
|
|
0:11:04
|
does not support this.
|
|
0:11:07
|
So the router is going to reject any of the packets that
|
|
0:11:10
|
went through DHCP snooping.
|
|
0:11:14
|
So there's two ways that you could fix this.
|
|
0:11:17
|
You could either get the server to allow this.
|
|
0:11:20
|
So that's going to be up to the actual application of the
|
|
0:11:23
|
DHCP server or you could tell the switch not to
|
|
0:11:26
|
add the information option.
|
|
0:11:28
|
If we say no ip dhcp snooping information option, it's
|
|
0:11:31
|
not going to insert the option number 82
|
|
0:11:34
|
Now all three of these features if we look at the documentation
|
|
0:11:39
|
under the configuration guide for the switches
|
|
0:11:43
|
these are going to be under configuring DHCP
|
|
0:11:45
|
features and IP source guard and then dynamic
|
|
0:11:48
|
ARP inspection.
|
|
0:11:51
|
So when you look at the configurations for these, there's
|
|
0:11:52
|
really not that much syntax that goes along with it.
|
|
0:11:56
|
It's more to understand what are these designed to prevent
|
|
0:11:59
|
against in the first place which is the Layer 2
|
|
0:12:02
|
spoofing of the DHCP server.
|
|
0:12:05
|
The ARP address poisoning of the default gateway on the
|
|
0:12:09
|
segment or the actual source spoofing that's prevented
|
|
0:12:15
|
against with the IP source guard.
|
|
0:12:18
|
But again, typically all three of these are normally used
|
|
0:12:21
|
in conjunction with each other.
|