This document covers how one can create security policy rules in VMware NSX. This will cover the different options of configuring security rules either through the Distributed Firewall or via the Service Composer User Interface. It will cover all the unique options NSX offers to create dynamic policies based on the infrastructure context.

VMware NSX Distributed Firewall (DFW) provides the capability to enforce firewalling functionality directly at the Virtual Machines (VM) vNIC layer. It is a core component of the micro-segmentation security model where east-west traffic can now be inspected at near line rate processing, preventing any lateral move type of attack.

This technical brief gives details about DFW policy rule configuration with NSX. Both DFW security policy objects and DFW consumption model will be discussed in this document.

We assume reader has already some knowledge on DFW and Service Composer functions. Please refer to the appropriate collateral if you need more information on these NSX components.

Distributed Firewall Object Grouping Model

NSX provides the capability to micro-segment your SDDC to provide an effective security posture. To implement micro-segmentation in your SDDC, NSX provides you various ways of grouping VMs and applying security policies to them. This document specifies in detail different ways groupings can be done and details on when you should use one over the other.
Security policy rules can be written in various ways as shown below:

Network Based Policies:

This is the traditional approach of grouping based on L2 or L3 elements. Grouping can be based on MAC addresses or IP addresses or a combination of both. NSX supports this approach of grouping objects. The security team needs to aware of networking infrastructure to deploy network-based policies. There is a high probability of security rule sprawl as grouping based on dynamic attributes is not used. This method of grouping works great if you are migrating existing rules from a different vendor’s firewall.

When not to use this: In dynamic environments, e.g. Self-Service IT; Cloud automated deployments, where you are adding/deleting of VMs and application topologies at a rapid rate, MAC addressed based grouping approach may not be suitable as there will be delay between provisioning a VM and adding the MAC addresses to the group. If you have an environment with high mobility like vMotion and HA, L3/IP based grouping approaches may not be adequate either.

Infrastructure Based Policies:

In this approach, grouping is based on SDDC infrastructure like vCenter clusters, logical switches, distributed port groups, etc. An example of this would be, clusters 1 to cluster 4
are earmarked for PCI kind of applications. In such a case, grouping can be done based on cluster names and rules can be enforced based on these groups. Another example would be, if you know which logical switches in your environment are connected to which applications. E.g. App Tier Logical switch contains all VMs pertaining to application ‘X’. The security team needs to work closely with the vCenter administration team to understand logical and physical boundaries.

When not to use this: If there are no physical or logical boundaries in your SDDC environment then this type of approach is not suitable. Also, you need to be very careful where you can deploy your applications. For example, if you would like to deploy a PCI workload to any cluster that has adequate compute resources available; the security posture cannot be tied to a cluster but should move with the application.

Application Based Policies:

In this approach, grouping is based on the application type (e.g: VMs tagged as “Web_Servers”), application environment (e.g: all resources tagged as “Production_Zone”) and application security posture. The advantage of this approach is that the security posture of the application is not tied down to either network constructs or SDDC infrastructure. Security policies can move with the application irrespective of network or infrastructure boundaries. Policies can be templated and reusable across instances of same types of applications and workloads. You can use variety of mechanisms to group. The security team needs to be aware of only the application that it is trying to secure based on the policies. The security policies follow the application life cycle, i.e. comes alive when the application is deployed and is destroyed when the application is decommissioned.

When not to use this: If the environment is pretty static without mobility and infrastructure functions are properly demarcated. You do not need to use application-based policies.

Application-based policy approach will greatly aid in moving towards a Self-Service IT model. The Security team needs to be only aware of how to secure an application without knowing the underlying topology. Concise and reusable security rules will require application awareness. Thus a proper security posture can be developed via application based policies.

NSX Security-Groups

Security-Groups is a container-construct which allows to group vCenter objects into a common entity.
When defining a Security-Groups, multiple inclusion and exclusion can be used as shown in the diagram below:

This document guides you through the step-by-step configuration and validation of NSX-v for microsegmentation services. Microsegmentation makes the data center network more secure by isolating each related group of virtual machines onto a distinct logical network segment, allowing the administrator to firewall traffic traveling from one segment of the data center to another (east-west traffic). This limits attackers’ ability to move laterally in the data center.

VMware NSX uniquely makes microsegmentation scalable, operationally feasible, and cost-effective. This security service provided to applications is now agnostic to virtual network topology. The security configurations we explain in this document can be used to secure traffic among VMs on different L2 broadcast domains or to secure traffic within a L2 broadcast domain.

