Version Kaspersky Lab FOR INTERNAL USE ONLY

Transcription

1

2 Version 1.15 Kaspersky Lab

3 Table of Contents Introduction... 4 Virtualization... 4 Hypervisors... 4 Full virtualization and para-virtualization... 6 Virtualization platforms... 7 Protection of Virtual Environments... 7 Kaspersky Security for Virtualization 3.0: Structure and Operation Principles General Protection Server Light Agent Use of resources Distribution of updates Licensing How Light Agents connect to Protection Server Chapter 1. Deployment Deploying Protection Installation of Protection Server System requirements What you will need for the installation Installation under Hyper-V and XenServer Installation under VMware ESXi Initial setup Deployment of Light Agents Deployment stages Preparation Installation on persistent machines Installation on non-persistent machines Chapter 2. Management Management Principles of Kaspersky Security for Virtualization Creating Managed Computers structure Configuring Protection Parameters File scanning algorithm Scan optimization technologies Detection technologies Comparing settings of Kaspersky Endpoint Security and Kaspersky Security for Virtualization Protection Monitoring Chapter 3. Scaling and Maintenance Scaling Protection Server Resources Specifics of Protection Server Discovery by Light Agents Assigning Protection Server to Light Agent Protection Servers and Load Balancing in Cluster VMware vsphere Microsoft Hyper-V Citrix XenServer... 76

4 2 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent 3.4 Device Control Accessing devices in a virtual environment Policy for RDP client Policy for Citrix Receiver VMware View Client policy Reconfiguring Protection Server Connection Settings and Deleting Protection Server Modifying Protection Server settings Deleting Protection Server... 84

5 3

6 4 KASPERSKY LAB Introduction Virtualization KL Kaspersky Security for Virtualization. Light Agent The Virtualization term is applied broadly to the information technology environment; most widely, however, it is used when speaking of a virtual hardware platform where an operating system can run. This platform is called a virtual machine, and the operating system running there a guest operating system. Hardware virtualization allows running operating systems similarly to ordinary applications. Several important conclusions follow. There can be many virtual machines on a physical server, their number is only limited with the server resources. They can be easily created, deleted, etc. Deployment of new services or testing environments takes minimal time. Also, virtualization helps to efficiently use physical equipment. Depending on the performed tasks, consumption of resources (processor time, RAM, disk I/O) by an operating system may vary. On a physical computer, resources are persistent and are initially selected to be sufficient for the most resource-consuming operations. Typically, high load does not last long, especially on a workstation. It means that most of the time resources are underloaded. On virtual machines, it is not a problem. A physical server hosts lots of them, and increased load on one of the virtual machines is compensated with absence of hard tasks on others; it is unlikely that all of them will require maximal resources simultaneously. Therefore, the available hardware can be used efficiently and a large amount of extra capacity to account for peak load is not necessary. It means that virtualization allows decreasing the number of servers, hardware and maintenance expenses, and electricity costs. Virtualization offers numerous other benefits, which, however, are beyond the scope of this course. Hypervisors A virtual machine has the necessary set of components. Adequate RAM and processor resources are allocated to it. The disk subsystem, network adapters and other devices are standard virtual devices provided by the virtualization platform, which allows the machines to be independent from the server hardware. A hypervisor provides connection between the physical server and virtual machine hardware. When the operating system tries to access hardware, the hypervisor intercepts this request and translates it to the server, and then transfers the answer in the reverse direction. The whole process is hidden from the operating system, which works with virtual hardware as if it were physical. There are two types of hypervisors. Hypervisors of Type 2 operate within the host operating system: VMware Workstation, VirtualBox and Parallels Desktop. Hypervisors of Type 1 run directly on the hardware without a host operating system. For this reason, they are more productive and widely used by enterprises. Those include VMware ESXi, Microsoft Hyper-V, Citrix XenServer, and others.

7 Introduction 5

8 6 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Hypervisors of Type 1 installed on several physical servers are joined into groups with a single management center. This can be called a cluster or a resource pool (on XenServer). Cluster resources may be considered as a single entity. It means that the administrator does not care on which server a virtual machine is running; the management center may move it from one hypervisor to another, for example, to balance their load. A group of hypervisors is able to deliver highly available services since virtual machines may run on any node. This capability becomes available if a network storage or special program technologies are employed (for example, VMware VSAN). In the former case, cluster nodes are connected to a single storage where virtual machine disks are stored. A physical server just provides the guest operating system with computational resources, such as CPU and RAM; while disk operations are not tied to it. It means that if a cluster node breaks down, a virtual machine can automatically start on another one that has access to its disk. Load balancing works similarly: a guest system is automatically moved to the least loaded host. Full virtualization and para-virtualization Initially, virtualization of x86-compatible operating systems was a difficult task, because they were designed to work on hardware and use the processor directly. This implies execution of instructions at the lowest level of processor architecture. At the same time, the hypervisor is located there, which is supposed to run guest machines as ordinary applications on an unprivileged level. Such systems were first created in the late nineties with the help of binary translation of non-virtualizable instructions run on the operating system kernel. In addition to virtual CPU, RAM, hardware and BIOS are allocated to a guest machine. Thus, hardware and virtual machines are completely isolated, and the operating systems are called fully virtualized. Binary translation decreases performance and processor efficiency; that is why an alternative approach was suggested, para-virtualization. It means that the guest operating system knows that it is virtualized and performs hypercalls that directly communicate with the hypervisor instead of privileged system calls. This not only takes load off the processor, but also helps to make the virtual machine monitor less intricate. Call substitution requires modification of the operating system kernel; that is why it is typically used in Linux virtual machines, where source codes are open. Para-virtualization relates not only to the processor, but also to RAM and hardware. VMware Tools, for example, is actually a backdoor in the hypervisor that provides the virtual machine with optimized drivers and time synchronization. Microsoft provides a Linux Integration Services package that improves operation of Linux systems under Hyper-V. Despite its advantages, the use of full para-virtualization is limited. It is mainly used by hosting providers, because ensures performance similar to non-virtualized systems. At the same time, such virtual machines are bound to the specific hypervisor and hardware. To make matters worse, there also some issues with Windows paravirtualization. In the mid 2000s, processor manufacturers developed special technologies (Intel VT-x, AMD-V) that allow getting rid of binary translation in fully virtualized machines. For this purpose, a new mode is added; it is named root and has the highest priority. The operating system can use the processor as if it were physical, and the hypervisor is moved lower, to the root level.

9 Introduction Virtualization platforms Let us consider the key concepts of virtualization platforms mentioned in this course. VMware vsphere VMware vsphere provides a complete set of tools necessary for virtual infrastructure deployment and maintenance. vcenter Server is the core component that joins several ESXi hypervisors into a single managed structure and provides access to all capabilities of VMware vsphere. It is supplied as a distribution that can be installed on Windows Server or as a ready Linux-based virtual appliance. The administrator can access vcenter Server through a Windows client or web interface. The ESXi hypervisor is based on the VMkernel operating system. It provides the drivers necessary for interacting with the hardware and applications responsible for the maintenance of virtual machines and interaction with vcenter Server. All together, VMkernel and the necessary software, comprise the ESXi hypervisor. Citrix XenServer Citrix XenServer is based on a free Xen hypervisor, which is widely used by hosting providers, for example, Amazon EC2 and Liquid Web, and also in the internal environment of Google, Yahoo, etc. The virtual machines running on XenServer are called domains. There is a parent domain (domain 0 or dom0) that starts first and has direct access to hardware. It is running a Linux-based operating system, which contains drivers and hypervisor management tools. Other virtual machines called domu (Unprivileged) start from dom0. They cannot access the hardware directly; dom0 forwards their requests to the hardware. Unlike VMware, Citrix does not have a special component responsible for working with a group of servers. The administrator selects the master node and connects the other hosts to it. The master then performs all management functions. XenServer hypervisors joined into a single structure are named a resource pool. Microsoft Windows Server Basic architecture of Hyper-V is similar to XenServer. Partitions are used here instead of domains. There is the parent partition where Windows Server 2008 R2 or higher or Windows 8 runs. It has access to the hardware and contains drivers and management tools. Virtual machines run in unprivileged partitions created by the parent. Hyper-V can be installed as a Windows Server role, or as an individual solution named Hyper-V Server. The latter is a simplified version of Windows Server Core without the capability to install additional roles. A set of Hyper-V hypervisors can be clustered similarly to physical Windows servers. In particular, such clusters ensure high availability of virtual machines. System Center Virtual Machine Manager (SCVMM) provides additional functionality. It is an application installed on Windows Server that allows working with the whole virtual infrastructure from a single console. SCVMM can also be used for managing other hypervisors (VMware ESXi, Citrix XenServer). Protection of Virtual Environments Like any other new technology, virtualization was not used for critical tasks at first. For a long time, virtual machines were used in testing environments, for temporary workplaces, in training centers, etc.; and servers 7

