VMware NSX-T Data Center for

Intrinsic Security [3.1]

Lecture 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]

Lecture Manual

NSX-T Data Center 3.1

Part Number EDU-EN-NSXTIS31-LECT (04/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® vMotion®, VMware
vSphere® Client™, VMware vSphere®, VMware vRealize® Network Insight Cloud™, VMware vRealize®
Network Insight™, VMware vRealize® Log Insight™ for vCenter™, VMware vRealize® Log Insight™, VMware
vRealize® Automation™ , VMware vRealize®, VMware vCloud®, VMware vCenter Server®, VMware
Workspace ONE® UEM, VMware Workspace ONE® Trust Network, VMware Workspace ONE®
Intelligence™, VMware Workspace ONE® Access™, VMware Workspace ONE®, VMware Workspace ONE®
for React Native, VMware Workbench, VMware View®, VMware Horizon® View™, Not a trademarked name,
VMware Verify™, VMware Validated Design™ for Software-Defined Data Center, VMware Validated
Design™ for IT Automation Cloud, VMware Tanzu™, VMware SD-WAN™ by VeloCloud®, VMware SD-
WAN™ by VeloCloud® – WFH Pro Subscription, VMware SD-WAN™ by VeloCloud® – WFH Subscription,
VMware SD-WAN™, VMware SD-WAN™ for AWS GovCloud (US), VMware Horizon® 7, VMware Horizon®
7, VMware Horizon® 7 on VMware Cloud™ on AWS, VMware Dynamic Environment Manager™, VMware
Customer Connect™, VMware Cloud™ on AWS GovCloud (US), VMware Cloud™ on AWS Outposts,
VMware Carbon Black, VMware Unified Access Gateway™, VMware Tanzu™ Kubernetes Grid™ Integrated
Edition, VMware SDDC Health Monitoring Solution™, VMware NSX-T™ Data Center, VMware NSX-T™,
VMware NSX® Service-defined Firewall™, VMware NSX® Network Detection and Response™, VMware
NSX® Manager™, VMware NSX® Intelligence™, VMware NSX® Firewall for Bare Metal, VMware NSX®
Firewall with Advanced Threat Prevention, VMware NSX® Firewall, VMware NSX® Edge™, VMware NSX®
Distributed IDS/IPS™, VMware NSX® Data Center Enterprise Plus, VMware NSX® Data Center, VMware
NSX Cloud™, VMware NSX® Advanced Load Balancer™, VMware NSX® Advanced Load Balancer™ – Basic
Edition, VMware NSX® API™, VMware NSX®, VMware vCenter® Log Insight™, VMware Lab Connect™,
VMware Go™, 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.

www.vmware.com/education
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.
Contents

Module 1 Course Introduction.............................................................................................. 1

1-2 Course Introduction ................................................................................................................................. 1
1-3 Importance ................................................................................................................................................... 1
1-4 Learner Objectives (1) ............................................................................................................................ 2
1-5 Learner Objectives (2) ........................................................................................................................... 2
1-6 Course Outline ........................................................................................................................................... 3
1-7 Typographical Conventions ................................................................................................................. 4
1-8 References.................................................................................................................................................. 5
1-9 VMware Online Resources ................................................................................................................... 6
1-10 VMware Learning Overview................................................................................................................ 7
1-11 VMware Certification Overview ........................................................................................................ 8
1-12 VMware Credentials Overview .......................................................................................................... 9

Module 2 Security Basics..................................................................................................... 11

2-2 Importance .................................................................................................................................................. 11
2-3 Module Lessons ........................................................................................................................................ 11
2-4 Lesson 1: Introduction to Security .................................................................................................... 12
2-5 Learner Objectives ................................................................................................................................. 12
2-6 Information Security ............................................................................................................................... 13
2-7 Specialized Areas of Security ........................................................................................................... 14
2-8 Information Security Management Framework .......................................................................... 15
2-9 Defense in Depth .................................................................................................................................... 17
2-10 Confidentiality, Integrity, and Availability Triad ...........................................................................19
2-11 About Confidentiality........................................................................................................................... 20
2-12 About Integrity ......................................................................................................................................... 21
2-13 About Availability ................................................................................................................................... 22
2-14 Authentication, Authorization, Accountability............................................................................ 23
iii
2-15 Risks, Threats, and Vulnerabilities .................................................................................................... 25
2-16 Knowledge Check: Introduction to Security ...............................................................................26
2-17 Review of Learner Objectives .......................................................................................................... 27
2-18 Lesson 2: Introduction to Firewalls .................................................................................................28
2-19 Learner Objectives ................................................................................................................................28
2-20 About Firewalls (1) .................................................................................................................................29
2-21 About Firewalls (2) ............................................................................................................................... 30
2-22 Firewall Rules ............................................................................................................................................ 31
2-23 Types of Firewalls .................................................................................................................................. 32
2-24 About Stateless Firewalls ................................................................................................................... 33
2-25 Stateless Firewalls: Traffic Management ..................................................................................... 34
2-26 Advantages and Limitations of Stateless Firewalls ................................................................. 35
2-27 About Stateful Firewalls ......................................................................................................................36
2-28 Stateful Firewalls: Traffic Management ......................................................................................... 37
2-29 Stateful Firewall Source Request ....................................................................................................38
2-30 Stateful Firewall Destination Response ........................................................................................39
2-31 Advantages and Limitations of Stateful Firewalls ................................................................... 40
2-32 About Application Firewalls ............................................................................................................... 41
2-33 Application Firewall Types ................................................................................................................ 42
2-34 Application Firewall: Traffic Management ................................................................................... 43
2-35 Advantages and Limitations of Application Firewalls ............................................................ 44
2-36 About Identity Firewalls ..................................................................................................................... 45
2-37 Identity Firewall: Traffic Management .......................................................................................... 46
2-38 Advantages and Limitations of Identity Firewalls .....................................................................47
2-39 Knowledge Check: Introduction to Firewalls ............................................................................. 48
2-40 Review of Learner Objectives ......................................................................................................... 49
2-41 Lesson 3: Introduction to Intrusion Detection and Protection ........................................... 50
2-42 Learner Objectives ............................................................................................................................... 50
2-43 About Intrusion Detection Systems ................................................................................................ 51
2-44 Features of Intrusion Detection Systems .................................................................................... 52
2-45 Limitations of Intrusion Detection Systems................................................................................. 53
2-46 About Intrusion Prevention Systems ............................................................................................ 54
2-47 Features of Intrusion Prevention Systems .................................................................................. 55
2-48 Limitations of Intrusion Prevention Systems ..............................................................................56
2-49 Types of Intrusion Detection and Prevention Systems ......................................................... 57
2-50 Combining Intrusion Detection/Intrusion Prevention Systems ...........................................58

iv
2-51 Types of Detection Methods ............................................................................................................59
2-52 Signature-Based Detection............................................................................................................... 60
2-53 Advantages and Limitations of Signature-Based Detection .................................................61
2-54 Anomaly-Based Detection .................................................................................................................62
2-55 Advantages and Limitations of Anomaly-Based Detection .................................................63
2-56 Protocol-Based Analysis .................................................................................................................... 64
2-57 Advantages and Limitations of Protocol-Based Analysis .....................................................65
2-58 User Behavior-Based Analysis ......................................................................................................... 66
2-59 Advantages and Limitations of User Behavior-Based Analysis ..........................................67
2-60 Selecting an Intrusion Detection/Intrusion Prevention Solution ........................................ 68
2-61 Knowledge Check: Introduction to Intrusion Detection and Protection ........................ 70
2-62 Review of Learner Objectives ........................................................................................................... 71
2-63 Key Points ................................................................................................................................................. 72

Module 3 VMware Intrinsic Security ............................................................................. 73

3-2 Importance ................................................................................................................................................ 73
3-3 Lesson 1: VMware Intrinsic Security ...............................................................................................74
3-4 Learner Objectives ................................................................................................................................74
3-5 Modern Data Center Security Challenges ................................................................................... 75
3-6 About Intrinsic Security ....................................................................................................................... 76
3-7 VMware Security Portfolio ................................................................................................................. 78
3-8 Firewall Concepts and Definitions .................................................................................................. 80
3-9 Service-defined Firewall Motivation ...............................................................................................82
3-10 About NSX Service-defined Firewall ............................................................................................ 84
3-11 NSX Service-defined Firewall Use Cases: Network Segmentation ..................................85
3-12 NSX Service-defined Firewall Use Cases: Secure VDI .......................................................... 86
3-13 NSX Service-defined Firewall Use Cases: Compliance .......................................................... 87
3-14 NSX Service-defined Firewall Use Cases: Internal Appliance Consolidation.................88
3-15 Distributed Firewall ............................................................................................................................... 89
3-16 About NSX Distributed IDS/IPS .......................................................................................................91
3-17 About NSX Intelligence .......................................................................................................................93
3-18 Network Detection and Response .................................................................................................95
3-19 NSX Gateway Security ....................................................................................................................... 96
3-20 Knowledge Check: VMware Intrinsic Security ........................................................................... 97
3-21 Review of Learner Objectives ......................................................................................................... 98
3-22 Key Points ................................................................................................................................................ 99

v
Module 4 Implementing Zero-Trust Security........................................................... 101
4-2 Importance ............................................................................................................................................... 101
4-3 Module Lessons ..................................................................................................................................... 101
4-4 Lesson 1: Zero-Trust Architecture ................................................................................................ 102
4-5 Learner Objectives .............................................................................................................................. 102
4-6 Traditional Security Challenges ...................................................................................................... 103
4-7 About Zero-Trust Security ............................................................................................................. 104
4-8 Zero-Trust Architecture Principles ............................................................................................... 105
4-9 Zero-Trust Architecture ....................................................................................................................106
4-10 Device Trust ........................................................................................................................................... 107
4-11 User Trust................................................................................................................................................108
4-12 Transport and Session Trust ...........................................................................................................109
4-13 Application Trust ................................................................................................................................... 110
4-14 Data Trust ................................................................................................................................................. 111
4-15 VMware Portfolio .................................................................................................................................. 112
4-16 Review of Learner Objectives ......................................................................................................... 114
4-17 Lesson 2: NSX Segmentation .......................................................................................................... 115
4-18 Learner Objectives ............................................................................................................................... 115
4-19 About NSX Segmentation................................................................................................................. 116
4-20 Use Cases for NSX Segmentation ................................................................................................. 117
4-21 NSX Segmentation Benefits ............................................................................................................. 118
4-22 Enforcing Zero-Trust with NSX Segmentation ......................................................................... 119
4-23 Step 1: Creating Virtual Security Zones ...................................................................................... 120
4-24 Step 2: Identifying the Applications Boundaries....................................................................... 121
4-25 Step 3: Implementing Micro-Segmentation ............................................................................... 123
4-26 Step 4: Securing Through Context ............................................................................................... 125
4-27 Knowledge Check: Implementing Zero-Trust Security ........................................................ 127
4-28 Review of Learner Objectives ........................................................................................................ 128
4-29 Key Points ............................................................................................................................................... 129

Module 5 User and Role Management ........................................................................131

5-2 Importance ............................................................................................................................................... 131
5-3 Module Lessons ..................................................................................................................................... 131
5-4 Lesson 1: Integrating NSX-T Data Center with VMware Identity Manager.................. 132
5-5 Learner Objectives .............................................................................................................................. 132
5-6 About VMware Identity Manager .................................................................................................. 133
5-7 Benefits of Integrating VMware Identity Manager with NSX-T Data Center .............. 135
vi
5-8 Prerequisites for VMware Identity Manager Integration...................................................... 136
5-9 Configuring VMware Identity Manager ....................................................................................... 138
5-10 Overview of the VMware Identity Manager and NSX-T Data Center Integration ... 139
5-11 Creating an OAuth Client ................................................................................................................. 140
5-12 Obtaining the SHA-256 Certificate Thumbprint ...................................................................... 142
5-13 Configuring VMware Identity Manager Details in NSX-T Data Center .......................... 143
5-14 Verifying the VMware Identity Manager Integration ............................................................. 145
5-15 Default UI Login .................................................................................................................................... 146
5-16 UI Login with VMware Identity Manager .................................................................................... 147
5-17 Local Login with VMware Identity Manager ............................................................................. 148
5-18 Review of Learner Objectives ........................................................................................................ 149
5-19 Lesson 2: Integrating NSX-T Data Center with LDAP ......................................................... 150
5-20 Learner Objectives .............................................................................................................................. 150
5-21 About LDAP ........................................................................................................................................... 151
5-22 Benefits of Integrating LDAP with NSX-T Data Center ...................................................... 152
5-23 Authentication with LDAP ............................................................................................................... 153
5-24 Adding an Identity Source ................................................................................................................ 154
5-25 Configuring the LDAP Server ......................................................................................................... 155
5-26 UI Login with LDAP ............................................................................................................................. 156
5-27 Review of Learner Objectives ........................................................................................................ 157
5-28 Lesson 3: Managing Users and Configuring RBAC ................................................................ 158
5-29 Learner Objectives .............................................................................................................................. 158
5-30 NSX-T Data Center Users ................................................................................................................ 159
5-31 Using Role-Based Access Control ................................................................................................160
5-32 Built-In Roles (1) ...................................................................................................................................... 161
5-33 Built-In Roles (2).................................................................................................................................... 162
5-34 Creating Custom Roles ...................................................................................................................... 163
5-35 Role Assignment .................................................................................................................................. 165
5-36 Lab 1: Reviewing the Lab Environment ....................................................................................... 166
5-37 Lab 2: Managing Users and Roles.................................................................................................. 167
5-38 Review of Learner Objectives ........................................................................................................ 168
5-39 Key Points ............................................................................................................................................... 169

Module 6 Distributed Firewall ..........................................................................................171

6-2 Importance ............................................................................................................................................... 171
6-3 Module Lessons ..................................................................................................................................... 171
6-4 Lesson 1: Configuring the Distributed Firewall ......................................................................... 172
vii
6-5 Learner Objectives .............................................................................................................................. 172
6-6 NSX-T Data Center Firewalls .......................................................................................................... 173
6-7 Features of the Distributed Firewall ............................................................................................. 174
6-8 Distributed Firewall: Key Concepts .............................................................................................. 175
6-9 Overview of a Security Policy ........................................................................................................ 176
6-10 Distributed Firewall Policy Categories ........................................................................................ 177
6-11 About Distributed Firewall Policies ............................................................................................... 178
6-12 Distributed Firewall Rule Processing within a Policy ............................................................. 179
6-13 Applied To Field for the Policy.......................................................................................................180
6-14 Configuring Distributed Firewall Policy Settings ...................................................................... 181
6-15 Enable Logging for Distributed Firewall Policy ........................................................................ 182
6-16 Creating Distributed Firewall Rules ............................................................................................... 183
6-17 Configuring Distributed Firewall Rule Parameters .................................................................. 184
6-18 Specifying Sources and Destinations for a Rule ...................................................................... 185
6-19 Creating Groups.................................................................................................................................... 186
6-20 Adding Members and Member Criteria for a Group .............................................................. 187
6-21 Specifying Services for a Rule ........................................................................................................ 188
6-22 Adding a Context Profile to a Rule ............................................................................................... 189
6-23 Configuring Context Profile Attributes .......................................................................................190
6-24 Custom FQDN Filtering ...................................................................................................................... 191
6-25 Setting the Scope of Rule Enforcement .................................................................................... 192
6-26 Specifying the Action for a Rule .................................................................................................... 193
6-27 Distributed Firewall Rule Settings .................................................................................................. 194
6-28 Jump To Application DFW Rules (1) ............................................................................................ 195
6-29 Jump To Application DFW Rules (2) ........................................................................................... 196
6-30 Saving and Viewing the Distributed Firewall Configuration ................................................ 197
6-31 Rolling Back to a Saved Distributed Firewall Configuration ............................................... 198
6-32 Distributed Firewall Configuration Import and Export .......................................................... 199
6-33 Lab 3: Configuring the NSX Distributed Firewall ................................................................... 200
6-34 Lab 4: Configuring L7 Distributed Firewall Rules .................................................................... 201
6-35 Review of Learner Objectives ....................................................................................................... 202
6-36 Lesson 2: Distributed Firewall Architecture and Troubleshooting..................................203
6-37 Learner Objectives .............................................................................................................................203
6-38 Distributed Firewall Architecture ................................................................................................. 204
6-39 Distributed Firewall Architecture: ESXi ......................................................................................205
6-40 Distributed Firewall Rule Processing: ESXi ............................................................................... 207

viii
6-41 Distributed Firewall Architecture: KVM ......................................................................................209
6-42 Distributed Firewall Rule Processing: KVM ................................................................................. 211
6-43 UI for Distributed Firewall Validation ............................................................................................ 212
6-44 Distributed Firewall Validation: ESXi CLI (1) .............................................................................. 213
6-45 Distributed Firewall Validation: ESXi CLI (2) ............................................................................. 215
6-46 Distributed Firewall Validation: ESXi CLI (3) ............................................................................. 216
6-47 Distributed Firewall Validation: KVM CLI .................................................................................... 217
6-48 Distributed Firewall Validation: NSX CLI (1) ............................................................................... 218
6-49 Distributed Firewall Validation: NSX CLI (2) .............................................................................. 219
6-50 Retrieving the Absolute Path for a Firewall Policy and a Rule .........................................220
6-51 Distributed Firewall Rule Validation: API..................................................................................... 221
6-52 Distributed Firewall Log Files ......................................................................................................... 222
6-53 Distributed Firewall Troubleshooting Flowchart .................................................................... 223
6-54 Troubleshooting Scenario 1: Problem Description ................................................................. 224
6-55 Troubleshooting Scenario 1: Root Cause .................................................................................. 225
6-56 Troubleshooting Scenario 1: Solution .......................................................................................... 226
6-57 Troubleshooting Scenario 2: Problem Description................................................................ 227
6-58 Troubleshooting Scenario 2: Root Cause ................................................................................. 228
6-59 Troubleshooting Scenario 2: Solution ......................................................................................... 229
6-60 Lab 5: Troubleshooting the NSX Distributed Firewall ..........................................................230
6-61 Review of Learner Objectives ........................................................................................................ 231
6-62 Lesson 3: Time-Based Firewall Rules.......................................................................................... 232
6-63 Learner Objectives ............................................................................................................................. 232
6-64 About Time-Based Firewall Rules ................................................................................................ 233
6-65 Use Cases for Time-Based Firewall Rules ................................................................................ 234
6-66 Requirements for Time-Based Firewall Rules (1) ................................................................... 235
6-67 Requirements for Time-Based Firewall Rules (2) ................................................................. 236
6-68 ESXi Packet Walkthrough ............................................................................................................... 237
6-69 KVM Packet Walkthrough ............................................................................................................... 238
6-70 Configuring Time-Based Distributed Firewall Rules .............................................................. 239
6-71 Configuring Time Windows............................................................................................................ 240
6-72 About Time Windows ........................................................................................................................ 241
6-73 UI Validation........................................................................................................................................... 242
6-74 CLI Validation on ESXi Hosts (1) ................................................................................................... 244
6-75 CLI Validation on ESXi Hosts (2) .................................................................................................. 245
6-76 CLI Validation on KVM Hosts (1) ................................................................................................... 246

ix
6-77 CLI Validation on KVM Hosts (2) .................................................................................................. 247
6-78 API Validation ....................................................................................................................................... 248
6-79 Useful Log Files.................................................................................................................................... 249
6-80 Relevant Log Events .........................................................................................................................250
6-81 Time-Based Firewall Troubleshooting Flowchart ................................................................... 251
6-82 Lab 6: Configuring Time-Based Firewall Rules ........................................................................ 252
6-83 Review of Learner Objectives ....................................................................................................... 253
6-84 Lesson 4: Identity Firewall ............................................................................................................... 254
6-85 Learner Objectives ............................................................................................................................. 254
6-86 About the NSX Identity Firewall ................................................................................................... 255
6-87 Use Cases for Identity Firewall ...................................................................................................... 256
6-88 Requirements for Identity Firewall (1) ......................................................................................... 257
6-89 Requirements for Identity Firewall (2) ........................................................................................ 258
6-90 Identity Firewall Components ........................................................................................................ 259
6-91 Identity Firewall Configuration Workflow .................................................................................260
6-92 Identity Firewall Enforcement Workflow ................................................................................... 261
6-93 Enabling Identity Firewall ................................................................................................................. 262
6-94 Adding an Active Directory Domain to NSX ........................................................................... 263
6-95 Creating Active Directory Groups ............................................................................................... 264
6-96 Configuring Identity Firewall Rules ............................................................................................... 265
6-97 Validating Identity Firewall Rules from the NSX UI ............................................................... 266
6-98 Validating Identity Firewall Rules from the ESXi CLI ............................................................ 267
6-99 Validating Identity Firewall Configuration from the API ...................................................... 268
6-100 Log Files for Troubleshooting Identity Firewall ...................................................................... 269
6-101 Lab 7: Configuring Identity Firewall Rules ................................................................................. 270
6-102 Review of Learner Objectives ........................................................................................................ 271
6-103 Key Points .............................................................................................................................................. 272

Module 7 Gateway Security...........................................................................................275

7-2 Importance ............................................................................................................................................. 275
7-3 Module Lessons ................................................................................................................................... 275
7-4 Lesson 1: Configuring the Gateway Firewall ............................................................................ 276
7-5 Learner Objectives ............................................................................................................................. 276
7-6 About the Gateway Firewall .......................................................................................................... 277
7-7 Predefined Gateway Firewall Categories ................................................................................. 279
7-8 Gateway Firewall Policy ...................................................................................................................280
7-9 Configuring Gateway Firewall Policy Settings ......................................................................... 281
x
7-10 Configuring Gateway Firewall Rules ............................................................................................ 282
7-11 Configuring Gateway Firewall Rules Settings.......................................................................... 283
7-12 Lab 8: Configuring the NSX Gateway Firewall ....................................................................... 284
7-13 Review of Learner Objectives ....................................................................................................... 285
7-14 Lesson 2: Gateway Firewall Architecture and Troubleshooting ..................................... 286
7-15 Learner Objectives ............................................................................................................................. 286
7-16 Gateway Firewall Architecture...................................................................................................... 287
7-17 Gateway Firewall Rule Processing ............................................................................................... 288
7-18 Gateway Firewall Validation: UI .....................................................................................................290
7-19 Gateway Firewall Validation: CLI ................................................................................................... 291
7-20 Gateway Firewall Validation: API ................................................................................................. 292
7-21 Log Files for Troubleshooting a Gateway Firewall ............................................................... 294
7-22 Gateway Firewall Troubleshooting Flowchart ........................................................................ 295
7-23 Scenario 1: Problem Description ................................................................................................... 296
7-24 Scenario 1: Root Cause (1) ............................................................................................................... 297
7-25 Scenario 1: Root Cause (2) .............................................................................................................. 298
7-26 Scenario 1: Resolution ........................................................................................................................ 299
7-27 Scenario 2: Problem Description ................................................................................................. 300
7-28 Scenario 2: Root Cause (1) ............................................................................................................... 301
7-29 Scenario 2: Root Cause (2) .............................................................................................................302
7-30 Scenario 2: Root Cause (3) .............................................................................................................303
7-31 Scenario 2: Resolution (1) ................................................................................................................ 304
7-32 Scenario 2: Resolution (2) ................................................................................................................305
7-33 Lab 9: Troubleshooting the NSX Gateway Firewall ............................................................ 306
7-34 Review of Learner Objectives ....................................................................................................... 307
7-35 Lesson 3: URL Analysis ....................................................................................................................308
7-36 Learner Objectives .............................................................................................................................308
7-37 About URL Analysis .......................................................................................................................... 309
7-38 Use Cases................................................................................................................................................ 310
7-39 Requirements and Limitations .......................................................................................................... 311
7-40 URL Category........................................................................................................................................ 312
7-41 Reputation Score and Severity ...................................................................................................... 313
7-42 Webroot and NSX Threat Intelligence Cloud Service .......................................................... 314
7-43 URL Analysis Architecture ............................................................................................................... 315
7-44 DNS Snooping on the Tier-1 Gateway ........................................................................................ 316
7-45 Mapping Category and Reputation to Domain ........................................................................ 317

xi
7-46 Enabling URL Analysis ........................................................................................................................ 318
7-47 Setting Context Profiles for URL Analysis ................................................................................ 319
7-48 Configuring a Layer 7 Rule for DNS Traffic..............................................................................320
7-49 URL Analysis Dashboard .................................................................................................................. 321
7-50 Scenario 1: Problem Description ................................................................................................... 322
7-51 Scenario 1: Root Cause and Resolution...................................................................................... 323
7-52 Scenario 2: Problem Description .................................................................................................. 324
7-53 Scenario 2: Root Cause and Resolution..................................................................................... 325
7-54 Scenario 2: Solution Verification ................................................................................................... 326
7-55 Scenario 3: Problem Description .................................................................................................. 327
7-56 Scenario 3: Root Cause .................................................................................................................... 328
7-57 Scenario 3: Resolution (1) ................................................................................................................. 329
7-58 Scenario 3: Resolution (2) ................................................................................................................330
7-59 Lab 10: Analyzing Web Traffic with URL Analysis ................................................................. 331
7-60 Review of Learner Objectives ....................................................................................................... 332
7-61 Key Points .............................................................................................................................................. 333

Module 8 Operating Internal Firewalls ...................................................................... 335

8-2 Importance ............................................................................................................................................. 335
8-3 Module Lessons ................................................................................................................................... 335
8-4 Lesson 1: Security Monitoring Tools ............................................................................................ 336
8-5 Learner Objectives ............................................................................................................................. 336
8-6 Monitoring Security from the NSX UI ......................................................................................... 337
8-7 Security Monitoring Tools ................................................................................................................ 338
8-8 Using the Right Tool for the Right Job ...................................................................................... 339
8-9 About vRealize Log Insight ............................................................................................................ 340
8-10 vRealize Log Insight: Content Pack for NSX-T Data Center ............................................. 341
8-11 Using vRealize Log Insight to Monitor NSX-T Data Center .............................................. 342
8-12 Configuring ESXi Hosts to Send Log Data to vRealize Log Insight ............................... 343
8-13 Enabling Logging for Firewall Rules .............................................................................................344
8-14 Using vRealize Log Insight to Monitor Distributed Firewall Information ....................... 345
8-15 Using vRealize Log Insight for Troubleshooting NSX Firewalls ....................................... 346
8-16 About vRealize Network Insight ................................................................................................... 347
8-17 vRealize Network Insight Architecture and Components .................................................. 348
8-18 Benefits of vRealize Network Insight .......................................................................................... 349
8-19 Planning, Securing, and Migrating Applications .......................................................................350
8-20 Security Policy Automation for Micro-Segmentation .......................................................... 352
xii
8-21 Security Operations, Auditing, and Compliance ..................................................................... 353
8-22 Lab 11: Using vRealize Log Insight to Diagnose NSX Firewalls ......................................... 354
8-23 Review of Learner Objectives ....................................................................................................... 355
8-24 Lesson 2: NSX Intelligence .............................................................................................................. 356
8-25 Learner Objectives ............................................................................................................................. 356
8-26 About NSX Intelligence .................................................................................................................... 357
8-27 Use Cases for NSX Intelligence..................................................................................................... 358
8-28 NSX Intelligence Requirements ..................................................................................................... 359
8-29 NSX Intelligence Sizing ..................................................................................................................... 360
8-30 NSX Intelligence Compatibility Matrix .......................................................................................... 361
8-31 NSX Intelligence Deployment (1) .................................................................................................. 362
8-32 NSX Intelligence Deployment (2) ................................................................................................. 363
8-33 Validating the NSX Intelligence Deployment ........................................................................... 364
8-34 Checking NSX Intelligence Services ............................................................................................ 365
8-35 NSX Intelligence Visualization (1) .................................................................................................. 366
8-36 NSX Intelligence Visualization (2) ................................................................................................. 367
8-37 NSX Intelligence Recommendations (1) ..................................................................................... 368
8-38 NSX Intelligence Recommendations (2) .................................................................................... 369
8-39 NSX Intelligence Recommendations (3) ..................................................................................... 371
8-40 NSX Intelligence Recommendations (4) .................................................................................... 372
8-41 Lab 12: Using NSX Intelligence to Gain Security Insights .................................................... 373
8-42 Review of Learner Objectives ....................................................................................................... 374
8-43 Lesson 3: Security Best Practices................................................................................................ 375
8-44 Learner Objectives ............................................................................................................................. 375
8-45 Grouping Best Practices................................................................................................................... 376
8-46 Tagging Best Practices (1)............................................................................................................... 377
8-47 Tagging Best Practices (2).............................................................................................................. 378
8-48 Gateway Firewall Policy Categories: Rule Placement Best Practices .......................... 379
8-49 Distributed Firewall Policy Categories: Rule Placement Best Practices.......................380
8-50 Placing the Most Hit Rules at the Top (1) ................................................................................... 381
8-51 Placing the Most Hit Rules at the Top (2) ................................................................................. 382
8-52 Placing the Most Hit Rules at the Top (3) ................................................................................. 383
8-53 Using the Applied To Field (1) ........................................................................................................ 384
8-54 Using the Applied To Field (2) ....................................................................................................... 385
8-55 Using the Applied To Field (3) ....................................................................................................... 386
8-56 Review of Learner Objectives ....................................................................................................... 387

xiii
8-57 Key Points .............................................................................................................................................. 388

Module 9 Network Introspection ................................................................................ 389

9-2 Importance ............................................................................................................................................. 389
9-3 Module Lessons ................................................................................................................................... 389
9-4 Lesson 1: Overview of Network Introspection ...................................................................... 390
9-5 Learner Objectives ............................................................................................................................ 390
9-6 About Network Introspection......................................................................................................... 391
9-7 Network Introspection Benefits .................................................................................................... 392
9-8 Network Introspection Use Cases ............................................................................................... 393
9-9 Overview of North-South Service Insertion for Network Introspection...................... 394
9-10 Overview of East-West Service Insertion for Network Introspection ......................... 395
9-11 Configuring Network Introspection ............................................................................................. 396
9-12 Review of Learner Objectives ....................................................................................................... 397
9-13 Lesson 2: North-South Service Insertion .................................................................................. 398
9-14 Learner Objectives ............................................................................................................................. 398
9-15 North-South Service Insertion Components (1) ..................................................................... 399
9-16 North-South Service Insertion Components (2) ................................................................... 400
9-17 North-South Service Registration and Deployment Workflow ....................................... 401
9-18 North-South Service Registration ............................................................................................... 402
9-19 North-South Service Deployment .............................................................................................. 403
9-20 Service Segments for North-South traffic............................................................................... 404
9-21 North-South Service Consumption Workflow ....................................................................... 405
9-22 North-South Service Insertion Rules .......................................................................................... 406
9-23 Configuring Redirection Policies for North-South Network Introspection ................. 407
9-24 North-South SI Classifier ................................................................................................................. 408
9-25 North-South Packet Flow............................................................................................................... 409
9-26 South-North Packet Flow................................................................................................................ 410
9-27 Log Files for Troubleshooting North-South Service Insertion............................................ 411
9-28 North-South Service Insertion Troubleshooting Flowchart................................................ 412
9-29 Review of Learner Objectives ........................................................................................................ 413
9-30 Lesson 3: East-West Service Insertion ....................................................................................... 414
9-31 Learner Objectives .............................................................................................................................. 414
9-32 East-West Service Insertion Components (1) .......................................................................... 415
9-33 East-West Service Insertion Components (2) ......................................................................... 416
9-34 East-West Service Registration and Deployment Workflow............................................ 417
9-35 East-West Service Registration..................................................................................................... 418
xiv
9-36 East-West Deployment Modes ..................................................................................................... 419
9-37 East-West Service Deployment .................................................................................................. 420
9-38 East-West Service Consumption Workflow ............................................................................ 421
9-39 Service Profiles and Service Chains ............................................................................................ 422
9-40 Creating Service Profiles ................................................................................................................. 423
9-41 Creating Service Chains ................................................................................................................... 424
9-42 East-West Service Insertion Rules............................................................................................... 425
9-43 Configuring Redirection Policies for East-West Network Introspection...................... 426
9-44 East-West SI Classifier ...................................................................................................................... 427
9-45 Service Path .......................................................................................................................................... 428
9-46 Service Proxy ....................................................................................................................................... 429
9-47 East-West Packet Flow (1) ............................................................................................................ 430
9-48 East-West Packet Flow (2) ............................................................................................................. 431
9-49 Log Files for Troubleshooting East-West Network Introspection ................................. 432
9-50 East-West Network Introspection Troubleshooting Flowchart ...................................... 433
9-51 Knowledge Check: Network Introspection ..............................................................................434
9-52 Review of Learner Objectives ....................................................................................................... 435
9-53 Key Points .............................................................................................................................................. 436

Module 10 Endpoint Protection ................................................................................... 439

10-2 Importance ............................................................................................................................................. 439
10-3 Module Lessons ................................................................................................................................... 439
10-4 Lesson 1: Overview of Endpoint Protection ........................................................................... 440
10-5 Learner Objectives ............................................................................................................................ 440
10-6 About Endpoint Protection.............................................................................................................. 441
10-7 Use Cases for Endpoint Protection ............................................................................................. 442
10-8 Endpoint Protection Process .........................................................................................................443
10-9 Automatic Policy Enforcement for New VMs ........................................................................ 444
10-10 Automated Virus or Malware Quarantine with Tags Example (1) ...................................445
10-11 Automated Virus or Malware Quarantine with Tags Example (2) ..................................446
10-12 Automated Virus or Malware Quarantine with Tags Example (3) ..................................447
10-13 Creating a Service Profile for Endpoint Protection ..............................................................448
10-14 Configuring Endpoint Protection Rules ......................................................................................449
10-15 Review of Learner Objectives ...................................................................................................... 450
10-16 Lesson 2: Endpoint Protection Architecture and Troubleshooting................................. 451
10-17 Learner Objectives .............................................................................................................................. 451
10-18 Endpoint Protection Components (1) ......................................................................................... 452
xv
10-19 Endpoint Protection Components (2) ........................................................................................ 453
10-20 Endpoint Protection Components (3) ........................................................................................454
10-21 Service Registration and Deployment Workflow .................................................................. 455
10-22 Service Consumption Workflow................................................................................................... 456
10-23 Verifying the Thin Agent Installation in Windows .................................................................. 457
10-24 Verifying the Thin Agent Installation in Linux ........................................................................... 458
10-25 Verifying the MUX Backend ........................................................................................................... 459
10-26 Reviewing the Default muxconfig.xml File ............................................................................... 460
10-27 Verifying the ESXi Firewall ............................................................................................................... 461
10-28 Verifying the Partner Service Registration ............................................................................... 462
10-29 Verifying the SVM Deployment from the NSX UI ................................................................. 463
10-30 Verifying the SVM Deployment from the vSphere Client ..................................................464
10-31 Verifying the SVM deployment from the Log Files .............................................................. 465
10-32 Verifying the SVM Networking from the vSphere Client ................................................... 466
10-33 Verifying the SVM Networking from the CLI........................................................................... 467
10-34 Verifying the EAM Agency Creation from the vSphere Client ........................................468
10-35 Verifying the EAM Agency Creation and Agent Installation from the Log Files ......469
10-36 Reviewing the muxconfig.xml File After Adding Partner Solutions .............................. 470
10-37 Log Files for Troubleshooting Endpoint Protection .............................................................. 471
10-38 Endpoint Protection Troubleshooting Flowchart .................................................................. 472
10-39 Knowledge Check: Endpoint Protection ................................................................................... 473
10-40 Review of Learner Objectives ....................................................................................................... 474
10-41 Key Points .............................................................................................................................................. 475

Module 11 Advanced Threat Prevention ................................................................. 476

11-2 Importance ............................................................................................................................................. 476
11-3 Module Lessons ................................................................................................................................... 476
11-4 Lesson 1: Introduction to the MITRE ATT&CK Framework .............................................. 477
11-5 Learner Objectives ............................................................................................................................. 477
11-6 About Cyber Attacks ........................................................................................................................ 478
11-7 Common Cyber Attackers Motivations ..................................................................................... 479
11-8 Common Cyber Attacker Targets .............................................................................................. 480
11-9 About the MITRE ATT&CK Framework .................................................................................... 481
11-10 MITRE ATT&CK Tactics and Techniques ................................................................................. 482
11-11 MITRE ATT&CK Tactics................................................................................................................... 483
11-12 Adversary Tactics............................................................................................................................... 485
11-13 Initial Access .......................................................................................................................................... 486
xvi
11-14 Execution Phase .................................................................................................................................. 488
11-15 Persistence Phase .............................................................................................................................. 489
11-16 Command and Control ..................................................................................................................... 490
11-17 Lateral Movement................................................................................................................................ 491
11-18 Data Exfiltration ................................................................................................................................... 492
11-19 NSX Security Solutions ..................................................................................................................... 493
11-20 Using NSX Security Solutions Against a Phishing Attack ..................................................494
11-21 Review of Learner Objectives ....................................................................................................... 495
11-22 Lesson 2: Distributed Intrusion Detection and Prevention ................................................ 496
11-23 Learner Objectives ............................................................................................................................. 496
11-24 About NSX Distributed IDS/IPS ................................................................................................... 497
11-25 Use Cases for NSX Distributed IDS/IPS ................................................................................... 498
11-26 Requirements for NSX Distributed IDS/IPS ............................................................................. 499
11-27 About IDS/IPS Signatures .............................................................................................................. 500
11-28 About IDS/IPS Profiles ...................................................................................................................... 501
11-29 About IDS/IPS Policies and Rules ................................................................................................502
11-30 NSX Distributed IDS/IPS Architecture.......................................................................................503
11-31 Configuring NSX Distributed IDS/IPS .........................................................................................505
11-32 Global Intrusion Signature Management ................................................................................... 506
11-33 Configuring Custom IDS/IPS Profiles .........................................................................................508
11-34 Configuring IDS/IPS Rules .............................................................................................................. 509
11-35 Monitoring IDS/IPS Events (1) ........................................................................................................ 510
11-36 Monitoring IDS/IPS Events (2) ........................................................................................................ 511
11-37 Lab 13: Configuring Distributed Intrusion Detection and Prevention .............................. 512
11-38 Review of Learner Objectives ........................................................................................................ 513
11-39 Lesson 3: Troubleshooting NSX Distributed IDS/IPS ........................................................... 514
11-40 Learner Objectives .............................................................................................................................. 514
11-41 NSX Distributed IDS/IPS UI Validation ........................................................................................ 515
11-42 NSX Distributed IDS/IPS CLI Validation (1) ............................................................................... 516
11-43 NSX Distributed IDS/IPS CLI Validation (2) .............................................................................. 517
11-44 NSX Distributed IDS/IPS CLI Validation (3) .............................................................................. 518
11-45 NSX Distributed IDS/IPS API Validation (1) .............................................................................. 519
11-46 NSX Distributed IDS/IPS API Validation (2) ............................................................................520
11-47 NSX Distributed IDS/IPS API Validation (3) ............................................................................. 521
11-48 NSX Distributed IDS/IPS Log Files .............................................................................................. 522
11-49 Relevant Log Events ......................................................................................................................... 523

xvii
11-50 Enabling IDS/IPS Event Logging .................................................................................................. 524
11-51 Sending IDS/IPS Events to a Syslog Collector ...................................................................... 525
11-52 NSX Distributed IDS/IPS Troubleshooting Flowchart ......................................................... 526
11-53 Scenario 1: Problem Description ................................................................................................... 527
11-54 Scenario 1: Root Cause ..................................................................................................................... 528
11-55 Scenario 1: Resolution ........................................................................................................................ 529
11-56 Scenario 2: Problem Description ..................................................................................................530
11-57 Scenario 2: Root Cause and Resolution...................................................................................... 531
11-58 Lab 14: Troubleshooting NSX Distributed IDS/IPS ............................................................... 532
11-59 Review of Learner Objectives ....................................................................................................... 533
11-60 Lesson 4: NSX Network Detection and Response ............................................................... 534
11-61 Learner Objectives ............................................................................................................................. 534
11-62 About NSX Network Detection and Response ..................................................................... 535
11-63 NSX Network Detection and Response Use Cases ............................................................. 536
11-64 NSX Network Detection and Response: High-Level Architecture ................................ 537
11-65 NSX Network Detection and Response Features ................................................................ 538
11-66 Network Sandbox............................................................................................................................... 539
11-67 Static File Analysis ............................................................................................................................. 540
11-68 Dynamic File Analysis ......................................................................................................................... 541
11-69 Intrusion Detection and Prevention ............................................................................................. 542
11-70 Network Traffic Analysis .................................................................................................................544
11-71 Automated Response ....................................................................................................................... 546
11-72 Active Threats and Attack Stages .............................................................................................. 547
11-73 Intrusion Blueprint................................................................................................................................ 548
11-74 Attack Timeline .................................................................................................................................... 549
11-75 Using NSX Intelligence for Network Traffic Analysis ...........................................................550
11-76 Lab 15: Using Network Traffic Analysis to Detect Threats ............................................... 552
11-77 Review of Learner Objectives ....................................................................................................... 553
11-78 Key Points .............................................................................................................................................. 554

xviii
Module 1
Course Introduction

1-2 Course Introduction

1-3 Importance
NSX-T Data Center offers a full range of security features to help you secure your environment
and protect it against advanced threats. These features include distributed and gateway firewall,
Distributed Intrusion Detection and Prevention, NSX Intelligence, and NSX Network Detection
and Response. As a security administrator, you must be familiar with configuring, operating, and
troubleshooting such features to properly secure your environment.

1
1-4 Learner Objectives (1)
• Define concepts related to Information Security
• Explain different types of firewalls and their use cases

• Describe the operation of Intrusion Detection and Intrusion Prevention Systems

• Describe the VMware Intrinsic Security portfolio

• Implement Zero-Trust Security using NSX Segmentation

• Configure user and role management

• Configure and troubleshoot Distributed Firewall, Identity Firewall, and Time-Based Policies

• Configure and troubleshoot Gateway Security

1-5 Learner Objectives (2)

• Use vRealize Log Insight, vRealize Network Insight, and NSX Intelligence to operate NSX
firewalls and generate security recommendations

• Explain security best practices related to grouping, tagging, and rule configuration

• Describe North-South and East-West service insertion

• Describe Endpoint Protection

• Configure and troubleshoot NSX Distributed IDS/IPS

• Describe the capabilities of NSX Network Detection and Response

2
1-6 Course Outline
1. Course Introduction
2. Security Basics

3. VMware Intrinsic Security

4. Implementing Zero-Trust Security

5. User and Role Management

6. Distributed Firewall

7. Gateway Security

8. Operating Internal Firewalls

9. Network Introspection

10. Endpoint Protection

11. Advanced Threat Prevention

3
1-7 Typographical Conventions
The following typographical conventions are used in this course.

Conventions Use and Examples

Monospace Identifies command names, command options, parameters, code fragments,

error messages, filenames, folder names, directory names, and path names:

• Run the esxtop command.

• ... found in the /var/log/messages file.

Monospace Identifies user inputs:

Bold
• Enter ipconfig /release.

Boldface Identifies user interface controls:

• Click the Configuration tab.

Italic Identifies book titles:

• vSphere Virtual Machine Administration

<> Indicates placeholder variables:

• <ESXi_host_name>

• ... the Settings/<Your_Name>.txt file

4
1-8 References
Title Location

NSX-T Data Center Administration https://docs.vmware.com/en/VMware-NSX-T-Data-

Guide Center/3.1/nsxt_31_admin.pdf

NSX-T Data Center Installation Guide https://docs.vmware.com/en/VMware-NSX-T-Data-

Center/3.1/nsxt_31_install.pdf

NSX-T Data Center Upgrade Guide https://docs.vmware.com/en/VMware-NSX-T-Data-

Center/3.1/nsxt_31_upgrade.pdf

5
1-9 VMware Online Resources
Documentation for NSX-T Data Center: https://docs.vmware.com/en/VMware-NSX-T-Data-
Center/
Documentation for VMware Validated Design: https://www.vmware.com/go/vvd-docs

VMware Communities: http://communities.vmware.com

• Start a discussion.

• Access the knowledge base.

• Access documentation, technical papers, and compatibility guides.

• Access communities.

• Access user groups.

VMware Support: http://www.vmware.com/support

VMware Hands-on Labs: http://labs.hol.vmware.com

VMware Learning: http://www.vmware.com/learning

• Access course catalog.

• Access worldwide course schedule.

6
1-10 VMware Learning Overview
You can access the following Education Services:
• VMware Learning Paths:

— Help you find the course that you need based on the product, your role, and your level
of experience

— Can be accessed at https://vmware.com/learning

• VMware Customer Connect Learning, which is the official source of digital training, includes
the following options:

— On Demand Courses: Self-paced learning that combines lecture modules with hands-on
practice labs
— VMware Lab Connect: Self-paced, technical lab environment where you can practice
skills learned during instructor-led training

— Certification Exam Prep: Comprehensive video-based reviews of exam topics and

objectives to help you take your certification exam

• For more information, see https://vmware.com/learning/connect-learning.

7
1-11 VMware Certification Overview
VMware certifications validate your expertise and recognize your technical knowledge and skills
with VMware technology.

VMware certification sets the standards for IT professionals who work with VMware technology.
Certifications are grouped into technology tracks. Each track offers one or more levels of
certification (up to four levels).

For the complete list of certifications and details about how to attain these certifications, see
https://vmware.com/certification.

8
1-12 VMware Credentials Overview
VMware badges are digital emblems of skills and achievements. Career certifications align to job
roles and validate expertise across a solution domain. Certifications can cover multiple products
in the same certification.

Specialist certifications and skills badges align to products and verticals and show expanded
expertise.

Digital badges have the following features:

• Easy to share in social media (LinkedIn, Twitter, Facebook, blogs, and so on)

• Validate and verify achievement

• Contain metadata with skill tags and accomplishments

• Based on Mozilla's Open Badges standard

For the complete list of digital badges, see http://www.pearsonvue.com/vmware/badging.

9
Module 2
Security Basics

2-2 Importance
NSX-T Data Center 3.1 introduces new security features. You must understand the basic
concepts of security, related terminologies, advantages, and limitations to use these features
effectively.

2-3 Module Lessons

1. Introduction to Security

2. Introduction to Firewalls

3. Introduction to Intrusion Detection and Protection

11
2-4 Lesson 1: Introduction to Security

2-5 Learner Objectives

• Define Information Security

• Identify the specialized areas of security

• Describe the information security management framework

• Explain Defense in Depth

• Describe Confidentiality, Integrity, and Availability

• Explain Authentication, Authorization, Accountability (AAA)

• Differentiate between risks, threats, and vulnerabilities

12
2-6 Information Security
Information Security is the practice of protecting information by preventing or reducing the
probability of unauthorized or inappropriate access to information:
• It involves various processes and methodologies that are planned, designed, and
implemented to protect sensitive data or information.

• It helps to protect electronic, print, or other forms of private, confidential, and sensitive data
or information.

Information security is accomplished through the adoption of technology, application of policy,

and training and awareness programs.

13
2-7 Specialized Areas of Security
Several specialized areas of security are available such as physical, personal, operations,
communications, and network.

Physical Security is the protection of physical objects, items, or areas of an enterprise or

organization from unauthorized access and misuse.

Personal Security is the protection of individuals and their privacy and rights.

Operations Security is the protection of all the details of a series of activities or an operation in
an organization.

Communications Security is the protection of all communications media, content, and technology
in an organization.
Network Security is the protection of the network infrastructure (components, connections, and
contents) in an organization.

14
2-8 Information Security Management
Framework
This framework provides procedures that enable a business to operate in a state of reduced
risk.

The information security management framework has the following features:

• Includes all organizational processes, operational processes, and participants relevant to

Information Security
• Is a combination of well-defined policies, procedures, standards, and guidelines to establish
the required level of Information Security

Security Metrics and Reporting: Information Security Metric is a quantifiable measure used to
track and assess the status of a specific Information Security process, and generate a report
based on the findings of the measurement.

Training and Awareness: It is the process of providing formal education to the organization
workforce about various Information Security threats and the company's policies and
procedures for addressing them.

Business Continuity Management: It is the advanced planning and preparation of an organization

to maintaining business functions or quickly resuming after a disaster occurs. It involves defining
potential risks including fire, flood, or cyber attacks.

Disaster Recovery: It is an organization's method of regaining access and functionality to its IT

infrastructure after events such as a natural disaster or cyber attack.

15
Business Resilience: It is the ability an organization to quickly adapt to disruptions caused due to
any disaster (fire, flood, or cyber attacks), while maintaining continuous business operations and
safeguarding the people, assets, and overall brand equity of the organization.

Risk Management: It refers to the practice of identifying potential risks in advance, analyzing
them, and taking precautionary steps to reduce or curb the risk.

Technical Security Architecture: it is the term used to define the overall system required to
protect an organization's IT infrastructure.

Asset Classification: It is a system for assigning assets into groups, based on several common
characteristics.
Security Management and Operations: It is the ability to collect valuable data about your
organization's security to improve your incident response plan. A standardized and repeatable
security operations management process help an organization manage security threats and
improve its security over time.

Roles and Responsibilities: For Information Security, roles are defined in the organization to
provide clearly defined responsibilities and an understanding of how the protection of
information must be accomplished.
Security Guidelines and Frameworks: It is a standardized guideline that aims to help a company
to use tried-and-tested processes to ensure protection against security threats.

Security Policy: It identifies the rules and procedures for all individuals accessing and using an
organization's IT assets and resources.

Governance: Information security governance ensures that an organization has the correct
information structure, leadership, and guidance. Governance helps ensure that a company has
the proper administrative controls to mitigate risk.

Compliance: An organization must comply with the minimum security-related requirements. For
Information Security, a clear set of technical systems, tools, and processes must be in place to
protect and defend the information and technology assets of an enterprise.

All features mentioned in the diagram are important for an Information Security Management
Framework. However, a hierarchy does not exist among these features.

16
2-9 Defense in Depth
The Defense in Depth (DiD) strategy presents the following characteristics:
• Includes several protection layers that are placed throughout an information system

• Helps prevent direct attacks against an information system and data because a break in one
layer leads the attacker to the next layer

Data: Data is the actual organization asset that you try to protect from any information security
breach. Data is at the core of a Defense in Depth (DiD) security model.

Application: Every application consumes and processes data or information. In DiD security, you
try to protect the application before protecting the data. If the application is secure, the data will
be automatically secure.

Host: In any system, the host provides the resources to run an application. Host security can
ensure that the applications running in it are safe from information breach.

Internal Network: It is the internal network connectivity of an organization. It provides the

communication and the flow of data or information between all devices in an organization. Host
security can be assured if the network connectivity is secure.

Internal Security Measures: These measures establish and implement employee life cycle
monitoring.
17
Examples include:

• Adopt user activity monitoring tools

• Communicate all the security protocols of the organization clearly to the employees

• Collect the right data from the employees so that the organization can be transparent
without leaving employees feeling untrusted or under surveillance

Physical Perimeter: It is the actual Physical Boundary in which the IT resources of an organization
exist. It is often protected with physical doors and guards and provides access only to
authorized people inside the premises.

Policies, Procedures, and Awareness: This layer ensures that proper guidance is available about
security and regulations are met. The guidance includes hiring practices, data managing
procedures, security requirements, and so on. Every employee should be aware of the
organizational policies and procedures.

18
2-10 Confidentiality, Integrity, and Availability
Triad
The Confidentiality, Integrity, and Availability (CIA) triad is a security model that was developed
to plan various parts of IT security.

19
2-11 About Confidentiality
Confidentiality protects information from unauthorized access by individuals, entities, or process.
Encryption is an example of confidentiality.

Confidentiality: In Information Security, confidentiality ensures that sensitive information is

accessed only by an authorized person (entity or process).

20
2-12 About Integrity
Integrity safeguards the accuracy and completeness of assets (data, device, or another
component of the environment). Digital Signature is an example of integrity.

Integrity: In Information Security, data integrity means maintaining and assuring the accuracy and
completeness of data over its entire life cycle. Data cannot be modified in an unauthorized or
undetected manner. Information Security systems typically provide message integrity in addition
to data confidentiality. Trustworthiness of data or resources, and preventing improper and
unauthorized change, can be achieved by using either MS driver signing or a signed email for an
important bid.

21
2-13 About Availability
Availability makes information accessible and usable on demand by an authorized entity. Service
uptime (resistant to DoS, resiliency) is an example of availability.

Availability: Information must be available when it is needed. The computing systems used to
store and process the information, the security controls used to protect it, and the
communication channels used to access it must be functioning correctly. High availability
systems aim to always remain available, preventing service disruptions because of power
outages, hardware failures, and system upgrades. Ensuring availability also involves preventing
denial-of-service attacks, such as a flood of incoming messages to the target system that forces
it to shut down.

Also, during a physical disaster, a backup and restore solution can ensure that the data remains
available.

22
2-14 Authentication, Authorization,
Accountability
Authentication, Authorization, Accountability is a framework for intelligently controlling access to
infrastructure resources, authorizing legitimate access by enforcing policies, auditing usage, and
providing the information necessary to bill for services.

Authentication identifies a user, typically when the user enters a valid user name and password.

Authorization defines what a user can do after successful login to a system.

Accounting defines the logging and reporting of Authentication and Authorization events.

23
Authentication:

• A user can be authenticated by using a token or one-time password (OTP) or passkey

(RSA SecurID) before access is granted.

• The process of authentication is based on each user having a unique set of criteria for
gaining access.

Authorization:

• The authorization process determines whether users have the authority to run certain
commands or alter system settings according to their privileges (system rights).

• For example, modifying the clock is a user system right for a certain authorization level.

24
2-15 Risks, Threats, and Vulnerabilities
You try to protect assets. Assets can include people, property, and information.
Risks, threats, and vulnerabilities are always associated with an asset.

Vulnerability Gaps or weakness in a security program or system that can be exploited by

threats to gain unauthorized access to an asset.

Threat A factor that can exploit a vulnerability, accidentally or intentionally, to

obtain, misuse, or destroy an asset.

Risk The potential for loss, misuse, or destruction of an asset as a result of a

threat exploiting a vulnerability.

25
2-16 Knowledge Check: Introduction to
Security
Go to https://via.vmw.com/KC1 to answer questions about this content.

26
2-17 Review of Learner Objectives
• Define Information Security
• Identify the specialized areas of security

• Describe the information security management framework

• Explain Defense in Depth

• Describe Confidentiality, Integrity, and Availability

• Explain Authentication, Authorization, Accountability (AAA)

• Differentiate between risks, threats, and vulnerabilities

27
2-18 Lesson 2: Introduction to Firewalls

2-19 Learner Objectives

• Define firewalls

• Explain firewall rules

• Describe stateless firewalls, their advantages, disadvantages, and use cases

• Describe stateful firewalls, their advantages, disadvantages, and use cases

• Explain application firewalls, their advantages, disadvantages and use cases

• Explain Identity Firewalls, their advantages, disadvantages, and use cases

28
2-20 About Firewalls (1)
A firewall is a system that prevents unauthorized access to or from a private network.

29
2-21 About Firewalls (2)
Firewalls have the following characteristics:
• A firewall can be implemented as either hardware or software, or a combination of both.

• Firewalls use rules to allow or prevent access to network endpoints.

• A firewall is considered the first line of defense while protecting private information.
However, it cannot be considered the only defense mechanism.

30
2-22 Firewall Rules
Firewall rules examine the control information in individual packets.
Firewall rules define which traffic (service) passing through a firewall is allowed or blocked,
between a source and a destination.

Protocol Source IP Destination IP Service Action

TCP 10.0.0.1 20.3.3.9 HTTP ALLOW

TCP 10.1.1.0/24 20.3.3.9 HTTP DENY

The first rule allows http traffic (service) using TCP as a transport layer protocol from a source
with IP address 10.0.0.1 to a destination with IP address 20.3.3.9.

The second rule denies http traffic (service) using TCP as a transport layer protocol from any IP
address in the subnet of 10.1.1.0/24 as a source to a destination with IP address 20.3.3.9.

31
2-23 Types of Firewalls
Based on the functionality, firewalls can be classified into the following types:
• Stateless firewall

• Stateful firewall

• Application firewall

• Identity Firewall

32
2-24 About Stateless Firewalls
Stateless firewalls inspect each packet in isolation, using preset rules to filter traffic.

33
2-25 Stateless Firewalls: Traffic Management
In stateless firewalls, each packet is managed independently, and the connection history is not
maintained.
The table includes examples of security rules to help you understand how traffic is managed by
the stateless firewalls when a client wants to communicate with a server.

Direction Source IP Destination IP Protocol Source Port Destination Port Action

In to Out 10.0.0.1 20.0.0.1 TCP 1-65535 80 Allow

Out to In 20.0.0.1 10.0.0.1 TCP 80 1-65535 Allow

The first rule takes care of the outgoing traffic from the client to the server. But it does not
guarantee the return traffic from the server to the client. The rule specifies that any traffic
coming from the client IP 10.0.0.1 (source) and a port number from 1 to 65535 (source) to the
server IP 20.0.0.1 (destination) and port number 80 (destination) is allowed on the server.

To allow the return traffic from the server to the client, you need another rule. The second rule
ensures that the client receives a response to its requests made to the server. The rule allows
the return traffic from the server IP 20.0.0.1 (source) and port number 80 (source) to the client
IP 10.0.0.1 (destination) and a port number from 1 to 65535 (destination).

34
2-26 Advantages and Limitations of Stateless
Firewalls
Stateless firewalls have the following advantages:

• Perform well if heavy traffic is present

• Process packets faster

• Cost less than stateful firewalls

Stateless firewalls have the following limitations:

• Cannot consider the complete pattern in which packets are entering

• Cannot differentiate between different traffic types at the application-level, including

HTTPS, HTTP, SSH, FTP, VolP, and so on

• Are susceptible to online attacks spread across different packets

35
2-27 About Stateful Firewalls
Stateful firewalls monitor all aspects of network traffic, including their communication channels
and characteristics. They act as dynamic packet filters because they filter traffic packets based
on the context and state.

The context of a connection involves the metadata associated with packets, such as:

• IP address and port of source and destination

• Last packet received time for managing idle connections

• Length of the packet

• Layer 4 TCP sequence numbers and flags

• Layer 3 data related to fragmentation and reassembly to identify session for the
fragmented packet

Firewalls apply their policy based on the state of the connection. The following example TCP-
based communication helps you understand the state. In TCP, the four bits (SYN, ACK, RST,
FIN) out of the nine assignable control bits are used to control the state of the connection:

• When a client application initiates a connection using three-way handshake, the TCP stack
sets the SYN flag to indicate the start of the connection. This flag is used by the firewall to
indicate a new connection.

• The server replies to the connection by sending SYN+ACK. The firewall has seen packets
from both sides and it promotes its internal connection state to ESTABLISHED. From the
TCP perspective, the connection is not fully established until the client sends a reply with
ACK.

• When a firewall sees an RST or FIN+ACK packet, it marks the connection state for deletion,
and future packets for this connection are dropped.

36
2-28 Stateful Firewalls: Traffic Management
Stateful firewalls determines the following factors for every packet that passes through them:
• Is it the start of a new allowed connection?

• Is it a part of an existing connection?

• Is it something else?

Based on these checks, stateful firewalls decide whether to allow a particular flow through them.

Stateful firewalls maintain the state of a connection in a state or flow table. This mechanism
allows the firewall to compare the current packets with the previous packets with a flow table
entry.

37
2-29 Stateful Firewall Source Request
The example displays a security rule that is configured on a stateful firewall.

Source IP Destination IP Service Action

20.0.0.1 20.10.0.2 http (TCP/80) Allow

ANY ANY ANY Deny

The example displays a flow table entry that assumes that the packet is the start of a new
allowed connection.

Source IP Destination IP Service Status Sequence Number

20.0.0.1 20.10.0.2 http (TCP/80) 3-Way HS 222 222 222

(SYN)

The security rule specifies that the IP addresses 20.0.0.1 and 20.10.0.2 can communicate with
each other over HTTP (TCP/80), and all other communications are denied.

The flow table entry is populated after a SYN message is sent by the source 20.0.0.1. Or, when
a request is made by the source to connect to the destination, the firewall creates a dynamic
entry for the start of the session in the flow table.

38
2-30 Stateful Firewall Destination Response
The table displays a flow table entry for the response received from the destination.

Source IP Destination IP Service Status Sequence Number

20.0.0.1 20.10.0.2 http (TCP/80) SYN/ ACK 222 222 222

(SYN)

When the stateful firewall receives a response from the destination, the stateful firewall
determines that the destination is part of an existing connection, updates the flow table
dynamically, and allows that traffic to come through it

The flow table is updated as follows:

• The destination responds to the source by acknowledging the SYN message sent by the
source (ACK). This is represented by the SYN/ACK status.
• An entry for the SYN message sent by the destination starts two-way communication.

The source sends an ACK message for the SYN message received from the destination. The
connection is established. The two-way communication between the source and the destination
for http traffic continues till the time the session is terminated by either the source or the
destination.

39
2-31 Advantages and Limitations of Stateful
Firewalls
Stateful firewalls have the following advantages:

• Detect forged messaging or unauthorized access

• Provide wider logging capacity and stronger attack mitigation

• Make better decisions based on present and past findings

• Act as building blocks for the advanced application layer filtering by firewalls or gateways

Stateful firewalls have the following limitations:

• Are resource-intensive because they need more processing power for CPU cycles and
memory to perform additional checks (context or state)

• Are more expensive than stateless firewalls

• Can have a larger attack surface compared to stateless firewalls because of a larger code
base footprint

40
2-32 About Application Firewalls
Application firewalls control input/output or system calls of an application or service. They
provide firewall services up to the application layer of the OSI model.

41
2-33 Application Firewall Types
Application firewalls can be classified into network-based and host-based application firewalls.

Network-Based Scan and monitor network-based traffic destined for the application
Application Firewalls layer or for any specific application or protocols such as FTP, DNS,
and so on.

Host-Based Application Monitor all the incoming and outgoing traffic initiated by an
Firewalls application or service on a local computer, system, or host.

On the slide, host-based firewalls do not refer to the built-in firewalls of an operating system.
Host-based firewalls refer to third-party installed firewalls.

42
2-34 Application Firewall: Traffic Management
The application firewall rules examine the packets passing through the firewall for any specific
application or protocols running at the application layer.
The table includes sample rules for an application firewall.

Source IP Destination IP Service Application Action

30.0.0.1 30.10.0.1 udp/53 DNS Allow

20.0.0.1 20.10.0.1 tcp/22 SSH Deny

In the sample rule, the application field inspects the packet beyond port number and protocol. It
compares the packet with the known application signature to ensure that traffic allowed on a
specific port number for a protocol is used by the intended application.

The first rule compares the packet against a known signature of DNS application and allows DNS
application-related communication between the source IP 30.0.0.1 and the destination IP
30.10.0.1. The destination manages all DNS requests on UDP port number 53 from source IP
30.0.0.1 to the destination IP 30.10.0.1.

The second rule compares the packet against a known signature of SSH application and
prevents the source IP 20.0.0.1 from opening SSH sessions to the destination IP 20.10.0.1 by
using a TCP connection on port 22.

43
2-35 Advantages and Limitations of
Application Firewalls
Application firewalls have the following advantages:

• Protect from application-specific attacks

• Prevent sensitive data loss or data leakage

• Provide real-time reporting and robust logging

Application firewalls have the following limitations:

• Performance is often an issue because they inspect all incoming and outgoing traffic at the
application layer.

• Increased sophistication of these firewalls makes them more expensive.

44
2-36 About Identity Firewalls
Identity Firewalls allow or deny access to network resources based on the identity (user name)
instead of the source IP address.

The Identity Firewall integrates with an identity provider (for example, Microsoft Active
Directory), and the identity provider helps in authenticating the users before allowing them
network access.

45
2-37 Identity Firewall: Traffic Management
In an Identity Firewall, the traffic is managed based on the identity of the user.
The user is authenticated with the help of the identity provider and allowed access to the
network based on their identity. The identity provider generates security logs for each user
login.

The table includes sample security rules for an Identity Firewall.

Source (User) Destination Service Action

User1 30.10.0.1 http Allow

User2 30.10.0.1 http Deny

After successful authentication of User1, the first rule allows him to establish http communication
to the destination 30.10.0.1.

Even after successful authentication of User2, the second rule does not allow him to establish
http communication to the destination 30.10.0.1 based on the identity (user name) of the user.

46
2-38 Advantages and Limitations of Identity
Firewalls
Identity Firewalls have the following advantages:

• Simplify the creation of security policies

• Enable easy identification of user activities on network resources

• Simplify user activity monitoring

Identity Firewalls have the following limitations:

• A compromise of the identity provider or the user agent can lead to serious security
breaches.

• A new user cannot access resources if a connection failure occurs between the Identity
Firewall and the identity provider or the user agent.

47
2-39 Knowledge Check: Introduction to
Firewalls
Go to https://via.vmw.com/KC2 to answer questions about this content.

48
2-40 Review of Learner Objectives
• Define firewalls
• Explain firewall rules

• Describe stateless firewalls, their advantages, disadvantages, and use cases

• Describe stateful firewalls, their advantages, disadvantages, and use cases

• Explain application firewalls, their advantages, disadvantages and use cases

• Explain Identity Firewalls, their advantages, disadvantages, and use cases

49
2-41 Lesson 3: Introduction to Intrusion
Detection and Protection

2-42 Learner Objectives

• Define Intrusion Detection systems

• Define Intrusion Prevention systems

• Describe the different types of Intrusion Detection and Intrusion Prevention systems

• Combine Intrusion Detection/Intrusion Prevention systems

• Describe the different detection methods used by Intrusion Detection/Intrusion Prevention

systems, their advantages, and disadvantages

• Explain the selection criteria for an Intrusion Detection/Intrusion Prevention solution

50
2-43 About Intrusion Detection Systems
An Intrusion Detection System (IDS) is a specialized system that parses and interprets network
traffic and host activities. This system compares patterns of activity, traffic, or behavior against
known attacks.

An IDS generates an alarm when a close match between a signature and patterns of activity,
traffic, or behavior in a network or host occurs. It does not block traffic.

51
2-44 Features of Intrusion Detection Systems
An IDS has the following features:
• Monitors and analyzes traffic continuously to detect intrusive behavior or attack

• Raises alarms or alerts if an unusual behavior or attack occurs

• Provides detailed logs about all activities

52
2-45 Limitations of Intrusion Detection
Systems
An IDS has the following limitations:

• It only provides visibility to possible attacks.

• It does not add another layer of security unless you have the right personnel and policy to
administer them and act on any threats.

• An IDS cannot read the contents of encrypted packets. Intruders can use these packets to
enter the network.

• The information from an IP packet is read by an IDS, but the network address can be
spoofed.
• False positives are frequent if the IDS is not properly tuned.

• The signature library must be continually updated to detect the latest threats.

53
2-46 About Intrusion Prevention Systems
An IPS system is an active device in the traffic path, which detects and prevents activity, traffic,
or behavior that is intrusive or malicious.

54
2-47 Features of Intrusion Prevention Systems
An IPS has the following features:
• Proactively detects and denies any malicious activity or attack

• Generates alarms or alerts if a security breach occurs

• Provides detailed logs about all activities

• Analyzes the traffic pattern continuously

• Helps in retrospective analysis after a security breach

55
2-48 Limitations of Intrusion Prevention
Systems
An IPS has the following limitations:

• More resource-intensive when compared to IDS

• Must be properly tuned to avoid blocking legitimate traffic

56
2-49 Types of Intrusion Detection and
Prevention Systems
IDS/IPS systems are of several types.

Network IDS/IPS Monitors network links and backbones, looking for attacks or any signs of
intrusion

Host IDS/IPS Operates on hosts, and defends and monitors the operating and file systems
for signs of intrusion

Distributed Mix of Network IDS/IPS and Host IDS/IPS systems, functioning as remote
IDS/IPS sensors and reporting to a central management system

Gateway IDS/IPS Combination of IDS/IPS functions in a gateway, which resides between your
internal and external networks

57
2-50 Combining Intrusion Detection/Intrusion
Prevention Systems
Intrusion Detection/Intrusion Prevention systems are complementary technologies that are
often deployed in parallel in enterprise networks.

In an enterprise network, an Intrusion Prevention system is usually placed close to the network
perimeter to block any malicious activity observed in the North-South traffic. On the other hand,
an Intrusion Detection system is used to monitor either the internal hosts or the internal East-
West traffic and generate an alarm if intrusive behavior is observed.
In the scenario, the attacker tries to access the internal host and the internal server with the help
of different attacks. Many attacks are detected and blocked by the IPS. Some attacks bypass
the IPS and enter the internal network.

The Host Intrusion Detection or Prevention system on the host detects the malicious activity
that bypassed the IPS and generates alarms or blocks the malicious activity.

Also, the IDS present in the network detects the intrusive traffic when it passes through the IDS
and tries to access the server. It generates alarms accordingly.
58
2-51 Types of Detection Methods
Intrusion Detection/ Intrusion Prevention systems use different detection methods for event
analysis:
• Signature-Based Detection

• Anomaly-Based Detection

• Protocol-Based Analysis

• User Behavior-Based Analysis

59
2-52 Signature-Based Detection
In this approach, the attack signatures are stored in a database and IDS/IPS detects intrusions
by matching these attack signatures with the network traffic.

In the scenario, the attacker tries to use the CGI scripts to perform an attack by sending
illegitimate inputs to the web server.

The attacker tries to access the /etc/shadow location with the help of a HTTP GET request.
The /etc/shadow file contains all passwords of users of the system. The attacker tries to
fetch all the available entries in this location.

IDS/IPS already has the signature of such attack patterns and blocks or generates an alarm
when it notices such malicious behavior.

60
2-53 Advantages and Limitations of Signature-
Based Detection
Signature-Based detection methods have the following advantages:

• Known attack patterns lead to less false positives

• Easy to implement

• Less resource-intensive

Signature-Based detection methods have the following limitations:

• Dependent on the signature database that needs to be frequently updated

• Slow or no reaction to new attacks

61
2-54 Anomaly-Based Detection
This detection method uses predefined rules to differentiate between normal and abnormal
activities.

In the scenario, the attacker tries to flood the server with UDP traffic, which is an abnormal
behavior according to the predefined rules present in IDS/IPS. IDS/IPS generates an alarm or
blocks the UDP flood because it understands that this behavior is anomalous.

62
2-55 Advantages and Limitations of Anomaly-
Based Detection
Anomaly-Based detection methods have the following advantages:

• Detects malicious network or compute behavior that is different from regular behavior

• Detects unknown attacks

Anomaly-Based detection methods have the following limitations:

• Requires a system learning period to define rules for normal and abnormal activity

• More false positives because of dependency on learned data (which can be correct or
incorrect)

• Greater implementation complexity

63
2-56 Protocol-Based Analysis
In this detection method, IDS/IPS inspects the traffic and looks for any mismatch in the protocol
header.

In the scenario, the attacker is trying to send malformed SNMP packets to the server by
changing the SNMP protocol header. IDS/IPS does a deep packet inspection to analyze the
protocol header and figures out the difference in the packet header. Then, IDS/IPS generates
alarms or blocks the malformed SNMP packets.
Usual SNMP packets are allowed to the SNMP server.

64
2-57 Advantages and Limitations of Protocol-
Based Analysis
Protocol-Based detection methods have the following advantages:

• Provides granularity up to the protocol level, ensuring that applications use legitimate
protocols

• Detects protocol header malformation

• Helps in deep packet inspection and investigates the protocol metadata

Protocol-Based detection methods have the following limitations:

• Requires proper fine tuning for deep packet inspection

• Resource-intensive

65
2-58 User Behavior-Based Analysis
Based on the daily activity of a user, IPS learns sample data and stores it in the database. User
activity is compared with the learned data to discover significant deviations.

In the scenario, the attacker manages to bypass the perimeter IPS and tries to use the end HR
host as a Command and Control (CNC) system. The attacker tries to access the /sbin folder,
which contains all the system administration utilities.

HIDS/HIPS analyzes this behavior based on the learned sample data and identifies it as unusual
behavior. It generates an alarm or blocks the HR user on the end HR host. Eventually, the
attacker is logged out of the end system.

66
2-59 Advantages and Limitations of User
Behavior-Based Analysis
User Behavior-Based detection methods have the following advantages:

• Detects intrusive behavior, which is significantly different from normal behavior, on end
hosts

• Detects any unknown attack pattern on the host

User Behavior-Based detection methods have the following limitations:

• Needs sample data for the initial learning about the usual behavior of the end user

• More false positives if the normal user must perform unusual tasks

• Greater implementation complexity

67
2-60 Selecting an Intrusion Detection/Intrusion
Prevention Solution
The diagram shows the different criteria to select an IDS/IPS solution.

Security:

• The IDS/ IPS solution should be able to provide preventive protection

• It should be able to accurately detect the intrusive or malicious behaviors

• Backed by highly-qualified security research team

Reliability:

• The IDS/IPS solution should be always available. You should be able to deploy it in primary
and standby mode. If the primary IDS/IPS stops, the secondary IDS/IPS should be available
to protect the network.

• Hardware components should be redundant and hot-swappable.

68
Vendor confidence:

• The Industry experience, leadership, and recognition of the IDS/ IPS vendor should be
considered.

• The solution from the vendor should have valid and globally acceptable industry
certifications.

• The vendor should provide good customer support.

Deployment:

• The IDS/IPS solution should be easy to deploy.

• Deployment flexibility must be available while using it in a multivendor environment.

Management:

• The IDS/IPS solution should have scalable and flexible central and local management.

• Detailed and clear reporting, analysis, and alerting should be available.

• Integration with existing IT infrastructure should be easy.

Performance:

• The IDS/IPS solution should have high throughput.

• The solution should have low latency.

• It should have some guaranteed uptime.

69
2-61 Knowledge Check: Introduction to
Intrusion Detection and Protection
Go to https://via.vmw.com/KC3 to answer questions about this content.

70
2-62 Review of Learner Objectives
• Define Intrusion Detection systems
• Define Intrusion Prevention systems

• Describe the different types of Intrusion Detection and Intrusion Prevention systems

• Combine Intrusion Detection/Intrusion Prevention systems

• Describe the different detection methods used by Intrusion Detection/Intrusion Prevention

systems, their advantages, and disadvantages

• Explain the selection criteria for an Intrusion Detection/Intrusion Prevention solution

71
2-63 Key Points
• Information Security is the practice of protecting information from unauthorized access and
use.
• The Confidentiality, Integrity, and Availability (CIA) triad is a security model that helps to
plan various parts of IT security.

• A firewall is a system that prevents unauthorized access to or from a private network.

• An Application Firewall control input/output or system calls an application or service.

• Identity Firewalls allow or deny access to network resources based on the user identity.

• An Intrusion Detection System parses and interprets network traffic and host activities and
raises alarm.
• An Intrusion Prevention System is an active device in the traffic path, which detects and
prevents malicious traffic or activity.

Questions?

72
Module 3
VMware Intrinsic Security

3-2 Importance
Intrinsic Security is the VMware approach to security. This feature helps unify security
operations. Understanding the intrinsic security strategy and portfolio allows administrators to
effectively secure their environment.

73
3-3 Lesson 1: VMware Intrinsic Security

3-4 Learner Objectives

• Define the VMware Intrinsic Security strategy

• Describe the VMware Intrinsic Security portfolio

• Define how NSX-T Data Center aligns with the intrinsic security strategy

74
3-5 Modern Data Center Security Challenges
With the evolution and growth of modern data centers, achieving reliant and effective security
becomes complex.

The digital world is reliant on effective cybersecurity. With the increase of digitized business
processes and the workplace expansion to remote working and digital customer experiences,
securing applications, data, and devices is of paramount importance.

This security includes minimizing risks, deploying consistent security controls, enforcing
compliance, and implementing strategies, such as Zero Trust that maximize protection.

Achieving these goals is not easy. Most organizations manage too many bolted-on security
solutions with siloed teams that often work with limited context and information about the
potential impacts of threats:

• Bolted-on solutions: The average company owns greater than 80 security products.
Managing so many products is not easy, especially if each product introduces a separate
agent or specialized interface resulting in creating more complexity and making security
harder to manage.

• Siloed teams: Cybersecurity requires collaboration between application, network, compute,

and security teams. Often, these groups are working in silos, using their own products and
tools. This lack of cohesion can prevent teams from working together toward joint solutions.

• Threat-centric solutions: Most solutions across the security spectrum focus on isolating
threats and protecting against them without providing enough knowledge or context around
what they are trying to protect. A threat-centric approach is always reactive and on the
attacker’s terms.

75
3-6 About Intrinsic Security
Intrinsic security uses the infrastructure across any application, any cloud, and any device to
protect applications and data everywhere.

Intrinsic security is a fundamentally different approach to security. This strategy uses threat
intelligence in addition to using the infrastructure and control points in new ways across any
application, cloud, or device. Intrinsic security helps unify all the teams in a company, accelerating
how they identify risk, prevent, detect, and respond to threats with the right context and
insights.

Intrinsic security helps in shifting from a reactive posture to a position of strength by moving
from a bolted-on to a built-in solution, from siloed to unified teams, and from a threat-centric to a
context-centric solution:

• Built-in solution: Rather than relying on standalone products, an intrinsic approach maximizes
security controls built directly into the infrastructure. Intrinsic security is built directly in the
software enabling you to use the existing infrastructure in new ways to protect endpoints
and workloads, networks, workspaces, and clouds, while gaining greater visibility and control
over policies to protect your business.
• Unified teams: An intrinsic security approach brings tools and teams together by enabling
security professionals to use data and events from IT and operations to control threats and
policies more effectively. This unified approach uses cloud, application, and device
infrastructure to provide richer insights about applications and the infrastructure.

By bringing together the technology and insights used by the security and the IT teams, you
can increase your team's agility to respond to new vulnerabilities and active threats.
• Context-centric solution: Intrinsic security aims to provide a rich context solution to enable
you to act faster to prevent or respond to a new threat.

76
Context-centric security creates awareness about behaviors and intended actions, including
data, users, access points, and configurations. It provides a powerful intelligence to quickly
identify:

— Workloads that compose applications

— Communication between applications

— Network services that the applications consume

— Users and devices connecting to these applications

— Posture of these devices

77
3-7 VMware Security Portfolio
VMware provides a range of solutions to achieve intrinsic security by securing and protecting all
workloads.

VMware provides a range of solutions to achieve intrinsic security. With this portfolio, you can
protect and secure all workload from the network to identity and access control in addition to
endpoints and cloud security:

• NSX Distributed Security includes the NSX Distributed Firewall and NSX Distributed
IDS/IPS. NSX Distributed Security enables you to secure data center traffic across virtual,
physical, containerized, and cloud workloads:

— NSX Distributed Firewall is a distributed, scale-out internal firewall that protects east-
west traffic.
— NSX Distributed IDS/IPS is an advanced threat detection engine that detects lateral
threat movement on east-west traffic across multicloud environments.

• NSX Advanced Load Balancer provides multicloud load balancing, web application firewall,
and application analytics across on-premises data center and clouds.

• NSX Gateway Security connects isolated, stub networks to shared uplink networks by
providing common gateway services such as NAT and IPsec.

78
• NSX Intelligence is a distributed analytics solution that provides visibility for NSX-T Data
Center environments. NSX Intelligence enables network and application teams to deliver
granular security posture, simplify compliance analysis, and enable proactive security.

• NSX Network Detection and Response is a platform that detects and contains sophisticated
cyber threats on premise or in the cloud.

• VMware SD-WAN virtualizes WAN connections to deliver high-performance, reliable branch

access to cloud services, private data centers, and SaaS-based enterprise applications.

• VMware Carbon Black is a cloud-native endpoint and workload protection platform.

• Workspace ONE securely delivers and manages any application on any device.

79
3-8 Firewall Concepts and Definitions
Network traffic is of the following types:
• North-south defines traffic that moves in and out of an organization’s network:

— Perimeter firewalls protect north-south traffic.

• East-west defines traffic that moves in an organization’s network:

— Internal firewalls protect east-west traffic.

Network segmentation divides a network into smaller, distinct subnetworks.

Network traffic is divided into the following types:

• North-south traffic has one end of the communication in the organization's network and the
other end outside (for example, to and from the Internet). North-south traffic typically
represents a small fraction of the overall traffic on a large organization’s network.

• East-west traffic has both ends of the communication in the organization's network. It
consists of applications workloads, users in the organization accessing an internal application,
or direct network traffic between two users (such traffic is often forbidden and its presence
indicates that something is wrong in the network). In modern data centers, east-west traffic
volume far surpasses north-south traffic volume.

80
Each type of network traffic has its own firewall solution:

• Perimeter firewalls protect north-south traffic. These firewalls exist between an

organization’s internal network and outside, usually the Internet. A perimeter firewall is the
last firewall between a traffic flow originating inside an organization’s network and the
Internet. Perimeter firewalls were originally the only firewalls present in an organization's
network.

• Internal firewalls exist in an organization’s network. Internal firewalls process east-west

traffic internal to an organization. The primary function of internal firewalls is to prevent the
lateral movement of attackers.

Network segmentation is a network security technique that divides a network into smaller,
distinct subnetworks and enables security teams to control each subnetwork’s security policies.
Network segmentation is applied on internal firewalls.

81
3-9 Service-defined Firewall Motivation
The modern data center is evolving at phenomenal speed, introducing new challenges for
security:
• Applications deploy across hybrid environments.

• Applications evolve, move, and use automation tools.

• The growing volume of east-west traffic introduces hair-pinning situations.

A strong defense at the perimeter only with the use of perimeter firewalls is not enough:

• Distributed internal firewalls protect large volumes of east-west traffic without sacrificing
security functionality, network performance, or manageability.

• Distributed internal firewalls combine traditional enterprise perimeter firewall capabilities and
network segmentation solutions to create an innovative firewall architecture.

The landscape of the modern data center is changing at a phenomenal speed. Workloads were
rapidly migrated from physical, to virtualized, to software-defined data centers. Today, most
data centers use multicloud environments, mobile devices, and new architectures such as
microservices and containers.
In the past, applications were static and typically confined to one environment. Today,
applications deploy across hybrid environments leading to a lack of visibility for the infrastructure
administrator.

Automation-driven application deployment models and continuously changing applications have

resulted in infrastructure and security teams having to continuously redefine networking and
security configuration across various platforms and network and security solutions.

Today, the volume of east-west traffic is higher than the north-south traffic (around 85 percent
of the total traffic).

82
Using only perimeter firewalls to secure an environment leads to hair-pinning situation,
throughput constraints, selective visibility, and a lack of consistency. A strong defense at the
perimeter only is not enough anymore.

Instead of relying exclusively on perimeter security, organizations must focus on detecting and
blocking malicious east-west (internal) network traffic as a core component of their information
technology security strategy. This requires an internal firewalling approach specifically designed
to protect large volumes of east-west data center traffic without sacrificing security
functionality, network performance, or manageability.

Distributed internal firewalls borrow distributed enforcement from network segmentation

solutions to manage east-west traffic scale and granularity requirements. Simultaneously, they
retain the enterprise edge firewall’s ability to create and enforce security policies based on users
and applications and include threat controls such as IDS/IPS, NTA/NDR, and sandboxing.

83
3-10 About NSX Service-defined Firewall
NSX Service-defined Firewall includes a distributed internal firewall, an intrusion
detection/prevention system (IDS/IPS), and behavior-based network traffic analysis.

NSX Service-defined Firewall secures data center traffic across virtual, physical, containerized,
and cloud workloads. It includes:

• A distributed stateful layer 7 internal firewall

• An intrusion detection system and intrusion prevention system (IDS/IPS)

• Deep analytics with NSX Intelligence

NSX Service-defined Firewall protects data center traffic from internal threats and avoids
damage from threats that make it past the network perimeter.

NSX Service-defined Firewall allows businesses to gain superior protection against lateral
movement of malware with advanced threat prevention. It also mitigates risk with an intrinsic
security approach that enables compliance, and simplifies and scales operations cost effectively
without compromising security.

The Service-Defined Firewall enforces a uniform set of security policies across workloads,
irrespective of the underlying infrastructure (on-premises or public cloud) or the workload
(physical server, virtual machines, or container).

84
3-11 NSX Service-defined Firewall Use Cases:
Network Segmentation
Network segmentation creates security zones in an organization:

• Quickly deploy new virtual zones independent of the scale of the environment.

• Use the existing network infrastructure.

• Provide visibility and control over applications.

Network segmentation separates different lines of business, provides external partners with
access to few applications, and secures DMZ workloads that are exposed to the outside.

Traditionally, the infrastructure was physically separated to achieve this segmentation between
tenants or between the DMZ and the rest of the environment. Workloads and data for different
tenants or different zones were hosted on different servers with their own dedicated firewalls.
This method led to suboptimal use of hardware resources.

NSX Service-defined Firewall allows organizations to run workloads that belong to different
tenants and different zones on the same hypervisor clusters and provide the same level of
segmentation they might get with physical firewalls and IDS appliances.

85
3-12 NSX Service-defined Firewall Use Cases:
Secure VDI
Desktop isolation can be achieved for the entire VDI environment:

• Stop lateral movement of attackers by blocking vulnerabilities.

• Stop malware from spreading in VDI environments.

• Supported for both VDI and RDSH.

• Work with both Citrix and VMware Horizon.

The use of contextual and identity-based security policies blocks the lateral movement between
virtual desktops.

Virtual Desktop Infrastructure (VDI) and Remote Desktop Session Host (RDSH) are two
technologies used to create virtualized desktop environments. VDI uses Windows or Linux Client
OS and creates one VM per user, while RDSH uses Windows Server OS and allows many users
to connect to the same VM.

In the example, the following rules have been set up:

• Users in Desktop Pool cannot talk to each other.

• User B in Desktop Pool can access Finance_app.

86
3-13 NSX Service-defined Firewall Use Cases:
Compliance
NSX Service-defined Firewall enables you to quickly achieve compliance:

• Easily achieve compliance for PCI-DSS, HIPAA, SOX, CIS, and so on.

• Remove blind spots.

• Ensure compliance regardless of workload location.

• Increase visibility in compliance zones.

Payment Card Industry Data Security Standard (PCI-DSS) is an information security standard
designed to reduce payment card fraud by increasing security controls around cardholder data.
Health Insurance Portability and Accountability Act (HIPAA) regulates the use and disclosure of
protected health information.

Sarbanes-Oxley Act (SOX) protect shareholders and the public from accounting errors and
fraudulent practices.

Center for Internet Security (CIS) benchmarks are security standards for defending IT systems
and data against cyberattacks.

87
3-14 NSX Service-defined Firewall Use Cases:
Internal Appliance Consolidation
NSX Service-defined Firewall consolidates the internal infrastructure:

• Replace discrete centralized appliances.

• Unify management by using native distributed IDS/IPS capabilities in NSX.

• Move the enforcement close to the workload.

• Lower the operating expenses.

When using traditional Perimeter Firewall and traditional Distributed IDS/IPS appliances, you
must hairpin east-west traffic to and from the appliance. Hair-pinning creates traffic jam and it
becomes a bottleneck whenever there is a sudden increase in traffic. In addition to increasing
latency, hair-pinning east-west traffic adds complexity, both from a network design and an
operations perspective.

A distributed, scaled-out internal firewall removes this hair-pinning situation and optimizes the
traffic flow. NSX Service-defined Firewall monitors large volume of east-west traffic without
creating a single choke point. It enables organizations to secure all east-west traffic while
minimizing the impact on network and server infrastructure.

88
3-15 Distributed Firewall
The distributed firewall is a distributed, scaled-out internal firewall that protects all east-west
traffic in the virtualized environment.

Benefits:

• Simplify security architecture

• Prevent unauthorized lateral movement on east-west traffic

Use cases:

• Rapidly deploy network segments

• Achieve Zero Trust network architecture

The distributed firewall provides visibility and control for virtualized workloads and networks.

89
Distributed firewalls offer the following benefits:

• Simplify security architecture: The distributed firewall radically simplifies network

deployment and operations by removing the need for network redesign, traffic hair-pinning,
or agent management. The distributed firewall deploys as a module on the transport nodes
during the installation of NSX.

• Prevent unauthorized lateral movement on east-west traffic: The distributed firewall is built
directly into the infrastructure. It has visibility of the network and workload context but
remains isolated from the attack surface.
Distributed firewalls apply to the following use cases:

• Rapidly deploy network segments: The distributed firewall speed and flexibility allows to
quickly create and reconfigure network segments, virtual security zones, or partner domains
by defining them entirely in the software. It removes the need to deploy discrete appliances
or to perform any network re-architecture.

• Achieve Zero Trust network architecture: Zero Trust is a security model based on the idea
that no network traffic should be trusted unless a security policy explicitly says otherwise.
The distributed firewall creates, enforces, and automatically manages granular segmentation
policies. These policies are created between applications, services, and workloads across
multicloud environments spanning VMs, containers, and bare-metal infrastructure to achieve
zero trust security.

90
3-16 About NSX Distributed IDS/IPS
NSX Distributed IDS/IPS is an advanced threat detection engine that detects lateral threat
movement on east-west traffic across multicloud environments.

Benefits:

• Gain elastic throughput

• Reduce false positives

• Improve use of compute capacity

Use cases:

• Detect lateral threat movements

• Replace discrete appliances

91
NSX Distributed IDS/IP offers the following benefits:

• Gain elastic throughput: NSX Distributed IDS/IPS removes hardware bottlenecks by using
inspection capacity that scales automatically with each workload.

• Reduce false positives: NSX Distributed IDS/IPS achieves more zero false-positive
workloads with curated rulesets and higher-fidelity signature matches based on precise
application context. For information, see VMware NSX Distributed IDS/IPS: A new
paradigm for east-west security at
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/v
mw-nsx-distributed-ids-ips-tech-white-paper-dec.pdf.

• Improve use of compute capacity: NSX Distributed IDS/IPS reuses existing compute
capacity and removes the need for dedicated appliances.

NSX Distributed IDS/IP applies to the following use cases:

• Detect lateral threat movements: NSX Distributed IDS/IPS inspects granular east-west
network traffic at every workload to effectively detect both known and unknown threats.

• Replace discrete appliances: By using native IDS/IPS capabilities in NSX, traditional IDS/IPS
appliances, including standalone, firewall-based, or virtual host-based can be replaced.

92
3-17 About NSX Intelligence
NSX Intelligence is a distributed analytics solution that provides visibility and dynamic security
policy enforcement for NSX Data Center environments.

Benefits:

• Natively integrated into NSX

• Distributed architecture

• Comprehensive layer 7 inspection

• Complete workflow context

Use cases:

• Automate segmentation recommendations

• Demonstrate and maintain policy compliance

• Simplify security incident troubleshooting

• Enhance protection against lateral movement

93
NSX Intelligence is a distributed analytics solution that provides visibility and dynamic security
policy enforcement for NSX-T Data Center environments. NSX Intelligence enables network and
application teams to deliver a more granular security posture, simplify compliance analysis, and
enable proactive security.

NSX Intelligence offers the following benefits:

• Natively integrated into NSX: The fact that NSX Intelligence is embedded in NSX simplifies
its operational model. You do not need to install other agents or mirror traffic to extra
appliances. Furthermore, the familiar NSX UI performs all management functions.
• Distributed architecture: Packet processing and workload analysis are distributed to each
hypervisor. The processing is in line with the distributed firewall in the hypervisor, making it
highly efficient with minimal overhead.

• Comprehensive layer 7 inspection: By using the NSX distributed firewall, the engine
processes every packet with a complete understanding of state and layer 7 context
(including protocol analysis and application ID).

• Complete workflow context: NSX Intelligence inventories all endpoints and traffic flows. It
also consolidates metadata and configuration data from NSX, vSphere, and so on to provide
complete workload context.

NSX Intelligence applies to the following use cases:

• Automate segmentation recommendations: NSX Intelligence simplifies the segmentation

operations by using automated firewall policy recommendation, iterative policy workflow,
and real-time visualization of application dependencies and security policies.

• Demonstrate and maintain policy compliance: NSX Intelligence provides a record of every
flow, from every workload, with continuous analysis. NSX Intelligence also highlights
misconfigurations, policy exceptions, and noncompliant flows between workloads or
security scopes.

• Simplify security incident troubleshooting: NSX Intelligence creates a detailed topology

visualization in the NSX UI with complete inventory and metadata of every workload. NSX
Intelligence removes blind spots by providing a continuous layer 7 analysis of every flow
without sampling.

• Enhance protection against lateral movement: NSX Intelligence proactively detects

anomalous behavior in network traffic patterns with built-in detection for classic attack
techniques such as network scans, exfiltration over alternate protocols, mismatched
application layer protocols, and so on.

94
3-18 Network Detection and Response
Network Detection and Response (NDR) provides advanced threat detection by detecting
malicious network behaviors.

NSX Network Detection and Response is a platform that detects and contains sophisticated
threats before they disrupt the business. NSX Network Detection and Response protects
network, cloud, and hybrid cloud traffic against MITRE ATT&CK techniques.
MITRE ATT&CK is a framework that documents attacker tactics and techniques based on real-
world observations.

NSX Network Detection and Response provides a cloud-based architecture that enables
sensors to gain comprehensive visibility into traffic that crosses the network perimeter (north-
south), as well as traffic that moves laterally in the perimeter (east-west), for both on-premises
network and cloud infrastructure.

NSX Network Detection and Response uses artificial intelligence and a combination of four
complementary technologies to detect and analyze the advanced threats that other tools miss
and reduces the number of false positives drastically:

• Network Traffic Analysis (NTA) detects anomalous activity and malicious behavior as it
moves laterally across the network.

• Intrusion Detection and Prevention detects and prevents known threats entering the
network. It applies AI to the malicious behaviors and malware samples collected to
automatically create IDS/IPS signatures.

• Advanced Threat Analyzer detects malicious content trying to enter the data center by
using sandboxing techniques with a full system emulation.
• Global Threat Intelligence updates the detection and analysis capabilities of NSX Network
Detection and Response in real time with threat intelligence.

NSX Service-defined Firewall with NSX Advanced Threat Protection provides a tightly
integrated set of network detection and response capabilities for east-west security in the data
center and multicloud environments.
95
3-19 NSX Gateway Security
NSX Gateway Security includes the following features:
• Stateful L4 firewall, NAT, IPSec VPN

• L7 AppID firewall

• URL analysis

• Routed mode deployment

NSX Gateway Security provides essential perimeter firewall protection that can be used in
addition to a physical perimeter firewall. It secures physical servers for traffic between virtual to
physical servers and physical to physical server workflows.

Each NSX Edge node implements the gateway firewall service, and Tier-0 and Tier-1 support this
service.

The gateway firewall provides a stateful layer 4 firewall and a layer 7 application firewall.

The gateway firewall deploys directly in the path of traffic (routed mode) and provides NAT,
IPSec VPN, and URL analysis features.
96
3-20 Knowledge Check: VMware Intrinsic
Security
Go to https://via.vmw.com/KC4 to answer questions about this content.

97
3-21 Review of Learner Objectives
• Define the VMware Intrinsic Security strategy
• Describe the VMware Intrinsic Security portfolio

• Define how NSX-T Data Center aligns with the intrinsic security strategy

98
3-22 Key Points
• VMware Intrinsic Security includes a wide portfolio of tools and products to protect
applications and data.
• NSX Service-defined Firewall includes a distributed firewall, an intrusion
detection/prevention system (IDS/IPS), and NSX Intelligence.

• NSX Gateway Security provides essential perimeter firewall protection and security
features such as IPSec VPN, NAT, and URL analysis.
Questions?

99
Module 4
Implementing Zero-Trust Security

4-2 Importance
To meet the security needs of the modern data centers, security administrators must
understand the Zero-Trust security strategy, how network segmentation helps build a Zero-
Trust architecture, and how to implement it.

4-3 Module Lessons

1. Zero-Trust Architecture

2. NSX Segmentation

101
4-4 Lesson 1: Zero-Trust Architecture

4-5 Learner Objectives

• Understand the traditional security challenges

• Define Zero-Trust security

• Understand the Zero-Trust architecture

• Describe the five pillars of a Zero-Trust architecture

102
4-6 Traditional Security Challenges
The traditional security model assumes that all users and components in an organization's
network can be trusted.

The foundation of IT security has looked almost the same for the last 30 years.

Traditional IT security is built on static information:

— If the device joined the domain.

— Whether the user has the correct password.

— Trusted users are inside the firewall. Threats and attacks come from the outside.

Virtual Private Network (VPN) and Multifactor Authentication (MFA) were introduced later to
ensure external protection. But these types of authentication are not enough.

This approach assumes that a user's identity is not compromised and that all users act
responsibly and can be trusted.
This traditional perimeter-centric security approach has proven inadequate for protecting
modern IT environments.

103
4-7 About Zero-Trust Security
Zero-Trust is a security model that does not automatically trust entities in the security perimeter.

Zero-Trust is a security model that does not automatically trust entities in the security perimeter.

This model emerged to mitigate the increase of network attacks and insider threats that exploit
the breaches of a traditional perimeter-centric approach to security.

The rapidly changing work styles and increased use of SaaS applications resulted in Zero-Trust
security becoming one of the most important forms of alternative security.

Zero-Trust moves the architecture from a single large DMZ to multiple smaller boundaries
around each application and data. If an attacker succeeds in penetrating one of these
boundaries, the attacker can only move in that perimeter and be easily contained.

104
4-8 Zero-Trust Architecture Principles
Zero-Trust security is defined by never trust, always verify, and enforce least privilege.
Zero-Trust architecture offers the following benefits:

• Have a strong knowledge about the user and the device used to request access.

• Enhance security around the data and application.

• Ensure secure transport and access.

• Implement security checks at each layer, extract logs, and build analytics.

• Implement automation and orchestration for remediation.

105
4-9 Zero-Trust Architecture
Zero-Trust security has a dynamic architecture model that establishes trust on all five of its
pillars.

Unlike the traditional security architecture, Zero-Trust recognizes that trust is a vulnerability.
Trust is built on a broader and deeper basis.
Zero-Trust security has a dynamic architecture model that contains five distinct pillars:

• Device

• User

• Transport and session

• Application

• Data

The Zero-Trust architecture has the following requirements:

— Trust must be established on each pillar.

— Decision to grant or deny access must be made for each pillar.

— The trust (once granted) needs to be reassessed often.

— When a change occurs, immediate action must be taken.

When trust is established on all five pillars and a good logging system is in place, visibility is
achieved.
This information can then be used to learn, monitor patterns, and build analytics for the
environment.

Visibility and analytics are of utmost importance in the Zero-Trust architecture because they
permit effective dynamic policies, trust decisions, and threat remediation using automation and
orchestration tools.

With the Zero-Trust architecture, all applications and data are equally protected, and no users or
devices are trusted by default.
106
4-10 Device Trust
Devices within an organization must first be known before being trusted. Then device
management and control can be configured.

Device Inventory: All hardware devices must be cataloged. The device inventory specifies which
devices are owned and controlled by the company. This inventory can then be used for access
control.

Device Management: Control over the devices is crucial in a Zero-Trust architecture. It includes
control over which software to install, which version, under what condition a given application
can be used, and so on. Security policies are used to put those controls in place.

Device Compliance: After determining the security policies, compliance checks must be run to
ensure that devices comply with the policies in place. Compliance checks must be run regularly
both at scheduled and unscheduled time. The solution should also support automatic remediation
when a device does not meet the expected security criteria.

Device Authentication: In addition to a strong password policy, digital certificates must be

installed on the devices to prevent unauthorized access.

107
4-11 User Trust
User trust is achieved by using secure authentication methods in addition to a strong conditional
access engine.

Passwordless Authentication: With passwordless authentication, users are authenticated without

entering passwords. Some examples of passwordless authentication are biometrics, security
tokens, one-time codes sent through email or phone, or certificate based-authentication.
Multifactor Authentication (MFA): A strong and secure authentication method is key to ensuring
a high level of trust in the user. However, relying on a password alone is not enough. MFA
requires two (or more) pieces of evidence to prove a user's identity. The evidence is usually a
combination of:

• Information that the user knows (password, security question, and so on)

• Information that the user has (security token, certificate, and so on)

• Information that is unique to the user (fingerprint, face/retina scan, and so on)

Conditional Access: Chaining authentication methods together is a good method to establish

higher security, but a strong conditional access engine is also required. Conditional access helps
determine whether and when to enforce stronger authentication. You narrow the conditions
under which access is granted to reduce the attack surface.

Dynamic Risk Scoring: A risk score must be calculated for each user and device. Administrators
can then use the user risk score and set policies for conditional access to applications and data.

108
4-12 Transport and Session Trust
Transport and session trust ensures that only valid requests are passed on by using
segmentation, encryption, and session protection.

Micro-segmentation is one of the core concepts of a Zero-Trust architecture. It involves

identifying traffic flows between workloads and allowing only the necessary flows. Micro-
segmentation enforces the least privileged access principle by giving users only as much access
as they need.

The NSX-T Data Center distributed firewall feature provides segmentation and least privilege
principle at the transport and network layer. Access to a network resource must be explicitly
permitted by a network security policy. Any unauthorized traffic is blocked.
Transport Encryption: In a Zero-Trust architecture, no distinction is made between internal and
external networks. Every packet must be encrypted. End-to-end transport encryption is crucial
to avoid data theft during transit.

Session Protection: A session is a temporary connection between two devices during which
information is exchanged. To protect the sessions from attackers, an effective authentication
system must be configured. Communications must be encrypted (to avoid replay attacks).
Finally, an expiration period must be defined to limit the amount of time attackers have to
perform an attack.

109
4-13 Application Trust
Application trust is gained by strong authentication methods and isolation.

Several available applications are not built for a Zero-Trust architecture model. Application trust
must then be gained by strong authentication methods and isolation:
• Single Sign-On (SSO): SSO allows users to authenticate to a system once and gain access
to many related but separate systems without authenticating again for the duration of the
session.
• Isolation: Segmentation of flows (as seen in the Transport and Session Trust pillar) can be
used to isolate and secure the applications. Example: only allow internal traffic between
application components and deny anything else. Another form of isolation is to separate one
program or application stack from the remaining running processes.

• Any Device Access: To enable employees to securely and seamlessly access any
application from any device is key to creating a digital workplace.

110
4-14 Data Trust
The last pillar of the Zero-Trust architecture is to keep the data safe by keeping its integrity, and
preventing data loss and data theft.

Protecting Data at Rest: In contrast to data in transit, data at rest represents data that is stored
on a stable medium. Securing the data at rest is as important as securing the data in transit.
Typical tools used to protect data at rest are antivirus software and encryption. Sensitive data
must also be isolated from other data.

The NSX-T Data Center distributed firewall contributes to protect data at rest with micro-
segmentation.

Integrity: data must be protected from unauthorized changes. Data must stay valid, accurate,
and consistent over its life cycle. Sources of integrity failure range from intentional alteration,
user error, and software or hardware error to act of nature. Most applications use hashing
functions to protect data integrity.

Data Loss Prevention (DLP): Policies must be implemented to protect sensitive data in
applications. DLP policies help prevent data leakage. For example, to prevent users from
accidentally leaking sensitive data, a security administrator can set up a policy that removes the
ability to copy and paste text and graphics in the application. DLP controls include copy/paste
restrictions, deny/allow websites, clear history and cookies in web browsers, enable encryption,
and so on.

Classification: Data classification is the process of classifying data based on its level of sensitivity
and the threat it represents to an organization. The classification of data helps determine the
baseline security controls that should be configured. Data is usually classified into sensitivity
levels such as restricted data, private data, or public data. Data should be periodically evaluated
and classified again.

111
4-15 VMware Portfolio
VMware provides a suite of products and solutions to establish trust in each pillar.

112
The diagram shows how VMware products and solutions can help establish trust in each of the
five pillars:

• Workspace ONE Trust Network provides access management capabilities to protect,

detect, and remediate threats.

• Workspace ONE UEM manages the full life cycle of any endpoint (mobile, desktop, and so
on).

• Workspace ONE Intelligence provides deep analytics and automation for the digital
workspace.

• Workspace ONE Access delivers multifactor authentication, conditional access, and single
sign-on for application.
• VMware Horizon delivers virtual desktops and apps.

• Unified Access Gateway secures the external access for Workspace ONE UEM, Workspace
ONE Access, and VMware Horizon deployments.

• VMware Dynamic Environment Manager manages profiles and policies across virtual,
physical, and cloud-based Windows desktop environments.

Products such as NSX-T Data Center span multiple pillars.

While NSX-T Data Center contributes to achieve a Zero-Trust architecture, it must be part of a
broader solution.

113
4-16 Review of Learner Objectives
• Understand the traditional security challenges
• Define Zero-Trust security

• Understand the Zero-Trust architecture

• Describe the five pillars of a Zero-Trust architecture

114
4-17 Lesson 2: NSX Segmentation

4-18 Learner Objectives

• Define NSX segmentation

• Recognize the use cases for NSX segmentation

• Identify the steps to enforce Zero-Trust with NSX segmentation

115
4-19 About NSX Segmentation
Segmentation is the process of dividing data center infrastructure into small zones, allowing fine-
grain control and inspection of traffic flows.
NSX Service-defined Firewall includes a distributed, scale-out internal firewall that simplifies and
automates both macro-segmentation and micro-segmentation:

• Macro-segmentation isolates and secures specific environments.

• Micro-segmentation isolates and secures specific applications in an environment.

Also called network segmentation, macro-segmentation isolates and secures specific

environments (virtual zones), such as development and production, from each other. Attackers
cannot move laterally between these environments.

Micro-segmentation enables security teams to define and enforce granular controls to the
workload level of an application.

116
4-20 Use Cases for NSX Segmentation
NSX Segmentation has the following use cases.
• Enforce a Zero-Trust architecture

• Rapidly deploy network segments.

• Isolate and secure applications.

With NSX Service-defined Firewall, security teams can deploy network segments easily, enable
application isolation, and enforce a Zero-Trust architecture with a single solution.
Use Cases:

• NSX Segmentation enforces a Zero-Trust architecture by creating granular policies

between applications, services and workloads.

• Network segments, virtual security zones, and partner domains are quickly created and
configured as they are entirely defined in software. NSX Service-defined Firewall also
removes the need to architect the network again and to deploy discrete appliances.

• Critical applications and shared services are protected from being compromised by two
mechanisms: autodiscovery of application boundaries and setting up segmentation policies
at the application level. NSX Service-defined Firewall also ensures that policies stay up-to-
date as applications evolve or move.

117
4-21 NSX Segmentation Benefits
NSX Segmentation offers key business and functional benefits:
• Limits lateral movement within the data center

• Minimizes risks and the effect of security breaches

• Simplifies network traffic flows

• Uses the existing underlay network infrastructure

• Lowers capital expenditures and operating expenses

• Automates IT service delivery

• Securely enables business agility

118
4-22 Enforcing Zero-Trust with NSX
Segmentation
Segmentation helps build a Zero-Trust approach to security by defining a security perimeter
around each application.

NSX Service-defined Firewall improves the security of today’s modern workloads by preventing
lateral movement using network segmentation. It is distributed, application-aware, and simple to
operate.

Follow this process to secure a data center environment with NSX segmentation:
1. Apply macro-segmentation to define virtual security zones.

2. In those security zones, identify the assets (understand the application behavior and
network flows).

3. Implement micro-segmentation to secure every application.

4. Implement contextual security policies.

You must always monitor the environment for changes or unexpected behavior and adapt the
security policies.

119
4-23 Step 1: Creating Virtual Security Zones
Protect segments of the network by creating virtual security zones.

Using macro-segmentation to isolate environments improves the security of the data center. It
prevents lateral movement between virtual zones.

Depending on their business structure and use cases, a security team typically chooses to
segment environments that should not be able to directly communicate with each other.
Examples include different business units (such as HR, Finance, and so on), partner environment,
and production environments.

Macro-segmentation provides a more flexible solution compared to a traditional appliance-based

firewall. It enables organizations to easily expand the number of zones needed and adapts easily
to changing network and security requirements as the business evolves.
Macro-segmentation is the first step to the Zero-Trust journey. It starts defining security zones in
the data center environment that will be further secured.

120
4-24 Step 2: Identifying the Applications
Boundaries
Identify the virtual machines and containers used by an application and the network traffic that is
necessary for the application to function.

When the network is macro-segmented into virtual security zones, you can move to micro-
segmentation and secure applications in a virtual zone.

121
Before implementing micro-segmentation, assets must be identified:

• Define the application boundaries by identifying the VMs and containers that an application
is using. Also, define the data, assets, applications, and services that need protection, such
as:

— Data: Credit Card Information, Protected Health Information (PHI), Personally

Identifiable Information (PII), Intellectual Property

— Assets: Point-of-sales terminals, manufacturing assets, IoT devices

— Applications: Custom or off-the-shelf software.

— Services: DNS, DHCP, Active Directory, LDAP, and so on.

• Identify how the traffic moves across the organization in relation to the previously defined
boundaries.

You must look for two types of traffic:

— External application traffic: Which user is connecting to the app, which shared services
the application is using, and so on
— Internal application traffic: Communication between the different application
components

A good understanding of the application footprint and the network traffic is the only way to
determine and enforce policies that secure access to the data.

This identification process is tedious and time consuming when performed manually. NSX
Intelligence or vRealize Network Insight can be used to automate the discovery of the
application boundaries.

122
4-25 Step 3: Implementing Micro-
Segmentation
Use micro-segmentation to allow necessary network traffic.

After the application's composition and necessary network traffic are identified, firewall rules
must be configured to allow necessary network traffic.

123
The NSX Distributed Firewall enables users to configure firewall rules from a single point, which
are then pushed to all the hosts that participate in the NSX network. The creation of rules can by
automated with NSX Intelligence. NSX Intelligence can recommend distributed firewall rules
based on the discovered traffic flows in the environment.

Micro-segmenting the network immediately reduces the attack surface of an application. It

restricts the application to only communicate with the resources that it absolutely needs.

In this process, security tags and security groups can be used:

• Security tags enable labeling NSX-T Data Center objects.

• Security groups include different objects that are added both statically and dynamically, and
can be used as the source and destination of a firewall rule. Security groups can use security
tags or other criteria (such as IP sets, MAC sets, segment ports, AD user groups, and so on)
to group virtual machines together.

124
4-26 Step 4: Securing Through Context
Set up security policies to establish the behavior of virtual machines and containers.

This step secures the traffic and the context of the application by setting up policies based on
the behavior of virtual machines and containers.

Security groups and tags can be used.

125
In the example, a security administrator wants to create a firewall policy to restrict network
access to VMs with an old version of Windows:

1. Tag VMs with the OS version used.

2. Create a security group that gathers all VMs that do not match the OS version threshold.

3. Create a security policy to restrict access to the members of that security group.

When a VM is created and does not meet the OS version criteria, it is automatically put in that
security group and blocked by the firewall rule. This approach removes the need for checking
each VMs individually.

Third-party services can be integrated to create more granular control. To find a list of NSX
partners, go to https:/www.vmware.com/products/nsx/technology-partners.html.

126
4-27 Knowledge Check: Implementing Zero-
Trust Security
Go to https://via.vmw.com/KC5 to answer questions about this content.

127
4-28 Review of Learner Objectives
• Define NSX segmentation
• Recognize the use cases for NSX segmentation

• Identify the steps to enforce Zero-Trust with NSX segmentation

128
4-29 Key Points
• Zero-Trust is a security model that does not automatically trust entities in the security
perimeter.
• Zero-Trust security has a dynamic architecture model that contains five distinct pillars:
device trust, user trust, transport and session trust, application trust, and data trust.

• NSX Data-T Center plays a role in the transport and session trust pillar and the data trust
pillar.
• Macro-segmentation is the process of dividing data center infrastructure into smaller zones.

• Micro-segmentation helps to build a Zero-Trust approach to security by defining a security

perimeter around each application.

• The NSX Service-Defined Firewall uses both macro-segmentation and micro-segmentation

to prevent lateral movement and protect workloads.

Questions?

129
130
Module 5
User and Role Management

5-2 Importance
You must manage users and roles to enforce the least user privilege and provide clear
separation of duties. By integrating NSX-T Data Center with VMware Identity Manager or LDAP,
you can configure role-based access control (RBAC) for external users.

5-3 Module Lessons

1. Integrating NSX-T Data Center with VMware Identity Manager

2. Integrating NSX-T Data Center with LDAP

3. Managing Users and Configuring RBAC

131
5-4 Lesson 1: Integrating NSX-T Data Center
with VMware Identity Manager

5-5 Learner Objectives

• Describe the purpose of VMware Identity Manager

• Identify the benefits of integrating NSX-T Data Center with VMware Identity Manager

• Configure the integration between NSX-T Data Center and VMware Identity Manager

• Verify the integration between NSX-T Data Center and VMware Identity Manager

132
5-6 About VMware Identity Manager
VMware Identity Manager is an identity as a service (IDaaS) solution.
VMware Identity Manager provides the following services for software as a service (SaaS), web,
cloud, and native mobile applications:
• Application provisioning
• Conditional access controls
• Single sign-on (SSO)

VMware products can use VMware Identity Manager as an enterprise SSO solution.

VMware Identity Manager is based on the OAuth 2.0 authorization framework.

133
To verify the version compatibility between NSX-T Data Center and VMware Identity Manager,
use the VMware Product Interoperability Matrix at
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&175=&140
=.

VMware Identity Manager is now offered as Workspace ONE Access.

134
5-7 Benefits of Integrating VMware Identity
Manager with NSX-T Data Center
VMware Identity Manager is the only user authentication method supported by NSX Federation.

The integration of VMware Identity Manager with NSX-T Data Center provides the following
benefits related to user authentication:

• Support for extensive authentication, authorization, and accounting (AAA) systems,

including:

— RADIUS

— Smart cards and common access cards

— RSA SecureID

— LDAP and OpenLDAP based on Active Directory (AD)

• Enterprise SSO:

— Common authentication platform across multiple VMware solutions

— Seamless SSO experience

In this release, NSX Federation only supports VMware Identity Manager integration.

NSX Federation includes an NSX Global Manager, which is used as a centralized console for
managing the network as a single entity while keeping configuration and operational state
synchronized across multiple locations. When configuring VMware Identity Manager, you must
configure every Local Manager and the Global Manager with VMware Identity Manager because
configuration for users and roles between the Global Manager and the Local Manager are neither
synchronized nor propagated.
NSX-T Data Center has its own native LDAP and Active Directory integration, but VMware
Identity Manager also offers this capability.

135
5-8 Prerequisites for VMware Identity
Manager Integration
The following prerequisites must be met before integrating VMware Identity Manager with NSX-
T Data Center:

1. Deploy the VMware Identity Manager appliance from an OVF template.

2. Configure time synchronization for the VMware Identity Manager virtual machine.

3. Perform an initial configuration of the VMware Identity Manager appliance.

136
The following steps must be completed before integrating VMware Identity Manager with NSX-
T Data Center:

1. From the vSphere Client, deploy the VMware Identity Manager appliance from an OVF
template.

2. Synchronize the VMware Identity Manager virtual machine time with the ESXi host where it
is running.

a.. Right-click the VM and select Edit Settings > VM Options.

b.. Scroll down to the Time section and select the Synchronize guest time with host
check box.

3. After deploying the VMware Identity Manager appliance, use the Setup wizard available at
https://<VMware_Identity_Manager_FQDN> to set passwords for the admin, root, and
remote SSH user and to select a database.

You can use the external Microsoft SQL or Oracle database, or the internal PostgreSQL
database. External Database is typically recommended for production environments and
high availability considerations. Internal Database can be used for a proof-of-concept
(POC).

137
5-9 Configuring VMware Identity Manager
After the initial setup, connect to the VMware Identity Manager administration console.
In the console, you configure the following settings:

• Identity sources

• Authentication methods

• Access policies

You can access the VMware Identity Manager Administration console at

https://<VMware_Identity_Manager_FQDN>:443/SAAS/admin.

The following identity sources are supported in VMware Identity Manager:

• Active Directory (AD) over LDAP or AD with integrated Windows authentication

• LDAP

• Local directory

To configure authentications methods, select Identity & Access Management > Authentication
Methods.

To define access policies, select Identity & Access Management > Policies.

Administrators can configure rules that specify the network ranges and types of devices that
users can use to sign in.

138
5-10 Overview of the VMware Identity
Manager and NSX-T Data Center
Integration
After both NSX-T Data Center and VMware Identity Manager appliances are deployed and
configured, you can integrate these components:

1. Create an OAuth client for NSX in VMware Identity Manager.

2. Obtain the SHA-256 certificate thumbprint for the VMware Identity Manager appliance.

3. Configure VMware Identity Manager details in NSX.

139
5-11 Creating an OAuth Client
Before enabling the integration of VMware Identity Manager and NSX-T Data Center, you must
register NSX-T Data Center as a trusted OAuth client in VMware Identity Manager:
1. From the VMware Identity Manager administration console, click the Catalog tab.

2. Select Settings > Remote App Access.

3. On the Clients page, click Create Client.

VMware Identity Manager uses the OAuth 2.0 authorization framework to enable third-party
applications, such as NSX-T Data Center and their users, to access specific data and services.
VMware Identity Manager protects the third-party account credentials.

Before enabling the integration between VMware Identity Manager and NSX-T Data Center, you
must register NSX-T Data Center as a trusted OAuth client in VMware Identity Manager.
140
When configuring NSX-T Data Center details, you select Service Client Token from the Access
Type drop-down menu. This selection indicates that the application, NSX-T Data Center in this
example, accesses the APIs for itself. The application does not access the APIs for a particular
user.

You must specify a client ID to uniquely identify NSX. You need this value to enable the VMware
Identity Manager integration.

You must also click Generate Shared Secret. You need this value to enable the VMware Identity
Manager integration.
Leave the default settings for all other options.

On the Create Client page, you can optionally set the token time-to-live values by specifying the
access, refresh, and idle timers.

141
5-12 Obtaining the SHA-256 Certificate
Thumbprint
Before you configure the integration between NSX-T Data Center and VMware Identity
Manager, you must obtain the SHA-256 certificate thumbprint of the VMware Identity Manager
appliance:

1. Use SSH to log in to the VMware Identity Manager appliance.

2. Run the sudo -s command to gain root access.

3. Navigate to the VMware Identity Manager configuration directory.

cd/usr/local/horizon/conf
4. Retrieve the SHA-256 certificate thumbprint of VMware Identity Manager.

openssl x509 -in sa-nsxvidm-01.vclass.local_cert.pem -noout

-sha256 -fingerprint
You need the SHA-256 certificate thumbprint value when you enable the VMware Identity
Manager integration.

142
5-13 Configuring VMware Identity Manager
Details in NSX-T Data Center
To enable VMware Identity Manager integration from the UI:

1. Select System > Settings > Users and Roles.

2. Click the VMWARE IDENTITY MANAGER tab.

3. Click EDIT.

4. Provide the configuration information and click SAVE.

143
In the OAuth Client ID and OAuth Client Secret text boxes, you enter the client ID and shared
secret that you generated when you created the OAuth client for NSX-T Data Center in
VMware Identity Manager.

In the SSL Thumbprint text box, you enter the SHA-256 certificate thumbprint value that you
generated from the VMware Identity Manager appliance command line.

The value entered in the NSX Appliance text box must be used to access NSX Manager after
the integration. If you enter the fully qualified domain name (FQDN) of NSX Manager and try to
access the appliance through its IP address, the authentication fails.
If a virtual IP (VIP) is set up in the NSX Management cluster, you cannot use the external load-
balancer integration even if you enable it. You can either have VIP or the external load balancer
while configuring VMware Identity Manager, but not both. Disable VIP if you want to use the
external load balancer. For information, see NSX-T Data Center Administration Guide at
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-
FBFD577B-745C-4658-B713-A3016D18CB9A.html .

144
5-14 Verifying the VMware Identity Manager
Integration
You can validate the successful communication between NSX-T Data Center and VMware
Identity Manager from the NSX UI.

Navigate to System > Settings > Users and Roles > VMWARE IDENTITY MANAGER to
validate the VMware Identity Manager integration. If the integration is successful, the VMware
Identity Manager Integration appears as Enabled, and the VMware Identity Manager appliance,
the OAuth Client ID, and the NSX Appliance fields are populated.

145
5-15 Default UI Login
The default login page appears when integration with VMware Identity Manager is not enabled.

The default login page also appears if integration with VMware Identity Manager is configured,
but VMware Identity Manager is down or not reachable at the time of the login.

146
5-16 UI Login with VMware Identity Manager
After the integration with VMware Identity Manager is enabled, you are redirected to the
VMware Identity Manager login page for authentication.

147
5-17 Local Login with VMware Identity
Manager
For troubleshooting or administration, you might need to bypass VMware Identity Manager
when the integration is enabled. Go to https://<NSX_Manager_FQDN>/login.jsp?local=true.

148
5-18 Review of Learner Objectives
• Describe the purpose of VMware Identity Manager
• Identify the benefits of integrating NSX-T Data Center with VMware Identity Manager

• Configure the integration between NSX-T Data Center and VMware Identity Manager

• Verify the integration between NSX-T Data Center and VMware Identity Manager

149
5-19 Lesson 2: Integrating NSX-T Data Center
with LDAP

5-20 Learner Objectives

• Identify the benefits of integrating NSX-T Data Center with LDAP

• Describe the LDAP authentication architecture

• Configure the integration between NSX-T Data Center and LDAP

150
5-21 About LDAP
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing and
managing distributed directory services.
Distributed directory services store information about users and groups, the network
infrastructure, and network services.

NSX-T Data Center 3.1 supports the following directory services or identity sources:

• Active Directory over LDAP

• OpenLDAP

151
5-22 Benefits of Integrating LDAP with NSX-T
Data Center
Integrating LDAP with NSX-T Data Center offers the following benefits:

• Reuses the existing directory service infrastructure

• Does not require the deployment of the VMware Identity Manager appliance

• Is simple to configure and manage

152
5-23 Authentication with LDAP
LDAP authentication operates as follow.

After integrating LDAP with NSX-T Data Center, the authentication process is as follows:

1. The user initiates a login request from the UI or the API.

2. NSX Manager receives the login request and creates an LDAP bind request to the
appropriate identity source, for example, Active Directory.

3. The identity source returns an LDAP bind response to NSX Manager.

4. The bind response might succeed or fail during authentication. If the status is success, NSX
Manager provides the appropriate access privilege based on the assigned RBAC role for the
user or group. If the status is failure, NSX Manager displays an authentication error.

153
5-24 Adding an Identity Source
You can add up to three identity sources.

You can add a new identity source by navigating to System > Settings > Users and Roles >
LDAP

You specify the following settings as part of the identity source configuration:

• Name: The name of the identity source.

• Domain Name: The domain you want to add as an identity source.

• Type: The following types of identity sources are available:

— Active Directory over LDAP

— Open LDAP

• LDAP Servers: The connection settings to your LDAP server (mandatory).

• Base DN: The point from where a server searches for users.

154
5-25 Configuring the LDAP Server
As part of adding an identity source, you specify the connection settings to the LDAP server.

You specify the following settings when configuring the connection to the LDAP server:

• Hostname/IP: The fully qualified domain name or the IP address of the LDAP server. In
LDAPS configurations, the FQDN must match the host name in the LDAP server certificate.

• LDAP Protocol: LDAP (unsecured) or LDAPS (secured).

• Port: The default LDAP port 389 and LDAPS port 636 are used for the directory sync. Do
not change the default values.

• Use StartTLS: This toggle is available only for the LDAP protocol. If enabled, SSL/TLS is
used to establish a secure connection.
• Certificate: LDAP server provides a certificate as part of the ADD/Check status workflow.
Accept the certificate.

• Bind Identity: Domain account with read permission for all objects in the domain tree.
• Password: Password for the bind identity account.

To verify that you can connect to the LDAP server, click Check Status (under Connection
Status).

155
5-26 UI Login with LDAP
You log in as an Active Directory or OpenLDAP user by specifying the domain name on the
NSX login page.

Log in with
user@domain and the
AD password.

If a domain is not provided, local authentication is performed.

156
5-27 Review of Learner Objectives
• Identify the benefits of integrating NSX-T Data Center with LDAP
• Describe the LDAP authentication architecture

• Configure the integration between NSX-T Data Center and LDAP

157
5-28 Lesson 3: Managing Users and
Configuring RBAC

5-29 Learner Objectives

• Identify the different types of users in NSX-T Data Center

• Recognize permissions and roles available in NSX-T Data Center

• Create and configure custom roles

• Assign roles to users

158
5-30 NSX-T Data Center Users
The following types of users can access the NSX-T Data Center environment:
• Local users

• Principal identity users

• External users:

— Active Directory and OpenLDAP users

— Users managed by VMware Identity Manager

Local users have been preconfigured by the system with specific roles and cannot be modified:

• admin with the Enterprise Administrator role.

• audit with the Auditor role.

Two new local users were added in NSX-T Data Center 3.1.1: guestuser1 and guestuser2. These
accounts are inactive by default and can be activated by the admin user by using the UI or the
API. Unlike the admin and audit users, these two users can be renamed and configured with
RBAC roles.

Principal identity users are unique users. These users own the object that they create, and
ensure that the object can only be modified or deleted by the owning principal identity. Principal
identity users are authenticated by client certificate. The authentication is local to NSX Manager.
Principal identities are usually used by third-party management platforms, such as VMware
Integrated OpenStack, Tanzu Kubernetes Grid Integrated Edition, vRealize Automation, and so
on, but they are also used by NSX Intelligence.

The nsx-intelligence principal Identity user is added when the NSX Intelligence appliance is
created. This user is configured with the Enterprise Administrator role, which cannot be modified.

159
5-31 Using Role-Based Access Control
RBAC enables you to restrict system access to authorized users.
Users are assigned roles, and each role has specific permissions:

• Local users are preconfigured with specific roles that cannot be modified.

• Principal identity and external users can be configured with any of the built-in roles or
custom roles.

Role-based access control (RBAC) is a method to enforce the least privilege and separation of
duties principles. RBAC restricts access based on the roles of individual users in a company.

160
5-32 Built-In Roles (1)
NSX-T Data Center provides built-in roles.

Role Description

Auditor Read permissions on all features

Enterprise Admin Full access permissions on all features

GI Partner Admin Role used for third-party endpoint protection

service insertion

LB Admin Read permissions on all networking services and

full access permissions on load-balancing
features

LB Operator Read permissions on all networking services and

load-balancing features

Netx Partner Admin Role used for third-party Network Introspection

service insertion

Network Admin Full access permissions on all networking

services

161
5-33 Built-In Roles (2)
Role Description

Network Operator Read permissions on all networking services and execute

permissions on monitoring and troubleshooting tools

Security Admin Full access permissions on all security configurations

Security Operator Read permission on all security configurations and execute

permissions on monitoring and troubleshooting tools

VPN Admin Read permissions on all networking services and full access
permissions on VPN features

162
5-34 Creating Custom Roles
The custom role-based access control (Custom RBAC) feature enables you to create custom
roles in addition to the existing built-in roles.

In this example, the users get full access to

the VPN and NAT services and read-only
access to the other networking features.

You can clone an existing role or

create a role.

Click any of the permissions to

access the Set Permissions menu.

When default roles cannot enforce least user privileges and clear separation of duties, Custom
RBAC helps enforce these options by providing more granularity. Custom RBAC provides
flexibility and customization opportunities for specific deployment considerations and use cases.

Only the Enterprise administrator can create a custom role. However, Enterprise administrators
can delegate the custom role creation to another custom role.

Custom RBAC has the following common use cases:

• Provide flexibility to create custom roles and grant custom permissions to NSX users

• Extend the current RBAC capabilities beyond the built-in roles with preconfigured
permissions
• Help companies to meet regulatory guidelines and compliance requirements for RBAC

163
The following NSX features are not supported with the Custom RBAC role:

• Upgrade

• Migrate

• Fabric

• TraceFlow

• NSX Intelligence

• Inventory of physical servers and containers

164
5-35 Role Assignment
You can add, change, and delete role assignments for users or user groups:
1. Select System > Settings > Users and Roles > USERS.

2. Click ADD and select a user type.

— Role Assignment for VIDM

— Role Assignment for LDAP

— Principal Identity with Role

3. Select the search domain.

4. Search for the users or user groups that you want to assign the roles to.

5. Select a role or roles and click SAVE.

When selecting a role for a user, you can In this example, you
choose from built-in or custom roles that created an LDAP user.
were created previously.

The nsx-intelligence principal identity user is added when the NSX intelligence appliance is
created. This user is configured with the Enterprise Administrator role and cannot be modified.

165
5-36 Lab 1: Reviewing the Lab Environment
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

166
5-37 Lab 2: Managing Users and Roles
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

167
5-38 Review of Learner Objectives
• Identify the different types of users in NSX-T Data Center
• Recognize permissions and roles available in NSX-T Data Center

• Create and configure custom roles

• Assign roles to users

168
5-39 Key Points
• VMware Identity Manager provides application provisioning, conditional access controls, and
SSO for SaaS, web, cloud, and native mobile applications.
• You can integrate NSX-T Data Center with VMware Identity Manager and configure RBAC
for users that VMware Identity Manager manages.

• You can add Active Directory over LDAP or OpenLDAP identity sources to NSX-T Data
Center and configure RBAC for these users.
• Role-Based Access Control enables you to restrict system access to authorized users.

• The custom RBAC feature in NSX-T Data Center enables administrators to create custom
roles in addition to the existing built-in roles.

Questions?

169
170
Module 6
Distributed Firewall

6-2 Importance
NSX-T Data Center includes a distributed firewall to protect the east-west traffic. You must
understand the architecture, configuration, and troubleshooting of a distributed firewall to ensure
that your workloads are protected. Additionally, you can use time-based and Identity Firewall
rules for more granular traffic filtering based on time and user identity, respectively.

6-3 Module Lessons

1. Configuring the Distributed Firewall

2. Distributed Architecture and Troubleshooting

3. Time-Based Firewall Rules

4. Identity Firewall

171
6-4 Lesson 1: Configuring the Distributed
Firewall

6-5 Learner Objectives

• Identify types of firewalls in NSX-T Data Center

• Describe features of distributed firewalls

• Create firewall policies

• Configure firewall rules

• Configure firewall rule attributes: groups, services, and profiles

• Save, roll back, import, and export the distributed firewall configuration

172
6-6 NSX-T Data Center Firewalls
NSX-T Data Center includes two types of firewalls: the distributed firewall (east-west) and the
gateway firewall (north-south).
The distributed firewall is a hypervisor, kernel-embedded stateful firewall:

• It resides in the kernel of the hypervisor and outside the guest OS of the VM.

• It controls the I/O path to and from the vNIC.

The gateway firewall is used for north-south traffic between the NSX gateways and the physical
network:

• It applies to Tier-0 and Tier-1 gateway uplinks and service interfaces.

• It is a centralized stateful service enforced on the NSX Edge node.

The gateway firewall can be used as perimeter, intertenant, or interzone firewall.

173
6-7 Features of the Distributed Firewall
The distributed firewall provides visibility and control for virtualized workloads and networks.
The distributed firewall has the following main features:

• Centralized configuration through the NSX UI or API

• Layer 2 stateless firewall rules

• Layer 3 stateless and stateful firewall rules

• Context-aware (layer 7) firewall rules

• Identity Firewall for Windows workloads

• FQDN Filtering

• Time-based policies

174
6-8 Distributed Firewall: Key Concepts
Several key concepts apply to distributed firewalls:
• Security policy: A collection of firewall rules and service configurations.

• Firewall rule: A set of instructions that determine whether a packet should be allowed or
blocked.

• Group: A construct with multiple objects statically or dynamically pooled together.

• Service: Defines a port and protocol combination and is used to specify the type of traffic
to be blocked or allowed in firewall rules.

• Context profile: Inspects the layer 7 content of the packets to allow or deny them.

175
6-9 Overview of a Security Policy
A security policy is a collection of firewall rules. You can configure different types of security
policies from the NSX UI.

NSX Manager allows five types

of policies to be configured.

The NSX UI enables you to configure several types of policies:

• Distributed Firewall policies: Used for configuring distributed firewall rules to control east-
west traffic.
• Gateway policies: Used for configuring gateway firewall rules to control north-south traffic.

• Endpoint policies: Used for configuring Guest Introspection services and rules.

• Network Introspection policies: Used for configuring north-south and east-west traffic
redirection rules.

• Distributed IDS/IPS policies: You can use these policies to define Intrusion Detection and
Prevention rules for east-west traffic

176
6-10 Distributed Firewall Policy Categories
A Distributed Firewall policy is a collection of firewall rules applied to east-west traffic.
The NSX UI enables you to group distributed firewall policies into different categories.

L2 FW Policies L3 FW Policies

Temporary Global policies High-level policy Specific and

policies used to that apply to AD, groupings. granular
Quarantine, DNS, NTP, application
Block, or Allow DHCP, backup, policies.
any traffic. and
management

Each category can

have its own
policies and rules.

The categories for distributed firewall rules include:

• Ethernet: All layer 2 policies. Layer 2 firewall rules are always evaluated before layer 3 rules.
• Emergency: Temporary firewall policies needed in emergency situations, such as blocking an
attacker from attacking a web server.
• Infrastructure: Nonapplication policies specific to infrastructure components, such as AD,
DNS, NTP, and so on.
• Environment: High-level policy groupings, for example, the production group cannot
communicate with the testing group or the testing group cannot communicate with the
development group.
• Application: Specific and granular application policy rules, such as rules between applications
or application tiers, or rules between microservices.
— Application tiers - In a multi-tier application, the functionality of the application is
separated into isolated functional areas, called application tiers.
— Microservices - It is an architectural style that structures an application as a collection of
services that are independently deployable
Each of these categories has its own policies and rules. Firewall rules are enforced left to right
and top to bottom across these categories.
You can reorder policies and rules in a specific category. However, you cannot move policies or
rules across different categories.
You can configure policies and rules under relevant categories.
177
6-11 About Distributed Firewall Policies
A firewall policy includes one or more firewall rules, which contain specific instructions for
managing various types of traffic.
A policy can contain stateful or stateless rules for enforcement.

Policies are enforced in a top-to-bottom order.

User-Created
Policy

A User-Created Rule Belonging

to the Policy

In a firewall policy, each firewall rule contains instructions that determine the following factors:

• Source and destination for the packet.

• Whether a packet should be allowed or blocked

• Protocols that the packet can use

• Ports that the packet can use

Policies are used for multitenancy, such as creating specific rules for sales and engineering
departments in separate policies.

A policy can be defined as enforcing stateful or stateless rules. Stateless rules are treated as
traditional stateless access-control lists (ACLs).

178
6-12 Distributed Firewall Rule Processing
within a Policy
Firewall rules are processed in a top-to-bottom order:

• You can move rules up and down within a policy.

• The first match triggers rule enforcement.

• Packets that do not match any other rule are matched by the default rule.

The system default rule for the distributed firewall is

Allow to ensure VM-to-VM communication. You can
change this default behavior.

Firewall rules are enforced in the following ways:

• Like firewall policies, firewall rules are processed in the top-to-bottom order.

• Each packet is checked against the top rule in the rule table before moving down the
subsequent rules in the table.

• The first rule in the table that matches the traffic parameters is enforced. Subsequent rules
cannot be enforced because the search is terminated for that packet.
Because of this behavior, you must place the most granular policies at the top of the rule table.

Packets not matching other rules are enforced by the default rule. The default rule is originally
set to the Allow action. This rule ensures that VM-to-VM communication is not broken during
staging or migration phases. To implement a Zero-Trust model where only the specified traffic is
allowed, the action for the default rule should be changed to block, and firewall policies defined
to specify all traffic to be allowed.

179
6-13 Applied To Field for the Policy
When creating a Distributed Firewall policy, you can define the scope of the policy. It can be the
full DFW or a specific security group.

The Applied To field configured at the policy level overrides the Applied To field configured at
the rules within it. You must configure the Applied To field either at policy level or at the rule
level, but not at both levels. For more granularity, consider configuring the Applied To field at
the rule level.

180
6-14 Configuring Distributed Firewall Policy
Settings
When creating a Distributed Firewall policy, you specify settings such as TCP Strict, Stateful, and
Locked.

TCP Strict: If it is enabled on a section and a packet

matches a rule in it, the packet is dropped if the packet
does not belong to an existing session and the SYN
flag of the packet is not set in the kernel.

Stateful: The distributed firewall performs stateful

packet inspection and tracks the state of network
connections. Packets matching a known active
connection are allowed. Packets that do not match are
inspected against the firewall rules.

Locked: This setting allows you to lock a policy while

making configuration changes so that other users
cannot make simultaneous modifications.

181
6-15 Enable Logging for Distributed Firewall
Policy
When creating a Distributed Firewall policy, you can enable logging for all rules within a policy.

182
6-16 Creating Distributed Firewall Rules
Rules are a set of criteria used to evaluate traffic flows. They contain instructions that determine
whether a packet should be allowed, dropped, or rejected.

Add rules to the

Distributed Firewall policy.

183
6-17 Configuring Distributed Firewall Rule
Parameters
A distributed firewall rule includes parameters such as source, destination, service, and context
profile. This rule defines the scope where the rules should be applied to and the action that
should be taken on a rule match. It also provides an option of logging when the traffic matches a
rule.

The best practice is to use this field to limit

the scope of the policy or rule. This method
User-Created Distributed helps in conserving the resources of the
Firewall Rule ESXi host.

Several parameters can be defined when configuring a distributed firewall rule:

• Name: You can specify a name for the rule.

• Sources: You can use previously defined groups.

• Destinations: You can use previously defined groups.

• Services: You can specify a port and protocol combination.

• Profiles: You use context profiles to define context-aware or layer 7 rules.

• Applied To: Defines the scope of the rule. It can be the full DFW or a specific security
group.

• Action: You can select from the following firewall rule actions:

— Allow

— Drop

— Reject

• ID: NSX manager automatically assigns an id to a rule when it is created. The ID can be used
for troubleshooting. It cannot be modified by the user.
The order of firewall rules determines how the traffic is managed. You can drag the rules in the
UI to change the order.

184
6-18 Specifying Sources and Destinations for a
Rule
When specifying sources and destinations for a firewall rule, you can use an IP or MAC address
or an object (such as a group). If you do not specify these parameters, they match Any.

A group can be used in the source

and destination fields of a firewall
l

Both IPv4 and IPv6 addresses are supported for sources and destinations options of the firewall
rule. Multicast addresses are also supported.

185
6-19 Creating Groups
A group defines a collection of assets on which security policies and rules can be applied.
A group can contain VMs, VIFs, segments, segment ports, IP and MAC addresses, AD user
groups, and physical servers.

Group
Name

Before creating a group that includes AD users, you must add an AD domain to NSX Manager.
You add this domain through the NSX UI by navigating to System > Configuration > Identity
Firewall AD > ADD ACTIVE DIRECTORY.

The main use case for creating a group that includes AD users is to configure identity-based
firewall rules.

186
6-20 Adding Members and Member Criteria for
a Group
Groups can be defined by using dynamic or static membership criteria:

• Dynamic group inclusion for VMs can be based on tags, machine names, OS names, or
computer names.

• Static group inclusion criteria apply to VMs, VIFs, segments, segment ports, IP sets, MAC
sets, AD user groups, physical servers, and nested groups.
Dynamic Group Inclusion Static Group Inclusion

Member selection can be based on

Groups, Segments, Segment Ports,
VIFs, Virtual Machines, and

187
6-21 Specifying Services for a Rule
When configuring distributed firewall rules, you specify one or more services.
Services contain the port and protocol definition for network traffic.

Services can be used in firewall

rules to classify the types of
traffic to block or allow.

Users can define A service classifies traffic based on

new services. the combination of port and
protocol.

NSX includes an extensive list of predefined services. You cannot modify or delete these
services. However, you can create additional services to meet your communication
requirements.

You can create a service while configuring a distributed firewall rule. Alternatively, you can
create additional services by navigating to Inventory > Services > ADD SERVICE.

188
6-22 Adding a Context Profile to a Rule
You can apply a context profile to a distributed firewall rule to enable a layer 7 firewall.

A context profile in the firewall

rule inspects packets based on
L7 application information.

Users can define new context profiles.

NSX Manager includes a list of predefined context profiles. You can also configure custom
context profiles for your firewall rules. Layer 7 firewall rules can be defined only in a stateful
firewall policy.

Alternatively, you can create context profiles by navigating to Inventory > Context Profile >
ADD CONTEXT PROFILE.

189
6-23 Configuring Context Profile Attributes
When creating a context profile for a distributed firewall rule, you configure two attributes:
application ID and domain name.

Set attributes for the

context profile that you
are creating.

Set FQDN-based
attributes, such as Set application-based
microsoft.com. attributes, such as FTP
and SSH.

A context profile defines context-aware attributes, including application ID, domain name, and
subattributes such as application version or cipher set.

Context profiles for distributed firewall rules include the following main attributes:

• APP_ID: You can choose from a list of preconfigured applications. You cannot add
applications. Examples include FTP, SSH, and SSL. Certain applications allow users to
specify subattributes. For example, when choosing SSL Application, you can specify the
TLS_VERSION and the TLS_CIPHER_SUITE. For CIFS, you can specify the
SMB_VERSION.

• DOMAIN_NAME: You can choose from a static list of fully qualified domain names (FQDNs)
or add your own FQDN.

190
6-24 Custom FQDN Filtering
In NSX-T Data Center 3.1, you can add your own fully qualified domain name (FQDN) for custom
filtering.

Enter your own Custom

Domain Name

Alternatively, you can create context profiles by navigating to Inventory > Context Profiles >
FQDNs > ACTIONS > Add FQDN.

191
6-25 Setting the Scope of Rule Enforcement
The Applied To attribute optimizes the resource utilization on the ESXi and KVM hosts. It also
helps in defining targeted policies at specific zones or tenants without affecting the policy
defined on other zones or tenants.

The Applied To attribute defines the

scope of enforcement per rule.

You can apply rules to the

distributed firewall or groups.

The appropriate use of the Applied To field is paramount to optimize resource utilization on the
transport nodes and to avoid scalability issues.

Zones can be compared to departments in an organization, whereas tenants can be compared

to different organizations managed by a service provider. In the NSX UI, you can create groups
to represent zones or tenants.

192
6-26 Specifying the Action for a Rule
You configure the following actions in a distributed firewall rule:
• Allow: Allows all traffic with the specified source, destination, and protocol.

• Drop: Drops packets with the specified source, destination, and protocol. Dropping a packet
is a silent action with no notification to the source and destination systems.

• Reject: Rejects packets with the specified source, destination, and protocol. Rejecting a
packet is a more graceful way to deny a packet, because it sends a destination unreachable
message to the sender.

193
6-27 Distributed Firewall Rule Settings
You configure distributed firewall rules settings, such as logging, direction, and IP protocol.

Logging can be turned off or on. Logs are

stored in the /var/log/dfwpktlogs.log file on
ESXi and KVM hosts.

Matches the direction of a packet

as it traverses the network.

You can configure several settings for distributed firewall rules:

• Logging: You can turn logging off or on. Logs are stored in the
/var/log/dfwpktlogs.log file on ESXi and KVM hosts.
• Direction: This setting matches the direction of traffic from the point of view of the
destination object.

— Considering VM as an object, In means that only traffic to the VM is checked, Out

means that only traffic from the VM is checked, and In-Out, means that traffic in both
directions is checked.

• IP Protocol: IPv4, IPv6, and IPV4-IPv6 protocols are supported.

• Log Label: Log labels can be used to identify a rule when analyzing the log files.

194
6-28 Jump To Application DFW Rules (1)
Jump To Application is a new Action type introduced in NSX-T Data Center 3.1. It has the
following characteristics:
• It is only available in Environment Category.

• It only jumps to Application Category.

The Jump to Application action enables you to do more granular rule processing at the
application level for interapplication and intraapplication communications.
You can create a firewall rule with Jump To Action with the same ease as writing any other
distributed firewall rule.

Identity and application firewall rules can also be configured with Jump To Action in the
environment category.

195
6-29 Jump To Application DFW Rules (2)

The WEB to DB traffic flow is processed as follows:

1. The WEB to DB traffic flow matches the JUMP TO APP rule in the PROD TO PROD policy,
under the Environment category. Such a rule allows the traffic flow to jump from the
Environment category to the Application category.

2. After jumping to the Application category, the WEB to DB traffic flow is checked against all
the rules in the Application category in a top-down order. When the traffic hits the WEB TO
DB rule in the INTRA-APP policy, the traffic flow is dropped based on the action of the
WEB TO DB rule.

196
6-30 Saving and Viewing the Distributed
Firewall Configuration
You can save and view distributed firewall configurations. Every time you publish a distributed
firewall rule, a draft of the configuration is saved automatically.

Viewing the Saved

Configuration

From this view, you can see a timeline with all saved distributed firewall configurations. The
following types of saved items are available:

• Auto-saved: Drafts automatically saved by the system immediately after distributed firewall
changes are published. This feature is enabled by default, but can be disabled if required.
Rolling back to the previous configuration requires reverting to the previously published
autosave.

— You can disable the Auto-saved feature in the NSX UI by navigating to Security >
Distributed Firewall > ACTIONS > General Settings and turn off the Auto Save Drafts
toggle.

• Saved by others: Distributed firewall configurations saved by other users different from the
user currently logged in to the system.

• Saved by me: Distributed firewall configurations saved by the user currently logged in to the
system.

197
6-31 Rolling Back to a Saved Distributed
Firewall Configuration
You can roll back to a previously saved distributed firewall configuration.

By clicking the name of the saved configuration in the histogram, a new wizard appears
displaying the details of the distributed firewall configuration on the top, including name,
description, and creation date. The bottom part of the screen displays the differences between
the saved configuration and the last published configuration.

198
6-32 Distributed Firewall Configuration Import
and Export
In NSX-T Data Center 3.1, you can import and export a distributed firewall configuration

While exporting a firewall configuration, you must provide a passphrase. This passphrase will be
needed while importing this configuration into the firewall. After the export is complete, you can
download the firewall configuration.

While importing a firewall configuration with the passphrase, you must also provide a name for
the configuration that you import into the firewall. All the imports are saved as drafts in the
firewall.

199
6-33 Lab 3: Configuring the NSX Distributed
Firewall
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

200
6-34 Lab 4: Configuring L7 Distributed Firewall
Rules
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

201
6-35 Review of Learner Objectives
• Identify types of firewalls in NSX-T Data Center
• Describe features of distributed firewalls

• Create firewall policies

• Configure firewall rules

• Configure firewall rule attributes: groups, services, and profiles

• Save, roll back, import, and export the distributed firewall configuration

202
6-36 Lesson 2: Distributed Firewall
Architecture and Troubleshooting

6-37 Learner Objectives

• Explain the distributed firewall architecture, components, and communication flow

• Use the UI, the CLI, the API, and the logs to verify the distributed firewall rule provisioning
status from NSX Manager and host transport nodes

• Troubleshoot common distributed firewall issues

203
6-38 Distributed Firewall Architecture
The high-level distributed firewall workflow includes the following steps:
1. Users configure distributed firewall policies through the NSX UI or API.

2. The policy role processes these policies.

3. Distributed firewall policies are then pushed to the manager role and persisted.

4. The manager role forwards the distributed firewall rule configuration to the central control
plane (CCP).

5. The CCP forwards the configuration to the LCP (nsx-proxy) through the Appliance Proxy
Hub (APH).

6. The host transport nodes (ESXi/ KVM) store the distributed firewall configuration and
configure the datapath accordingly.
7. The transport nodes send rule statistics and status to NSX Manager.

204
6-39 Distributed Firewall Architecture: ESXi
On an ESXi host, the distributed firewall includes several components:
1. nsx-proxy receives the configuration changes from the CCP and configures datapath
modules.

2. Datapath modules include the following components:

— VSIP: Receives firewall rules and downloads them on each VM’s vNIC

— VDPI: Performs L7 packet inspection

3. Stats Exporter collects flow records from the distributed firewall data plane kernel modules
and generates rules statistics.

4. nsx-proxy passes rules statistics and real-time data to the management plane.

205
The following datapath modules are responsible for distributed firewall rule processing:

• VMware Internetworking Service Insertion Platform (VSIP): This module is the main part of
the distributed firewall kernel module that receives the firewall rules and downloads them on
each VM’s vNIC.

• VMware Deep Packet Inspection (VDPI): This deep packet inspection module daemon in the
user space is responsible for L7 packet inspection. VDPI can identify application IDs and
extract context for a traffic flow.

L7 rules, like the remaining DFW rules, are programmed into VSIP. VSIP forwards L7 packets to
VDPI, which inspects and extracts the L7 information from the packets and returns them to
VSIP.

Stats Exporter collects flow records from the VSIP kernel module and generates rule statistics.

206
6-40 Distributed Firewall Rule Processing: ESXi
vmware-sfw is a software construct where distributed firewall rules are stored and enforced.
vmware-sfw maintains a rule table and a connection table.

When a distributed firewall rule is configured, its information is stored in the rule table. After the
initial rule configuration, the traffic is managed as follows:

1. A lookup is performed in the connection table to check whether a connection exists.

2. If the connection is not present, the packet is matched against the rule table.

3. If the packet is allowed and the traffic type is stateful, a connection entry is created in the
connection table.

4. All subsequent packets for the same connection are serviced directly from the connection
table. Stateless packets are always matched against the rule table.

The vSphere ESXi network IOChain is a framework that enables you to insert functions into the
network datapath.

207
The IOChain framework is used by NSX to host vmware-sfw, which is a software construct
where distributed firewall rules are stored and enforced.

vmware-sfw maintains the following types of tables:

• Rule Table: Locally stores all applicable firewall rules

• Connection Table: Caches flow entries for stateful rules with an action

208
6-41 Distributed Firewall Architecture: KVM
On a KVM host, the distributed firewall includes several components:
1. nsx-proxy: Receives configuration changes from the CCP and configures datapath modules

2. Datapath modules:

— OVS: Manages stateless rules

— Conntrack: Tracks established connections for stateful rules

— VDPI: Performs L7 packet inspection

3. Stats Exporter: Collects flow records and generates rules statistics

4. nsx-proxy: Passes rules statistics and real-time data to the management plane

The slide shows the distributed firewall architecture on a KVM. The same architecture also
applies to bare-metal servers.

209
The following datapath modules are responsible for distributed firewall rule processing on a
KVM:

• OVS: Core data path component for L2, L3, and distributed firewall. It provides ingress and
egress filtering for stateless rules.

• Conntrack: Module responsible for tracking established connections for stateful firewall
rules.

• VDPI: A deep packet inspection module daemon in the user space that is responsible for L7
packet inspection. VDPI can identify application IDs and extract context for a traffic flow.

210
6-42 Distributed Firewall Rule Processing: KVM
In a KVM environment:
• The distributed firewall rules are programmed into OVS.

• The conntrack module is responsible for tracking established connections for stateful firewall
rules.

When a distributed firewall rule is configured, its information is stored in OVS as a flow. After the
initial configuration, the traffic is managed as follows:

1. A lookup is performed in conntrack to check whether a connection exists.

2. If the connection is not present, the packet is matched against the OVS flow table.

3. If the packet is allowed and the type of traffic is stateful, an entry is created in the
connection table.
4. All subsequent packets for the same connection are serviced directly from the connection
table. Stateless packets are always matched against the OVS flow table.

211
6-43 UI for Distributed Firewall Validation
You can check the Distributed Firewall policies and rules from the NSX UI.

The rule has been successfully

realized in the datapath.
The rule parameters are correct.

The rule is hit.

You can check the Distributed Firewall rules configured from the NSX UI by navigating to
Security > East West Security > Distributed Firewall.

If the rules for a given policy were successfully realized in the data plane, a Success status
appears at the policy level in the NSX UI.

You can check the rule hits statistics. The statistics are aggregated every 15 minutes from all the
transport nodes. You can reset the rule statistics by clicking the vertical ellipsis icon in the NSX
UI.

You can also check the Capacity Dashboard to ensure that the configuration is within the
supported limit of NSX-T Data Center. The Capacity Dashboard can be accessed from the UI by
navigating to Security > Security Overview > Capacity.

212
6-44 Distributed Firewall Validation: ESXi CLI
(1)
Run the command to validate the firewall VIB installation on the ESXi host:

[root@sa-esxi-04:~] esxcli software vib list | grep vsip

vsipfwlib 3.1.0.0.0-7.0.17107169 VMware VMwareCertified 2020-
10-31
Run the command to validate that nsx-proxy is running on the host:

[root@sa-esxi-04:~] /etc/init.d/nsx-proxy status

nsx-proxy agent service is running

Run the command to check the connection between the host and MP/CCP:

[root@sa-esxi-04:~] esxcli network ip connection list | grep

'1234\|1235'
tcp 0 0 172.20.10.53:31558 172.20.10.41:1235 ESTABLISHED
264946 newreno nsx-proxy
tcp 0 0 172.20.10.53:45742 172.20.10.41:1234 ESTABLISHED
264946 newreno nsx-proxy
The VIB for the distributed firewall is called vsipfwlib, and it is installed during the transport node
preparation.

The nsx-proxy agent is the communication point between the transport node and NSX Manager
for both the Management Plane and the Central Control Plane. If nsx-proxy is not running on the
ESXi host, then the connection between the host and CCP is not established and distributed
firewall rules are not realized in the data plane. Also, if the host cannot communicate with the
management plane, rule statistics are not reported back to the manager or displayed in the UI.

If nsx-proxy is running, you can check the connection between the host and MP on port 1234 ,
and the connection between the host and CCP on port 1235. In this example, both connections
are established successfully.

213
The output of the esxcli network ip connection list command provides the
following details:

• The local address of 172.20.10.53 is the management address of the transport node. The
transport node uses different source ports to connect to NSX Manager.

• The foreign or remote address of 172.20.10.41 is the IP address of NSX Manager. Port 1234
is used to connect to MP. Port 1235 is used for CCP connections.
• The state of the connection is ESTABLISHED.

214
6-45 Distributed Firewall Validation: ESXi CLI
(2)
Run the summarize-dvfilter command to retrieve the distributed firewall filters for a VM
running on an ESXi host.

In vSphere environments, vmware-sfw is a software construct where distributed firewall rules

are stored and enforced.

On an ESXi host, the summarize-dvfilter command can be used to retrieve the name of
vmware-sfw associated with the vNIC of a VM.

215
6-46 Distributed Firewall Validation: ESXi CLI
(3)
Run the vsipioctl commands to query the firewall rules applied to the vNIC of a virtual
machine.

dvFilter

In the example, the vmware-sfw name for VM web-01 is nic-266312-eth0-vmware-sfw.2. You

can use this identifier to query the rules associated with the vNIC of this VM.

Run the vsipioctl getrules -f command and the name of the filter you retrieved with
the previous command to query the rules associated with the vNIC of a VM. In the example, you
can see that the rules attached to VM web-01 match those configured from the NSX UI. The
command output also includes a timestamp with the realization time, which can be helpful for
further log analysis.

Run the vsipioctl getaddrsets -f command and the name of the filter to query the
addrsets referenced in the output from the rule definition.

The source and the destination fields in a firewall rule have an associated addrset represented
with a UUID. Each UUID has a mapping with the IP addresses and MAC addresses of the source
and the destination workloads as per the firewall rule definition.

You can use the vsipioctl getfwconfig -f command to obtain both rules and the
addrsets associated with the vNIC of a VM.

216
6-47 Distributed Firewall Validation: KVM CLI
In KVM environments, the ovs-appctl -t /var/run/openvswitch/nsxa-ctl
dfw/vif command can be used to retrieve the virtual interface identifier associated with a
vNIC.

Run the command to retrieve the distributed firewall rules realized in the vNIC of a virtual
machine:

VIF ID

In KVM environments, the ovs-appctl -t /var/run/openvswitch/nsxa-ctl

dfw/vif command can be used to retrieve the virtual interface identifier associated with a
particular vNIC. The Vif ID is required to obtain the associated distributed firewall rules.

The ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/rules

command, with the Vif ID obtained in the previous steps as a parameter, can be used to
retrieve its associated distributed firewall rules.

The ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/addrsets

command, with the ID of the addrset specified as a parameter can be used to resolve the
addrsets from the rules command output.

217
6-48 Distributed Firewall Validation: NSX CLI
(1)
You can verify the distributed firewall in the NSX CLI by using the get firewall status
and get firewall summary commands.

The get firewall published-entity command shows the rules published to CCP.

To ascertain the names of the firewall rules, search for the entity_id that is returned by the get
firewall published-entity command in the NSX UI Search bar.

218
6-49 Distributed Firewall Validation: NSX CLI
(2)
Administrators who are unable to access the transport nodes directly can obtain the rules and
addresses through the NSX CLI.
1
2
1

In the example, you perform steps 1 to 3 on the NSX CLI to obtain the rules and addresses.

219
6-50 Retrieving the Absolute Path for a
Firewall Policy and a Rule
Before validating the rule realization from the API, you retrieve the absolute path for distributed
firewall policies and rules from the NSX UI.

Distributed Firewall policies and rules are identified by their absolute path. You can
retrieve the identifiers from the NSX UI by selecting Copy path to clipboard.

To retrieve the API information for a distributed firewall or policy, you must obtain its absolute
path. Click the vertical ellipsis icon next to each rule or policy to copy the path to the clipboard in
the UI.

For example, the Allow Web Traffic rule allows HTTP traffic from the Web-VMs to the App-
VMs. The id for this rule is /infra/domains/default/security-policies/3-
TIER_POLICY/rules/Allow_Web_Traffic. The id for this rule's policy is
/infra/domains/default/security-policies/3-TIER_POLICY.

220
6-51 Distributed Firewall Rule Validation: API
You can verify the realization of a distributed firewall rule by using an API call:
GET https://NSX_IP/policy/api/v1/infra/realized-
state/realized-entities?intent_path=RULE_ABSOLUTE_PATH

The following API call provides details about how the distributed firewall rule was realized:

https://NSX_IP/policy/api/v1/infra/realized-state/realized-
entities?intent_path=RULE_ABSOLUTE_PATH
You obtained the RULE_ABSOLUTE_PATH object identifier from the UI.

The output of this API call provides additional details about how the distributed firewall rule was
realized in the Management Plane and the Data Plane. The mapping appears between the rule
identifier in NSX Policy, which is /infra/domains/default/security-
policies/3-TIER_POLICY/rules/Allow_Web_Traffic. The identifier in NSX
Manager (realization_specific_identifier) appears, which in this example is
3053. You can find this identifier in the NSX UI by changing to the Manager tab. You can also
see how the state is REALIZED and the runtime_status is SUCCESS. The state
refers to the successful realization in the management plane, whereas the runtime_status
refers to the successful configuration in the data plane.

221
6-52 Distributed Firewall Log Files
Several log files are useful for troubleshooting distributed firewall rules.

You can use the dfw keyword or the rule identifier to filter the nsx-syslog logs at the datapath.

222
6-53 Distributed Firewall Troubleshooting
Flowchart
Use these steps to troubleshoot distributed firewall.

For information about the configuration maximums for Distributed Firewall, see VMware
Configuration Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=19-34.

You can also check configuration maximums directly in the NSX UI by navigating to Security >
Security Overview > Capacity.

223
6-54 Troubleshooting Scenario 1: Problem
Description
Recently, a team member modified the configuration of the distributed firewall. After making
changes, a HTTP connection cannot be established from sa-app-01 to sa-db-01.

224
6-55 Troubleshooting Scenario 1: Root Cause
The firewall rule was configured with the wrong values in the Applied To field.

The source and destination VMs are part of the

App-Servers and DB-Servers group, respectively.

225
6-56 Troubleshooting Scenario 1: Solution
To resolve the issue, change the value in the Applied To field to App-Servers and DB-Servers.

226
6-57 Troubleshooting Scenario 2: Problem
Description
Recently, a team member created a custom SSH profile and configured a firewall rule to allow
SSH sessions from sa-app-01 to sa-db-01.

After making changes, an SSH session cannot be established from sa-app-01 to sa-db-01.

227
6-58 Troubleshooting Scenario 2: Root Cause
The Custom SSH profile and its attributes do not match in the context profile.

The attribute for the Custom

SSH profile was set to accept
SSL traffic instead of SSH.

228
6-59 Troubleshooting Scenario 2: Solution
To resolve the problem, you must either use the default SSH profile or modify the Custom SSH
profile to allow the SSH application instead of SSL.

You must specify both the L4 service and the L7 context profile for a distributed firewall rule to
reduce the attack surface. You are explicitly allowing an L7 application to run on the specific L4
port.

229
6-60 Lab 5: Troubleshooting the NSX
Distributed Firewall
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

230
6-61 Review of Learner Objectives
• Explain the distributed firewall architecture, components, and communication flow
• Use the UI, the CLI, the API, and the logs to verify the distributed firewall rule provisioning
status from NSX Manager and host transport nodes

• Troubleshoot common distributed firewall issues

231
6-62 Lesson 3: Time-Based Firewall Rules

6-63 Learner Objectives

• Explain time-based firewall rules and their use cases

• Identify requirements for time-based firewall rules

• Describe the architecture for time-based firewall rules

• Configure time-based firewall rules and perform basic troubleshooting

232
6-64 About Time-Based Firewall Rules
You can use time-based firewall rules to configure security rules that are only valid for a specific
period.
Time-based firewall rules include the following features:

• They are available for distributed and gateway firewalls.

• They are configured at the firewall policy level and apply to all the rules in it.

• Both recurring and once-off firewall rules can be configured.

233
6-65 Use Cases for Time-Based Firewall Rules
Time-based firewall rules are used to:
• Allow Internet access to users only during a specific time of the day.

• Allow access to specific services only during maintenance or backup windows.

• Allow access to external services only during burst periods.

234
6-66 Requirements for Time-Based Firewall
Rules (1)
Time-based firewall rules require NTP to be configured on each transport node.

Run the command to verify that the NTP service runs on an ESXi host:

/etc/init.d/ntpd status
Run the command to verify that the NTP service runs on a KVM host:

/etc/init.d/ntp status

235
6-67 Requirements for Time-Based Firewall
Rules (2)
The local NTP client must successfully communicate with the configured NTP server.

To verify the NTP associations on ESXi and KVM hosts, run the ntpq -p command.

[root@sa-esxi-04:~] ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================
==
*ntp3-sjc31.vmwa 10.188.26.21 3 u 87 1024 377 31.274 0.471
0.187
The transport nodes must be configured with an external NTP server for time-based firewall
rules to work. Local NTP servers cannot be used when configuring time-based firewall rules.

For information about troubleshooting NTP problems, see VMware knowledge base article
1005092 at https://kb.vmware.com/s/article/1005092.

In the output of the ntpq -p command, the * symbol indicates that this server was
successfully selected for synchronization.

236
6-68 ESXi Packet Walkthrough
When using time-based distributed firewall rules in an ESXi host:
1. A rule is considered active or inactive based purely on time. If the rule is active, the general
distributed firewall flow is applied.

2. A lookup is performed in the connection table to check if a connection exists.

3. If the connection is not present, the packet is matched against the rule table.

4. If the traffic is stateful, a connection entry is created in the connection table.

5. All subsequent packets for the same connection are serviced directly from the connection
table.

237
6-69 KVM Packet Walkthrough
When using time-based distributed firewall rules in a KVM host:
1. A rule is considered active or inactive based purely on time. If the rule is active, the general
distributed firewall flow is applied.

2. A lookup is performed in conntrack to check whether a connection exists.

3. If the connection is not present, the packet is matched against the OVS flow table.

4. If the packet is allowed and the type of traffic is stateful, an entry is created in the
connection table.

5. All subsequent packets for the same connection are serviced directly from the connection
table. Stateless packets are always matched against the OVS flow table.

238
6-70 Configuring Time-Based Distributed
Firewall Rules
To configure time-based distributed firewall rules:

1. Navigate to Security > East West Security > Distributed Firewall > CATEGORY SPECIFIC
RULES.

2. Select the appropriate policy and click the Set Time Window icon.

Although the time window is associated to the security policy from the NSX UI, the time window
is applied to all the firewall rules within it at the datapath.

239
6-71 Configuring Time Windows
You configure the following parameters in Time Window:
• Name

• Time zone (UTC or local to transport node)

• Frequency (weekly or one time)

• Recurring days

• Start and end date

• Start and end time

The From and Till parameters must be configured in 30-minute increments. For example, from
04:30 to 05:00 is a valid configuration. However, if a user configures an interval from 04:15 to
04:45, a configuration error appears in the UI.

240
6-72 About Time Windows
A Time Window has the following properties:
• You can associate a time window with both distributed and gateway policies.

• You can use a time window in multiple firewall policies.

• You can configure a firewall policy with only one time window.

241
6-73 UI Validation
The image illustrates a successful firewall policy realization example.

If the NTP service is not running for a transport node, a realization error occurs.

242
An error with code 1001 appears in the UI during the configuration of a time-based firewall rule in
the following scenarios:

• The NTP service is down.

• Connectivity does not exist between the local NTP client and the configured NTP server.

243
6-74 CLI Validation on ESXi Hosts (1)
To retrieve the name of vmware-sfw for a VM, run the command:
summarize-dvfilter | grep -A8 <VM_name>

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

world 266312 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-266312-eth0-vmware-sfw.2
agentName: vmware-sfw
...
In vSphere environments, vmware-sfw is a software construct where distributed firewall rules
are stored and enforced. In ESXi, the summarize-dvfilter command is used to retrieve
the name of vmware-sfw associated with the vNIC of a particular VM. In the example, you
retrieve the vmware-sfw name for the sa-web-01 virtual machine. You use this identifier to query
the rules associated with the vNIC of this VM.

244
6-75 CLI Validation on ESXi Hosts (2)
To retrieve the firewall rules for a given vmware-sfw identifier, run the command:

To retrieve the firewall schedulers for a given vmware-sfw identifier, run the command:

The output of the vsipioctl getrules command shows the rules attached to the sa-
web-01 virtual machine. The firewall rule configured to reject traffic on port 8443 (TCP) has a
time-attributed profile associated with it.

The output of the vsipioctl getcontainers command shows the schedulers attached
to the sa-web-01 virtual machine. The container identifier matches the one in the previous
command. Also, the output of this command provides the configuration details for the scheduler,
such as its start and end time and date.

245
6-76 CLI Validation on KVM Hosts (1)
To retrieve the Vif ID for a VM, run the command:
ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/vif

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 : 2
In KVM, the ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/vif
command is used to retrieve the Vif ID associated with the vNIC of a particular VM. In the
example, you retrieve the Vif ID, which is 57601300-2e82-48c4-8c27-
1e961ac70e81, for the sa-web-02 virtual machine. You use this identifier to query the rules
associated with the vNIC of this VM.

246
6-77 CLI Validation on KVM Hosts (2)
To retrieve the firewall rules for a given Vif ID, run the command:
ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/rules <Vif ID>

ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/rules

57601300-2e82-48c4-8c27-1e961ac70e81
Vif ID: 57601300-2e82-48c4-8c27-1e961ac70e81
ruleset cfd87959-aa66-4a39-9201-425dd065e62c {
rule 3059 inout protocol tcp from addrset d2aec960-a0be-47be-
85b9-c5c5b7ed6dcc to addrset 3864b996-0fad-4472-9b38-
d108f9495555 port 8443 reject;
}
...

To retrieve the schedulers configured on the KVM host, run the command:

ovs-appctl -t /var/run/openvswitch/nsxa-ctl
dfw/DfwSchedulerRules

ovs-appctl -t /var/run/openvswitch/nsxa-ctl
dfw/DfwSchedulerRules
Section: cfd87959-aa66-4a39-9201-425dd065e62c (Sched: 0 )
Rule: 3059 (ON)
...
The output of the ovs-appctl -t /var/run/openvswitch/nsxa-ctl
dfw/rules <Vif ID> command shows the rules attached to the sa-web-02 virtual
machine. In the example, the firewall rule with ID 3059 is configured to reject traffic on port
8443 (TCP).

The output of the ovs-appctl -t /var/run/openvswitch/nsxa-ctl

dfw/DfwSchedulerRules command shows that the rule with ID 3059 is ON. In the
example, the scheduler ID is 0 and the rule state is ON because the current time is within the
configured time window. When the current time is not within the configured time window, a
scheduler ID associated with the rule appears, and the rule appears as OFF.

247
6-78 API Validation
Use the following API call to retrieve the firewall schedulers:
GET https://<nsxmgr>/policy/api/v1/infra/firewall-schedulers/
{
"results" : [ {
"start_time" : "06:30",
"end_time" : "07:00",
"start_date" : "02/18/2021",
"end_date" : "02/18/2021",
"timezone" : "UTC",
"recurring" : false,
"resource_type" : "PolicyFirewallScheduler",
"id" : "App_Maintenance",
"display_name" : "App Maintenance",
"description" : "App Upgrade to version 3",
"path" : "/infra/firewall-schedulers/App_Maintenance",
...
} ],
...
}
This API call returns a list of all time windows configured in the NSX environment, including their
settings.

248
6-79 Useful Log Files
Several log files are useful for troubleshooting time-based firewall rules.

You can use the dfw keyword or the rule identifier to filter the logs on one the ESXi and KVM
hosts.

249
6-80 Relevant Log Events
ESXi:
• /var/log/nsx-syslog.log
...
2021-02-18T14:50:50Z cfgAgent[264874]: NSX 264874 -
[nsx@6876 comp="nsx-controller" subcomp="cfgAgent"
tid="9C0F3700" level="info"] dfw: Update runtime status to
nestdb (error, meta info): 1001, NTP Service is not up
KVM:

• /var/log/vmware/nsx-syslog
...
2021-02-18T15:13:58.710479Z sa-kvm-01 NSX 3331 - [nsx@6876
comp="nsx-kvm" subcomp="nsx-agent"] StartDfwNtpThread:
IsNTPInSync returned false
The slide shows examples of the error messages displayed in the ESXi and KVM hosts when
time-based firewall rule realization errors occur.

You can look for the 1001 error code on the ESXi hosts and the IsNTPInSync keyword on
the KVM hosts. On the ESXi and KVM hosts you can filter the logs using the dfw keyword.

250
6-81 Time-Based Firewall Troubleshooting
Flowchart
Use these steps to troubleshoot Time-Based Firewall.

251
6-82 Lab 6: Configuring Time-Based Firewall
Rules
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

252
6-83 Review of Learner Objectives
• Explain time-based firewall rules and their use cases
• Identify requirements for time-based firewall rules

• Describe the architecture for time-based firewall rules

• Configure time-based firewall rules and perform basic troubleshooting

253
6-84 Lesson 4: Identity Firewall

6-85 Learner Objectives

• Explain Identity Firewall and its use cases

• Identity requirements for Identity Firewall

• Describe the architecture and components of Identity Firewall

• Configure Identity Firewall and perform basic troubleshooting

254
6-86 About the NSX Identity Firewall
The NSX Identity Firewall (IDFW) allows or denies access to applications based on user-based
distributed firewall rules.

The NSX Identity Firewall requires setting up Active Directory synchronization so that the NSX-
T Data Center environment can consume AD users and groups.

255
6-87 Use Cases for Identity Firewall
Identity Firewall can be used for Virtual Desktops or Remote Desktop Session Host.

Identity Firewall can be used for Virtual Desktops (VDI) or Remote Desktop Session (RDSH),
enabling simultaneous logins by multiple users, user application access based on requirements,
and the ability to maintain independent user environments.

VDI management systems control what applications users are granted access to when using VDI
virtual machines. NSX-T Data Center controls access to the destination servers from the source
VDI machines, which have IDFW enabled.

With RDSH, administrators create security groups with different users in Active Directory (AD),
and allow or deny those users access to an application server based on their role. For example,
Human Resources and Engineering can connect to the same RDSH server, and have access to
different applications from that server.

256
6-88 Requirements for Identity Firewall (1)
Identity Firewall has the following requirements:
• Active Directory must be integrated with NSX Manager.

• The ESXi hosts must be prepared for NSX-T Data Center.

• IDFW must be enabled at the vSphere cluster level or on standalone ESXi hosts.

• IDFW is supported only on Windows operating systems.

• IDFW is supported only on virtual workloads.

Identity Firewall only supports Microsoft Active Directory at present, including the following
versions:

• Windows Server 2012

• Windows Server 2012R2

• Windows Server 2016

• Windows Server 2019

IDFW is only supported on Windows operating systems running on virtual machines. Physical
servers are not supported at present. For a complete list of the Windows versions supported
for both desktop and RDSH enforcement, see NSX-T Data Center Administration Guide at
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-
9CD3FC21-9ED4-4FB3-9E19-67A7C4D1F53E.html#GUID-9CD3FC21-9ED4-4FB3-9E19-
67A7C4D1F53E.

257
6-89 Requirements for Identity Firewall (2)
For Identity Firewall to work, a Thin Agent must be installed on the guest operating system. This
Thin Agent is installed as part of VMware Tools and includes the following drivers:
• NSX Network Introspection (vnetWFP.sys)

• NSX File Introspection (vsepflt.sys)

• VMCI (vsock.sys)

Identity Firewall requires VMware Tools version 11.

NSX Network Introspection

NSX File Introspection Driver

VMCI Socket

The VMware tools full installation mode adds these three drivers by default.

All drivers can be found in the C:\Windows\system32\drivers folder.

Identity Firewall requires a version of VMware Tools that is compatible with NSX-T Data Center.
For information, see VMware Product Interoperability Matrix at
https://interopmatrix.vmware.com/#/Interoperability?isHideGenSupported=true&isHideTechSu
pported=true&isHideCompatible=false&isHideIncompatible=false&isHideNTCompatible=false&is
HideNotSupported=true&isCollection=false&col=175,4926,4090,5371,4729,4198,3413,5316,423
2,3787,3394,3777,3645,3451,2852,3216,2714,2595,2526,2176,1689&row=139,5100,4778,4751,3
987,3808,3343,4779,4074,3668,3206,2963,2800,2698,2319,2514,2321,2308,962,1705,1082,10
60,982,925,918,915,432,891,747,579,509,797,605,443,374,512,394,307,204,384,205,203,202,
330,206,201,200,207,199,208.

258
6-90 Identity Firewall Components
The architecture of the Identity Firewall includes the following components:
• Active Directory: Provides the Active Directory Groups for building IDFW rulesets.

• NSX-proxy: Receives configuration from NSX Manager and configures the data plane.

• VSIP: Enforces Identity Firewall rules on the datapath.

• Thin Agent: Collects login events, connection, and identity information from the Guest VM.

• Context Mux: Acts as a proxy for communication between the Guest VM and the ESXi host.
Receives events from the Thin Agent and forwards them to the datapath.

• Context Engine: Forwards VM events to the VSIP module for rule enforcement.

259
6-91 Identity Firewall Configuration Workflow
The Identity Firewall is configured as follows:
1. The user enables IDFW and configures an identity firewall rule from the NSX UI.

2. The policy role processes the identity firewall rule and passes it to the manager role.

3. The manager role performs SID translation for the AD Groups and passes the configuration
to the CCP.

4. The CCP distributes the IDFW configuration to the ESXi hosts through APH.

5. The host transport node receives the IDFW configuration through NSX-proxy and
configures the VSIP and the Context Engine accordingly.

6. The Context Engine enables Guest VM traffic monitoring using the Context Mux and the
Thin Agent.

A security identifier (SID) is a unique value used to identify security groups in Windows
operating systems. The SID value for a given security group remains constant across all
operating systems.

The identity firewall rules are stored in the datapath using the SID of a group instead of its name.
NSX Manager is responsible for translating the name of security groups into SIDs before passing
the configuration information to the Central Control Plane (CCP).

260
6-92 Identity Firewall Enforcement Workflow
Identity firewall rules are enforced as follows:
1. User logs into the guest VM.

2. User starts a network connection.

3. The Thin Agent detects the connection. It then gathers connection and identity information
and sends it to the Context Mux.

4. The Context Mux receives the guest VM events and forwards them to the Context Engine.

5. The Context Engine forwards the connection and the identity information to the VSIP
module for rule enforcement.

6. For the first connection, a login event is sent to the MP through the NSX-proxy.

7. The Management Plane tracks the login information to produce and display runtime data.

261
6-93 Enabling Identity Firewall
Before creating Identity Firewall policies and rules, you must enable Identity Firewall for the
environment.

Turn on the Identity Select the clusters

Firewall Status where you want to
toggle. enable Identity
Firewall.

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

Distributed firewall must also be enabled for Identity Firewall to work.

To enable Identity Firewall on standalone hosts or clusters, select the Identity Firewall Settings
tab.

262
6-94 Adding an Active Directory Domain to
NSX
You need to add an Active Directory domain to NSX-T Data Center so that the environment
can consume AD users and groups.

From the NSX UI, navigate to System > Configuration > Identity Firewall AD > ACTIVE
DIRECTORY to add an active directory domain.

You can register an entire Active Directory domain, or you can synchronize a subset of a large
domain. After a domain is registered, NSX synchronizes all Active Directory data required by
Identity Firewall.

After it is configured, you can click View Sync Status to see the current state of the Active
Directory, the previous synchronization state, the synchronization status, and the last
synchronization time.

263
6-95 Creating Active Directory Groups
Using Active Directory objects, you create security groups for use in Identity Firewall rules.

264
6-96 Configuring Identity Firewall Rules
You create Identity Firewall rules by configuring AD-based security groups as the source field.

In the example, a rule has been created to prevent

users in the Developers Active Directory group from
opening SSH sessions to Windows VMs.

You use the Developers Active Directory Group as the source.

The Applied To field should be an NSX Group containing any machine where the IDFW is
needed and the user can log in to access a given destination.

265
6-97 Validating Identity Firewall Rules from the
NSX UI
You can validate the Identity Firewall policies and rules from the NSX UI.

The rule has been successfully

realized in the datapath.
The rule parameters are correct.

The rule is hit.

You can check the Identity Firewall rules configured from the NSX UI by navigating to Security >
East West Security > Distributed Firewall.
If the rules for a given policy have been successfully realized in the data plane, you see a
Success status at the policy level in the NSX UI.

You can check the rule hits statistics. The statistics are aggregated every 15 minutes from all the
transport nodes. You can reset the rule statistics from the three dots menu icon in the NSX UI.

You can also check the Capacity Dashboard to ensure that configuration is within the supported
limit for NSX-T Data Center. The Capacity Dashboard can be accessed from the UI under
Security > Security Overview > Capacity.

266
6-98 Validating Identity Firewall Rules from the
ESXi CLI
You also validate the Identity Firewall rule from the CLI. First, you retrieve the name of the
dvfilter associated with a VM vNic.

dvfilter name

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.

The vsipioctl getfwconfig -f <dvfilter-name> command displays the rules

attached to the dvfilter of the VM, as well, as additional configuration details. An Identity Firewall
rule with ID 3064 is available. The rule 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 d5b3231f-59eb-4762-a65c-91ca0711195d corresponds to the Windows
security identifier (SID) of S-1-5-21-826080028-694968213-2415077811-45603.

267
6-99 Validating Identity Firewall Configuration
from the API
You verify the realization of Identity Firewall rules by using the following API call:

GET https://NSX_IP/policy/api/v1/infra/realized-
state/realized-entities?intent_path=RULE_ABSOLUTE_PATH
You use the following REST API call to list all configured Active Directory domains:

GET https://NSX_IP/policy/api/v1/directory domains

Active Directory Domain

LDAP Server

The API call and procedure to retrieve the status of an Identity Firewall rule is the same as a
distributed firewall rule.

268
6-100 Log Files for Troubleshooting Identity
Firewall
The table includes useful log files and locations.

Component Log Location

NSX Management Cluster nsxcli get log-file policy

nsxcli get log-file manager
nsxcli get log-file controller

Thin Agent (Guest VM) vmware.log

Context MUX (ESXi) /var/log/syslog

Rule Enforcement (ESXi) /var/log/nsx-syslog.log

/var/log/dfwpktlogs.log

269
6-101 Lab 7: Configuring Identity Firewall Rules
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

270
6-102 Review of Learner Objectives
• Explain Identity Firewall and its use cases
• Identity requirements for Identity Firewall

• Describe the architecture and components of Identity Firewall

• Configure Identity Firewall and perform basic troubleshooting

271
6-103 Key Points
• The distributed firewall is a hypervisor, kernel-embedded stateful firewall.
• A security policy is a collection of firewall rules.

• Firewall rules are processed in a top-to-bottom order.

• From the NSX UI, you can check the rule parameters, the rule statistics, and if the rule was
successfully realized in the datapath.

• Time-based firewall features enable you to write rules which are valid for a specific period.

• Time-based firewall rules are configured at the firewall policy level and apply to all the rules
in it.

• Identity Firewalls filter the traffic based on the identity of the user.

Questions?

272
273
Module 7
Gateway Security

7-2 Importance
NSX-T Data Center includes a gateway firewall to protect the north-south traffic. The URL
analysis feature inspects the north-south traffic and monitors the access to external websites.
Using and understanding the gateway firewall and its features contribute to secure your
environment.

7-3 Module Lessons

1. Configuring the Gateway Firewall

2. Gateway Firewall Architecture and Troubleshooting

3. URL Analysis

275
7-4 Lesson 1: Configuring the Gateway
Firewall

7-5 Learner Objectives

• Describe the functions of the gateway firewall

• Explain the purpose of a gateway policy

• Create gateway firewall policies and rules

276
7-6 About the Gateway Firewall
The gateway firewall has the following characteristics:
• A stateful and stateless firewall for north-south traffic

• Independent of the distributed firewall

• Implemented on both Tier-0 and Tier-1 and requiring the SR component of the router

• Enforced on the northbound-facing interface of the gateway

The NSX-T Data Center gateway firewall provides essential perimeter firewall protection that
can be used in addition to a physical perimeter firewall. The gateway firewall supports stateless
and stateful firewall rules.

277
The gateway firewall works independent of the distributed firewall. A user can consume the
gateway firewall using either the UI or REST API framework provided by NSX Manager. The
gateway firewall configuration is similar to the distributed firewall policy. This configuration is
defined as a set of individual rules in a policy. Like the distributed firewall, the gateway firewall
rules can use tagging and groups to build policies.

The gateway firewall is a centralized firewall implemented on the northbound-facing interface of

the gateway (Tier-0 uplinks and Tier-1 RouterLinks). The firewall is implemented on a Tier-0 or
Tier-1 service router (SR) component that is hosted on the NSX Edge Node.

The service router component of a Tier-0 or Tier-1 gateway provides north-south routing
functionality and centralized services, such as NAT, load balancing, and so on.

The Tier-0 gateway firewall supports stateful firewall filtering only with active-standby high
availability mode. The active-active mode supports only stateless rules.

The gateway firewall service is part of the NSX Edge node for both bare-metal and VM form
factors. The gateway firewall is useful in developing PCI zones, multitenant environments, or
DevOps-style connectivity without forcing the intertenant or interzone traffic onto the physical
network. The gateway firewall datapath uses the Data Plane Development Kit (DPDK)
framework supported on NSX Edge to provide better throughput.

278
7-7 Predefined Gateway Firewall Categories
The gateway firewall includes predefined categories under the ALL SHARED RULES tab, where
rules across all gateways are visible.

Predefined Gateway Firewall Categories

Emergency rules are always Each category can have its own rules
evaluated first. and policies.

The gateway firewall includes several predefined categories for rules.

• Emergency: Used for quarantine and can also be used for Allow rules.

• System: Automatically generated by NSX-T Data Center and specific to internal control
plane traffic, such as BFD rules, VPN rules, and so on.

• Pre Rules: Globally applied across all NSX gateway nodes.

• Local Gateway: Rules specific to a particular NSX gateway node.

• Auto Service Rules: Autoplumbed rules applied to the data plane.

• Default: Rules that define the default gateway firewall behavior.

Categories are evaluated from left to right. Each category can have its own rules, which are
evaluated top to bottom.

279
7-8 Gateway Firewall Policy
A Gateway Firewall policy includes one or more individual firewall rules and is applied to north-
south traffic.
Gateway policies can be applied to Tier-0 and Tier-1 gateways and their interfaces.

Select the Tier-0 or Tier-1 gateway that the

Gateway Firewall policy applies to.

A default gateway policy exists to allow

all traffic.

280
7-9 Configuring Gateway Firewall Policy
Settings
To create a Gateway Firewall policy, you assign a policy name and configure the settings. You
can also set a Time Window so that the policy is only applicable during the specified period.

You can specify a Time Window for

Drops packets that are not preceded by a

complete three-way TCP handshake. Works
only with a default ANY-ANY block rule
configured.

Performs stateful packet inspection and tracks

the state of network connection.

Prevents simultaneous firewall configuration

changes by multiple users.

To create a Gateway Firewall policy, you assign a policy name.

You can configure the following settings when creating a Gateway Firewall policy:

• TCP Strict: In certain circumstances, the firewall might not see the TCP three-way
handshake for a particular flow (that is, due to asymmetric traffic). By default, the firewall
does not enforce the need to see a three-way handshake and will pick up sessions that are
already established. TCP Strict can be enabled per section to turn off midsession pickup.
When enabling the TCP Strict mode for a particular firewall policy and using a default ANY-
ANY Block rule, packets that do not complete the three-way handshake connection
requirements and that match a TCP-based rule in this policy section are dropped.

• Stateful: When this option is enabled, the gateway firewall performs stateful packet
inspection and tracks the state of network connections. Packets matching a known active
connection are allowed by the firewall, and packets that do not match are inspected against
the gateway firewall rules.

• Locked: This setting allows you to lock a policy while making configuration changes so that
others cannot make modifications at the same time.

You can also set a Time Window so that the policy is only applicable during the specified period.
For this feature, the NSX Edge nodes need to have an NTP server configured.

281
7-10 Configuring Gateway Firewall Rules
You create one or more rules in the policy to allow, drop, or reject traffic.

Gateway firewall rules are

enforced top to bottom.

Add rules to the Gateway

Firewall policy.

Context Profile is only available on Tier-1 gateways.

282
7-11 Configuring Gateway Firewall Rules
Settings
You can specify the logging, direction, and IP protocol for the gateway firewall rule. A firewall
rule must be published for it to take effect.

Publish the rule when the

configuration is complete.

The rules are logged in the Syslog file of the edge node.

You can access these logs using one of the following ways:

• In root mode: /var/log/syslog

• With the CLI: get log-file syslog

In the rule settings, you can also choose the direction and the IP protocol:

• In: The rule only checks traffic to the gateway interface.

• Out: The rule only checks traffic from the gateway interface.

• In-Out: The rule checks traffic from both directions.

283
7-12 Lab 8: Configuring the NSX Gateway
Firewall
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

284
7-13 Review of Learner Objectives
• Describe the functions of the gateway firewall
• Explain the purpose of a gateway policy

• Create gateway firewall policies and rules

285
7-14 Lesson 2: Gateway Firewall Architecture
and Troubleshooting

7-15 Learner Objectives

• Describe the gateway firewall architecture

• Use the UI, the CLI, the API, and the logs to validate and troubleshoot the gateway firewall
configurations

• Troubleshoot common gateway firewall problems

286
7-16 Gateway Firewall Architecture
The gateway firewall workflow is as follows:
1. Users configure gateway policies from the NSX UI.

2. The policy role processes gateway policies.

3. Gateway policies are sent to NSX Manager, which validates and forwards them to the CCP.

4. The CCP distributes the firewall configuration through APH to the relevant edge nodes.

5. nsx-proxy receives the firewall configuration from the CCP and configures the edge data
path.

6. The Stats Exporter collects flow records from the datapath and generates rule statistics.

7. nsx-proxy reports the firewall rules statistics and status to the management plane.

287
7-17 Gateway Firewall Rule Processing
On an NSX Edge node:
• Gateway Firewall rules are programmed into rule classifier.

• The flow table tracks established connections for stateful firewall rules.

When a Gateway Firewall rule is configured, its information is stored in a rule table in the Rule
Classifier module. After the initial rule configuration, the traffic is managed as follows:

1. A lookup is performed in the flow table to check whether a connection exists.

2. If the connection is not present, the packet is matched against the rule table in Rule
Classifier.

3. If the type of traffic is stateful, an entry is created in the flow table.

4. All subsequent packets for the same connection are serviced directly from the flow table.
Stateless packets are always matched against the rule table.

288
The Rule Classifier maintains stateful and stateless rules for the following features:

• Gateway Firewall

• NAT

• Load Balancing

• IPSec

• Service Insertion

The Flow Table is responsible for tracking established connections for stateful firewall rules,
NAT, and load balancing edge services. When a new connection is made, the first packet is
matched against the flow table to determine if a session exists.
A rule classifier and flow table are created for each gateway. If two gateways are present in the
NSX Edge node, two rule classifier instances and flow tables are created: one for each gateway.

289
7-18 Gateway Firewall Validation: UI
You can check the configured Gateway Firewall policies and rules from the NSX UI by navigating
to Security > North South Security > Gateway Firewall.
The rule was successfully
realized in the datapath.
The rule parameters are
correct.

Packets match the rule.

Use the NSX UI to verify the configuration:

• Gateway Firewall is enabled for the given gateway.

• The realization state for a given gateway firewall policy should be successful.

• Rule statistics indicate that traffic is matching the firewall rule.

You can enable logging for the rule for troubleshooting the policy.

290
7-19 Gateway Firewall Validation: CLI
You can use these CLI commands to query the NSX Edge node interfaces that have Gateway
Firewall rules configured, as well as the firewall rules associated with a particular interface.

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
sa-nsxedge-01> get firewall 5215b15b-7c8a-4c90-810d-
b5a26bad8a00 ruleset rules
DNAT rule count: 0
SNAT rule count: 0
Firewall rule count: 2
Rule ID : 3048
Rule : inout protocol tcp stateless from any to
addrset {172.16.10.11, 172.16.10.12, 172.16.20.11,
172.16.30.11} port 22 drop
Rule ID : 2025
Rule : inout protocol any stateless from any to any
accept
On an NSX Edge node, the get firewall interfaces command can be used to
retrieve all interfaces that have firewall rules configured.

The get firewall <interface_id> ruleset rules command lists all the firewall
rules for a specified interface.

The <interface_id> of a given interface is found in the previous command result.

In the example, the rule attached to the uplink of NSX Edge (T0-GW-01-Uplink-1) matches the
Block SSH rule in the NSX UI.
This command can also be used to retrieve any user-configured NAT rules or system-default
rules.

291
7-20 Gateway Firewall Validation: API
You can gather additional information about the realization state of a gateway firewall rule by
using the following API calls:
• To retrieve the realized state, use:

GET https://<NSX_Manager_IP>/policy/api/v1/infra/
realized-state/status?intent_path=<GATEWAY_RULE_PATH>
• To retrieve the realized entity, use:

GET
https://<NSX_Manager_IP>/policy/api/v1/infra/
realized-state/realized-
entities?intent_path=<GATEWAY_RULE_PATH>

You can retrieve the identifiers for

the Gateway Firewall policies and
rules by selecting Copy Path to
Clipboard.

You can gather additional information about the realization state of a gateway firewall rule by
using API calls.

292
This first API call returns the realization status of the object identifier passed as a parameter. In
the example, if the gateway firewall rule was successfully realized, it returns a SUCCESS status.
The GATEWAY_RULE_ABSOLUTE_PATH can be obtained from the UI.

The second API call provides additional detail about how the gateway firewall rule is realized in
the management plane and the data plane. The details include the mapping between the rule
identifier in NSX Policy and NSX Manager, as well as the realization and runtime status of the
rule. The realization state refers to the successful configuration of the rule in the management
plane, whereas the runtime status refers to the successful configuration in the data plane.
Gateway Firewall policies and rules are identified by their absolute path. This identifier is used in
API calls, CLI commands, and log files. You can select the Copy path to clipboard option in the
UI to find the identifier for a particular policy or rule. This option is available by clicking the
vertical ellipsis next to each rule or policy.

For example, the identifier for the Block SSH traffic gateway policy is
/infra/domains/default/gateway-policies/Block_SSH_traffic. And
the identifier for the BLOCK SSH firewall rule is /infra/domains/default/gateway-
policies/Block_SSH_traffic/rules/Block_SSH.

293
7-21 Log Files for Troubleshooting a Gateway
Firewall
Several log files are useful for troubleshooting gateway firewall rules.

You can validate the Gateway Firewall rule publication by using the get log-file syslog
command on NSX Edge.

The rule id or the FIREWALL keyword can be used to parse the logs.

294
7-22 Gateway Firewall Troubleshooting
Flowchart
Use these steps for troubleshooting Gateway Firewall.

For information about the configuration maximums for Gateway Firewall, see VMware
Configuration Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=19-35.

You can also check configuration maximums directly in the NSX UI by navigating to Security >
Security Overview > Capacity.

295
7-23 Scenario 1: Problem Description
Recently, a team member modified the configuration of the gateway firewall. After making
changes, the app-server (172.16.20.11) cannot ping the control-center (172.20.10.80) anymore.
The rule has been successfully
realized in the datapath.

The rule parameters are correct.

But the rule is not matched.

296
7-24 Scenario 1: Root Cause (1)
The logs display that the ICMP packets are rejected by firewall rule 3069.
sa-nsxedge-01> get log-file syslog | find FIREWALL
sa-nsxedge-01.vclass.local NSX 5223 FIREWALL [nsx@6876
comp="nsx-edge" subcomp="datapathd" s2comp="firewallpkt"
level="INFO"] <2 5215b15b7c8a4c90:810db5a26bad8a00> INET
reason-match REJECT 3069 OUT 84 PROTO 1 172.16.20.11-
>172.20.10.80
The packets are rejected by rule 3069, which is not the rule that you configured to allow the
traffic between 172.16.20.11 and 172.20.10.80.

297
7-25 Scenario 1: Root Cause (2)
A more generic rule in a different policy that rejects traffic from 172.16.20.11 to 172.20.10.80 was
configured before the allow rule.
Because rules are evaluated from top to bottom, when the traffic matches the reject rule, the
Allow_Control_Center rule is never matched.
The traffic from the app-server to the control-server
matches both rules, but only the top rule is applied.

298
7-26 Scenario 1: Resolution
You can resolve the problem by changing the order of these two policies so that the more
specific rule is at the top and evaluated first.

299
7-27 Scenario 2: Problem Description
A Security Administrator created a rule in the Gateway Firewall to enable SSH access to the
web servers, and it is not working as expected.

The rule was successfully realized in the

datapath.

The rule parameters are correct.

The rule statistics indicate that the rule

is matched. However, the session
count must not be 0 because it is SSH
traffic.

300
7-28 Scenario 2: Root Cause (1)
The logs display the incoming SSH packets hit the correct rule and are allowed, but the
outcoming packets are rejected by the deny_all rule.

sa-nsxedge-01> get log-file syslog | find FIREWALL

sa-nsxedge-01.vclass.local NSX 5223 FIREWALL [nsx@6876
comp="nsx-edge" subcomp="datapathd" s2comp="firewallpkt"
level="INFO"] <2 5215b15b7c8a4c90:810db5a26bad8a00> INET
reason-match PASS 3056 IN 48 TCP 172.20.10.80/51444-
>172.16.10.11/22 S
sa-nsxedge-01.vclass.local NSX 5223 FIREWALL [nsx@6876
comp="nsx-edge" subcomp="datapathd" s2comp="firewallpkt"
level="INFO"] <2 5215b15b7c8a4c90:810db5a26bad8a00> INET
reason-match REJECT 3059 OUT 48 TCP 172.16.10.11/22-
>172.20.10.80/51444 SA

301
7-29 Scenario 2: Root Cause (2)
In the firewall configuration in the edge CLI, the rule is stateless.
sa-nsxedge-01> get firewall 5215b15b-7c8a-4c90-810d-
b5a26bad8a00 ruleset rules
DNAT rule count: 0
SNAT rule count: 0
Firewall rule count: 4
Rule ID : 3056 Rule : inout protocol tcp stateless
from any to addrset {172.16.10.11, 172.16.10.12} port 22
accept with log

302
7-30 Scenario 2: Root Cause (3)
In the Policy Settings in the UI, the policy is configured as Stateless.

Stateless: The firewall filters packets based on

each individual packet.

Stateful: The firewall filters packets based on the

context and state of a network connection.

As the Firewall Policy is stateless, the firewall does not consider the SSH session as a whole. It
inspects every packet and matches it to the rule.
In the scenario, the rule set by the security admin is: allow all TCP packets on port 22 (SSH) to
the web-servers VMs. A rule that allows packets leaving the web-servers on TCP port 22 does
not exist. As the policy is stateless, the firewall does not consider the return packets as part of
the same session. Those packets are dropped by the deny_all rule at the bottom.

303
7-31 Scenario 2: Resolution (1)
You can resolve the problem by adding the firewall rule for the return packets.

Create a rule in the Allow SSH policy to allow the SSH return packet.

You create a service with the Raw-Port-Protocol option with service type TCP and source port
22.

304
7-32 Scenario 2: Resolution (2)
You can also create a stateful policy to allow SSH access to the web servers.

Now that the policy is stateful, the firewall keeps track of the whole SSH connection and the
return packets are not dropped.
Change a policy from stateless to stateful is not possible after it has been created and published.
Thus, a new policy must be created.

305
7-33 Lab 9: Troubleshooting the NSX
Gateway Firewall
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

306
7-34 Review of Learner Objectives
• Describe the gateway firewall architecture
• Use the UI, the CLI, the API, and the logs to validate and troubleshoot the gateway firewall
configurations

• Troubleshoot common gateway firewall problems

307
7-35 Lesson 3: URL Analysis

7-36 Learner Objectives

• Explain URL Analysis

• Identify uses cases for URL Analysis

• Describe the key concepts of URL Analysis

• Describe the URL Analysis architecture

• Configure URL Analysis

• Identify and resolve common URL Analysis issues

308
7-37 About URL Analysis
URL Analysis monitors access to external websites.
URL Analysis analyzes the north-south traffic and it is only available on the Gateway Firewall.

Websites are classified into categories and assigned a reputation score based on their domain.

In the NSX-T Data Center 3.1 release, traffic cannot be filtered based on the URL classification.

In NSX-T Data Center 3.1, URL Analysis only supports classification and reputation scoring based
on the domain of the URL. Dropping or allowing traffic, based on the reputation or classification
of a specific domain, is not possible yet.

309
7-38 Use Cases
Security administrators use URL Analysis to:
• Gain insight into the type of websites accessed in their organization

• Understand the reputation and risk of the accessed websites

310
7-39 Requirements and Limitations
Before using URL Analysis, administrators must consider the following factors:
• URL Analysis needs the NSX Data Center Distributed Threat Prevention license in addition
to the NSX Data Center Enterprise Plus license.

• URL Analysis must be enabled at the NSX Edge cluster level.

• The management interface of the NSX Edge nodes must have Internet connectivity to
download category and reputation definitions.

• URL Analysis is only supported on traffic initiated from a Tier-1 gateway.

• A layer 7 firewall rule must be configured on the Tier-1 gateway uplink to capture the DNS
traffic.

311
7-40 URL Category
URL categories are used to classify websites into different types:
• More than 80 categories are predefined in the system.

• A website or domain can belong to multiple categories.

Category Name Category ID

Uncategorized 0

Real Estate 1

Computer and Internet Security 2

Financial Services 3

Business and Economy 4

Computer and Internet Info 5

... ...

Food and Dining 83

A site or domain can belong to multiple categories. For example, www.vmware.com belongs to
both the Business and Economy category and the Computer and Internet Info category. A
domain can belong to a maximum of five categories.

312
7-41 Reputation Score and Severity
The reputation score is a measure of the trustworthiness of a URL. It ranges from 1 to 100.
Based on their reputation score, URLs are classified into the following severities:

• High Risk (1 through 20)

• Suspicious (21 through 40)

• Moderate Risk (41 through 60)

• Low Risk (61 through 80)

• Trustworthy (81 through 100)

• Unknown

Based on their reputation score, URLs are classified into the following severities:

• High Risk (1 through 20): Sites with a high probability of containing malicious links or
payloads.

• Suspicious (21 through 40): Sites with a higher than average probability of containing
malicious links or payloads.

• Moderate Risk (41 through 60): Benign sites that exhibit some characteristics that suggest
security risks.

• Low Risk (61 through 80): Benign sites that rarely exhibit characteristics that expose the
user to security risks.

• Trustworthy (81 through 100): Well-known sites with strong security practices.

• Unknown: An unknown reputation score is reported in the NSX UI when the NSX Edge
node cannot retrieve the reputation score for a given domain in a timely manner.

313
7-42 Webroot and NSX Threat Intelligence
Cloud Service
Webroot has the following features:

• External repository that hosts the URL category and reputation definitions

• Maintained by a third party

NSX Threat Intelligence Cloud Service has the following features:

• Obtains reputation and category data from Webroot and caches it for use in the NSX
environment

• Maintained by VMware

NSX uses a third party threat intelligence service called Webroot to get URL reputation scores
and severity. Webroot uses a combination of cloud-based analytics and machine learning to
generate an external repository containing URL categories and reputations.

NSX Threat Intelligence Cloud Service gets the reputation and category data from Webroot and
caches them locally for NSX to use. NSX Threat Intelligence Cloud Service is maintained by
VMware.

314
7-43 URL Analysis Architecture
URL Analysis operates as follows:
1. NSX Threat Intelligence Cloud Service obtains the reputation and category data from
Webroot and caches it.

2. NSX Manager obtains the SSL keys from NSX Threat Intelligence Cloud Service and sends
the keys to the NSX Edge nodes through the central control plane (CCP). Configuration
changes are also pushed to the NSX Edge nodes through CCP.
3. The NSX Edge nodes connect to NSX Threat Intelligence Cloud Service over SSL and
download the URL category and reputation data locally.

4. The NSX Edge nodes collect traffic data for the FQDNs and send it to NSX Manager, which
graphically displays the information.

315
7-44 DNS Snooping on the Tier-1 Gateway
The Tier-1 gateway inspects the DNS response packets to get a mapping between the IP and
the domain.

316
7-45 Mapping Category and Reputation to
Domain
When the session terminates, the DNS table is used to find the domain mapped to the
destination IP.

The reputation and category for the mapped domain are retrieved from the local edge cache.

NSX Threat Intelligence Cloud Service and Webcloud are retrieved if the local cache does not
have an entry.

The entry is added into the local Edge URL table with the domain name, the category, the
reputation score, and the session count.

The URL table is retrieved every 5 minutes.

317
7-46 Enabling URL Analysis
You enable URL Analysis by navigating to Security > North South Security > URL Analysis >
Settings.

You enable URL Analysis at the NSX Edge cluster level. When enabled, you can check the
connection status to Cloud Service for each NSX Edge node. Also, you can verify the version of
the URL Data used.

318
7-47 Setting Context Profiles for URL Analysis
Context profiles for URL Analysis specify the categories of traffic to be analyzed.

2
1

An NSX Edge cluster can have multiple profiles attached.

To set a context profile for URL Analysis:

1. Click the Set link on the URL Analysis Settings tab.

2. Add a new context profile and enter a name.

3. Configure the attributes for the context profile.

The only attribute type available during the URL Analysis configuration is URL Category.

Creating context profiles is optional. If profiles are not created, all traffic is analyzed.

319
7-48 Configuring a Layer 7 Rule for DNS
Traffic
You must configure a layer 7 gateway firewall rule for DNS traffic so that URL Analysis can
analyze domain information.

The Tier-1 gateway backed by the

NSX Edge cluster where URL
Analysis is enabled.

To configure the layer 7 gateway rule, navigate to Security > North South Security > Gateway
Firewall > Gateway Specific Rules.
URL Analysis relies on the configuration of the layer 7 rule to capture the DNS traffic that
traverses the NSX Edge cluster. This layer 7 rule must be configured on a Tier-1 gateway
backed by the NSX Edge cluster that you want to analyze traffic for.
The DNS traffic is analyzed to extract the host name and IP information from the DNS packets.
This information is used to categorize and score the traffic.

The services in the gateway layer 7 rule are set to DNS-UDP and DNS to capture DNS traffic
over both TCP and UDP. Also, the context profile for this rule is DNS.

320
7-49 URL Analysis Dashboard
You can view the URL Analysis dashboard by navigating to Security > North South Security >
URL Analysis > URLs.

The diagram shows the URL distribution.

On the right, the URL Analysis dashboard shows a summary of all analyzed URLs classified by
reputation score and category:

Colors are used to differentiate the risk level:

• Red represents High Risk URLs.

• Orange represents Suspicious URLs.

• Yellow represents Moderate URLs.

• Gray represents Low Risk URLs.

• Green represents Trustworthy URLs.

Different colors are also used to represent URL categories (for example, Social Networking,
Search Engine).

At the bottom of the page, additional details about each URL, including its reputation score, URL,
category, and session count, are available.

The NSX UI can take up to five minutes to display URL information. The NSX Edge nodes
synchronizes data with the management plane at this frequency.

321
7-50 Scenario 1: Problem Description
You have a valid Enterprise Plus license for NSX-T Data Center.
However, when navigating to Security > North South Security > URL Analysis, a message
appears.

322
7-51 Scenario 1: Root Cause and Resolution
To use the URL Analysis feature, you must have the NSX Data Center Distributed Threat
Prevention license in addition to the NSX Data Center Enterprise Plus license.

After adding the correct licenses, you can start using the URL Analysis feature.

For additional information about the licensing requirements for NSX-T Data Center 3.1, see the
VMware NSX Data Center datasheet at
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmwa
re-nsx-datasheet.pdf and VMware knowledge base article 80866 at
https://kb.vmware.com/s/article/80866.

323
7-52 Scenario 2: Problem Description
URL Analysis is configured but does not display any URL Analysis data.
In the URL Analysis Settings, the NSX Edge node connection status is Up but
the URL Data version shows 0.0.0.

324
7-53 Scenario 2: Root Cause and Resolution
The edge-appctl -t /run/vmware/edge/dpd.ctl fw/geturlconfigstat
command checks the communication status between NSX Edge and the Cloud Service.

root@sa-nsxedge-01:~# edge-appctl -t /run/vmware/edge/dpd.ctl

fw/geturlconfigstat
{"dbVersion":"v 0 0 u
0","configurationStatus":"enabled","status":"0","error":"FW_UR
L_FILTERING_DB_ERR"}
The command output indicates that the NSX Edge node cannot reach the Cloud Service server
and cannot download the reputation scores locally.

This command must be run in root mode.

You can access root mode by entering st e in the CLI. The password for root was set up
during the edge configuration.

The output of the command shows a communication issue between the NSX Edge node and the
Cloud Service server. The status is 0. It raises an error code and NSX Edge cannot retrieve the
database version or any other information.
To resolve this issue, the communication between the NSX Edge node and the Cloud Service
server must be established because one of the prerequisites for URL Analysis is for the NSX
Edge nodes to have Internet access to be able to download category and reputation definitions.

325
7-54 Scenario 2: Solution Verification
After the communication between the NSX Edge node and the Cloud Service server is re-
established, the command shows the following status:

root@sa-nsxedge-01:~# edge-appctl -t /run/vmware/edge/dpd.ctl

fw/geturlconfigstat
{"dbVersion":"v 7 621 u
75","configurationStatus":"enabled","dbUpdateTime":"1610036360
","localLookupCount":"47","cloudLookupCount":"34","status":"1"
,"error":"FW_URL_FILTERING_NO_ERR"}
The UI displays the URL Data Version for the NSX Edge node and URL Analysis works as
expected.

After the Internet connection is re-established, the command shows a status of 1, which is
correct. It also displays the URL Data Version (dbVersion) and reports no errors.

The NSX Edge node now displays a URL Data Version in the NSX UI. In this example, the version
is 7.621.75.

326
7-55 Scenario 3: Problem Description
URL Analysis is configured and enabled but does not display any URL Analysis data.

327
7-56 Scenario 3: Root Cause
The layer 7 rule for DNS traffic was not configured on the Tier-1 gateway.
sa-nsxedge-01> get firewall 3791a6ce-4cb2-41e5-b069-
7a24b15d6e39 ruleset rules
Firewall rule count: 1
Rule ID : 2024
Rule : inout protocol any from any to any accept

In the gateway firewall rules for the Tier-1 gateway, the layer 7 rule for DNS traffic is missing.
The only rule present is the default rule.

URL Analysis relies on the configuration of the layer 7 rule to capture the DNS traffic that
traverses the NSX Edge cluster. This layer 7 rule must be configured on the Tier-1 gateway.
To retrieve the firewall interface id, run the get firewall interface command. The
output includes the id of the uplink interface of the Tier-1 SR.

328
7-57 Scenario 3: Resolution (1)
After adding the layer 7 DNS rule, the NSX CLI lists the rule.
sa-nsxedge-01> get firewall 3791a6ce-4cb2-41e5-b069-
7a24b15d6e39 ruleset rule
Firewall rule count: 3
Rule ID : 3057
Rule : inout protocol udp from any to any port 53
interface uuid 3791a6ce-4cb2-41e5-b069-7a24b15d6e39 with
attribute profile 892c3032-5814-4b2c-852a-f26c69824753 accept

Rule ID : 3057
Rule : inout protocol tcp from any to any port 53
interface uuid 3791a6ce-4cb2-41e5-b069-7a24b15d6e39 with
attribute profile 892c3032-5814-4b2c-852a-f26c69824753 accept

Rule ID : 2024
Rule : inout protocol any from any to any accept

329
7-58 Scenario 3: Resolution (2)
The rule is also present in the NSX UI, and URL Analysis starts inspecting the traffic.

330
7-59 Lab 10: Analyzing Web Traffic with URL
Analysis
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

331
7-60 Review of Learner Objectives
• Explain URL Analysis
• Identify uses cases for URL Analysis

• Describe the key concepts of URL Analysis

• Describe the URL Analysis architecture

• Configure URL Analysis

• Identify and resolve common URL Analysis issues

332
7-61 Key Points
• The gateway firewall is a stateful firewall for north-south traffic, independent from the
distributed firewall.
• The gateway firewall service is part of the NSX Edge node.

• The gateway firewall is a centralized service requiring the SR component of the router.

• A Gateway Firewall policy includes one or more individual firewall rules and can be applied
to Tier-0 and Tier-1 gateways and their interfaces.

• URL Analysis analyzes the north-south traffic and monitors the access to external websites.

• Websites are classified into categories and assigned a reputation score.

Questions?

333
334
Module 8
Operating Internal Firewalls

8-2 Importance
As a security administrator, you must understand the Day-2 operations of your NSX-T Data
Center environment to proactively detect, diagnose, and address problems or misconfigurations.

8-3 Module Lessons

1. Security Monitoring Tools

2. NSX Intelligence

3. Security Best Practices

335
8-4 Lesson 1: Security Monitoring Tools

8-5 Learner Objectives

• Monitor NSX-T Data Center security features by using the NSX UI

• Describe the different use cases of vRealize Log Insight, vRealize Network Insight, and NSX
Intelligence

• Explain the capabilities and use of vRealize Log Insight for troubleshooting NSX firewalls

• Describe the benefits and security uses cases of vRealize Network Insight

336
8-6 Monitoring Security from the NSX UI
You can monitor NSX-T Data Center firewalls and other security components from the Security
Overview dashboard of the NSX UI.

The Security Overview dashboard in NSX Manager provides a summary of the Distributed
Firewall Rule utilization, including a breakdown of the types of rules configured in the system.
This dashboard also includes information related to NSX Distributed IDS/IPS, URL Analysis, and
Threat Detection.

337
8-7 Security Monitoring Tools
NSX-T Data Center integrates with vRealize Log Insight and vRealize Network Insight to provide
operational visibility of the security posture in your environment:
• vRealize Log Insight delivers heterogeneous log management with intuitive, actionable
dashboards and analytics.

• vRealize Network Insight delivers intelligent operations for physical and software-defined
networking and security.
NSX Intelligence is a native distributed analytics solution that provides visibility and dynamic
security policy enforcement for NSX-T Data Center environments.

338
8-8 Using the Right Tool for the Right Job
vRealize Log Insight vRealize Network Insight NSX Intelligence

Usage • Small projects and • Discovering • Native security, deep

applications application flows security, and
through the NSX analytics.
• Logging tool with rich
Distributed Firewall
search and filtering • Applying security
and other third-party
capabilities policies directly to
vendors
NSX.

Excels at • Providing near real- • End-to-end network • Simple and automatic

time insights into visibility through recommendations
flows through logging physical devices and applied directly to the
from the NSX virtual networking NSX Distributed
Distributed Firewall constructs Firewall.
rules.
• Troubleshooting • Quickly reducing
networking issues micro-segmentation
time to value

Scale Most likely one application Approximately 10 million Approximately 144 million
at the time flows per day flows per day

339
8-9 About vRealize Log Insight
vRealize Log Insight collects, imports, and analyzes logs to provide answers to problems related
to systems, services, and applications, and derive important insights.
You can select to display the events in your system for the last five minutes, hour, or day. You
can also view a breakdown of errors by the hour and observe the trends in log events.

The vRealize Log Insight web interface includes the following tabs:

• The Dashboards tab contains custom dashboards and content pack dashboards. On the
Dashboards tab, you can view graphs of log events in your environment, or create your
custom sets of widgets to access the information that matters most to you.

• On the Interactive Analytics tab, you can search and filter log events, and create queries to
extract events based on timestamp, text, source, and fields in log events. vRealize Log
Insight presents charts of the query results. You can save these charts to review later on
the Dashboards tab.

• On the Content Packs tab, you can access content packs, which contain dashboards,
extracted fields, saved queries, and alerts that are related to a specific product or set of
logs.

• On the Administration tab, vRealize Log Insight administrators can manage user accounts,
configure storage location and archiving, configure an outgoing SMTP server for email
notifications, and change several other parameters. Users who are not administrators can
view and manage their user alerts, event export tasks, and shared dashboard URLs on this
tab. They can also view content pack alerts and other limited information.
340
8-10 vRealize Log Insight: Content Pack for
NSX-T Data Center
To view log dashboards in vRealize Log Insight with details on the NSX-T Data Center
operations, you must install the NSX-T Data Center content pack.

341
8-11 Using vRealize Log Insight to Monitor
NSX-T Data Center
NSX Manager and the NSX Edge nodes can be configured to send logs to vRealize Log Insight
for monitoring the infrastructure.

To monitor NSX-T Data Center:

1. Open an SSH connection to NSX Manager or the NSX Edge nodes.

2. Set up log forwarding to vRealize Log Insight.

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

info
3. Verify that log forwarding is configured.

get logging-servers
After you deploy the NSX-T Data Center environment, you can configure NSX Manager and the
NSX Edge nodes to send logging information to vRealize Log Insight.

For example, if you want vRealize Log Insight to analyze information related to the gateway
firewall traffic, you must send the NSX Edge logs to vRealize Log Insight.

342
8-12 Configuring ESXi Hosts to Send Log Data
to vRealize Log Insight
Before you can monitor Distributed Firewall rules from vRealize Log Insight, you must configure
your ESXi hosts to forward log events:

esxcli network firewall ruleset set -r syslog -e true

esxcli system syslog config set --loghost=sa-vrli-
01.vclass.local
esxcli system syslog reload
If vSphere is integrated through the Log Insight Administration page, vRealize Log Insight can
configure all hosts for a given vCenter Server automatically.

343
8-13 Enabling Logging for Firewall Rules
You enable logging for the firewall rules that you want in the NSX UI.

344
8-14 Using vRealize Log Insight to Monitor
Distributed Firewall Information
After you enable logging for the firewall rules, you can use the NSX - Distributed Firewall -
Traffic dashboard in vRealize Log Insight to understand the traffic in your environment.

NSX - Distributed Firewall - Traffic

The NSX - Distributed Firewall - Traffic dashboard displays the following information:

• Top Firewall Sources and Destinations: These dashboards depict the top source and
destination IP addresses from all firewall rules that are logging data. This information enables
you to determine the origin and destination of most traffic that passes through the firewall.

• Applications Ports Permitted or Denied: These dashboards measure all in/out connections
permitted and denied in the NSX-T Data Center environment by destination port. Traffic
types without an associated port, such as ICMP, are not displayed.

• Top Firewall Sources and Destinations by bytes: These dashboards display all firewall traffic,
in bytes by source and destination IP address, from the client to a server.

345
8-15 Using vRealize Log Insight for
Troubleshooting NSX Firewalls
You can search and filter log events on the Interactive Analytics tab.

To find only events that contain the specified keywords, enter complete keywords, globs, or
phrases in the search text box and click Search.

Using quoted text in the main search field matches exact phrases. Search uses only full tokens.
For example, searching for err does not find error as a match.

You can also specify the time range on either the Dashboards or Interactive Analytics pages in
the web user interface. Time ranges are inclusive when filtering.

Using filters, you can search for log events that match certain values of specific fields. The fields
available depend on the content packs installed.
You can combine multiple field filters by creating a filter row for each field. You can toggle the
operator that is applied to multiple-row filters:

• To apply the AND operator, select all.

• To apply the OR operator, select any.

You can use globs in search terms, for example, vm* or vmw?re:
• For 0 or more characters, use *.
• For one character, use ?.
A glob describes the match of values returned when using wildcards or regular expressions.

To troubleshoot NSX firewall rules, you can use the FIREWALL_PKTLOG keyword to filter the
logs. Additionally, you can add filters based on the rule ID, action, source and destination IP
addresses, and so on.
346
8-16 About vRealize Network Insight
vRealize Network Insight provides a converged operations plane between virtual and physical
networks. You discover, optimize, and troubleshoot applications from the data center to the
cloud to the branch.

vRealize Network Insight is an operations and analytics application that delivers intelligent
operations for software-defined networking and security. vRealize Network Insight helps
customers build an optimized, highly available, and secure network infrastructure across
multicloud environments. It accelerates micro-segmentation planning and deployment. vRealize
Network Insight provides visibility across virtual and physical networks and operational views to
both manage and scale NSX deployments.
vRealize Network Insight is available for deployment on-premises or as a VMware Cloud service
called vRealize Network Insight Cloud.

347
8-17 vRealize Network Insight Architecture
and Components
vRealize Network Insight includes two distinct appliances:

• The platform VM processes and presents network data.

• The collector VM collects the data for the platform VM.

The vRealize Network Insight Platform VM stores, processes, and analyzes data from proxy VMs
and displays flows, graphs, paths, events, and so on.
The vRealize Network Insight Proxy VM (collector) securely pairs with the platform VM and
collects data from data sources and sends the collected data to the platform VM.
Data sources enable the application to gather data from certain aspects of your data center.
These aspects range from your NSX installation to physical devices.

For a complete list of supported data sources, see the section about supported products and
versions in Installing vRealize Network Insight at https://docs.vmware.com/en/VMware-
vRealize-Network-Insight/index.html.

348
8-18 Benefits of vRealize Network Insight
Using vRealize Network Insight provides several benefits:
• Secure your network with micro-segmentation recommendations, compliance, and auditing.

• Plan, secure, and migrate applications.

• Troubleshoot network and security throughout the virtual and physical infrastructure.

• Manage and scale NSX with a best practice checklist.

The screenshot shows the home page of the vRealize Network Insight UI using the dark theme.
Using vRealize Network Insight, you can deploy micro-segmentation with comprehensive
NetFlow assessment to model security groups and firewall rules, use actionable
recommendations for implementing micro-segmentation, and monitor compliance postures over
time.
vRealize Network Insight can help you improve performance and availability with converged
visibility across physical and virtual networks. You can also simplify NSX operations management
with intuitive UI and natural language search to quickly identify issues, troubleshoot, and get best
practices deployment and compliance recommendations.

349
8-19 Planning, Securing, and Migrating
Applications
Use vRealize Network Insight to manage your applications:
• Visualize application topology
• Identify application dependencies
• Access security groups and firewall rules
• Monitor traffic flows and metrics
• Plan micro-segmentation
• Plan migrations

350
Use vRealize Network Insight to discover applications where they reside, whether in VMs,
containers, or the cloud. Discover applications using machine naming convention, tags, attributes,
or retrieve from a Configuration Management Database (CMDB).

Identify application boundaries and determine which applications to start with to plan micro-
segmentation. Identify application dependencies to drive application migration to public clouds,
other data centers, or disaster recovery sites.

351
8-20 Security Policy Automation for Micro-
Segmentation
vRealize Network Insight automates micro-segmentation:

• Discover vCenter Server and NSX constructs, such as folders, clusters, VXLANs, and
security tags.

• Automate security groupings based on vCenter Server and NSX constructs, workload
characteristics, ports, or common services.

• Recommend security policies and firewall rules (Zero-Trust model).

352
8-21 Security Operations, Auditing, and
Compliance
vRealize Network Insight provides real-time understanding of security group memberships and
effective firewall rules for a VM, between VMs, and between VMs and physical machines.

The compliance engine can write policies and set alerts. Instant alerts can be sent on policy
violation or noncompliance.

A data center time machine tracks all changes for troubleshooting, audit, and compliance
purposes.

353
8-22 Lab 11: Using vRealize Log Insight to
Diagnose NSX Firewalls
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

354
8-23 Review of Learner Objectives
• Monitor NSX-T Data Center security features by using the NSX UI
• Describe the different use cases of vRealize Log Insight, vRealize Network Insight, and NSX
Intelligence

• Explain the capabilities and use of vRealize Log Insight for troubleshooting NSX firewalls

• Describe the benefits and security uses cases of vRealize Network Insight

355
8-24 Lesson 2: NSX Intelligence

8-25 Learner Objectives

• Describe NSX Intelligence and its use cases

• Explain NSX Intelligence system requirements

• Deploy the NSX Intelligence appliance

• Explain NSX Intelligence visualization and recommendation capabilities

356
8-26 About NSX Intelligence
NSX Intelligence is a distributed analytics solution that provides visibility and dynamic security
policy enforcement for NSX-T Data Center environments, including:
• Visualization of the data center objects and traffic flows

• Recommendations for micro-segmentation planning

• Continuous monitoring of changes in the environment

357
8-27 Use Cases for NSX Intelligence
NSX Intelligence enables several capabilities for security administrators.

NSX Intelligence enables the following capabilities for security administrators:

• Visibility: Gain insight about the micro-segmentation traffic flows.

• Policy Recommendations: Generate security recommendations and dynamically enforce

security policies.

• Continuous Monitoring: Detect if virtual machines change their group membership.

358
8-28 NSX Intelligence Requirements
The requirements to deploy NSX Intelligence are:
• NSX Intelligence must be deployed on ESXi hosts managed by vCenter Server.

• The NSX Intelligence appliance must have a static IP address. You cannot change the IP
address after installation.

• Local NSX Manager instances support NSX Intelligence.

• NSX Intelligence requires an NSX Data Center Enterprise Plus license.

• You must have an Enterprise Administrator role to install the NSX Intelligence appliance and
to start and stop data collection.

Other user roles such as Security Administrators can visualize the NSX Intelligence data and
create and apply recommendations. However, an Enterprise Administrator role is mandatory to
install the NSX Intelligence Appliance and to start and stop data collection.

359
8-29 NSX Intelligence Sizing
NSX Intelligence is deployed as a virtual appliance (OVA).
The following sizes are available:

• A Small appliance size can be used in the following environments:

— Lab or proof-of-concept

— Small-scale production

• A Large appliance size can be used in a large-scale production environment.

Small Large

vCPU 16 32

RAM 64 GB 128 GB

Disk 2 TB 2 TB

360
8-30 NSX Intelligence Compatibility Matrix
The table shows the compatibility between versions of NSX-T Data Center and NSX
Intelligence.
NSX Intelligence must be upgraded before NSX Manager.

NSX-T Data Center NSX Intelligence 1.2 NSX Intelligence 1.1.1 NSX Intelligence 1.1
Version

3.1.1 Yes No No

3.1.0 Yes No No

3.0 Yes Yes Yes

For the most up-to-date compatibility information, see VMware Product Interoperability Matrices
at
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&175=&555
=.
Since NSX Intelligence 1.1.0, the upgrade is performed from the NSX UI only. Although you can
upgrade the appliance using the CLI, the CLI upgrade process does not include important
preupgrade checks.

361
8-31 NSX Intelligence Deployment (1)
You can deploy the NSX Intelligence appliance from the NSX UI by navigating to System >
Configuration > Appliances > ADD NSX INTELLIGENCE APPLIANCE.

362
8-32 NSX Intelligence Deployment (2)
The NSX Intelligence appliance can be deployed from a local file or a remote OVA link.

You must configure NTP services across all NSX appliances and ESXi hosts to ensure accurate
flow time stamps and data correlation between the ESXi hosts and NSX Manager.
363
8-33 Validating the NSX Intelligence
Deployment
After the deployment finishes successfully, you validate the status of the NSX Intelligence
appliance by navigating to System > Configuration > Appliances.

From the Actions menu, you can stop or start data collection and delete the appliance.

Data collection starts automatically after deploying the appliance.

364
8-34 Checking NSX Intelligence Services
You check the status of the NSX Intelligence services from the appliance command line:
get services

If you observe an error or alarm in the NSX UI, you can check the status of the NSX Intelligence
services from the appliance command line with the get services command.

In a healthy NSX Intelligence appliance, all services should be running and the Service Health
must be stable. All services do not have an associated Service Health (for example, the spark-
job-scheduler service).

365
8-35 NSX Intelligence Visualization (1)
You can visualize flows for VMs and security groups by navigating to Plan & Troubleshoot >
Discover & Plan > Discover & Take Action.

Flows are unprotected, blocked, or allowed.

Users can filter data flows based on Security groups, VMs, physical servers, and IP addresses.

In addition, NSX Intelligence offers enhanced filtering capabilities to more granularly define flows
that are displayed in the canvas.
Data flows are divided into the following categories:
• Unprotected: The traffic flow matches the default firewall rule to allow, drop, or reject any
traffic from any source and any destination. More granular security policies are needed to
secure the environment.
• Blocked: The traffic flow matches a more granular rule than the default rule that drops or
rejects traffic.
• Allowed: The traffic flow matches a more granular rule than the default rule that allows
traffic.

Since NSX Intelligence 1.2.0, a mini map view is available to improve the navigation.

A galactic view is also available to improve the display of large environments.

366
8-36 NSX Intelligence Visualization (2)
You can examine the details of traffic flows by clicking the corresponding line in the canvas.

The screenshot shows an allowed SSH flow between sa-web-01 and sa-app-01. It also displays
details about two unprotected flows.

Each flow includes the following information:

• Source: Name of the source VM, the user, and the process run
• Destination: Name of the destination VM
• Services: Service or services identified in the flow
• App ID: Application ID, if applicable
• FQDN: Fully qualified domain name, if applicable
• Latest Flow: Unprotected, allowed, or blocked
• End Time: Time when the flow ended

367
8-37 NSX Intelligence Recommendations (1)
You can start security recommendations by navigating to Plan & Troubleshoot > Discover &
Plan > Recommendations.
You can run concurrent recommendations.

368
8-38 NSX Intelligence Recommendations (2)
Recommendations analyze traffic data for a given set of VMs or a security group for a specified
period. Recommendations suggest security groups, services, and distributed firewall rules.
You configure the following parameters to start a recommendation:
• Selected Entities in Scope
• Traffic Considered
• Connectivity Strategy
• Recommendation Output Mode
• Recommendation Service Type
• Time Range

369
You configure the following parameters to start a recommendation:

• Selected Entities in Scope: VMs, physical servers, and security groups can be used as inputs
for the recommendation. Security groups can include virtual machines, segment ports,
segments, and VIFs.

Up to 1 security group and up to 100 VMs or physical servers are supported. But no more
than 250 effective compute entities can be used for the recommendation boundary.

• Traffic Considered:

• All Traffic: This default option considers all outbound, inbound, and intra-application
traffic flow types.

• Incoming and Outgoing Traffic: This option considers all traffic flow types that originate
from and outside the application boundary.
• Incoming Traffic: This option only considers traffic flow that originates outside the
application boundary.

• Connectivity Strategy:

• None: This default option does not create any default rule for the security policy.

• Allowlist: This option creates a default drop rule.

• Denylist: This option creates a default allow rule.

• Recommendation Output Mode:

— Objected-based: This default option recommends security groups, including VMs.

— IP-based: This option recommends security groups, including a static list of IPs.

• Recommendation Service Type:

• L4 Services: This default option generates L4 services and rules as an output for the
recommendation.

• L7 Context Profiles: L7 rules, including context-profile information, are recommended

for flows with L7 application id information. If application information is not available, L4
recommendations are generated.

• Time Range: Period for which data is analyzed. It ranges from the last 1 month to the last 1
hour.

370
8-39 NSX Intelligence Recommendations (3)
The Monitoring column indicates whether VM changes are detected after the initial
recommendation.
If VMs change their group membership after the initial analysis session, a rerun flag is set and
users are prompted to rerun the recommendation to analyze changes.

You can turn the Monitoring toggle on or off.

371
8-40 NSX Intelligence Recommendations (4)
The recommended distributed firewall rules, security groups, and services can be published in
NSX Manager.

After the recommendation session is completed, recommendations about the distributed firewall
rules, security groups, and services that should be created to secure the environment are
provided. You can publish these recommendations in NSX Manager and the distributed firewall
rules, security groups, and services are automatically configured for you. You can customize the
recommendations before final publication. This customization can include changing the names of
the recommended rules and security groups.

372
8-41 Lab 12: Using NSX Intelligence to Gain
Security Insights
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

373
8-42 Review of Learner Objectives
• Describe NSX Intelligence and its use cases
• Explain NSX Intelligence system requirements

• Deploy the NSX Intelligence appliance

• Explain NSX Intelligence visualization and recommendation capabilities

374
8-43 Lesson 3: Security Best Practices

8-44 Learner Objectives

• Explain security grouping and tagging best practices

• Describe Gateway Firewall policy categories and rule placement best practices

• Describe Distributed Firewall policy categories and rule placement best practices

• Explain the impact of rule placement and the use of the Applied To field

375
8-45 Grouping Best Practices
The use of groups can be made optimal by following these best practices:
• Use IP and CIDR blocks as static grouping constructs.
• Build broader groups for different environments and zones using static criteria such as IP
subnets and segments.
• Build application-level grouping using dynamic grouping with VM Tags, VM name, or a
combination of both.
• Limit nested groups to three levels of nesting for manageability and resource optimization.
• When using dynamic groups, limit the complexity of the criteria to avoid unexpected
members.
• When possible, use the equal-to criteria to limit the number of unexpected members.

Groups are a useful tool for defining the source or destination in a rule. The use of groups can be
made optimal if best practices are considered from the outset.
With security, a fine balance must exist between agility, dynamic membership, and the security
of the environment. In new deployments, security administrators might heavily rely on regular
expressions to create groups. Although this feature is supported, you must use this method to
create initial groupings only. These initial groupings should be reviewed for accuracy, and static
groups should be created for at least critical components.

If the goal is to have automated security, the use of tags is preferred over groups with complex
membership criteria.

376
8-46 Tagging Best Practices (1)
Tags are typically used to automate security policy enforcement for new applications being
provisioned. Two approaches exist when creating tags in NSX-T Data Center:
• Multiple tags: Assign multiple tags to a given VM based on multiple criteria (that is, one tag
per environment, one tag per tier, and one tag per type of application)

• Combined tags: Assign a single tag to a given VM that combines multiple criteria (that is,
environment, tier, and type of application are combined in a single tag)

Security tags are applied to virtual machines, logical ports, and logical segments, and can be used
for dynamic Security Group membership.

The criteria environment, tier, and type of application are only used for illustrative purposes.
Security administrators might select other criteria that are suitable for their particular
deployment.

377
8-47 Tagging Best Practices (2)
In small deployments, combined tags can significantly simplify tagging and grouping operations.
However, in large-scale implementations, you must use both tagging methods to balance
manageability with processing efficiency.

Challenges Benefits

Multiple Tags Less visibility and harder to Less rules to manage

troubleshoot

Combined Tags More rules to manage (one rule per Simplified tagging and
tag permutation) grouping operations

One of the challenges that might arise when using multiple tags is following the logic when
troubleshooting. For this reason, some administrators advocate the use of compound or
combined tags. The tradeoff with this model is more rules to manage, because a rule must be
written for each permutation. Combined tags are not exclusive to traditional tagging. Typically, a
successful implementation uses a combination of tagging strategies. When large-scale
implementations use combined tagging only, many rules might result, which in turn affects the
processing efficiency on the vNIC.

378
8-48 Gateway Firewall Policy Categories: Rule
Placement Best Practices
The Gateway Firewall simplifies the policy definition by having predefined categories. Gateway
Firewall rules are evaluated top to bottom in a category and left to right across categories.

Most of the Gateway Firewall user configuration is done in the Pre-Shared and Local categories.
As best practice:

• Place corporate policies in the Pre-Shared Rules category.

• Place tenant and application policies in the Local Gateway category.

The gateway firewall includes several predefined categories for rules:

• Emergency: Used for quarantine. It can also be used for Allow rules.

• System: Automatically generated by NSX-T Data Center and specific to internal control
plane traffic, such as BFD rules, VPN rules, and so on. System rules are not to be edited.

• Pre-Rules: The rules are globally applied across all gateways.

• Local Gateway: These rules are specific to a particular gateway.

• Auto Service: These rules are autoplumbed and applied to the data plane.

• Default: These rules define the default gateway firewall behavior.

379
8-49 Distributed Firewall Policy Categories:
Rule Placement Best Practices
The rules in the Distributed Firewall are also classified into categories and processed top to
bottom and left to right.

The diagram summarizes the type of rules each category should contain as best practice.

The categories for distributed firewall rules include:

• Ethernet: All layer 2 policies. Layer 2 firewall rules are always evaluated before layer 3 rules.

• Emergency: Temporary firewall policies needed in emergency situations, such as blocking an

attacker from attacking a web server.
• Infrastructure: Nonapplication policies specific to infrastructure components, such as AD,
DNS, NTP, DHCP, vCenter Server, ESXi hosts, and so on.

• Environment: High-level policy groupings, for example, the production group cannot
communicate with the testing group or the testing group cannot communicate with the
development group.
• Application: Specific and granular application policy rules, such as rules between applications
or application tiers, or rules between microservices.

Ideally, the top categories should be less dynamic than the bottom categories.

380
8-50 Placing the Most Hit Rules at the Top (1)
Place rules that are hit the most towards the top of the ruleset:
• The more rules that need to be evaluated when a new connection is made, the longer the
potential delay introduced by the firewall.

• After a rule or group update, all existing connections are re-evaluated against the updated
ruleset. The quicker the existing connections can be re-evaluated, the better.

Firewall rules for latency-sensitive workloads should also be placed towards the top of the
ruleset to minimize processing time.

381
8-51 Placing the Most Hit Rules at the Top (2)
The most hit rules are located toward the top of the ruleset in the NSX UI.

To retrieve the hit count statistics for a given firewall rule from the NSX UI:

1. Navigate to Security > East West Security > Distributed Firewall.

2. Navigate to the appropriate category, APPLICATION in this example.

3. Find the firewall rule you want to retrieve the hit count for.
4. Click the statistics icon.

382
8-52 Placing the Most Hit Rules at the Top (3)
You can also verify that the most hit rules are located toward the top of the ruleset by using the
NSX CLI command: vsipioctl getrules -f <dvfilter-name> -s

On an ESXi host, the summarize-dvfilter command can be used to retrieve the name of
dvfilter associated with the vNIC of a VM. The firewall rules are stored in this software construct.

You can use this identifier to query the rules associated with the vNIC of such a VM. Run the
vsipioctl getrules -f command and the name of the filter you retrieved with the
previous command to query the rules associated with the vNIC of a VM.

The option -s is used to print the rule statistics.

383
8-53 Using the Applied To Field (1)
The Applied To field dictates the scope for rule enforcement and optimizes resource utilization.

NSX distributed firewall rules are processed as follows:

1. After the user configures the security rules in the NSX UI, the security policy is built by NSX
Manager.
2. This policy is then sent to the ESXi and KVM hosts.

3. The VSIP module on each host places only the necessary rules on the vNIC filters of each
VM.

In the example, the first rule allowing DNS and NTP traffic from any source to any destination is
applied to the DFW as per default. As a result, all virtual machines running on hosts prepared for
NSX store this rule on their vNIC filter.

The second and third rules are applied to the GREEN-VMs group and the BLUE-VMs group,
respectively. Only the VMs in the green group get the second rule, and only the VMs in the blue
group get the third rule.

384
8-54 Using the Applied To Field (2)
The screenshot shows an example of an ineffective use of the Applied To Field.

Unneeded Rules Applied

In the example, ESXi-03 runs web, application, and database servers that are part of a 3-Tier
application. Such a host also runs other virtual machines that serve other purposes and do not
belong to the 3-Tier application. Unnecessary rules being applied to the other virtual machines
too because the firewall rules were configured with the default DFW in the Applied To field.
These unnecessary rules increase the processing time and number of rules stored in the
dataplane.

385
8-55 Using the Applied To Field (3)
The screenshot shows a more efficient use of the Applied To field where the distributed firewall
rules are only stored in the appropriate virtual machines.

Only Needed Rules

In the example, the virtual machines that do not belong to the 3-Tier application no longer
receive the firewall rules. The Applied To field was updated appropriately so that the rules are
only applied and stored on the 3-Tier virtual machines.

386
8-56 Review of Learner Objectives
• Explain security grouping and tagging best practices
• Describe Gateway Firewall policy categories and rule placement best practices

• Describe Distributed Firewall policy categories and rule placement best practices

• Explain the impact of rule placement and the use of the Applied To field

387
8-57 Key Points
• You can use the NSX UI Security dashboards to monitor Distributed Firewall rules, NSX
Distributed IDS/IPS, URL Analysis, and Threat Detection events.
• NSX-T Data Center integrates with both vRealize Log Insight and vRealize Network Insight
to provide operational visibility of the security posture in your environment.

• NSX Intelligence is a native distributed analytics solution that provides visibility and dynamic
security policy enforcement for NSX-T Data Center environments.
• Placing the most hit firewalls rules at the top and using the Applied To field effectively
reduces resource consumption and speeds up rule evaluation time.

Questions?

388
Module 9
Network Introspection

9-2 Importance
NSX-T Data Center includes a Network Introspection feature to provide advanced network and
security controls to partners. Understanding Network Introspection, how to configure it, and the
capabilities it offers helps build strong security in your data center environment.

9-3 Module Lessons

1. Overview of Network Introspection

2. North-South Service Insertion

3. East-West Service Insertion

389
9-4 Lesson 1: Overview of Network
Introspection

9-5 Learner Objectives

• Describe Network Introspection use cases and benefits

• Explain how north-south service insertion works for Network Introspection

• Explain how east-west service insertion works for Network Introspection

• Identify the steps to configure Network Introspection

390
9-6 About Network Introspection
Network Introspection enables third-party services to examine north-south or east-west traffic
and to take appropriate actions.
Partner services provide advanced security features such as IDS/IPS, next-generation firewall,
and URL filtering.

Using the provided framework and APIs, technology partners can integrate their network and
security solutions with NSX-T Data Center.

NSX-T Data Center supports both north-south and east-west service insertion for Network
Introspection.

Service insertion for Network Introspection can be applied on each VM vNIC to check east-west
traffic.

Service insertion for Network Introspection can be applied at Tier-0 and Tier-1 gateways to
check north-south traffic.

Tier-0 gateways connect the virtual and physical networks to provide external connectivity.
Tier-0 gateways also offer gateway services between NSX-T Data Center and the external
networks.

Tier-1 gateways are typically used to connect virtual machines and containers that are attached
to different networks or segments. Tier-1 gateways provide segment interconnection and
separation and offer gateway services to the internal networks or segments. Tier-1 gateways
connect to a Tier-0 gateway for external connectivity.

391
9-7 Network Introspection Benefits
Network introspection has several benefits.

Service insertion for network introspection offers the following benefits:

• Granular Service Insertion: Network Introspection allows a granular approach to network

and security control. Because service insertion is applied per logical router or logical ports,
additional security controls can be used where needed. With the use of rule-based traffic
redirection, partner security controls can be applied to chosen critical applications and
workloads while the NSX native security controls are maintained everywhere.

• Simplified Provisioning: After the partner services are registered with NSX, the services are
present in the NSX Catalog, and service instances can be deployed directly from NSX. NSX
also allows deployments automation when new hosts are added to the cluster.

• Universal Application-Based Policies: As groups used in the redirection rules are shared with
the partner's manager, the NSX groups can be used in policies across all partner appliances.

• Flexible and Scalable Service Chain: Different services might be needed for different
environments or workloads. Network Introspection allows services to be chained together.
The traffic is then automatically forwarded across that chain. Service chains can be applied
to different environments or workloads by using redirection rules.

392
9-8 Network Introspection Use Cases
Inline advanced security controls:
• Using granular traffic redirection

• Available at the perimeter and per workload

• For containers, VMs, bare metal, and cloud

• IDS/IPS, threat prevention, next generation firewall, web filtering, antimalware, and outbreak
prevention

Visibility and analytics:

• Using granular traffic copy

• Available per workload

• For containers and VMs

• Traffic aggregation and distribution of application traffic

• Performance monitoring and security analytics

393
9-9 Overview of North-South Service
Insertion for Network Introspection
The north-south partner security service is typically inserted at the data center perimeter.

• The insertion points are the uplinks of the Tier-0 or Tier-1 gateway.

• A partner service virtual machine (SVM) is deployed close to the NSX Edge node to
process the redirected traffic.

• Any workload behind the Tier-0 and Tier-1 gateways on-premises and in NSX Cloud is
protected.

• Partner services provide advanced security features such as IDS/IPS, next-generation

firewall, and URL filtering.

The L2 north-south insertion mode (also called the Bump in the Wire mode) of the partner
service is supported.

A Service Virtual Machine (SVM) is a virtual appliance provided by the partner service. This
appliance is connected over the service plane to receive redirected traffic.

You can find a complete list of the partner solutions supported for service insertion in NSX-T
Data Center 3.1 in the VMware Compatibility Guide at
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=nsxt&details=1
&releases=538&api=6&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc.

394
9-10 Overview of East-West Service Insertion
for Network Introspection
The east-west partner security service intercepts traffic from a host:

• The insertion points are each guest VM’s vNIC.

• Partner SVMs can be deployed either on compute hosts or in a service cluster.

• The protected workloads are containers and VMs running on ESXi hosts.

• Partner services provide advanced security features such as VM-integrated next-generation

firewall and micro-segmentation.

For SVMs deployed on compute hosts, an SVM does not need to be installed on every host.
Some customers prefer to deploy the partner SVM on each host to achieve the least amount of
traffic hairpinning.

When the partner SVM is deployed in a service cluster, traffic is sent from the compute hosts
across the overlay to the hosts in the service cluster.

395
9-11 Configuring Network Introspection
You can use these high-level steps to configure north-south and east-west Network
Introspection.

Configuring Network Introspection for both east-west and north-south traffic includes the
following high-level steps:

1. Register a service with NSX to make it available to the catalog.

• Partners use the API to register their services with NSX Manager.

2. Deploy instances of a registered service from the NSX UI.

• For north-south service insertion, select the gateway and host to deploy the SVM on.

• For east-west service insertion, choose the number of SVMs to be deployed and the
service plane to which they will connect.

3. Create redirection rules to the partner appliances from the NSX UI.

4. Use the partner service by configuring Next Generation Firewall rules, using additional
services for threat prevention, and so on. These configurations are done through the
Partner Manager.

396
9-12 Review of Learner Objectives
• Describe Network Introspection use cases and benefits
• Explain how north-south service insertion works for Network Introspection

• Explain how east-west service insertion works for Network Introspection

• Identify the steps to configure Network Introspection

397
9-13 Lesson 2: North-South Service Insertion

9-14 Learner Objectives

• Explain the north-south service insertion architecture and components

• Describe the service deployment and consumption workflows for north-south service
insertion

• Configure north-south service insertion

• Explain the packet flows for north-south service insertion

• Troubleshoot north-south service insertion

398
9-15 North-South Service Insertion
Components (1)
The main service insertion components are:

• Partner Service Virtual Machine (SVM):

— Provides the packet processing functionality

— Is deployed as an OVA

• Partner Manager:

— Registers partner services with the NSX catalog

— Manages policies and operations across all SVMs

• NSX Management Cluster:

— Deploys SVMs and creates service segments

— Configures the Service Insertion Classifier based on the redirection rules

An OVA is a file format that supports the exchange of virtual appliances across products and
platforms. It allows to deploy preconfigured VMs or vApps to vCenter Server or the ESXi
inventory.

399
9-16 North-South Service Insertion
Components (2)
• Service segments:

— Are overlay segments automatically created during the partner service deployment

— Are used to interconnect the SVMs and the Tier-0 or Tier-1 gateways

• Service Insertion Classifier

— Intercepts and redirects traffic based on redirection rules

Segments separate networks and provide layer 2 connectivity to their attached VMs and
containers. Overlay segments are used for the communication between transport nodes.
Transport nodes are hypervisors that host VMs which communicate over NSX-T Data Center
segments. An edge node is also considered a transport node.

400
9-17 North-South Service Registration and
Deployment Workflow
To register and deploy a service instance:

1. The partner administrator creates a service definition.

2. The service definition is registered in NSX.

3. The NSX administrator deploys the selected service.

4. NSX Manager deploys the SVMs OVA on the transport node through vCenter Server.

5. Service segments are created automatically.

6. The SVM registers itself with the Partner Manager.

401
9-18 North-South Service Registration
Partners must register their services with NSX-T Data Center by using the API or partner CLI.
After registration, these services are listed under System > Service Deployments > CATALOG.

A partner registers the service with NSX-T Data Center by making an API call or by using the
partner management console (CLI). Partners can automate service registration from their
management console.

In this registration process, several parameters must be specified, including the location (URL) of
the OVF.

For more information, see NSX-T Data Center API Guide at

https://code.vmware.com/apis/1083/nsx-t.

402
9-19 North-South Service Deployment
You deploy the north-south service by navigating to System > Service Deployments >
Deployment.

After a service is registered and appears in the catalog, an instance of the service must be
deployed so that it can start processing network traffic. Each partner releases its own partner
service OVF for NSX-T Data Center integration
Select the north-south service from the drop-down menu.

In north-south service deployments, you must consider the following factors:

• The SVM must be deployed on an ESXi transport node because logical switching is needed
to bridge traffic to the interface where the partner service is attached.

• The partner service instance is typically deployed on the same host as the edge node to
avoid hairpinning situations.

• The deployment mode can be standalone or active-standby. Active-active is not supported

for the SVM.

• Each SVM can only be applied to one gateway.

The deployment process might take some time, depending on the vendor's implementation. The
deployment and operational status are monitored.

After the deployment is successful, you can verify that the SVMs were deployed by navigating
to System > Service Deployments > Service Instances.

403
9-20 Service Segments for North-South traffic
Service segments are automatically created during the service deployment:
• Two overlay segments are created per service:

— Untrusted segment

— Trusted segment

• The SVM is attached to the two service segments.

• Two ports are created on the Tier-1 or Tier-0 gateway. One port connects to the untrusted
segment and the other port connects to the trusted segment.

A third HA segment can be optionally created in active-standby SVM deployments.

404
9-21 North-South Service Consumption
Workflow
To consume a service instance:

1. The partner administrator configures the partner policy from the Partner Manager. This
policy is applied to all SVMs.

2. The NSX administrator configures the redirection policy and rules from the NSX UI.
Redirection rules are applied to the SI Classifier.

405
9-22 North-South Service Insertion Rules
Service insertion or redirection rules define the type of traffic that is forwarded to the Partner
SVM:
• Redirection rules are applied to the SI Classifier on the Tier-1 or Tier-0 uplink.

• The two available actions are: Redirect and Do Not Redirect.

• Redirection rules are stateless by default, but can be configured as stateful at the policy
level.

Reflexive rules are automatically created with stateless redirection rules.

• The Redirect action has associated metadata that defines the next hop IP address for the
redirected traffic.

Name Source Destination Service Redirect to Action

External [External] [Production ANY [SVM] REDIRECT

Access Segment]

Internal Users [Internal Users] [Production ANY [SVM] DO NOT

Segment] REDIRECT

406
9-23 Configuring Redirection Policies for
North-South Network Introspection
Redirection policies for north-south traffic must be configured to determine the type of traffic
redirected to the partner service.

You configure redirection policies for north-south traffic to determine the type of traffic
redirected to the partner service. Configuring traffic redirection is similar to configuring a firewall.
You can define detailed redirection rules, which identify the traffic that should be inspected by
the partner services. You can create selective redirection rules by using security groups.

407
9-24 North-South SI Classifier
The SI Classifier intercepts and redirects traffic based on the redirection rules:
• The SI Classifier is applied to the uplink of the Tier-0 or Tier-1 gateway.

• The redirect action of the service insertion rule determines the next-hop IP address for the
traffic:

— For north-south traffic, the next-hop IP address is the Untrusted interface.

— For south-north traffic, the next-hop IP address is the Trusted interface.

• Traffic is sent from the Untrusted or Trusted interface of the Tier0/Tier1 gateway to the
Partner SVM in a Bump in the wire mode.

Bump in the wire mode is also called transparent firewall. A transparent firewall allows to filter
traffic between hosts within the same subnet, instead of between subnets.

408
9-25 North-South Packet Flow
A north-south incoming packet is processed as follows:
1. The packet is received on the Tier0/Tier1 gateway uplink and matches a service insertion
rule.

2. The packet is redirected to the untrusted interface of the Tier0/Tier1 gateway.

3. The packet reaches the SVM on its untrusted interface and the SVM relays the packet on its
trusted interface.

4. The packet ingresses through the trusted interface of the Tier0/Tier1 gateway.

5. The packet is processed through regular L3 routing.

A north-south incoming packet is processed as follows:

1. The packet is received on the uplink of the Tier0/Tier1 gateway and goes through the
service pipeline IPSec, DNAT, and firewall. The packet then matches a service insertion rule.

2. Based on the REDIRECT action of the service insertion rule and its associated metadata, the
next-hop IP address information is retrieved, and the packet is redirected to the untrusted
interface.

3. The packet reaches the SVM on its untrusted interface. The SVM then relays the packet on
its trusted interface.

4. The packet ingresses through the trusted interface of the Tier0/Tier1 gateway. The packet
is marked with a flag indicating that it has already traversed the partner SVM.

5. The packet is processed through regular L3 routing.

409
9-26 South-North Packet Flow
A south-north incoming packet is processed as follows:
1. The packet is received on the downlink of the Tier0/Tier1 gateway, goes through L3
routing, and egresses through the uplink.

2. The packet matches a service insertion rule.

3. The packet is redirected to the trusted interface of the gateway.

4. The packet reaches the SVM on its trusted interface and the SVM relays the packet on its
untrusted interface.

5. The packet ingresses through the untrusted interface of the Tier0/Tier1 gateway.

6. The packet is processed through regular L3 routing.

After regular L3 routing is performed, the packet goes to the following service pipeline Firewall,
SNAT, and IPSec.

410
9-27 Log Files for Troubleshooting North-
South Service Insertion
Service Deployment Packet Logs

NSX Manager: NSX Edge:

• /var/log/policy/policy.log • /var/log/syslog
• /var/log/proton/nsxapi.log
• /var/log/cm-inventory/cm-
inventory.log

Sample log entry from /var/log/syslog:

NSX 2186 FIREWALL [nsx@6876 comp="nsx-edge"

subcomp="datapathd.firewallpkt" level="INFO"]
<5e9c4f966c044e3a:b6a30881158ab25e> INET reason-match PBR 2052
OUT 84 PROTO 1 1.1.3.10->2.1.4.1
The sample log file from NSX Edge illustrates a match for a north-south service insertion rule
with id 2052. As part of the log, you can also observe the IP to which the traffic is to be
redirected, which is 2.1.4.1 in the example.

411
9-28 North-South Service Insertion
Troubleshooting Flowchart
Follow these steps for troubleshooting north-south service insertion.

You can check the configuration maximums for north-south service insertion in VMware
Configuration Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=34-59,34-
61,34-62.

You can also check configuration maximums directly in the NSX UI by navigating to Security >
Security Overview > Capacity.

412
9-29 Review of Learner Objectives
• Explain the north-south service insertion architecture and components
• Describe the service deployment and consumption workflows for north-south service
insertion

• Configure north-south service insertion

• Explain the packet flows for north-south service insertion

• Troubleshoot north-south service insertion

413
9-30 Lesson 3: East-West Service Insertion

9-31 Learner Objectives

• Explain the east-west service insertion architecture and components

• Describe the service deployment and consumption workflows for east-west service
insertion

• Configure east-west service insertion

• Explain the packet flows for east-west service insertion

• Troubleshoot east-west service insertion

414
9-32 East-West Service Insertion Components
(1)
The components for east-west service insertion:

• Partner Service Virtual Machine (SVM):

— Provides the packet processing functionality and it is deployed as an OVA.

• Partner Manager:

— Registers partner services with NSX

— Manages service policies and vendor templates

• NSX Management Cluster:

— Deploys SVMs and creates the service segment

— Configures the Service Insertion Classifier based on the redirection rules

415
9-33 East-West Service Insertion Components
(2)
• Service segment:
— Is an overlay segment
— Automatically created during the partner service deployment
— Used to interconnect the SVMs and the guest VMs
• Service Insertion Classifier:
— Intercepts traffic after it passes through the distributed firewall
— Redirects packets to the service segment
• Service Proxy:
— Resides in front of every SVM
— Performs protocol conversion between the service segment and the local circuit of the
SVM

Service proxy either redirects original packet or delivers a copy to the SVM. The chosen action
is configured by the partner in the partner template during the service registration.

The redirect action is used for inline security use cases, and the copy action is used for
monitoring use cases.
416
9-34 East-West Service Registration and
Deployment Workflow
To register and deploy a service instance:

1. The partner administrator creates a service definition.

2. The service definition is registered in NSX.

3. The NSX administrator deploys the selected service.

4. NSX Manager deploys the SVM OVA on the transport node through vCenter Server.

5. Service segments are created automatically.

6. The SVM registers itself with the Partner Manager.

417
9-35 East-West Service Registration
Partners must register their services with NSX-T Data Center by using the API or partner CLI.
After registration, these services are listed under System > Service Deployments > CATALOG.

Like the north-south service insertion, a service must first be registered with NSX for east-west
service insertion.

See NSX-T Data Center API Guide at https://code.vmware.com/apis/1083/nsx-t.

418
9-36 East-West Deployment Modes
Two deployment options are available for the SVM.

In a host-based deployment (distributed mode), the SVMs are deployed on every single host in
the compute cluster.

In a cluster-mode deployment (centralized mode), a desired number of SVMs are deployed on a

dedicated cluster. The traffic is redirected to the SVMs over the overlay network.

419
9-37 East-West Service Deployment
You deploy the east-west service by navigating to System > Service Deployments >
Deployment.

After a service is registered, an instance of the service must be deployed so that it can start
processing network traffic.
Select the east-west service from the drop-down menu.

In east-west deployments, you must consider the following factors:

• Specify the service segments that the VMs use for east-west network traffic protection.

• Specify the SVM deployment type (host-based or cluster-based):

— If cluster-based is selected, you must specify the number of SVMs to be deployed.

The deployment process might take some time, depending on the vendor's implementation. The
deployment and operational status are monitored.

After the deployment is successful, you can confirm that the SVMs have been deployed by
navigating to System > Service Deployments > Service Instances.

420
9-38 East-West Service Consumption
Workflow
To consume a service instance:

1. The partner administrator configures the partner policy from the Partner Manager. This
policy is applied to all SVMs.

2. The NSX administrator configures the service profiles, the service chains, the redirection
policy, and rules from the NSX UI. Redirection rules are applied to the SI Classifier.

421
9-39 Service Profiles and Service Chains
A service profile is a specific instantiation or customization of a vendor template.
A service chain specifies the sequence of service profiles applied to the network traffic.

A service profile is a specific instantiation or customization of a vendor template. You can create
multiple service profiles based on the needs of your environment and workloads. For example,
you can create one service profile for next-generation firewall, one service profile for IPS, and
one service profile for network monitoring.

You can specify one or more service profiles in a service chain and determine the order in which
the traffic should be processed. For example, the traffic should be first analyzed by the next-
generation firewall, followed by IPS, and finally processed by the network monitoring service
profile.

Since NSX-T Data Center 3.0, you can also use east-west service chaining for north-south
traffic. The traffic at the uplink of the NSX Edge node is intercepted and redirected to the same
service chains configured for east-west service insertion.

422
9-40 Creating Service Profiles
You create Service Profiles by navigating to Security > Network Introspection Settings >
Service Profiles.

A service profile is a specific instantiation or customization of a vendor template. For example, if

a vendor template defines an IPSec tunneling operation, a service profile specifies details such as
IPSec tunnel endpoints, algorithms, and so on. You can create multiple service profiles, for
example, one for IPS and one for a next-generation firewall.

Service profiles can also be registered by the partner during the service registration.

423
9-41 Creating Service Chains
After you create service profiles, you can create service chains.

A service chain is a sequence of service profiles defined by the network administrator. A service
chain defines the logical sequence of operations to be applied to network traffic, for example,
firewall, then monitor, and then IPSec VPN. Service chains can specify different sequences of
service profiles for different directions of traffic (egress or ingress).

You can create one or more service profiles in a service chain. In most of our customer's
environments, only one service profile is configured in a service chain. However, if a requirement
arises for tight security, more service profiles can be added.

Service chains can specify different sequences of services profiles for different directions of
traffic (egress/ingress).

424
9-42 East-West Service Insertion Rules
The east-west service insertion rules have the following characteristics:
• The service chain is configured at the policy level. Each policy can be only configured with a
service chain.

• Redirection rules are applied to a group or the distributed firewall.

• Redirection rules are stateful, by default, but can be configured as stateless at the policy
level. Reflexive rules are not created automatically.

Redirect To: Restricted Service Chain

Name Source Destination Service Applied To Action

From [Restricted] ANY ANY [Restricted] REDIRECT

Restricted

To Restricted ANY [Restricted] ANY [Restricted] REDIRECT

Intra Restricted [Restricted] [Restricted] ANY [Restricted] REDIRECT

Restricted Service Chain NGFW IPS NETMON

425
9-43 Configuring Redirection Policies for East-
West Network Introspection
Redirection policies for north-south and east-west traffic must be configured to determine the
type of traffic redirected to the partner service.

A redirection policy is a construct that specifies traffic matching patterns (based on NSX-T Data
Center security groups) and a service chain. All traffic matching the pattern is redirected along
the service chain.

You configure redirection policies for east-west traffic to determine the type of traffic
redirected to the partner service.

All traffic matching a redirection rule is redirected along the specified service chain.

426
9-44 East-West SI Classifier
East-west redirection rules are applied to the SI Classifier. The SI Classifier has the following
characteristics:
• Resides at the vNIC of the virtual machine.

• Intercepts traffic after it has been allowed by the DFW filter.

• Packets matched against the redirection rules in the SI classifier are diverted to the service
segment.

Service Insertion Classifier is implemented in the traffic path as a dvFilter.

427
9-45 Service Path
A service path is the data plane realization of a service chain:
• Possible service paths for a service chain are determined by NSX Manager and distributed
to the data plane through CCP.
• Each service path is identified by a Service Path Index (SPI).
• The path selection depends on the type of deployment: clustered or host-based.
• If the preferred path fails, another path can be used as an alternative.

In a host-based deployment, the following criteria are used to determine the preferred path or
paths:
• Use all SVMs at least once.
• Do not use cross-host bandwidth unless needed.
• Minimize latency and maximize throughput by punting traffic to local services.
• A locality counter is maintained per path, indicating the number of local services in the path.
Paths with a higher locality counter are preferred.
In a clustered deployment the following criteria are used to determine the preferred path or
paths:
• Use all SVMs at least once.
• Minimize the amount of cross-host traffic in the service cluster.
• A crossing counter, indicating the number of times the traffic must cross between hosts, is
maintained per path. Paths with a lower crossing counter are preferred.
428
9-46 Service Proxy
The Service Proxy resides in front of each SVM and performs protocol conversion between the
service segment and the local circuit of the SVM:
1. The TEP of the transport node decapsulates the Geneve packet.

2. The packet arrives to the Service Proxy through the service segment without a Geneve
header.

3. The Service Proxy encapsulates the packet with the Geneve protocol and sends it on the
local circuit.

429
9-47 East-West Packet Flow (1)
The following packet flow occurs between the guest VM and the SVM:
1. As the packet egresses the guest VM, the SI Classifier matches it against the redirection
rules.

2. The SI Classifier selects a service path.

3. The packet is sent over the overlay service segment.

4. The packet passes through the service proxy and is handed off to the SVM.

The traffic flow is the same regardless of the deployment mode. A TEP is needed on the
transport node for the service segment even if the SVM is in the same compute node as the
guest VM.

430
9-48 East-West Packet Flow (2)
The following packet flow occurs between the SVM and the guest VM:
1. The SVM returns the traffic.

2. The Service Proxy looks up the next hop and sends it either to the Guest VM or the next
SVM (if it is a part of a service chain).

3. The packet is sent across the overlay service segment to the original source.

4. The SI Classifier of the original source guest VM receives the packet and sends it to the
routing component.

5. The original packet is switched to the destination by using the normal network path.

431
9-49 Log Files for Troubleshooting East-West
Network Introspection
Service Deployment Packet Logs

NSX Manager: ESXi host:

• /var/log/policy/policy.log • /var/log/dfwpktlogs.log
• /var/log/proton/nsxapi.log
• /var/log/cm-inventory/cm-
inventory.log

Sample log entry from /var/log/dfwpktlogs.log:

89598508 INET match PBR 1026 OUT 84 ICMP 10.10.10.1-

>10.10.10.3 FG 0 SFG 0 FID 638058624 SCID 1 V 1 FA 2 |FWD:
00:50:56:96:2f:f8 SI 1 SPI 25 TTL 2 |REV 00:50:56:96:2f:f8 SI
1 SPI 26 TTL
89598508 INET TERM 1026 OUT ICMP 8 0 10.10.10.1->10.10.10.3
24/24 2016/2016
The log extract shows a match for an east-west redirection rule with ID 1026. Such rule redirects
traffic using a Service Chain with identifier 1 (SCID=1).

432
9-50 East-West Network Introspection
Troubleshooting Flowchart
Follow these steps for troubleshooting east-west service insertion.

For the configuration maximums for east-west service insertion, see VMware Configuration
Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=34-59,34-63.

You can also check configuration maximums directly in the NSX UI by navigating to Security >
Security Overview > Capacity.

433
9-51 Knowledge Check: Network
Introspection
Go to https://via.vmw.com/KC6 to answer questions about this content.

434
9-52 Review of Learner Objectives
• Explain the east-west service insertion architecture and components
• Describe the service deployment and consumption workflows for east-west service
insertion

• Configure east-west service insertion

• Explain the packet flows for east-west service insertion

• Troubleshoot east-west service insertion

435
9-53 Key Points
• Network Introspection enables third-party services to examine network traffic passing
through a gateway and to take appropriate actions.
• NSX-T Data Center supports both north-south and east-west service insertion for Network
Introspection.

• North-south service insertion for Network Introspection intercepts traffic on the Tier-0 and
Tier-1 uplinks.
• East-west service insertion for Network Introspection intercepts workloads running on ESXi
hosts at the vNIC.

• A service profile is a specific instantiation or customization of a vendor template.

• A service chain specifies the sequence of service profiles applied to network traffic.

436
437
Module 10
Endpoint Protection

10-2 Importance
NSX-T Data Center includes an Endpoint Protection feature to offer antivirus and antimalware
capabilities to partners. Understanding Endpoint Protection, how to configure it, and the
capabilities that it offers helps build strong security in your data center environment.

10-3 Module Lessons

1. Overview of Endpoint Protection

2. Endpoint Protection Architecture and Troubleshooting

439
10-4 Lesson 1: Overview of Endpoint
Protection

10-5 Learner Objectives

• Describe Endpoint Protection and its use cases

• Configure Endpoint Protection

440
10-6 About Endpoint Protection
Endpoint Protection is a platform for partner integration for agentless antivirus and antimalware
functionality.
Endpoint Protection provides visibility into in-guest events by analyzing the OS and file data.

For a complete list of the partner solutions supported for Endpoint Protection in NSX-T Data
Center 3.1, see the VMware Compatibility Guide at
https://www.vmware.com/resources/compatibility/search.php?deviceCategory=nsxt&details=1
&releases=538&api=5&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc.

Endpoint Protection is also called Guest Introspection.

441
10-7 Use Cases for Endpoint Protection
NSX-T Data Center supports the following use cases for Endpoint Protection:
• Integration and offloading to third-party services

• Policy-based agentless antivirus and antimalware protection

• Protection for Windows and Linux workloads running on vSphere

442
10-8 Endpoint Protection Process
The Endpoint Protection process has the following steps:
1. Modules for Endpoint Protection are installed on hosts as part of host preparation.

2. The partner’s integrated service is deployed as an SVM.

3. The administrator defines Endpoint Protection policies for the VMs.

4. The partner SVM uses the Endpoint Protection API library to introspect and protect guest
VMs from malware.

As part of host preparation, NSX-T Data Center distributes Endpoint Protection modules to all
hosts in a cluster. An NSX-T Transport Node Profile is required for Endpoint Protection to
ensure that NSX is deployed on any new host added to the cluster.
The integrated service is deployed as a virtual appliance running partner services, also called a
service virtual machine (SVM).

The administrator defines Endpoint Protection policies for the VMs.

The integrated service uses the Endpoint Protection API library (formerly known as EPSec API
library) to introspect and protect guest VMs from malware.

Because Endpoint Protection enables SVMs to read and write specific files on guest VMs, it
provides an efficient way to optimize memory use and avoid resource bottlenecks.

443
10-9 Automatic Policy Enforcement for New
VMs
Endpoint Protection policies are automatically applied and enforced when a new VM is added.

Automatic policy enforcement follows these steps:

1. A new ESXi host is added to the cluster.

2. NSX-T Data Center automatically deploys the Endpoint Protection framework and SVMs.

3. When a new guest VM comes online on the new host, appropriate security policies are
applied.

4. The security policies follow the VM even when the VM migrates (through vSphere vMotion).

444
10-10 Automated Virus or Malware Quarantine
with Tags Example (1)
Endpoint Protection policies and tags can be used to automatically quarantine compromised
workloads.

In the example, all VMs are part of the Standard group.

Two endpoint policies were set up (Standard and Quarantine).

Two distributed firewall policies were also set up (Standard, Quarantine).

The antivirus SVM monitors activities on the guest of the VMs in the Standard group.

If malicious activities are detected, the ANTI_VIRUS.VirusFound tag is set for that VM.

445
10-11 Automated Virus or Malware Quarantine
with Tags Example (2)
The ANTI_VIRUS.VirusFound tag places the VMs that are virus-infected in the
Quarantine group, where the Quarantine endpoint and distributed firewall policy are enforced.

In the example, the Quarantine distributed firewall policy blocks all inbound and outbound traffic
except the necessary security tools.

446
10-12 Automated Virus or Malware Quarantine
with Tags Example (3)
After remediation, VMs are scanned again. If no virus is found, the
ANTI_VIRUS.Virusfound tag is removed and the traffic flow to and from the VMs
resumes.

The VMs are removed from the Quarantine group, eliminating the Quarantine policies. Traffic
flow to and from the VMs resumes.

This process prevents the spread of the virus to other VMs. This entire process is automated
and does not require manual intervention.

447
10-13 Creating a Service Profile for Endpoint
Protection
The Endpoint Protection service profiles define the level of protection for a group of workloads.

Service profiles are created from a template provided by the partner.

Select the Partner Service that has

been previously registered.

Service profiles enable administrators to choose protection levels for a VM by selecting the
templates provided by the vendor. For example, a vendor can provide silver, gold, and platinum
policy levels.

Each profile that is created might serve a different type of workload. A gold service profile
provides complete antimalware to a PCI-type workload, whereas a silver service profile only
provides basic antimalware protection to a regular workload.

448
10-14 Configuring Endpoint Protection Rules
Administrators can create rules to associate a service profile to a specific VM or group of VMs.

When a rule is applied to a group of VMs, Service profiles enable you to protect
all guest VMs within the group are workloads using security services
protected by the selected service profile. provided by partners.

449
10-15 Review of Learner Objectives
• Describe Endpoint Protection and its use cases
• Configure Endpoint Protection

450
10-16 Lesson 2: Endpoint Protection
Architecture and Troubleshooting

10-17 Learner Objectives

• Explain the Endpoint Protection architecture and components

• Describe the service deployment and consumption workflows for Endpoint Protection

• Troubleshoot Endpoint Protection

451
10-18 Endpoint Protection Components (1)
The main Endpoint Protection components are:
• Partner Manager

— Registers partner services with vCenter Server and NSX Manager.

• NSX Management Cluster

— Provides the API and UI interface to deploy and manage partner appliances.

— Allows administrators to create endpoint service profiles and protection policies.

• ESXi Agent Manager (EAM)

— NSX Manager uses the ESXi Agent Manager (EAM) component in vCenter Server to
deploy the partner service VM on every host of the cluster configured for Endpoint
Protection.

452
10-19 Endpoint Protection Components (2)
• Partner Service Virtual Machine (SVM):
— Is deployed as an OVA.
— Receives Endpoint Protection events and data through the GI library, and scans files or
processes events to detect malware and viruses.
• Guest Virtual Machine (GVM):
— Runs a file or network introspection lightweight agent, called the Thin Agent, which
offloads files and processes for scanning to the SVM based on the configured Endpoint
Protection policy.
— The Thin Agent can be installed on Windows and Linux guests.

In Windows operating systems, the Thin Agent is installed as part of VMware Tools.

In Linux operating systems, the Thin Agent is a separate package that can be downloaded from
the VMware web page and it does not require open-vm-tools.

For information about the guest operating systems supported for Endpoint Protection, see
NSX-T 3.1 Data Center Administration Guide at https://docs.vmware.com/en/VMware-NSX-T-
Data-Center/3.1/administration/GUID-1983D27F-19F9-4689-91DF-C63446D3288B.html.
453
10-20 Endpoint Protection Components (3)
• NSX Proxy:
— Receives configuration from NSX Manager and configures the data plane.

• Context Multiplexer (MUX)

— Maintains the SVM configuration.

— Relays messages between the guest VMs and the SVM.

— Processes Endpoint Protection policies.

— Reports the health status for Endpoint Protection.

The Context Multiplexer or MUX is installed as VIB during the transport node preparation.

MUX uses the muxconfig.xml file to record the SVM configuration details.

MUX communicates with the Thin Agent on the guest VM over a fast channel, called Virtual
Machine Communication Interface (VMCI), and uses TCP/IP to relay messages to the GI library in
the partner SVM.

454
10-21 Service Registration and Deployment
Workflow
The steps to register and deploy a service instance are as follows:

1. The NSX administrator installs a Thin Agent on every Guest VM.

2. The partner administrator registers the partner service with vCenter Server and NSX-T
Data Center from the Partner Manager.

3. The NSX administrator deploys the partner service from the NSX UI.

4. NSX Manager uses the EAM component in vCenter Server to deploy the partner service
VM on each host of the cluster.

5. After SVMs are deployed, NSX Manager sends the SVM configuration to MUX.

6. The MUX establishes communication with the guest introspection library on the SVM.

After SVMs are deployed, NSX Manager sends the SVM configuration to MUX. MUX stores the
SVM configuration details in the muxconfig.xml file, and it uses these details to establish the
connection with the SVM for the first time. Any future configuration changes in the SVM are also
captured in this file.

455
10-22 Service Consumption Workflow
The steps to consume Endpoint Protection are as follows:
1. The NSX administrator creates endpoint service profiles and rules.

2. NSX Manager passes the configuration to the CCP, which publishes it to the transport node.

3. The transport node receives the configuration information through the NSX Proxy and
forwards the Endpoint Protection configuration to MUX.

4. MUX processes the endpoint policies and rules to protect the guest VMs.

Endpoint service profiles specify the protection level for the guest VMs.

Endpoint Protection rules associate VM groups with the service profiles.

456
10-23 Verifying the Thin Agent Installation in
Windows
In Windows operating systems, the Thin Agent is installed as part of VMware Tools. The full
installation of VMware tools includes the following drivers:

• NSX Network Introspection (vnetWFP.sys)

• NSX File Introspection (vsepflt.sys)

• VMCI (vsock.sys)

All drivers can be found in the following C:\Windows\system32\drivers folder.

NSX Network Introspection Driver

NSX File Introspection Driver

For a list of supported Windows version, see NSX-T Data Center Administration Guide at
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-
1983D27F-19F9-4689-91DF-C63446D3288B.html.
In earlier versions of Windows, the NSX Network Introspection driver (vnetWFP.sys) is
vnetflt.sys.

457
10-24 Verifying the Thin Agent Installation in
Linux
In Linux operating systems the Thin Agent does not require open-vm-tools and is installed as a
separate package.

Run the following command to verify that the Thin Agent is running:

service vsepd status

The Thin Agent information is logged in the /var/log/syslog.log file.

In Linux operating systems, the Thin Agent is a separate package that can be download from
the VMware web page, and it does not require open-vm-tools.

GLib 2.0 must also be installed on the Linux VM.

For all the Linux supported versions, see NSX-T Data Center Administration Guide at
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-
1983D27F-19F9-4689-91DF-C63446D3288B.html.

458
10-25 Verifying the MUX Backend
Run the following command to verify that the VIB for MUX is installed on the ESXi host:
[root@sa-esxi-04:~] esxcli software vib list | grep mux
nsx-context-mux 3.1.0.0.0-7.0.17107169 VMware VMwareCertified
2020-10-31
This extract of /var/log/syslog.log shows the initialization of MUX on the ESXi host:

nsx-context-mux: nsx-context-mux started

[INFO](EPSEC)[265006] NSX Context Multiplexor (null).
[MUX_VERSION_STRING]
[INFO](EPSEC)[265006] VMkernel sa-esxi-04.vclass.local 7.0.0
#1 SMP Release build-15843807 x86_64
[WARNING](EPSEC)[265009] Not sending events. MuxHandler has
not been registered.
[INFO](EPSEC)[265006] Creating default muxconfig.xml file at
MUX start with Solution 100 entry
...
[INFO](EPSEC)[265006] MuxSolutionHandler[0x95466eae70]
connected to solution[100] at [0.0.0.0:/tmp/48656]

459
10-26 Reviewing the Default muxconfig.xml File
MUX uses the muxconfig.xml file to record the SVM configuration details:
• The muxconfig.xml file is automatically created during the transport node preparation.

• It can be located on the ESXi host at /var/run/muxconfig.xml.

• It is automatically updated when partner solutions are added.

• Manual changes to this file are not supported and are overwritten by NSX Manager.

The screenshot shows a sample output of the muxconfig.xml file when no partner services
are deployed in the environment.

460
10-27 Verifying the ESXi Firewall
A firewall ruleset is automatically created on the ESXi host to allow communications between
MUX and the partner SVM:
• It can be located at /etc/vmware/firewall/Mux-Ruleset.xml.

• It opens TCP ports 48651 through 48666.

TCP ports 48651

through 48666 are
opened between the
ESXi host and the
SVM.

461
10-28 Verifying the Partner Service Registration
Review the /var/run/proton/nsxapi.log log file on NSX Manager to validate the
partner service registration:
• Service definition:

SERVICE-INSERTION [nsx@6876 comp="nsx-manager"

subcomp="manager"] Successfully created ServiceDefinition
with id : 38f7c31c-546e-4127-ab30-d5a0774fe1bb and name :
anti-malware solution
• Vendor template creation:

SERVICE-INSERTION [nsx@6876 comp="nsx-manager"

subcomp="manager"] Successfully created ServiceDefinition
with id : 38f7c31c-546e-4127-ab30-d5a0774fe1bb and name :
anti-malware solution
• Service registration:

SERVICE-INSERTION [nsx@6876 comp="nsx-manager"

subcomp="manager"] API registerServiceManager : Time taken
to register service manager with name anti-malware is 332 ms

462
10-29 Verifying the SVM Deployment from the
NSX UI
You can check the SVM deployment by navigating to System > Service Deployments >
Deployment.

The deployment status of each service instance also appears in the NSX UI.

The Health Status appears as Down until at least

463
10-30 Verifying the SVM Deployment from the
vSphere Client
You can also verify the SVM deployment from the vSphere Client.

The ESX Agents resource

pool is automatically created
An SVM is deployed on for the SVMs.
each host of the cluster.

464
10-31 Verifying the SVM deployment from the
Log Files
You can review SVM deployment events using these log files:

• NSX Manager: /var/run/cm-inventory/cm-inventory.log

• vCenter Server: /var/log/vmware/eam/eam.log

OVF template deployment:

INFO http-nio-127.0.0.1-7440-exec-1 DeploymentUnitServiceImpl

- FABRIC [nsx@6876 comp="nsx-manager" subcomp="manager"] [GI]:
Configuration would be created using vcDeploymentConfig
INFO http-nio-127.0.0.1-7440-exec-1 DeploymentUnitServiceImpl
- FABRIC [nsx@6876 comp="nsx-manager" subcomp="manager"]
Deployment configuration for version 1.0.0.3784
...
Resource pool creation:

INFO InventoryFetcher InventoryFetcher - SYSTEM [nsx@6876

comp="nsx-manager" subcomp="Fabric"] ResourcePool added on
cmId 9704633c-f8f5-493f-bcd4-1a18dfac0999 -> ResourcePool
[id=resgroup-182, name=ESX Agents, parent=resgroup-33,
owner=domain-c32]

465
10-32 Verifying the SVM Networking from the
vSphere Client
A standard virtual switch called vmservice-vswitch is created during the SVM deployment with
the following port groups:

• vmservice-vmknic-pg is a VMkernel port group used to connect the MUX. The MUX
VMkernel interface has an IP of 169.254.1.2, which cannot be modified.

• vmservice-vshield-pg is a virtual machine port group used to connect the partner SVM.

A standard vswitch named vmservice-vswitch is created during the SVM deployment. This
standard switch does not have any physical NICs attached. The vswitch is used for internal
communication between the ESXi host and the SVM.

466
10-33 Verifying the SVM Networking from the
CLI
Run the following command to retrieve the IP address and the vmkernel interface assigned to
MUX:

[root@sa-esxi-04:~] esxcli network ip interface ipv4 get

Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type
---- ------------ ------------- -------------- ----------
vmk1 169.254.1.2 255.255.255.0 169.254.1.255 STATIC
Run the following command to validate the connectivity between MUX and the SVM:

[root@sa-esxi-04:~] esxcli network ip connection list | grep

mux
tcp 0 0 169.254.1.2:24783 169.254.1.64:48652 ESTABLISHED
3089447 newreno nsx-context-mux

467
10-34 Verifying the EAM Agency Creation from
the vSphere Client
NSX Manager uses the EAM component in vCenter Server to deploy the partner service VM on
each host of the cluster:

• An EAM Agency is created per cluster.

• EAM installs an NSX Agent on each host to help with agentless offload capabilities.

Endpoint Protection in NSX Data Center for vSphere requires a separate Endpoint Protection
service virtual appliance to help with agentless offload capabilities in addition to the partner SVM
per host. In NSX-T Data Center, the components of the Endpoint Protection service virtual
appliance are moved to the NSX Agent installation to simplify the overall architecture and
reduce the number of service virtual appliances needed for Endpoint Protection to only one
partner appliance per host. The reduction of the number of service virtual appliances to run
Endpoint Protection means less server downtime and possible interruption during deployments
and upgrades.

468
10-35 Verifying the EAM Agency Creation and
Agent Installation from the Log Files
You can review the /var/log/eam/eam.log log file from vCenter Server to troubleshoot
EAM events:

• EAM agency creation:

INFO | vlsi | EsxAgentManagerImpl.java | 376 | Creating

agency:eam.Agency.ConfigInfo {agencyName = '_NSXT_9704633c-
f8f5-493f-bcd4-1a18dfac0999_domain-c32', ...
• NSX agent deployment:

INFO | host-42-0 | DeployVmJob.java | 622 | Deploying agent

on host esxi4.corp.local ( host-42) with name anti-malware
SVA (1)

469
10-36 Reviewing the muxconfig.xml File After
Adding Partner Solutions
The muxconfig.xml file is automatically modified after the SVM deployment.

The solution ID and IP

address of the SVM.

UUIDs of the VMs protected

by Endpoint Protection.

470
10-37 Log Files for Troubleshooting Endpoint
Protection
The table includes a summary of useful log files and locations.

Component Log Location

Thin Agent (Guest VM) vmware.log

GI Library (Partner /var/log/syslog

SVM)
/var/log/messages

MUX (ESXi) /var/log/syslog

NSX Manager /var/log/proton/nsxapi.log

/var/log/cm-inventory/cm-inventory.log

EAM (vCenter Server) /var/log/vmware/eam/eam.log

471
10-38 Endpoint Protection Troubleshooting
Flowchart
Follow these steps for troubleshooting Guest Introspection.

For information about configuration maximums for Endpoint Protection (Guest Introspection),
see VMware Configuration Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=22-0.

472
10-39 Knowledge Check: Endpoint Protection
Go to https://via.vmw.com/KC7 to answer questions about this content.

473
10-40 Review of Learner Objectives
• Explain the Endpoint Protection architecture and components
• Describe the service deployment and consumption workflows for Endpoint Protection

• Troubleshoot Endpoint Protection

474
10-41 Key Points
• Endpoint Protection provides visibility into in-guest events by analyzing the OS and file data,
and offers antivirus and antimalware capabilities.
• Endpoint Protection policies are automatically applied and enforced when a new VM is
added.

• NSX Manager uses the ESXi Agent Manager (EAM) component in vCenter Server to deploy
the partner service VM on every host of the cluster configured for Endpoint Protection.
• The Guest VMs run a file or network introspection lightweight agent, called the Thin Agent.
The Thin Agent offloads files and processes for scanning to the SVM based on the
configured Endpoint Protection policy.

Questions?

475
Module 11
Advanced Threat Prevention

11-2 Importance
NSX Distributed IDS/IPS and NSX Network Detection and Response provide visibility and
protection against advanced threats in your network. As a security administrator, you must learn
to properly configure these features to successfully prevent malicious attacks against your
environment.

11-3 Module Lessons

1. Introduction to the MITRE ATT&CK Framework

2. Distributed Intrusion Detection and Prevention

3. Troubleshooting NSX Distributed IDS/IPS

4. NSX Network Detection and Response

11-4 Lesson 1: Introduction to the MITRE
ATT&CK Framework

11-5 Learner Objectives

• Define cyber attacks, their motivations, and targets

• Describe the MITRE ATT&CK framework

• Explain the different phases of a cyber attack

• Describe the use of NSX security solutions to protect against cyber attacks

477
11-6 About Cyber Attacks
A cyber attack is a malicious and deliberate attempt to breach the information system of an
individual or organization.
Common types of cyber attacks include:
• Malware
• Phishing
• Man-in-the-middle attacks
• Denial-of-service attacks
• SQL injection
• Zero-day exploits
• DNS tunneling

Cyber attacks might be of the following types:

• Malware is the term used to describe malicious software, including spyware, ransomware,
viruses, and worms.
• Phishing is the practice of sending fraudulent communications that appear to come from a
reputable source, usually through email. The goal is to steal sensitive data such as credit
card and login information, or to install malware on the victim's machine.
• Man-in-the-middle attacks occur when attackers interrupt the traffic between two systems
to filter and steal data. Unsecure public Wi-Fi is often used as entry point for man-in-the-
middle attacks.
• A denial-of-service attack floods systems, servers, or networks with traffic to exhaust
resources and bandwidth. As a result, the system is unable to fulfill legitimate requests.
• A Structured Query Language (SQL) injection occurs when an attacker inserts malicious
code into a server that uses SQL and forces the server to reveal information that it normally
would not.
• A zero-day exploit occurs after a network vulnerability is announced but before a patch or
solution is implemented. Attackers target the disclosed vulnerability during this window of
time.
• DNS tunneling manipulates DNS requests and responses to implement a command and
control channel for malware or to exfiltrate data.

478
11-7 Common Cyber Attackers Motivations
Cyber attackers are often motivated by financial gain or the desire to obtain confidential
information. Some common practices include:

• Encrypt files and demand ransom.

• Steal online credentials to withdraw funds or make unauthorized purchases.

• Steal information to gain advantage over competitors or to sell it on the dark web.

• Intelligence gathering for economic, political, or military advantage.

479
11-8 Common Cyber Attacker Targets
Cyber attackers often use the following vulnerabilities to exploit computer systems:

• Human errors

• Poor software development practices

• New threat vectors

• Perimeter-centric approaches

Humans continue to be the weakest link when it comes to security. Most malware attacks prey
on human weaknesses through social engineering. This psychological manipulation might cause
you to reveal sensitive information, or to assist in infecting your systems. Scam emails, spurious
surveys, fraudulent advertisements, and counterfeit websites are all part of the threat landscape.

Attackers often target administration mistakes or misconfigurations in complex software-based

systems too. Poor software development practices and technology advancements also give
hackers the opportunity to exploit software vulnerabilities and experiment with new threat
vectors. Finally, the increased sophistication of network attacks and insider threats frequently
exploit the conventional approach to only secure the perimeter.

480
11-9 About the MITRE ATT&CK Framework
The MITRE ATT&CK framework is a globally accessible knowledge base that describes the
various phases of a cyber attack and the platforms they are known to target.

The MITRE ATT&CK framework is a useful tool across many cyber security disciplines. Some
common use cases include:

• Gap analysis of security controls

• Evaluation of security products and services

• Security testing through red teaming or adversary emulation

The MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework is a
curated knowledge base and model for cyber adversary behavior, describing the various phases
of an adversary's attack life cycle and the platforms they are known to target.

The adoption of ATT&CK is widespread across multiple disciplines, including intrusion detection,
threat hunting, security engineering, threat intelligence, red teaming, and risk management.

Red Teaming is a multilayered attack simulation designed to measure how well a company's
employees, networks, applications, and physical security controls can withstand an attack from a
real-life adversary.

481
11-10 MITRE ATT&CK Tactics and Techniques
The MITRE ATT&CK framework divides adversary behavior into different categories:

• Tactics represent the objective the attacker wants to achieve.

• Techniques are the series of actions and steps to achieve the attacker's objectives.

Tactics represent why the attacker performs an action. An attacker tactic might be to collect
personal identifiable information or to execute files and exfiltrate data.

Techniques represent how an adversary achieves a tactical objective by performing a series of

steps or actions. For example, an adversary might send phishing messages to gain access to
victim systems.

The MITRE ATT&CK framework represents the relationship between its tactics and techniques
in MITRE ATT&CK Enterprise Matrix, which is available at
https://attack.mitre.org/versions/v8/matrices/enterprise/. A different version of such a matrix
is also available for mobile devices.

482
11-11 MITRE ATT&CK Tactics
MITRE ATT&CK Enterprise Matrix contains fourteen distinct adversary tactics representing the
different phases of an attack. Each tactic is achieved by using one or more adversary
techniques.

The MITRE ATT&CK Enterprise Matrix contains fourteen distinct adversary tactics:

1. Reconnaissance: Gathering information to plan future adversary operations. Such

information might include details of the victim organization, infrastructure, or staff/personnel.

2. Resource Development: Creating, purchasing, or compromising resources that can be used

to support the attack. Such resources include infrastructure, accounts, or capabilities.
3. Initial Access: Consists of techniques that use various entry vectors to gain initial foothold
within a network.

4. Execution: During this phase of the attack, the adversary is trying to run malicious code on a
local or remote system.

5. Persistence: Consists of techniques that adversaries use to keep access to systems across
restarts, changed credentials, and other interruptions that might cut off their access. Some
examples include replacing or hijacking legitimate code or adding startup code.
6. Privilege Escalation: The adversary attempts to gain higher-level permissions on a system or
network. Adversaries can often enter and explore a network with unprivileged access but
require elevated permissions to follow through on their objectives. Common approaches are
to take advantage of system weaknesses, misconfigurations, and vulnerabilities.

483
7. Defense Evasion: Consists of techniques that adversaries use to avoid detection throughout
their attack. Techniques used for defense evasion include uninstalling or disabling security
software, and obfuscating or encrypting data and scripts.
8. Credential Access: Adversaries attempt to steal credentials such as account names and
passwords. Techniques used to get credentials include keylogging or credential dumping.
Using legitimate credentials can give adversaries access to systems, make them harder to
detect, and provide the opportunity to create more accounts to help achieve their goals.

9. Discovery: Consists of techniques that an adversary might use to gain knowledge about the
system and internal network. These techniques help adversaries observe the environment
and orient themselves before deciding how to act. Native operating system tools are often
used toward this objective.

10. Lateral Movement: Adversaries attempt to enter and control remote systems on a network.
Adversaries might install their own remote access tools to accomplish lateral movement or
use legitimate credentials with native network and operating system tools.

11. Collection: Consists of techniques that adversaries might use to gather information.
Common target sources include various drive types, browsers, audio, video, and email.
Common collection methods include capturing screenshots and keyboard input.
12. Command and Control: Adversaries try to communicate with compromised systems in a
victim network. During this phase, adversaries commonly attempt to mimic normal,
expected traffic to avoid detection.

13. Exfiltration: Frequently, the next goal after collecting data is to steal or exfiltrate the data.
After collecting data, adversaries often compress or encrypt the data to avoid detection
while removing it.

14. Impact: Destroying or tampering with data.

484
11-12 Adversary Tactics
The diagram illustrates how the adversary tactics of the MITRE ATT&CK framework can be
combined to perpetrate a cyber attack.

The attack illustrated in the diagram includes five different stages:

1. The attacker attempts to penetrate the network by using one or more initial access vectors.
Malicious emails and compromised websites are commonly used by adversaries as an initial
access vector. These techniques often target victims through social engineering techniques
and prompt users to click a link in an email that redirects them to a malicious website.

2. During the second stage of the attack, the adversary executes exploits against vulnerable
or insecure systems in the network, with the intention to connect to and interact with them.
Using malware, attackers might bypass user authentication, allowing them to control the
target system remotely. This type of malware, also called a backdoor, is usually designed to
be persistent and always available, so that perpetrators can connect at will.

3. Having gained access to the infected system, attackers can issue instructions or run
commands to assist their attack objectives.

4. The attacker might use different tools and techniques to compromise other systems and
move around the network. In the example, the attacker moves laterally within the enterprise
network until it finally reaches the database, which is the target of the attack.

5. The attacker steals or extracts the data from the database.

485
11-13 Initial Access
Perpetrators commonly use malicious emails and compromised websites to help them deliver
malware to their targets, including:

• Spam and email spoofing

• Phishing

• Watering hole attack and website spoofing

• Pharming and malvertising

486
Perpetrators often use the following techniques as an initial access vector:

• Spam and email spoofing: Spam is the term used to describe unwanted emails that are
typically distributed in bulk. Spam messages typically contain commercial content or dubious
financial transactions. A well-crafted message that includes personal details, and a forged
sender address, a practice known as email spoofing, often serves as click-bait to lure the
victim to click a link to or open an attached document, either of which points a website
where malware is delivered.

• Phishing: Users receive emails that trick them to visit fake websites to capture their sensitive
information, such as website credentials or credit card details. Phishing attacks often contain
a strong social engineering component where attackers pretend to be someone trusted by
the victim, such as a bank or a department within their organization.

• A watering hole is a website that has been compromised. People who have come to rely on
the website, trust it, and can become victims to malware download, or to theft of their
sensitive information. On the other hand, in website spoofing, perpetrators use tools that
duplicate websites to create fakes that masquerade as trusted ones, often with similar
domain names. When established, perpetrators use various techniques to drive traffic to the
malicious website, such as pharming and malvertising.
• Pharming involves the redirection of web traffic from a legitimate site to a fake site for the
purpose of stealing user names, passwords, financial data, and other personal information.
Malvertising is the practice of injecting malicious code into legitimate online advertisements.

487
11-14 Execution Phase
During the execution phase, the attacker runs malicious code on a local or remote system.
Adversaries often execute exploits against:

• Complex networks

• Software vulnerabilities

• Misconfigured systems

• Insecure software development practices

Adversaries often execute exploits against:

• Complex networks: Network architectures are becoming more distributed and complex.
Where networks were once built around isolated data centers, they now connect with the
cloud, applications, and various IoT devices, giving attackers more potential entry points.
Additionally, monitoring security across data centers and the cloud has become a key
challenge for network security teams.

• Software vulnerabilities: Attackers often scan the network for systems that have not been
patched against known vulnerabilities. Attackers can also target zero-day exploits where
the perpetrators target a disclosed vulnerability before a patch or solution is available.

• Misconfigured systems: Attackers execute exploits against misconfigured systems, for

example those that use default credentials.

• Insecure software development practices: This could include code that is susceptible to
buffer overflow attacks or that includes Easter eggs. Buffer overflow attacks attempt to
overwrite or access data in memory during the execution of a program. On the other hand,
an Easter egg is a term used to describe hidden code that appears within an application if
certain actions are carried out. Easter eggs usually provide the means for the attackers to
establish a backdoor to the system.

488
11-15 Persistence Phase
During the persistence phase of an attack, perpetrators look to keep access to the target
system across restarts, changed credentials, and other interruptions so that they can connect at
will.

Adding startup code and backdoor attacks are often used to achieve this objective.

A backdoor is a type of malware that negates normal authentication procedures to access a

system, giving perpetrators remote access to it at any time.

Backdoors are not just used by cybercriminals. Backdoors can also be installed by software or
hardware providers as a deliberate means of gaining remote access to their technology.
Backdoors of the noncriminal variety are useful for helping customers who are locked out of
their devices or for troubleshooting and resolving software issues.

489
11-16 Command and Control
Having gained access to the infected system, attackers are able to issue instructions or run
commands to assist with their attack objectives.

Command and control provide the attackers with the hands-on capability to execute instructions
or gather further information.

Command and control is often abbreviated as C2.

490
11-17 Lateral Movement
Attackers often pivot through multiple systems and explore the network to find their target and
gain access to it.

In the example, attackers move laterally in the corporate network until they gain access to the
database server:

1. An attack is launched to exploit a known vulnerability in the web server.

2. From the web server, the attacker accesses the application server.

3. From the application server, the attacker accesses the database to steal data.

491
11-18 Data Exfiltration
When they have reached their objective, attackers might use different techniques for getting
the data from the target network and avoiding detection, such as:

• Compression

• Encryption

• Data transfer size limits

• Exfiltration over web service

• Exfiltration over DNS

• Data transfer to a cloud account

• Scheduled transfer

Attackers often use compression and encryption techniques to avoid detection during the
removal of the data. Other techniques used during the data exfiltration process include:

• Data transfer size limits: To exfiltrate data in fixed size chunks instead of whole files or limit
packet sizes to avoid triggering network data transfer threshold alerts.

• Exfiltration over web service: Adversaries might use an existing, legitimate external web
service to exfiltrate data rather than their primary command and control channel. This
mechanism might give a significant amount of cover because of the likelihood that hosts in a
network were already communicating with the web service before the attack. Additionally,
firewall rules might also exist to permit traffic to these services.

• Exfiltration over DNS: DNS data exfiltration is a way to exchange data between two
computers without any direct connection. During the exfiltration phase, the client makes a
DNS resolution request to an external DNS server address. Instead of responding with an A
record in response, the attacker’s name server will respond with a CNAME, MX, or TXT
record, which allows a large amount of unstructured data to be sent between attacker and
victim.

• Transfer data to a cloud account: Attackers might exfiltrate data by transferring it to a cloud
account that they control from the same target device to avoid file transfer and network-
based exfiltration detection.

• Scheduled Transfer: Data exfiltration is performed only at certain times of day or at certain
intervals to blend traffic patterns with normal activity or availability.

492
11-19 NSX Security Solutions
Tactics DFW IDS/IPS NDR Sandbox

Initial access ✓ ✓ ✓

Execution ✓

Persistence ✓ ✓ ✓

Privilege escalation ✓ ✓ ✓ ✓

Defense evasion ✓ ✓ ✓

Credential access ✓ ✓ ✓

Discovery ✓ ✓ ✓ ✓

Lateral movement ✓ ✓ ✓ ✓

Collection ✓ ✓ ✓

Command and control ✓ ✓ ✓

Exfiltration ✓ ✓

Impact ✓ ✓ ✓

The VMware Service-Defined firewall secures both north-south and east traffic entering the data
center. It also provides visibility and protection across MITRE ATT&CK tactics and techniques.
The solution includes:

• A distributed stateful layer 7 internal firewall

• A distributed intrusion detection and prevention system (IDS/IPS)

• NSX Network Detection and Response (NDR), which is a platform that uses artificial
intelligence to detect and contain sophisticated threats.

493
11-20 Using NSX Security Solutions Against a
Phishing Attack
The Service-Defined Firewall can be used to protect against various stages of a phishing attack.

The Service-Defined Firewall can be used to protect against various stages of a phishing attack:

• NSX Distributed IDS/IPS and NSX Network Detection and Response (NDR) are advanced
threat detection and prevention solutions. They identify the attacker's attempts to exploit
the system and prevent them from executing malicious code.

• All Service-Defined Firewall solutions provide protection against lateral movement within the
network. So even if one computer is compromised, the attackers are stopped from pivoting
through different systems in the network.

• NDR can also be used to detect and prevent data exfiltration. So even if the attackers reach
their target, they are stopped from extracting the data from the network.

494
11-21 Review of Learner Objectives
• Define cyber attacks, their motivations, and targets

• Describe the MITRE ATT&CK framework

• Explain the different phases of a cyber attack

• Describe the use of NSX security solutions to protect against cyber attacks

495
11-22 Lesson 2: Distributed Intrusion Detection
and Prevention

11-23 Learner Objectives

• Explain NSX Distributed IDS/IPS and its use cases

• Define the NSX Distributed IDS/IPS Detection terminology

• Describe the NSX Distributed IDS/IPS architecture

• Configure NSX Distributed IDS/IPS

• Interpret NSX Distributed IDS/IPS Events

496
11-24 About NSX Distributed IDS/IPS
NSX Distributed IDS/IPS uses real-time deep packet inspection to identify and prevent attempts
at exploiting vulnerabilities in your applications:
• Protects east-west traffic and prevents lateral threat movement
• Uses signatures to identify malicious traffic patterns
• Is implemented as a distributed solution across multiple ESXi hosts

NSX Distributed IDS/IPS uses real-time deep packet inspection to identify and prevent attempts
at exploiting vulnerabilities in your applications:
• Protects east-west traffic and prevents lateral threat movement: The objective of many
malicious attacks is not solely to penetrate the network. Once in, attackers often pivot
through multiple systems and explore the network to find their main target and gain access
to it. NSX Distributed IDS/IPS recognizes and prevents lateral movement across the
network when perimeter security has been compromised.
• Uses signatures to identify malicious traffic patterns: NSX Distributed IDS/IPS uses an
external cloud-based signature store to remain up to date with known malicious activity,
including zero-day vulnerabilities.
• Is implemented as a distributed solution across multiple ESXi hosts. Like the distributed
firewall architecture, NSX Distributed IDS/IPS is implemented as a kernel module in the ESXi
hosts. This distributed architecture significantly reduces hairpinning by processing traffic
closer to the source.

497
11-25 Use Cases for NSX Distributed IDS/IPS
NSX Distributed IDS/IPS protects against malicious activity, including:
• Exploits of known application-level vulnerabilities
• Application denial of service
• Lateral movement
• Client and server-side exploits
NSX Distributed IDS/IPS also enables security administrators to augment or replace discrete
appliances.

• Application Denial of Service: A denial-of-service attack floods systems, servers, or

networks with traffic to exhaust resources and bandwidth. As a result, the system is unable
to fulfill legitimate requests.
• Client and server-side exploits: Client-side attacks exploit the trust between the user and
the website or server they visit. Common client and server-side exploits include:
— Spoofing: Tricking the user into believing a website or server is legitimate.
— Cross-site scripting (XSS): Allows an attacker to execute code in the user's web
browser to take control of a user's session or to steal login credentials.

NSX Distributed IDS/IPS also allows security administrators to replace or augment discrete
appliances. By using native IDS/IPS capabilities in NSX, traditional IDS/IPS appliances, including
standalone, firewall-based, or virtual host-based solutions can be replaced. Some customers
might also decide to keep their traditional IDS/IPS appliances in place, while using NSX
Distributed IDS/IPS for additional east-west traffic protection.
498
11-26 Requirements for NSX Distributed
IDS/IPS
Before using NSX Distributed IDS/IPS, administrators must consider the following factors:

• The NSX Distributed IDS/IPS components are installed as part of the host preparation.

• NSX Distributed IDS/IPS can be enabled at the vSphere cluster level and for standalone
ESXi hosts.

• NSX Manager needs Internet access to download intrusion detection signatures. Proxy
settings can be configured if necessary.

• NSX Distributed IDS/IPS requires an NSX Data Center Distributed Threat Prevention
license.

499
11-27 About IDS/IPS Signatures
An IDS/IPS signature contains metadata used to identify an attacker's attempt to exploit a
known operating system or application vulnerability.

NSX Manager downloads IDS/IPS signatures daily from a cloud-based signature repository.

Signatures are classified into the following severity categories:

• Critical

• High

• Medium

• Low

An IDS/IPS signature contains metadata used to identify an attacker's attempt to exploit a

known operating system or application vulnerability. Such metadata provides context about the
attempt, such as the affected product, attack target, and so on.

IDS/IPS signatures are matched against traffic headers by using regular expressions.

The cloud-based signature repository updates its signatures approximately every two weeks.
NSX Manager downloads IDS/IPS signatures daily. However, zero-day vulnerabilities are pushed
down as required.

IDS/IPS signatures are classified into severity categories based on their CVSS score.

500
11-28 About IDS/IPS Profiles
An IDS/IPS profile defines the IDS signatures that are included or excluded from detection.

The default IDS profile is configured to include all signatures labeled as critical.

501
11-29 About IDS/IPS Policies and Rules
An IDS/IPS policy is a collection of IDS rules.

An IDS/IPS rule contains a set of instructions that determine which traffic is analyzed, including:

• Sources and Destinations

• Services

• IDS profile

• Applied To

• Mode

IDS rules can be applied to DFW or to specific groups.

NSX-T Data Center 3.1 includes the following modes for an IDS/IPS rule:

• Detect Only: Detects signatures and does not act.

• Detect & Prevent: Detects signatures and performs the action specified by the security
administrator. Available actions are alert, drop, and reject.

Different rules can be configured with different modes.

Customers typically start with the Detect Only mode. After tuning for false positives, they
change to Detect and Prevent.

502
11-30 NSX Distributed IDS/IPS Architecture
NSX Distributed IDS/IPS operates as follows:
1. NSX Manager downloads IDS/IPS signatures from a cloud-based store.
2. Users configure IDS/IPS profiles and rules.
3. Policy stores the IDS/IPS configuration and passes it to the manager.
4. NSX Manager passes the information to the CCP.
5. CCP pushes the IDS/IPS configuration to hosts, through APH.
6. The ESXi hosts store the signature information locally and configure the datapath.
7. The ESXi hosts collect traffic data and send events to NSX Manager.
8. NSX Manager parses and displays these events in the UI.

IDS signatures are written into the IDS module in the datapath, while IDS rules are stored in the
VSIP module.
VSIP evaluates traffic against IDS rules. If a match is found, the packet is sent to IDS.

503
The IDS module then evaluates the packets against IDS signatures.
Distributed Firewall rules are always evaluated before Distributed IDS/IPS rules. If a distributed
firewall rule rejects a traffic flow, this traffic will never be evaluated by IDS/IPS.

504
11-31 Configuring NSX Distributed IDS/IPS
You enable Distributed Intrusion Detection and Prevention for standalone hosts or clusters by
navigating to Security > East West Security > Distributed IDS/IPS > SETTINGS.

On this tab, you can also verify the last time the signatures were downloaded, configure
automatic updates, and manage global signatures.

Configure automatic upgrades and verify the last time

signatures were downloaded

Manage global signatures.

Enable or disable IDS/IPS for standalone hosts and clusters.

If the Auto update new versions check box is selected, signatures are automatically applied to
the ESXi hosts after they are downloaded from the cloud. If autoupdate is disabled, the
signatures are stopped at the listed version.

505
11-32 Global Intrusion Signature Management
Global Intrusion Signature Management enables you to override the default action for a given
signature and globally disable signatures that are not relevant to your environment.

Take actions on multiple Globally disable signature.

selected signatures.

Globally override the action

recommended by VMware.

Globally disabled signatures are not available in new profiles and are removed from existing
profiles.

506
All signatures are preconfigured with a default VMware Recommended action. You can override
this action globally or per profile. Available actions are:
• Alert is typically used in new deployments or new signatures.
• Drop and Reject are commonly used for:
— High Fidelity Signatures with no false positives
— High impact exploits
— After a signature has been deployed in alert-only mode
Dropping a packet is a silent action with no notification to the source and destination
systems. On the other hand, rejecting a packet is a more graceful way to deny a packet,
because it sends a destination unreachable message to the sender. Rejecting the packet is
also faster as the action occurs immediately.

507
11-33 Configuring Custom IDS/IPS Profiles
Using custom IDS/IPS profiles, you specify the IDS signatures that you want to include or
exclude for detection based on their severity, attack type, attack target, CVSS, and affected
products.

Creating granular workload-specific profiles reduces noise and false positives in your
environment.

You create custom IDS profiles by navigating to Security > East West Security > Distributed
IDS/IPS > PROFILES.

You configure the IDS signatures that you want to include or exclude for detection based on
their severity and more granular criteria, such as:
• Attack Types: Categorizes signatures by attack techniques such as trojan activity or
attempted DoS. It aligns with the MITRE ATT&CK Framework.
• Attack Targets: Broad category of possible attack targets such as IoT, Mobile Client, or
Networking Equipment.
• CVSS: Signatures are included or excluded based on their CVSS score range (none, low,
medium, high, and critical).
• Products Affected: Signatures specific to vulnerable applications or operating systems.
Globally disabled signatures are not available for inclusion in profiles.

You can also click the Manage signatures for this profile link to disable individual signatures for
the profile that might not be relevant to your workloads, or to override the global action
configured for a given signature.
508
11-34 Configuring IDS/IPS Rules
You specify how traffic is managed in your environment by configuring one or more rules that
define the IDS profile used and IDS/IPS as the mode of operation.

Just like distributed firewall rules, IDS/IPS rules are evaluated top to bottom.

You create IDS policies and rules by navigating to Security > East West Security > Distributed
IDS/IPS > RULES.

The Sources, Destinations, Services, and Applied To fields operate in the same way as those in a
distributed firewall rule.

The IDS Profile specifies the group of signatures the traffic is matched against.

The mode field in an IDS/IPS rule determines the action that is taken when a signature is
triggered.

The following modes are available for an IDS/IPS rule:

• Detect Only: Regardless of the global or per-signature action, only alerts are generated, and
no preventive action is taken. This mode is equivalent to an Intrusion Detection System.
• Detect & Prevent: The action specified for the given signature either globally or at the
profile level is taken (alert, drop, reject). The action specified at the profile level overrides
the action configured globally. This mode is equivalent to an inline Intrusion Prevention
System.
Like distributed firewall rules, IDS/IPS rules are evaluated top to bottom. You must place the
most hit rules at the top to avoid the unnecessary evaluation of subsequent rules.

509
11-35 Monitoring IDS/IPS Events (1)
You monitor IDS/IPS events by navigating to Security > East West Security > Distributed
IDS/IPS > EVENTS.

The Events tab displays all intrusion detection attempts identified in the system:

• Critical severity signature events appear in red.

• High severity signature events appear in orange.

• Medium severity signature events appear in yellow.

• Low severity signature events appear in gray.

Administrators can filter events based on their severity. Free-form text is also available for
further filtering of events.

IDS events are graphically represented by using a histogram. Security administrators can specify
the period that they are interested in by adjusting the blue vertical lines.

Each IDS/IPS event type is represented by a dot in the histogram. The size of the dot is
proportional to the number of occurrences of an event.

Additional information about each type of event appears in a tabular format.

NSX Manager keeps the last 14 days of data or up to 1.5 million records.

510
11-36 Monitoring IDS/IPS Events (2)
Each event can be expanded to retrieve details about the intrusion attempt, including the
attacker, victim, protocol, attack type, and so on.

Each event can be expanded to retrieve the following details:

• Signature ID

• Severity
• Details or description of the event

• Product affected

• Users affected

• VMs affected

Additional information appears for the last occurrence of the event, including:

• Attacker and target IP addresses

• Bytes exchanged

• Attack and traffic flow direction

The Intrusion Activity diagram displays the occurrences for a particular signature-event on the
selected date. Prevented occurrences are represented with a green bar, and detected only
occurrences are represented with a purple bar. By clicking the bars, you can display the detailed
Intrusion History for a given signature.

511
11-37 Lab 13: Configuring Distributed Intrusion
Detection and Prevention
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

512
11-38 Review of Learner Objectives
• Explain NSX Distributed IDS/IPS and its use cases

• Define the NSX Distributed IDS/IPS Detection terminology

• Describe the NSX Distributed IDS/IPS architecture

• Configure NSX Distributed IDS/IPS

• Interpret NSX Distributed IDS/IPS Events

513
11-39 Lesson 3: Troubleshooting NSX
Distributed IDS/IPS

11-40 Learner Objectives

• Use the UI, the CLI, and the API to validate the NSX Distributed IDS/IPS configuration

• Use log files to validate the NSX Distributed IDS/IPS configuration and events

• Identify and troubleshoot common NSX Distributed IDS/IPS problems

514
11-41 NSX Distributed IDS/IPS UI Validation
The NSX UI displays the realization status of IDS/IPS profiles and policies.

In the example, the IDS/IPS profile and rules are successfully realized in the data plane.

515
11-42 NSX Distributed IDS/IPS CLI Validation
(1)
You verify that IDS is enabled on an ESXi host by running the following command:

nsxcli -c get ids status

NSX IDS Status

--------------------------------------------------
status: enabled
uptime: 267367 (3 days 02:16:07)
The output of the command displays whether IDS is enabled or disabled on the ESXi host. If
enabled, it also displays its uptime.

516
11-43 NSX Distributed IDS/IPS CLI Validation
(2)
Use the following command to retrieve the IDS/IPS profiles configured on the ESXi host:

nsxcli -c get ids profiles

NSX IDS Profiles
--------------------------------------------------
Profile count: 1
1. 69dec1b2-648d-477c-bc3c-24aad86d5369
Use standard vsipioctl firewall commands to retrieve IDS/IPS rules:

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;
}
Before running the vsipiotcl getrules -f command, you must run the summarize-
dvfilter command to retrieve the name of vmware-sfw associated with the vNIC of a VM.
In vSphere environments, vmware-sfw is a software construct where Distributed Firewall and
IDS/IPS rules are stored and enforced.

In the example, the vmware-sfw name for the VM is nic-267791-eth0-vmware-sfw.2. Run the
vsipioctl getrules -f command and the name of the filter to query the IDS/IPS rules
associated with the vNIC of a VM.

The IDS/IPS rule displays the UUID of the IDS profile it has been configured with, which is
69dec1b2-648d-477c-bc3c-24aad86d5369 in the example. The IDS profile UUID matches the
output from the nsxcli -c get ids profiles command.

The rule includes an idp_protect attribute, which means that the rule was configured with the
Detect & Prevent mode from the NSX UI. Rules configured in Detect Only mode show the
idp_detect attribute instead.

517
11-44 NSX Distributed IDS/IPS CLI Validation
(3)
Use the following command to retrieve IDS event statistics:

nsxcli -c get ids events stats

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

Protos to MP
Sent 11
Dropped 0

Alerts to MP
Sent 11
Dropped 0

Event Queue
Dropped 0
--------------------------------------------------
In the example, 11 critical intrusion detection events were identified and sent to NSX Manager for
reporting.
In a healthy system, the number of total events should equal the number of alerts sent to the
management plane (MP). If the number of alerts sent to MP is less than the intrusions detected, it
might indicate a communication problem between the ESXi host and NSX Manager, because the
intrusions are detected in the dataplane, but not successfully reported to NSX Manager.
You can run the esxcli network ip connection list | grep 1234 command
to check the connectivity between the host and the management plane.
In a healthy system, the dropped queues should also be 0.

518
11-45 NSX Distributed IDS/IPS API Validation
(1)
Use the following API call to retrieve the status for the IDS signatures:

GET
https://<nsxmgr>/policy/api/v1/infra/settings/firewall/securit
y/intrusion-services/signatures/status
{
"download_status": "READY",
"signature_status": "AVAILABLE",
"version_id": "f3e0bf8f03565cd106632003502c4299f10ececf",
"resource_type": "IdsSignatureStatus",
...
}
In the example, the IDS signatures were successfully downloaded and are ready to use.

519
11-46 NSX Distributed IDS/IPS API Validation
(2)
Use the following API call to retrieve the existing IDS profiles:

GET
https://<nsxmgr>/policy/api/v1/infra/settings/firewall/securit
y/intrusion-services/profiles
{
"profile_severity": [ "HIGH", "MEDIUM", "CRITICAL"],
"overridden_signatures": [
{
"marked_for_delete": false,
"overridden": false,
"action": "ALERT",
"signature_id": "2001569",
"enable": false,
}
],
"resource_type": "IdsProfile",
"id": "3-Tier_Application",
"display_name": "3-Tier Application",
"description": "IDS/IPS Profile for critical, high and medium
signatures",
...
}
In the example, the IDS profile is configured to detect high, medium, and critical signatures. The
signature with id 2001569 was excluded from detection because the enable field is set to false.
By default, the action for this signature is alert because the signature was not overridden.

520
11-47 NSX Distributed IDS/IPS API Validation
(3)
Use the following API call to retrieve the existing IDS policies:

GET
https://<nsxmgr>/policy/api/v1/infra/domains/default/intrusion
-service-policies
Use the following API call to retrieve all rules for a given IDS policy:

GET
https://<nsxmgr>/policy/api/v1/infra/domains/default/intrusion
-service-policies/<policy-id>/rules
{"action": "DETECT_PREVENT",
"ids_profiles": [
"/infra/settings/firewall/security/intrusion-
services/profiles/3-Tier_Application" ],
"resource_type": "IdsRule",
"id": "1a1c3a30-0f96-11ea-a257-376471a93fd4",
"display_name": "3-Tier_Application IDS/IPS Rule",
"source_groups": ["ANY"],
"destination_groups": ["ANY"],
"services": ["ANY"],
"logged": false
"scope":["/infra/domains/default/groups/3-Tier"], ...}
The IDS rule in the example is configured to detect and prevent traffic based on an IDS profile
called 3-Tier Application. The source and destination for this rule are ANY. The traffic for all
services is being monitored. Logging is not enabled in the rule, and the Applied to field, identified
by the scope attribute, was configured to a group named 3-Tier.

521
11-48 NSX Distributed IDS/IPS Log Files
The following log files are helpful for troubleshooting IDS/IPS issues.

522
11-49 Relevant Log Events
Use the following command to review the logs related to the realization of an IDS/IPS profile.

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

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
Use the following command to review the logs related to the realization of IDS/IPS rules.

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

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
On the ESXi host, nsx-syslog.log logs all events related to the realization of IDS/IPS
profiles and rules. Use the IDSApp keyword to filter logs related to IDS/IPS profile realization
issues. The dfw keyword can be used to troubleshoot the realization of IDS/IPS policies and
rules.

523
11-50 Enabling IDS/IPS Event Logging
Use the following command to enable IDS/IPS event logging on an ESXi host.

nsxcli -c set ids engine alertlog enable

When logging is enabled, you review the logs related to IDS/IPS events by running the following
command:

less /var/log/nsx-idps/fast.log
Sample of network Trojan detection:

12/01/2020-10:49:42.978197 [**] [1:4003599:7] ET TROJAN

Chthonic Checkin [**] [Classification: A Network Trojan was
Detected] [Priority: 1] {TCP} 192.168.248.165:1112 ->
176.119.0.216:80
Distributed IDS/IPS event logging is disabled by default. To enable it, you can run the nsxcli
command set ids engine alertlog enable from the ESXi host.

When event logging is enabled, IDS events are captured in /var/log/nsx-

idps/fast.log. The example shows the detection of a network trojan threat.
Enabling IDS/IPS event logging on an ESXi host is helpful to troubleshoot live environments.

524
11-51 Sending IDS/IPS Events to a Syslog
Collector
From NSX-T Data Center 3.1, you can export IDS/IPS events to an external Syslog collector:
• Syslog must be enabled on the ESXi host.
• IDS/IPS Syslog collection must be globally enabled through the NSX API.
• Events are sent directly from the ESXi host to the Syslog server in the EVE.JSON format.
• Events can be filtered using the IDPS_EVT string.

Apart from globally enabling IDS/IPS Syslog collection from the NSX API, you must ensure that
Syslog collection is also enabled on the ESXi hosts. You enable Syslog collection on ESXi hosts
by running the following commands:
esxcli network firewall ruleset set -r syslog -e true
esxcli system syslog config set --loghost=<syslog-server>
esxcli system syslog reload
The screen capture shows a sample of IDS/IPS events from vRealize Log Insight.
525
11-52 NSX Distributed IDS/IPS Troubleshooting
Flowchart
Use these steps to troubleshoot NSX Distributed IDS/IPS.

You can use the VMware knowledge base to check for known issues related to NSX Distributed
IDS/IPS at https://kb.vmware.com/.
For information about the configuration maximums for NSX Distributed IDS/IPS, see VMware
Configuration Maximums Guide for NSX-T 3.1 Data Center at
https://configmax.vmware.com/guest?vmwareproduct=NSX-
T%20Data%20Center&release=NSX-T%20Data%20Center%203.1.0&categories=19-64.

526
11-53 Scenario 1: Problem Description
To prevent Apache CouchDB vulnerability attacks, an administrator created a profile and a rule:

1. An IDS profile including all signatures for which the affected product is Apache CouchDB.

2. An IDS rule configured with the new IDS Profile and the mode set to Detect & Prevent.

Apache CouchDB attacks are detected in the system, but not prevented.

527
11-54 Scenario 1: Root Cause
The action for all Apache CouchDB signatures is set to Alert. Only alerts are generated.
Preventive action is not taken.

528
11-55 Scenario 1: Resolution
For an attack to be blocked, the mode for the IDS rule must be Detect and Prevent, and the
signature action must be Drop or Reject.

529
11-56 Scenario 2: Problem Description
A security administrator has configured NSX Distributed IDS in an NSX-T Data Center 3.0.0
environment.

A few days later, the networking team reported an increase in network latency alerts,
particularly at times when a high traffic load exists.

530
11-57 Scenario 2: Root Cause and Resolution
Root cause:

Due to a software issue, when NSX Distributed IDS is enabled in a 3.0.0 or 3.0.1 NSX-T Data
Center environment, increased datapath latencies of up to 20 milliseconds might be observed.

Resolution:

This issue was resolved in NSX-T Data Center 3.0.2 and 3.1.0. The environment must be
upgraded to one of these versions during the next maintenance window.

For information about the issue, see VMware knowledge base article 81724 at
https://kb.vmware.com/s/article/81724.

531
11-58 Lab 14: Troubleshooting NSX Distributed
IDS/IPS
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

532
11-59 Review of Learner Objectives
• Use the UI, the CLI, and the API to validate the NSX Distributed IDS/IPS configuration

• Use log files to validate the NSX Distributed IDS/IPS configuration and events

• Identify and troubleshoot common NSX Distributed IDS/IPS problems

533
11-60 Lesson 4: NSX Network Detection and
Response

11-61 Learner Objectives

• Describe NSX Network Detection and Response and its use cases

• Explain the high-level architecture of NSX Network Detection and Response

• Describe the features of NSX Network Detection and Response including Sandboxing,
IDPS, and Network Traffic Analysis

• Describe the visualization capabilities of NSX Network Detection and Response

• Use NSX Intelligence to perform Network Traffic Analysis

534
11-62 About NSX Network Detection and
Response
NSX Network Detection and Response is an advanced threat prevention platform that provides
complete network visibility, detection, and prevention of sophisticated threats:

• It collects network traffic across on-premises networks, cloud, and hybrid cloud
infrastructures.

• It uses artificial intelligence techniques to analyze network traffic and gain insights into
advanced threats.
• It automatically triggers prevention workflows and proactively hunts for network threats.

535
11-63 NSX Network Detection and Response
Use Cases
Security teams use NSX Network Detection and Response.

Security teams can use NSX Network Detection and Response for the following purposes:

• Detect all threat movements: NSX Network Detection and Response can detect threats
entering the network perimeter (north-south), as well as attacks that move laterally in the
network perimeter (east-west), both on-premises, and in the public and hybrid cloud.
• Visualize the entire attack: NSX Network Detection and Response enables you to visualize a
complete intrusion blueprint and a detailed threat timeline across the network so that you
can quickly understand the scope of an attack and prioritize resources. Additionally, NDR
maps to the MITRE ATT&CK tactics and techniques for greater understanding of the key
events in an intrusion.

• Prevent intrusions faster: NSX Network Detection and Response uses real-time, scalable AI
and machine learning to detect and stop threats at wire speed.
• Reduce false positives: NSX Network Detection and Response delivers the industry’s
highest fidelity insights into advanced threats and reduces false positives by up to 90
percent. NDR learns in real time to update detection fidelity.

536
11-64 NSX Network Detection and Response:
High-Level Architecture
The high-level architecture of NSX Network Detection and Response contains the following
distinct tiers:

• Scalable Analytics Tier

• Management Tier

• Sensor Tier

The high-level architecture of Network Detection and Response contains distinct tiers in the
following functions:

• The Scalable Analytics Tier is like the brain of NDR. It is a distributed analytics platform
containing multiple nodes that perform deep content inspection, network traffic analysis,
network and asset profiling, and anomaly detection.

• The Management Tier includes a single manager that provides the REST API and a web-
based UI interface for all user configurations. Additionally, the manager correlates low-level
alerts and events.

• The Sensor Tier includes one or more sensors, and it is responsible for collecting network,
email, web, and mobile traffic.

537
11-65 NSX Network Detection and Response
Features
NSX Network Detection and Response provides Sandboxing, Intrusion Detection and
Prevention, and Network Traffic Analysis capabilities.

NSX Network Detection and Response includes the following key components:

• Network Sandbox that uses a combination of static and dynamic program analysis
techniques to identify, both known and previously unknown, malware and malicious
documents.

• Intrusion Detection and Prevention uses tailored signatures to effectively protect

applications against a wide range of known attacks and exploits.

• Network Traffic Analysis uses artificial intelligence techniques to detect malicious network
behaviors. This feature enables security teams to detect cyber attackers attempting to
break into the network, move laterally, and exfiltrate stolen information.

All these NDR components produce alerts across multiple assets, which are then aggregated to
provide security analysts with a high-level blueprint of all ongoing network intrusions.

538
11-66 Network Sandbox
The Network Sandbox capability of NDR detects malicious content attempting to access the
network through web, email, and file transfer.

The Network Sandbox dissects and analyzes the objects it receives, as well as observes their
attempted behavior within the system. To achieve this function, Network Detection and
Response uses the following techniques:
• Static File Analysis

• Dynamic File Analysis

The Network Sandbox dissects and analyzes the objects it receives, as well as observing their
attempted behavior within the system. To achieve this function, Network Detection and
Response uses the following techniques:

• Static file analysis extracts the unique characteristics of a file, such as its structure, and uses
machine learning algorithms to classify and identify malware indicators.

• Dynamic file analysis performs memory analysis and observes how the file interacts with the
system, identifying indicators of malicious activity.
Static document analysis takes place when a file is examined without executing it, whereas
dynamic analysis looks at the actions of the document and can only occur when the file is
executing.

539
11-67 Static File Analysis
Static file analysis looks for abnormalities in the files without executing them, including:

• Structural anomalies

• Missing or added segments

• Embedded files

• Encryption and fingerprinting

Static file analysis looks for abnormalities in the files without executing them. Structural anomalies
might include embedded shellcode, abnormal macros, or other executable programs that are not
normally present in the type of document being analyzed.

You must perform static document analysis because today’s sophisticated malware does not
always execute its malicious code, especially when it suspects that it is running in a malware
detection system. Static document analysis is also very efficient and fast because it is not
necessary to load or execute functions. This feature can be critical when trying to evaluate large
numbers of files for potential malware.

540
11-68 Dynamic File Analysis
Dynamic file analysis monitors the actions of a file while it is being executed. It performs memory
analysis to discover how the file attempts to interact with the system it runs on.

Dynamic File Analysis can detect the following scenarios:

• A file downloads an external program and executes it

• A file installs a program

• A file connects to a website that is known to be malicious

• An application encrypts files on the disk

• An application tries to evade detection by the analysis environment

Dynamic file analysis is not limited to just monitoring the calls between the malware and the
operating system. It has full visibility of the actual code instructions as they are being executed in
memory and in the CPU. It can see and evaluate every instruction the malware performs, as well
as everything the operating system and kernel do.

541
11-69 Intrusion Detection and Prevention
NSX Network Detection and Response includes an IDPS that detects known threats entering
the network. In addition, it uses pattern recognition and AI-powered analysis to learn the regular
activity of the network and identify anomalous behavior.

The combination of intelligent analytics with known malicious techniques provides the following
advantages:
• Detects lateral network movement and complex malware attacks.

• Protects the network against unknown attacks.

• Reduces the number of false positives and low-fidelity alerts.

NSX Network Detection and Response includes an IDPS that detects known threats entering
the network, and continuously updates its signatures to protect against new variations of known
threats. In addition, NDR uses pattern recognition and AI-powered analysis to learn the regular
activity of a network and identify anomalous behavior that differs from usual traffic patterns.

542
The increasing complexity of attacks makes it hard to secure networks using traditional
signature-based IDPS approaches only. Insignificant changes in the network can often indicate
far greater threats. Moreover, attacks might not involve malware directly. Instead, network
intrusions might occur by bad actors who have acquired login credentials. These network
intrusions will look like employees performing their daily tasks and will go undetected by
traditional IDPS systems. NDR can successfully detect these complex malware attacks by
combining AI-powered analysis and known malicious behavior.

Because NDR does not solely rely on known malicious techniques, it can detect unknown or new
variants of attacks that evade signature-based detection.
NDR’s high-fidelity alerts reduce false positives by using an AI system that is automatically
trained on both network traffic and malicious behaviors.

543
11-70 Network Traffic Analysis
NDR's Network Traffic Analysis uses supervised and unsupervised machine learning techniques
to detect anomalous activity and malicious behavior as it moves across the network.

Network Traffic Analysis transforms and analyzes network traffic recorded by the NDR sensors
to uncover anomalous activity caused by an active threat, including:

• Protocol Anomalies

• Traffic Anomalies

• Host Anomalies

NDR's Network Traffic Analysis uses supervised and unsupervised machine learning techniques
to detect anomalous activity and malicious behavior as it moves across the network.

• Supervised machine learning is useful to classify information when the properties in the
dataset are well-understood. Supervised machine learning trains algorithms to classify data
or predict outcomes. As input data is fed into the model, such model is adjusted to ensure
that it fits the data appropriately and can accurately predict its outcome.

• On the other hand, unsupervised machine learning techniques are useful when subject
matter experts are unsure about the properties or relationships within the dataset. Such
techniques are useful in discovering patterns that help solve clustering or association
problems.

544
Network Traffic Analysis transforms and analyzes network traffic recorded by the NDR sensors
to uncover anomalous activity caused by an active threat, including:

• Protocol Anomalies: Identifies unusual protocols in the network such as DNS tunneling and
DNS zone transfers, which could be redirecting employees or data to other areas of the
web.

• Traffic Anomalies: Identifies unusual traffic throughout the network, which could include
cryptocurrency mining activity, remote file execution, or port scanning. Traffic anomalies can
indicate large threats that do not have any characteristics of known malicious activity, such
as an advanced, undetectable exploit that is attempting to exfiltrate large volumes of
information.

• Host Anomalies: Detects unusual behavior by computers and other systems on the network
such as unusual traffic volumes, logins from strange locations, and periodic check-ins that
could indicate a cybercriminal testing out login credentials.

545
11-71 Automated Response
NSX Network Detection and Response automatically creates attack visualizations that give
security teams the context they need to quickly understand the scope of an attack and prioritize
their response, including:

• The extent and duration of every event

• Active threats and affected hosts

• Communication between local and external systems

• Data sets accessed and harvested

546
11-72 Active Threats and Attack Stages
NSX Network Detection and Response provides a summary of malicious activity in the network
by showing the affected hosts and the stages of the active threats.

NDR classifies malicious activity by attack stage in alignment with the MITRE ATT&CK
framework.

547
11-73 Intrusion Blueprint
NSX Network Detection and Response includes a dynamic blueprint that shows how an attack
enters and moves laterally across the network, including compromised hosts and external
communications.

548
11-74 Attack Timeline
NSX Network Detection and Response also provides a detailed chronology of each stage of an
attack to assist with remediation.

549
11-75 Using NSX Intelligence for Network
Traffic Analysis
NSX Intelligence 1.2 introduces proactive Network Traffic Analysis as a Tech Preview feature.

The Threat Detections tab

Network Traffic Analysis requires a large-sized NSX Intelligence appliance. Tech Preview
features are not officially supported in production deployments.

Once the large NSX Intelligence appliance has been successfully deployed, you can access the
Network Traffic Analysis feature by navigating to Security > Network Traffic Analysis > Threat
Detections.

550
The NSX UI includes two tabs:

• Threat Detections: Allows you visualize detected threats and gain detailed information
about them.

• Event Definitions: Allows you to configure and fine-tune event definitions and thresholds.

NSX Intelligence categorizes threats according to the MITRE ATT&CK framework:

• Persistence: Detects and alerts if an unusually high amount of traffic is dropped by a

distributed firewall rule.
• Credential Access: Detects if a VM sends an unusual number of responses to LLMNR/NBT-
NS requests

• Discovery: Detects and alerts if an intruder tries to attack multiple open ports or services of
a system (scanning) or a single port or service across multiple systems (sweeping)

• Command and Control: Detects the use of non-standard ports for a given a protocol. For
example, SSH traffic runs on a port other than the standard port 22.

• Lateral Movement: Detects suspicious behavior for remote connections such as telnet, SSH,
and VNC, as well as, remote RDP/RDS sessions.

NSX Intelligence threat detection capabilities will be significantly enhanced in future releases with
the integration of NSX Network Detection and Response capabilities.

551
11-76 Lab 15: Using Network Traffic Analysis to
Detect Threats
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

552
11-77 Review of Learner Objectives
• Describe NSX Network Detection and Response and its use cases

• Explain the high-level architecture of NSX Network Detection and Response

• Describe the features of NSX Network Detection and Response including Sandboxing,
IDPS, and Network Traffic Analysis

• Describe the visualization capabilities of NSX Network Detection and Response

• Use NSX Intelligence to perform Network Traffic Analysis

553
11-78 Key Points
• The MITRE ATT&CK Framework describes the various phases of a cyber attack and the
platforms they are known to target.

• The VMware Service-Defined firewall provides visibility and protection against the MITRE
ATT&CK tactics and techniques.

• NSX Distributed IDS/IPS uses real-time deep packet inspection to identify and prevent
attempts at exploiting vulnerabilities in your applications.
• You can use the NSX UI, CLI, API, and logs to troubleshoot issues related to NSX
Distributed IDS/IPS.

• NSX Network Detection and Response is an advanced threat prevention platform that
provides complete network visibility, detection and prevention of sophisticated threats.

• NSX Network Detection and Response provides Sandboxing, Intrusion Detection and
Prevention, and Network Traffic Analysis capabilities.

• NSX Intelligence 1.2 introduces proactive Network Traffic Analysis as a Tech Preview
feature.

Questions?

554