I have been meaning to write an article about VDI hardening for a little while. Couple weeks ago listened the recording to an awesome VMworld session entitled “VMware View Security Architecture and Best Practices” hosted by Rob Randell and Mark Benson, both from VMware. This session has finally put me back on track to write this article.
Most administrators will spend time architecting security for Windows GuestOS and authentication methods such as RSA, and will end up forgetting other important components that also need close attention in VMware View architecture. The most common components in a View architecture are listed below; however some organisations will also have Load Balancers, Identity Management, Self-Service Password Systems, Gina chaining components, VPN amongst others components and devices.
This topic really needs to be segmented into Soft Clients and Thin Clients. The reason for that is View Soft Client will always run on top of your existing operating system, either Window, MAC or Linux, therefore is vulnerable to the attack surface of the base operating system. The rule applies also to embedded operating systems.
End computing devices such as Thin Clients, Zero Clients, mobiles and tablets are less vulnerable by nature because of the reduced attack surface and lockdown environment; however it is recommended to keep the devices always up-to-date with latest firmware’s and security fixes.
View Soft Clients will always be more vulnerable and need more attention. The recommendations for devices running soft clients may include the following, but are not limited.
In a VMware View architecture both are services run on Windows Server platforms therefore are subject to the OS attack surface. The same hardening techniques utilised for your common Windows Server infrastructure should be used here and they may include the follow, but are not limited.
It is very common to see administrators disabling services in the GuestOS to optimise the end0user experience but often forgotten is that disabling services you are also reducing the attack surface.
Security Servers are a critical piece in your DMZ and expose Windows attack surface to the external world. Make sure all hardening guidelines are strictly followed and that the virtual or physical Windows is not member of the domain. All items listed above will apply to the Security Servers and additionally, if possible, utilise a different vSphere infrastructure to support your DMZ. The reason for that is that despite the creation of multiple vSwitches in a single host the virtual switching happens in a single process. Make sure you security advisory board is comfortable with the solution. Some more info on the subject you will find on from Brad HedLund.
Additional global security settings related to the overall VDI solution that you may need to consider will include:
Because vCenter Server runs on a Windows host, it is especially critical to protect this host against vulnerabilities and attacks. The standard set of recommendations applies, as it would for any host: install antivirus agents, spyware filters, intrusion detection systems, and any other security measures. Make sure to keep all security measures up-to-date, including application of patches.
There are a number of hardening recommendations for vCenter Server and also for ESX Servers that are covered on the published by VMware in April 2010. I strongly recommend you to go through this document and see if your VDI/vSphere environment is compliant with your organisations guidelines.
Optionally and additionally you can run the script created by William Lam.
Before I go ahead I would like to point out that hardening Windows Parent VM or SOE is almost limitless and it should be catered for your organisation’s needs and policy guidelines. You can go from patching and removing MSN Messenger to actually not installing whole Windows frameworks and components if you utilise as part of the initial deployment. Actually, I would recommend you to have a look at Microsoft Deployment Toolkit (MDT)as it allows you to create a very granular deployment of your base Windows XP or 7.
Additionally, I recommend you to look at my and PCoIP spreadsheet and utilise it as base for your SOE hardening. There are a large number of registry tweaks and Group Policy options to be applied.
Lastly, check out . The PDF also includes a batch file that will help you to customise your Windows 7 SOEs. The batch file will change few registry settings and disable basic services; however these changes are targeting performance, not security. You should review your requirements and change the list of actions accordingly.
You will need to decide amongst a large number of features what shall or shall not be available to your users. After you create your matrix of features that should be available to the users you can utilise the instructions from my article to only deploy the feature set required. As a guideline these are the items you should look for when hardening our SOE/Parent VM:
The key point that I would like to make here is that you do not need to go nuts and start hardening your whole VDI environment. Follow you organisation’s best practices and policy guidelines if you have one. If you don’t, normally common sense wins.