10 8 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent remained physical for the most part. Protection seemed to be unnecessary for the temporary virtual machines, because if they get infected, they can be easily recreated or rolled back to a previous state. With time, virtualization technologies developed, received additional functionality and gained a significant share of the market. Enterprises began to move the load and work processes from physical computers into the virtual infrastructure. At the same time, the risks of infections and compromise started to grow. Unlike testing environment, which can be isolated, a full-fledged workstation can access the corporate network and servers, and may infect other computers. The necessity to protect virtual machines became evident. First, typical solutions developed for physical computers were used for this purpose. This approach provided security, but neither the fact that all the machines are located on the same physical server nor virtualization specifics were taken into account. The main issues of traditional protection that needed to be solved were: Drastic hypervisor performance decrease while running tasks on schedule, when all virtual machines simultaneously perform on-demand scanning or download databases; Inefficient resource consumption (is described in detail in the next chapter).

11 Introduction 9

12 10 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent A dedicated scanning server, which would serve guest machines on each hypervisor, would solve these problems. In this case, the boot process can be controlled on the whole host, rather than only an individual virtual machine. For usability and security reasons, the scanning server is installed on a specially prepared virtual machine. It processes the requests that the agents installed on the guest machines send over the network. This architecture also helps to solve the issue of different statuses of the databases on the virtual machines. If the traditional solution is used, the databases are not updated while the machine is turned off, and after it is turned on, some time passes until the update task completes. Moreover, the machines deployed from a template need even more time to receive up-to-date databases. As of today, all large Anti-Virus vendors offer some solutions to protect virtual environments. Some of them are agent-based, and some are agentless. Agentless solutions exist only for VMware so far, and use vshield Endpoint. This technology provides an API using which files on the virtual machines can be scanned, disinfected or deleted. For this purpose, a thin agent by VMware (included with VMware Tools) is installed on guest machines. So the agentless solution term is rather relative in this case and means that the thin agent is very simple and consumes minimal resources. Kaspersky Security for Virtualization 2.0 is an agentless solution for VMware. It is described in detail in course KL

13 Introduction 11

14 12 KASPERSKY LAB Agentless protection has its pros and cons. KL Kaspersky Security for Virtualization. Light Agent Limited protection. The vshield Endpoint driver (thin agent) is very simple and therefore almost does not influence the performance of the protected virtual machine. However, it can be used only for scanning files on the drive. It cannot provide protection from attacks via a browser, memory scanning, proactive defense, etc. Such an approach is possible on servers, but is insufficient for a typical workstation. Hard framework. Many of the protection functions cannot be implemented because of the solution specifics. The task of Anti-Virus products is to scan data. Object access is intercepted by VMware tools. The capability to use new functionality also depends on VMware. At the moment, file system protection is only supplemented with the Network Attack Blocker, which is implemented through Network Extensibility APIs. Inefficient resource consumption on small installations. For those customers who have small virtual infrastructures, vshield Endpoint does not seem attractive. We need to take into account the fact that it will be necessary to install several additional virtual machines: vshield Manager for installing and managing vshield Endpoint (one per vcenter Server) and the Security Virtual Machine (per each ESXi host). They consume storage space and memory. If you need to protect just a couple of ESXi hosts with several virtual servers, the gain is not obvious. And if Network Attack Blocker is also necessary, yet another Security Virtual Machine will need to be additionally deployed on each ESXi host. Cost. As of today, vshield Endpoint is included in VMware vsphere Standard license and higher, but the use of Network Attack Blocker will require additionally purchasing a vcloud Networking and Security license. Also, Network Attack Blocker requires a distributed virtual switch, which is only included with most expensive editions of VMware vsphere. All the described problems are solved to some extent in Kaspersky Security for Virtualization 3.0.

15 Introduction 13

16 14 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Kaspersky Security for Virtualization 3.0: Structure and Operation Principles General Architecture of Kaspersky Security for Virtualization 3.0. Light Agent is hypervisor-independent. Unlike the agentless solution, this product does not require integration with the virtualization platform for its installation and configuration. Not only it simplifies the system and minimizes the number points of failure; this also reduces the infrastructure requirements. Kaspersky Security for Virtualization 3.0 comprises two elements: Light Agent Is installed on the protected virtual machines and sends the files to the Protection Server for scanning. The Light Agent is a simplified (without the file scan functionality) version of Kaspersky Endpoint Security 10. Protection Server Scans the files received from the Light Agents. The Protection Server also holds a shared cache of verdicts (see the Shared cache section under 2.2). The Protection Server is a separate virtual machine where Kaspersky Security for Virtualization is installed. The Protection Server is also called SVM (Security Virtual Machine) in Kaspersky Security Center interface and in the configuration files. Kaspersky Security for Virtualization 3.0 is deployed and managed through Kaspersky Security Center. Both components, the Protection Server and the Light Agent, are the Administration Server s clients. The clients interact with each other and with the Kaspersky Security Center through the Network Agent. It is pre-installed on the Protection Server; and the administrator is to install it on the protected virtual machines. The general operation schema is as follows. The administrator creates policies and tasks for the Protection Server and Light Agents in Kaspersky Security Center. These settings are transferred to the corresponding applications and are used for scanning the files, etc. When started, the Light Agent establishes connection to the Protection Server. When the user opens a file, the Light Agent intercepts this operation. Then the decision is made whether the file is to be scanned. If yes, it is transferred to the Protection Server, where it is scanned according to the policy. The result is returned to the Light Agent, which takes the corresponding action: allow access, disinfect, or delete. Data is transferred between the Light Agent and the Protection Server over TCP. Protection Server The Protection Server is based on SUSE Linux Enterprise Server 11 SP2. It is supplied as a virtual appliance packed for a specific platform: Hyper-V (*.vhd), XenServer (*.xva) or VMware (*.ova). For better performance, the operating system is fine-tuned for each implementation to benefit from full or partial para-virtualization.

17 Introduction 15

18 16 KASPERSKY LAB Light Agent KL Kaspersky Security for Virtualization. Light Agent The Light Agent is installed on the protected virtual machines. It is based on Kaspersky Endpoint Security 10 and contains all of its components except for the Encryption. The Network Agent, which provides connection to the Kaspersky Security Center, must also be installed together with the Light Agent. The only substantial difference from Kaspersky Endpoint Security is that the Light Agent transfers objects for scanning to the Protection Server instead of a locally installed virus scan engine. Files are intercepted by the File, Mail, Web and IM Anti-Viruses. Other functionality (Firewall, System Watcher, Network Attack Blocker, Controls) works similarly to Kaspersky Endpoint Security, that is, on the protected virtual machine. Use of resources Prioritization and control of resources play an important role in virtual environments. Uncontrolled resource consumption by virtual machines is undesirable, because it affects the overall hypervisor performance. A dedicated Protection Server helps to control object scanning. In case of a storm of requests from the Light Agents, the Protection Server acts as a bottleneck and reduces the stream to the values specified by the administrator. All requests that cannot be processed immediately are queued (see section 3.1 for details). Thus, a temporary peak load is distributed in time without taking up all of the hypervisor s resources. In addition to control, Kaspersky Security for Virtualization helps to save resources. The fact that the virus scan engine and databases exist on the Protection Server only instead of each virtual machine allows decreasing the hypervisor memory consumption, and a shared cache on the Protection Server allows considerably decreasing the number of scans and, consequently, the load on the processor and RAM. After the Protection Server scans a file from one virtual machine, it saves this information, and if a scan request for the same file is received from another machine, it just returns the cached verdict (see the Shared cache section for details). A shared cache is efficient if similar virtual machines are running on the hypervisor, especially VDI. The Light Agent requires fewer resources than Kaspersky Endpoint Security. The optimizations implemented in it allow reducing the load on CPU and the drive. Distribution of updates Kaspersky Security for Virtualization 3.0 is a complex product with multilevel protection designed to provide utmost security. Most of its components require regular updates, because the number of threats permanently grows, and they become more sophisticated. To counter all those threats, various databases are issued. Some of them are designed for the Light Agent and are stored on the protected virtual machine, but most of them pertain to the Protection Server, which scans objects. This way, best balance of efficiency and performance is achieved. The Light Agents do not perform resource-consuming operations; instead, they take care of the functionality that neither requires frequent updates nor needs to be moved to the Protection Server. For example, if System Watcher would operate on an individual virtual machine, it would require sending too much information about applications activities over the network, which would decrease the solution performance. So, Protection Server uses signature and heuristics databases, and Light Agents databases of phishing and malicious links and the databases designed for the System Watcher and Network Attack Blocker. All components are updated centrally via Kaspersky Security Center, which downloads databases from Kaspersky Lab servers in the Internet. The Protection Server downloads databases from the Administration Server repository according to the schedule of the update task created by the administrator.

19 Introduction 17

