Use NSX firewall best practices to improve security

NSX-T distributed firewall best practices

Trust nothing

The first best practice you should adopt once you implement the NSX-T DFW is the trust-nothing approach, also commonly called the zero-trust approach. Traditionally, firewalls at the network edge didn't control traffic between VMs in the data center, but VMware's virtual firewall can. The NSX-T DFW automatically allows all traffic, which is how the network normally behaves without microsegmentation. Figure 1 shows the default Layer 3 rule -- rule ID 2 -- that allows all traffic.

But to allow all traffic by default is not a best practice. VMware recommends it because, otherwise, NSX-T blocks all traffic for applications once you install it. You should configure the DFW and drop the default allow-all rule for safer operation.

To mitigate any security risks, first, investigate what traffic the system should allow. Then, create firewall rules.

As a best practice, ensure that management components, such as vCenter Server Appliance, aren't blocked by the DFW. One approach is to run these VMs in a management cluster that isn't configured for NSX-T. In that setup, network virtualization and the DFW can't impact those management VMs.

Still, this approach leaves those management VMs unprotected. You can instead run these VMs in a protected cluster. Add them to the DFW's exclusion list so that they won't become unavailable when the DFW blocks traffic. When you finish creating firewall rules, even just for the vCenter management server, then you can remove the protected VMs from the exclusion list.

Inspect and control traffic with VMware's tool

Another best practice is to use the NSX Intelligence feature available with the NSX-T Enterprise Plus license. To protect VMs, you must determine which ports and protocols they use. The NSX Intelligence feature inspects all traffic and creates designated firewall rules for that traffic.

Figure 2 shows a subset of VMs and the connections between them in separate network segments. The green line between VMs identifies traffic already allowed by a firewall rule. The dashed red line shows traffic that's not yet protected.

NSX Intelligence offers traffic recommendations, which provide an overview of all discovered traffic that you can create firewall rules for. As an administrator, identify which firewall rules NSX-T should create to allow traffic, and remove those rules from the unwanted traffic recommendations.

It isn't necessary to drop or reject those rules because, once you create the allow rules, you should enable NSX-T to block all other traffic by default.

Group VMs efficiently

NSX Intelligence also recommends groups that can put together VMs that communicate with each other. NSX-T uses these groups for the Sources and Destinations fields of the DFW. They are also important to the Applied To field.

The Applied To field keeps firewall rule processing efficient. By default, the Applied To field refers to the entire DFW. If you check the Applied To field on any rule, the DFW applies that rule to all VMs in the inventory. The DFW will also place the rule on VMs that aren't a source or destination for the rule itself. For example, if you create 1,000 firewall rules with the Applied To field enabled on each rule, the DFW must then process 1,000 rules for every VM -- even if the rules affect only two VMs.

You can create a group with those two VMs and then enable the Applied To field only for that group. This ensures the DFW only places the firewall rules on those two VMs in the group, rather than on the entire VM inventory. You can also use that group for the Sources and Destinations fields. Figure 3 shows a set of rules where the DFW uses a group for application servers in the Applied To field.

You can create groups with several criteria, such as VM names and tags. When a VM name contains the keyword web, the VM becomes a member of the web servers group, for example. Tags label VMs and classify them into groups as well. You can use tags in combination with automation software, such as vRealize Automation, to classify new VMs deployed through that software. The VMs will automatically belong to the right groups and receive the applicable firewall rules.

RBAC

The last NSX firewall best practice is to configure RBAC. NSX-T can integrate with Microsoft Active Directory (AD) or VMware Workspace One Access -- formerly known as Identity Manager -- to work with groups and users from both AD and Workspace One. NSX-T can also use those groups and users to assign roles to AD or Workspace One.

Unlike other VMware products, NSX-T isn't able to create specific roles with privileges. Use the built-in roles to have RBAC. For the DFW, those roles are Security Operator and Security Admin. Figure 4 shows the Security Operator and Security Admin roles, which NSX-T can assign to a group or user that originates from AD.

The NSX-T documentation contains an overview of the exact features available for each permission, such as full access, execute, read and none, for these roles. Security Admin -- formerly known as Security Engineer in NSX-T Data Center 3.0 -- has full configuration access to the security-related features. Security Operator has read-only access to NSX-T but is able to use the troubleshooting tools to analyze the software.