VMware Hands-on Labs - HOL-1822-01-NET


Lab Overview - HOL-1822-01-NET - VMware NSX Cloud - Secure Native Workloads in AWS

Lab Guidance


Note: It will take more than 120 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.

VMware NSX Cloud provides customers the ability to abstract and manage Networking and Security policies in Public Cloud environments such as Amazon Web Services (AWS).

Through a scenario of an application deployed in AWS with minimal security, we will explore how VMware NSX Cloud provides the capability of bringing an existing AWS Virtual Private Cloud (VPC) under NSX management and micro-segmentation to native EC2 instances running in AWS.

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


 

Disclaimer

This session may contain product features that are currently under development.

This session/overview of the new technology represents no commitment from VMware to deliver these features in any generally available product.

Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind.

Technical feasibility and market demand will effect final delivery.

Pricing and packaging for any new technologies or features discussed or presented have not been determined.

 

 

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 - Introduction to the AWS Console (15 minutes)

Introduction


The NSX management and control plane components, as well as a 2-tier WordPress application have been provisioned in Amazon Web Services. We will examine the component inventory.

This Module contains the following lessons:


Solution Overview and Lab Validation


This lab includes many pre-configured items that are necessary for future lessons. We will examine a brief overview of the configured solution and review the functionality of the configured lab environment.

The configurations that will be reviewed include:


 

Solution Overview

As companies move workloads to public cloud providers they require a way to extend their SDDC network and security policies into these environments, while allowing native workloads to run. VMware NSX Cloud provides companies with the ability to extend enterprise security, compliance and governance.

NSX provides solutions for the top Networking and Security challenges companies face in public cloud environments:

 

 

Solution Components

 

The solution consists of the following components, each of which will be explored in upcoming lessons:

 

 

Lab Topology

 

The picture depicts the environment that is provisioned and used during the lessons of this lab. The environment explores the scenario of a developer deploying a 2-tier WordPress application in Amazon Web Services (AWS), including the use of native AWS capabilities such as Elastic Load Balancer to provide load balancing between a pair of web servers. The application deployment lacks security policies that match the company corporate standards, and it will be necessary to use NSX to apply consistent policies to the application environment.

The deployment of VMware NSX Cloud requires one Management VPC and one or more Compute VPCs. The NSX Central Management Plane (NSX Manager and Cloud Services Manager) and Central Control Plane (NSX Controller) components have been pre-configured.

 

 

Lab provisioning status page

The AWS portion of the lab provisioning is currently completing. A webpage has been provided that displays the status of the lab resources that are being provisioned on AWS as part of this lab startup.

NOTE: The resources provisioned in Amazon Web Services are accessible only from the Main Console of the HOL environment.

The lab provisioning can be expected to take 10-15 minutes.

 

Overview of Amazon Web Services and NSX solution components


We will review the Amazon Web Services and NSX components that have been configured in the lab environment.


 

Management VPC

 

In the Management VPC in AWS, the following components have been configured:

AWS Services

NSX Components

 

 

Compute VPC

 

In the Compute VPC in AWS, the following components have been configured:

AWS Services

2-tier WordPress application components

The NSX Cloud Gateway depicted will be deployed as part of the lab exercises.

 

Amazon Web Services Management Console access


All application and NSX component instances for this lab are running in Amazon Web Services. Throughout this lab it will be necessary to access the AWS management console to verify inventory and configurations. This lesson will establish access to the AWS management console.


 

Accessing AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Log in to the AWS Console

 

  1. Type vmware_hol_user for the AWS Management User Name.
  2. Type or copy the Password from the Account Information page.
  3. Click the Sign In button.

 

 

 

AWS Management Console

 

The AWS management console page will appear.

 

 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

Select Region

 

Verify that the console is viewing North California region resources. If a different region is selected the lab resources will not be displayed.

  1. Click the Region Name to the left of Support in the upper right.
  2. Select US West (N. California).

 

Review of Amazon Web Services inventory


In this lesson we will review the Amazon Web Services and NSX components that are part of the solution:

Please Note: Some AWS inventory screens may show delete, terminated, detached, etc entries that differ from the screenshots. These are items from the previous lab deployment that have been removed, but not yet cleared from, the AWS UI.


 

Review Configured Virtual Private Clouds

 

  1. Click Services in the upper left corner of the AWS management console.
  2. Click VPC under Network & Content Delivery.

 

 

Click Your VPCs

 

  1. Click Your VPCs under VPC Dashboard on the left.

 

 

Review Configured VPCs

 

There are multiple VPCs configured in this AWS Region. In particular, there is a Management VPC for management and control plane components, and a Compute VPC where the application instances are deployed. The VPC IDs will be different for each lab pod.

 

 

Click Peering Connections

 

  1. Click on Peering Connections under VPC Dashboard on the left.

 

 

Review Configured Peering Connection

 

There is an active VPC peering connection between the Management and Compute VPCs, allowing traffic to flow between VPCs.

 

 

Click Security Groups

 

  1. Click on Security Groups on the left under Security.

 

 

Review Configured Security Groups

 

There are Security Groups configured for the Management and Compute VPCs to allow EC2 instances to communicate.

 

 

Click EC2

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

Review NSX EC2 Instances

 

There are three EC2 instances running that comprise the NSX solution:

 

 

Review WordPress Application EC2 Instances

 

There are four EC2 instances running that comprise the 2-tier WordPress application plus an instance running nmap for security scans later in the lab.

 

 

View the Configured Load Balancer

 

  1. Click Load Balancers under Load Balancing on the left. You may need to scroll down.

 

 

Web Load Balancer

 

As part of the application deployment, the developer has created a load balancer for the web-tier instances. We will see this load balancer in action during application functionality verification.

 

Conclusion


This completes Module 1. We have reviewed the components of the solution that are deployed in Amazon Web Services, successfully logged in to the AWS management console, and reviewed the AWS inventory.


 

Congratulations, you've finished Module 1

Proceed to Module 2 for validation the application functionality. You may also proceed to any other module of interest.

 

Module 2 - Verify Application Functionality (15 minutes)

Introduction