20 18 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent After the Protection Servers have downloaded all the necessary databases, they serve as update sources for the Light Agents. They are accessible through the shared folder of the Protection Server. To provide for the rollback functionality, each new set of databases is placed into an individual folder whose name includes the timestamp. Eventually, old folders are deleted. Light Agents update completely automatically and do not require administrator s attention. The databases are loaded on the schedule specified for the local update task, once every 2 hours by default. This architecture provides updates for all virtual machines and allows taking load off Kaspersky Security Center significantly when compared with Kaspersky Endpoint Security. The algorithm of selecting the Protection Server for the Light Agents ensures optimal distribution of the network load. Licensing In Kaspersky Endpoint Security, per node licensing is used. Workstations and servers require different keys because these operating systems are used differently. This licensing type is also implemented in Kaspersky Security for Virtualization 3.0; the only difference is that only running virtual machines are taken into account. Rigid binding of a license to a virtual machine makes little sense, because machines are often deleted and recreated. As a result, the Administration Server will pile up non-existing nodes, and licenses would be wasted on them. If VDI is used, enterprises try to reduce expenses by consolidating virtual machines on hypervisors. Per node licensing becomes disadvantageous in this case; that is why Kaspersky Security for Virtualization also supports licensing based on counting the cores of the processor installed on the physical server. Another advantage of per core licensing is that it helps to stay within the license limitations when the number of virtual machines on the hypervisor changes with time. All licenses are counted by the Protection Server, which transfers this information to the Administration Server. From the point of view of Kaspersky Security Center, this process does not depend on the hypervisor; that is why in a heterogeneous environment where different hypervisors are used (for example, VMware and Hyper-V), everything will work seamlessly. Any license of Kaspersky Security for Virtualization allows using full functionality of the Light Agent, including basic protection (File Anti-Virus, Web anti-virus, Firewall, etc.), and also various Controls. How Light Agents connect to Protection Server When started, the Light Agent must establish connection to the Protection Server. It cannot find out the server s address directly, because there is no third party that would store this data centrally (as vshield Endpoint). That is why multicast is used for discovery. Protection Servers send special packets with the information necessary for the Light Agents. A Light Agent listens to Servers multicasts and selects the Server located on the same hypervisor as itself. If it cannot be found, connection is established to the Protection Server with the fewest Agents connected.

21 Introduction 19

22 20 KASPERSKY LAB Chapter 1. Deployment 1.1 Deploying Protection KL Kaspersky Security for Virtualization. Light Agent Planning. Protection deployment starts with the installation of Kaspersky Security Center. Deployment and management of Light Agents requires that the computer with the Administration Server has access to all protected virtual machines. Then it is necessary to define location of the Protection Servers. Installing one Protection Server per hypervisor is optimal. The installation wizard will not allow installing more (except for a XenServer resource pool). For each virtual machine of the Protection Server it is necessary to select the drive location and network. Network connection must satisfy the main requirements of the Protection Server: Connection to Kaspersky Security Center (to receive updates, policies, tasks, and also send events); Connection to all protected virtual machines; Ability to multicast to all guest virtual machines (at least within the host). Installation of Kaspersky Security Center. Kaspersky Security Center can be installed either on an individual virtual machine, or on a physical server. Its installation and configuration is described in detail in KL Kaspersky Security and Management training course. From the viewpoint of the Administration Server, Protection Servers and Light Agents are different products that require their respective plug-ins. They provide the capability to deploy and manage these components; for this reason, they must be installed beforehand. Installation of Protection Servers. Use Kaspersky Security Center to deploy Protection Servers on each hypervisor. The installation wizard automatically defines the networks available on the hypervisor and allows specifying the storage where the virtual machine s drive will be located. Installation of Light Agents. At the last stage, the Light Agents are deployed to the virtual machines that need to be protected.

23 Chapter 1. Deployment 21

24 22 KASPERSKY LAB 1.2 Installation of Protection Server System requirements KL Kaspersky Security for Virtualization. Light Agent The Protection Server actively interacts with the hypervisor when counting licenses and receiving information about the location of virtual machines during the discovery. The Light Agent works with the drivers of guest machines, which vary depending on the hypervisor version. There are many technicalities, and despite its versatile architecture, Kaspersky Security for Virtualization 3.0 officially supports only the following versions of hypervisors: VMware ESXi 5.5; VMware ESXi 5.1u2; Microsoft Hyper-V Server 2008 R2; Microsoft Hyper-V Server 2012; XenServer 6.1; XenServer These requirements are not checked during the installation, and the administrator should pay special attention to this. Prior to installing the Protection Server, make sure that: There is a DHCP server in the network The installation wizard does not allow specifying the network settings of the Protection Server manually, and completely relies upon the DHCP server. If the Protection Server cannot receive an IP address automatically, the wizard will return an error and roll back its actions. Folder sharing is allowed on the target hypervisor (only for Hyper-V) The administrative share is used for copying the Protection Server image to the target hypervisor. What you will need for the installation Regardless of the hypervisor where Kaspersky Security for Virtualization is installed, the administrator will need the following before the installation: Kaspersky Security Center; Protection Server plug-in A special wizard is used for installing the Protection Server. It appears after the plug-in for the Administration Console is installed and can be started by clicking the Manage Kaspersky Security for Virtualization Light Agent link on the Getting Started page of Kaspersky Security Center. The wizard allows installing the Protection Server or modifying its settings (see section 3.5); Protection Server distribution The distribution of the Protection Server consists of a zipped virtual machine image and an XML file that describes it. The description contains brief information about the Protection Server, including the maximum size of the virtual drive and the hash sum used for checking the image integrity (click the Validate button in the wizard for this). The description file and unpacked image of the Protection Server must be located in the same folder. For the installation under VMware ESXi, vcenter Server is necessary and parameters of two accounts configured on it: an administrator and a read-only.

25 Chapter 1. Deployment For the installation under Hyper-V or XenServer, hypervisor access parameters are required: IP address and the username and password of an administrator account. 23

26 24 KASPERSKY LAB Installation under Hyper-V and XenServer KL Kaspersky Security for Virtualization. Light Agent For the administrator, the installation procedure is the same regardless of the hypervisor type. In the wizard, it is necessary to specify access parameters for the target hypervisor, and then install and configure the Protection Server. Technical details, however, do depend on the hypervisor type (this will be described in the next section). The installation procedure includes the following: Selecting the hypervisor. Under Hyper-V or XenServer, the administrator can select only one target host for the installation of Protection Server. There is a command line utility that helps to automate installation on numerous hypervisors, but its functionality is limited. At this stage, it is necessary to specify: Hypervisor type (Hyper-V or XenServer); IP address of the hypervisor; Username and password of the hypervisor s administrator account. Selecting the image. At this stage, the administrator selects the description file for the Protection Server. It may be located in the local file system or in a shared folder. Configuring the virtual machine of the Protection Server. At this stage, select the storage for the virtual machine, and also the network to which it will be connected. Remember that under Hyper-V, you need to specify the path for the virtual drive in the hypervisor s file system.

27 Chapter 1. Deployment 25

28 26 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Configuring Protection Server access and Administration Server connection. The Protection Server has two user accounts. One of them is used by the installation wizard for configuring the Protection Server parameters over SSH (klconfig). The other is the administrator account (root), which is not typically used and is necessary mainly for viewing the log, changing internal parameters of the product or troubleshooting. You can enable SSH access for root. However, it makes the Protection Server more vulnerable to attacks aimed at brute-forcing the administrator s password. With this option selected, it is especially important to set a difficult password for root. As far as klconfig is concerned, this account has limited permissions and no access to the system shell (bash). It can run only a limited set of statements to change a few parameters of Kaspersky Security for Virtualization and Network Agent. The installation wizard can automatically configure connectivity of the Network Agent to Kaspersky Security Center. For this purpose, the IP address of the Administration Server must be specified in the properties of the Remote installation packages container; if the DNS name is specified, the administrator will have to manually type the IP address of the Administration Server at the corresponding step of the installation wizard. Installation on Hyper-V cluster shared volumes Cluster shared volumes (CSV) allow several nodes to have simultaneous read/write access to a drive. The drive must be accessible over a shared bus, for example, iscsi, FCoE or SAS. Usually, CSV is used in a failover cluster. If a virtual machine is clustered and one of the nodes breaks down, the machine will automatically start on another one. From the operating system viewpoint, CSV is an ordinary folder (for example, C:\ClusterStorage\VolumeN, where N is the running number). Path to it is the same on all nodes of the failover cluster. The installation wizard of the Protection Server treats CSV as the hypervisor s local storage. The only thing the administrator should pay attention to is that different paths must be selected for the virtual drives of the Protection Servers installed on different nodes of a cluster; otherwise, the names will conflict.

29 Chapter 1. Deployment 27

