Since VMware NSX-T 2.4, VMware has introduced the ability with NSX to be able to pinpoint application identity, FQDN and URL whitelisting and provides the identity based firewall. All of these features of NSX-T since 2.4 take the platform to new heights of features and capabilities. With the new layer 7 application identification, your organization’s micro-segmentation objectives become much easier to accomplish and you can actually achieve context-aware micro-segmentation. In this post we will take a look at the NSX layer 7 firewall features and get a better overview of the capabilities provided.
What is the NSX Context-aware firewall?
VMware has been able to turn the security world of firewalling on its head with NSX context-aware firewall. Instead of the very static constructs of IP subnets and security zones that you find used with traditional firewalling, NSX is able to use the very rich knowledge that it has visibility to by being a part of the hypervisor kernel and “seeing” the traffic coming to and from the workloads there.
This allows NSX to be very dynamic in nature. With the application ID of a certain type of network traffic, you can think of this like a fingerprint. Regardless of what port that type of traffic comes across in your network, you can identify it effectively and apply rules to that type of traffic.
With the idea of context-aware firewall, NSX can now use constructs that are based on specific characteristics, operating systems, application identification, and others. This can also be combined with the identity-based firewall that can filter traffic based on the AD group that a member is a part of.
So the whole notion of context is powerful when it comes to filtering traffic as it now can base a filtering decision on the traffic flow and application/user context of the flow.
How is NSX Layer 7 firewall configured?
When looking at how the NSX Layer 7 firewall is configured, this is accomplished by means of context profiles. The context profile is a construct that identifies the application of a network flow.
By default NSX-T provides a large number of default context profiles that you can readily take advantage of, right out of the box. As you can see, these are found under the Inventory section of your NSX-T manager UI.
You can also add your own context profiles to the environment as well for customized traffic profiling.
Navigating to the Security tab, and the Distributed firewall, we can see the Context profile column in the distributed firewall rules that can be edited to effectively scope the traffic flows to the context of a specific application.
When you select to edit the context profile for a distributed firewall rule, you will see the following dialog box popup that allows you to choose which context profile you want to add to the firewall rule.
So, as you can see, adding an Application ID to our distributed firewall rule can tighten the scope of your network flow so that it is restricted to a specific application ID or a specific application ID is blocked.
NSX Identity Based Firewall
You can read my post here about a brief primer on how to get started with the Identity based firewall configuration. To give a general overview of the identity based firewall, it allows scoping network traffic depending on the identity of the user who is initiating the traffic flow.
This is extremely powerful in the realm of VDI or RDSH where you may have many different people authenticating to the same set of resources. However, you want one group member to be able to connect to one set of resources and then you want another group member to be able to connect to a different set of resources.
This is possible with the identity-based firewall capabilities. When setting up the identity-based firewall, you connect the NSX manager to your Active Directory infrastructure. With the hooks into Active directory, NSX can then apply group memberships to distributed firewall rules effectively.
The beauty of NSX identity-based firewall capabilities is that it is effective down to the specific TCP stream of an end user. In other words, if you have multiple people logged into the same RDSH server, one user could be allowed to connect to one resource and the other user could be allowed to connect to different resources.
With legacy firewalling and other legacy techniques for security like 802.1x, you can apply security to a specific network object or IP address. This means it is an all or nothing approach. Either all users get a certain set of resources or all have their traffic filtered. This is not the case with identity-based firewall.
FQDN and URL Whitelisting
URL Whitelisting is another NSX layer 7 firewall feature that allows you to scope traffic based on specific FQDNs or URLs that nodes are communicating with. Having the ability to scope traffic to a URL or FQDN is immensely powerful.
There is nothing more frustrating than trying to scope traffic with firewalls that may only be capable of layer 3 & 4 where you cannot use DNS names to scope your traffic. Today’s large cloud providers and cloud SaaS applications may have hundreds of IPs they are using to service the cloud service. And, these IPs may be constantly changing.
I don’t know about you, but having the ability to scope traffic based on an FQDN/URL is a whole lot easier and more efficient than having to enter 200 IPs.
The URL/FQDN whitelisting is based on context profiles as we mentioned earlier, talking about application IDs.
Wrapping Up
The VMware NSX Layer 7 Firewall Features provide a wealth of capabilities to control network traffic flows effectively at the hypervisor kernel layer. There are many powerful layer 7 firewall features that provide context to the traffic flows.
This includes application identification, identity-based firewall, and URL whitelisting. All of these capabilities provide next-generation capabilities for micro-segmenting your environment.
0 Comments