One of the really beautiful things about security in the world of NSX is that
we have a concept
called micro segmentation.
So to really appreciate that, let's talk about in the old days, let's go back
20 or 30 years
and take a look at how we did controlling of traffic on a network back in the
early days.
So back in the early days, let's imagine we have a router, we couldn't call
that router
one, and we have a network over here, let's call that the 10-10 network.
And then over here on the right, we have the 10-20 network, and then we have
some servers
and printers and other devices connected respectively to those networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and printers and other devices connected respectively to those networks.
So perhaps this device right here is at 10.20.0.100, and instead of here is at
10.20.0.101.
And over here, this device is at 10.10.0.
Let's go ahead and use 90.
And this device right here, let's say it's at 10.10.0.91.
All right, fantastic.
And then for default gateway services, let's imagine this router is at dot one
on the 10-10
network and over here on the 10-20 network that is dot one over here with 10-20 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network and over here on the 10-20 network that is dot one over here with 10-20
.1.
And then based on the IP configuration of these devices, they would be using
dot one
on their respective networks as their default gateway.
And then router one, of course, can have connectivity to additional networks,
which we'll
just represent as a cloud.
And let's further more imagine that over here, this group of computers in this
network
segment, that's the human resources department.
And over here on the right hand side on the 10-20 network, let's imagine that's
the engineering
group.
So I wanted to set up controls to control what traffic is allowed.
For example, between 10-10 over here and 10-20-0 over here, what we would do in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For example, between 10-10 over here and 10-20-0 over here, what we would do in
the old days
is we would set up controls at this router.
So we could put in access control list at these interfaces that specify, "Hey,
I want
to permit or deny this certain type of traffic based on IP address or the layer
for protocol,
et cetera, going between 10-10 and 10-20 and the pass that was implemented with
access
control list.
And with stateful filtering, it can go ahead and based on our rules allow
initial
flows of traffic and then dynamically remember those states and allow the reply
traffic to
come back."
So many of the routers and most of the firewalls today are capable of doing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So many of the routers and most of the firewalls today are capable of doing
stateful filtering,
where they allow initial flows of traffic and remember that session and allow
the reply
traffic to come back.
However, I've got a question and a problem to present and that's this.
What if we want to control what traffic is allowed between this host?
We'll call it host A and this host, host B.
Now if they are the same local area network and they're not going through the
router interfaces
or if this was a firewall, they're not going through the firewall interfaces,
how do we
control what traffic is allowed between host A and host B?
And the answer in the old world was if this was a VLAN, we could set up layer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the answer in the old world was if this was a VLAN, we could set up layer
two security
and implement that but that was really, really tedious to do manually.
However, in the world of NSX, if these are two VMs and they're both right here,
for example,
on segment 10, we can set up a distributed firewall and that distributed
firewall, think
of it like a firewall with a set of rules that hovers over the entire network.
So with the distributed firewall, we could say, for example, as part of our
rules, that
hey, we don't want to allow, let's say, certain types of traffic, let's say a
ping
request or any ICMP traffic between host A here and host B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
request or any ICMP traffic between host A here and host B.
So if we set up that distributed firewall rule, it doesn't matter if these
devices A
and B are on the same local segment or if we move one to another segment, that
distributed
firewall rule is going to be implemented regardless of where that machine goes.
Now if we had to do those rules for every single machine to every other
possible virtual
machine, that would be very tedious as well.
So we're also going to leverage the concept of groups.
And as an example of that, we could create a group called users.
And this user's group could represent a group of VMs that are acting as clients WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this user's group could represent a group of VMs that are acting as clients
.
So maybe for this user's group, and then we go ahead and color code these.
So for the user's group, we'll go ahead and use this orange color right there.
And let's go ahead and put this VM and that VM and that VM and that VM, we'll
put them
all inside of this group called users.
And then we can create another group called servers.
And just for this example right here, let's just imagine this web server here
and also
this database server here are going to be part of that group.
And then as part of our configuration for the security policy rules as part of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then as part of our configuration for the security policy rules as part of
our distributed
firewall, we can specify exactly what is allowed between, for example, objects
or in this case,
VMs that are in the user's group, if they're connecting to or interacting with
the servers
group.
So let me clean up a little bit of this as we continue our discussion here.
So as part of our rules, let's go ahead and use ICMP as an example.
We can say no, ICMP from the user's security group, if it is trying to access
any objects
or VMs here as part of the server's security group.
And then the cool thing is this, once we implement that, this VM right here on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then the cool thing is this, once we implement that, this VM right here on
the same local
network segment as the web server, if we had that rule in place, there'd be no
permissions
for any kind of ICMP traffic that was initiated from this VM trying to go to
the web server
because in our security policy rules, we're specifying that that is not allowed
.
Now another great question I'd like to chat with you about is regarding, okay,
how exactly
do we get these VMs?
For example, these four VMs in orange here, how do we get them included as part
of this
user's security group?
Now, one way is we can just manually go select them and add them or we could go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, one way is we can just manually go select them and add them or we could go
ahead and
create a dynamic group.
So for a dynamic group, we can specify if a VM matches these criteria, for
example, this
OS or that IP address, then go ahead and include them as part of the group.
Now, one of those options we conclude as a criteria for a group membership is
the concept
of a tag.
So for example, in NSX, we could go ahead and create a tag called user, and I
'll go ahead
and call it user tag here, and we create another tag called server tag.
And we associate that user tag with these four VMs right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we associate that user tag with these four VMs right here.
And if we have a group that's looking for any VMs that have that tag, that'll
dynamically
make any of those four VMs that have that tag a member of that group.
And we can do a similar concept for the servers to make them a member of the
servers group.
We either manually add them individually or we could look for some
characteristic, including
the use of a tag.
So for these servers, if we specify these two servers that they had this tag
called server
tag, and then we create a group called servers.
And as part of the dynamic membership of that group, if you have the tag called
server
tag, you're a member of that group.
And that way we can very easily on the fly, manipulate the tags associated with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that way we can very easily on the fly, manipulate the tags associated with
the VMs.
And as a result, they would then be included as part of the respective security
group.
And then also as a byproduct of that, if we have our distributed firewall rules
that
are permitting or denying certain types of traffic flow, we're now able to
control all
the traffic that flows between any of our VMs in our environment based on our
security
policy rules.
Also, another really cool thing about a distributed firewall is that very
similar to the concept
of routing where a host transport node will make all the routing decisions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of routing where a host transport node will make all the routing decisions
early and
then forward it to the final destination.
The same thing is true for our distributed firewall rules.
For example, if this little VM right here, which is running on host A, is
trying to send
traffic that's going either to another VM on the local segment or needs to be
routed
through the NSX routed environment, either way, host A because it has a copy of
not only
the distributed router, but also all the rules included as part of our
distributed firewall
rules.
If there's a deny that says, hey, that traffic is not allowed, it's the ESXi
host transport
node where that VM lives that's going to identify, hey, that's not allowed and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
node where that VM lives that's going to identify, hey, that's not allowed and
kill it right
near the source.
So for this VM here, this part of the users group, if it was trying to connect
down to
this database server here, which is part of the servers group, where this VM
here, VMA
is running on host A and the database VM is running on host B, if that traffic
from this
VM to that server is not allowed, it's ESXi A, that host transport node that
has all that
information about the distributed firewall rules that's going to go ahead and
say, whoa,
that traffic is not allowed and deny it right there.
Didn't have to wait until it gets all the way over to ESXi B for ESXi B to make WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Didn't have to wait until it gets all the way over to ESXi B for ESXi B to make
the decision.
ESXi A can enforce those rules immediately, drop the traffic and the host ESXi
B would
never have to make that decision because the traffic was never sent over there
in the first
place.
So again, just like routing, the security policy rules as part of a distributed
firewall
are processed as close to the source as possible.
So let me clean some of this up and let's talk about one other concept
regarding distributed
firewalls.
And the concept I'd like to share with you is the order.
Let's imagine we have several rules in place that are either going to permit or
deny traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
deny traffic.
How exactly are those processed?
And the answer is they are going to be processed in, first of all, a set of
categories.
So those categories go left to right.
So I'm going to call this category one, two, three, and four, and five.
They have some names as we'll see in the interface.
And again, those are processed from left to right.
And within each of those categories, there could be one or more policies which
also include
rules that are permitting or denying traffic based on a match.
So let's imagine here in category one, we have a couple rules.
Let's call it rule A and B.
And then over here in category two, we have rules C. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then over here in category two, we have rules C.
And D and E. And then category three, we have F and G and H and I, each of
those representing
rules.
And then over here in category four, B, J and K and L. And then category five,
it's M and
N and O and P and Q.
And those could go on.
And again, each of those represents the individual rules as part of our
security policy.
So as far as how these are processed looking for a match, we're going to start
on the
left with the first category and then go through everything in that first
category and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
category and then
go to category two, then we'll check all the rules in that category and then go
to category
three, check all those rules.
So let's imagine we have traffic that's flowing through the network or wants to
flow through
the network inside of NSX and for the criteria for the matching, there's
nothing specifically
matching in category one, there's no specific rules as part of category two.
But let's imagine that we have a rule H here in category three.
And so there's a match.
And as a result, it's going to go ahead and do what that rule says.
And the options that we can specify for a rule that's being matched is we can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the options that we can specify for a rule that's being matched is we can
go ahead and
allow that traffic.
We can go ahead and drop that traffic or we can reject that traffic.
So allow simply says, permit the traffic to go.
A drop says, go ahead and drop the traffic.
Don't let it continue.
However, don't bother telling anybody else that you drop the traffic.
So if this client, for example, right here was trying to connect to this server
down here,
maybe it was a TCP session that was being attempted by this VM and it was being
denied
here.
So if the rules being matched and the action was dropped, this client would not
get a TCP
reset or any other indication that it was being rejected by the network or by WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
reset or any other indication that it was being rejected by the network or by
the server.
So we have dropped as the action for a matched rule.
This VM would simply, if it matched that rule, simply think, wow, the service
isn't working
and it would simply timeout.
On the other hand, if we said reject as opposed to drop for the action on that
matched H rule,
in that case, if this VM initiated or tried to initiate a TCP session down to
the server,
the response coming back would be a TCP reset.
Effectively, information is saying, you know what?
This isn't going to happen.
It's not going to work.
At which point, this VM right here would know because it's got feedback from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At which point, this VM right here would know because it's got feedback from
the network
that that session is not allowed.
And as a result, instead of waiting, for example, for several seconds to
timeout, it
would know immediately that session is not allowed.
So from a security perspective, why would we use one over the other?
Well, if we use a drop and somebody's trying to attack us or scan our network
and figure
out what's available, if we do a drop, we're not giving back to the particular
network,
potential attacker, any additional information.
Where if we say reject as our action for that rule, then an attacker is going
to get a response
back.
And then based on that response, the attacker has just a teeny bit more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then based on that response, the attacker has just a teeny bit more
information regarding
what's allowed or not allowed on our network.
Also I'd like to point out something right here as the very last rule in the
very last
category.
And that rule, by default, is permitting all IP traffic at layer three.
So here's what that means.
If we don't have any specific rules earlier in our security policies that are
denying
or matching on traffic, everything at the end of the day, if it's not matched
earlier,
is going to match on this rule right here.
And that default action is allow, meaning all the traffic is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that default action is allow, meaning all the traffic is going to be
allowed by default.
Now that may seem like a foreign concept of a default allow at the end of our
security
policy.
However, just imagine if the default behavior they set up as part of the
security policy
rules was to drop or reject traffic.
That means that pretty much no traffic would flow whatsoever in our networked
environment
unless it was permitted explicitly earlier.
Now it might be a good goal to get to a point where we add on an additional
rule and we
say we want to drop everything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
say we want to drop everything.
But that would be after we have explicitly set up our rules to permit the
traffic that
we want on our network.
So just be aware that by default, there is a default allow action at the end of
the
distributed firewall policy security rules.
And again, if we don't have traffic that's matched earlier in the policy, it's
going to
hit that allow rule by default.
So now that we've taken a big picture look at the concept of a distributed
firewall that
provides us the ability at a very granular level to control what traffic flows
are allowed.
In the next video, let's pause for a moment and create a specific game plan WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In the next video, let's pause for a moment and create a specific game plan
that we can
put together, implement, and verify.
So I'll see you in the next video for that game plan.