VMware NSX and Comprehensive Security for the SDDC


I’ve written several prior articles on the VMware NSX network virtualization platform as it relates to security. NSX offers such a robust platform for security, I sometimes come across folks interested in NSX yet not aware of the full potential of NSX in terms of security. I hope to provide some additional insight in this short blog.


VMware NSX comes integrated with the Distributed Firewall (DFW), which offers L2-L4 security at the vNIC level and protects East-West traffic, and the Edge Firewall provided by the Edge Services Gateway, which offers L2-L4 security at the edge and protects North-South traffic in and out of the Software Defined Data Center (SDDC). I described both of these in a prior blogs, Firewalling & Micro-segmentation with VMware NSX and VMware NSX Service Composer: Advanced Security & 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. For a complete list of security partner solutions and more information, see the supported NSX third party security products on the VMware NSX Technology Partners webpage.


In a recent blog, VMware NSX: Advanced Security Services with Check Point vSEC, I also discussed VMware NSX integration with the well known security vendor Check Point. In that blog, I discussed how 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. In this post, I’ll provide some more detail on some of the third party integration capabilities by using Check Point vSEC to as an example


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. Here, the firewall has been configured on all clusters.

VMware NSX - Host Preperation

VMware NSX - Host Preperation


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 will 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 to a third party appliance known as the Service VM (SVM) via NetX API. In Check Point’s case, this SVM is the vSEC Gateway. As shown below, the vSEC Gateway resides on each ESXi host being protected.

VMware NSX - Logical Diagram with DFW and Check Point vSEC

VMware NSX - Logical Diagram with DFW and Check Point vSEC


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.

VMware NSX: Security Policy to Redirect Traffic to Check Point vSEC Gateway

VMware NSX: Security Policy to Redirect Traffic to Check Point vSEC Gateway


Below, I apply this security policy to a specific Security Group identifying all Test VMs in the environment.

VMware NSX: Applying Security Policy to "All_Test_VMs" Security Group

VMware NSX: Applying Security Policy to "All_Test_VMs" Security Group


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. As I mentioned in my prior blog, Check Point vSEC supports 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 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 block just 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.

Check Point SmartConsole: Creating a Security Policy to Block Access to Facebook

Check Point SmartConsole: Creating a Security Policy to Block Access to Facebook


Below shows another example of a search done on the word ping while under the IPS tab. Specific known attack signatures are already known and security measures/protections enabled by default when the IPS software blade is enabled.

Check Point SmartConsole: Searching for Known "ping" Attacks in IPS Database

Check Point SmartConsole: Searching for Known "ping" Attacks in IPS Database


However, one can edit a default action if desired as shown below where the action and corresponding ping size can be modified.

Check Point SmartConsole: Editing the Default Settings for an IPS Protection Rule

Check Point SmartConsole: Editing the Default Settings for an IPS Protection Rule


To see a quick six minute overview of traffic redirection using Service Composer, Check Point vSEC deployment, and an example of URL Filtering and Application Identification see the below embedded video from the VMware NSX YouTube Channel.



Twitt

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Leave a Reply

*


nine − = 2