S 4.413 Secure use of virtualisation using Hyper-V

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Head of IT, Specialists Responsible

The secure use of virtualisation with Hyper-V is based on the implementation of the planning safeguards (see S 2.490 Planning the use of virtualisation using Hyper-V) and the module M 3.40Y Virtualisation, here especially the safeguard S 4.v7 Secure operation of virtual infrastructures and S 5.154 Secure configuration of a network for virtual infrastructures. The present safeguard shows the aspects specific to the Hyper-V to be installed. The following aspects are focussed on:

The guests themselves require only a few Hyper-V-specific modifications.

To secure the management instance and the configuration and to implement the authorisations, Microsoft offers a detailed documentation, which should by all means be used, providing the Hyper-V Security Guide and the online resources referenced there.

Management instance

The hardening of the management instance is based on the reduction of the points of attack by means of a basis with reduced functionality (see S 2.490 Planning the use of virtualisation using Hyper-V). The Server Core (see S 4.416 Use of Windows Server Core) and the stand-alone Hyper-V server are particularly suited for this purpose.

Without such a basis, at least the SSLF (Specialized Security Limited Functionality) baseline should be used. It can also be used in addition to such a basis.

The SSLF baseline must be applied prior to the installation of the Hyper-V role; otherwise corrections described in Microsoft's Hyper-V Security Guide must be made after the SSLF baseline has been used.

To the management instance, the following principle applies: No other services and applications may be operated. In principle, exceptions apply to security software such as anti-virus scanners, Host IDS and infrastructure services used by default (time synchronisation), remote management and software maintenance tools. Wherever this is possible, these exceptions should not be made

If an anti-virus scanner with real-time examination is used, it is absolutely necessary to exclude all Hyper-V resources from being scanned in order to avoid false alarms (failures of guests) and reductions in performance. These resources must be protected against viruses using an anti-virus scanner in the guest systems.

In order to decommission guest systems, tools to securely delete the VHD files should be held in reserve (see S 2.433 Overview of the methods for deleting and destroying data).

Hyper-V configuration

By default, there are no limits for the CPU use of the guests sharing the same core. Without limits regarding the CPU use, individual guests can cause malfunctions of other services exploiting the total available computing power in full. Since the CPU requirements are not always fully known in advance, the CPU load of the guests should be subject to permanent monitoring.

Using Hyper-V, limits for the CPU use can be set (fixed limit) or priorities (relative weighting). Both options cannot avoid the "starvation" of a system; this is only possible by setting an absolute reserve (Virtual Machine Reserve). This option should be applied to critical services.

For host systems with many CPUs/cores, this problem is less pronounced, as there is an implicit restriction via the number of the virtual CPUs per VM.

In order to provide sufficient separation of the guests, it must be ensured during the configuration that no overlapping in the access to physical resources is permitted. It must not be possible to access virtual storage media (virtual hard disks/VHDs) or physical devices of the hosts (USB stick, DVD drive).

When backing up a server via the Hyper-V VSS Writer, the configuration of the virtual network and the virtual network components is not backed up. The network configuration should therefore be documented so that a restoration from the documentation is possible in emergencies.

Authorisations

In many cases, the administrators of the guest systems should shut down and boot up their IT systems themselves and access the console without having an influence on other systems and networks when doing so (see S 2.446 Separation of administrative tasks for virtualisation servers).

In order to implement this, only authorisations for the following operations may be granted in the Authorisation Manager for Hyper-V:

All other authorisations can impair the separation between the systems and require a security analysis adjusted to the specific environment.

Guest system configuration

The safeguard S 4.348 Time synchronisation in virtual IT systems requires the time synchronisation of the guests to compensate the load-dependent drift generated during the virtualisation. Without time synchronisation, the guest systems depend on the timer interrupts of the virtual CPU. Thus, the clocks of the VM run more inexactly with the increasing load of other systems. For Hyper-V, there is also the problem of the support of different time zones on guests (Windows expects that the RTC runs with local time) as well as of suspend and resume events. If snapshots are reactivated, for example after moving a VM to another server, the guest system is running with the wrong time and sometimes needs a long time to synchronise again from an external source. To allow the synchronisation, Microsoft offers a synchronisation service as part of the "Hyper-V Integration Services" which must be installed on the guest system. Using this service, the system time of the guest is compared to the clock of the host system; in addition, the clocks are immediately corrected in the event of leaps in time (suspend/resume) depending on the virtualisation. Here, the host system should synchronise using a reliable network time (see S 4.227 Use of a local NTP server for time synchronisation).

Problems might occur when host systems or guests are members of domains or even different domains. Then, the clocks are simultaneously corrected via the network and locally. In many cases, this results in minor deviations. For Active Directory servers as guest system in particular, this can cause problems with the replication. In this case, the synchronisation with the host should be disabled. In this case, however, the ability to restore the original time quickly after a recovery of the virtual machine is lost.

It is possible to only partially disable the synchronisation with the host on a Windows guest with the "Integration Services" installed without setting the time after the boot and without having an effect in case of suspend/resume events. For this purpose, the following command is used:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0.

Afterwards, an external time source must be configured on the guest.

Whenever synchronisation is carried out using an external time source, a relatively short synchronisation interval should be selected (every 10-20 minutes) to be able to compensate the high drift depending on the situation.

Review questions:

© Federal Office for Information Security. All rights reserved.