In the lab scenario, a 2-tier WordPress application has been deployed by an application developer in to Amazon Web Services. An additional instance has been deployed in AWS to simulate a possible hacker attempting to scan the application instances for vulnerabilities.

This Module contains the following lessons:


 

Application Diagram

 

 

Review security policies


We will look at the security policies that were applied to the WordPress application when the developer deployed it. Since NSX has not been deployed, the security policies that are applied are what have been configured in Amazon Web Services.


 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page. If you've completed the previous lesson you can click on the account information tab that is open and proceed to the next step.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The AWS Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

 

Locate the AWS Management Console URL

 

  1. Click the Console URL to open a new browser tab and connect to the AWS Management Console.

 

 

Log in to the AWS Console

 

  1. Type vmware_hol_user for the AWS Management User Name.
  2. Type or copy the Password from the Account Information Page.
  3. Click the Sign In button.

 

 

 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

Select Region

 

Verify that the console is viewing North California region resources.

  1. Click the Region Name to the left of Support in the upper right.
  2. Select US West (N. California).

 

 

Navigate to EC2 Dashboard

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Navigate to the Deployed Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

Select the wordpress-web-01a Instance

 

  1. Select the wordpress-web-01a instance.

 

 

Open the Inbound Rules

 

  1. Click view inbound rules at the bottom of the screen in the Description tab for that instance. This instance has been configured with an AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Web and SSH traffic are allowed from the HOL Main Console (Source IP ranges may vary). All traffic between application instances is allowed within the AWS VPC environment.

 

 

Select the wordpress-db-01a Instance

 

  1. Select the wordpress-db-01a instance. Make sure wordpress-web-01a is not also selected.

 

 

Open the Inbound Rules

 

  1. Click view inbound rules at the bottom of the screen in the Description tab for that instance. This instance has also been configured with an AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Like the wordpress-web-01a instance, Web and SSH traffic are allowed from the HOL Main Console (Source IP ranges may vary). All traffic between application instances is allowed within the AWS VPC environment.

 

WordPress application validation


A 2-tier WordPress application has been deployed by a developer in Amazon Web Services. NSX will be used to secure this application in upcoming lessons. We will validate the pre-NSX functionality of the application.


 

Accessing AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the WordPress Application Information

 

  1. Click on the WordPress Application Elastic Load Balancer DNS Name link to open a new browser tab and connect to the WordPress application.

 

 

Verify WordPress Application is Functioning

 

Verify that the WordPress application is functioning. The IP address of the server presenting the page is noted. You can refresh the browser a few times to see the Server IP address change to the other web server (172.16.10.10 and 172.16.10.11).

Note: Scrolling down in the browser will display the blog posts depicted in the screen shot.

 

 

Open Account Information Page

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another and click on the Account Info bookmark.

 

 

Locate Web Server Information

 

  1. Locate the Wordpress-web-01a Instance Public IP Address that will be used to log in to the instance.

 

 

Open PuTTY in the Main Console

 

  1. Click on the PuTTY Icon on the Windows Quick Launch Task Bar.

 

 

Type the IP Address for the wordpress-web-01a Instance

 

  1. Type the IP Address of the wordpress-web-01a instance from the Account Information Page.
  2. Click Open.

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

 

Test Connectivity to wordpress-web-02a Instance

 

  1. Type the following command to test the connectivity between the wordpress-web-01a and wordpress-web-02a instances:
ping -c 5 172.16.10.11

 

 

Instance is Reachable

 

The pings are successful since the AWS security policy is allowing all traffic between instances.

 

 

Test Connectivity to wordpress-db-01a Instance

 

  1. Type the following command to test the connectivity between the wordpress-web-01a and wordpress-db-01a instances:
ping -c 5 172.16.10.20

 

 

Instance is Reachable

 

The pings are successful since the AWS security policy is allowing all traffic between instances.

 

Perform port scan of the application environment


To simulate a potential hacker, an Ubuntu Linux instance has been configured with nmap to perform a port scan of the application environment in Amazon Web Services. We will scan the IP subnet where the application instances are deployed and review the open ports.


 

Nmap Instance Log In

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Open PuTTY

 

  1. Click on the PuTTY Icon on the Windows Quick Launch Task Bar. If the previous PuTTY session is still open, click on the PuTTY Icon in the upper left corner of that window and select New Session.

 

 

Enter the IP Address of the nmap-01a Instance

 

  1. Type the IP Address of the nmap-01a instance from the Account Information Page.
  2. Click Open.

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

 

Run nmap Scan of the Application IP Subnet Range

 

  1. Type the following command to start the nmap scan:
nmap -F -Pn -T5 --open 172.16.10.10-20

To speed up the scan time and reduce clutter, the nmap scanner is using the following options:

 

 

Scan Results of the Web Tier

 

The wordpress-web-01a and wordpress-web-02a instances at 172.16.10.10 and 172.16.10.11 have ports 80 and 22 open.

 

 

Scan Results of the DB Tier

 

The wordpress-db-01a instance at 172.16.10.20 has ports 80, 3306 and 22 open. As a database instance, we don't want to have port 80 open, and we only want port 3306 open to the web instances.

 

Conclusion


This completes Module 2. We have validated that the developer's WordPress application is functioning within AWS, including the load balancer. Through the review of the security policies that were applied in AWS we discovered the application is exposed to the Internet and potentially malicious attacks. Lastly, we used a common security scanner to validate the open ports and discovered a port on the database server that shouldn't be open.


 

Congratulations, you've finished Module 2

Proceed to Module 3 for an Introduction to the NSX Management Components. You may also proceed to any other module of interest.

 

Module 3 - Introduction to NSX Management Components (30 minutes)

Introduction


As part of the VMware NSX Cloud solution, separate instances are deployed in Amazon Web Services to support the Management and Operations User Interface for the solution. These instances are:

NSX Cloud Services Manager manages the complete lifecycle of deployed NSX components in AWS and provides a unified view between NSX Manager and the AWS inventory. Other functions of NSX Cloud Services Manager include:

NSX Manager provides the graphical user interface (GUI) and the REST APIs for creating, configuring, and monitoring NSX components such as the NSX controllers and logical switches. NSX Manager is the management plane for the NSX eco-system. It provides an aggregated view and is the centralized network management component of NSX. It provides a method for monitoring and troubleshooting workloads attached to virtual networks created by NSX. It provides configuration and orchestration of:

