WEBVTT

00:04.069 --> 00:07.380
>> Here are a couple of
extra security measures

00:07.380 --> 00:09.375
that we can take
with our switches.

00:09.375 --> 00:12.630
The first one is called
a DHCP snooping,

00:12.630 --> 00:14.010
and this is a
feature that you can

00:14.010 --> 00:15.930
turn on on some switches.

00:15.930 --> 00:17.520
It's based on the idea that

00:17.520 --> 00:20.715
the DHCP protocol is
inherently insecure.

00:20.715 --> 00:22.590
There really is no server of

00:22.590 --> 00:24.600
authentication to
make sure that the IP

00:24.600 --> 00:26.430
addresses being assigned are

00:26.430 --> 00:28.680
from a legitimate DHCP server.

00:28.680 --> 00:30.825
Just like so many
of our protocols,

00:30.825 --> 00:33.170
DHCP was designed for function,

00:33.170 --> 00:34.810
but not secure function.

00:34.810 --> 00:37.580
So we can add on security at
the switch level and have

00:37.580 --> 00:40.550
the switch analyze the
network for DHCP requests,

00:40.550 --> 00:42.980
specifically, DHCP offers.

00:42.980 --> 00:44.990
Hopefully narrow down
the offers that come

00:44.990 --> 00:47.590
from unauthorized DHCP servers.

00:47.590 --> 00:49.495
We've also got flood guards,

00:49.495 --> 00:51.740
and our switches can
look for specific types

00:51.740 --> 00:53.990
of traffic that are in
excess of what's normal.

00:53.990 --> 00:56.000
We talked a lot about denial of

00:56.000 --> 00:58.400
service attacks or ping floods.

00:58.400 --> 01:00.880
On switches, you
can unmark floods.

01:00.880 --> 01:02.880
There are all sorts of floods;

01:02.880 --> 01:06.820
UDP floods, TCP
floods, SYN floods.

01:06.820 --> 01:08.600
So ultimately, looking for

01:08.600 --> 01:10.100
an inordinate amount of traffic,

01:10.100 --> 01:12.140
a specific type would be

01:12.140 --> 01:15.070
what a flood guard is
going to do for you.

01:15.070 --> 01:19.365
Then x2; root guard
and BPDU guard.

01:19.365 --> 01:21.960
Both have to do with
Spanning Tree Protocol.

01:21.960 --> 01:25.010
We talked about Spanning
Tree Protocol briefly,

01:25.010 --> 01:27.350
but the whole idea is
that Spanning Tree is

01:27.350 --> 01:30.050
designed to mitigate the
problems switching loops.

01:30.050 --> 01:31.520
What Spanning Tree does,

01:31.520 --> 01:33.140
is it creates a
logical structure of

01:33.140 --> 01:34.460
an inverted tree where

01:34.460 --> 01:37.310
the root switch is the
basis of the inverted tree.

01:37.310 --> 01:39.575
It's the root, and all
the other switches

01:39.575 --> 01:42.005
ultimately connect through
a pathway up to the root,

01:42.005 --> 01:44.710
and then any other redundant
links are disabled.

01:44.710 --> 01:47.930
Ultimately, everything is
coming up through the root.

01:47.930 --> 01:50.330
We want to make sure that
our particular route switch

01:50.330 --> 01:51.740
is one that is capable of

01:51.740 --> 01:53.450
handling a solid
amount of switching

01:53.450 --> 01:56.555
traffic because it's
going to be very busy.

01:56.555 --> 01:58.610
We also want to make
sure that it is

01:58.610 --> 02:00.290
guarded and that we don't have

02:00.290 --> 02:01.790
the capability of another switch

02:01.790 --> 02:03.785
modifying or
impersonating the root.

02:03.785 --> 02:06.415
That's where the root
guard feature comes in.

02:06.415 --> 02:08.965
Then we have BPDU guard,

02:08.965 --> 02:11.455
which stands for Bridge
Protocol Data Unit,

02:11.455 --> 02:13.310
and this is communication
that should

02:13.310 --> 02:15.320
only go across trunking ports.

