Module 10: NSX-T Data Center Security Design: © 2020 Vmware, Inc

Module 10: NSX-T Data
Center Security Design
© 2020 VMware, Inc.

Importance
Conventional security models assume that everything in an organization’s network can be trusted. The Zero Trust
model assumes the opposite: trust nothing and verify everything. This model addresses the increased sophistication of
network attacks and insider threats that frequently exploit the conventional perimeter-controlled approach.
You must understand how security rules work in NSX-T Data Center and how the distributed firewall and gateway
firewall treat traffic flows. You must also be able to incorporate a tested security policy methodology.
© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 2

Module Lessons
1. NSX-T Data Center Distributed Firewall
2. NSX-T Data Center Identity Firewall
3. NSX-T Data Center Gateway Firewall
4. Security Policy Methodology

Lesson 1: NSX-T Data Center Distributed Firewall
© 2019 VMware Inc. All rights reserved.

Learner Objectives
• Describe the advantages of an NSX-T Data Center distributed firewall
• Describe the relationship between the management, control, and data planes and the distributed firewall
• Describe the steps involved in a DFW policy lookup when a traffic flow is initiated from one VM to another
• Identify the effect on throughput, if any, incurred when the distributed firewall inspects the VM-to-VM traffic
• Compare the distributed firewall differences between NSX Data Center for vSphere and NSX-T Data Center as they
relate to L7 inspection
• Describe the NSX-T Data Center feature that can create firewall rules based on a URL
• Describe the steps involved in the FQDN-based rule enforcement
• Describe bare-metal use cases

NSX-T Data Center Distributed Firewall (1)
Micro-segmentation simplifies
network security:
• Zero Trust / Least Privilege model.
• Each VM can now be its own
perimeter.
• Policies align with logical groups.
• Prevents threats from spreading.
• Network topology-agnostic.

NSX-T Data Center Distributed Firewall (2)
Stateful distributed L2 through L7 services are available for all workloads:
• Firewall rules are enforced for any workload on any platform regardless of network transport.
• Static and dynamic groupings are based on compute object, tags, and user.
• Enforcement is based on 5-tuple, APP-ID, FQDN/URL, and User-ID.
• Micro-segmentation for overlay-backed workloads.
• Micro-segmentation of VLAN-backed workloads connected through existing routers or CSP.

NSX-T Data Center Distributed Firewall: Flow Table and Rule Table

NSX-T Data Center Distributed Firewall: Layer 7 APP-ID
Port-independent enforcement on the
DFW:
• Built-in APP-IDs for common
infrastructure and enterprise apps
• Version subattributes for TLS and
CIFS
• Cipher-suite subattribute for TLS
• Used in rules through context
profiles
• Can be combined with FQDN
allowlisting

NSX-T Distributed Firewall Data Center: Layer 7 APP-ID Benefits
Benefits:
• Reduced attack surface by only
allowing traffic matching APP
fingerprint
• Enables enforcement of security
protocol versions/ciphers
• Enhanced visibility into E-W
application flows
• No impact on throughput

NSX-T Data Center Distributed Firewall: Enforcement Based on Port and APP-ID
L4
Port-Based Enforcement >
L7
Port + APP-ID Based
Enforcement >
Port-Independent
Enforcement >

NSX-T Data Center Distributed Firewall: Applying APP-ID Policies

NSX-T Data Center Distributed Firewall: FQDN Allowlisting
Overview:
• Allow traffic to FQDN or URLs for
a particular VM
• Enforced at DFW level
• Uses DNS snooping
Benefits:
• Supports communication to a
different system or application in a
multisite data center
• Supports applications that use
native cloud services
• Supports URL domain on the
Internet

NSX-T Data Center Distributed Firewall: FQDN to IP Mapping
Workflow for FQDN to IP mapping:
1. The DNS request for
office365.com is initiated from the
client VM.
2. The DNS request matches the L7-
DNS rule.
3. The DNS request is sent to the
vDPI Engine and released to the
destination.
4. The DNS response matches the
connection table entry and is sent
to vDPI.
5. vDPI extracts IP and FQDN from
the DNS response.
6. vDPI programs IP and FQDN
mapping into the data plane.