This Module contains the following lessons:


Perform log in to NSX Cloud Services Manager


One function of the NSX Cloud Services Manager is to provide a unified view of the inventory between NSX and Amazon Web Services. In this lesson we will log in to the NSX Cloud Services Manager.


 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page. If you've completed the previous lesson you can click on the account information tab that is open and proceed to the next step.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The AWS Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

 

NSX Cloud Services Manager Account Information

 

  1. Click on the NSX Cloud Services Manager DNS Name link to open a new browser tab and connect to the NSX Cloud Services Manager console.

 

 

Certificate Validation

 

The hands-on lab environments are built on-demand, so the certificates are not yet trusted. In a production deployment, a trusted certificate would be generated and used to secure connectivity. To continue the log in process:

  1. Click Advanced.
  2. Click Proceed link.

 

 

Log in to NSX Cloud Services Manager

 

  1. Type admin for the Username.
  2. Type VMware1! for the Password.
  3. Click Log In.

 

Review configured AWS account and inventory


NSX Cloud Service Manager provides a unified view of NSX and AWS inventory. We will review the inventory reported by NSX Cloud Service Manager and compare it to the AWS inventory.


 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

CSM Configuration and Inventory

 

  1. Click Cross-Cloud.

 

 

Review AWS Account Information

 

The AWS account information has been configured in Cloud Services Manager. This information will be different for each lab pod.

 

 

Review Number of Configured VPCs

 

There are 2 VPCs configured in this AWS account.

 

 

Review Number of Configured Instances

 

There are 7 instances running in this AWS account.

 

 

Click VPCs

 

  1. Click VPCs.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs.

 

 

 

Review VPCs

 

These are the two VPCs we saw in the AWS inventory in previous lessons.

 

 

Management VPC Deployment Indication

 

The Management VPC includes an icon that shows NSX management components are installed in this VPC.

 

 

Management VPC Instances

 

  1. Click Instances in the Management-VPC.

 

 

Compare Management VPC Instances to AWS Inventory

 

The NSX components that were reported in the AWS inventory are listed.

 

 

Click VPCs

 

  1. Click VPCS at the top of the screen to go back to the list of VPCs.

 

 

Confirm VPC is not Managed by NSX

 

The Compute VPC reports a Status of "NSX Managed - No." Later in this lab we will deploy NSX components in this VPC to manage the running AWS EC2 instances.

 

 

Click Instances

 

  1. Click Instances in the Compute-VPC.

 

 

Confirm Instances are not Managed by NSX

 

The AWS EC2 instances for the 2-tier WordPress application that were reported in the AWS inventory are listed. The NSX State circle is not green because NSX components have not been deployed.

 

Perform log in to NSX Manager


As the centralized management plane for the solution, we will be using NSX Manager to configure security policies for our WordPress application, as well as to validate the successful deployment of NSX in Amazon Web Services. In this lesson we will log in to NSX Manager.


 

Accessing NSX Manager

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another and click on the Account Info bookmark.

 

 

NSX Manager Account Information

 

  1. Click on the NSX Manager DNS Name link to open a new browser tab and connect to the NSX Manager console.

 

 

Certificate Validation

 

The hands-on lab environments are built on-demand, so the certificates are not yet trusted. In a production deployment, a trusted certificate would be generated and used to secure connectivity. To continue the log in process:

  1. Click Advanced.
  2. Click Proceed link.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1! for the Password.
  3. Click Log In.

 

Review NSX Manager User Interface


In preparation for the deployment of NSX in Amazon Web Services to manage our application, we will walk through several of the NSX Manager User Interface screens to view the current configuration of the lab environment, validate that the NSX management infrastructure is functional, and get familiar with the new HTML5 interface.


 

Click Dashboard

 

  1. Click Dashboard.

 

 

Management Cluster Status is Up

 

The status of the Management Cluster (NSX Manager) is reported. The Manager Connection reports as Up.

 

 

Controller Cluster Status is Up

 

Scrolling down below the Management Cluster status, we see the the status of the Controller Cluster (NSX Manager) is reported as Up.

 

 

Click Fabric

 

  1. Click Fabric on the left.

 

 

Review Fabric Status

 

As a fresh deployment of NSX, the Fabric inventory will be empty.

  1. Click each of the options at the top of the screen, starting with Hosts and ending with Transport Nodes, to validate that each is empty.

We will return to this inventory in upcoming lessons to validate that the NSX deployment is operational.

 

 

Click Inventory

 

  1. Click Inventory on the left.

 

 

Review Configured Grouping Objects

 

This section will include the grouping objects that simplify the creation of security policies in NSX.

  1. Click each of the options at the top of the screen, starting with Groups and ending with MAC Sets, to validate that each are empty.

In upcoming lessons we will return here to create dynamic grouping objects for the application security policies.

 

 

Click Firewall

 

  1. Click Firewall on the left.

 

 

Review Default Firewall Policy Configured

 

The default NSX firewall policy has been deployed. We will return to this screen in an upcoming lesson to configure the application security policies.

 

 

Click Switching

 

  1. Click Switching on the left.

 

 

Confirm Logical Switch Inventory is Empty

 

No Logical Switches have been created. We will create a new logical switch in an upcoming lesson to attach our application instances.

 

Conclusion


This completes Module 3. We have logged into the NSX Cloud Services Manager (CSM) that is deployed in Amazon Web Services. The NSX CSM acts as the operations user interface for the VMware NSX Cloud solution. We also reviewed the AWS inventory from within NSX CSM. We have also logged into the NSX Manager that is deployed in Amazon Web Services. We reviewed the inventory of NSX objects to confirm only the defaults are present and to get familiarity with the new HTML5 interface.


 

Congratulations, you've finished Module 3

Proceed to Module 4 to secure the application environment with NSX. You may also proceed to any other module of interest.

 

Module 4 - Securing Applications with NSX (60 minutes)

Introduction


Securing the WordPress application in Amazon Web Services (AWS) requires security policies for the instances that will be NSX managed. NSX provides a distributed firewall with logical grouping capabilities to simplify configuration and provide consistency.