30 28 KASPERSKY LAB Behind the scenes KL Kaspersky Security for Virtualization. Light Agent After the installation wizard receives the necessary information, deployment of the Protection Server starts. This process comprises two parts: deployment of the virtual machine image and configuration of the Protection Server. The former is platform-dependent. Let us study them in some more detail. Deploying the image Hyper-V. The installation wizard first mounts the \\<hypervisor address>\admin$ (which corresponds to %systemroot%). There, it creates a temporary folder with a randomly generated name. Then the following happens: The virtual machine of the Protection Server is created on the hypervisor; A local administrator account named LASvmUser_<an alphanumeric sequence> is created on the hypervisor. The Protection Server will use it to connect to the hypervisor and gather the necessary information (the number of CPU cores, load on the hypervisor, etc.); The virtual drive of the Protection Server is copied to the temporary folder; The virtual drive of the Protection Server is moved to the location specified by the administrator; The virtual machine of the Protection Server is granted full access to the disk; Virtual machine resources are configured: CPU (2 processors), memory (2 GB); To connect the Protection Server to the selected network, a port is created on the corresponding virtual switch; The WinRM service is configured, which the installation wizard needs for interacting with Hyper-V; The virtual machine of the Protection Server starts; The installation wizard defines the IP address of the Protection Server using the information from the hypervisor. XenServer. The wizard loads the image directly to the specified storage. Creates a virtual machine, configures resources, starts it and defines the IP address. Configuring the Protection Server The second stage does not depend on the hypervisor. The following steps are taken: The installation wizard checks whether it can connect to the Protection Server using the found IP address over SSH; The installation wizard connects to the Protection Server over SSH under the klconfig account and configures it: Changes the hostname; Connects the Network Agent to Kaspersky Security Center; Configures parameters for Protection Server hypervisor connections: IP address, hypervisor type, username and password. For Hyper-V, the account created by the wizard (LASvmUser_< >) is specified, for Citrix XenServer the account specified by the administrator in the installation wizard when connecting to the hypervisor. All the settings are stored in the /etc/opt/kaspersky/la/scanserver.conf file on the Protection Server; The Protection Server is restarted.

31 Chapter 1. Deployment All steps are logged. The trace file can be found in the installation folder of Kaspersky Security Center, in Plugins\la.plg\DeployWizard\log.txt. 29

32 30 KASPERSKY LAB Installation under VMware ESXi KL Kaspersky Security for Virtualization. Light Agent The Protection Server of Kaspersky Security for Virtualization is installed on the ESXi hypervisor by the same installation wizard as on Hyper-V/XenServer. The steps included in the installation wizard are mainly the same as those described higher. The main difference of the deployment process under VMware ESXi compared to the Hyper-V/XenServer is the capability to install the Protection Server on several hosts at once. Instead of the hypervisor, the installation wizard connects to vcenter Server, which stores all information about the virtual infrastructure. During the installation, the administrator will need to specify two accounts that must be created on vcenter Server beforehand. The first one, administrative, is necessary for deploying a Security Virtual Machine on the hypervisor. The other, with minimal permissions, is necessary for the Protection Server to receive information from vcenter Server, for example, to count licenses and define the hypervisor where a virtual machine is running. Let us study the stages of deploying a Protection Server under VMware ESXi. Connection to vcenter Server. Specify the address of vcenter Server (IP address or DNS name) and password of the administrator account. This data is used only once and is not saved anywhere. You cannot specify ESXi address here, that is why installation on hypervisors that are not connected to a vcenter Server is not supported. Selecting Protection Server Image. The administrator must specify location of the distribution description file. It is can be a path in the local file system or a file in a shared folder. Selecting the hypervisors. The installation wizard displays the list of hypervisors connected to the vcenter Server selected at the first step. For each hypervisor, the following information is displayed: whether it is accessible at the moment, whether a Protection Server operates there, and whether the rights granted to the specified account are sufficient for the installation. The administrator is to select the hosts to be protected. If the rights are insufficient or a Protection Server is deployed already, the hypervisor cannot be selected. To speed up the process, deployment can run simultaneously on all of the selected hosts. It will speed up the process, but the load will increase.

33 Chapter 1. Deployment 31

34 32 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Parameters of Protection Server Virtual Machine. Similarly to Hyper-V/XenServer, the administrator is to select a name for the Protection Server virtual machine, the repository where the virtual hard drive will be copied and the network to which the virtual machine will be connected. This is to be done for each hypervisor selected at the previous step. When selecting the repository, you need to take into account the available free space. By default, a Protection Server hard drive reserves 30 GB at once; with the Use dynamic allocation option selected, it will take up about 2 GB right away and later will grow as necessary within the limit of 30 GB. This mode is named thin provisioning. A DHCP server must operate in the Protection Server s network; otherwise, the virtual machine will not be able to receive an IP address, and the installation will fail. Protection Server access and Administration Server connection parameters. At this step, you will need to specify the passwords for the administrative account, root, and also for the klconfig account, which the installation wizard uses for setting up the Protection Server (these accounts and Network Agent configuration specifics are described in detail in the Installation under Hyper-V and XenServer section) Non-Privileged Access to vcenter Server. Parameters of this account of vcenter Server will be stored on the Protection Server and used for service purposes.

35 Chapter 1. Deployment 33

36 34 KASPERSKY LAB Initial setup KL Kaspersky Security for Virtualization. Light Agent Right after the installation, the Protection Server cannot provide adequate protection. It is not activated and it does not have up-to-date databases. For Kaspersky Endpoint Security, an update task is created by the Quick Start wizard of Kaspersky Security Center, and a license can be automatically distributed to new nodes. For a Protection Server, it is the administrator who is to create the update and license installation tasks. Additional requirements for the network are imposed by multicasting, which is used by the Protection Server, because multicasting cannot go outside a broadcast domain. Activation of the Protection Server A license is installed by running the Add key task on the Protection Server. Light Agents need not be activated, they receive the necessary information about the license when connect to the Protection Server. The License installation task can be run within a management group or within a computer selection. The Protection Server can be activated by an activation code, or a key file, or a license from the Administration Server repository. Key autodistribution (which is available, for example, for Kaspersky Endpoint Security) is not possible.

37 Chapter 1. Deployment 35

38 36 KASPERSKY LAB Update task of the Protection Server KL Kaspersky Security for Virtualization. Light Agent An update task is necessary only for the Protection Server. The Light Agents download their part of updates automatically from a shared folder of the Protection Server. The task is very simple, it has only one parameter: the update schedule. All standard Kaspersky Security Center schedules are supported, including On virus outbreak, On completing another task and When new updates are downloaded to the repository. Considering the fact that Protection Servers are relatively few, the latter option is recommended, because it will not place much load on the network.

39 Chapter 1. Deployment 37

40 38 KASPERSKY LAB Network organization KL Kaspersky Security for Virtualization. Light Agent Light Agents learn about the location of Protection Servers from multicasts. Routing of multicast packets between subnets depends on network equipment, physical or virtual. In some cases, the Light Agents will be able to receive packets from the Protection Server, and in some cases the administrator will need to take additional actions. If multicast packets cannot pass between subnets, two solutions can be used. The easiest method is to add the necessary number of network adapters to the Protection Server and connect them to the respective subnets. However, this solution is hardly scalable. Virtual machine parameters are modified manually (sometimes, the process can be automated, but this will still require time), and this solution is not applicable to large infrastructures with numerous networks. Protection Servers must be able to multicast not only within the hypervisor, but also to neighbors (or better yet, to all hypervisors), so that in case of a failure, the Light Agents can switch to an operational Protection Server. And even if you do not need to provide for fault tolerance, don't forget that virtual machines working within the same hypervisor may belong to different subnets. Besides, guest machines may be dynamically relocated between physical servers, and you will need to provide for all possible combinations. A more universal method is to configure the network equipment to forward multicast packets by enabling IGMP proxy. The implementation depends on the specific router.

41 Chapter 1. Deployment 39

42 40 KASPERSKY LAB 1.3 Deployment of Light Agents Deployment stages KL Kaspersky Security for Virtualization. Light Agent Preparation for installing the Light Agents includes two parts: required and optional (but desirable). The former comprises installation prerequisites: Plug-in To be able to create policies and tasks, and configure the installation package of the Light Agent, it is necessary to install the corresponding plug-in for the Administration Console; Installation package of the Light Agent The Light Agent package is not included in the Administration Server repository by default; it is necessary to add it using the standard wizard; The rest of the preparation depends on the use of the virtual infrastructure and network status. Generally, the administrator must ensure that correct security settings are applied right after the installation. A structure of management groups, policies and tasks are created for this purpose. The groups are necessary if different computers require different security settings. Different policies can be created for them. Critical tasks (update and license installation) are created for the Protection Server, and Light Agents will be able to immediately use up-to-date databases. The process of deploying protection on guest machines depends on the major virtualization scenario. On virtual servers (persistent virtual machines), the product is deployed similarly to Kaspersky Endpoint Security. The administrator creates and runs a remote installation task that deploys the Light Agent and the Network Agent on the protected machines. If VDI is used, the administrator needs to install the Light Agent and the Network Agent only on the template virtual machine. For non-persistent machines, the dynamic mode for VDI is to be enabled in the Network Agent settings, and the corresponding optimization should also be enabled. This can be done during the local installation of the Network Agent. As soon as the template is ready, the whole VDI pool can be recreated based on the new image. As a result, all virtual machines will be protected.

43 Chapter 1. Deployment 41

