Before jumping to NSX-T Distributed Firewall (DFW) concept and rule creation, I want to point out why this solution is important and what security issues can be addressed by using this powerful solution. Building a zero trust model security has been the biggest concern of network and security teams. In traditional data centers, high-level segmentation is built, which could help to prevent various types of the workload from communicating. But the main challenge of the legacy security model is data centers facing a lack of lateral prevention communication system between workloads within a tier. In other words, traffic can traverse freely inside a network segment and access the crucial information until it reaches the physical firewall to get dropped. In addition, implementing different layers of security and firewalls would cause complexity and cost.
NSX-T Distributed Firewall (DFW) is a hypervisor kernel-based firewall that monitors all the East-West traffic and could be applied to individual workloads like VM and enforce zero-Trust security model. Micro-segmentation logically divides department or set of applications into security segments and distribute firewalls to each VM.
The main advantages of leveraging DFW are an orchestration of policies with security groups or tags, horizontal movement reduction in data centers to minimize the risk of security breaches, and finally, reduction of capital expenditure(CAPEX) cost. Furthermore, NSX-T DFW not only can operate based on layer 2 to layer 4, but it can leverage layer seven information. In another blog post, I explain how to use context-awareness to filter traffic based on URL and FQDN.
NSX-T DFW has different predefined categories :
Ethernet – Layer 2 policies are the first line of defense and will be considered before layer three rules.
Emergency – Temporary firewall rules for emergency occasions.
Infrastructure – Non-application firewall rules like vCenter, ESXi, DNS, Active directory, and so on.
Environment – High-level policy groupings like eliminating communication of test and production environment.
Application – Application policy rules between tiers.
The priority to apply rules is from top-down and left to right. Meaning, if you write a rule in Infrastructure, it has priority over a rule in Application. So, you need to place the most fundamental rules on top of the list.
To apply distributed firewall rules, you need to create a policy section that collects firewall rules. Then you need to create a Rule that contains guidance to allow/drop the traffic. To determine the source and destination of the rule security group containing static (Members /IP address) or dynamic objects (criteria) will be created. Services determine what port/protocol to use in the rule, and based on that, traffic will be allowed or dropped. Context profile will be used for layer seven application content (URL/FQDN) filtering. Applied to, specifies the rule’s scope to apply at which level it could be at DFW level or security group. Lastly, Rule Action has three different modes of Allow, Drop, and Reject to determine the rule’s action.
In the next article, I will show you how to create a security group, policy, and rules.