After the Central Management Plane (NSX Manager and NSX Cloud Services Manager) and Central Control Plane (NSX Controllers) have been deployed in the Management VPC, the following steps are required to secure instances in AWS:

  1. An NSX Cloud Gateway is deployed in each Compute VPC with instances to be managed by NSX.
  2. A Cloud Administrator will create Logical Networks and Security Policies using the NSX Manager UI or APIs.
  3. A Cloud Administrator will generate a set of tags in NSX Cloud Services Manager.
  4. A Developer will apply the tags to their instances in AWS for consumption of NSX policies at the time of instance creation.
  5. The NSX Agent is installed on each AWS instance to be managed by NSX.

This Module contains the following lessons that will result in the securing of the WordPress application:


 

Required Security Policies

 

The WordPress application requires the following security policies:

The nmap instance is outside the scope of the security policies, and is provided as a tool to assess the security posture of the application in this lab.

 

Deploy NSX Cloud Gateway in Amazon Web Services


NSX needs to be deployed to provide security policies for the application instances in Amazon Web Services. The first step is to deploy the NSX Cloud Gateway in the Compute VPC where the application instances are deployed.

As an Edge Transport Node in NSX, the NSX Cloud Gateway provides the following services in each VPC it is deployed:


 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page. If you've completed the previous lesson you can click on the account information tab that is open and proceed to the next step.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The AWS Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

 

NSX Cloud Services Manager Account Information

 

  1. Click on the NSX Cloud Services Manager DNS Name link to open a new browser tab and connect to the NSX Cloud Services Manager console.

 

 

Certificate Validation

 

The hands-on lab environments are built on-demand, so the certificates are not yet trusted. In a production deployment, a trusted certificate would be generated and used to secure connectivity. To continue the log in process:

  1. Click Advanced.
  2. Click Proceed link.

 

 

Log in to NSX Cloud Services Manager

 

  1. Type admin for the Username.
  2. Type VMware1! for the Password.
  3. Click Log In.

 

 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

CSM Configuration and Inventory

 

  1. Click Cross-Cloud.

 

 

Click VPCs

 

  1. Click VPCs to return to the view of Management-VPC and Compute-VPC.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs.

 

 

 

Click Actions Pull-Down Menu

 

  1. Click Actions in the Compute-VPC box.
  2. Click Deploy NSX Cloud Gateway.

 

 

Provide NSX Cloud Gateway Configuration Settings

 

  1. Select Private IP.
  2. Click PEM File and select nsx-management.
  3. Disable Quarantine Policy.
  4. Click Next.

 

 

Configure High Availability Settings

 

The NSX Cloud Gateway supports a High Availability (HA) deployment model. To reduce the amount of time it takes to complete the lab, we will not configure HA.

  1. Uncheck the Enable HA for NSX Cloud Gateway box.
  2. Select your Availability Zone. Note: If the wrong availability zone is selected, the subnet menus for steps 3-5 will be empty.
  3. Select nsx-uplink-subnet for the Uplink Subnet.
  4. Select nsx-downlink-subnet for the Downlink Subnet.
  5. Select nsx-compute-mgmt-subnet for the Management Subnet.
  6. Click Deploy.

 

 

NSX Cloud Gateway Begins Deployment

 

The deployment process begins for this VPC. It can take approximately 5 minutes to complete. The deployment progress screen will report on the actions being completed in the process.

Deployment of the NSX Cloud Gateway provides the local control plane for NSX policies in our VPC, as well as an installation location for the NSX Agents that will be deployed in an upcoming lesson.

Continue to the next lesson to configure logical groupings and firewall policies while the NSX Cloud Gateway deployment completes. We will then return to NSX Cloud Services Manager to verify completion.

 

Create Logical Groupings and Firewall Policies


NSX is able to leverage contextual information about workloads to create dynamic policy groups. This provides a greatly simplified operational model for security policy management. In this lesson we will create several dynamic security groups to simplify policy management.


 

Accessing NSX Manager

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another and click on the Account Info bookmark.

 

 

NSX Manager Account Information

 

  1. Click on the NSX Manager DNS Name link to open a new browser tab and connect to the NSX Manager console.

 

 

Certificate Validation

 

The hands-on lab environments are built on-demand, so the certificates are not yet trusted. In a production deployment, a trusted certificate would be generated and used to secure connectivity. To continue the log in process:

  1. Click Advanced.
  2. Click Proceed link.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1! for the Password.
  3. Click Log In.

 

 

Click Groups in the Inventory Menu

 

  1. Click Inventory.
  2. Click Groups.

 

 

Create Web Group

 

  1. Click Groups at the top of the screen.
  2. Click Add.

 

 

Group Name is Web

 

  1. Type Web for the group Name.
  2. Click Membership Criteria.

 

 

Click Criteria

 

  1. Click Criteria.

 

 

Membership Criteria Based on VM Named Web

 

  1. Select Virtual Machine.
  2. Select Name.
  3. Select Contains.
  4. Type web.
  5. Click Save.

 

 

Create DB Group

 

  1. Click Add.

 

 

Group Name is DB

 

  1. Type DB for the group Name.
  2. Click Membership Criteria.

 

 

Click Criteria

 

  1. Click Criteria.

 

 

Membership Criteria Based on VM Named DB

 

  1. Select Virtual Machine.
  2. Select Name.
  3. Select Contains.
  4. Type db.
  5. Click Save.

 

 

Create App Isolation Group

 

  1. Click Add.

 

 

Group Name is Wordpress-app

 

  1. Type Wordpress-app for the group Name.
  2. Click Membership Criteria.

 

 

Click Criteria

 

  1. Click Criteria.

 

 

All VMs Containing Wordpress Will Be Members

 

  1. Select Virtual Machine.
  2. Select Name.
  3. Select Contains.
  4. Type wordpress.
  5. Click Save.

 

 

Review Created NSGroups

 

The three NSGroups have been successfully created.

These will be used in the firewall policies that we will create next.

 

 

Click Firewall

 

  1. Click Firewall on the left side.

 

 

Select Default Layer3 Section

 

  1. Click Default Layer3 Section if it isn't already selected (outlined with a blue box).

 

 

