NSX-T 2.4 Introduces Layer 7 Application Identity, FQDN /URL Allowlisting and Identity Firewall

With last’s week landmark release of NSX-T 2.4,  and the RSA conference in full swing,  this is the perfect time to talk about to some of the new security functionality we are introducing in NSX-T 2.4.

If you prefer seeing NSX-T in action, you can watch this demo which covers Layer 7 application identity, FQDN Filtering and Identity Firewall. Or if you are around at RSAC in San Francisco this week, swing by the VMware booth. 

Micro-segmentation has been one of the key reasons why our customers deploy NSX Data Center. With Micro-segmentation, NSX enables organizations to implement a  zero trust network security model  in their on-premise data center as well as in the cloud and beyond.  A key component making Micro-segmentation possible is the Distributed Firewall, which is deployed at the logical port of every workload allowing the most granular level of enforcement, regardless of the form factor of that workload – Virtual Machine – Container – Bare Metal Server or where that workload resides – On Premise – AWS -Azure – VMC.

NSX-T 2.4 provides significant new security features and functionality such as Context-aware Micro-segmentation, Network (and Security) Infrastructure as Code, E-W Service Insertion and Guest Introspection.  Layer 7 Application Identity, FQDN /URL allowlisting and Identity Firewalling are key features that make NSX-T Context-aware.

In this blog and the below demo, I’m covering how the new Context-aware capabilities can be leveraged to enable the zero-trust network security model.

Challenges with Traditional Data Center Security

In the traditional network-centric approach to security, network and security teams are tasked with determining the appropriate policy and rules after a new application has been developed. This often is a very time consuming, manual and error-prone process involving various review cycles, and results in a complex set of rules based on network constructs such as IP addresses and Ports that are hard to tie to applications. In addition to that initial complexity, network-based security policies are not conducive to changing applications

Modern day applications are a network of distributed servers, which can consists of Virtual Machines, Containers and sometimes Bare Metal systems, which are all intended to work together. In the traditional network-centric approach to security, VLANs and hairpinning of traffic to hardware-based firewalls are used to provide a certain level of segmentation between different kinds of workloads. This is often used to segment the tiers of applications, but does not prevent lateral communication between workload within a tier, leading to a large lateral attack surface between various applications. Most importantly, this model and the life cycle of associated policies is also not aligned with applications The disconnect between policies and the actual applications these policies should protect leads to explosion in the number of rules providing inadequate and inflexible security.

Zero Trust Through Context

How can we provide the ultimate level of segmentation, and how can we deliver a security policy that is aligned with our applications, and is provisioned and decommissioned right along with the application itself ?
We need to be able to identify our application,  determine which workloads comprise the application, and what network traffic is necessary for the application to function. Then we can create micro-segmentation policies to restrict any other traffic, which immediately reduces the attack surface.

The NSX-T Distributed Firewall is the key component in enforcing Micro-segmentation. It’s built directly into the hypervisor kernel and provides Layer 2 to Layer 7 stateful filtering, enabling a context-defined and network-independent policy and enforcement at line rate. This enforcement is distributed to the most granular level, with basically a firewall sitting right at the vNic of every virtual machine.   All policies are centrally configured either from the UI, through a CMP or using our API.

In traditional security approaches, policies are applied to static groups defined by the network topology like security zones and IP subnets.

Because NSX is embedded in the hypervisor, it has rich contextual knowledge of what is taking place with dynamic workloads in both the physical and virtual environments.  Instead of grouping and rules based on where something is in the network, we can use constructs based on specific characteristics of that workload,  including for example the Operating System or Name of the workload. Through the use of security tags, workload can also be grouped based on criteria such as the function of the application, the application tier the workload is part of, the security posture, regulatory requirements such as PCI or GDPR or the environment the application is deployed in. With Identity Firewalling, we can also create a policy that limits access to applications based on the Active Directory group a user belongs to, and with Layer 7 Application Identity in NSX-T 2.4, we now also provide customers the ability to define a policy that allows/denies flows from a particular application/protocol to traverse E-W between workloads regardless of the port that is being used.

In NSX-T, Groups can be based on a combination of static and dynamic criteria such as tags as well as AD User Group. Criteria in Red are new in NSX-T 2.4.

Layer 7 Application-ID

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. This enables our customers to reduce the attack surface even further by ensuring only the intended application is able to communicate on a given port and preventing any other protocols from tunneling across an open port. Beyond identifying the protocol/application itself, NSX-T 2.4 also enables the enforcement of additional Layer 7 attributes, including protocol versions for TLS and CIFS and Cipher suites for TLS, enforcing the usage of secure protocol versions and cipher suites.

Enforcement based on combination of port and/or app-ID/version 

With Layer 7 Application Identity, NSX-T leverages a set of built-in application signatures, which allow us to fingerprint network flows in order to determine which Layer 7 application/protocol generated the flow. A central component to this is the DPI or Deep Packet Inspection Engine. When a flow matches a firewall rule with a Layer 7 context profile applied to it, a few packets for that flow are punted to the DPI engine, which matches these packets against a set of application signatures. When a match is found, the DPI engine programs the APP-ID to Flow mapping information into the in-kernel context-table. When the next packet for this flow comes in, we match the information we have in the context and flow table with the Rule table entries and either deny or allow the flow. All subsequent packets for that flow are processed in kernel, delivering unmatched L7 firewall throughput.

