Summary: With Context-awareness, NSX for vSphere 6.4 enables customers to enforce policy based on Application and Protocol Identification and expands the Identity Firewall support to Multiple User Sessions.

A few weeks ago, VMware released version 6.4 of NSX for vSphere.  The 6.4 release brings many new features, with Context-awareness being key from a security perspective.  Micro-segmentation enables East-West security controls, and is a key building block to a secure datacenter. Context-awareness builds-on and expands Micro-segmentation by  enabling customers even more fine-grained visibility and control.  NSX has supported the use infrastructure or application-centric constructs such as Security Groups based on criteria like VM name or OS version, or Dynamic Security Tags describing things like the workload function, the environment it’s deployed in, or any compliance requirements the workload falls under, enabling fine-grained control and allowing customers to automate the lifecycle of a security policy from the time an application is provisioned to the time it’s decommissioned. Prior to 6.4, rules with  infrastructure or application-centric grouping constructs on the Management plane, are eventually translated to 5-tuple based rules in the dataplane.

Figure: NSX drives policy based on Network, User and Workload Context

A crucial aspect of Context-awareness is that we support the use objects different than the traditional 5-tuple directly in the dataplane without having to the management plane “translating” these objects to IP addresses, protocols and ports.

Context-Aware Architecture

Under the hood, the key architectural components enabling context-awareness are the Context-Engine and Context-table along with other components that allow us to discover contextual information for every connection. The Context-Engine is a user-space component that resides on every host in an NSX-prepared cluster. It receives discovered contextual information and programs the Context-Table with that information.  The Context-Table keeps track of Context-Attributes for every flow going through the distributed firewall filter. Every new connection along with it’s Context-Attributes is then checked against the Distributed Firewall Rule-set and is mapped to a rule, not just based on 5-tuple but also based on the context-attributes specified in the rule.

In the 6.4 release, two new features take advantage of this context-aware architecture, Application and Protocol Identification and Multi-session Identity Firewall.


Figure: NSX 6.4 Context-Aware Architecture

Application and Protocol Identification

Application and Protocol Identification is the ability identify which application a particular packet or flow is generated by, independent of the port that is being used.  In addition to visibility into flows, enforcement based on application identity is another key aspect, enabling customers to allow or deny applications to run on any port, or to force applications to run on their standard port. Deep Packet Inspection (DPI) is foundational to this functionality, it enables matching of packet payload against defined patterns, commonly referred to as signatures.


Figure: NSX Native Distributed Firewall now acts on Layer 7 as well as L2 – L4

Getting Layer 7 visibility into East-to-West application flows in a datacenter and being able to enforce policy based not only on port but also based on the Layer 7 application identification, enables customers to reduce the attack surface even further.  The Application and Protocol Identity feature in NSX for vSphere 6.4 enables visibility across a large number of applications and enforcement based on applications commonly seen in enterprise datacenter infrastructure or application tiers such as Active Directory, DNS, HTTPS or MySQL.

Customers can use built-in Layer 7 Service Objects for port-independent enforcement or  create new Service Objects that leverage a combination of Layer 7 Application Identity, Protocol and Port. Layer 7 based Service Objects can be used in the Firewall Rule table and Service Composer, and application identification information is captured in Distributed Firewall logs, Flow Monitoring and Application Rule Manager (ARM) when profiling an application.

Key use-cases for Application and Protocol Identification are centered around Layer 7 visibility and enforcement across Infrastructure services, Intra/Inter Application and VDI/End User Compute:

 

  • Enforcement based on both Port and Layer 7 App-ID enabling customers to further reduce the attack surface by ensuring only the intended application can run across a given port

  • Blocking of Vulnerable Application Versions allowing customers to enforce the use of more secure/less vulnerable versions
  • Blocking of Vulnerable Application Versions allowing customers to enforce the use of more secure/less vulnerable versions

  • Application Layer 7 Visibility enables customers to discover what applications and application versions (TLS) are being used

Application and Protocol Identification in Application Rule Manager

Application Rule Manager (ARM) was introduced in NSX for vSphere 6.3,  and enables customers to automate application profiling and rapidly apply the appropriate allowlisting policy. In NSX for vSphere 6.4, ARM has been augmented with the Recommendation Engine, which is covered in detail in this blog post by my colleague Ganapathi. In addition to the recommendation engine, ARM now also has visibility into layer 7 context.

During the “Flow Monitoring” phase, ARM will learn about flows coming in/out of the application being profiled as well as flows in between application tiers. It will also learn about any Layer 7 Application Identity for the flows being discovered. This layer 7 visibility in ARM provide additional validation for Security teams that a particular flow should or should not be allowed in a zero-trust policy model. In addition to visibility, ARM also provides customers the ability to create new Layer 7 Service Objects outside of the list of ~50 built-in layer 7 services. For instance, if ARM discovers Bittorrent traffic, security teams can create an L7 service object for Bittorrent in order to explicitly allow/deny this application.


Figure: Intra-application flows identified based on Layer 7  Application Rule Manager

Application and Protocol Identification in Live Flow Monitoring

Live Flow Monitoring provides visualization of flows as they traverse a particular vNIC. This enables quick troubleshooting. As of NSX for vSphere 6.4, application context is also captured in Live Flow Monitoring for flow that match an L7 rule. Application fingerprinting in Live Flow Monitoring is available for over 1000 applications.

Figure: Live Flow Monitoring with Application Context

Application and Protocol Identification in Distributed Firewall Logs

With the Distributed Firewall, logs can be enabled/disabled on a per-rule basis. Any flow that is matching a rule with an L7 service object and logging enabled will trigger a log that contains the Application ID. Vrealize Log Insight can be used to gain additional insight into logs including the Distributed Firewall Logs

Architecture for Application and Protocol Identification