Add a new section above

 

  1. Click Add Section.
  2. Click Add Section Above.

 

 

Section name will be wordpress-app

 

  1. Type Wordpress-App for Section Name.
  2. Select NSGroup in the dropdown for the Applied To Type.
  3. Select the Wordpress-app group created previously.
  4. Click the Right Arrow to add to the Selected box.
  5. Click Save.

 

 

Click on newly created section

 

Now we have a firewall section for our WordPress Application.

  1. Click the Wordpress-App Section and make sure it is highlighted with a blue box.

 

 

Add a new rule below

 

  1. Click Add Rule.
  2. Click Add Rule Below.

 

 

Hover the mouse pointer over name and click the pencil

 

  1. Move the mouse pointer to the blank area under Name.
  2. Click the Pencil.

 

 

Rule name is Any to Web

 

  1. Type Any to Web for the Rule Name.
  2. Click Ok.

 

 

Hover the mouse pointer over destinations and click the pencil

 

  1. Move the mouse pointer to the blank area under Destinations.
  2. Click the Pencil.

 

 

Select the Web group as the destination

 

  1. Select NSGroup from the pulldown menu.
  2. Select the Web group.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Hover the mouse pointer over services and click the pencil

 

  1. Move the mouse pointer to the blank area under Services.
  2. Click the Pencil.

 

 

Select the HTTP service

 

  1. Type http.
  2. Select HTTP.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Add a new rule below

 

  1. Click Add Rule.
  2. Click Add Rule Below.

 

 

Hover the mouse pointer over name and click the pencil

 

  1. Move the mouse pointer to the blank area under Name.
  2. Click the Pencil.

 

 

Rule name is Web to DB

 

  1. Type Web to DB for the Rule Name.
  2. Click Ok.

 

 

Hover the mouse pointer over sources and click the pencil

 

  1. Move the mouse pointer to the blank area under Sources.
  2. Click the Pencil.

 

 

Select the Web group as the source

 

  1. Select NSGroup from the pulldown menu.
  2. Select the Web group.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Hover the mouse pointer over destinations and click the pencil

 

  1. Move the mouse pointer to the blank area under Destinations.
  2. Click the Pencil.

 

 

Select the DB group as the destination

 

  1. Select NSGroup from the pulldown menu.
  2. Select the DB group.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Hover the mouse pointer over services and click the pencil

 

  1. Move the mouse pointer to the blank area under Services.
  2. Click the Pencil.

 

 

Select the MySQL service

 

  1. Type MYSQL.
  2. Select MySQL.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Add another rule below

 

  1. Click Add Rule.
  2. Click Add Rule Below.

 

 

Hover the mouse pointer over name and click the pencil

 

  1. Move the mouse pointer to the blank area under Name.
  2. Click the Pencil.

 

 

Group name is Allow SSH

 

  1. Type Allow SSH for the Rule Name.
  2. Click Ok.

 

 

Hover the mouse pointer over destinations and click the pencil

 

  1. Move the mouse pointer to the blank area under Destinations.
  2. Click the Pencil.

 

 

Select the wordpress-app group as the destination

 

  1. Select NSGroup from the pulldown menu.
  2. Select the Wordpress-app group.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Hover the mouse pointer over services and click the pencil

 

  1. Move the mouse pointer to the blank area under Services.
  2. Click the Pencil.

 

 

Select the SSH service

 

  1. Type SSH.
  2. Select SSH.
  3. Click the Right Arrow to move it to the Selected box.
  4. Click OK.

 

 

Add another rule below

 

  1. Click Add Rule.
  2. Click Add Rule Below.

 

 

Hover the mouse pointer over name and click the pencil

 

  1. Move the mouse pointer to the blank area under Name.
  2. Click the Pencil.

 

 

Rule name is Deny All

 

  1. Type Deny All for the Rule Name.
  2. Click Ok.

 

 

Hover the mouse pointer over action and click the pencil

 

  1. Move the mouse pointer to the blank area under Action.
  2. Click the Pencil.

 

 

Select the option to drop the traffic

 

  1. Select Drop from the Action drop down menu.
  2. Click OK.

 

 

Click Save

 

  1. Click Save. Note: You may need to scroll back up to the top.

 

 

Save the section

 

  1. Click Save.

 

 

Review the configured policies

 

The security policies for the WordPress application have been created. We are allowing HTTP traffic from the internet to our Web servers, MySQL (port 3306) traffic from the Web servers to the DB server, and SSH traffic to all of our servers. Everything else is denied (dropped).

We leveraged the NSGroups that we created earlier to simplify the source, destination, and firewall section configuration.

Next we will return to NSX Cloud Services Manager to check on the deployment progress of our NSX Cloud Gateway.

 

 

Return to NSX Cloud Services Manager

 

  1. Select the NSX Cloud Services Manager browser tab in Google Chrome that was opened previously. Note: The order of browser tabs may differ if you have completed previous Modules.

 

 

NSX Cloud Gateway Deployment is Completed

 

  1. Click Finish when deployment is complete.

 

 

Compute-VPC is NSX Managed

 

The Compute-VPC now reports as NSX Managed with a Cloud Gateway deployed.

 

Applying Tags to the Application Instances


NSX-specific Amazon Web Services Tags are used to indicate where the EC2 instance's network interface should be logically "attached" in NSX. During attachment, security policies are pushed. Prior to enabling the NSX Agent on the WordPress application instances in AWS, we will configure the Tag on their network interfaces.


 

Accessing AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Log in to the AWS Console

 

  1. Type vmware_hol_user for the AWS Management User Name.
  2. Type or copy the Password from the Account Information Page.
  3. Click the Sign In button.

 

 

 

Select Region

 

Verify that the console is viewing North California region resources.

  1. Click the Region Name to the left of Support in the upper right.
  2. Select US West (N. California).

 

 

Navigate to EC2 Instances

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances in the menu on the left.

 

 

Widen the Name Column

 

  1. Move the mouse over the column divider and then click and drag right to expand the Name column.

 

 

Select the first WordPress Web instance

 

  1. Select wordpress-web-01a.

 

 

Click the Tags tab for this instance

 

  1. Click the Tags tab below the list of EC2 instances.
  2. Click Add/Edit Tags.

 

 

