Designing a NSX Security framework

As described in my previous blog, implementing micro-segmentation can have a operational burden on the network/security teams who must manage the environment.
There are multiple ways to organize the NSX firewall rulebase leveraging the NSX Distributed Firewall (DWF), to enable micro-segmentation.

One of the methods is using a (non-official) security framework. The NSX Security Framework provides a predefined security offensive, which can be used as a service ( Security-as-a-Service (aka SaaS .. hmm the name is already in use).

Requirements

A proper design always start with requirements (the “why”-question).

Below an example-list of requirements which are involved with the NSX Security Framework:

• The solution must provide a zero-trust network security framework which enables end-users (business group or user group) to:
  • Allow only access to privately owned application servers with the RDP and SSH protocols, for management purposes.
  • Prohibited application servers access to other application server which belong to other Lines of Businesses (LOBs).
  • Segment their application servers into two (2) or more Application Tiers, by providing predefined firewall-rules.
  • Allow only external access from the internet and/or the customer site to application servers in the first application tier.
  • Allow internal access to lower situated application tiers from upper situated application tiers only on designated ports (for example HTTPS (tcp port 443) and SQL (tcp port 1433))
  • Allow granular internet access from application server only.
  • Allow access from application servers to shared services, such as DNS, NTP, SNMP and Microsoft Active Directory.

For the sake of the overview I’ve used a slimmed-downed version of the security framework requirements , as it can get complex quite fast when using multiple security layers.. As required you can add additional security layers (for example environments or tenants), which I will describe below,

Conceptual design.

The conceptual design broadly outlines the requirements into “building blocks” that are involved with the NSX Security Framework (answering the “what”-question).

A schematic block-diagram says more that a thousand words and perfectly describes how each block (“security object”) communicates with other blocks and which communication is allowed and/or prohibited.

This diagram is self-explaining and I don’t think that additional clarification on this is needed.

Logical design

After the o so needed,  tinky winky concept, we’re getting down into the bits and bytes (a.k.a. the good stuff).

We now have to translate the conceptual design into a logical design (answering the “how”-question, which is described in the paragraphs below:

NSX Security Object Design

To accomplish a NSX security framework we have to use available NSX security constructs. The following NSX security constructs are available (but not all will be used):

• NSX Security Groups
• NSX Security Tags
• NSX IP Set objects
• NSX Mac sets
• NSX Service
• NSX Service sets
• NSX Identity Firewall

NOTE: The NSX Distributed Firewall filtering is based on traditional technical constructs (IP addressing and (TCP/UDP) ports), so the NSX Security constructs must be translated into the traditional constructs. Which .. is not your problem, but it must be considered.

---

Design Decision:
For the NSX Security Framework to function, we use the following NSX security constructs: NSX Security Groups, NSX Security Tags and (optional) NSX IP Set Objects.
Justification:
NSX Security Groups enables multiple objects (VM’s) to be grouped together, dynamically and/or statically. This simplifies the NSX DFW rulebase, because the rules are only based on these NSX Security Groups instead of individual objects.

NSX Security Tags provide a simple method of including virtual machines into NSX Security Groups. The Virtual Machine owner or administrator only has to tag a VM to put hem into the NSX Security Framework, were predefined firewall are configured.

NSX IP Set objects are optionally used for systems that are not identifiable through NSX Security Tags (for example physical servers).
Implication:
The use of only these NSX Security construct may limit the available functionalities which VMware NSX for vSphere can offer (for example: the NSX Identity Firewall construct is not being used, which can be needed addition for the customer)

---

Each block in the conceptual design represents a NSX Security Groups and the communication between the blocks represents the predefined NSX Distributed Firewall rulebase.

Each block, or NSX Security Group, has an NSX Security Tag associated with it. In this example there are 6 NSX Security Groups and 6 NSX Security Tags. Each VM should be tagged with a minimum of 2 NSX Security Tags: these tags places the VM within the NSX Security Framework and applies the security layers on them.

---

Design Decision:
Each application server (VM) must be member of at minimum 2 NSX Security Group-types: an Line of Business NSX Security Group and a Application Tiering NSX Security Group.
Justification:
If a VM is not a member of those NSX Security Group types, the NSX Security Framework is not able to apply all security layers to this particular server. This means that the default firewall is applied to that particular VM.
Implication:
When implementing a server all security layers must be consider, which creates a additional administrative burden.

---

Default Firewall Rule Design

The default firewall rule is the last firewall in the NSX DFW rulebase and is applied when no other rules apply.

---

Design Decision:
The default rule is set to DENY.
Justification:
The requirements states that the solution must provide a zero-trust network security framework.
This means that all network traffic, which are not identified as legit, must be dropped.
Implication:
All legit network traffic must be identified, which can be daunting task for the network/security team (when migrating towards a NSX Security Framework).

---

NSX DFW Rulebase Design

Now that all NSX Security constructs are in place, it is time to organize the NSX DFW rulebase.

REMEMBER: the last (default) rule is set to DENY and traffic hitting this rule is DROPPED.

This means that all legitimate network traffic must be addressed in the rules above the last default (deny) rule. The NSX Security framework is built upon multiple security layers: each layer identifies particular network traffic and prescribes which communication is allowed and/or prohibited.

This example consist of two security layers, which are based on: Line of Business and Application Tiering.

For the NSX Security Framework to function correctly: The last security layer must be designed in a way that it ALLOWS traffic (as a replacement for the default rule), all other security layers must designed to PROHIBIT traffic. This way the NSX Security Framework works like a funnel, only the legitimate traffic is allowed and all other traffic is dropped.

Also NSX DFW rules must be created which check if the VM’s, who receive or send traffic, are member of the two NSX Security Group types (aka the security layers). If the particular VM is not a member of both NSX Security Group types (the security layers), traffic must be dropped. I would call this the NSX Security Framework Enforcements rules throughout this article.
The NSX Security Framework Enforcement rules must be place above all security layer-rules.

For particular (specific) traffic that must be allowed (for instance internet-access from vm’s) a separate firewall section is created which is placed above the security layers, but below the NSX Security Framework Enforcement rules.

For the VM which are placed in the block “shared services” the firewall rules are placed above the NSX Security Framework Enforcement rules.

NSX Firewall Section Design

To sustain an overview of the different firewall rules, firewall sections are used.
Each firewall section contains the necessary firewall rules, associated with them.

For additional safety, a firewall section can be locked, which prohibit NSX Security framework modification which can lead to malicious access.

---

Design Decision:
For the NSX Security Framework, different NSX Firewall Sections are used, which are locked
Justification:
NSX Firewall Sections enables the NSX Security administrator to keep track of the different firewall rule types, which makes it easier to manage.

Locking NSX Firewall Section prohibit any modification on the NSX Security Framework
Implication:
None

---

The following sequence of NSX Firewall Section must be created:

NSX Distributed Firewall rulebase overview.

The table below is an example of how the NSX firewall rulebase should be look like:

Name	Source	Destination	Ports	Action
SECTION: Shared Services
DNS-services	ANY	DNS-Servers	DNS	ALLOW
NTP-services	ANY	NTP-Servers	NTP	ALLOW
Microsoft-AD	ANY	MS-DCs	LDAP	ALLOW
SECTION: Framework Enforcement
AppTier-ingress	SG:!AppTierx	SG:AppTierx	ANY	REJECT
AppTier-egress	SG:AppTierx	SG:!AppTierx	ANY	REJECT
LOB-ingres	SG:!LOBx	SG:LOBx	ANY	REJECT
LOB-egress	SG:LOBx	SG:!LOBx	ANY	REJECT
SECTION: Specific rules
Internet access	SG:Internet-Access	Internet	HTTP HTTPS	ALLOW
SECTION: Security Layer – LOB
LOB-1 ingress	SG:!LOB-1	SG:LOB-1	ANY	REJECT
LOB-1 egress	SG:LOB-1	SG:!LOB-1	ANY	REJECT
LOB-2 ingress	SG:!LOB-2	SG:LOB-2	ANY	REJECT
LOB-2 egress	SG:LOB-2	SG:!LOB-2	ANY	REJECT
LOB-3 ingress	SG:!LOB-3	SG:LOB-3	ANY	REJECT
LOB-3 egress	SG:LOB-3	SG:!LOB-3	ANY	REJECT
SECTION: Security Layer – AppTier
AppTier-1 ingress	Internet	SG:AppTier-1	HTTPS	ALLOW
AppTier-2 ingress	SG:AppTier-1	SG:AppTier-2	HTTPS SQL	ALLOW
AppTier-3 ingress	SG:AppTier-2	SG:AppTier-3	SQL	ALLOW
SECTION: Default rule
Default rule	ANY	ANY	ANY	BLOCK

The ! (exclamation mark) tells the rule to negate (exclude) the supplied value.

CONCLUSION

This NSX Security framework is non-official (I’m not saying unsupported). I see a lot of customers adopting this framework as it is very manageable, because of the low amount of firewall rules. The NSX Security Framework is easy to understand, is transparant and provides a easy to consume security offensive.

NOTE: This model/framework has some limitations: The framework uses NSX Security Groups and NSX Security Tags. When NSX is deployed in an cross-VC environment it will only work in ACTIVE/PASSIVE deployments. This is due to local resolving of the NSX Security Group membership, information which is not synchronized between NSX Managers.