NSX-T Data Center Distributed Firewall: FQDN-Based Enforcement
FQDN enforcement process:
1. HTTP Get is initiated for
office365.com from the client VM.
2. The destination IP is matched
against the IP-FQDN table in the
data plane.
3. The connection entry is added into
the connection table.
4. The packet is sent to the
destination.
5. Subsequent packets for this flow
are evaluated based on the
connection table.

NSX-T Data Center Bare-Metal Server Value Proposition
The NSX-T Data Center bare-metal server provides consistent networking and security across any platform, including
bare metal.

Bare-Metal Use Case (1)
Use Case 1:
• Virtual to physical or physical to virtual micro-
segmentation:
– Stateful L4 firewall with OVS-based NSX Agent
enforcement running in the physical endpoint
– V2P or P2V in or across networks
Use Case 2:
• Physical to physical micro-segmentation:
– Stateful L4 firewall with OVS-based NSX Agent
enforcement running in the physical endpoint
– P2P in or across networks

Bare-Metal Use Case (2)
Use Case 3:
• Bare-metal connectivity with VLAN-Backed
workloads:
– Physical and virtual workloads connected in the
same VLAN logical switch
– Majority use case
Use Case 4:
• Bare-metal connectivity with overlay-backed
workloads:
– Physical and virtual workloads connected on the
same overlay logical switch

Bare-Metal Server Fundamentals
The bare-metal server offers supportability.

Bare-Metal Server Modes
The bare-metal server supports several configurations.

Review of Learner Objectives
• Describe the advantages of an NSX-T Data Center distributed firewall
• Describe the relationship between the management, control, and data planes and the distributed firewall
• Describe the steps involved in a DFW policy lookup when a traffic flow is initiated from one VM to another
• Identify the effect on throughput, if any, incurred when the distributed firewall inspects the VM-to-VM traffic
• Compare the distributed firewall differences between NSX Data Center for vSphere and NSX-T Data Center as they
relate to L7 inspection
• Describe the NSX-T Data Center feature that can create firewall rules based on a URL
• Describe the steps involved in the FQDN-based rule enforcement
• Describe bare-metal use cases

Lesson 2: NSX-T Data Center Identity Firewall

Learner Objectives
• Describe how micro-segmentation supports a zero-trust architecture for IT security
• Describe how Identity Firewall for NSX-T Data Center can be used for VDI and RDSH
• Identify the Active Directory, VMware Tools, and guest OS requirements to support Identity Firewall for NSX-T
Data Center
• Recognize the responsibilities of each component in the transport node, guest VM, and ID engine required to
support Identity Firewall

Identity Firewall for NSX-T Data Center: Feature Overview

Identity Firewall for NSX-T Data Center: Use Case Overview
Comparing VDI and RDSH:
1. VDI: User-based context
2. RDSH: Multiple users, separate sessions, one server, or VM

Identity Firewall for NSX-T Data Center: VDI Use Case Example
The VDI management systems control which users can log in to the VDI VMs:
• NSX-T Data Center controls access to destination servers from the source VM.
• IDFW user-context is processed at source.
• Guest Introspection Service and user-based context are used.

NSX-T Data Center 3.0: Security
IDFW has several requirements and supported AD, VMware Tools, and guest operating systems.

Identity Firewall for NSX-T Data Center: Performance
Granular control of IDFW enablement:
• Cluster and standalone
• Multiple vCenter Server instances
Configuration distribution through the
NSX Manager cluster control plane:
• Improves performance and scale

Identity Firewall for NSX-T Data Center: IDFW Enforcement Workflow
Workflow for IDFW Enforcement:
1. The user logs in to VM.
2. The user starts the network connection.
3. Thin Agent detects the connection.
4. Thin Agent gathers the connection identity and sends
the information to Context Engine.
5. Both connect and identity information are sent to DFW
for enforcement.
6. The login event is sent to MP if it is the first
connection.
7. IDFW tracks login information to produce runtime data
for display.