Click Create Tag

 

  1. Click Create Tag.
  2. Type nsx:network under Key.
  3. Type default under Value.
  4. Click Save.

 

 

Click Instances

 

  1. Click Instances in the menu on the left.

 

 

Select the second WordPress Web instance

 

  1. Select wordpress-web-02a.

 

 

Click the Tags tab for this instance

 

  1. Click the Tags tab below the list of EC2 instances.
  2. Click Add/Edit Tags.

 

 

Click Create Tag

 

  1. Click Create Tag.
  2. Type nsx:network under Key.
  3. Type default under Value.
  4. Click Save.

 

 

Click Instances

 

  1. Click Instances in the menu on the left.

 

 

Select the WordPress DB instance

 

  1. Select wordpress-db-01a.

 

 

Click the Tags tab for this instance

 

  1. Click the Tags tab below the list of EC2 instances.
  2. Click Add/Edit Tags.

 

 

Click Create Tag

 

  1. Click Create Tag.
  2. Type nsx:network under Key.
  3. Type default under Value.
  4. Click Save.

 

 

Summary

We have applied the NSX-specific AWS Tag to the WordPress application instances. Once the NSX Agent is deployed, this tag will "attach" the instances to the default NSX Logical Switch that was created during the NSX Cloud Gateway deployment. Security policies will also be applied to these instances.

 

Installation of NSX Agent


To continue the process of securing the WordPress Application instances, the NSX Agent must be deployed on each of the instances. The NSX Agent provides the data plane functions within each Amazon Web Services instance where it is installed. This includes:

A best practice would be to include the agent in the "gold master" images that are used in an organization's Amazon Web Services environment. The NSX Agent can also be installed in existing deployed, or brownfield, instances.

The NSX Agent will be deployed on each of the WordPress application instances via a script.


 

Install on First Web Instance

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate Instance Information

 

  1. Locate the Wordpress-web-01a Instance Public IP address that will be used to log in to the instance.

 

 

Open PuTTY

 

  1. Click on the PuTTY Icon on the Windows Quick Launch Task Bar. If the wordpress-web-01a PuTTY session (172.16.10.10) is still open, select that window from the task bar and skip ahead to Enable the NSX Agent.

 

 

Type the IP Address of wordpress-web-01

 

  1. Type the IP Address of the wordpress-web-01a instance from the Account Information Page.
  2. Click Open.

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

 

Install the NSX Agent

 

  1. Type the following command to start the NSX Agent installation script:
./install_agent.sh

 

 

NSX Agent has been installed

 

The NSX Agent installation can take 3-5 minutes to complete. Once installation is complete, the NSX Agent starts and reports a status of OK.

 

 

Install on Second Web Instance

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate Instance Information

 

  1. Locate the Wordpress-web-02a Instance Public IP address that will be used to log in to the instance.

 

 

Open PuTTY

 

  1. Switch to the PuTTY window and click on the PuTTY Icon in the upper left of the open PuTTY session.
  2. Select New Session.

 

 

Type the IP address of wordpress-web-02a

 

  1. Type the IP Address of the wordpress-web-02a instance from the Account Information Page.
  2. Click Open.

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

 

Install the NSX Agent

 

  1. Type the following command to start the NSX Agent installation script:
./install_agent.sh

 

 

NSX Agent has been installed

 

The NSX Agent installation can take 3-5 minutes to complete. Once installation is complete, the NSX Agent starts and reports a status of OK.

 

 

Install on DB Instance

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate Instance Information

 

  1. Locate the Wordpress-db-01a Instance Public IP address that will be used to log in to the instance.

 

 

Open PuTTY

 

  1. Switch to the PuTTY window and click on the PuTTY Icon in the upper left of the open PuTTY session.
  2. Select New Session.

 

 

Type the IP address of wordpress-db-01a

 

  1. Type the IP Address of the wordpress-db-01a instance from the Account Information Page.
  2. Click Open.

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

 

Install the NSX Agent

 

  1. Type the following command to start the NSX Agent installation script:
./install_agent.sh

 

 

NSX Agent has been installed

 

The NSX Agent installation can take 3-5 minutes to complete. Once installation is complete, the NSX Agent starts and reports a status of OK..

 

Validate NSX Deployment


Following the deployment of the NSX components in the Compute-VPC, we will walk through the NSX configuration in NSX Manager and NSX Cloud Services Manager to verify operation.


 

Log in to NSX Manager

Select the NSX Manager browser tab in Google Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the NSX Manager URL from the Account Information browser tab.

 

Note: If the page has timed out enter admin for the username and VMware1! for the password and click Log In to continue.

  1. Click on the NSX Manager DNS Name link to open a new browser tab and connect to the NSX Manager console.

 

 

Click Fabric

 

  1. Click Fabric on the left.

 

 

Click Edges

 

  1. Click Edges at the top.

 

 

A Newly Created Edge Node

 

A new Edge node has been created.

Note: You may need to refresh the browser if nothing is displayed.

 

 

Click Edge Clusters

 

  1. Click Edge Clusters at the top.

 

 

A Newly Created Edge Cluster

 

A new Edge Cluster has been created.

Note: You may need to refresh the browser if nothing is displayed.

 

 

Click Transport Nodes

 

  1. Click Transport Nodes at the top.

 

 

A Newly Created Transport Node

 

A new Transport Node has been created (the newly deployed Cloud Gateway).

Note: You may need to refresh the browser if nothing is displayed.

 

 

Click Switching

 

  1. Click Switching on the left.

 

 

Click Switches

 

  1. Click Switches at the top.

 

 

Switch Inventory Changes

 

Two Logical Switches are created, and there are 4 Logical Ports on the Default Logical Switch.

Note: You may need to refresh the browser if nothing is displayed.

 

 

Click Groups under Inventory

 

  1. Click Inventory.
  2. Click Groups.

 

 

Click the Wordpress-app NSGroup

 

  1. Click Wordpress-app.

 

 

Group membership

 

The Wordpress-app group has 3 Virtual Machines as effective members.

  1. Click 3 next to Virtual Machine.

 

 

The WordPress instances are listed as members

 