44 42 KASPERSKY LAB Preparation KL Kaspersky Security for Virtualization. Light Agent The Light Agent package is not included in the standard distribution of Kaspersky Security Center, it has to be added manually. A standard package adding wizard serves this purpose in Kaspersky Security Center. To start it, click the Create installation package link in the Remote installation / Installation packages node. Select the Create installation package for a Kaspersky Lab application option in the wizard. By default, a kud/kpd description file is offered to be selected in the application folder. However, the packages are usually supplied in selfextracting archives; that is why the Open window also allows selecting an archive. The package will be unpacked automatically on the Administration Server. Updates copying should be disabled in the package. Updates are distributed by the Protection Server, and pre-installed databases will only place extra load on the network and increase the package creation time. If the Light Agent plug-in has been installed before adding the package, the wizard will offer to select the application components. This step is almost the same as in the Kaspersky Endpoint Security installation wizard, except for the encryption components that are not included in the Light Agent. Similar to KES 10, several installation options are available: Standard all components will be installed; Basic only the protection components will be installed, without controls; Custom you can select any combination of components. Installation on persistent machines From the installation point of view, persistent machines can be regarded as physical computers. In this case, the Light Agent is installed the same way as Kaspersky Endpoint Security. The administrator selects the virtual machines where it is necessary to deploy protection, specifies the accounts allowed to install applications, and creates a task that will deploy the Light Agents together with the Network Agents. The license need not be specified in the installation task.

45 Chapter 1. Deployment 43

46 44 KASPERSKY LAB Installation on non-persistent machines Non-persistent VDI machines KL Kaspersky Security for Virtualization. Light Agent Virtualization of workstations (mainly, VDI Virtual Desktop Infrastructure) allows enterprises to simplify and centralize management, and also enable employees to work with familiar environment remotely and almost from any device (BYOD model, Bring Your Own Device). The desktop and applications become a service, for which only a small client and an appropriate connection are necessary. VDI is based on a template (a master image). A set of virtual machines is created from the template by cloning. Actually, each user is provided with a copy of the same virtual machine, only personal settings and data may be loaded from an individual storage. The administrator need not bother about upgrading or installing new software on all workstations. Instead, only the template is to be modified, and the whole set of virtual machines will be recreated from it. There are various types of VDI installations. Virtual machines may be assigned to the users, or may be allocated randomly. In the latter case, after a session is finished, virtual machines usually roll back to the initial state and all the changes made by the user are deleted. These virtual machines are called non-persistent. If Kaspersky Security Center treats such machines the same way as typical computers, its database will quickly be filled with phantom hosts that connected to the Administration Server some time ago, but were then deleted. It also concerns the data related to these hosts. The Network Agent gathers information about the installed applications, hardware, missing Windows Updates and found vulnerabilities, and sends it to the Administration Server. Moreover, since all virtual machines are alike, this data need not be gathered. The whole set of applications is known in advance because is installed from a single template, and the list of hardware is also of no use, because virtual machines use standard devices allocated by the hypervisor, which has nothing to do with real server hardware (except for the processor and, maybe, some other data). The administrator does not need events from a deleted VDI virtual machine either. No machine nowhere to investigate incidents and solve issues. There are also some additional complexities. First, the Advanced Disinfection technology cannot be used on a nonpersistent machine, and module updates cannot be installed either: both require a restart. Second, the Administration Server is not able to distinguish between the Network Agents of the virtual machines deployed from a single image. All of them will have the same identifier, and will be displayed as copies of the same machine in the Administration Console (the computer name will be supplemented with a tilde and a running number).

47 Chapter 1. Deployment 45

48 46 KASPERSKY LAB Dynamic mode for VDI KL Kaspersky Security for Virtualization. Light Agent All these issues are solved by using a special mode of the Network Agent: dynamic mode for VDI. When a virtual machine is shut down, the Network Agent working in the dynamic mode sends a special signal to the Administration Server. As a result, the following information is deleted: Computer from the Administration Server database; Its events; Objects from the repositories (Backup, Quarantine, Unprocessed objects); Network lists (hardware, installed applications, Windows Updates, Vulnerabilities). Even if a virtual machine is just turned off and the Agent cannot send a signal to the Administration Server, the abovementioned information will be deleted upon the visibility period expiration. Also, the Network Agent will change its identifier at startup, for the computers not to be mixed up in the Administration Console. Dynamic mode for VDI is enabled during the installation and cannot be disabled in the policy later. The corresponding option is available in the local installation wizard. Additionally, the administrator can select the Optimize Kaspersky Security Center Network Agent settings for virtual infrastructure option, which means that network lists (hardware, installed applications, etc.) will not be sent to the Administration Server. Certainly, you will also need to disable sending network lists in the policy of Network Agent, but in this case we are talking about the default settings that will be applied before the policy settings are received from the Administration Server. It is especially important for the performance when the virtual machine starts, because the Network Agent will not try to define the installed hardware, applications, etc. A Network Agent that will work in the dynamic mode can also be installed remotely from Kaspersky Security Center. For this purpose, open the properties of the Network Agent package in the Administration Server repository and in the Advanced section, select the Enable dynamic mode for VDI checkbox. Lists sending cannot be disabled in the package.

49 Chapter 1. Deployment 47

50 48 KASPERSKY LAB Chapter 2. Management KL Kaspersky Security for Virtualization. Light Agent 2.1 Management Principles of Kaspersky Security for Virtualization The functionality of Kaspersky Security for Virtualization resembles that of Kaspersky Endpoint Security, but is divided into two parts: Light Agent and Protection Server. Management is also similar. Kaspersky Security for Virtualization is also managed via Kaspersky Security Center, it has tasks and policies; however, they pertain to two different (from Kaspersky Security Center s viewpoint) products. The Protection Server has: Update tasks because files are scanned on the Protection Server; License installation task it is logical from the management point of view; Regulation of the use of KSN Kaspersky Security Network is for the most part employed for scanning files. The rest is configured on the Light Agent side: Protection policy; Controls; Virus Scan Task. Creating Managed Computers structure To be able to efficiently manage virtual machines protected by Kaspersky Security for Virtualization, the administrator should create a structure of administration groups with respective tasks and policies. It is recommended to group virtual machines as follows: Protection Servers; Persistent virtual machines (if any); Non-persistent virtual machines (if any). The Protection Server requires specific policies and tasks. It considerably differs from the Light Agents and Kaspersky Endpoint Security, since users do not work there and its local file system need not be protected. For a Protection Server, it is logical to configure statuses different from those configured for Light Agents, and also create individual report templates in Kaspersky Security Center. Separation of persistent virtual machines from non-persistent is necessary because their lifecycle and major scenarios differ drastically. Persistent machines work for a long time, months and years, and, in substance, do not differ from physical computers. They need to be scanned for viruses; operating system updates and vulnerabilities should be controlled. By contrast, the lifetime of a non-persistent machine is one session only. Such a machine need not be scanned for viruses; and it is the template where updates are installed and vulnerabilities are fixed. As a result, virus scan, vulnerability and inventory tasks need to be created only for the group of persistent machines. A protection policy can be applied to all protected virtual machines.

51 Chapter 2. Management 49

52 50 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Groups can be filled automatically with the help of relocation rules. In Kaspersky Security Center, you can configure various criteria for moving computers into groups: for example, network parameters, or membership of a group or unit in Active Directory. Virtual machines can be separated from physical, and virtual machines running on one platform (for example, ESXi, Hyper-V) from virtual machines running on another platform. This information is delivered to the Administration Server by the Network Agent. The corresponding settings are located on the Virtual machines tab of a relocation rule. Another parameter on this tab is whether a virtual machine is a part of VDI. It allows finding the machines where a Network Agent working in dynamic mode for VDI is installed. This parameter helps to separate non-persistent machines from persistent. Protection Servers can be grouped by the operating system type and Network Agent availability. Protection Servers are running Linux, while protected machines various versions of Microsoft Windows. All of them have Network Agent installed.

53 Chapter 2. Management 51

