The COVID-19 pandemic has forced many organizations to shift their business online and their employees to work from home. As a result,  business had to quickly adjust and scale up their infrastructure, sometimes with security as an afterthought.

Malicious actors are already taking advantage of this new reality by targeting the vulnerabilities commonly associated with employees connecting to corporate resources from their home environment. This includes social engineering and phishing campaigns, denial of service attacks, and exploiting vulnerabilities in home routers.

Secure VDI Environments with NSX

Providing employees working from home with secure and reliable access to their corporate resources and applications by the use of Virtual Desktop Infrastructure (VDI) helps our customers to reduce the impact on productivity and continuity as well as the risk associated with remote access to internal data.

In this blog post, I will cover a couple of use cases on how NSX can provide security for End User Compute and share some resources to help customers who are scaling up their VDI / remote desktop session host (RDSH) infrastructure to adapt to this new world in which vast numbers of employees are now working from home.

Protect Your Desktop Pools

The initial target of an attack is almost never the actual attacker’s objective. Once an attacker has gained access, lateral movement is frequently an intermediary step along the way to the crown jewels. With Virtual Desktop Infrastructure, user-desktops reside within the datacenter, physically close to the severs hosting critical applications and data. As most of us know, humans are the weakest link in a security chain, and bringing humans within the datacenter through desktop virtualization can present a new threat vector, allowing attackers to take advantage of vulnerable users/desktops to gain access to data on the nearby servers.

Ensuring that VDI pools and RDSH farms are isolated from the rest of the datacenter is crucial and providing this segmentation at scale, without requiring network re-architecture is key to what the NSX Service-Defined Firewall enables. Through the use of dynamic security groups based on criteria such as VM name, network segment or security tag, desktops are grouped together and the approriate segmentation policy is applied which isolates these desktops from the rest of the datacenter. If you need to massively scale up the number of remote desktops due to many employees now working from home, these new desktops are added to existing groups, and the same segmentation policy is applied as soon as the desktop comes up, without having to make any policy changes, needing network re-architecture,  or adding on physical firewall appliances. Compare that to the traditional model in which traffic to/from desktop pools is hairpinned to a physical firewall which has a policy based on IP addresses and subnets, that doesn’t scale and needs to be manually adjusted to account for the large increase in desktops/IP addresses in VDI pools. This need for manual intervention doesn’t only slow down the roll-out, but is error-prone, leading to both operational inefficiency and an increase in risk.

Figure 1: Leveraging Dynamic Security Tags to immediatley apply a consisent pre-defined security policy

Similarly to how attackers will try to move laterally within an environment in order to gain access to valuable systems/data, ransomware and other types of malware often exhibit worm-like behavior that allow them to spread from one infected machine to another. Many of us are familiar with the WannaCry ransomware which exploited the EternalBlue vulnerability in Windows SMBv1 servers. Once WannaCry has been executed on one machine, it will scan the rest of the environment for vulnerable servers and propagate itself laterally.

Microsoft recently published a security advisory about the existence of a remote code execution vulnerability impacting SMBv3.1.1 clients and servers on Windows 10 and Windows Server operating systems. This vulnerability CVE-2020-0796 is also being refered to as SMBGhost or CoronaBlue and similarly to EternalBlue, it’s considered wormable, meaning that if exploited it can self-propagate over the network.

While network-based segmentation leveraging a traditional firewall deployed between zones can help to prevent lateral movement between zones, it does not offer any protection against propagation within a subnet such as a desktop pool. The NSX Distributed Firewall, on the other hand, literally sits at the vNIC of every workload, and has the ability to intercept traffic before it hits the network, regardless of whether that traffic is going to the internet, a production application in the datacenter or another desktop.

The beauty of this is in it’s simplicity: with just a single rule on the distributed firewall, customers can isolate every desktop from every other desktop across their VDI pools, and through the use of dynamic security groups based on tags or other constructs, this policy is automatically applied to every desktop that is spun up. With just this single desktop isolation rule in place, NSX customers can stop the self-propagation of ransomware across their desktops as well as the lateral movement of an attack. Beyond this, if some lateral communication between desktops is required, customers can configure a firewall policy leveraging Layer-7 Application-Identity to only allow the use of more secure protocols. Additionally with the Distributed IDS/IPS coming soon to NSX-T, we will be able to detect any attempt at exploiting a vulnerable service regardless of if this is an attacker attempting to gain a foothold or ransomware spreading from desktop to desktop across an allowed port on the same network segment.

Figure 2: A Single Distributed Firewall rule applied to Desktop pools provides desktop isolation

Enable User-Based Access Control

Most organizations have distinct desktop pools for contractors and employees. With NSX, we can apply different access policies to these pools so that only users logged in from a desktop in the “employee” pool have access to internal applications. But often, a more granular policy application is required.  For instance, within the “employee” pool, the medical staff should be able to access their medical records application but should not able able to access the HR applications, while the opposite is true for HR users, regardless of which VDI desktop or RDS host these users access their applications from.

NSX Service-Defined Firewall enables user-based or identity firewalling (IDFW). With IDFW, customers can create firewall rules based on active directory user groups in order to provide granular per-user access to applications. NSX Identity Firewalling is based on flow context, not based on IP address, and therefore can be applied to both users accessing their apps from their individual VDI desktops or multiple users accessing published desktops or applications through an RDS host. With NSX-T, IDFW-based rules can also use Layer 7 and/or FQDN context-profiles to provide even more granular per-user control.

Identity Firewall can be enabled per cluster and/or for standalone hosts. NSX-T can retrieve user to group mapping from active directory, allowing users to then configure an NSX group based on one or more AD-Groups. When firewall rules are configured with an AD-based group as the source, the security identifier (SID) of that group is programmed in the dataplane of the distributed firewall. When a user logs in to a VDI desktop or RDSH host, flows from that user are tagged with the SID of the user who generated the flow, and matched against the SID-based rules, right at the vNIC of that VDI desktop or RDS host.

Figure 3: Identity Firewall providing Per-User granular application access for both VDI Desktops and RDSH Published Desktops/Applications

Protecting the VDI Infrastructure

Vrtual desktop delivery/management solutions consist of many different workloads that perform distinct functions, for example Unified Access Gateways and Connection Servers. Furthermore, some of these functions need to interact with other infrastructure components such as Active Directory servers, DNS servers or VMware vCenter. Ensuring proper controls for access from the outside world to the VDI management components or the other way around, as well allowing only the flows that are required between all of the components that make up the VDI management layer is paramount to ensuring a secure infrastructure upon which secure desktops can be delivered.

Many of our customers use NSX to micro-segment their Horizon deployments, leveraging the benefits of intrinsic security that scales along with the applications/infrastructure. Similarly to the per-desktop policies I’ve talked about earlier, through the use of dynamic security groups in the VDI Management micro-segmentation policy, if an expansion of the infrastructure components like the connections servers is required to deal with the increase in employees working from home, the appropriate policies are automatically applied to those new servers without requiring any firewall policy reconfiguration.

Figure 4: Micro-segmenting the Horizon Management Infrastructure

Conclusion

VMware customers can take advantage of their existing NSX investments to enhance their organization’s security posture. The distributed nature of NSX and the Service-Defined Firewall mean that customers can quickly scale up their VDI infrastructure without needing to keep adding physical security appliances. NSX uses stranded compute resources you already have (your hypervisors) to provide in-kernel L2-L7 firewall that scales along with your compute.