The context-aware architecture (described above) in NSX for vSphere 6.4 enables Application and Protocol Identification by keeping track of the Application-ID attribute for every flow in the Context-table. In addition to the Context-Engine and Context-Table, the Deep Packet Inspection (DPI)-Engine analyzes every flow and determines the L7 application Identity. After it has determined the App-ID, the Context Engine updates the Context Table flow entry with the appropriate application attribute. The flow is then re-evaluated against all rules that match the App-ID as well as 5-tuple, the flow table is updated and the appropriate enforcement action is taken.


Figure: Application Identification is kept in the Context Table

Configuring Application and Protocol Identification

Configuring a Distributed Firewall policy that leverages Application and Protocol Identification can be done using the Firewall Rule Table or using Service Composer. Regardless of which method you are using, here are the basic steps to follow:

  1. Create the appropriate Service Object
    • Go to Groups and Tags → Service
    • Select Layer 7 and specify App ID, Protocol and Port
    • Note: for port-independent enforcement, this step can be skipped.
  2. Use the Service Object in a rule/policy
    • Create a new DFW rule (first create a new policy when using Service Composer)
    • Choose the appropriate Source/Destination as usual
    • In the service field, select the L7 service object you have created earlier, or for port-independent enforcement, choose one of the ~50 built-in L7 service objects (name starting with APP_)
    • Choose the appropriate action (allow/deny)
    • Enable logging if required
    • Save the rule and publish the changes.

                      Figure: Adding a new Layer 7 Service Object                                          

Figure: Intra-Application Policy using Layer 7 Service Objects

Demo

Here’s a quick demo showing how NSX Application and Protocol Identification is configured and how it works.

Multi-session Identity Firewall

VMware introduced Identity Firewall feature with the NSX for vSphere 6.0 release. Identity Firewall allows customers to create firewall rules based on Active Directory user groups.  Prior the the NSX 6.4 release, Identity Firewall has been primarily used for Virtual Desktop Infrastructure (VDI) where it enables a different set of policies to be applied to a Virtual Desktop depending on the user who logs in to the desktop. With VDI, a Virtual Desktop is allocated to a single user. Upon user login, NSX determines the user-to-IP mapping either using NSX Guest Introspection Framework or Active Directory Log Scraping and adds those IP addresses into relevant Security Groups and Rules at the hypervisor dataplane where the rules are enforced.  This enables a highly scalable deployment in VDI environments.

Many of our customers also leverage Microsoft’s Remote Desktop Services (RDSH) or Virtual User Sessions besides VDI, especially for single application delivery. VMware Horizon or Citrix XenApp can both provide application deployment and access use RDSH services.

With NSX for vSphere 6.4, we are expanding the Identity Firewall use-case by enabling support for RDSH.  This means that with 6.4, multiple users can be logged in to the same Remote Desktop Session Host, and an appropriate Distributed Firewall ruleset will be applied to each user.  We have also extended User Identity to the Endpoint Monitoring feature.  Customers can now use Endpoint Monitoring along with Application Rule Manager to profile applications and map flows to applications, processes, and the user who is running the process.

Figure: Virtual Desktop Infrastructure and Virtual User Sessions

Architecture for Multi-session Identity Firewall

Similarly to Application and Protocol Identification, the Multi-session Identity Firewall feature leverages the context-aware architecture in NSX for vSphere 6.4. First of all, the context-aware architecture allows the use of attributes different from 5-tuple in the dataplane.  With regards to Identity Firewall, this means that NSX Manager no longer need to translate users to IP address at the dataplane as was the case prior to 6.4. The Security Identifiers (SIDs) of a user can now be programmed directly at the dataplane and incoming flows can be matched against them.  A new option is available when creating a new Firewall Section or Policy in Service Composer which defines that directory-group based security groups within the section/policy should be programmed directly as SID-attributes in the dataplane ruleset. See details below on how to configure this.

Once the appropriate policy has been configured, flows from remote user sessions will be evaluated against the configured policy.  Using the VMware Tools Thin Agent along with Guest Introspection (GI) Framework, NSX is able to determine if a particular VM is an RDSH host. When a user logs in to an RDSH host and generates TCP flows, the Context-Engine leverages event information from the Guest Introspection Service Virtual Machine (GI SVM) to update the Context Table with a new entry mapping the user’s group Security Identifiers (SIDs) to the flow. The flow on the datapath along with the mapped SID is then matched against the Distributed Firewall rules that have Security Groups based on user-identity and the appropriate enforcement action is taken.


Figure: User-Context (SID) is maintained in the Context Table

Configuring Multi-session Identity Firewall

Prior to configuring Multi-session Identity Firewall, there are some prerequisites that need to be met.  

  • Active Directory must be integrated with NSX Manager
  • VMware Tools must be running on the RDSH VM
  • NSX for vSphere 6.4 along with  Guest Introspection SVM 6.4 needs to be deployed on all hosts

Once prerequisites have been met, you can configure Distributed Firewall rules to be applied to Multiple user session following the below steps, either using the Firewall Rule Table or Service Composer:

  1. Create a Security Group based on the applicable Active Directory Group (do not use any other membership criteria)
    • Go to Service Composer → Security Groups
    • Select the appropriate Directory Group(s) under Objects to Include
    • Note: do not include any other membership criteria besides Directory Groups
  2. Create a new Distributed Firewall Section or Service Composer Policy and check Enable User Identity at source
    • Note: No translation from users to IP happens for rules in this section/policy
    • Use the earlier created Security Group as source in the rule(s)

Figure:  Defining a Security Group based on Directory Group Membership   

 

Figure:  Rules based on User Identity

Demo

In this 5 minute demo, I’m reviewing some of the basics behind Multi-session Identity Firewall before showing how to user user-session based firewall rules.