Identity Firewall for NSX-T Data Center: IDFW Processes
IDFW processes:
1. Request SID translation.
2. Firewall rule with native AD Group members (no IP
translation needed).
3. Socket event and identity.
4. Records identity, source, and source port.
5. VSIP looks up the Identity based on the actual 5-tuple
in the flow.
You tag the flow with Identity.
6. Enforces the DFW rule on 5-tuple and identity.
Numbers do not represent the actual flow. They only
represent what each component does in the process.

• Describe how micro-segmentation supports a zero-trust architecture for IT security
• Describe how Identity Firewall for NSX-T Data Center can be used for VDI and RDSH
• Identify the Active Directory, VMware Tools, and guest OS requirements to support Identity Firewall for NSX-T
Data Center
• Recognize the responsibilities of each component in the transport node, guest VM, and ID engine required to
support Identity Firewall

Lesson 3: NSX-T Data Center Gateway Firewall

Learner Objectives
• Identify where an NSX-T Data Center gateway firewall is physically implemented
• Describe the order of operations if both NAT and edge firewall rules match a flow
• Describe the function of a Centralized Service Port (CSP)
• Describe how to override the default behavior of edge firewall rules so that they are not applied to every CSP and
uplink
• Describe the function of an NSX-T Data Center bridge firewall

Overview of the NSX-T Data Center Gateway Firewall
Use case:
• Perimeter, intertenant, and
internamespace in containers
Implementation:
• Instantiated per logical router and
supported on both Tier-0 and Tier-1
• Applied to logical router uplinks
(both T0 and T1)
• GFW is a centralized service and
needs an SR component of logical
router
• GFW is physically implemented on
NSX Edge nodes

NSX-T Data Center Gateway Firewall: Deployment and Consumption
Deployment:
• Gateway firewall deployment,
policy management, and
enforcement are independent of
distributed firewall
• Stateful edge firewall is only
supported on the A/S topology
Consumption:
• Like distributed firewall, the
gateway firewall policy is defined
as a set of individual rules within a
section.
• Like distributed firewall, gateway
firewall policies can use logical
objects, tagging, and grouping
constructs (for example, Groups).

NSX-T Data Center Gateway Firewall: Additional Information
Firewall applied to logical router uplinks (both T0 and T1):
• Router link on T1
• Uplink on T0
Centralized service:
• Requires the services router (SR)
• T0 already has SR. T1 must be attached to the edge cluster
If both NAT and edge firewall rules match a flow:
• From outside to inside: NAT and firewall
• From inside to outside: Firewall and NAT
• Option to bypass firewall in the NAT rule
EFW Flow State is synced from active to standby in the A/S topology for high
availability.

NSX-T Data Center Gateway Firewall: Gateway Firewalling on T0
Gateway firewalling on T0 is as perimeter firewall at the virtual and physical boundaries.

NSX-T Data Center Gateway Firewall: Gateway Firewalling on T1
Gateway firewalling on T1 is as intertenant firewall.

NSX-T Data Center Gateway Firewall: Micro-Segmentation and Perimeter Firewall (1)
Micro-segmentation and perimeter firewall are available for VLAN-backed workloads with CSP.
Overview:
• A logical router (T0 or T1) can be attached to a VLAN-
backed logical switch through a centralized service
port (CSP).
• GW FW applied to the SR uplink and CSP.
• DFW applied to workloads on VLAN-backed and
overlay-backed logical switches.
• Provides both DFW and centralized services (NAT,
Firewall) to VLAN and overlay-backed workloads.

NSX-T Data Center Gateway Firewall: Micro-Segmentation and Perimeter Firewall (2)
Micro-segmentation and perimeter firewall are available for VLAN-backed workloads with CSP.

NSX-T Data Center Gateway Firewall: Only Perimeter Firewall (1)
Only perimeter firewall is available
for VLAN-backed workloads.
Overview:
• Workloads connected to a
VSS/VDS port group on a compute
host prepared by a third party.
• A logical router (T0 or T1) can be
attached to a VLAN-backed logical
switch through a CSP.
• An edge firewall is applied to the
SR uplink.
• Provides centralized services
(NAT, firewall) to VLAN-backed
workloads.