The WordPress application instances are all present as effective members of this group (criteria was VM name contains 'wordpress').

 

 

Open AWS Management Console

Select the AWS Console tab in Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the AWS Console URL link from the Account Information browser tab, vmware_hol_user for the User Name and type or copy the password from the Account Information Page.

Note: If the AWS Console page has timed out enter vmware_hol_user for the User Name and VMware1!! for the Password to continue.

 

 

Navigate to EC2 Dashboard in AWS Console

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

New Instance for NSX Cloud Gateway

 

A new EC2 Instance has been created for the NSX Cloud Gateway.

 

 

Click Security Groups

 

  1. Click on Security Groups on the left under Network & Security.

 

 

NSX Cloud Gateway Security Groups in AWS

 

Several new AWS Security Groups were created for application instances and to control traffic in/out of the NSX Cloud Gateway.

 

 

Log in to NSX Cloud Services Manager

Select the NSX Cloud Services Manager browser tab in Google Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the NSX Cloud Services Manager URL from the Account Information browser tab.

Note: If the page has timed out enter admin for the username and VMware1! for the password and click Log In to continue.

 

 

CSM Configuration and Inventory

 

  1. Click the VPC-AWS Console tab.
  2. Click Accounts at the top of the screen.

 

 

Refresh the AWS account information

 

  1. Click Actions.
  2. Click Resync Account.

This will take 20-60 seconds to complete.

 

 

Click VPCs

 

  1. Click VPCs.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs.

 

 

 

Click Instances

 

  1. Click Instances in the Compute-VPC.

 

 

WordPress instances are managed by NSX

 

  1. Our Wordpress application instances report as managed by NSX.
  2. The nmap-01 instance did not receive an AWS Tag or an NSX Agent install.

 

Validation of WordPress application functionality


Prior to NSX deployment, the 2-tier WordPress application running in Amazon Web Services was left wide open to the Internet and several unneeded ports were exposed as potential attack surfaces. This lesson will revisit the application functionality and test basic connectivity.


 

Account Information

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another and click on the Account Info bookmark.

 

 

Locate the WordPress Application Information

 

  1. Click on the WordPress Application Elastic Load Balancer DNS Name link to open a new browser tab and connect to the WordPress application.

 

 

Refresh WordPress site to validate functionality

 

Verify that the WordPress application is functioning. The IP address of the server presenting the page is noted.

  1. Refresh the browser a few times to see the Server IP address change to the other web server (172.16.10.10 and 172.16.10.11).

 

 

Open Account Information Page

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another and click on the Account Info bookmark.

 

 

Locate Web Server Information

 

  1. Locate the Wordpress-web-01a Instance Public IP address that will be used to log in to the instance.

 

 

Open PuTTY

 

  1. Click on the PuTTY Icon on the Windows Quick Launch Task Bar. If the previous PuTTY session is still open, click on the PuTTY Icon in the upper left corner of that window and select New Session.

 

 

Type the IP Address of wordpress-web-01a

 

  1. Type the IP Address of the wordpress-web-01a instance.
  2. Click Open.

 

 

Test connectivity to wordpress-web-02a

 

  1. Type the following command to test the connectivity between the wordpress-web-01a and wordpress-web-02a instances:
ping -c 5 172.16.10.11

 

 

Instance is not reachable via ICMP

 

The pings are unsuccessful. This matches the security policy we configured in NSX.

 

 

Test connectivity to wordpress-db-01a

 

  1. Type the following command to test the connectivity between the wordpress-web-01a and wordpress-db-01a instances:
ping -c 5 172.16.10.20

 

 

Instance is not reachable via ICMP

 

The pings are unsuccessful. This matches the security policy we configured in NSX.

 

Perform security scan of application environment


We will revisit the Ubuntu Linux instance with nmap to perform a port scan of the application environment in Amazon Web Services. We will scan the IP subnet where the application instances are deployed and review the open ports following the deployment of NSX in the environment to ensure the unneeded ports are closed.


 

Nmap Instance Log In

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Open PuTTY

 

  1. Click on the PuTTY Icon on the Windows Quick Launch Task Bar. If the previous PuTTY session is still open, click on the PuTTY Icon in the upper left corner of that window and select New Session.

 

 

Type the IP Address of nmap-01a

 

  1. Type the IP Address of the nmap-01a instance from the Account Information Page.
  2. Click Open.

 

 

Run nmap scan

 

  1. Type the following command to start the nmap scan:
nmap -F -Pn -T5 --open 172.16.10.10-20

To speed up the scan time and reduce clutter, the nmap scanner is using the following options:

 

 

Web instance results

 

The wordpress-web-01a and wordpress-web-02a instances at 172.16.10.10 and 172.16.10.11 have ports 80 and 22 open, as expected with the configured NSX security policies.

 

 

 

DB Instance results

 

Based on the configured NSX security policies, the wordpress-db-01a instance at 172.16.10.20 only reports port 22 as being open to the nmap instance.

Note: Leave the nmap-01a PuTTY session open for the next lesson.

 

Quarantine Policy


NSX Cloud provides the capability to detect and quarantine rogue instances in a VPC. For example, if a person with malicious intent forcibly stops the NSX Agent on an NSX managed instance, the compromised instance will be quarantined using the default Security Group in Amazon Web Services (AWS). NSX Cloud uses AWS Security Groups in conjunction with the VPC’s Quarantine Policy. During the deployment of the NSX Cloud Gateway in a previous lesson, NSX Cloud created additional Security Groups in AWS and modified the default Security Group to limit access. You can enable or disable Quarantine Policy on a per-VPC basis.

We'll be demonstrating this feature by turning on the Quarantine policy and observing the EC2 instance Security Group changes in the AWS management console. We will also observe that the EC2 instance without the NSX Agent loses connectivity.

When Quarantine Policy is enabled:


 

Open AWS Management Console

Select the AWS Console tab in Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the AWS Console URL link from the Account Information browser tab, vmware_hol_user for the User Name and type or copy the Password from the Account Information Page. Enter this same information if the console has timed out.

 

 

Navigate to EC2 Dashboard in AWS Console

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

Select the wordpress-web-01a Instance

 

  1. Select the wordpress-web-01a instance.

 

 

