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
Over the past few weeks, I’ve been working with a number of customers that are keen to see how NSX can complement their existing or new VDI environment(s). N.B. I say VDI a lot in this article, but it applies to both VDI and RDSH. As soon as this discussion starts my mind leaps into distributed Firewalling, Identity Firewalling, Introspection Services and Intrusion Detection/Prevention Services. I think it’s an exciting discussion and one more of us will be having as time goes on if we haven’t already.
I’ve found a number of good articles out there that discuss this topic in parts, but not a lot that discussed the whole concept. Stijn Vanveerdeghem had a nice post on this topic. Following on from Stijn, what I want to discuss in this post are the multiple solutions VMware have that can secure and enhance your VDI environments.
What does a typical environment look like?
I’ll hold my hand up and say I am far from a EUC Architect. If you find something isn’t quite right in this article, please reach out and we can get it corrected.
From a Networking standpoint, the design of the VDI or RDSH environment is surplus. I am more interested in the workloads and how to protect them. That said, I have to understand what the environment looks like, at least from a high level. Most environments will have a VDI flat network which is isolated from all the infrastructure and applications. It’s very possible the VDI environment will be placed on a separate cluster or infrastructure stack entirely. Something like this…
Now we know what we are dealing with, let’s look at some of the problems faced with VDI environments.
- East/West traffic between VDI’s.
- Different users on the VM’s and/or contractors moving between department.
- Heavy applications (anti-virus) on each VDI.
Looking at each problem individually, we can find a simple and elegant solution to quickly mitigate each of them.
East/West Traffic between VDI’s.
As Stijn mentions in his article, an attacker rarely attacks the component that is valuable to them. They are looking to gain access to an environment and then move laterally between VM’s/Application’s.
A common problem in VDI or RDSH environments is providing access to a single VM. This VM then has access to other VMs in the same layer 2 domain.
Easy win for VMware NSX. Distributed Firewalling is a feature that can be enabled to lock up the VDI from the vNIC level. Meaning the ingress and egress are controlled before the traffic hits the virtual switch.
URL filtering is also something that I think is a wonderful addition to the NSX service. Allowing customers to use predefined (by VMware) URL’s to allow or block traffic. While they are predefined, they do cover a vast number of options. I suspect at some point in the future, this will be a customizable feature.
N.B. As of NSX-T 3.1, custom URL/FQDN support has been added.
User Movement.
I’m sure many of us have used RDSH sessions where multiple users from multiple departments use the same VM to access varying applications within a data centre. I typically call this a “jump box” which has access to a number of applications and servers. Regardless of whether you are meant to have connections to said application or server, you do, because connections all originate from that 1 VM. Do you have separate boxes for separate teams/users? Do you rely on the application authentication to vet out legitimate and illegitimate users? You can, but why don’t we piggyback on that distributed Firewall idea and bolt-on Identity Firewalling.
Identify Firewalling is covered very nicely in a VMware whiteboard session. In essence, it maps users (based on login events) to VDI or RDSH sessions. These sessions then have specific rules pushed to the vNIC of that VM. Meaning Jane from accounts will have specific rules which allow her to access her payment applications, while Matt from HR will have a different set of rules allowing him to get to his people applications. The best part about this is, as Jane and Matt move between VDI or RDSH sessions, the rules follow them, dynamically.
Moving one step further, if Matt fancies a career change and moves to accounts. All that’s required is a change in Active Directory. NSX will then populate Matt’s new rules based on the group change (logout and login are required). This ensures Matt can no longer see the HR systems and can now see all the Accounts systems.
The dynamic nature of the IDFW greatly reduces operational workload as it relies on the AD groupings. While it might take a little more time to set up initially, the workload will reduce exponentially.
Application Density
VDI’s and RDSH VMs all need protecting. The majority of the time, anti-virus and/or anti-malware products are installed on each of the VMs. While there are ways to globally manage these, it can be a management nightmare, not to mention extra resources are required for each VM to host these applications.
Enter Introspection Services! VMware NSX has the concept of deploying service VM’s for Network or file introspection. I will focus on the file introspection services, but the models are somewhat similar.
Rather than deploying anti-virus software on each VM, you install an add-on to the VMware tools (which should already be installed). This is lightweight and then allows the service VM to access the file system on the VM for vulnerability scanning. This additional scanning is now offloaded onto the service VM, freeing up all the resources for the user. It’s important to note that 1 service VM will be deployed per ESXi hosts enabled for introspection services and each host service VM will monitor all VMs on the host, provided you configure it to do so.
This should dramatically decrease the resources required for each VM as well as make management easier as it can all be done via the third-party service control VM.
Little Something Extra (IDS/IPS).
While it’s not mentioned in the above requirements, I find the inbuild IDS/IPS (Intrusion Detection System/Intrusion Prevention System) feature fascinating. I’ve not seen any other hardware or software that provide true distributed IDS/IPS. Game-changer!
Customers can now use NSX to detect or prevent potential and real application threats. This level of layer 7 protection provides another layer of security on an already stacked product line.
Customers may want to see IDS/IPS deployed and protecting their VDI and RDSH environments in certain used cases.
Problem Solved!
We started with 3 problems:
- East/West Traffic.
- User Movement.
- Application Density.
Using the NSX features we managed to solve all of our problems in a simple and effective manner.
I understand the above is high-level and some of you may want a little more meat on the bones. Over the next few posts, I will go into greater depth on each of the solutions (not Introspection services) and run through some configuration examples. I’ll also attempt to add an automation section in each of them as speeding up any deployment is key for all of us.
Leave a Reply