Security Hardening for Windows 10 – VDI
VDI hardening is an often-neglected part of the implementation of a new deployment. Most common reason is its complexity to secure your environment without breaking it. But with the current amount of security breaches and ransomware it has become a necessity to spend a decent amount of time on the balance between usability and security.
20 years ago, you could get away with only deploying the windows updates every 6 months or so. Now you want to deploy them as soon as possible after their release on patch-Tuesday. And I remember many discussions where people would say a virus scanner is not needed on a VDI, especially a non-persistent, because a reboot will bring it back to its original state. But those recommendations are long outdated. So for sure, the bare minimum on your VDI deployment is:
- Up-to-date virus scanner
- Up-to-date OS and applications
- Multi-factor authentication, for sure when connecting from unsecure networks.
Optimize services for performance
In the article “Desktop Optimizations for Windows 10 – VDI“, I describe the ways to disable services and scheduled tasks for performance reasons. You should do the same for security reasons because you don’t need 70 unused services running which all can have potential security vulnerablity.
Your VDIs should be deployed in their own VLAN, with a firewall between them and any other VLAN datacenter. When attackers manage to enter your network, the next thing they will try to do is reach any of the core components (like for example Active Directory). Firewalls and gateways restrict traffic to their respective zones, reducing lateral movement and attack surface to contain the blast radius of a breach.
At some clients we even go as far as enabling the Windows Firewall on each of the VDIs or servers. It comes at an expense, because you have to manage them all, but it really makes a difference in your overall security.
Move your eventlogs to a persistant drive
In case you have non-persistant environment (remove changes after each reboot), then it is key to maintain your eventlogs between reboots. Luckily Microsoft has come with a few Group Policies to redirect the 4 key eventlogs. But I believe this does not go far enough.
I found following wonderfull script on the Microsoft website, which moves ALL eventlogs to the new location:
Every computer should have an Anti Virus solution installed. But with VDI this is a bit of a tricky topic when not handeld well. Every antivirus solution comes with a footprint, but remember that you have to multiply that footprint by the number of machines you have, and if that number is hundres or thousands it can easily create a huge impact on your budget. That is why it is important to consider at least following topics when choosing and implementing your antivirus solution:
- Configure your list of exclusions, as detailed as possible.
- Updates of your signatures need to happen as they become available. But how big is your signature file? If you are using a provisioning solution like PVS or MCS this can have a big impact on your cache file.
- Performance and other optimizations, best you can do is contact your virusscanner vendor and discuss the best practices for your particular situation.
Citrix and VMware both have detailed documentation about the antivirus best practices:
Prevent Access to Unauthorized Applications
Out of the box, windows has many other applications (besides CMD, Powershell & Regedit) that the users should not access. But mostly in a VDI-environment we work with a limited set of golden images, where often applications are installed that are not used by all employees. To block those, you can use Microsoft AppLocker, it is great for Whitelisting: Based on group membership, certain applications will be blocked from launching. I suggest that if a group of users does not need it for work, then block access to it.
And if you don’t have time to configure it in details, then at least turn on the audit mode. It just takes a few seconds, but you’ll be able to review the logs later. And like I said, logging is very important to have in case you got breached. It’ll help you to find out what happened.
If you wish to go one step further, I recommend that you use Ivanti Application Control (formerly know as AppSense Application Manager). It goes in to much more detail and has a lot more options to configure your application security.
End of Life / End of Support
At many organisation I notice that, without much thinking, admins install all the Visual C++ redistributables, because some software might need it. Sometimes that’s true, but not always. It is a good practice to make sure that software that is no longer needed or supported by the vendor is not installed on your system.
The same is true for older systems: Citrix Virtual Apps & Desktops, Windows OS, VMWare Horizon,…
For Citrix, here is the list:
For Microsoft products this is the list:
For Visual C++ redistributables, here is a more detailed list:
For VMware the list can be found here:
Shutdown, Reboot, Hybernate
To make sure that our users don’t accidently shutdown their VDI or event worse a multi-session computer, shared with tens of people. Do the following:
- Disable Hybernate: Powercfg -h off
- Disable Shutdown: User Configuration > Administrative Templates > Start Menu and Taskbar > Remove and Prevent Access to the shutdown command.
- Block Shutdown Privilege: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Shut Down the System
Prevent Access to Regedit, CMD & Powershell
In most cases it’s also standard to prevent the user from altering your system and the best places to start are:
- CMD: User Configuration > Administrative Templates > System > Prevent access to the command prompt
- Powershell: User Configuration > Administrative Templates > System > Don’t run specified Windows Applications > Add Powershell & Powershell_ISE (x86 & x64)
- Powershell: User Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn On Script Execution > Allow only signed scripts
- Registry: User Configuration > Administrative Templates > System > Prevent access to Registry Editing Tools
Note: Make sure you don’t lock yourself out as an Administrator
Local Drives, Network Drives, Client Drives
Local Drives: Your users need files, but those files normally are just their data files. They don’t need access to the system files of your VDI machine. So a rule of thumb: Block access to the Local system:
- User Configuration > Administrative Templates > Windows Components > Windows Explorer > Prevent Access to drives from My Computer > Restrict Al Drives
Network Drives: Keep it clean and structured. I have seen envrionments where, through all kinds of rules, there are potentially tens or even hundreds of drives mapped. Believe me, you lose sight of things (never good from a security point of view) and you’ll spend to much time troubleshooting and slow down the logon proces.
Client Drives: I prevent access to all client drives and other USB drives by default. And just in some extreme exceptional cercomstances open access for specific users. With Citrix Policies:
Auto connect client drives – Disabled
Client drive redirection – Prohibited
Client fixed drives – Prohibited
I’m more an expert in Citrix then any other product (Microsoft WVD, VMware, …), so I’ll focus here on explaining how a user connection flow in Citrix is and what the important security measures are.
When users start a session, it is done through the Citrix Workspace app or a website. The user clicks the icon for his virtual desktop or app and it launches. The first imprtant security measure here is the user’s connecting device. This can be anything (Windows, MacOS, Linux, iOS,…) and a user can connect from anywhere. So mostly you as an IT admin don’t have any impact on this device. That is why it is important to run a check on the connecting device before the user opens his session. For that I suggest using Endpoint Analysis Scans from the Citrix Gateway (ADC).
Advanced Endpoint Analysis Scans is used to scan user devices before allowing the user to connect to the database. The device is scanned for security information such as up-to-date OS, antivirus, web browser version and so on. You can use it as part of the smart access policies configured on the Netscaler/ADC. Here is an interesting document by Citrix on how to set it up.
If the user is connecting from outside the LAN (on a public internet connection), make sure the connection ALWAYS goes through the Citrix ADC/Gateway (Netscaler) and over SSL. Making the IIS browser of the Storefront public facing is a bad practice. With the Netscaler, the SSL traffic is handeled and the AD credentials are verified before the user enters the internal LAN.
Also, setup multi factor authentication. There are many options out there that are compatible and easy to setup.
If you don’t know the traffic flow for a Citrix connection, there is a very good video on youtube about it. It’s a bit of an older video, but still relevant:
Security is important, but it is also something that is always changing and improving. That is why I want to maintain this as a living document with new settings and configurations as I get to know about them or implement them at the customer site.
Did I forget something? Or do you believe there is an error in this text? Please let me know in the comments below.