So we did our verification, we integrated Active Directory,
we enabled the DFW and Gateway Firewalls for identity services,
and we also created our NSX group that is linked back to our Active Directory
group.
We also verified that when we looked at that group,
it showed the effective member as this little Windows client machine right here
.
So our next step is to go ahead and take that NSX group,
which is using the Active Directory group,
and then use it in a firewall policy rule.
So for the demonstration, here's what I propose we do.
Let's go ahead and modify our distributed firewall policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's go ahead and modify our distributed firewall policy.
Let's specify that we want to go ahead and first of all,
deny SSH for everyone,
and then we can test that as well,
and then we'll come back in and create another rule above it,
permitting SSH if the source is coming from a member of that NSX group,
which is linked back to the Active Directory group.
Also as a test here, let's also bring in a computer over here.
I've got a computer called Mint.
20 right here.
So at the moment, both this client right here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at the moment, both this client right here,
the Windows client and also this Linux client,
they should both be able to do an SSH session up here to the 23.1.2.1 address,
which is our little external router.
So before we implement our security policy rules and levers the group,
let's verify first that we have full SSH connectivity from both these VMs
up to the router interface at 23.1.2.1.
So to do that, let me make sure all those VMs are running.
We'll go to the VM and templates view.
So Mint 20 is running.
I just want to confirm where it's at.
So it's over on segment 20. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's over on segment 20.
Fantastic.
And our Windows 11 client is running and it's on segment 10.
Let's bring up remote consoles for both of those.
So we'll go to Mint 20 and go to summary tab here and click on launch remote
console.
So here on the Mint 20 device on segment 20, let's bring up a command prompt.
And let's do a ping first just to verify connectivity to 23.1.2.1.
And that is great.
And we'll do a control C and let's do an SSH dash L to log in as VYOS.
That's the username up at 23.1.2.1 press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's the username up at 23.1.2.1 press enter.
And that's work in.
We'll say yes to accept.
And then we'll put in the password and we are in.
So if we do a who, that shows us who are currently connected as so we're going
through
that and we appear like we're coming from 23.1.2.60.
And our address here is a fudun.io config.
Our address here is 10.20.0.153.
All right. So SSH works from the Mint 20 VM over on segment 20.
And let's also verify that SSH works from our Windows client, which is over on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's also verify that SSH works from our Windows client, which is over on
segment 10.
So let's bring up a command prompt on our Windows computer.
There it is.
And let's do a ping to 23.1.2.1.
And that looks great.
Let's also do an SSH to that same IP address with SSH space dash L for log in
as VYOS.
And then the IP address of that router, which is 23.1.2.1. And that looks good.
We'll say yes and log in with the password.
And that looks good.
We'll type in who and we are also being netted to that IP address right there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll type in who and we are also being netted to that IP address right there.
So if we logged on over here as well and we did that same thing and then we did
a who,
we're going to have two people logged in.
One of them is the Windows computer and the other is the Linux fantastic.
So we'll type in exit and we'll exit out of the SSH session for both of them.
All right. So now back in the NSX manager, which we'll go to right now,
let's create a new security policy rule to deny all SSH traffic if it's going
to that external router.
So to do that, let's go ahead and use the distributed firewall to implement
that.
And let's add a new policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's add a new policy.
And let me go ahead and collapse the left hand side.
And let's call this new policy, our SSH policy.
And then I'll make this column a little bit bigger here.
Fantastic.
And for this policy, let's create a new rule and let's deny SSH for everyone.
So we'll say the source is going to be from anywhere,
but for the destination, we'll deny all SSH to that specific IP address
of our external router, which is at 23.1.2.1 and press enter and click on apply
.
All right. So that's the destination. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right. So that's the destination.
And for the services, let's go ahead and specify just TCP port 22.
So we'll type in SSH. They've already got that identified force.
So in the services column here, SSH, we're really talking about traffic
matching at layer four,
the protocol TCP going to the well known port of 22 and we'll click on apply.
And then we could also furthermore implement a context profile to make sure it
's really the
SSH application. But for our demo, this will work just fine with just looking
at the layer four port
and protocol in use. And then for the action, we'll go ahead and use the drop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and protocol in use. And then for the action, we'll go ahead and use the drop
down, say reject,
and then we'll click on publish. All right. So that is done. We'll click right
here,
where it says in progress, we'll click on the refresh. And that looks great.
So at this very moment, if this VM tries to do an SSH session here, or if this
VM,
which is meant 20, tries to do an SSH session, they should both be blocked.
And because we're doing it with the distributed firewall, it would be done
respectively by host A over here and host B over here, both of which have
copies of that
distributed firewall. And both would deny that traffic if it was attempting to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
distributed firewall. And both would deny that traffic if it was attempting to
go up to that IP
address. So while we're here, let's verify that. So this is our Linux client. A
moment ago, we were
able to SSH and we'll hit the upper key. And now it's saying boom, connection
refused.
And let's also verify that from the Windows client. So here it is right here.
And we'll hit the upper
key and try to do SSH and survey says that connection is refused as well. So
that's NSX
denying that traffic. So if we clicked here on stats, even though it hasn't got
to the full 15
minutes yet, so we don't have this information right here, it does show us that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
minutes yet, so we don't have this information right here, it does show us that
we do have some
hit counts over here. So that rule is indeed being hit. Also, that rule is 7144
. We could also
verify it's being hit by going to plan and troubleshoot. And then on the left
hand side,
expanding that going down to traffic analysis. And then here in the trace flow
tile, clicking on
get started. And so for the traffic, we want to go ahead and say we're looking
for TCP traffic,
going to the world on port of 22, it'll look like a send request initially. And
for the VM,
let's go ahead and choose the Windows 11 client. And let's go ahead and also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's go ahead and choose the Windows 11 client. And let's go ahead and also
for the destination,
specify that instead of going to a VM, we're going to an IP address. So use IP
Mac, a layer three
for IP only, and 23.1.2.1. And then we'll click on trace to go ahead and
validate that that traffic
is indeed being denied by that rule as part of our distributed firewall policy.
So we'll give
that a moment to crank that out. And sure enough, so because the Windows client
was running on host
day, host day saw that traffic looked at the distributed firewall, there was a
rule specifically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
rule specifically
rule 7144. And it matched on that rule. So it denied the traffic. And that was
the end of that
conversation from that VM's perspective. So next, let's add another rule in
front of that one on
our distributed firewall that's going to permit the traffic if the client is
coming from a member of
that NSX group, which is tying back to the active directory group. So with
security selected on the
left with distributed firewall selected, I'm going to collapse that left hand
side to give us a little
more room here. And then for our SSH policy, we'll simply go ahead and select WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
more room here. And then for our SSH policy, we'll simply go ahead and select
it and we'll add another
rule. And we're going to put this rule above the deny. So for the new rule, we
'll call it permit
SSH. And for conditions for this rule being matched for the source, here's
where we're going to specify
the source group. So we'll click on the pencil and the sources column here for
this rule.
And then we're going to select this group right here. Now also, it'd be a great
idea just to verify
that at this moment that if we click here on view members, that that VM shows
up as a member of
that group, which it does. And that's due to the group definition, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that group, which it does. And that's due to the group definition, which is
tying back to the active
directory group called the S two SSH. So that looks great. We'll go ahead and
click on close
and then click on apply. And then as we continue configuring this rule, we're
specifying that traffic
is coming from a member of the group called NSX group tide. Let me go ahead and
make that a little
bit bigger tied to the active directory group. And if the destination is, and I
'm going to put that
same destination address. So for the destination, I'm going to use IP address
and put in 23.1.2.1,
and then click on apply. So there's the destination. And then for the service, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then click on apply. So there's the destination. And then for the service,
I also want to specify
we're looking at layer four for TCP going to the well known port of 22. So we
'll click on the pencil
in the services column, then we'll do a quick filter looking for SSH. There it
is right there.
TCP going to port 22, click on apply, and let's check our work. So this rule
permit SSH matches
if the source is in this group, and the destination is this IP address, and the
layer four protocol
is TCP going to port 22. So we're not going to be using context profiles. We're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is TCP going to port 22. So we're not going to be using context profiles. We're
not looking at the
application layer. We're just looking at layer four and the services column
here. And then it's
applied to artistry to firewall, and it's allowing the traffic. So we'll go
ahead and click on publish.
And here it says in progress, we'll click on refresh. And that looks good. So
let's bring in,
first of all, our Linux client, which is not an active directory, and it's also
not in that
active directory group. Let's verify that from our Linux Mint 20 computer that
is still going to
match on this rule, which is denying the SSH traffic. So here is our Linux
computer. We'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
computer. We'll
hit the up arrow key and try to SSH connection refused. If we try to ping, for
example, 8888,
that is being allowed. So that's great. We still have connected to the internet
. We're just being
blocked on that connection for SSH to 23.1.2.1. Also, we tried to ping 23.1.2.1
. That should work
because we are not explicitly denying that either. And so that's going all the
way through our
distributed firewall policy and being permitted by the final rule there. So we
'll do control
C there. But just to confirm, we cannot SSH. We're still being denied because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
C there. But just to confirm, we cannot SSH. We're still being denied because
we're not a member of
that active directory group. So let's minimize that. And let's bring in our
Windows client, which,
because it's a member of this group, it should match on this rule. And that
traffic should be allowed.
So here is our Windows client. And just to confirm, let's do an IP config. Sure
enough,
this is a 10 10 zero one 66. And a moment ago, when we tried our SSH session,
it was being denied.
But now, because we have the new rule that says, Hey, if you're a member of
this group as the source, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this group as the source,
and you're going to this IP address 23.1.2.1, and as TCP port 22, we're going
to go ahead and
permit it. So we'll press enter. And sure enough, it's asking us to log on to
that external router.
I'll put in the password there. And we are good to go. So for that rule right
there,
let me go ahead and scrunch these columns a little bit over. Let's click on
stats. So notice here
that we have had some traffic that's matched on that rule as shown right here.
So in the popularity
index and session count, it has numbers here. And again, with the warning that
this information
may be stale up to 15 minutes as there's aggregation that's done every 15 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
may be stale up to 15 minutes as there's aggregation that's done every 15
minutes. But we do have hit
counts here also to reinforce that that rule is being matched. Another way to
test this would be
to go ahead and disable that rule that's permitting that traffic will click on
publish. And then we'll
bring back our windows client. And then right here, if we try that SSH again,
now it's going to be
reset because that rule that's permitting based on group membership is no
longer enabled. So if
we enable that rule again, click on publish now permitting that traffic based
on group membership,
and then bring back our windows client, which is a member of that group and hit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then bring back our windows client, which is a member of that group and hit
the upper key
and press enter. Now we can log in with SSH, no problem. So let's recap. We
verified we have
active directory set up. We had a client logging on to active directory. We
trained NSX on how to
interact with active directory, including the use of LDAP, so that NSX could
only know who the
users are that are logging in, but also what groups those users are a member of
. Then furthermore,
we specified for the distributed firewall function and the gateway firewall
function
that we want both of those to be able to use identity based firewall services. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we want both of those to be able to use identity based firewall services.
And then we created
an NSX group that was tied to an active directory group. And then we use that
group as part of our
firewall rules. In our example, we use it as part of a distributed firewall
rule permitting SSH,
if the source was a member of the group. Also, it's important to note that we
're going to be using
the identity based firewall for the source information, not the destination. So
maybe in the future at
some point, they'll change the way that that's allowed. But currently, when we
use identity based
services as part of our security policy rules, if we're going to use them, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
services as part of our security policy rules, if we're going to use them, we
need to use them as
the source and not the destination as part of these security policy rules. Also
, now that we've
gone through this together, what we'll have to do in the next video is present
a scenario where
something has gone a little bit wrong, and they're going to call upon you and I
to identify what the
problem is and fix it regarding identity firewall services. So I'll see you in
this video as we
validate this knowledge together.