54 52 KASPERSKY LAB 2.2 Configuring Protection Parameters File scanning algorithm KL Kaspersky Security for Virtualization. Light Agent Operation principles of the Light Agent presume that various components participating in file scanning are distributed between the Protection Server and guest virtual machines to ensure best performance and efficiency. A network request for file scanning always takes more time than checking locally stored exclusions and/or cache; additionally, these operations are not resource-consuming. For this reason, the Light Agent processes exclusions and maintains a local iswift cache, while the Protection Server scans files. It also maintains the Shared cache, which stores information about scanned files from all connected guest virtual machines. The scanning algorithm is as follows. File operations are intercepted by the corresponding component: File, Mail, Web or IM Anti-Virus. The same tools are used as in Kaspersky Endpoint Security 10, for example, File Anti-Virus employs the klif.sys driver. The object is blocked and checked against the exclusions configured by the administrator. In this case, protection policy allows using masks or environment variables, unlike that of Kaspersky Security for Virtualization 2.0, whose VMware vshield Endpoint thin agent is not able to process them. If the object does not match any exclusions, iswift checks whether it has been changed since the previous scanning and whether it needs to be rescanned. If yes, a scan request is sent. The request is transferred to the Protection Server instead of the local virus scan engine used in Kaspersky Endpoint Security. The scan settings specified for the Light Agent in Kaspersky Security Center policy are also transferred to the Protection Server (there are few of them, for example, heuristics level, archive scanning). If ZIP and RAR archives are scanned, the Light Agent unpacks them and sends the unpacked files to the scanner one by one. If threat is detected in one of the objects, it can delete the malicious file and repack the archive without it. For other types of archives, such disinfection is not supported, and they are deleted entirely. The Protection Server first checks whether the file has non-zero size, then checks it against the shared cache. If the file needs scanning, the request is transferred to the virus scan engine. It returns a verdict, based on which the action specified in the policy is taken. If the file is clean, this information is added to the shared cache and to the iswift cache on the guest virtual machine. Scan optimization technologies iswift There are several methods that allow improving Anti-Virus scanning performance without decreasing the security level. For example, exclusions and caching. Let us study the latter. The idea behind caching is to avoid unnecessary scanning. If a file has already been scanned and is being accessed again, it need not be scanned unless the databases have been updated meanwhile. If the file is accessed after the databases are updated, it will be rescanned. This way, if an infected file gets cached, it will be deleted from the cache as soon as scanned with the databases to which the threat has been added. Kaspersky Security for Virtualization uses two caches: one on the side of the guest virtual machine (iswift), and the other shared cache on the Protection Server. The iswift technology uses the information from NTFS file system to monitor changes in the files, and this approach is rather efficient: the checksum need not be counted. Frequency of objects rescanning is regulated by socalled quarantine periods, which gradually increase if the file is not changed. The iswift technology is used by realtime protection and on-demand scan tasks.

55 Chapter 2. Management Shared cache The shared cache allows additionally reducing the number of scan requests. If a file has been scanned on one of the virtual machines, this information immediately becomes available to all Light Agents connected to the corresponding Protection Server. Best performance is achieved on the hypervisors where VDI virtual machines are running. They have almost identical configuration and files, because are created from the same image. Cache is a database stored in the memory of the Protection Server for quick access. It is cleared after a restart. There is a limitation on the number of records; when reached, the least frequently used records are replaced with new. Let us study the main principles according to which the shared cache operates: Hash of the full file path is used Path hash is counted quickly, unlike MD5 checksum. File properties are taken into account (creation and modification dates, size) This ensures that the cached record describes this specific version of the file. So, changes in a cached file will be discovered even if connection to the Protection Server is temporarily lost The timestamps of the antivirus databases employed for the first and last scanning are recorded Are used in the rescanning algorithm (see later in this document) Settings of the Light Agent with which the file was scanned are considered The information about the protection profile under which the object was scanned is also stored in the cache, and if the settings are hardened, the file will be rescanned even if it has not been changed. In some cases, cache is not used: On the file close operation All objects are always scanned on closing, because the file might have been changed. The objects stored on network resources or removable drives Such objects are not cached. Otherwise, it would be possible to connect a USB flash drive to a virtual machine protected by Kaspersky Security for Virtualization, its files would be scanned and cached, then modify them on an unprotected computer and avoid scanning at the next connection. Certainly, it is necessary to take care that the size, creation date and modified date of the files are exactly the same as before, but they can be spoofed. Virus Scan Task The virus scan task scans all objects. The scanning results are also cached to be used by real-time protection. After the first scanning, the file record is added to the cache, including the timestamp of the databases used for scanning. Then the file is not re-scanned: the cache data is used. After the Protection Server receives new databases, cached records cannot be used already, and the object is rescanned as soon as any virtual machine sends the corresponding request. The timestamp of the databases used for scanning is also cached. As a result, two records with database timestamps are stored on the Protection Server already: those of the first and last scanning. Then the file is not scanned again until newer databases are downloaded, and after an update and repeated scanning, the date of the last used databases is updated in the cache. This algorithm is used until the difference between the timestamps of the databases used for the first and the last scanning is less than 48 hours. After that, the file is not scanned until the Protection Server is restarted. 53

56 54 KASPERSKY LAB Detection technologies KL Kaspersky Security for Virtualization. Light Agent When scanning a file, Kaspersky Security for Virtualization uses the same tools as the File Anti-Virus of Kaspersky Endpoint Security for Windows. Signature analysis is the foundation of the scanning procedure, which is performed the first. If threats are not detected, heuristic analysis is performed. It uses the emulator that runs a set of statements against the object to understand how it behaves when started. The deeper the heuristics level, the more statements are run and the more accurate verdict returned, but performance decreases. In the end, the KSN check is performed. The file checksum is calculated for the KSN request, which is first checked against the local cache. If the record is found there, the corresponding verdict is returned; otherwise, the request is sent to the KSN cloud. Depending on the results returned by the first two technologies, a so-called synchronous or asynchronous request is sent to KSN. The former is used if a threat was found in the object, and the file is blocked until the verdict is received from KSN. If the primary verdict was clean, access is allowed, and the KSN request is sent in the background. In either case, the verdict from KSN is ultimate, regardless of the results returned by the other technologies. The received verdict is saved in the local KSN cache. If the answer is not received upon timeout, the verdict received at a previous stage is considered to be final. On-demand scan tasks use only synchronous KSN requests. Similarly to Light Agents, Protection Servers do not establish external connections. The KSN proxy of Kaspersky Security Center is used instead. If KSN proxy is disabled in Kaspersky Security Center, Kaspersky Security for Virtualization cannot use this technology either.

57 Chapter 2. Management 55

58 56 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Comparing settings of Kaspersky Endpoint Security and Kaspersky Security for Virtualization Policies Settings of Kaspersky Security for Virtualization are almost completely copied from Kaspersky Endpoint Security. The policy of the Light Agent also looks and is structured similarly to Kaspersky Endpoint Security policy, and an administrator who has some experience with KES 10 will easily get used to the virtualization protection solution. The following parameters that are not applicable to Kaspersky Security for Virtualization are missing from its settings: File Anti-Virus section ichecker the main purpose of using ichecker in Kaspersky Endpoint Security is caching results of scanning FAT32 file system, which is mainly used on removable devices. This scenario, however, is rare in virtual environments; therefore, ichecker is not used; Application settings section Do not start scheduled tasks while running on battery power not applicable to a virtual environment; Use proxy server for activation the Light Agents do not require activation, licensing information is received from the Protection Server; Proxy server settings the Light Agents do not use it; Reports and storages section Inform Administration Server about file encryption events encryption components are not included in the Light Agent; The iswift technology parameter in the File Anti-Virus Settings Additional section works differently. It is responsible not only for the use of local iswift cache on the Light Agent side, but also for the use of shared cache on the Protection Server. The Light Agent, when transferring a file for scanning, can also specify whether a request is to be sent to the shared cache. Since protection components are divided into two parts (Protection Server and Light Agent), the settings of Kaspersky Endpoint Security policy are also divided similarly, and the KSN settings section is located in the Protection Server policy. It is the only section in the Protection Server policy over and above the standard general settings and events settings. The administrator can independently enable the use of KSN for file scanning and categorization and/or for scanning links. On the Light Agent side, KSN requests are made by the following components: File categorization: Application Startup Control; Application Privilege Control; System Watcher; Link scanning and categorization: Web Anti-Virus; IM Anti-Virus; Web control. On the Protection Server side, KSN is used when scanning files. So, the settings of the Protection Server are applied to two different (from Kaspersky Security Center viewpoint) products. The Light Agent has no access to the Protection Server policy; that is why it asks the Protection Server every 15 minutes whether to use KSN.

59 Chapter 2. Management 57

60 58 KASPERSKY LAB Tasks KL Kaspersky Security for Virtualization. Light Agent The tasks settings of Light Agent and Kaspersky Endpoint Security are also similar. Both products have Virus scan, Inventory and Change application components tasks. Update and License installation tasks pertain to the Protection Server; they were described earlier. The Light Agent inventory task is absolutely identical to its counterpart of KES 10. Virus scan tasks, however, have some specifics in the Light Agent. They do not use ichecker, and do not scan either files or password-protected archives. Memory, registry and rootkit scanning works similarly to KES 10.

61 Chapter 2. Management 59

62 60 KASPERSKY LAB 2.3 Protection Monitoring KL Kaspersky Security for Virtualization. Light Agent Kaspersky Security for Virtualization is similar to Kaspersky Endpoint Security not only in the settings. Protection monitoring is also alike. The administrator can use standard Kaspersky Security Center tools: Reports Statistics Events Selections Repositories You only need to take into account partition of the functionality between the Protection Server and the Light Agent. Specifically, a license is installed on the Protection Server and license use is also counted by Protection Servers. This information is then sent to Kaspersky Security Center and can be found in the reports. Depending on the key type, the report shows how many physical cores are installed on the protected hypervisors, or how many virtual machines are using the licenses per nodes and which type: server or workstation. You can also find information about the number of licenses used on each Protection Server individually. For this purpose, in the properties of the Keys report, on the Detail fields tab, add one or a few fields: Licensing units covered how many processor cores are installed on the physical server where Protection Server works; Licensing units covered for workstations how many virtual machines with client operating systems use the license on the protected hypervisor; Licensing units covered for servers how many virtual machines with server operating systems use the license on the protected hypervisor.

