To really appreciate the use of a context profile, let's take just a moment and
review some of the basic concepts of a distributed firewall and then we'll add
on top of it context profiles.
When setting up a distributed firewall, think of it like a firewall service
that hovers over the entire topology.
So, I think we set up our rules as part of a distributed firewall.
All of our transport nodes involved, including host transport nodes and edge
transport nodes.
They all have a copy of that distributed firewall and they can enforce that
policy.
And that's a good thing because if we have a VM like this, VM number one right WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's a good thing because if we have a VM like this, VM number one right
here, that wants to communicate down here with VM number two, when VM number
one tries to communicate or sends traffic over to VM number two, because the
host A, which is one of our transport nodes has a copy of that distributed
firewall.
If that traffic is not permitted, it's host A, they can go ahead and squash
that right there, very close to the source.
We're not wasting a lot of resources over on ESXAB or other edge nodes because
we're stopping that traffic as close to the source as possible.
If that traffic is not allowed by the rules in the distributed firewall.
And as far as the rules in a distributed firewall go, we can filter based on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as far as the rules in a distributed firewall go, we can filter based on
source or destination IP address information.
That'd be at the layer three or the network layer of our protocol stack.
So put S and D for source and destination.
And an example of source and destination should be, for example, traffic coming
from the 1010 zero network, trying to go to the 1020 zero network.
There'd be an example of including some IP information as part of our
distributed firewall rule.
In addition to specifying the source and or destination addresses involved as
part of one of our policy rules for the distributed firewall, we can also
specify specifically what services we want to permit or deny. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specify specifically what services we want to permit or deny.
And that would be information, for example, right here, the transport layer of
our protocol stack. So things like TCP or UDP, including the ports involved.
So, for example, SSH uses the well known port at the server of TCP port 22 and
the traditional flavor of DNS uses UDP at the transport layer with port number
53.
So we can specifically permit or deny traffic based on that layer for
information as well.
I also want to throw in ICMP, which is protocol number one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I also want to throw in ICMP, which is protocol number one.
So TCP is protocol number six, UDP is protocol number 17 in decimal and ICMP is
protocol number one.
And once again, in our distributed firewall, we can permit or deny based on any
of that information.
Now, in addition to specifying as part of our DFW rules, information about the
source and the association IP addresses and the transport protocols and our
reports that are being used.
We also have like 11 billion other things that we can also match on to control
traffic.
As we looked at in the previous skill on TFW, we also can do it based on group WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As we looked at in the previous skill on TFW, we also can do it based on group
membership as a condition of source or destination.
We also looked at how we can use dynamic group membership by, for example,
giving a certain number of VMs, a certain tag, and then including any of those
VMs that have that tag as part of a group.
And I'm going to draw a little line right here between these lower layers,
layer four, layer three, et cetera, and the application layer services.
And I'd also like to pose a question.
If the VM number one here is trying to initiate an SSH session down here to VM
number two, which is over on the 1020s or network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
number two, which is over on the 1020s or network.
How do we really know that it's really the SSH application that this VM is
trying to use as it connects over?
Well, one way is to say, well, based on the traffic is going to TCP to the well
known port of 22.
So based on that, maybe it's an SSH session, but you know what?
There's a lot of other ways that we can generate traffic using TCP port 22 that
would not be SSH.
So another option we want to include is to be able to take a deeper look and
see what's really running at the application layer and not just what is the
ports and protocols that are in use. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ports and protocols that are in use.
So if we wanted to permit SSH sessions from VM one to VM two and we wanted to
make really sure that it really is SSH, what we're going to do is we are going
to leverage a context profile and a context profile.
You can kind of think of it as taking a closer look at what's really going on
at the application layer.
So for example, if we're going to create a DFW rule that wants to make really
sure that it really is SSH, not just some other application that's trying to
use TCP port 22 to bypass some security policies that we have. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
use TCP port 22 to bypass some security policies that we have.
What we could do is this we could say in our security policy role, if the
source, let's go ahead and say that this VM belongs to a group either manually
or dynamically built group for clients.
So let's say the source is a member of the group clients and the destination is
a member of the group server.
So we'll imagine that VM two is in the servers group or instead of using group
membership, we could also do it based on IP addresses.
If we know what those IP addresses are, or we could say based on the subnet the
client's and the subnet the servers in, it just depends on what we want to
implement as far as our security. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
implement as far as our security.
So for this, we'll say if the source VM is in the client's group and the
destination is in the servers group and if the service and I'm intentionally
putting this here in orange because I want you to think of layer four
information.
If the service is TCP going to the well known port of 22 that service component
in our DFW rule addresses the layer for information right here.
So this is saying TCP going to port 22. And then what we're going to add on top
of it is a context profile, which I will put in green to help us remember that
this is looking at the application layer services. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is looking at the application layer services.
So in the context profile, we could say we're looking for the characteristics
of an application known as SSH. And I'm going to put right here on the left and
say that's the application identifier or the app that is recognizing.
So in that case, if this VM right here tries to initiate a conversation to this
VM here as long as the VM one is in the clients group and VM two is in the
servers group and the initial flow of traffic is on TCP port 22 and at the
application layer.
And as [garbled] is identifying that, yep, this really is SSH. It's not some other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as [garbled] is identifying that, yep, this really is SSH. It's not some other
tunnel traffic just going over TCP port 22 based on all those considerations
matching that will allow that flow of traffic for an session from this VM right
here via one going down to VM two.
So the takeaway here is that a context profile gives us the ability to take a
closer look at what's really going on at the application layer.
And then we can use that as part of our rules. And if we choose not to use a
context profile, which we don't always have to, then we're just relying on the
matching and permitting or denying based on layer for protocols such as TCP or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
matching and permitting or denying based on layer for protocols such as TCP or
UDP or ICMP.
And the case of TCP and UDP, the ports involved for the initial flow of traffic
.
And so in a world where hackers and attackers can do tunneling of protocols
under different and non standard ports, it's important to have this additional
application awareness component so that we can accurately control the flow of
traffic with the intended apps that we want going through our network.
And on the other hand denying certain applications that we don't want to flow WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And on the other hand denying certain applications that we don't want to flow
through our network.