Only perimeter firewall is available
for VLAN-backed workloads.
Overview:
• Workloads connected to a
VSS/VDS port group on a compute
host prepared by a third party.
• A logical router (T0 or T1) can be
attached to a VLAN-backed logical
switch through a CSP.
• The gateway firewall is applied to
the SR uplink.
• Provides centralized services
(NAT, firewall) to VLAN-backed
workloads.

Perimeter firewall is available only for
VLAN-backed workloads.
Overview:
• Software L2 bridge function on the
edge node.
• High throughput L2 bridge through
the DPDK-based edge node.
• For L2 connectivity between
overlay logical switch and VLANs.
• Bridge firewall applies to all traffic
in and out of the bridge between
the overlay switch and the bridged
physical VLAN.

NSX-T Data Center Bridge Firewall
Perimeter firewall is available only for
VLAN-backed workloads.
Overview:
• Software L2 bridge function on the
edge node
• High throughput L2 bridge through
the DPDK-based edge node
• For L2 connectivity between
overlay logical switch and VLANs
• Bridge firewall applies to all traffic
in and out of the bridge between
the overlay switch and the bridged
physical VLAN

• Identify where an NSX-T Data Center gateway firewall is physically implemented
• Describe the order of operations if both NAT and edge firewall rules match a flow
• Describe the function of a Centralized Service Port (CSP)
• Describe how to override the default behavior of edge firewall rules so that they are not applied to every CSP and
uplink
• Describe the function of an NSX-T Data Center bridge firewall

Lesson 4: Security Policy Methodology

Learner Objectives
• Identify the steps to perform before defining security policy rules
• Identify the NSX-T Data Center component responsible for collecting and saving an inventory of all VMs
• Describe how to use the VM inventory collection to tag VMs
• Describe NSX-T Data Center logical grouping based on VM name, tags, logical switch, logical port, and more
• Identify the types of documentation and the individuals to consult to understand the application
• Recognize NSX-T Data Center security best practices

Workload, Policy Grouping Methodology, and Consumption: Security Policy Consumption
Model
Policy is configured through the Firewall Rule table by using GUI or REST API in NSX Manager.
The following high-level logical steps must be performed before you define security policy rules:
1. Collect the VM inventory.
2. Tag workloads.
3. Group workloads.
4. Create an application profile.
5. Define the appropriate security policy.

Workload, Policy Grouping Methodology, and Consumption: Tags
Overview:
• Applied to workloads and can be used for security
group membership.
• Statically assigned upon provisioning or dynamically
based on the intended or runtime posture.
• Third-party services can apply tags.
Benefits:
• Automated security policy enforcement and life cycle
for new applications being provisioned.
• Enables dynamic service chaining. If one service finds
an issue, then another service can try to fix it.

Workload, Policy Grouping Methodology, and Consumption: Contextual Grouping of Workloads

Workload, Policy Grouping Methodology, and Consumption: Grouping or Policy Methodology

Workload, Policy Grouping Methodology, and Consumption: Example
The example shows a rule with network, infrastructure, and application-based grouping.

Workload, Policy Grouping Methodology, and Consumption: Rule Enforcement and Resource
Utilization
The Applied To option dictates the scope of rule enforcement and optimizes resource utilization.

Planning Process

Understanding the Application

Micro-Segmentation Methodologies: Determining the Policy Creation Approach
Policies are application-centric
Data center environments are dynamic
Advanced security services are used
Policies are SDDC infrastructure-centric
Uses logical constructs
Policies are network-centric
Uses only IP address and MAC address-centric

Breaking Down the Application

Preparing Documentation: Prewriting Rules
Name Source Destination Service Action Applied To

Allow Users to App01 Any SG-APP01-WEB HTTPS Allow SG-APP01-WEB
Allow App01 Web to SG-APP01- SG-APP01-APP TCP 8080 Allow SG-APP01-WEB
App01 App WEB SG-APP01-APP
Security Group SG-Contains SG-Inclusion Criteria

SG-APP01-WEB APP01-WEB-01 Static
APP01-WEB-02
SG-APP01-APP APP01-APP-01 Static
Service Group SG-Contains Port or App_ID

SVG-APP01-WEB SRV-HTTPS TCP 443
SVG-APP01-APP SRV-TCP8080 TCP 8080

