This is part 11 of 20+ blogs I am writing covering the exam prep guide for the VMware Certified Advanced Professional 6 – Network Virtualisation Deployment (3V0-643)  VCAP6-NV certification.

At the time of writing there is no VCAP Design exam stream, thus you’re automatically granted the new VMware Certified Implementation Expert 6 – Network Virtualisation (VCIX6-NV) certification by successfully passing the VCAP6-NV Deploy exam.

Previous blogs in this series:

Part 1 – Intro
Part 2 – Objective 1.1
Part 3 – Objective 1.2
Part 4 – Objective 1.3
Part 5 – Objective 2.1
Part 6 – Objective 2.2
Part 7 – Objective 2.3
Part 8 – Objective 3.1
Part 9A – Objective 3.2 IPSec VPNs
Part 9B – Objective 3.2 SSL VPNs
Part 9C – Objective 3.2 L2 VPNs
Part 10 – Objective 3.3

This blogs covers:

Section 4 – Secure a vSphere Data Center with VMware NSX
Objective 4.1 – Configure and Manage Logical Firewall Services

• Configure Edge and Distributed Firewall rules according to a deployment plan:
  • Create/configure Firewall rule sections for specific departments
  • Create/configure Identity-based firewall (IDFW) for specific users/groups
• Configure SpoofGuard policies to enhance security
• Filter firewall rules to narrow a scope

 

NSX Logical Firewall High-Level Overview

VMware NSX provides two types of logical firewalls.

1. The Edge Firewall functions at the perimeter of the software-defined data center (SDDC) to allow or deny North-South bound traffic, deployed and configured on an Edge Services Gateway (ESG). The ESG can be deployed as a VM to enable high-availability, thus the Edge Firewall is also highly-available.
2. The Distributed Firewall functions inside the software-defined data center (SDDC) to allow or deny East-West bound traffic. The Distributed Firewall is embedded in the ESXi host kernel. The distributed nature of being embedded in the kernel of every firewall enabled cluster member makes the Distributed Firewall highly available.

You can deploy these firewalls independent of each other or together depending on requirements.

Edge Firewall

As mentioned above the Edge Firewall functions at the perimeter of your SDDC. This might be for your own corporate NSX deployment or as a cloud consumer as a tenant if your service provider is utilising VMware vCloud Director and NSX.

The Edge Firewall is configured on the Edge Services Gateway (ESG). The Edge Firewall by default blocks all incoming (south-bound) traffic. It processes Layer 3 traffic only.

Screen shot below of Edge Firewall on an ESG.

Distributed Firewall

I attended VMworld 2015 in San Francisco and saw Martin Casado present the keynote on NSX and also a presentation by Bruce Davie for a vChampion breakfast in Sydney. I was sold! This is what kicked off my interest in NSX and why I did my VCP-NV and now working towards VCAP6-NV/VCIX6-NV. Micro-segmentation is the shizzle and it’s the DFW gives you that functionality.

The Distributed Firewall (DFW) is enabled by default and embedded in the vSphere ESXi host kernel when you run the cluster-level Host Preparation option. This deploys the NSX kernel modules and enables the DFW feature.

So think about this for a second;  as the DFW is embedded in the host kernel, you can block traffic between two VMs, on the same host, on the same or different L2 or L3 network segments. In VDI deployments where you may have /21 subnets with 2000 odd VDIs this micro-segmentation is a massive feature.

Think about this also. You put servers in a DMZ for a reason, but if a server in the DMZ gets hacked they can then launch other attacks east-west to other servers in the DMZ, with DFW you can micro-segment all of these servers and deny all east-west traffic in that zone apart from legitimate traffic. Can you imagine trying to do this stuff with physical firewalls.

There are a heap of cool features that the DFW offers and I cannot list them all, but the last one I want to mention is what happens when you vMotion a VM – the DFW rules follow it, and you delete that VM and if the rules are based on dynamic membership the firewall rules are deleted also. Rule sprawl no-more.

By default, the DFW configures an allow/any rule. Make sure before you change this rule to a default deny/any rule that you exclude the vCenter Server and NSX Manager from the firewall. See blog 2 for excluding VMs from the DFW.

VMware says that the DFW as it’s embedded in the hypervisor kernel that it delivers close to line rate throughput, so if your host has 10Gb of bandwidth you have near 10Gb/s of firewall capacity, add another host to the cluster and you now have 20Gb/s. It scales out automatically. All the hosts collectively function as one firewall. Awesome!

Lastly, the DFW allows you to create either L2 or L3 (or both) firewall rules. The traffic passes though these rule sets as it traverses the up and down the OSI stack.

Here is a picture of the L3 section of the DFW, note where you get to this, it’s via the Firewall section on the left-hand-side.

 

