I'd like you to think with me how simple it
is for someone to connect to our physical networks.
So for this switch, if we have physical access, we could boom!
Plug into it.
Now hopefully, we've got our physical switches and gear
in locked-up closets that are air conditioned and everything
else.
But it's still pretty easy for a user
to connect because we have RJ45 jacks in their offices,
in their cubes.
And all they do is they plug in.
Now the question I have for us is,
what is connecting to our network?
And that is why we need the feature of port security.
So in this video, I'd like to talk with you about what it is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in this video, I'd like to talk with you about what it is
and why we need it.
I see three major challenges with controlling
who is connecting to a port.
Number one, we just don't know who exactly it is.
I mean, maybe it's Bob today or Sally tomorrow.
Or maybe Bob comes in with another device
that's not his PC.
And he plugs into the jack in his office.
And we've got this thing connected to our network.
So who or what is connected is a problem.
If we're not sure what it, then we can't control it.
Another challenge is that we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Another challenge is that we could
have multiple devices connecting on one port that
are not authorized.
And here's an example.
Bob decides he's going to bring in some more devices to work.
And he wants them in his office.
So he disconnects his PC from the network connection.
And instead, he puts in his own switch,
which are very affordable for a nonmanaged, simple switch.
So he bought it at Fry's or some other store.
He brings in.
He connects his network connection to the switch.
And then from the switch, he connects his PC
and all of his other toys that he's
brought in that he wants physical access to network
with.
So we could have multiple devices all
coming in on this one port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
coming in on this one port.
And that port is gig 0/0 on the switch.
And the third challenge is that there
could be a hacker or somebody malicious who
is connecting to a switch port and trying
to compromise a switch.
And one technique that can be used
is called a CAM table overflow attack, also sometimes referred
to as MAC flooding.
And here's how it works.
Using malicious software or software intended
to harm the switch, the device connected to the switch
sends in thousands and thousands of frames.
But instead of using its real Mac address as the source WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But instead of using its real Mac address as the source
address, it will create a bogus Mac address or a made-up Mac
address for every single one of the frames.
So now, the switch is learning thousands of source Mac
addresses all off gig 0/0.
Now what's the real harm in that?
The real harm is that the switch does not
have unlimited memory to remember all that information.
It uses the CAM table-- the Content Addressable Memory
space to remember Mac addresses.
And if that is totally consumed, the switch
is not going to have the ability to correctly understand WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is not going to have the ability to correctly understand
which Mac addresses belong to which ports.
And so the hacker, if they do this CAM table overflow attack
and then eavesdrop on the network,
their intent is that they want to see every frame
from every device on that VLAN being sent out
their specific port where they can now listen
to all the traffic on the VLAN.
It's also possible that the performance on the switch
is going to be compromised, which
could also act as a denial of service
attack against the switch.
And just for fun, let me demonstrate
how easy it is to do that type of an attack--
a CAM table overflow attack against the switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a CAM table overflow attack against the switch.
So here at the access layer switch,
let's do a few commands just to verify that gig 0/0 really
is associated with VLAN 10.
So we'll do a show vlan brief.
That'll do it for us.
And there's VLAN 10.
And VLAN 10 currently has gig 0/0 assigned to it.
Fantastic.
Also, if we want to take a look at the Mac address table,
we do a show mac address table.
And then we can filter down even further by specifying VLAN 10.
Press Enter.
And there's all the Mac addresses
it's learned-- the switch has learned that are associated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's learned-- the switch has learned that are associated
with VLAN 10.
And we can even do one step further.
We can go ahead and do a show mac
address-tablespace and interface gig 0/0 space vlan 10.
And that will narrow it down to the VLAN 10 Mac addresses
that it's learned that are associated
with that specific interface.
So at the moment, there's just two of them.
Now I have another host that is connected off of gig 0/0.
And it happens to be a Kali Linux box.
So if I log on as the user root with the password toor-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I log on as the user root with the password toor--
T-O-O-R, which is root backwards,
and then in Kali Linux, we'll pull up a terminal.
And from here, if we do an ifconfig just
to verify our information, so our IP address is 10.16.0.99.
And our Mac address is ending in fe, four 7's, a 0, and a 1.
So that also should show up as a dynamically-learned layer
2 address on VLAN 10.
Let's go take a look.
So back at the CLI, we'll do an up arrow key, press Enter.
Eh, it's not there.
Well, let's go tell the Kali Linux
box to generate some traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
box to generate some traffic.
So back at Kali, let's generate some traffic.
We'll do a ping to 10.16.0.1, just the VLAN 10 interface
on core 1.
We should get a response there.
Great.
Now do a Control-C to stop that ping.
Let's go back to the CLI.
I just want to verify that we are on the right port.
And we'll do a show mac address table for interface gig 0/0
at vlan 10.
Press Enter.
And sure enough.
There it is.
So the Kali Linux box was being very quiet
in the background until it generated some traffic.
So at this command right here, we have three Mac addresses
that this switch has learned off gig 0/0 that are all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that this switch has learned off gig 0/0 that are all
associated with VLAN 10.
However, if we use a little utility like macof,
which is built in this part of the toolset on Kali Linux,
we can use M-A-C-O-F space.
And then we can go ahead and do a dash i, specifying, hey,
on which interface do we want to use?
And we want to use Ethernet 0 space.
And then just to be kind, I'm not going to let this run
and go [RASPBERRY SOUND],, millions
and millions of packets.
I'm going to go ahead and do a dash n
and just going to do like 50.
Now this is going to spit out 50 frames, all of which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now this is going to spit out 50 frames, all of which
are going to have a made up source
Mac address as we start to fill up the CAM table.
And it happens really fast.
And in this virtualized environment,
this Kali Linux box is pumping them out
faster than the actual switch can actually learn them
because it's also virtualized.
So I'll do that a few times.
And then let's go take a look at the CAM table.
So a moment ago, we had three Mac addresses
that were associated with VLAN 10 on port gig 0/0.
If we hit the up arrow key now and do that same exact command WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we hit the up arrow key now and do that same exact command
again, here we go.
There's page one.
There's page two.
There's page three, et cetera.
And if we want to do a show mac address table,
and we'll do a count for VLAN 10, press Enter.
That's going to get us a summary.
So we have 113 Mac addresses.
And that's because I only did that command a few times.
But a real attacker would just let
it run and try to compromise the switch by doing a CAM table
overflow attack.
So now the question is, how do we protect ourselves WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now the question is, how do we protect ourselves
against those three things--
number one, not knowing exactly which device is connecting;
number two, having multiple devices
connecting on a single port; and three,
having somebody that tries to do a CAM table overflow
attack against us on the switch?
And the answer is a feature called port security.
And in the next video, we'll take a look
at how this feature called port security protects us
against those scenarios.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.