NSX-T Distributed Firewall Architecture with Layer 7 Flow evaluation

In NSX-T, Layer 7 App-ID is configured via Context Profiles, which can then be applied to one or more Distributed Firewall rules. A number of context profiles are built-in to NSX-T for the most common applications and protocol used in data centers. In addition, customers can define custom context profiles based on a specific APP-ID and sub-attributes such as protocol version (for SSL and CIFS) and/or FQDN/URL.

Defining a custom Context Profile

 

FQDN Allowlisting

With FQDN allowlisting, security administrators can define firewall rules that explicitly provide access to a set of URLs or FQDNs. This can be leveraged to micro-segment applications that are accessing external SaaS/Cloud services for which the IP addresses are unknown or subject to change. In addition to application Micro-segmentation FQDN allowlisting can also provide granular SaaS application or web access to users in a VDI environment.

FQDN Allowlisting

 

FQDN allowlisting leverages the same context-aware architecture that is used for Layer 7 App-ID, in which nearly all packets for a flow are processed in kernel. Furthermore we leverage Distributed DNS Snooping to map domain names to IP addresses. Distributed DNS Snooping is unique to the NSX and take advantage of the unique position of the Distributed Firewall – In kernel, and applied to the logical port of every workload – which enables us to learn about every DNS query and response, regardless of whether it’s going to an external or internal DNS server, without requiring any agent.

In NSX-T 2.4, FQDN allowlisting is configured by defining a context profile with one or more pre-canned URLs, and then applying the context profile to a firewall rule. In addition to FQDN,  Layer 7 App-ID can also be defined in the same context profile to limit the types of applications/protocols that can access the specified URL/FQDN.

Identity Firewall for VDI and RDSH

Besides micro-segmenting applications, many of our customers also leverage NSX to protect their VDI infrastructure and Desktops. NSX provides isolation between desktops, granular access to applications for distinct groups of desktops, and micro-segmentation for the VDI infrastructure. With NSX-T 2.4, we further expand on this with E-W Service Insertion and Guest Introspection, allowing customers to insert additional security controls such as IPS/IDS or Agentless Anti-virus into their VDI environment. One other key feature introduced in NSX-T 2.4 is User-based or Identity Firewall (IDFW). With IDFW, customers can create firewall rules based on active directory user groups in order to provide granular per-user access to applications. The Identity Firewall features is based on flow context, and therefore can be applied to both users accessing their apps from VDI Desktops or RDSH sessions. With NSX-T 2.4, IDFW-based rules can also use Layer 7 and/or FQDN context-profiles to provide even more granular per-user control.

NSX-T can retrieve User to Group mapping from Active Directory, allowing users to then configure a Group based on one or more AD-Groups. When firewall rules are configured with an AD-based group as the source, the Security Identifier (SID) of that group is programmed in the dataplane of the Distributed Firewall. When a user logs in to a VDI desktop or RDSH host, VMware tools (thin agent) is used to retrieve the user/group information. The Context-engine which is an NSX  component running on the hypervisor then programs the group SID to flow mapping into the context table. Finally, the information about the flow in the context table is matched against SID-based rules in the firewall rule table and the appropriate action is taken.

Identity Firewall is disabled by default, and can be enabled per cluster and/or for standalone hosts. Active Directory needs to be registered with NSX in order for NSX to retrieve group and user information. Once that is done, security administrators can create a group based on one or more AD-groups. This group can then be used as the source of one or more Distributed Firewall rules.

Creating AD-Based Groups and using them in Distributed Firewall Rules

Update: The COVID-19 pandemic has forced many organizations to shift their business online and many employees to work from home. At the same time, malicious actors are taking advantage of this new reality  by tageting the vunerabilities commonly associated with employees connecting to corporate resources from their home environment. This includes social engineering and phishing campaigns, denial of service attacks, exploiting vulnerabilities in home routers and leveraging VPN access in order to gain access to sometimes poorly segmented assets in the datacenter. Providing employees who are now working from home secure and reliable access to their corporate resources and applications by the use of Virtual Desktop Infrastructure or VDI helps our customers to reduce the impact on productivity and continuity as well as the risk associated with remote access to internal data.  Furthermore, (micro)-segmentation and the adoption of zero trust are key in reducing the attack surface and potential impact of a breach.
I’ve updated this blog to include a few links to some resources that cover how VMware customers can use their existing NSX investment to ensure they can safely adjust and scale up their End-User Compute infrastructure:

Demo

In this 15 minute demo, we are covering how the new Context-aware capabilities in NSX-T 2.4 including Layer 7 App-ID, FQDN allowlisting and Identity Firewall can be leveraged to enable the zero-trust network security model.

NSX-T Resources

To learn more information about NSX-T check out the following resources: