VMware Hands-on Labs - HOL-1803-02-NET


Lab Overview - HOL-1803-02-NET - VMware NSX - Distributed Firewall and Micro-Segmentation

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

In this lab we will explore use cases around VMware NSX and  Micro-Segmentation, including more in depth reviews of the Distributed  Firewall and Service Composer UI.  Use cases include solutions around  collapsing segmented networks, intelligent grouping of servers, and user  based security.

Lab Module List:

 Lab Captains:

 

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Service Composer and Distributed Firewall Overview (45 minutes)

Distributed Firewall - Micro-segmentation Overview


NSX Distributed firewall (DFW) is a hypervisor kernel-embedded firewall that provides visibility and control for virtualized workloads and networks. You can create access control policies based on VMware vCenter objects like datacenters and clusters and virtual machine names; network constructs like IP or IPSets, VLAN (DVS port-groups), VXLAN (logical switches), security groups, as well as user group identity from Active Directory. Firewall rules are enforced at the vNIC level of each virtual machine to provide consistent access control even when the virtual machine gets vMotioned. The hypervisor-embedded nature of the firewall delivers close to line rate throughput to enable higher workload consolidation on physical servers. The distributed nature of the firewall provides a scale-out architecture that automatically extends firewall capacity when additional hosts are added to a datacenter.

Micro-segmentation is powered by the Distributed Firewall (DFW) component of NSX. DFW operates at the ESXi hypervisor kernel layer and processes packets at near line-rate speed. Each VM has its own firewall rules and context. Workload mobility (vMotion) is fully supported with DFW, and active connections remain intact during the move. This advance security capability makes the data center network more secure by isolating each related group of virtual machines onto a distinct logical network segment, allowing the administrator to firewall traffic traveling from one segment of the data center to another (east-west traffic). This limits attackers’ ability to move laterally in the data center.  

The outline of this module is:

Distributed Firewall Basic Functionality 

Improved IP discovery mechanism for Firewall function

Logically apply Security with Service Composer

Start the module from your desktop. The desktop is your Control center jumpbox in the virtual environment. From this desktop you will access the vCenter Server Appliance deployed in your virtual datacenter.

Special Note: On the desktop you will find a file names README.txt.  It contains the user accounts and passwords used for all the virtual devices and VM's in the lab.


 

Notice to User about Distributed Firewall - Micro-segmentation Section

If you have completed HOL-1803-01-NET, Module 6 - Distributed Firewall, then it is important to note that this section titled, Distributed Firewall in this lab is a repeat of that module, and is not required to continue on with this lab.  If you would like to skip this section and move to the next section in this lab, we provide a link below to skip ahead.

Click here to skip to Improved IP Discovery Mechanism for Virtual Machines and SpoofGuard module

 

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Access vSphere Web Client

 

  1. Bring up the vSphere Web Client via the icon on the desktop labeled, Google Chrome.

 

 

Configure Rules for Web Application Access

You will now configure Distributed Firewall access to a 3-tier application. The application has two web servers, and one each of an application and database server. There is also a Load Balancer servicing the two web servers.

 

 

Create 3-Tier Security Groups

 

  1. Click on Service Composer.

Service Composer defines a new model for consuming network and security services in virtual and cloud environments. Polices are made actionable through simple visualization and consumption of services that are built-in or enhanced by 3rd party solutions. These same polices can be made repeatable through export/import capabilities, which would help make it easier to stand up and recover an environment when there is an issue. One of those objects for repeatable use is a Security Group.  We will cover Service Composer and Security Groups in depth in a later the module, called "Service Compose and DFW Overview."

 

 

Create 3-Tier Access Rules

 

Next you will add new rules to allow access to the web vm and then set up access between the tiers.  

  1. On the left hand menu, select Firewall.

 

 

Restart Putty Session to web-01a

 

  1. Click the Session icon in the upper left
  2. Click Restart Session.

 

 

Topology After Adding Distributed Firewall Rules for the 3-Tier Application

 

The diagram shows the relative enforcement point of the vNIC level firewall.  Although the DFW is a Kernel Loadable Module (KLM) of the vSphere ESXi Host the rules are enforced at the vNIC of the guest VM.  This protection moves with the VM during vMotion to provide complete fulltime protection not allowing for a "window of opportunity" during which the VM is susceptible to attack.

 

 

Module Clean Up

 

You will need to set the Default Rule back to Allow to proceed to the next Module.

  1. Change the Default Rule Action back to Allow.
  2. Publish Changes.

 

Improved IP Discovery Mechanism for Virtual Machines and SpoofGuard


After synchronizing with the vCenter Server, NSX Manager collects the IP addresses of all vCenter guest virtual machines. If a virtual machine has been compromised, the IP address can be spoofed and malicious transmissions can bypass firewall policies.

You create a SpoofGuard policy for specific networks that allows you to authorize the IP addresses reported and alter them if necessary to prevent spoofing. SpoofGuard inherently trusts the MAC addresses of virtual machines collected from the VMX files and vSphere SDK. Operating separately from Firewall rules, you can use SpoofGuard to block traffic determined to be spoofed.

SpoofGuard supports both IPv4 and IPv6 addresses. When using IPv4, the SpoofGuard policy supports a single IP address assigned to a vNIC. IPv6 supports multiple IP addresses assigned to a vNIC. The SpoofGuard policy monitors and manages the IP addresses reported by your virtual machines in one of the following modes:

This mode allows all traffic from your virtual machines to pass while building a table of vNIC-to-IP address assignments. We can review this table at our convenience and make IP address changes. This mode automatically approves all ipv4 and ipv6 address on a vNIC.

This mode blocks all traffic until there is an approval each vNIC-to-IP address assignment.

Note: SpoofGuard inherently allows DHCP requests regardless of enabled mode. However, if in manual inspection mode, traffic does not pass until the DHCP-assigned IP address has been approved.

SpoofGuard includes a system-generated default policy that applies to port groups and logical networks not covered by the other SpoofGuard policies. A newly added network is automatically added to the default policy until the administrator adds the network to an existing policy or creates a new policy for it.

NSX distributed firewall operation requires discovery of IP addressees for objects that are specified as a source or a destination.  Prior to NSX 6.2, this was achieved by VMtools inside the VM. This exercise will show you how to discover IP addresses with VMtools and Trust-On-First-Use.


 

Review SpoofGuard Settings

 

Click on the browser tab for the vSphere Web Client

  1. Click the Home Icon
  2. Click Networking & Security

 

 

Explore SpoofGuard

 

  1. Click SpoofGuard in the Navigator

 

 

Enable IP address discovery via ARP Snooping

 

  1. Click Change

 

 

Migrate Linux-01a from vDS to a new Logical Switch

First, we must migrate the linux-01a VM from its existing vDS to a Logical Switch to leverage SpoofGuard IP Discovery capabilities.

 

 

Navigate back to Networking & Security

 

  1. Under the Navigator, click the Back buton in the history field until you get back to to the NSX configuration interface.

 

 

Verify that Linux-01a was discovered via ARP Snooping

 

  1. Select SpoofGuard from the Navigator menu
  2. Click on Default Policy
  3. Pick Active Virtual NICs in the View dropdown
  4. Enter "lin" and press enter to filter for linux-01a

Notice that the Source Field denotes TOFUARP (Trust On First Use ARP) for the address 192.168.120.115.

 

 

SpoofGuard Wrap Up

This concludes the section on Improved IP Discovery Mechanism for Virtual Machines and SpoofGuard.  We have successfully migrated a VM into the NSX environment, and leveraged SpoofGuard to learn the IP address of the VM with the new Trust-On-First-Use ARP feature.

 

Security Groups Overview


We will now build upon the Security Group capabilities we discovered in the Distributed Firewall - Micro-segmentation Overview.  NSX Security Groups are a way to logically group and define assets that you want to protect. Security groups may be static (including specific virtual machines) or dynamic where membership may be defined in one or more of the following ways:

Note that security group membership changes constantly. For example, a virtual machine tagged with the AntiVirus.virusFound tag is moved into the Quarantine security group. When the virus is cleaned and this tag is removed from the virtual machine, it again moves out of the Quarantine security group.


 

Access the Service Composer

 

  1. Click the Service Composer on the left panel.

 

 

View Membership

 

  1. Click the number in the Virtual Machine column associated with the new Web Security Group.

Note: There should 6 in the Virtual Machine column for the Web Security Group, including all VMs with "WEB" in their name, without consideration for capitalization, or IP networks.

  1. Click the X in the upper right hand corner of the dialog box to close it.

 

Security Policy Overview


NSX Security Policies can be a collection of the following service configurations, Firewall rules, Endpoint services, Network introspection services.  Firewall rules can consist of rules that define the traffic to be allowed to, from, or within the security group.  Endpoint services can implemented via third party solution provider services such as anti-virus or vulnerability management services. Network introspection services are services that monitor your network such as IPS.

During service deployment in NSX, the third party vendor selects the service category for the service being deployed. A default service profile is created for each vendor template.

Note When you have many security groups to which you need to attach the same security policy, create an umbrella security group that includes all these child security groups, and apply the common security policy to the umbrella security group. This will ensure that the NSX distributed firewall utilizes ESXi host memory efficiently.


 

Create a New Security Policy

 

  1. Select the Security Policies tab in the Service Composer panel
  2. Click the Create Security Policy icon
  3. Type in "Block Web-to-Web Traffic" in the Name field
  4. Click Firewall Rules in the left panel

 

 

Verify Firewall Rule Synchronization

 

  1. Click on Firewall

 

 

Test Web VM to Web VM connectivity using Putty

 

Next we will test communication and access between the Web VMs making up the 3-tier application. Our first test will be to open a console to web-01a and ping web-02a.

  1. Click on the PuTTY shortcut on the desktop taskbar 
  2. Select web-01a.corp.local
  3. Click on Open

 

Review of Service Composer Canvas


Service Composer offers a canvas view displaying all security groups within the selected NSX Manager. The view also displays details such as members of each security group as well as the security policy applied on it.

This topic introduces Service Composer by walking you through a partially configured system so that you can visualize the mappings between security groups and security policy objects at a high level from the canvas view.


 

Graphical View of Service Composer Canvas

 

 

  1. Click Service Composer
  2. Click Canvas

All security groups within the selected NSX Manager (that are not contained within another security group) are displayed along with the policies applied on them. The NSX Manager drop-down lists all NSX Managers on which the currently logged in user has a role assigned.

Each rectangular box in the canvas represents a security group and the icons within the box represent security group members and details about the security policy mapped to the security group.

 

 

Module 1 - Conclusion


This now completes Module 1 on Service Composer and Distributed Firewall.  We have created both static and dynamic Security Groups, applied both static and dynamic Security Policies, including firewall rules, and used SpoofGuard to discover and allow VMs on to the network that are not running VMTools.


 

Module 1 Clean Up

 

Prior to finishing Module 1, you need to remove the rule that was created during this section.

  1. Navigate back to Service Composer
  2. Select Security Policies tab
  3. Right-click on Block Web-to-Web Traffic row
  4. Select the Delete option. When prompted "Remove security policy?", click Yes

 

 

You've finished Module 1

Congratulations on completing Module 1.

If you are looking for additional information on NSX Routing capabilities and configuration, then please review the NSX 6.3 Documentation Center via the URL below:

Proceed to any module below which interests you the most:

Lab Module List:

Lab Captain:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 2 - Collapse 3-Tier Application Feature Walk-Through (15 minutes)

Securing Collapsed Architectures with NSX's Distributed Firewall Capability


In this module, you will explore how the Distributed Firewall (DFW) functionality in NSX allows customers to collapse traditional multi-tier network architectures into single, flat networks while maintaining application isolation at the same time.  This is essential to getting away from a network-centric approach to security and moving to a workload-centric approach. You will be using two different applications, (HR and Finance) that have been placed on the same logical switch and subnet.   

You will then configure and test the following:

When you have completed this lab module, you have proven that NSX DFW has secured and isolated the applications from each other while allowing intra-application communication to function as normal on the same network infrastructure.  


 

Review Sample Network Architecture

 

Before we collapse a 3-tier application network into a single network, lets look at an example of a 3-tier application segmented into individual network subnets to provide Layer 3 isolation between the web, application, and database tiers.  It is important to note that we were missing security firewall rules protecting communication between VMs resident on the same layer 2 domain, and even between tiers of the application.  When organizations begin to scale out multiples of these multi-tier workloads the choice is to either deploy more subnets or deploy application components (e.g. databases from different applications) on the same L2 domain.  

For example, an organization may have the database components for multiple applications resident on the "DB-Tier" network.  With traditional firewalls, there is no protection between those databases.  This could potentially allow someone with approved access to one DB machine the ability to access another DB on the same network.  NSX's DFW allows organizations collapse the entire network structure into a single L2 segment and provide intra-application functionality while providing inter-app application isolation.

 

 

Access vSphere Web Client

 

  1. Click on the shortcut to Google Chrome on the Main Console window.

 

 

Validate Finance Application is working

 

  1. Open a New Tab in Chrome.
  2. Click on the Finance DB App bookmark.

Validate you are accessing the Financial Department Cost Centers Database.  You should receive data from fin-web-01a.

 

 

Validate the HR Application

 

  1. Open a New Tab in Chrome.
  2. Click on the HR DB App bookmark.

Validate you are accessing the HR Employee Salary Database.

 

 

Launch a Remote Console to fin-web-01a VM

 

  1. Click the tab for vSphere Web Client.
  2. Click fin-web-01a.corp.local.
  3. Click on the Summary tab.
  4. Click Gear Icon and  Launch Remote Console.

 

 

Return to the vSphere Web Client Session

 

  1. Click the vSphere Web Client browser icon on the Taskbar

 

 

Return the vSphere Web Client

 

  1. Click the vSphere Web Client browser icon on the Taskbar.

 

 

Access the Firewall Configuration

 

  1. Click the Firewall from the Navigator menu on the left.

 

 

Create HR App Security Group

 

  1. Select Security Group from the Object Type drop down menu.
  2. Click New Security Group to define the HR App security group.

 

 

Create Finance App Security Group

 

  1. Select Security Group from the Object Type drop down menu.
  2. Click New Security Group to define the Finance App security group.

 

 

Add a New Firewall Rule

 

  1. Click the Green Plus icon of the Collapsed App Tier Rules section to add a new rule.

 

 

Publish Changes

 

  1. Click Publish Changes to deploy the new firewall rules to the effected VMs and hosts.

 

 

Validate Finance Application is working

 

  1. Click the tab "HOL- Finance Department".
  2. Click the Refresh button.

Validate you are accessing the Financial Department Cost Centers Database.

 

 

Validate the HR Application

 

  1. Click on the tab "HR-Medical Enrollment".
  2. Click the Refresh button.

Validate you are accessing the Medical Enrollment Database.

 

 

Lab Clean Up prior to moving to next Lab Module

 

Before proceeding to the next module, we must first clean up the firewall rules.    

  1. Click the vSphere Web Client browser tab.

 

Module 2 - Conclusion


This now completes Module 2, a guided walk through application isolation with NSX Distributed Firewall (DFW) for a single flat network.  In this module, we showed how collapsing a 3-tier network application into a single NSX Logical Switch does not impact how NSX provides zero-trust security via the Distributed Firewall.  We started this lab with verifying communication between the HR and Finance application VMs on the same network.  Then we created firewall rules with logical groupings of VMs to protect and prevent communication between the HR and Finance applications, and verified the enforcement of the rules we created by testing VM communication across and within the application stacks.   After verifying the applications were isolated from each other, we deleted our firewall rules to prepare for another module of the lab.

We hope you enjoyed learning about the application isolation, zero-trust capabilities of NSX DFW.


 

You've finished Module 2

Congratulations on completing Module 2.

If you are looking for additional information on NSX Routing capabilities and configuration, then please review the NSX 6.3 Documentation Center via the URL below:

Proceed to any module below which interests you the most:

Lab Module List:

Lab Captain:

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 3 - Intelligent Grouping (30 minutes)

Intelligent Grouping


Module 3 Intelligent Grouping


 

Introduction

The End of Support (EOS) of major enterprise platforms like Windows XP, Windows 2000 Server, and Windows Server 2003 are a major challenge for organizations running mission-critical applications necessary for day-to-day business. For example, in July 2015, when Microsoft ended support for Windows 2003, it put millions of enterprise servers at risk.

Organizations using an Operating Systems that is EOS likely introduced serious security risks into their environments, unless they are fully prepared to migrate to a new platform or put compensating controls in place. Hackers know that platform providers like Microsoft will no longer acknowledge or patch vulnerabilities, so these systems quickly become a favorite target for attacks, and the risks of running an unsupported platform after EOS will increase over time as more issues are found and not patched.

NSX can help mitigate the issue of EOS Operating Systems by providing additional security via the Distributed FireWall (DFW) and Service Composer. In this lab you will use NSX Security Groups to corral windows XP VMs and provide firewall polices to protect them in a simulated environment.  

The outline of this module is:

Lab Captain:

Module 3 - Chris Cousins, Sr. Systems Engineer, United States.

 

 

Log on to the End of Support Virtual Machines


Using Windows XP VMs we will determine the current security access to external and internal resources.


 

Login to the vSphere Web Client

 

If you are not already logged into the vSphere Web Client:

(The home page should be the vSphere Web Client.  If not, Click on the vSphere Web Client Taskbar icon for Google Chrome.)

  1. Type in administrator@vsphere.local into User name
  2. Type in VMware1! into Password
  3. Click Login
  1. Clicking on the Push-Pins will allow task panes to collapse and provide more viewing space to the main pane.  You can also collapse the left-hand pane to gain the maximum space.

 

 

Log on to EOS Virtual Machines

 

  1. Select Home
  2. Select VMs and Templates

 

 

Verify Internal Access

 

Launch Mozilla Browser from desktop.

  1. Click Customer DB-App link to launch internal application.

 

 

Open Command Prompt for External Access

 

The control console VM exists outside of the virtual environment we are using for this lab. As such it represents a service external to our environment. We will use the control center IP address 192.168.110.10 to represent Internet services.

  1. Click Start menu.
  2. Launch Command prompt.

If “Command Prompt” icon not shown.  Click “Run” and type “cmd” and press Enter to bring up the Command Prompt”

 

Security Group Creation


Now that we see the potential vulnerability of allowing end of support VMs to access external resources we want to find a way to secure them. We will use Security Groups in NSX to quickly identify machines running EOS OSes and secure them using policy enforcement.


 

Create Security Group

 

  1. Click the vSphere Web Client browser tab.
  2. Click the HOME icon.
  3. Select Networking & Security.

 

Limit VM Access


We will now apply rules to limit VM external access.


 

Apply Policy

 

Go to Service Composer.

  1. Select the "Windows XP EOS" Security Group we created previously.
  2. Click the "Apply Policy" icon.

 

 

Configure 1st Firewall Rule

 

  1. Name:  Access Internal Resources
  2. Action : Allow
  3. Source: Policy's Security Group
  4. Destination: Click Change

 

 

Add Additional Firewall Rule

 

We have created a Security Group to allow Windows XP VM to access the Internal Services (internal Applications). However we still need to Add an additional rule to allow access between internal services as well as modifying the Default firewall rule to block all other access including External access.

  1. Click Firewall to access the firewall rules.

 

 

Modify Default Firewall Rule

 

In order to block any unwanted traffic including traffic to external services from the Windows XP EOS VMs we need to enable blocking on the default firewall rule. The default firewall rule is in the default firewall section.

  1. Click to expand the Default Firewall Rule section.
  2. Click the Pencil Icon on the Action Column of the Default Rule.
  3. Select Block as the action.
  4. Click Save.

 

Verify Limited Access from Windows XP VMs


We now have rules in place for the EOS windows XP VMs. We can proceed with testing access to internal and external services.


 

Reopen Console to win-xp-01a

 

  1. Click the browser tab for "win-xp-01a".

 

 

Verify External Access is Blocked

 

  1. Reopen the Command Prompt on the win-xp-01a desktop.
  2. In the Command Prompt, enter: ping 192.168.110.10
  3. Verify that external access to the Control Center is now blocked.
ping 192.168.110.10

Now we can see that win-xp-01a has access to internal services, but its external access has been completely blocked per the Group Policy.

 

 

Module Clean-Up: Set Default Rule to Allow

 

  1. Expand the Default Section Layer3.
  2. Hover and Click the pencil on the Action column of the Default Rule.
  3. Select the Allow Action.
  4. Click Save.

 

Module 3 Conclusion


 Congratulations on completing Module 3.

In the lab we have seen how using intelligent grouping can quickly containerize End of Support Operating Systems via security groups.  Once security groups are in place we can use them to create firewall rules that can both limit access to and from the virtual machines contained within. The Security Groups are a versatile tool and can be reused to change or create new policies as our security requirements evolve.

If you are looking for additional information on NSX Security Groups capabilities and configuration, then please review the NSX 6.3 Documentation Center via the URL below:

Lab Module List:

Lab Captain:


 

How to End Lab

 

To end the lab click on the END button.  

 

Module 4 - User Based Security with a Jump Box (45 minutes)

User Based Security in a Jump Box Scenario


Module 4

User Based Security in a Jump Box Scenario.


 

Introduction

In this Lab Module you will create firewall rules using the NSX Identity Based Firewall feature. This feature uses a connection to Active Directory from the NSX manager. The NSX manager scans the event log of the AD Server to determine log on credentials and events. Users logging on to VMs can have their VMs instantly assigned to Security Groups based on their AD groups.  The Security Groups combined with firewall rules allow us to control access within our environment.

This lab uses two different Active Directory groups and two different users. The first user, a network administrator who should be able to get to any application in the environment and a Human Resources administrator who should only have access to a specific HR web based application.      

 

This is the outline for this module:

 Lab Captain:

Module 4  Chris Cousins, Sr. Systems Engineer, United States.

 

Explore Link between NSX and Active Directory


NSX links with Active Directory to use AD groups to provide identity based firewall rules.


 

Launch Browser and vSphere Web Client

 

 

 

 

  1. Click on Home icon
  2. Click on Networking & Security

 

 

AD Synchronization

 

  1. Click the "Double-Gear".
  2. Click the "Single-Gear" to get updates from the AD.  You should see a Success Status and the current date.

Note this may take 2-3 minutes to succeed.

With a configured and synchronized AD connection you are ready to make use of the AD Groups in your security policies.

 

NSX Guest Introspection


Before creating Identity Based Firewall (IDFW) rules, we will need to configure NSX Guest Introspection.


 

Deploy Guest Introspection

 

  1. Click Home icon.
  2. Click Networking & Security

 

 

Service Deployments

 

  1. Select Installation.
  2. Select Service Deployments tab.
  3. Click + icon to deploy Guest Introspection.

 

 

Guest Introspection deployment wizard

 

  1. Select Guest Introspection service.
  2. Click Next.

 

  1. Select RegionA01-COMP02.
  2. Click Next.

 

  1. Leave default values.
  2. Click Next.

 

 

Starting Data Collection

 

  1. Click Finish.

Wait a few minutes for the installation to complete and then confirm successful installation to the cluster.

 

 

 

Verify Guest Introspection installation on hosts

 

  1. Click Home icon.
  2. Click Hosts and Clusters.

 

  1. Expand the RegionA01-COMP02 folder.
  2. Verify the Guest Introspection VM is operational and deployed on the esx-03a.corp.local host.
  3. Verify the Guest Introspection VM has an IP address assigned.

 

Use Security Objects based on AD Groups


  1. Security Objects are defined to based on AD group membership and will be used to enforce security policy.

 

Create a Security Object based on AD Groups

 

  1. Hover the mouse over the Home Button.
  2. Click on Networking & Security.  

 

 

Create New Firewall Rule Section

 

  1. Click the Firewall link on the navigation pane.
  2. Click the "Add Section" icon on the "Flow Monitoring & Traceflow Rule section"

 

 

Add Rule Net-Admin

 

  1. Click the Add rule icon on the newly created rule section.
  2. Click to Expand the newly created rule section.
  3. Click the pencil Icon on the Name column to edit the new rule.

 

 

Add Rule HR-Admin

 

  1. Click to Expand the AD based Rule section
  2. Click the Add Rule icon.

 

Define Internal Application Firewall Rules


Internal applications in this lab will require additional rules to allow for communication between application tiers.


 

Add Additional Firewall Rule

 

We have created a AD based firewall rules to allow HR admins and Net admins to access the appropriate applications based on there role. However we still need to Add an additional rule to allow access between internal services as well as modifying the Default firewall rule to block all other access including External access.

  1. Click Firewall to access the firewall rules.

 

 

Modify Default Firewall Rule

 

In order to block any unwanted traffic we need to enable blocking on the default firewall rule. The default firewall rule is in the default firewall section.

  1. Click to expand the Default Firewall Rule section.
  2. Click the Pencil Icon on the Action column of the Default Rule.
  3. Select Block as the action.
  4. Click Save.

 

Testing User Identity Based Rules


In order to test the newly created rules we must log on to the win12-jump VM with different user AD credentials.


 

Test User Identity Rule

 

You can test the new Identity based rules by opening a console to the Jump Box (win-12-jump) VM in the domain and logging in as a member of the Active Directory AppConfiguration group or the Human Resources group.  User Netadmin is a member of the AppConfiguration group and therefore can login into any internal application or application teir. User  HRadmin is  a member of the Human Resources  group and can only login into HR web application and the Financial web application.  You will login as each and see the results of trying to access the multiple 3-tier applications.

  1. Clicking on the Home icon.
  2. Click on the VMs and Templates.

 

 

Open Console to Jumpbox

 

Expand the containers "RegionA01" and "Discovered virtual machines" to find win12-jump.

  1. Expand Misc VMs.
  2. Right Click on "win12-jump".
  3. Click on "Open Console".

 

 

Switch to other user

 

  1. Click on Send Ctrl-Alt-Del.
  2. Click on "Other user".

 

 

Login in as NetAdmin

 

  1. Enter User name = NetAdmin.
  2. Password = VMware1!.  (be sure to add "." after "!" mark)
  3. Click on the arrow.

 

Module 4 Conclusion


Congratulations on completing Module 4.

In the lab we have seen how using Identity Based Firewall features within NSX we can control access to internal applications.  We created AD based firewall rules for both a Network Administrator and a Human Resources Administrator. These rules allow the HR admin to only connect to the HR web application via HTTP protocol.  The rules also allow the Network Admin to connect to any of the applications via any protocol.  In this way we can control access to the correct applications with the correct level of privilege based on roles within the organization.

If you are looking for additional information on NSX Identity Based Firewall capabilities and configuration, then please review the NSX 6.3 Documentation Center via the URL below:

Lab Module List:

Lab Captain:


 

How to End Lab

 

To end the lab click on the END button.  

 

Module 5 - NSX Application Rule Manager (30 minutes)

Module 5 Application Rule Manager



 

Introduction

The Application Rule Manager (ARM) is a new toolset introduced in NSX 6.3. Application Rule Manager utilizes real-time flow data to enable quick and efficient microsegmentation planning and implemenation of Zero Trust security models. ARM provideds a new way to help secure new or existing applications on scales larger than what Log Insight can handle, and environments on a smaller scale than what vRealize Network Insight (vRNI) would address.

ARM gathers real-time flow data both IN, OUT and between application workloads allowing for the creation of app-centric security models. ARM can monitor up to 30 VMs per session and a total of 5 sessions can be running at any given time. ARM also provides visibility into blocked flows and the firewall rules that are blocking the traffic.  

There are three steps in the application rule manager workflow:

  1. Select virtual machines (VMs) that form the application and need to be monitored. Once configured, all incoming and outgoing flows for a defined set of VNICs (Virtualized Network Interface Cards) on the VMs are monitored. There can be up to five sessions collecting flows at a time.
  2. Stop the monitoring to generate the flow tables. The flows are analyzed to reveal the interaction between VMs. The flows can be filtered to bring the flow records to a limited working set.
  3. Use flow tables to create grouping object such as security groups, IP sets, services and service groups and firewall rules.

Lab Captain:

Module 5 - Chris Cousins, Sr. Systems Engineer, United States

 

Application Microsegmentation



 

Launch Chrome Browser and vSphere Web Client

 

  1. Double-click on Chrome icon on the desktop

 

 

Login to the vSphere Web Client

 

If you are not already logged into the vSphere Web Client:

(The home page should be the vSphere Web Client. If not, click on the vSphere Web Client Taskbar icon for Google Chrome.)

  1. Type in administrator@vsphere.local in to User name
  2. Type in VMware1! into Password
  3. Click Login

 

 

Explore Application Rule Manager

 

  1. Select Home
  2. Select Networking & Security

 

 

Select Flow Montoring

 

  1. Select Flow Monitoring

 

 

Start New Session for HR_App

 

  1. Select Application Rule Manager tab
  2. Click Start New Session to start collecting application flow data.

 

 

Select HR_DB_App Virtual Machines

 

  1. Session Name: HR_DB_App.
  2. Select Virtual Machine in the Object Type drop-down menu.
  3. Type hr into the Search field.
  4. Select hr-web-01a.corp.local, hr-db-01a.corp.local, and hr-app-01a.corp.local.
  5. Click on the right arrow
  6. Click OK.

 

 

Create Some Traffic Flows - ICMP

 

Application Rule Manager is now collecting flow data from the three HR_App virtual machines. The longer the collection process runs, the more data you will have to analyze. For our purposes, we will collect flow data for three minutes. To generate some flow data:

  1. Open a Putty session and select hr-web-01a.corp.local
  2. In the commmand line, type ping -c 2 172.16.60.12
  3. Open the Command Prompt on the Main Console
  4. ping 172.16.60.10
ping -c 2 172.16.60.12
ping 172.16.60.10

 

 

Create More Traffic Flows - HTTPS

 

  1. Open a new Chrome browswer tab
  2. Click on the HR DB App bookmark
  3. Refresh the page several times.

 

 

Data Collection - Stop

 

Within three minutes, you will see Flows in the Flow Monitoring console. The number of flows will vary in each lab.

  1. After three minutes, click Stop.
  2. Click Yes to confirm.

 

 

Review Flow Data

 

Here we can see source and destination IPs as well as services like HTTP, HTTPS, etc.

 

 

Start New Session for Finance_DB_App

Before we analyze the data collected for HR_App, we will configure a second session for Fin_App in order to demonstrate collecting multiple data flow sessions.

 

 

Start Session for Finance_DB_App

 

  1. Click Start New Session

 

 

Select Finance_App Virtual Machines

 

  1. Session Name: Finance_DB_App.
  2. Select Virtual Machine in the Object Type drop-down menu.
  3. Type fin into the Search field.
  4. Select fin-web-01a.corp.local, fin-db-01a.corp.local, and fin-app-01a.corp.local.
  5. Click on the right arrow
  6. Click OK.

 

 

Finance_App Data Collection

 

Application Rule Manager is now collecting flow data from the three Finance_App virtual machines. The longer the collection process runs, the more data you will have to analyze. For our purposes, we will collect flow data for three minutes. To generate flow data, open a new Chrome browswer tab and click on the Finance DB App bookmark and refresh the page several times. Within three minutes, you will see Flows in the Flow Monitoring console. The number of flows will vary in each lab.

  1. Click Stop
  2. Click Yes

 

 

Review Sessions

 

We can now see that Application Rule Manager has successfully collect flow data for both the HR_DB_App and Finance_DB_App virtual machines.

 

 

Review Sources

 

  1. Click on Source to review vnics being montiored.

 

 

Review Flow Duration

 

  1. Click on Flows to review collection time and duration.

 

 

Start Flow Analysis for Finance_DB_App

 

  1. Click Analyze to being analyzing the collected flow data.

 

 

Start Flow Analysis for HR_App

 

When the data analysis is complete for Finance_DB_App:

  1. Select HR_DB_App in the Session drop down menu
  2. Click Analyze

 

 

Verify Data Analysis

 

  1. Verify Analysis Complete has green checkmark. This indicates data analysis was successful.

 

 

HR_DB_App Processed View

 

After analyzing and processing flow data, NSX has replaced the IPs with VM names, making it easier to logically map flows between objects.

 

 

HR_DB_App Firewall Rules

 

We will use the information ARM has given us to microsegment virtual machines within and between HR__DB_App & Finance_DB_App. Let's see if hr-web-01a can communicate with hr-db-01a.

  1. Open a Putty session for hr-web-01a.corp.local.
  2. Click hr-db-01a.corp.local in the Destination column to retrieve its IP address.
  3. Here we can see the IP address 172.16.60.12 as well as the Vnic information.
  4. Ping 172.16.60.12. You should see a successful ping with no packet loss.
ping -c 2 172.16.60.12

We just verified that the HR_DB_App web-01a virtual machine can communicate directly with the db-01a virtual machine. This is not an ideal situation! Next, we will configure appropriate firewall rules to control traffic between the three-tiered virtual machines.

 

 

New Firewall Rules

 

  1. Select the flow with Source (192.168.110.10), Destination (hr-web-01a.corp.local) and Service (SSH).
  2. Click the Gear icon
  3. Select Create Firewall Rule

 

 

Control Center to HR_Web

 

  1. Name: Control Center to HR_Web
  2. Click Select across from Service

 

 

Select Services

 

  1. Enter https in the search field.
  2. Select HTTPS.
  3. Click right arrow.
  4. Confirm SSH and HTTPS are selected
  5. Click OK

 

 

Confirm Configuration

 

  1. Confirm your configuration matches the image and click OK

 

 

Configure HR_Web to HR_App Firewall Rule

 

  1. Select the row that lists hr-app-01a as the Destination.
  2. Click the Actions gear and select Create Firewall Rule.  

 

 

New Firewall Rule: HR_Web to HR_App

 

  1. Name: HR_Web to HR_App
  2. Leave everything else as default and click OK

 

 

Configure New Firewall Rule: HR_App to HR_DB

 

  1. Select the row with hr-db-01a as the Destination.
  2. Click the Gear icon and select Create Firewall Rule
  3. Do NOT select the row with ICMP Echo as the Service

 

 

New Firewall Rule: HR_App to HR_DB

 

 

 

Publish Firewall Rules

 

  1. Under Flow Details, select the Firewall Rules tab. Here we can see the firewall rules you just created.
  2. Firewall rules can also be Edited and Deleted from this view.
  3. Click Publish

 

 

Enter Name

 

  1. Section Name: HR_DB_App
  2. Select Default Section Layer 3

 

 

Review HR_DB_App Firewall Rule

 

  1. Select Firewall in the Navigator panel

 

 

HR_DB_App 3 Tier Firewall Rule

 

Here we can review the firwall rules we just configured in Application Rule Manager. Next, we will test the HR_DB_App to make the web page still resolves and unsecure traffic has been blocked.

 

 

Edit Default FW Rule

 

  1. Under the Default Rule, click on the Pencil icon to edit the rule.
  2. Action: Block
  3. Click Save

 

  1. Publish Changes

 

 

Verify HR_DB_App is working

 

If you closed the HOL-HR Department tab:

  1. Open a new Chrome browser tab
  2. Click on the HR DB App bookmark.

You should be able to see the HR Employee Salary Database.

 

 

Open Command Prompt

 

Let's test if we can successfully ping the web, application and database servers from the Main Console:

  1. ping 172.16.60.10
  2. ping 172.16.60.11
  3. ping 172.16.60.12
ping 172.16.60.10
ping 172.16.60.11
ping 172.16.60.12

Now we can see that ICMP traffic is being blocked. The only allowed traffic is HTTPS.

Note: In this lab, we configured the web-01a firewall rule to allow SSH so we can access the virtual machine via Putty to do the next test.

 

 

Open Putty

 

ping -c 2 172.16.60.12
  1. ping -c 2 172.16.60.12
  2. After about 10 seconds, enter Control+C to terminate.

Now we can see traffic from the web-01a to db-01a has been blocked!

 

Module 5 Conclusion


Congratulations on completing Module 5!

If you are looking for additional information on NSX Application Rule Manager capabilities and configuration, then please review the NSX 6.3 Documentation Center via the URL below:

Lab Module List:

Lab Captain:


 

How to End Lab

 

To end the lab click on the END button.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1803-02-NET

Version: 20180215-205024