Securing the Application

Securing the Application: vRealize Network Insight Micro-Segmentation Planning

Security Rule Model: Policy Model for Data Center Least Privilege (1)

Security Rule Model: Policy Model for Data Center Least Privilege (2)

NSX-T Data Center Security Best Practices
Follow these NSX-T Data Center security best practices:
• Always see release notes, compatibility guides, and recommended configuration maximums.
• Exclude management components, NSX Manager, vCenter Server, and security tools from the DFW policy to avoid
a lockout.
• Choose the policy methodology and rule model to enable optimum groupings and policies for micro-segmentation.
• Use the NSX-T Data Center tagging and grouping constructs to group an application or environment to its natural
boundaries. This method enables simpler policy management.
• Consider the flexibility and simplicity of a policy model for day-2 operation. The policy model must address ever-
changing deployment scenarios rather than simply be part of the initial setup.
• Use separate DFW sections to group and manage policies based on the chosen rule model (for example, emergency,
infrastructure, environment, application, or tenant sections).
• Use an allowlist model: Create explicit rules for allowed traffic and the default DFW rule from Allow to Block.

Summary of Virtual Infrastructure DFW Design Decisions
Design Decision ID Design Decision Description Applicable to Architecture Model

HY1303-VI-DFW-001 Higher-level external traffic filtering is
provided by a physical firewall, and the
rules are customer defined. Only generic
rules are applied at the physical
boundary and distributed firewall will be
used for granularity.
HY1303-VI-DFW-002 Distributed firewall rules are
consolidated into policies.
HY1303-VI-DFW-003 Configure the security groups' dynamic
membership by using tags.
HY1303-VI-DFW-004 Limit the scope of the distributed
firewall rules to the group members.

Lab 7: Security Policy Design
Review and document the overall design for the customer’s security policy:
1. Read the Customer Security Requirements
2. Propose the NSX-T Data Center Workload Tagging
3. Propose the NSX-T Data Center Workload Grouping
4. Propose the NSX-T Data Center Security Policy

• Identify the steps to perform before defining security policy rules
• Identify the NSX-T Data Center component responsible for collecting and saving an inventory of all VMs
• Describe how to use the VM inventory collection to tag VMs
• Describe NSX-T Data Center logical grouping based on VM name, tags, logical switch, logical port, and more
• Identify the types of documentation and the individuals to consult to understand the application
• Recognize NSX-T Data Center security best practices

Key Points
• Micro-segmentation provided by NSX-T Data Center supports a zero-trust security architecture.
• The Identity Firewall features allow an administrator to create Active Directory user-based distributed firewall
rules.
• NSX-T Data Center distributed firewall rules can be applied based on more than simply IP and ports, such as tags,
device names, user IDs, and URLs.
• A gateway firewall is a service that is part of NSX Edge, which is instantiated per logical router.
• Before defining security rules, as part of your methodology, examine the areas of VM inventory collection, tag
workloads, group workloads, application profiling, and defining the policy.
Questions?

Module 10: NSX-T Data Center Security Design: © 2020 Vmware, Inc

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 10: NSX-T Data Center Security Design: © 2020 Vmware, Inc

Uploaded by

Copyright:

Available Formats

Module 10: NSX-T Data

Center Security Design

© 2020 VMware, Inc.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 2

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 3

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 5

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 6

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 7

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 8

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 9

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 10

Port-Based Enforcement >

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 11

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 12

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 13

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 14

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 15

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 16

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 17

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 18

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 19

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 20

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 21

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 23

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 24

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 25

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 26

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 27

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 28

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 29

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 30

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 31

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 33

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 34

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 35

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 36

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 37

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 38

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 39

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 40

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 41

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 42

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 43

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 44

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 45

© 2019 VMware Inc. All rights reserved.

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 47

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 48

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 49

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 50

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 51

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 52

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 53

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 54

© 2020 VMware, Inc. VMware NSX-T Data Center: Design | 10 - 55

Policies are application-centric

Data center environments are dynamic

Advanced security services are used

Policies are SDDC infrastructure-centric

Uses logical constructs