Configure Edge and Distributed Firewall rules according to a deployment plan

Well, it’s a VCAP exam so no doubt VMware will be giving us a design we will need to implement. We just need to make sure we know how to configure this stuff and all the options. Make sure you read the Edge Firewall and DFW bits in the NSX 6.2 Administration Guide and some of the VMware NSX Blogs.

Firewall rules are processed from the top down.

Create/Configure Firewall Rule Sections for Specific Departments

OK, remember this simple thing: you can only create sections on the Distributed Firewall. Sections keep DFW rules separate. So you might have rules for IT and rules for HR for example. You can create multiple sections for L2 or L3 rules.

One important thing to note re: Cross-vCenter NSX deployments: There can only be one universal L2 and one universal L3 section and they MUST be managed by the primary NSX Manager. Rules outside of the universal sections are only local to their respective NSX Manager.

To Create a DFW Firewall Rules Section

Pre-Reqs: Choose the NSX Manager you need to add the Rules Section on. Read the full pre-reqs here.

Click Firewall on the left-hand-side of the screen. 

Determine if you’re adding the section for L2 or L3, click the appropriate option. For my example below I have selected L3 Rules.

Click the yellow folder icon  to Add a Section.

Enter the unique name for the Section. If you have a cross-vCenter NSX deployment you will also have a tick box to make the section Universal.

Click Publish Changes to enable the configuration. Note the new section below.

You can see now that I have added a section for HR and IT.

And if I expand each section you can see some basic rule sets I created.

Allow incoming HTTP to a web server tier that contains the HR web server, and allowing the IT department to SSH everywhere. All other traffic is blocked. This is just a basic example. In production I would lock it down more.

We will probably be asked to create sections and create rules for the sections.

DFW Deleting Sections

You can delete sections and all rules that the section contains.

Simply find your section and click the red  to delete.

Click Publish Changes to enable the configuration.

DFW Merging Sections

Merging consolidates the rules from two sections into one.

You cannot merge the default section with anything.

Find the section to be merged and click the green  to merge.

You will be asked if you want to merge with the rule above or below.

Click Publish Changes to enable the configuration.

Create/Configure Identity-Based Firewall (IDFW) for specific users/groups

Again, you can only create Identity-Based rules on the Distributed Firewall.

When thinking Identity Based Firewall Rules think Active Directory users and groups!

For this feature to work you need vSphere, NSX and Active Directory. You also either need to utilise AD Log scraping or Guest Introspection to identify where users are logging in from.

IDFW are firewall rules based on Active Directory (AD) users or groups. NSX determines where the user is logged into and maps the login to an IP address, which is then used by the DFW to apply the firewall rules.

This feature is only supported on Windows 7 operating systems and above and AD Windows Servers 2008 and above.

Before NSX can consume user and groups and apply DFW rules there are three things that must be configured.

1.  The clusters must be prepared (see blog 3).
2. NSX must have a connection to the AD Domain.
3. NSX needs to be able to determine where the user is logged in. It can determine this by either using the VMware Tools Guest Introspection (full VMware Tools install), or by configuring AD Event Log access where it scrapes the logs, or both.

Once all of the above is in-place then you can create some NSX Security Groups and add AD Groups to them. Then you can create some Security Policies with firewall rules.

If all is working as expected when a user logs in this event is detected along with the IP address, the Security Policy is then applied to the user. The crazy bit here is this feature is supported on both virtual and physical Windows machines (physical will require the event log configuration obviously).

Lets roll through configuring this all and test run some tests to confirm its working.

Prepare Clusters/Enable Distributed Firewall

Note: My clusters are already prepared. Check to make sure the Distributed Firewall is enabled. If not, click the blue cog and select Enable Firewall.

 

Connect NSX Manager to an Active Directory Domain

You can register one or more AD Domains with NSX Manager.

Log into the vSphere Web Client.

Click Networking and Security.

Click NSX Managers on the left-hand-side.

Select the NSX Manager, then click Manage, followed by Domains.

Click the green + sign to Add a Domain.

Enter the Domain Name, enter the NetBIOS Name.

Enter the AD Domain Controller IP address. Select either LDAP or LDAPS.

The username and password must have read access to AD. You would probably use a service account.

The next section is optional. This configures the Event Log access. I am going to configure this. You can choose between CIFS or WMI, the default is CIFS.

The configuration is complete.

You can see the AD Domain configured.

Synchronise NSX Manager with Active Directory

You now have the connection to AD configured. By default it will synchronise every 3 hours. You can force a sync.

Click the AD Domain you want to sync. You can either do a Full or Partial Sync.

• Full Sync: The state of all objects are sync’d. Click the icon.
• Delta Sync: Only sync objects changed since last sync. Click the icon.

