Another type of segment profile we have is the security segment.
And we had to tweak this several skills ago as we were working with DHCP
services,
because by default, if we have an external DHCP server,
that's not part of the NSX environment, and it's feeding in DHCP server
messages,
like offers and acknowledgments, and the client would be doing the discover and
the request.
So there's the door process right there, one, two, three, four.
The default behavior with the default security segment says,
"You know what? Any server messages which would include offers and acknowled WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"You know what? Any server messages which would include offers and acknowled
gments
based on the ports involved for DHCP servers, those are going to be blocked if
they're trying
to come into the network from a VM. Does that be a VM here or here or here or
here?
Anywhere. Because of the default security segment, security profile,
that's denying any DHCP server-based messages. And that's a great thing to
prevent accidentally
or intentionally somebody from trying to inject or pretend to be a rogue DHCP
server
handing out incorrect information." So as we take a look at the options
involved in a security segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
involved in a security segment,
one of them is to protect against erroneous DHCP server type messages coming in
.
We can also filter based on STP messages, specifically BPDU filtering,
because at the end of the day, most of our VMs down here have absolutely no
need to see any
BPDUs as a result of spanning tree trying to not have a loop. We also have, as
part of our security
segment profiles, the options of doing RA Guard. And RA Guard is a really
important feature because
if we're using IP version 6 and we have some VMs down here, we don't want these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we're using IP version 6 and we have some VMs down here, we don't want these
VMs advertising
as a router would router advertisements. Because just like we don't want this
VM to pretend it's
a DHCP server and mess up our networking, we also don't want this VM to offer
router advertisements
to again influence our network from an IPv6 perspective regarding having a
router available,
especially if it's this VM, which is not the correct router for the segment.
So for this demonstration of using a security segment segment profile,
let's go ahead and use this segment right here. And we'll use a Kali Linux box. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's go ahead and use this segment right here. And we'll use a Kali Linux box.
We'll use Kali 10.
Let's also use a Mint Linux box right here, and that'll be Mint 10.
And to demonstrate the benefit of this, I'd like to first of all create a
security segment profile
that will allow DHCP server messages to come in from the segment and from the V
Ms on that segment.
Then we can demonstrate how an attacker could very easily advertise and act as
a rogue DHCP
server for other devices on the network segment. And then once we verify that
we'll change it up
by applying a security segment that's denying DHCP server messages coming in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by applying a security segment that's denying DHCP server messages coming in
from any VMs here.
And at that point, with them being filtered here and not being allowed in, this
Kali Linux box won't
be able to pretend or influence the network or become a rogue DHCP server that
clients are
getting IP addresses from. So here on the vSphere client, let's make sure both
those VMs are on the
right segment. We'll right click on Kali 10. We'll click on edit settings and
go down to its network
card. And it's on segment 10, non-VRF. That's fantastic. And then we'll take a
look at Mint 10.
And this shows us that it's on segment 10 for green. Let's go ahead and change WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this shows us that it's on segment 10 for green. Let's go ahead and change
that by right
clicking on Mint 10, clicking on edit settings. And we'll put that on the right
segment along with
the Kali Linux box. So for networked after we'll click on browse, and let's put
on segment 10,
non-VRF, and click on OK. All right, that looks good. We'll click on OK. And
let me power on
Kali 10 right now. And then we'll power on Mint 10 here in a moment. Next, let
's head over to the
NSX manager. And let's create a security segment profile that's permitting DHCP
server traffic.
So here in the NSX manager, we'll click on the networking tab. On the left, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here in the NSX manager, we'll click on the networking tab. On the left, we
'll click on segments
under connectivity. And then let's go ahead under the sub tab of profiles right
here. And let's
create our own security segment profile. So with profile selected here and
segment profile selected
down below, let's click on add segment profile. And we want a segment security
segment profile.
So we'll select that. And let's call it our sec, sec profile. And then in this
profile, let's go
ahead and not disable DHCP server messages. Let's not disable any BPDUs. And we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ahead and not disable DHCP server messages. Let's not disable any BPDUs. And we
're not using IPV6.
So our a guard being enabled won't matter at all. So effectively, for our
purposes, I wanted to
make sure that in our security profile, we are allowing DHCP server messages,
which by default,
in the default profile, that is not allowed. And again, that's a good thing in
a production
environment, because we don't want rogue VMs pretending to be DHCP servers. But
for the demo,
I'd like to make sure initially that we're not blocking that with the segment
profile. So we'll
click on save. And now the segment profile saved, let's apply it to our segment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
click on save. And now the segment profile saved, let's apply it to our segment
10. So still here
under the networking tab with segment selected, we'll click on the sub tab of
NSX under segments.
And let's go to our segment 10 non VRF. We'll edit it by clicking on the three
dots clicking on edit.
And then scrolling down and then expanding segment profiles. And then here for
our security segment,
we'll use the drop down. And we'll choose the security segment profile we just
created and click
on safe. And then we'll go ahead and click on close editing. And just to
confirm here for segment
10, if we click on the link for port slash interfaces, here it's showing us our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10, if we click on the link for port slash interfaces, here it's showing us our
Kali Linux box. And if
we expand that and then expand the segment port profiles, effectively, it's
inheriting our segment
security profile from the segment, which is allowing DHCP server messages to
come in. So we'll click
on close. Let's go back to the topology view. So here on segment 10, let's go
ahead and go to
this Kali Linux box. And let's create a rogue DHCP server. So here is that Kali
Linux box that's
Kali 10. And let's hope put up a command prompt. And from here, they launched a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Kali 10. And let's hope put up a command prompt. And from here, they launched a
tool called
your cinea, which could be a fantastic tool in the wrong hands. Let me go ahead
and do a dash g
for the graphical version. Open is not installed on this distribution of Linux.
Let me go ahead
and take a peek at another VM. Let me see if I have it here on mint 10. And if
I don't have an
install of mint 10, I'll just go ahead and deploy it. And we'll just make mint
10 or attack our
machine here for a moment. And because they're both on the same segment, and
the security segment
profile is permitting DHCP messages. Effectively, we can have either one of
these machines pretend
to be a rogue DHCP server. So here is that mint Linux device. Let's go to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be a rogue DHCP server. So here is that mint Linux device. Let's go to a
command prompt.
And from here, let's type in your cinea press center. And it's not installed.
All right,
let's go ahead and install it real quick. The pseudo apt install your cinea
will say yes to continue.
And I'll just take a moment. All right, so let's go ahead and launch it with
pseudo your cinea. And I'll do dash g for the graphical option. And there it is
. Also,
before we set up this device to pretend to be a DHCP server, I'd like to take a
moment and just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
moment and just
disable the native NSX DHCP services so we can see and verify that this rogue
DHCP server does
indeed work without any competition from the NSX environment. So we'll go back
to the NSX
manager, and we'll go to our segments. And then for the segment 10 here, we'll
click on the three
dots, click on edit. And then over here on the right, we'll say please delete
DHCP config,
click on delete, and then click on save. And we are no longer offering DHCP
services
from NSX on that segment. We'll close editing. And let's head back to this mint WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from NSX on that segment. We'll close editing. And let's head back to this mint
10 VM where we
just installed your cinea. And we'll make it a DHCP server. So let me make that
a little bit
bigger. So if you click here on DHCP and then click launch attack, we can
specify here, we want
to create a DHCP rogue server, we'll click on OK, and we'll put the information
regarding it.
So for the server ID, I'm going to pick something on the 10 subnet, like 10 dot
10 dot zero dot.
Let's imagine that this VM is at 254 that that's its IP address. So we'll make
that the server
ID and then we'll hand out the IP addresses in the range 10 dot 10 dot zero dot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ID and then we'll hand out the IP addresses in the range 10 dot 10 dot zero dot
201 all the way
through 10 dot 10 dot zero dot 205. And that way we see those IP addresses come
up on a client,
we'll know where they came from. And then we'll set the lease for, I say 1000
seconds and that
they need to renew in 500 seconds and then the mask is a 24 bit mask. So we'll
put that in as well.
And then for the default gateway. So let's imagine this hacker machine is
really at 10 10 zero 254.
We can hand that out as the default gateway for the clients to use 10 dot 10
dot zero dot
D54. And that way when they try to use their default gateway, they're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
D54. And that way when they try to use their default gateway, they're going to
be handing that
data directly to the attacker machine at which point they could analyze it and
then forward it
along its way. And then for the DNS server, let's also put 10 dot 10 dot zero
dot 254,
which once again is the attacker machines, we could lie about DNS information.
And then for
the domain, we could call this OGIT dot com or whatever domain we want to
specify and then
click on OK. Now before I click on OK here, in the background, I have some
requests for
DHCP renewals that I'm seeing. And that's coming from whoever got the IP
address previously of 183. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address previously of 183.
So here's what I propose we do. Let's go ahead and click on OK here to enable
this
service. Let's go back to full screen. And let's go back to the vSphere client
and let's bring up
another client that we can bring up on that same subnet. So here's a VM and it
is not on the right
subnet. So maybe right click and click on edit settings. And let's put it also
on that same segment,
which is the seg 10 non VRF. Click on OK, click on OK, and then we'll go ahead
and power it up.
So we'll click on power power on. And as it powers up, let's head back over to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on power power on. And as it powers up, let's head back over to
our mint Linux and
take a look. So now with this rogue DHCP server in place, let's verify whether
or not the client
got an IP address from the range that was being handed out by our little rogue
DHCP server here.
So to do that, let's go to our VM, even a machine right here will launch remote
console. And that
did not get an IP address. Oh, I see it timed out on me. I didn't get there
quite fast. Let's do it
one more time. I'll click on launch attack DHCP, create a rogue DHCP server.
And I'll go ahead and
fill in the details again. All right, so I've supplied all that information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fill in the details again. All right, so I've supplied all that information
again. Let me
also bring in our client and I'll go ahead and have it reboot. And while it reb
oots, let me go
ahead and launch this attack to become the rogue DHCP server. And then we can
verify whether or
not that client actually gets an IP address from this rogue DHCP server. So
there we go. So there's
the discover that came from the client. There's the offer that we sent. And
then the client did a
request and there's the acknowledgement. So we go back to that client. And here
if we do an IF
config and press enter, we can confirm the IP address it got which is 10 10 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
config and press enter, we can confirm the IP address it got which is 10 10
zero two zero one.
And if we do a route and press enter, it's also showing the default gateway
that is being used.
So this information about the IP address, the default gateway, the DNS server
was all handed out
from our rogue DHCP server. Now we don't want that to be able to happen on our
network. So that's
why as part of the default security segment profile, it is blocking DHCP server
messages
from VMs connected to that segment by default. And that way only authorized
DHCP servers can
actually hand out IP addressing information to the VMs. So back in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually hand out IP addressing information to the VMs. So back in the
configuration for our
segment, again, this is segment seg 10 non VRF, I'm going to go ahead and set
these segment security
profile back to the default. And if we click on the three dots, we can confirm
the settings by
clicking on view. So in the default, we're filtering BP to use from going to
our VMs,
we're blocking DHCP server messages. And as a result, once we click on save
here,
that same attack that was trying to be initiated by that VM on segment 10,
that would no longer be successful. Because based on the segment security WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that would no longer be successful. Because based on the segment security
profile,
it is not allowing the DHCP messages coming in from servers into the network.
So the DHCP server
side protocol would be UDP port number 67. And on the client, the client would
be using UDP port
68. So based on the default segment security profile, not allowing DHCP server
messages,
that's one of the methods it's using to identify that that's DHCP server
traffic. And as result
of the segment security profile, it's dropping it and not allowing that attack
to succeed.
Also before I forget, I want to modify my DHCP services for the segment. So we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also before I forget, I want to modify my DHCP services for the segment. So we
really are
handing out IP addresses from NSX once again. So I'll click on the three dots
click on edit,
and then click on set DHCP config. We'll use gateway based DHCP services. And
then the range,
I'm going to use 10.10.0.151 through 10.10.0.200 with a lease. Let's put 1,000
seconds there.
And a DNS server of eight, eight, eight, eight, eight, click on apply, and then
click on save.
And now that we have DHCP services set up for that segment, once again, I'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now that we have DHCP services set up for that segment, once again, I'll
click here on
close editing. Let's bring back our little client. So here's our little client.
And currently,
we have an IP address and default route that we learned via the rogue DHCP
server. So I'm going
to go ahead and reboot this little VM. And so it'll go back to the Dora process
once more. But
this time it'll get correct information from the real NSX DHCP services. And
for that VM that was
doing the rogue DHCP services function, if it tried it again, it would be
blocked based on our
security segment profile. So now if we type in I have config and press enter,
now we're showing
an IP address of 10.10.0151. If we type in route, it'll show us our default WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an IP address of 10.10.0151. If we type in route, it'll show us our default
gateway is 10.10.01.
And if we tried to ping something on the internet based on name and press enter
,
that should also work once again.
[BLANK_AUDIO]