So now that we have verified our basic connectivity,
as well as confirming SSH and access out to the internet,
to Cisco and eBay,
let's begin our process based on our game plan of
eliminating some of that traffic on the distributed firewall,
leveraging context profiles.
So for our first task right here,
we're going to deny SSH from clients that would include these VMs.
So we'll make sure they're in the clients group,
and we'll set up a deny so that if they're trying to go to
this IP address right here at 23.1.2.1 using SSH, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this IP address right here at 23.1.2.1 using SSH,
that we're going to drop it.
So as part of setting up the new rule,
we're going to identify the SSH service,
basically the TCP protocol and port 22,
as well as using a context profile to confirm it's really SSH.
So without further ado,
let's head over to the NSX manager,
and let's create a new policy and a new rule that does exactly that.
So here in NSX manager, we'll click on the security tab,
and then on the left,
we'll go down under policy management to distributed firewall.
So that's where we are in the interface.
I'm also going to go ahead and collapse the left-hand side WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm also going to go ahead and collapse the left-hand side
to give us a little more room right here.
So here in the distributed firewall,
if we click on the all rules sub tab here,
it's showing us all the rules that exist from any of the categories.
And so if we want to see the category specific rules,
we can click right here.
And here we have Ethernet,
emergency, infrastructure, environment, and application.
And so these are going to be processed going from left to right.
And then within each category,
it's done from top down.
So for example, here in the application category,
we currently have three rules.
And these are three of the default rules that came with the system. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And these are three of the default rules that came with the system.
One for neighbor discovery protocol,
one for DHCP services,
and one for anything else that happens to be layer three.
And those are all being permitted by default in the default rules.
So I'll go ahead and collapse the default policy with his three rules.
And actually before we limit SSH,
let's verify that we can do SSH.
This is Mint1.
So we'll type in SSH,
and it'll do a dash L for login.
And we'll log in as the user bios to the IP address 23.1.2.1 press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll log in as the user bios to the IP address 23.1.2.1 press enter.
And it wants the password.
I'll supply that.
We'll press enter.
And sure enough, that works.
No problem.
Multipine exit.
Another option too,
we can use to test connectivity on a port is we can use telnet.
Now by default, telnet is going to be using TCP,
going to the well-known port for telnet of 23.
However, we can go ahead and change that here at the command line
by saying we want to telnet to 23.1.2.1.
However, we want to use port 22.
So that's a convenient way to help check and test connectivity
to see whether a port is open or not.
So if we press enter here, check it out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we press enter here, check it out.
We connected on that port.
Now once I press enter here,
it's going to say, whoa,
this isn't the SSH application.
It says the device at the other end.
And so there's a protocol mismatch error here
and it's kicking us out.
But we did get connectivity.
So if we do that again and just waited,
we have this open TCP session now here to port 22.
Just a way to verify that port is being allowed
through the network over to that gateway at 23.1.2.1.
So press enter, we'll close that.
And now that we've verified that SSH works
and that the TCP port 22 is open, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and that the TCP port 22 is open,
let's create a new policy.
So here with the distributed firewall selected
and the sub-tab of category specific rules
and with the application category selected,
let's click on add policy.
And let's name this our SSH policy.
So regarding this policy,
over here, there's a little gear for advanced configuration.
So we'll click on the gear.
And here for these settings for our SSH policy,
here are the defaults,
including TCP strict is enabled,
which basically means that there's a TCP segment
that's going through.
And it's not an initial send request. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's not an initial send request.
It's not part of an existing TCP session
that we've already seen.
It's going to go ahead and drop it effectively.
It's going to prevent something from manipulating
or trying to inject TCP traffic
if it's not part of an existing session.
The next option is stateful.
It is also enabled by default,
which basically means that the firewall
is going to monitor and maintain state information
for all the active connections going through it.
And then the third option here is locked.
It is off by default.
So if we have multiple administrators
and we want to lock the settings for this policy,
we can do so, do our work, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can do so, do our work,
and then take off the lock when we're done.
So I'm going to go ahead and leave the defaults
for the policy called our SSH policy.
We'll go ahead and click on cancel,
no changes there.
And now let's add a rule.
So within this policy, with it selected,
we'll click right here on add rule.
And to help demonstrate the differences
between this column here, which is services,
which is again referring to things like the layer
for protocol and the ports involved and context profiles,
which is actually looking at the application layer information,
I would like to make two separate rules here
so we can compare and contrast the two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so we can compare and contrast the two.
So for the first rule, we'll call it deny TCP to 22,
which means we're going to deny TCP traffic
if it's going to TCP port 22.
And then we're going to source.
Let's click on the edit icon.
And let's go ahead and say that's all clients.
And let's click on view members and survey says,
oh, I don't have my mint machines with that tag.
So we'll correct that here in a moment.
So I'm going to go ahead and use that group.
And we'll include mint one and mint two as part of that group.
So we'll click on close there, select that group, all clients, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on close there, select that group, all clients,
and click apply.
And then before I forget, I'm going to go ahead
and just click on publish here to save my changes.
And let's go back and make sure that mint one and mint two
are associated with that group called all clients.
So to do that, we're going to go to inventory.
And let me expand the left hand side here.
So if we click on groups and go to all clients,
and once again, click on view members at the moment,
we don't have mint one and mint two
because they don't have the correct tag associated with them.
So let's fix that by going to virtual machines.
Let's edit mint one and mint two by clicking on the three dots. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's edit mint one and mint two by clicking on the three dots.
Next to each of them, clicking on edit.
And we'll say that regarding tagging,
we want to assign the tag of client tag.
So we've assigned that to mint one.
We'll go ahead and scroll down, click on save,
and we'll do the same thing for mint two.
So for mint two, we'll go ahead and click on the three dots,
click on edit.
And then for the tags column, we'll go ahead
and choose the client tag there as well.
And then scroll down, click on save.
And then just to confirm I expand the left hand side,
so we're still under inventory.
We look at groups now for all clients
and click on view members right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and click on view members right here.
And sure enough, now we have mint one and mint two.
Fantastic.
All right.
So now that those are both members of the group,
let's go back to our firewall policy.
So we'll go to security on the top.
On the left, we'll click on distributed firewall.
I'll collapse that so we have more room to work with right here.
And let's continue our editing.
So for this rule called deny TCP to 22,
it's going to be rule ID 5096.
The source it's matching on is the all clients group.
And we can also change that too.
If we wanted to change it to, for example, IP addresses, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we wanted to change it to, for example, IP addresses,
we could add IP addressing information here.
So we could say, for example, 10, anything is going to match.
But because we already have our groups identified
with all clients and mint one and mint two are in that group,
we are good to go.
So we click on cancel there.
For the destination, I want it to just be to our router interface
at 23.1.2.1.
So we'll click on the pencil and we'll put in just that IP address
by clicking here on IP addresses
and putting in the destination address of 23.1.2.1
and clicking on apply.
All right.
So there's our destination. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for the service, let's go ahead and specify
the layer four protocol and the well-known port.
So to configure that, we'll click here
in the services column on the icon to edit that section.
So here in the services section, this
has over 400 different services that are identified.
And even though it has names of applications here
in this name column, it's really focused
on these service entries regarding the protocols
and ports that they are using.
So if we want to match on SSH, for example, port 22 for TCP,
we can go ahead and filter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can go ahead and filter.
We type in SSH, press enter.
And here is an entry for that.
So if we select this as a service,
it's really just matching on TCP with a destination port
of 22, which is the well-known port for SSH.
So we'll go ahead and click on that, click on apply.
And now we're matching on SSH.
And if we want to deny that traffic,
we would simply right here in the action section,
go ahead and click on either drop or reject.
So because it's TCP based, if we do a drop,
it'll just leave the client hanging.
If we do a reject, it'll cause a TCP reset WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we do a reject, it'll cause a TCP reset
to be sent to the client.
So before I click on publish, let's do a quick check
just to make sure that currently that port 22 is open.
So back here at Mint 1, if we do that telnet to port 22,
see how it's open right there, no problem.
Also, if we do an SSH to that router interface
and put in the password, we are connected.
So that's all working at the moment.
So they minimize this.
And let's go ahead and click on publish
and push those changes out to the distributed firewall.
So if we wanted to also, we don't have to apply this
to the entire distributed firewall. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the entire distributed firewall.
We could also just have it apply to specific groups.
But for our purposes, we want this to be a rule
and have it applied to the distributed firewall as a whole.
So I'm not going to make any changes right here
on the apply to section.
I'll click on cancel.
And so with reject there selected and currently it's enabled,
we'll click on publish.
So right here where it says in progress,
it's a little amber color.
We'll click on refresh there and make sure it is green.
Fantastic.
So here's our client.
We tested with a few moments ago Mint 1.
So we did a telnet, which is just kind of like tricking the system,
trying to connect on port 22, in this case, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
trying to connect on port 22, in this case,
with the 22 there and press enter.
We have a reset that came back.
And that's why it says connection refuse.
So then we try to use SSH because it's also going to the well known port
of TCP port 22 is being denied.
Now at this point in our game, it's only being denied
just because of the layer for port and protocol that was trying to go to.
TCP port 22.
And to confirm that we can hover over here on the SSH,
click on it and it'll give us a little pop-up saying, yep,
TCP, destination port equals 22.
And that's what it means for this SSH service. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's what it means for this SSH service.
Also, if there was a certain port and protocol that didn't exist already pred
efined,
you can also create new service entries to specify pretty much any port and
protocol.
And then you can include that as part of your security policy rule.
Also, there's another verification of this.
We could test this by using trace flow.
So if we go to plan and troubleshoot right here,
and then on the left, we'll expand our left-hand column,
go down to traffic analysis.
And then here on the tile for trace flow, we'll click on get started.
So for this trace, instead of using the default ICMP, we can choose TCP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for this trace, instead of using the default ICMP, we can choose TCP.
We can choose the destination port of 22.
It's very likely the clients can be using some random high-numbered port for
that session.
So we just make one up 6, 7, 8, 3.
For the TCP flags inside the TCP header, it's going to include a SIN flag,
which effectively looks like a SIN request.
So if you want to include more, we can click here and simply specify what we
want included.
So a SIN is fantastic.
And then for the source, we'll go ahead and choose Mint 1.
And for the destination, we'll go ahead and say, we don't want to test to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for the destination, we'll go ahead and say, we don't want to test to a
virtual machine,
but rather to an IP address.
And for the IP address, we'll click on layer 3, because we also don't care
about the layer 2
address there.
The destination IP address is 23.1.2.1.
And with that in place, we'll click on trace.
And because it's a distributed firewall, the host, that's currently the compute
resource
for Mint 1, it should be dropping that traffic immediately.
And here we go.
So that traffic was injected on ESXIB, because that's the host that's hosting
Mint 1.
And then logically went through the distributed firewall.
And it was then rejected.
And that's saying it's real 5096, which is going to be the rule that we just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's saying it's real 5096, which is going to be the rule that we just
set up to deny traffic
to TCP port 22.
So to verify that, if we go back to security and distributed firewall,
and we open up our SSH rule right here, let me collapse the left-hand side,
give us a little more room, there's the rule ID right there, 5096.
So effectively, at this point, any traffic, if it's going to this IP address
and it's going
on TCP port 22 as the destination port, that's going to match this rule and be
rejected.
So let me go ahead and disable that for a moment.
And we go ahead and make a new rule that's going to match just on the context WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we go ahead and make a new rule that's going to match just on the context
profile,
looking for the application ID for SSH.
So to do that, we'll go ahead and choose our SSH policy.
We'll click on add rule.
And I'm going to drag and drop this to just below the other one we just made.
So there's the new rule right there.
We'll call this deny SSH app.
And then for the source, let's go ahead and use the all clients group once
again.
So we'll click on the pencil, select all clients right there, click apply,
and we'll use the same destination.
So click on the pencil there for destination, and we'll click on IP addresses, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So click on the pencil there for destination, and we'll click on IP addresses,
and we'll put in the IP address 23.1.2.1 as the destination IP address.
So if you wanted to, you could go to range up there.
So we can do zero slash 24 that cover the whole subnet or for a specific host,
we could do 23.1.2.1 or we could do a slash 32.
Either way is great with or without the slash 32.
It's going to assume that we're talking about that specific host if we put that
IP address in, then we'll click on apply.
And then for services, for this example, I'm going to leave these services,
which is looking at the layer for information, for example, TCP port 22, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is looking at the layer for information, for example, TCP port 22,
I'm going to leave that blank and tell it just with a context profile to look
for
and see whether or not is the SSH application being carried in the application
layer
in the protocol stack.
So to do that, we'll click on the pencil.
And lucky for us, there's already a context profile for SSH.
So if we click on the filter and type in SSH and press enter, there it is right
there.
So this context profile is looking at the application layer for SSH traffic.
So we're going to go ahead and select it, click on apply. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're going to go ahead and select it, click on apply.
And then for the action for this new rule, I'm going to specify that we want to
go ahead
and reject it.
So the previous one there is disabled.
And now we only have this one reject rule regarding SSH.
So we'll go ahead and click on publish.
And here is the rule idea of 5097.
So now we only have this one rule that says deny traffic if it's the SSH using
a context
profile looking for the actual application itself.
So from a services perspective, this rule doesn't really care if it's TCP port
22 or
try three or anything else.
We're simply relying now completely on the context profile looking for the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're simply relying now completely on the context profile looking for the
application
of SSH.
So now if we bring back our client and we try to test, let's go ahead and do a
SSH again,
even though at layer four, we're not specifically looking just for TCP to port
22,
because at the application layer with our context profile, we're looking for
SSH.
And that's where attempting to use.
That's what's causing this reset to be sent to us from NSX,
because the distributive firewall policy is not allowing it.
So for demonstration purposes, I use two specific rules, but most of the time,
you're just going to want to have one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you're just going to want to have one.
So if we take this one right here, that's just looking for TCP traffic going to
the well known
port of 22, let's go ahead and click on the three dots there and we'll delete
that one,
click on publish.
And let's just edit our existing deny SSH app rule.
So currently we're looking for just the application layer information for SSH,
but we could also, in addition to that, say, hey, at layer four,
we also are specifically looking for TCP going to 22.
So we'll click on the pencil for the services column there,
and then for the layer for protocol, we'll do a search for SSH. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then for the layer for protocol, we'll do a search for SSH.
And again, we'll choose this one right here, but remember, when it says
services,
we're talking about layer four information.
This is TCP going to port 22.
So we'll click on apply there and then click on publish.
So originally we had two separate rules to compare and contrast,
filtering just based on layer four information versus application layer
information.
And for this rule right here, we are now paying attention to both,
including what is the specific layer for information regarding TCP going to
port 22,
as well as the application layer, checking to make sure it's really SSH. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as well as the application layer, checking to make sure it's really SSH.
And if it is in both those conditions match, we're going to go ahead and reject
the traffic.
So as far as our game plan goes, our first example denying SSH,
including the use of context profiles to look for the application SSH,
we have implemented that and tested it.
[BLANK_AUDIO]