VMware Tools Guest Introspection

Make sure you have deployed the Guest Introspection Service! Installation – Service Deployments – Guest Introspection.

As mentioned earlier, for NSX to detect where the user is logged in and map this to an IP address you either need to configure Event Log access (as shown above) or on virtual machines use the Guest Introspection feature.

To enable this you need to do a full install of VMware Tools.

Select and enable the NSX File Introspection Driver.

Make sure you have deployed the Guest Introspection Service! 

 

Identity-Based Firewall (IDFW) Testing

The vSphere, NSX and Active Directory components for IDFW are all configured. I will run through the process and test that it actually works.

Prior to starting this test I created two standard Domain User accounts called TestUser01 and TestUser02. Only TestUser01 is a member of the AD Group called DenyPing.

Log into the vSphere Web Client.

Click Networking and Security.

Click NSX Managers on the left-hand-side.

Create the Security Group.

Select the NSX Manager, then click Manage, followed by Grouping Objects.

Click on Security Groups.

Click the green + sign to Add a Security Group.

What I am going to do is create a dynamic group membership based on the AD Group called DenyPing, which contains the user called TestUser01.

I change the Criteria Details to Entity and click this icon  to select the type of entity I want to use. In my case I select Directory Group.

I can now see all my AD Groups. I select the DenyPing group.

Click, next, next, finish to complete creating the Security Group. I can see it has been completed.

Create the Firewall Rule Based on the Security Group.

Click on the Firewall option

In the Distributed Firewall – Default Section Layer 3, I am going to create the rule (example section only).

The Source is the Security Group I created that contains the AD Group.

Now to test this. I log into a VM that has the Guest Introspection installed with the TestUser01 account. I try pinging the the VMs gateway IP address: 10.0.0.1. My Ping is blocked.

I log into the same VM with the TestUser2 account and try the same ping test and it works.

 

Configure SpoofGuard Policies to Enhance Security

The NSX Manager collects all the IP addresses of virtual machines with VMware Tools installed. If a VM has been hacked then the IP address can be spoofed or faked and malicious traffic can be sent through firewalls.

SpoofGuard allows you to create policies to define what to do with new IPs found on virtual networks that belong to virtual machines. SpoofGuard works in two modes:

• Automatically Trust on First Use – This will allow the initial IP of the VM to pass and you can browse the trusted IPs and block at leisure. If the IP of a vNIC changes after first use then it will be blocked.
• Manually Approve – This will block all traffic until approved. This includes all DHCP traffic.

Create a SpoofGuard Policy

Click on SpoofGuard on the left-hand-side. 

Click the green + sign to Add a New Policy.

Give the policy a Name, Enable it, then select the Operation Mode.

Select the Scope of the Policy. You can choose Logical Switches, Distributed Port Groups or Legacy Port Groups. I have selected Logical Switch so I can apply this to my Web Tier and any VMs that reside on it.

I now go and power on a VM called Web-01a that resides on the Web Tier logical switch.

I can see in SpoofGuard straight away under the policy I created that the Web-01a that SpoofGuard has blocked traffic from this VM.

I want to allow this VM so I will click on Approve (see above). Click Publish Changes. The IP is now in the Approved IP list.

Edit an Approved IP

You might have an already approved IP for a VM, but you need to change the IP and do not want the server blocked after the change. You can edit the approved IP and modify it to the new IP.

Click the Pencil icon under Approved IP, Add the new IP and Remove the Old.

Clear an IP Address

You might want to remove an IP already approved.

Locate the VM and IP.

Click the Clear Approve IP(s) button, followed by clicking Publish Changes.

 

Filter Firewall Rules to Narrow a Scope

I am not going to spend much time here. Basically the firewall filter does exactly that, it filters your firewall rules based on criteria. It’s a glorified search box. There is a wide range of search criteria you can use. These are the FilterOff and FilterOn icons. 

A basic example below. These are my current firewall rules before the filter is applied.

Now I have applied the following filter, only filtering on rules that block.

My firewall rules are filtered accordingly.

 

And that brings me to the end of Blog 11 on NSX Logical Firewall Services. Probably covered a lot more ground than required. I am not going to go into detail for the Edge Firewall rules. It is pretty straight forward. Make sure you have a good understanding of its capabilities. Make sure you read the relevant pieces in the NSX 6.2 Administration Guide.

I haven’t played with Identity-Based Firewall rules, the AD configuration or SpoofGuard before so it was good to get an understanding of those.

Blog 12 is going to cover exam Objective 4.2 which is based on Configuring and Managing Service Composer. Some of this I actually covered off in this blog. It’s live now.

I hope this brain-drain on my part has provided you with some good information \o/

Follow me on Twitter or LinkedIn.

Be Social; Please Share.