02:15.320 --> 02:16.970
When one switch is connecting to

02:16.970 --> 02:19.925
another switch or is
connecting to a router,

02:19.925 --> 02:22.820
we have access ports
and trunking ports.

02:22.820 --> 02:24.575
Trunking is switch to switch.

02:24.575 --> 02:28.130
Access ports are where your
client devices plug in.

02:28.130 --> 02:29.660
We want to make sure
that we don't have

02:29.660 --> 02:32.840
BPDUs coming in on
client or access ports

02:32.840 --> 02:34.130
because that would indicate

02:34.130 --> 02:36.830
some reconfiguring on our
network environments.

02:36.830 --> 02:41.120
So we turn BPDU Guard on
with our access ports.

02:41.120 --> 02:43.415
Also, with port security,

02:43.415 --> 02:46.460
we can set configuration
options like only allowing

02:46.460 --> 02:48.320
certain MAC addresses or

02:48.320 --> 02:49.880
a certain number
of MAC addresses

02:49.880 --> 02:51.635
to connect to a certain port.

02:51.635 --> 02:53.750
That's not really
high-end security

02:53.750 --> 02:54.950
>> because MAC addresses

02:54.950 --> 02:58.025
>> can be spoofed just like
most addresses however.

02:58.025 --> 03:00.580
It does give us one
more layer of defense.

03:00.580 --> 03:01.950
Our key takeaways;

03:01.950 --> 03:04.370
we spent this chapter
looking at switches more

03:04.370 --> 03:07.280
deeply and we talked about
the ways switches operate,

03:07.280 --> 03:10.295
as well as some of the security
concerns with switches.

03:10.295 --> 03:12.290
We continue to focus
on the fact that

03:12.290 --> 03:14.540
switches use MAC
addresses and we

03:14.540 --> 03:16.310
have to make sure that
the table in which they

03:16.310 --> 03:18.635
store those MAC
addresses is protected.

03:18.635 --> 03:21.170
Remember, that table
is called the CAM

03:21.170 --> 03:22.670
table and we're concerned

03:22.670 --> 03:24.714
>> with things
like MAC flooding.

03:24.714 --> 03:27.430
>> Another concern with
switches is switching loops

03:27.430 --> 03:30.095
that lead to what are referred
to as broadcast storms,

03:30.095 --> 03:32.600
and that's when all data
is going out all ports on

03:32.600 --> 03:33.980
a switch because it's gotten

03:33.980 --> 03:36.530
confused as to where
specific hosts are.

03:36.530 --> 03:39.240
When a switch doesn't know
where to send traffic,

03:39.240 --> 03:41.120
it goes back to
an operating like

03:41.120 --> 03:44.695
a hub and all data goes out
all ports all the time.

03:44.695 --> 03:47.310
That can be caused by MAC flood.

03:47.310 --> 03:49.370
But we can also see
that as a result of

03:49.370 --> 03:50.810
redundant links that are set up

03:50.810 --> 03:52.745
to have additional
fault tolerance.

03:52.745 --> 03:54.590
But if they're not
configured properly

03:54.590 --> 03:55.790
with the Spanning Tree,

03:55.790 --> 03:57.485
it can cause a lot of confusing,

03:57.485 --> 03:59.585
making Spanning
Tree very helpful.

03:59.585 --> 04:01.430
We also talked about needing to

04:01.430 --> 04:03.455
monitor security
through our switches.

04:03.455 --> 04:05.780
But because of how
switches operate,

04:05.780 --> 04:08.870
we need to enable port
span or port mirroring on

04:08.870 --> 04:09.890
a specific port on

04:09.890 --> 04:12.745
the switch so that we
can view all traffic.

04:12.745 --> 04:15.635
We also discuss VLAN
tagging a trunking,

04:15.635 --> 04:17.480
which essentially is how
we're going to enable

04:17.480 --> 04:20.390
valence to spend
multiple switches and

04:20.390 --> 04:22.280
can also tag for
layer 2 switches

04:22.280 --> 04:23.120
>> that still want to have

04:23.120 --> 04:27.000
>> VLANs and allow that
inner VLAN communication.