63 Chapter 2. Management 61

64 62 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Protection Server learns about the configuration of physical server processors by sending a request to the hypervisor. The number of nodes using a license is somewhat more complicated. When the Light Agent connects to the Protection Server for the first time, it receives a ticket with information about the license. The Light Agent prolongs this ticket every two hours; if it does not, it means that the virtual machine has either been shut down or moved to another host and the Protection Server vacates the ticket. The information about active tickets and the operating system type (workstation or server) is sent to the Administration Server. Another type of reports that has its specifics is the report about Anti-Virus databases statuses. The report includes data from Protection Servers and Light Agents. Versions of databases may vary in these products, because they have different update task schedules and different sources. Maintaining the databases up-to-date on the Protection Server is a critical task of the administrator, because Protection Servers scan files and are responsible for distributing updates to the Light Agents. For this reason, it is desired to create an individual report about Anti-Virus database statuses for the Protection Servers group only, since the administrator cannot influence the database update process on the Light Agents. Files are scanned on the Protection Server, but threat detection events are entirely related to the protected virtual machines, like in Kaspersky Endpoint Security. When working with non-persistent virtual machines, remember that the information about detected threats is stored during the user session only. Afterwards, the events are deleted, and the incident disappears from the Viruses report.

65 Chapter 2. Management 63

66 64 KASPERSKY LAB Chapter 3. Scaling and Maintenance 3.1 Scaling Protection Server Resources KL Kaspersky Security for Virtualization. Light Agent One of the main issues of traditional protection solutions for virtual environments are various storms, when the same task starts on all guest virtual machines simultaneously. First of all, this concerns on-demand scan tasks, which are especially resource-consuming and can quickly decrease hypervisor performance. In Kaspersky Security for Virtualization 2.0, this issue is solved by limiting the number of machines that can be simultaneously scanned by a task. Kaspersky Security for Virtualization 3.0 Light Agent employs another approach. The administrator limits the resources that the Protection Server can use for processing scan requests. It specifically concerns the consumed RAM and processor time. The more resources are allocated, the more objects can be scanned simultaneously. On the other hand, the Protection Server may place too much load on the hypervisor s RAM and CPU and indirectly influence the disk subsystem, because the more requests it can process, the faster the Light Agents will give files for scanning and more often access the file system. Changing the number of virtual processors or the amount of RAM allocated to a Protection Server does not provide enough flexibility for fine-tuning the system to specific requirements. The stream of scan requests can be limited programmatically by queuing. If the number of scan requests from the Light Agents exceeds the specified limit, these requests are queued. The Light Agents have to wait for their files to be scanned, and the load on the hypervisor does not reach critical values. On the other hand, the more objects can be scanned simultaneously on the Protection Server, the less the real-time protection of the guest virtual machines is delayed, and the less time is necessary for on-demand scanning. The limitation on simultaneous processing of requests is set by the max_processor_threads parameter (the maximum number of processor threads) in the configuration file /etc/opt/kaspersky/la/scanserver.conf on the Protection Server, and the queue size is set by the max_request_queue_length parameter; it is rather large by default (10000) and does not need to be modified. Configuring Protection Server parameters on powerful servers with numerous virtual machines requires balancing the resources allocated per virtual machine (the number of processors and RAM) against the program limitations on the stream of requests. RAM must not be used up; otherwise, the operating system will start using the swap file, which will result in drastic performance decrease of the virtual machine. In this case, you had better reduce the number of processor threads. The reverse situation when too many resources are allocated to a virtual machine and they underwork is also unwanted. The default values for the Protection Server are selected so that to provide best performance for a hypervisor with 50 to 70 VDI virtual machines: 2 virtual processors 2 GB RAM 75 processor threads.

67 Chapter 3. Scaling and Maintenance 65

68 66 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent Generally, Protection Server parameters can be calculated based on the number of VDI guest machines: Where vcpu = VMs/40, but no less than 2 and no more than the number of physical cores on the host (taking into account HyperThreading). ProcessorThreads = VMs*1.5, but at least 50 RAM = 1 GB + (ProcessorThreads -25)/50 vcpu is the number of virtual CPU allocated to the Protection Server; VMs the number of protected virtual machines; RAM the recommended memory allocated to the Protection Server; ProcessorThreads the max_processor_threads parameter. For example, for a hypervisor with 120 virtual machines, the Protection Server parameters should be as follows: vcpu = 120/40 = 3 ProcessorThreads = 120*1.5 = 180 RAM = 1 + (180 25)/50 = 4.1 It is recommended to configure static MAC for the protected virtual machines if their number exceeds 70 under Hyper-V (because of its specific behavior with a large number of running virtual machines). Optimal SVM parameters for server virtualization vary considerably, because the load on the server heavily depends on its role. Servers are more powerful than workstations, and there are less of them on the hypervisor; additionally, it is necessary to take into account how the Light Agents work with the Protection Server. To send files for scanning, the Light Agent establishes a particular number of connections to the Protection Server. The more connections can be established, the more data can be transferred per unit of time. In most cases, the default settings of the Light Agent need not be changed, but for heavily loaded virtual machines with frequent disk transfers the number of allowed connections to the Protection Server can be increased. The parameters can be configured in the registry on the protected virtual machine. They cannot be managed centrally. The default values are 10 for real-time protection (the oasconnectionsperserver key), and 2 for on-demand scanning (the odsconnectionsperserver key). As you can see, real-time protection has higher priority than on-demand scanning. The settings can be found in HKLM\Software\KasperskyLab\protected\KSVLA3\profiles\AVProxy\settings\def (on a 32-bit operating system); HKLM\Software\Wow6432Node\KasperskyLab\protected\KSVLA3\profiles\ AVProxy\settings\def (on a 64- bit operating system). These parameters can be modified only when the Light Agent s self-defense is off. If the stream is large, the Protection Server may fail to scan all files in time. If an object has been intercepted by real-time protection, it remains blocked for the user while waiting for scanning, and upon timeout (30 seconds) the file will be skipped. If the request is sent by an on-demand scan task and is not transferred for scanning in 30 seconds, it will be skipped, and the task will proceed. If all connections are busy on the Light Agent, the object will wait for 30 seconds, after which a scan error will be returned. All scan requests sent by real-time protection that are skipped for some reason (if the Protection Server is inaccessible, or upon timeout) will be queued for rescanning. They will be processed as soon as possible. Ondemand scanning will not try to re-scan the skipped files.

69 Chapter 3. Scaling and Maintenance 67

70 68 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent 3.2 Specifics of Protection Server Discovery by Light Agents Protection Servers notify the network about themselves by multicasting on top of the UDP protocol. The Protection Server sends its packets to every 10 seconds. The Light Agents listen on this address and thus learn about Protection Servers. The nodes interact within the framework of IGMPv2 protocol on Windows XP, and IGMPv3 on Windows Vista or later. To receive the multicast traffic, inbound connections must be allowed on UDP 9876 of the virtual machines with the Light Agents. Each multicast packet by Protection Server contains the following data: IP address and port where the Light Agents are to connect; Identifier of the protected hypervisor; The number of connected Light Agents; SVM version; Hypervisor type. The server detection algorithm is as follows: The Light Agent listens for inbound multicasts from various Protection Servers. The Light Agent selects a Protection Server to connect: 2.1. When the Light Agent receives a packet, it asks the Protection Server whether they are located on the same hypervisor. For this purpose, it sends the Protection Server the id of the protected virtual machine 2.2. If the Protection Server and the Light Agent are located on the same hypervisor, searching for the Server is finished. This is the main Protection Server. Interaction with the main Protection Server requires minimal network interaction overhead If 20 seconds after the first packet is received the main Protection Server is not found or is not accessible, the Light Agent selects a Protection Server with the fewest Light Agents connected If the connection cannot be established at step 2.3, the next least loaded Protection Server is selected, etc. The Light Agent attempts to connect to the selected Protection Server on port TCP If the Light Agent connected to another Protection Server receives a packet from the main server, it switches there. If the Light Agent is moved to another hypervisor, it all starts at step 2. The Light Agent "asks" the Protection Server whether the hypervisor has been changed every 5 minutes. If connection is lost, the Light Agent connects to the first Protection Server that sends a packet.

71 Chapter 3. Scaling and Maintenance 69

72 70 KASPERSKY LAB Assigning Protection Server to Light Agent KL Kaspersky Security for Virtualization. Light Agent In some cases, dynamic detection is unwanted and Light Agents must be bound to a particular Protection Server. It can be done by modifying the registry of the virtual machine where the Light Agent is installed. The Light Agent s branch is: HKLM\Software\KasperskyLab\protected\KSVLA3, on a 32-bit operating system; HKLM\Software\Wow6432Node\KasperskyLab\protected\KSVLA3, on a 64-bit operating system. The use of multicast is regulated by the profiles\remoteservicesprovider\settings\discoveryenabled key, REG_DWORD (32-bit). Value 0 means that detection of Protection Servers is disabled. After disabling the detection, it is necessary to specify the address of the Protection Server to which the Light Agent must connect. It is to be specified twice: In the profiles\avproxy\settings\def\avservers\0000 REG_SZ key with <IP address>:9876 value In the profiles\remoteservicesprovider\settings\remoteservicesaddress REG_SZ key with <IP address>:9876 value Before making changes to the registry, disable self-defense of the Light Agent.