Open the Inbound Rules

 

  1. Click view inbound rules at the bottom of the screen in the Description tab for that instance. This instance has been configured with an AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Web and SSH traffic are allowed from the HOL Main Console (Source IP ranges may vary). All traffic between application instances is allowed within the AWS VPC environment.

 

 

Select the nmap-01a Instance

 

  1. Select the nmap-01a instance.

 

 

Open the Inbound Rules

 

  1. Click view inbound rules at the bottom of the screen in the Description tab for that instance. This instance has been configured with an AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Web and SSH traffic are allowed from the HOL Main Console (Source IP ranges may vary). All traffic between application instances is allowed within the AWS VPC environment.

Note: The nmap-01a instance currently has SSH (port 22) allowed inbound. Later in this lesson we will observe a Security Group change as a result of Quarantine Policy which will remove SSH access to this instance.

 

 

Log in to NSX Cloud Services Manager

Select the NSX Cloud Services Manager browser tab in Google Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the NSX Cloud Services Manager URL from the Account Information browser tab.

Note: If the page has timed out enter admin for the username and VMware1! for the password and click Log In to continue.

 

 

Zoom Browser

 

The next few steps to enable Quarantine Policy perform better with the browser zoom set to 100% to improve readability. It is recommended that you adjust the Zoom setting in Google Chrome back to 100%. Note: You'll be prompted to change the zoom setting back to 90% following the Quarantine Policy setting steps.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '+' next to Zoom to adjust the setting to 100%.

 

 

CSM Configuration and Inventory

 

  1. Click the VPC-AWS Console tab.
  2. Click VPCS at the top of the screen.

 

 

Edit Quarantine

 

  1. Click Actions in the Compute-VPC.
  2. Click Edit Quarantine.

 

 

Turn on Quarantine

 

  1. Click Default Quarantine slider to On.
  2. Click Save.

 

 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

Open AWS Management Console

Select the AWS Console tab in Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the AWS Console URL link from the Account Information browser tab, vmware_hol_user for the User Name and type or copy the Password from the Account Information Page. Enter this same information if the console has timed out.

 

 

Navigate to EC2 Dashboard in AWS Console

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

Select the wordpress-web-01a Instance

 

  1. Select the wordpress-web-01a instance.

 

 

Open the Inbound Rules

 

  1. Click view inbound rules at the bottom of the screen in the Description tab for that instance. This instance has been changed to the vm-underlay-sg AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Turning on Quarantine moves all instances that are NSX Managed to the vm-underlay-sg Security Group. This Security Group allows all traffic to the instance from the AWS network, but NSX Cloud is enforcing security policy to each instances as was configured earlier in the lesson.

 

 

Select the nmap-01a Instance

 

  1. Select the nmap-01a instance.

 

 

Open the Inbound Rules

 

Since this instance does not have the NSX Agent installed, the quarantine policy has moved the instance to the default AWS Security Group for the Compute-VPC. Now we'll look closer at the default Security Group changes.

 

 

Click Security Groups

 

  1. Click on Security Groups on the left under Network & Security.

 

 

Select the Compute VPC Default Security Group

 

  1. Select the DEFAULT-nsx-compute-security-group security group.

 

 

Click Inbound

 

  1. Click the Inbound tab to view the inbound rules. The only rule is allowing all traffic within the same (default) security group. This blocks our SSH connection. In a production environment a bastion or jump host would be needed in the same security group to restore access to quarantined instances.

 

 

Click Outbound

 

  1. Click the Outbound tab to view the outbound rules. The rules are setup to allow communication to the NSX Cloud Gateway so the instance could install the NSX Agent.

 

 

Verify nmap-01a SSH connection is lost

 

The PuTTY window for nmap-01a will now be unresponsive and an connection error message may appear.

 

 

Refresh WordPress site to validate functionality

 

Verify that the WordPress application is functioning. The IP address of the server presenting the page is noted.

  1. Click the tab with the Wordpress application. If the tab was closed, re-open by selecting the link the the Account Info page.
  2. Refresh the browser a few times to verify the application is still functioning.

Turning on the Quarantine Policy in the Compute-VPC has successfully quarantined the instance that was not properly managed by NSX, without impacting the Wordpress application.

 

Traffic Visibility


NSX provides additional operational tools to give visibility into the traffic occurring in an application environment running in Amazon Web Services. We will look at some of the traffic statistic aggregation features of NSX.


 

Log in to NSX Manager

Select the NSX Manager browser tab in Google Chrome that was opened previously. If this browser tab has been closed open a new browser tab using the NSX Manager URL from the Account Information browser tab.

Note: If the page has timed out enter admin for the username and VMware1! for the password and click Log In to continue.

 

 

Click Firewall

 

  1. Click Firewall on the left side.

 

 

Firewall Statistics

 

  1. The Stats column displays the packets, bytes and number of sessions for each rule.

 

 

Click Switching

 

  1. Click Switching.

 

 

Click Logical Ports for Default Switch

 

  1. Click 4 under Logical Ports.

 

 

Click on a Logical Port

 

Here we see the 3 WordPress application instances that we enabled NSX for security, plus the uplink port.

  1. Click the first Logical Port listed with "Cloud" prefix

 

 

Click Monitor

 

Additional information about this port is available.

  1. Click Monitor.

 

 

Port Statistics

 

NSX provides traffic statistics for this WordPress application instance.

 

 

Click Begin Tracking

 

  1. Click Begin Tracking to start the switch port statistic tracking feature (it opens a new browser tab).

 

 

Track Switch Port Statistics

 

NSX provides near-real time statistic tracking for this switch port. You can switch over to the WordPress website broswer tab and refresh the page a few times to generate traffic and then review this page.

 

Conclusion


This completes Module 4, and the Hands-On Lab. The WordPress application that was deployed in Amazon Web Services has been successfully secured by installing NSX components in Amazon Web Services and applying consistent security policies to the application instances.


 

Congratulations, you've finished Module 4 and the Hands-On Lab!

Follow the instructions at the end of this lesson to end the lab. You may also proceed to any other module of interest.

 

 

How to End Lab

 

To end your 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-1822-01-NET

Version: 20180412-122736