Part 1: Complement your VDI environment with NSX.
Part 2: Complement your VDI environment with NSX: dFW.
Part 3: Complement your VDI environment with NSX: IDFW.
Part 4: Complement your VDI environment with NSX: Introspection Services.
Part 5: Complement your VDI environment with NSX: IDS/IPS.
Part 6: Complement your VDI environment with NSX: Advanced Load Balancer
I started the series discussing the different features within NSX that can complement a VDI environment. I’ll focus on dFW today, a well-known NSX feature.
Recap: East/West Traffic between VDI’s.
dFW, one of NSX’s well known and most marketable features, with good reason. Many attacks don’t target the motherload first time, but rather something lightly protected (think webserver) and then move laterally within the DC to something of better value (think DB). dFW with a zero-trust model alleviates this issue with Firewall instances running on each of the VM vNICs.
Naturally, this helps within a VDI environment, meaning users on one (1) VDI can’t bounce to other VDI’s to gain access to applications or systems they shouldn’t.
Let’s move into the configuration.
VM Groups.
Before we start with the dFW rules, I’d like to create groups of VM’s for easy reference within my rules.
I’ll start by creating a group called NTP Servers and manually assign the NTP VMs into the groups.
Secondly, I will group the DNS servers together, using a more dynamic method, VM name containing the word “dns”. This will pickup my two (2) DNS servers.
Finally, I will use tagging. Previously I created tags within NSX and assigned them to my AD Servers. My group then assigns any VM with this tag into the group.
Three (3) groups have been created, using three (3) different methods of the assignment. I’ve used three (3) different methods to illustrate the flexibility of NSX. In a real environment, you may choose to use the same method of VM identification or mix it up.
Rule Categorization.
One of my favourite additions in NSX-T has been the rule categorisation section. Five (5) categories make up the rule definitions:
- Ethernet = Used for Layer 2 based rules.
- Emergency = Used for quarantine and allow rules.
- Infrastructure = Define access to shared services. Global rules – AD, DNS, NTP, DHCP, Backup, Management Servers.
- Environment = Rules between zones – production vs development, inter-business unit rules.
- Application = Rules between applications, application tiers, or the rules between microservices.
Important to note the rules are processed in a specific order. Left to right and top-down within each section. i.e. All Ethernet rules are run through top-down and then all emergency rules etc.
I feel this is a critical improvement for two (2) reasons. One (1) it allows administrators to naturally structure rules for easy of management and two (2) allows the placement of common/most used rules to be executed first.
Rule Structure.
Rule structure is a heavily debated topic and in my opinion, really depends on your haves and wants. That said, I am a fan of single rules for single services. Grouping services and ports, in my opinion, is messy and insecure, although can be easier to manage.
To start, I want to create policies, which used to be called sections. I’ve created a section within Infrastructure for my core applications, NTP, DNS and Active Directory.
Within each of the policies, I have applied rules. Each rule is specific to the infrastructure component listed in the policy heading.
In my eyes, this creates a tidy and manageable rule structure.
For those with eagle eyes, you’ll notice the applied to the field has been set to only push the rules to the “VDI Users”. This is something VMware has been driving home for years. The use of the applied to field allows the relevant rules to be pushed towards VMs. This speeds up the processing of rules at the vNIC layer.
URL Filtering.
URL filtering is something I wanted to cover in this part of the series, especially since my focus is VDI. Within the dFW rules, you are able to allow or deny traffic based on the destination URL. In the example below I have created a VDI to any rule utilising the HTTPS service. What’s great about this rule, aside from the apply to field being set, is the use of the context profile. Within the context profile, I have specified “mail.google.com”. Assuming my users need to reach their email accounts which I hold in google.
The placement of this rule was within the “Application” category and “VDI outbound” policy. Operationally this should be easy to locate, should it need amending.
Automate using Terraform.
Raymond de Jong has a terrific Terraform post covering security and other NSX-T elements. I can’t recommend this post enough!
Security Groups.
resource "nsxt_policy_group" "ntp_servers" {
display_name = "NTP Servers"
criteria {
ipaddress_expression {
ip_addresses = ["192.168.10.0/24"]
}
}
}
resource "nsxt_policy_group" "dns_servers" {
display_name = "DNS Servers"
criteria {
condition {
key = "Name"
member_type = "VirtualMachine"
operator = "CONTAINS"
value = "dns"
}
}
}
resource "nsxt_policy_group" "ad_servers" {
display_name = "AD Servers"
criteria {
condition {
key = "Tag"
member_type = "VirtualMachine"
operator = "EQUALS"
value = "AD_Server"
}
}
}
resource "nsxt_policy_group" "vdi_users" {
display_name = "VDI Users"
criteria {
ipaddress_expression {
ip_addresses = ["10.0.0.0/8"]
}
}
}
Context Profiles.
resource "nsxt_policy_context_profile" "mail_google_com" {
display_name = "mail.google.com"
domain_name {
value = ["mail.google.com"]
}
}
dFW rules for Infrastructure.
# DFW Infrastrcutre Category Rules - NTP
resource "nsxt_policy_security_policy" "NTP" {
display_name = "NTP"
category = "Infrastructure"
locked = false
stateful = true
tcp_strict = false
rule {
display_name = "NTP Access In"
source_groups = [nsxt_policy_group.vdi_users.path]
destination_groups = [nsxt_policy_group.ntp_servers.path]
action = "ALLOW"
services = ["/infra/services/NTP"]
logged = false
scope = [nsxt_policy_group.vdi_users.path]
}
}
# DFW Infrastrcutre Category Rules - DNS
resource "nsxt_policy_security_policy" "DNS" {
display_name = "DNS"
category = "Infrastructure"
locked = false
stateful = true
tcp_strict = false
rule {
display_name = "DNS Access In"
source_groups = [nsxt_policy_group.vdi_users.path]
destination_groups = [nsxt_policy_group.dns_servers.path]
action = "ALLOW"
services = ["/infra/services/DNS"]
logged = false
scope = [nsxt_policy_group.vdi_users.path]
}
}
# DFW Infrastrcutre Category Rules - AD
resource "nsxt_policy_security_policy" "AD" {
display_name = "AD"
category = "Infrastructure"
locked = false
stateful = true
tcp_strict = false
rule {
display_name = "AD Access In"
source_groups = [nsxt_policy_group.vdi_users.path]
destination_groups = [nsxt_policy_group.ad_servers.path]
action = "ALLOW"
services = ["/infra/services/Active_Directory_Server"]
logged = false
scope = [nsxt_policy_group.vdi_users.path]
}
}
dFW rules for Applications.
# DFW Application Category Rules - VDI
resource "nsxt_policy_security_policy" "VDI" {
display_name = "VDI Outbound"
category = "Application"
locked = false
stateful = true
tcp_strict = false
rule {
display_name = "VDI Access Out"
source_groups = [nsxt_policy_group.ad_servers.path]
action = "ALLOW"
services = ["/infra/services/HTTPS"]
logged = false
profiles = [nsxt_policy_context_profile.mail_google_com.path]
scope = [nsxt_policy_group.vdi_users.path]
}
}
Leave a Reply