73 Chapter 3. Scaling and Maintenance 71

74 72 KASPERSKY LAB KL Kaspersky Security for Virtualization. Light Agent 3.3 Protection Servers and Load Balancing in Cluster One of the main advantages of clusters in virtual environments is that resources are joined into a single pool. The administrator need not monitor on which host a virtual machine is running. The virtualization platform takes up the management and decides which host will provide its computational resources. Load balancing policies can automatically move virtual machines from a more loaded host to a less loaded. It is also possible to move all virtual machines from the least loaded host to the others and then turn it off. It is especially useful at night and helps to reduce energy costs. A Protection Server is most efficient if the Light Agents connected to it are located on the same host with itself. Maintenance of a group of hypervisors with one SVM is technically possible, but is not reasonable because of the network interaction expenses. Several Protection Servers running on the same physical server are also unwanted, since the Light Agents will continually switch between the main Servers, which will reduce scanning performance. When installed in a cluster, Protection Servers must not migrate to prevent a situation when there are no Protection Servers on a host at all, or, on the contrary, several. Additionally, it is extremely important to provide automatic start of the Protection Server together with the hypervisor to ensure protection when the physical server is restarted for maintenance or as a result of a failure. Let us study how these requirements can be fulfilled on various virtualization platforms. VMware vsphere This case is the simplest one. The installation wizard makes the necessary changes in the configuration of the cluster and the ESXi host. Let us examine these changes. Load balancing in VMware vsphere is provided by the Distributed Resource Scheduler (DRS) service. It is configured at the cluster level. The DRS policy can be overridden for individual machines on the VM Overrides (select the cluster, then Manage Settings), it is disabled for the Protection Server. Automatic start is configured in the properties of the ESXi host (Manage Settings VM Startup/Shutdown).

75 Chapter 3. Scaling and Maintenance 73

76 74 KASPERSKY LAB Microsoft Hyper-V KL Kaspersky Security for Virtualization. Light Agent In Microsoft products, dynamic load management is provided by the Performance and Resource Optimization and Dynamic Optimization technologies implemented in the System Center Virtual Machine Manager. The installation wizard does not interact with SCVMM; that is why the administrator has to manually exclude the Protection Server from the balancing policy. For this purpose, in the properties of the virtual machine, on the Actions tab, enable the Exclude virtual machine from optimization actions option. On Hyper-V, automatic start of virtual machines together with the host is enabled by default for all machines, including the Protection Server. However, the guest machine starts only if it had been running before the hypervisor was turned off. You make the hypervisor start the Protection Server regardless of whether it had been running. For this purpose, open the virtual machine properties on the Actions tab and change the default value to Always automatically turn on the virtual machine.

77 Chapter 3. Scaling and Maintenance 75

78 76 KASPERSKY LAB Citrix XenServer KL Kaspersky Security for Virtualization. Light Agent In a resource pool, every host can have a local repository of its own (unavailable to other hosts). A Protection Server installed in the local repository cannot be moved. A shared repository can be connected to the pool. If a shared repository is used, virtual machines are not bound to a specific host and may be run on any one having enough free RAM. The Protection Server is no exception. Several Protection Servers may run on one of the hosts, and none on another one; that is why it might be worthwhile to assign a priority host where the virtual machine will start. For this purpose, open the machine properties in XenCenter and select the necessary node on the Home Server tab.

79 Chapter 3. Scaling and Maintenance 77

80 78 KASPERSKY LAB 3.4 Device Control KL Kaspersky Security for Virtualization. Light Agent Work with a virtual workstation does not mean that you will not use physical devices. Quite often, you need to print out a document, save a file to a USB flash drive or a local drive or even connect a microphone and a webcam. All the vendors we have mentioned provide the capability to use various devices via a client program: View Client (VMware), RDP client (Microsoft), and Citrix Receiver (Citrix). Enterprises need to control the devices connected to the network. If a workstation where a removable drive is connected provides access to important information, it needs protection regardless of whether it is physical or virtual. Accessing devices in a virtual environment Implementation of access to the devices varies; it depends not only on the vendor, but also on the client settings. For example, on both RDP clients and Citrix Receiver local drives, DVD drives and USB flash drives are mounted as special System Folders on Windows by default. They are indistinguishable from other folders for the guest operating system and consequently for the Device Control of the Light Agent. The client transfers to the virtual machine only information about media contents, but does not give any data about the media itself. This schema requires that the VDI client supports the device and that drivers are installed on the computer from which access is initiated. For USB devices, however, a more universal method is available, which all the described vendors support: low-level data redirection from the USB port. This way, users can connect almost any USB device. These devices are recognized by the operating system of the virtual machine as if they were connected directly, and the Light Agent can correctly define their type. However, access universality is accompanied with management difficulties. The VDI client is not responsible for defining the device and the administrator loses fine-tuning capabilities. To be able to use the Device control, the administrator is to prohibit high-level access and allow only low-level data redirection. We will explain it in more detail later, together with comparing the device control tools provided by the described vendors.

81 Chapter 3. Scaling and Maintenance 79

82 80 KASPERSKY LAB Policy for RDP client KL Kaspersky Security for Virtualization. Light Agent An RDP client is a universal tool for remote desktop connections. The user can select the type of the devices to be accessible on the virtual machine: Drives (hard drives, DVD drives, removable USB drives); Supported Plug and Play devices; Clipboard; Printer; Audio devices. Limitations are configured in the group policy: Computer configuration \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Session Host \ Device and Resource Redirection. The administrator can specify permissions for various types of supported devices (from audio to smart cards) here. Connection of printers is regulated in the neighbor branch, Printer Redirection. The policy can be assigned to the group of computers that require RDP access. Low-level redirection is provided by RemoteFX. This technology is supported in RDP version 7.1 or later (under Windows 7 SP1 or later). Its use is regulated by the group policy: Computer configuration \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Connection Client \ RemoteFX USB Device Redirection, is disabled by default. However, USB redirection in RemoteFX is considered rather as an addition to the standard high-level access; that is why, for example, removable USB media do not work by default even with the corresponding group policy configured (see the Microsoft knowledgebase article at To add their support, carry out the following command on the computer with the RDP client: reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client\UsbSelectDeviceByInterfaces" /v 101 /t REG_SZ /d "{A5DCBF D2-901F-00C04FB951ED}" /f, Where 101 is the unique identifier of the key, and the long number in the brackets GUID of USB devices. At the same time, it is necessary to disable the use of traditional redirection method. For example, for local drives, USB flash drives and optical drives, this is regulated by the Do not allow drive redirection parameter in Computer configuration \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Session Host \ Device and Resource Redirection.

83 Chapter 3. Scaling and Maintenance 81

84 82 KASPERSKY LAB Policy for Citrix Receiver KL Kaspersky Security for Virtualization. Light Agent Citrix has a client for accessing virtual infrastructure, Citrix Receiver. It is used together with XenApp and XenDesktop, the VDI solution by Citrix. We are interested in the latter only, because XenApp is responsible for providing access to applications rather than virtual machines. XenDesktop has an administration console named Citrix Desktop Studio. It allows monitoring infrastructure status, creating virtual machine pools, managing them, assigning users, etc. Policies for HDX (High Definition Experience) are also located here. This technology was designed by Citrix to improve efficiency of transferring data via the Internet (first of all, graphics and multimedia); however, the same principles are applicable to peripheral devices or local drives. It is based on the ICA protocol by Citrix. There are HDX policies for computers and users. A user policy allows the administrator to define types of devices that can be redirected by the client. Available options include local drives, optical drives, network folders, USB devices, etc. The corresponding settings can be found in the ICA\File Redirection and ICA\Printing branches. Management capabilities are even wider than in Microsoft Active Directory here, because a policy can be applied not only to individual users, their groups, and Active Directory units, but also to clients IP addresses, their types and pools of virtual machines. USB redirection is enabled by the Client USB Device Redirection parameter in the ICA\USB Devices branch of HDX policy. Standard redirection of removable drives can be disabled using the Client Removable Drives parameter in ICA\File Redirection; the same can be done for other devices, too. VMware View Client policy A solution for VDI by VMware is named Horizon View. It is a multifunctional solution that provides wide capabilities. Sets of virtual machines are called pools. The administrator assigns users or groups from Active Directory having access to a pool, and then configures policies for pools. Unlike Microsoft and Citrix, the VMware client supports only low-level redirection for connecting devices, that is why you can only enable or disable USB redirection in the policy. Here, the Device Control of the Light Agent comes in handy for fine-tuning.

85 Chapter 3. Scaling and Maintenance 83