With the launch of VMware NSX in 2013, VMware pioneered micro-segmentation. Back then our solution was based on stateful Layer 4 filtering. We’ve added in dynamic grouping, enabling policies based on VM context such as VM Name, Operating System or Security Tags. Using dynamic grouping, the life cycle of a Service-defined Firewall policy is directly tied to the life cycle of the workloads/application it’s protecting. This is radically different from traditional firewalls which use IP-address based policies.
Another addition to our Service-defined firewall is Layer 7 Application Identity. You may be familiar with the concept from the perspective of a perimeter firewall where it can be used to allow access to Facebook chat but block access to Facebook games. The data center is different and so are the use cases for layer 7 Application Identity.
In this blog I will cover why organizations should use Layer 7 Application Identity in their data center segmentation policies.
What Are the Problems with Port-Based Rules?
While stateful Layer 4 firewalls have significantly reduced both the complexity and security gaps that come with configuring stateless Access Control rules (ACLs), there are still a couple of shortcomings.
No Visibility Into Application Protocol
Layer 4 based rules don’t guarantee that the traffic destined to a port really is using the protocol you want to allow. This means that when you create a Layer 4 rule which allows MYSQL traffic to your Database workloads, you are really allowing ANY traffic coming to port TCP/3036 to those database workloads, regardless if it’s actually a MYSQL service listening to that port or another service. An attacker can take advantage of this by running a service on that port and tunnel through traffic across the firewall. Similarly, a Layer 4 rule allowing your users or applications HTTP access to the internet also allows those users and applications to connect to any service on the internet, as long as it runs on port 80. A malicious actor may be able to exploit this by using this allowed connection in order to establish a reverse shell or in order to exfiltrate data.
As a Layer 4 firewall has no visibility into what application is running and generating traffic, it also can’t differentiate between protocol versions. To a Layer 4 firewall, there is no difference between HTTPS SSLv3, HTTPS TLSv1.2 or even SMB traffic coming on port 80. As a result, application servers running vulnerable services can be exploited as a Layer 4 firewall is not able to block the usage of an unsecure protocol.
No Support for Dynamic Protocols
Another problem with Layer 4 rules is that some applications are dynamic in nature and dynamically open ports used for data transfer. FTP and RPC are examples of this. With these protocols, once the initial “control” connection from the client to the server has been established, the server will use that connection to inform the client which randomly assigned ephemeral/dynamic port it should establish a secondary “data” connection to, and the client then connects to the server on that specified port. With traditional firewalls you need to create a rule allowing traffic on all ephemeral ports (49152 to 65535) to the server. This poses a risk as there are a myriad of services that could be running on any of these ports.
Use Layer 7 Application Identity with VMware NSX
Service Options in Firewall Rules
VMware NSX supports a broad range of options for specifying what services should be allowed in each firewall rule. L2 service objects include protocols like IPv6 or ARP and enable administrators to block the use of any of these Layer 2 protocols. The same can be done for Layer 3 protocols like GRE. Most firewall rules leverage Layer 4 objects, which are a combination of transport layer protocol and port. As an example, the NTP L4 Service Object matches UDP traffic destined to port 123. Beyond these static services, NSX supports Application Level Gateways (ALGs) and Layer 7 context profiles.
Application Level Gateways
Application Level Gateways (ALGs) dynamically allow connections through the firewall for protocols that open additional ephemeral ports. This alleviates the need for additional firewall rules that allow traffic to come in on all ephemeral ports to the server. NSX-T has built-in ALGs for the most used dynamic protocols, including FTP, RPC and Oracle. These ALG service objects are available for use on the distributed and gateway firewall. When a rule is configured using an ALG service object, the firewall will monitor the control connection and dynamically allow additional connections based on the data port specified in the exchange between server and client.
Layer 7 Application Identity
While traditional Layer 4 objects match the port specified in the TCP/UDP header of a flow, Layer 7 objects are port-independent and instead use signatures to match content in the payload of a flow. This allows a firewall to distinct for instance HTTP from MYSQL traffic, even if both services run on port 80. NSX-T comes with a set of Layer 7 context profiles. These map with the services customers commonly run within the data center and enable port-independent enforcement. These can be used on the distributed firewall (DFW) and the Tier-1 gateway firewall (GFW). Layer 7 context-profiles can be used in combination with a static L4 port-based service object, in combination with an ALG dynamic port-based service object or by itself for port-independent enforcement. Just a handful of packets are required for the NSX firewalls to fingerprint the APP-ID a flow is generated to/from, which means there is no throughput penalty for enabling this functionality.
Where to Use Layer 7 Application Identity
Shared Infrastructure Services
Organizations often have a set of infrastructure services which are shared between tenants and/or zones. A small set of static firewall rules are typically used to enable access to these shared services. Creating the shared service access rules is often one of the first steps our customers take as they operationalize NSX for micro-segmentation. Unlike the internet perimeter, where a firewall needs to be able to distinct several thousand (micro-)applications and SaaS, only a handful of well-known services/applications typically exist as part of the shared infrastructure. These typically include DNS and DHCP servers, Active directory, NTP, Logging and Storage or Backup servers. NSX has built-in Layer 7 support for the infrastructure services most enterprises run. Using Layer 7 Application in shared services rules helps reducing the attack surface by ensuring attackers cannot use open firewall ports to run covert servers or exploit weaknesses in vulnerable versions of protocols. As these infrastructure servers provide services to a large part of the enterprise, reducing the attack surface to the minimum is crucial not only to protect the shared services segment, but also to protect other enterprise application that utilize these shared services
Insecure Protocols and Meeting Compliance
Exploitable vulnerabilities exist within SSL and early versions of TLS. POODLE and BEAST are man-in the-middle exploits against 3.0 and TLS 1.0 respectively, which resulted in organizations moving their web servers to TLS 1.1 and above. In April 2015, the Payment Card Industry Security Standards Council removed SSL from the PCI Security Standard (PCI DSS , and organizations had to implement TLS 1.1/1.2 in order to remain compliant. NSX can distinct between different versions of SSL/TLS, allowing security teams to get visibility into, and enforce the use of specific version of the protocol throughout the organization even if application owners would inadvertently spin up a server accepting client-initiated downgrades to non-complaint versions of the protocol. By using tags, workloads that need to meet compliance can be marked, and a specific set of rules required for compliance can be applied to only those workloads. NSX also allows administrators to enforce the use of secure cipher suites with TLS. This further reduces the potential for attack by blocking the use of certain vulnerable legacy algorithms that are supported in TLS 1.0 – 1.2.
Micro-segmenting N-tier Applications
Most enterprise applications today are not monolithic but are a multi-tier network of clients and services, consisting of several workloads that perform distinct functions. These functions or tiers can generally be classified as presentation, application logic and data tiers. There is a finite list of Layer 7 protocols commonly used for each of these tiers. Users generally access the presentation tier of application tier through a browser over HTTP or HTTPS. This presentation layer then interacts with the application logic or middleware which generates and processes dynamic content and running services such as ASP.net, Spring or Node.js. HTTP/HTTPS is commonly used for the presentation layer to access the application logic. The middleware servers in turn access and manipulate data on back-end datastores which are accessed through one of a few common database protocols; such as Orcable, MySQL, MSSQL or SAP MaxDB. NSX has built-in Layer 7 context-profiles for the applications/protocols that are enterprises typically run on each tier of multi-tier applications. This include HTTP and various version of SSL/’TLS as well as a broad array of database protocols including all of the ones listed above.
Customers should use Layer 7 context-profiles in their intra-application micro-segmentation policies along with L4 services objects to reduce the attack surface by ensuring the protocol traveling across the open firewall port is indeed the intended protocol. In addition, by writing firewall policies that are Layer-based instead of port-based, the appropriate set of firewall rules for new applications that are being rolled out can be determined quicker; for instance, a single firewall rule can be used to allow MySQL across any port coming into an MySQL server, regardless of what port the application developers decided to run that service on.