Microsegmentation is powered by the Distributed Firewall (DFW) component of NSX. DFW operates at the ESXi hypervisor kernel layer and processes packets at near line-rate speed. Each VM has its own firewall rules and context. Workload mobility (vMotion) is fully supported with DFW, and active connections remain intact during the move.

This paper will guide you through two microsegmentation use cases and highlight steps to implement
them in your own environment.

Use Case and Solution Scenarios

This document presents two solution scenarios that use east-west firewalling to handle the use case of
securing network traffic inside the data center. The solution scenarios are:

Scenario 1: Microsegmentation for a three-tier application using three different layer-2 logical segments (here implemented using NSX logical switches connected over VXLAN tunnels):

Figure 1 – Scenario 1 Logical View.

In Scenario 1, there are two VMs per tier, and each tier hosts a dedicated function (WEB / APP / DB
services). Traffic protection is provided within the tier and between tiers. Logical switches are used to
group VMs of same function together.

Scenario 2: Microsegmentation for a three-tier application using a single layer-2 logical segment:

Figure 2 – Scenario 2 Logical View.

In Scenario 2, all VMs are located on same tier. Traffic protection is provided within tier and per function (WEB/ APP/ DB services). Security Groups (SG) are used to logically group VMs of same function together.

For both Scenario 1 and Scenario 2, the following security policies are enforced:

Security Policy

For Scenario 1, a logical switch object is used for source and destination fields. For Scenario 2, a Service Composer / Security Group object is used for source and destination fields. By using these vCenterdefined objects, we optimize the number of needed firewall rules irrespective of number of VMs per tier (or per function).

NOTE: TCP port 1433 simulates the SQL service.

Physical Topology

Figure 3 – Physical Topology.

Two ESXi hosts in the same cluster are used. Each host has following connectivity to the physical
network:

one VLAN for management, vMotion, and storage. Communication between the ESXi host and the NSX Controllers also travels over this VLAN.

The purpose of this implementation is to demonstrate complete decoupling of the physical infrastructure from the logical functions such as logical network segments, logical distributed routing and DFW.
In other words, microsegmentation is a logical service offered to an application infrastructure irrespective of physical component. There is no dependency on where each VM is physically located.

This article provides information on configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.0 environment. It helps you eliminate common causes for problems during certificate implementation, including configuration steps and details, and avoid common misconfigurations in the implementation of custom certificates in your environment.

Configuring CA signed certificates is a challenge with vSphere as with any complex enterprise environment. Securing an environment is a requirement in many large organizations. You need public certificates (such as Verisign, enterprise certificates, Microsoft CA, or OpenSSL CA) to ensure a secure communication. This article provides steps to allow configuration of these certificates on vSphere components in an environment.

Please validate each step below. Each step provides instructions or a link to a document that provides information on configuring the certificates in your environment.

Note: You do not need to follow all the steps. However, it is recommended that certificates are replaced for all components in a vSphere environment.

Configuring vCenter Server 5.0 certificates should be the first step in a deployment. In a new installation, it also reduces the amount of overhead required for implementation because hosts need not be reconnected to vCenter Server. In an existing configuration, ESXi hosts must be reconnected after configuring the certificate because the password used to connect to vCenter Server is encrypted with the certificate. At this point, vCenter Server should be installed and configured appropriately and all functions (such as, Web services including Hardware Status) should be functional. If they are not working before the configuration of the certificates, they will not work later. For more information, see Configuring CA signed certificates for VMware vCenter Server 5.0 (2015421).

File a support request with VMware Support, include the gathered information, and note this Knowledge Base article ID (2015383) in the problem description. For more information, see How to Submit a Support Request .

Rating: 5/5

This article provides information on manually configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.1 or vSphere 5.5 environment. VMware has released a tool to automate much of the described process below. Please see Deploying and using the SSL Certificate Automation Tool 1.0.x (2041600) before following the steps in the article.

In the case that you are unable to use the tool this article helps you eliminate common causes for problems during certificate implementation, including configuration steps and details, and helps avoid common misconfigurations in the implementation of custom certificates in your environment.

Configuring CA signed certificates is a challenge with vSphere as with any complex enterprise environment. Securing an environment is a requirement in many large organizations. You need either public certificates (such as Verisign or Globaltrust), Microsoft CA certificates, or OpenSSL CA certificates to ensure a secure communication.

This article provides steps to allow configuration of these certificates on vSphere components in an environment. The article also assumes that all components are installed and running already with self-signed certificates.

Please validate each step below. Each step provides instructions or a link to a document that provides information on configuring the certificates in your environment.