VMware NSX provides an integrated Distributed Firewall (DFW), which offers L2-L4 security at the vNIC level and protects East-West traffic, and an Edge Firewall provided by the Edge Services Gateway (ESG), which offers L2-L4 security at the edge and protects North-South traffic in and out of the Software-Defined Data Center (SDDC).
Figure 1: VMware NSX DFW and Edge Firewall Logical Design Example
The DFW is a kernel-level module and allows for enhanced segmentation and security across a virtualized environment. DFW enables a distributed security architecture allowing for micro-segmentation.
In addition to the DFW and ESG Firewall, there are many third party integrations with well-known security partners such as Check Point and Palo Alto Networks. In this blog, we’ll focus on the Check Point vSEC solution for NSX; some of this content I also posted prior on several posts on my personal blog. For a complete list of security partner solutions and more information, see the supported NSX third party security products on the VMware NSX Technical Partners Webpage.
For this blog, the following VMware and Check Point components and corresponding versions are used:
- VMware vSphere 5.5
- VMware vCenter 5.5
- VMware NSX 6.1.4
- Check Point Management Server R77.30
- Check Point SmartConsole R77.30
- Check Point vSEC Controller R77.30
- Check Point vSEC Security Gateway R77.20
Third party security solutions integrating into NSX such as Check Point vSEC go beyond the basic L2-L4 firewall capabilities provided by DFW and can provide additional L5-L7 support. Check Point, for instance, allows IPS/IDS, Application Control, URL Filtering, Identity Awareness, Anti-Virus, Anti-Bot, and Threat Emulation. You can find more details about the Check Point vSEC solution on the Check Point website.
The Check Point vSEC solution, similar to some other third party security solutions integrating with NSX, deploys a Service VM (SVM) on every hypervisor and leverages the NetX API for traffic redirection and inspection. In Check Point’s case, the SVM is called vSEC Gateway. The VMware Service Insertion Platform allows for NetX API communication between a third party service running in user space and respective VMware/NSX security/networking modules in the ESXi kernel.
Check Point also has hardware appliance offerings. The Check Point SmartConsole management utility can manage both the physical and virtual Check Point gateways/appliances as shown in the below diagram. The vSEC Controller sits on the Check Point Management Server and connects to both NSX Manager and vCenter to learn about the virtual environment. Learned virtual objects such as Security Groups or VMs can then be used in security policies defined via the SmartConsole management client and installed on the vSEC Gateways (SVMs) on each respective ESXi host.
Figure 2: Check Point SmartConsole Managing Virtual and Physical Gateways/Appliances
The DFW function is activated when a user uses NSX Manager plugin from within vSphere Web Client to prep selected hosts for DFW as shown below in Figure 3. Here, the firewall has been configured on all clusters.
Figure 3: DFW Enabled on All Clusters in NSX
When a host is prepared, a kernel module (VIB) known as the VMware Service Insertion Platform (VSIP) is installed on the respective hypervisor. There are several slots available on the VSIP and DFW occupies slot 2. Third party vendor solutions plug into the VSIP via the first available free slot. The VSIP is in kernel space and a secure channel called the VMCI is used to redirect traffic via NetX API to the third party SVM appliance. As shown below, the vSEC Gateway resides on each ESXi host being protected.
Figure 4: Check Point vSEC Gateway Installed on Each ESXi Host in NSX Environment
Security policies can then be configured in NSX via Service Composer to redirect specific desired traffic to the third party security service, in this case the Check Point vSEC Gateway. An example of a security policy to redirect all traffic to the Check Point vSEC Gateway is shown below in Figure 5.
Figure 5: Configuring Network Introspection Services in NSX
In Figure 6, the created security policy is applied to a specific Security Group identifying all Test VMs in the environment.
Figure 6: Applying Created Security Policy to ‘All_Test_VMs’ Security Group in NSX
Once desired traffic is being redirected to the Check Point vSEC gateway, the respective third party management policy configuration tool can be used to enable, configure and apply advanced security.
The below screen shot shows a policy being configured in the Check Point SmartConsole (prior called SmartDashboard) to block all access to Facebook for nodes being protected by the vSEC Gateways in the vSEC_Compute_Cluster vSEC Gateway Cluster. Note how granular the access restriction can be. One can even just block specific access to a particular feature or activity on Facebook without blocking the entire site. In this case, the actual traffic is being inspected to identify the correlating activity.
Figure 7: Application and URL Filtering in Check Point SmartConsole
Figure 8 below shows another example of a search done on the word ping while under the IPS tab. Specific attack signatures are already known and security measures/protections enabled by default when the IPS software blade is enabled.
Figure 8: IPS in Check Point SmartConsole
One can also edit the default action of a protection if desired as shown below where the action and corresponding ping size for the Max Ping Size protection is modified.
Figure 9: Overriding Default IPS policy for ‘Max Ping Size’ Protection in Check Point SmartConsole
To see a quick six minute overview of traffic redirection using VMware NSX Service Composer, Check Point vSEC deployment, and an example of URL Filtering and Application Identification see the above video.
Humair
Comments
0 Comments have been added so far