VMware View AntiVirusPractices TN en
VMware View AntiVirusPractices TN en
x
BEST PRACTICES
Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Problems with Standard Antivirus Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The VMware Solution to Antivirus Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 VMware vShield Endpoint Architecture in Brief. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Antivirus Protection for the Entire Virtual Desktop Infrastructure. . . . . . . . . . . . . . . . 5 Antivirus Protection for Horizon View Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Install Only the Core Virus Scanner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 With vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Without vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Use Random or Staggered Scan Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 With vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Without vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Update Virtualization and Other Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 With vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Without vShield Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Configure Virus Scanner Exclusion Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Resolve Virus Scanner Deployment Issues in Linked Clones. . . . . . . . . . . . . . . . . . . . . . . 8 Potential Issue 1: Unique SIDs for Virus Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Required Workaround for Some Legacy Antivirus Software . . . . . . . . . . . . . . . . . . 9 Potential Issue 2: Reacting to Virus Infections Depending on Whether the Master Image or a Cloned Desktop Is Infected. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Protect the Horizon View Desktop During ThinApp Package Use. . . . . . . . . . . . . . . . . 10 Background Information on ThinApp Isolation Modes and the Role of the Sandbox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Recommendations for Horizon View Desktop Scanning When Using ThinApp Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Antivirus Protection for the View Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Antivirus Protection for Storage in the Horizon View Environment. . . . . . . . . . . . . . . . . . 13 Scanning Mapped Drives or Shared Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Protecting User Data Disks (UDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Protection Strategies for Storage Related to ThinApp Packages. . . . . . . . . . . . . . . . . . 13 Protection of the ThinApp Executable and Primary Data Container During Package Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 VMware Partnership with eEye Retina. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Protecting the ThinApp Repository in a Horizon View Environment . . . . . . . . . . . . . 15 Outbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Inbound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Scanning the ThinApp Application Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Protecting External Drives Involved with the ThinApp Application. . . . . . . . . . . . . . 16 Scanning the Persona Repository of User Profile Files. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors and Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BEST PRACTICES / 2
Introduction
Desktop virtualization is a transformative platform technology that can deliver cost-effective, manageable network and desktop access to workers with diverse computing needs. However, with security threats becoming more sophisticated, more frequent, more targeted, and potentially more profitable to those who seek to inflict damage, IT administrators must increase their vigilance and find security solutions architected for the virtual desktop environment. Solutions such as log analysis, host-based intrusion-prevention system (HIPS) technology, firewalls, and antivirus software need to evolve and adapt to the needs of desktop virtualization. This paper focuses on the best practices for protection against viruses in the VMware Horizon View 5.x virtual desktop environment. Antivirus software is one of the largest segments in todays computer security market. Nearly every enterprise deploys antivirus software on every desktop. As services such as security, mobility, access control, and line-of-business applications are all rolled up into the datacenter or cloud, antivirus practices need to be rolled up as well.
Malware Labs
Creates signature/rule
Update Service
With Horizon View, you can examine the system bottleneck during an antivirus storm, when virus scanners are running at the same time as users are accessing virtual desktops. Antivirus storms can cause 100 percent saturation in shared compute (CPU) and SAN/NAS (storage I/O) environments. In addition, the memory footprint is significant when antivirus software is installed on each virtual machine. Traditional antivirus agents are resource-intensive and not optimized for highly utilized, cloud-computing environments. Antivirus storms can defeat the cost-cutting achievements of a virtual desktop implementation. To address the need to eliminate antivirus storms and to maximize performance and consolidation ratios in the virtual desktop environment, VMware offers a solution.
BEST PRACTICES / 3
BEST PRACTICES / 4
AV OS
APP OS
APP OS
APP OS
View Clients
Introspection
VMware vSphere
When viruses or malware are detected, the security partners antivirus solution manages the remedial action to the affected virtual machines, based on the administrators specifications.
BEST PRACTICES / 5
BEST PRACTICES / 6
Without vShield Endpoint However, if you do not use vShield Endpoint in your Horizon View virtual desktop implementation, you need to carefully schedule random or staggered scans. In most organizations, IT administrators enable OAS for inbound (write) and outbound (read) file access scenarios. In organizations that are very sensitive about security, customers may prefer to perform additional frequent on-demand scans. With most antivirus solutions, you can perform ODS on a scheduled basis and always have OAS enabled. A best practice is to consider the impact on the storage and hypervisor resources, and to randomize the ODS scan times based on the hypervisor or storage LUN. You may or may not be allowed by the antivirus software vendor to stagger scans with an antivirus agent installed on each virtual machine. Randomizing the scan schedule may be more viable, which would allow you to reduce the number of same-host virtual machines that are running their signature file updates simultaneously. However, you are only randomizing the signature file updates, not eliminating concurrent updates. Most antivirus software defaults to immediate updating when there is a new signature file available, which ensures immediate virus scanning when a new virus is circulating. With virtualization visibility, you can gather I/O load data by comparing the increased ratio between a clean virtual machine and a virtual machine with antivirus installed. Prevent virus scanning activities from saturating the I/O, and make sure that host CPU utilization is lower than 80 percent of your host capacity.
BEST PRACTICES / 7
BEST PRACTICES / 8
Required Workaround for Some Legacy Antivirus Software VMware recommends using QuickPrep to generate unique SIDs for linked clone desktops because the personalization process is faster. However, with legacy antivirus software, a few complicating factors may require action in addition to using QuickPrep. Some antivirus software products need a unique local SID if they do not leverage VMware vShield Endpoint. These products use the local SID to generate a Globally Unique Identifier (GUID) for tracking during the scanning process.
If the antivirus software you choose for your environment is not integrated with vSphere, and the software needs a local SID to generate its own GUID for each endpoint, or if for any other reason you need a unique local SID for your linked clone desktops, you can use a workaround to avoid running Sysprep. The workaround is to use Recompose on each desktop to force the system to create a new local SID. This takes a long time, depending on the number of files in the virtual machine. However, you may find that spending this time to Recompose is more acceptable than time spent with Sysprep during creation of the desktops. If you decide to use the Recompose approach, you must make sure that: The View Composer component is installed on the virtual machine. (This is standard.) The View Agent needs to use View Composer for the Recompose. The Active Directory controllers are reachable from all of the desktops. To automate the Recompose, you can create a power-off script to save the SID before shutting down the virtual machine. VMware Horizon View Administrator allows you to provide a custom script to interact with View Composer. For more information on how to configure View Composer, refer to the VMware Horizon View Administration guide.
Important: Remember that if you integrate the vShield Endpoint antivirus solution with your Horizon View implementation, you do not need this workaround. (In the case of linked clone pools, the vShield Endpoint driver must be installed on the parent image as part of the VMware Tools installation.) vShield Endpoint passes the virtual machine BIOS UUID on to the partner antivirus software. The BIOS UUID is not always unique, so vShield Endpoint also provides to the partner antivirus software the full path to storage for the virtual machine. This differentiates two virtual machines with the same BIOS UUID. If you do not use vShield Endpoint, determine if your antivirus software requires this workaround for QuickPrep. The necessity for the workaround depends upon how the antivirus software generates the GUID. Instead of using the local SID to create a GUID, some antivirus products leverage the MAC address or the hostname stored in DNS to create the GUID.
BEST PRACTICES / 9
If the antivirus software leverages the MAC address or the DNS entry of the endpoint to generate a GUID, and if no other software installed on each virtual desktop needs the local SID to distinguish endpoints, QuickPrep is sufficient, with no need to use Sysprep or the Recompose workaround described above. If you are concerned about duplicate local SIDs on linked clones, refer to The Machine SID Duplication Myth (and Why Sysprep Matters). Potential Issue 2: Reacting to Virus Infections Depending on Whether the Master Image or a Cloned Desktop Is Infected If a virus is found, the first and immediate step is to perform the virus scanning on the master image. Scanning the master image first is the best option because it is a template and not in use. If an infection is found, clean it and then perform a Recompose. If the master image is clean, but the cloned desktop is infected, the best course of action is to Refresh the cloned desktop. If the cloned desktop cannot be refreshed for some reason (or if the infection happened in a UDDsee next subsection), then use the antivirus solution to clean up the malware on each clone individually.
BEST PRACTICES / 10
Background Information on ThinApp Isolation Modes and the Role of the Sandbox The isolation mode of a ThinApp package determines how much is written to the sandbox, and how much is written to the host desktop. VMware ThinApp sets up the default isolation mode for the virtual application by restricting some desktop directories from writes. During Setup Capture, you can set the isolation mode of directories that ThinApp has not already set. You can choose from two directory isolation modes, as in the following picture.
These directory isolation mode choices are: Full write access to non-system directories (Merged isolation mode) During application use, the user can read from and write to directories on the desktop system hosting the ThinApp package. Writes to system directories are automatically excluded, and changes to those directories are stored instead in the ThinApp application sandbox. This is the default isolation mode. Restricted write access (WriteCopy isolation mode) The user can read from the system hosting the ThinApp package. The user cannot write to any directory on the host system, except for a few automatically specified user directories: - %Desktop% - %Personal% (My Documents) - %SystemSystem%\spool All other writes to files and registry keys are saved to copies of these files in the ThinApp application sandbox. A third isolation mode choice is available only from the Package.ini configuration file: Full isolation mode The user cannot read from or write to the system hosting the ThinApp package. Reads are from the files and registry keys within the virtual bubble. All writes are stored in the application sandbox. ThinApp itself sets this isolation mode for only a few directories, and ThinApp packagers should never choose Full isolation mode for the entire virtual application. A virtual application must be able to read and utilize the underlying operating system, and Full isolation mode would prevent that. The virtual application would not be able to run.
BEST PRACTICES / 11
Registry isolation mode defaults to WriteCopy, unlike the default for directory isolation mode, which is Merged. You can change the default registry isolation mode in the Package.ini configuration file for ThinApp. For details on isolation modes, see Configuring Isolation Modes for the File System and Registry in ThinApp (Video Included). Recommendations for Horizon View Desktop Scanning When Using ThinApp Packages You need to be aware of how ThinApp package isolation mode can possibly expose your system to malware or viruses. If the virtualized package is fully isolated from the desktop system, data and settings changes remain within the ThinApp sandbox. However, ThinApp sets only a few directories to Full isolation mode. The general isolation mode for most directories is either Merged or WriteCopy, and some runtime changes are therefore saved directly to the host desktop system. Any application can bring in viruses or other malware to the system. System files in a ThinApp package are always protected from writes by both Merged and WriteCopy isolation modes. If malware attacked a system, changes to system files would be stored and isolated in the sandbox, instead of on the host desktop system. For recommendations about scanning the sandbox, see Scanning the ThinApp Application Sandbox. Changes to non-system files may be written to the desktop system, so you need to routinely run a scheduled, on-demand virus scan on the desktop system that hosts the ThinApp package, just as you would for any system hosting native applications. Even if the desktop is nonpersistent and deleted upon user logout, you must scan the desktop for viruses during a user session.
BEST PRACTICES / 12
BEST PRACTICES / 13
Protection of the ThinApp Executable and Primary Data Container During Package Creation You will store ThinApp virtualized applications within your Horizon View environment in a ThinApp Repository. Before you place the executables and primary data containers in the repository, you need to ensure that the ThinApp packages you created are free from malware. Consider the environments during the two phases of package creation: Capture machine Build machine To protect against incorporating malware into a ThinApp package as you capture the application, you must use a clean capture machine. A clean capture machine is a generic installation of the lowest version of the operating system that will be in your deployment scenario. ThinApp uses a Delta snapshot algorithm. The ThinApp prescan takes a snapshot of the clean machine. Then you install the application you want to capture. The postscan takes a snapshot of the machine with the application installed, and ThinApp uses the difference between the snapshots to create the virtual application. Most application vendors recommend that antivirus software and other security technologies such as firewalls not be installed or running when you install their applications; the application installation during ThinApp capture follows these guidelines. If possible, do not install applications such as antivirus software on your clean capture machine. If anything is preinstalled on the clean capture machine, and the application being captured uses any of those items, the new application installation skips installing those items. When you later place the captured application on a host machine, and those items are missing, the virtual application will not run properly. If your organizations policies require you to install antivirus software on the capture machine, you must install the same version of the antivirus software on all of the machines where you expect the virtual application to run. The virtual application may rely on components of the antivirus software that were preinstalled on the capture machine. However, other factors may come into play that you cannot predict when you do not capture on a clean machine. For an accurate application capture, use a clean capture machine. For similar reasons, if you do not need a network connection for the application, disable the connection or use host-only mode. These are general recommendations for a clean capture machine, and your environment will have unique requirements. Be sure to consider the effects of those requirements on the creation of a clean captured application. The machine on which you build the ThinApp package is another concern. You can build the virtual application on a different machine from the one where you captured the application. The build machine does not have to be a machine with only a clean, basic operating systemthe build machine can be an environment with other applications installed. Therefore, a best practice is to run a virus scan against the ThinApp application project directory before you build, if you are not building on the clean capture machine. And because you may rebuild the virtual application after tweaking configurations, keep the project directory free of viruses by continuing to run scheduled on-demand virus scans on it. With these proper safeguards, you will not be packaging malware into the ThinApp executable or primary data container. Occasionally your virus scanner may point to a ThinApp package as having a virus or malware, but this may be a false positive (an error). Contact your antivirus vendor to find out if the virus detection is accurate, or if the virus checker is giving a false positive because of the ThinApp package format. Note: You might think that it would be a good idea to capture an application and an installation of an antivirus program with ThinApp so that you can protect the application. However, because you cannot virtualize a device driver with ThinApp, it is not possible to capture an antivirus package. After you place the ThinApp virtualized application on a ThinApp Repository and run the application on a desktop, you must continue to be vigilant about protecting the executable and the deployment system. The executable itself is read-only to the user, but malware authors are clever, and no file is invulnerable to attack. You must properly secure both the read-only ThinApp executable and the desktop system.
BEST PRACTICES / 14
VMware Partnership with eEye Retina To protect against vulnerabilities in the application being virtualized, consider a solution from eEye Retina. Any application, including a virtual application, is vulnerable to hacking because it listens to ports and takes instructions from other files (including from malware or a virus). With ThinApp virtual applications, the location of the infection can be the host desktop or the ThinApp application sandbox. Other sections of this paper discuss how to protect the desktop and the sandbox.
Traditional vulnerability assessment solutions are not able to look into a ThinApp package, examine its components, and expose vulnerabilities. VMware and eEye Digital Security have partnered to create a vulnerability management tool within eEyes Retina suite of products. This tool recognizes ThinApp virtualized application packages and lists known vulnerabilities for those applications so that you can patch these applications before distribution. You include an eEye Retina script in the ThinApp package, which notifies Retina where the application is on the system. Retina then uses the ThinApp SDK to audit application vulnerabilities, particularly the application version number, even when the application is not running. The tool does not identify viruses or malware, but instead warns you about known vulnerabilities for the application versions that you have packaged. This capability is particularly important to government agencies and other security-sensitive enterprises. The Retina suite of products also is able to secure ESX and ESXi virtual machines; vulnerability management for virtual applications extends this security surveillance. Protecting the ThinApp Repository in a Horizon View Environment In a Horizon View environment, ThinApp executables and primary data containers are stored in a ThinApp Repository (Windows application share). Consider how viruses or malware might travel to or from this file share: Outbound As users access the ThinApp packages, malware can travel out to users Inbound Malware could accompany a ThinApp package as it is copied to the file share, or as users connect to the file share to access applications
Outbound If you properly packaged a virtual application with ThinApp on a clean machine, you do not need to be concerned about malware in the executable or primary data container that could travel out to the desktop.
Do not enable on-access scanning of executables in the repository, or user performance will be impacted on each access of a ThinApp package. If you are forced to scan the repository, choose on-demand scanning during periods of low use. If you are required to use on-access scanning for the ThinApp repository, make sure that all ThinApp packages larger than a couple of megabytes have separate primary data containers. You can choose this option during Setup Capture. The primary data container includes the ThinApp runtime for each virtualized application. By isolating the ThinApp runtime from the executable for each package, you reduce the size of the executable and minimize the scan time at application launch. For more information on creating a separate DAT file, see the ThinApp Users Guide. At a minimum, try to exclude the DAT files from scanning because they are generally larger than the executables. Some virus scanners provide file-extension exclusion filters. Even if you cannot exclude DAT or EXE files from on-access scans, the impact of scanning these files is lessened if you separate the DAT file from the EXE. These recommendations are for the purpose of decreasing application launch times and augmenting application performance. Of course, you may have regulations that require scanning the EXE and DAT files. In this case, try to use on-demand scanning at low-usage hours.
BEST PRACTICES / 15
Inbound If you properly set permissions on the ThinApp Repository to read-only, user access to ThinApp packages in the repository is read- and execute-only, so you do not need to be concerned about transfer of infections from user systems to the repository.
As you add ThinApp packages to the repository, scan them in case the process of copying the packages in has carried in viruses or malware. To do this, set up virus scanning of the repository only for inbound files, if this option is available in your virus checker. If specifying only inbound files for scanning is not possible with your virus checker, set up on-demand scanning of the repository at a regular, low-impact time of day, rather than use on-access virus scanning, which would impact user access to the files. Scanning the ThinApp Application Sandbox The ThinApp application sandbox stores changes to data and settings that are not writable to the host desktop because of isolation mode settings. Therefore, the sandbox may contain infected files. If the sandbox is not persistent (that is, you delete it upon logout), you may think that you do not need to scan it for viruses. However, an infection can spread quickly even within one user session. If the sandbox is persistent, you do need to scan it. So, in either casepersistent or nonpersistentyou need to develop a strategy for scanning the sandbox. The ThinApp application sandbox is a standard, readable folder in Windows, and therefore is easy to include in virus scans. However, scanning the sandbox on access would impair application performance: users access their data and settings throughout application use. If possible, exclude the sandbox from on-access scanning. If you are required to scan the sandbox, use on-demand scanning during periods of low use. You might want to test how scanning impacts performance to choose the best time of day. If a virus is discovered in the sandbox, you can either clean or delete the sandbox. A fresh sandbox is automatically regenerated the next time the user runs the virtualized application. During ThinApp packaging, you determine where to locate the ThinApp sandbox for each application. If you use Horizon View Persona Management, you would most commonly locate the ThinApp application sandbox within the persona user profile location so that Persona Management includes it in the user profile. See the Persona Management section for advice on scanning the Persona Management user profile location. If you are required to scan the sandbox, and the sandbox resides outside of the users profile, it is a best practice to set the sandbox location to a local drive to avoid incurring extra network traffic. The ideal is to use a nonpersistent Horizon View virtual desktop with a local ThinApp application sandbox because the sandbox is included in the automatic deletion on logout. A new sandbox is generated upon starting the application. If you use Horizon View Persona Management, the ThinApp application sandbox is by default included in the Persona Repository; if you do not want to retain the sandbox, you must exclude the sandbox from roaming. Refer to the VMware Horizon View Administration guide and the VMware View Persona Management Deployment Guide for implementation details. Protecting External Drives Involved with the ThinApp Application Your directory isolation mode setting for the ThinApp virtual application applies not only to directories on the local desktop, but also to virtual drives. However, your isolation mode setting does not apply to external drives connected to the host desktop system. By default, users can write to network drives and removable disks. Therefore, you need to be aware that viruses and malware can travel to these drives. Be sure to scan them with your antivirus checker, or guard against writes to these drives. For information about how to restrict virtual application writes to network drives and removable disks, see The SandboxNetworkDrives Parameter in Package.ini in ThinApp and The SandboxRemovableDisk Parameter in Package.ini in ThinApp.
BEST PRACTICES / 16
BEST PRACTICES / 17
Conclusion
Virus and malware prevention in virtual desktops creates some challenges that need to be taken into consideration when architecting the virtual desktop environment. However, these challenges can be properly tackled, either by deploying a vShield Endpoint integrated solution in the Horizon View environment or by taking some small steps during initial deployment and configuration. Horizon View provides a modern, high-performance, flexible virtual desktop that is both better secured than a physical desktop and also more easily cleaned of any infection that does get through the antivirus software.
VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com
Copyright 2013 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item No: VMW-BP-ANTIVIRUS-USLET-20130329-WEB