2.2. Host Security Recommended Practices for Red Hat Enterprise Linux With host security being such a critical part of a secure virtualization infrastructure, the following recommended practices should serve as a starting point for securing a Red Hat Enterprise Linux host system: Run only the services necessary to support the use and management of your guest systems. If you need to provide additional services, such as file or print services, you should consider running those services on a Red Hat Enterprise Linux guest. Limit direct access to the system to only those users who have a need to manage the system. Consider disallowing shared root access and instead use tools such as sudo to grant privileged access to administrators based on their administrative roles. Ensure that SELinux is configured properly for your installation and is operating in enforcing mode. Besides being a good security practice, the advanced virtualization security functionality provided by sVirt relies on SELinux. Refer to Chapter 4, sVirt for more information on SELinux and sVirt. Ensure that auditing is enabled on the host system and that libvirt is configured to emit audit records. When auditing is enabled, libvirt will generate audit records for changes to guest configuration as well start/stop events which help you track the guest's state. In addition to the standard audit log inspection tools, the libvirt audit events can also be viewed using the specialized auvirt tool. Ensure that any remote management of the system takes place only over secured network channels. Tools such as SSH and network protocols such as TLS or SSL provide both authentication and data encryption to help ensure that only approved administrators can manage the system remotely. Ensure that the firewall is configured properly for your installation and is activated at boot. Only those network ports needed for the use and management of the system should be allowed. Refrain from granting guests direct access to entire disks or block devices (for example, /dev/sdb ); instead, use partitions (for example, /dev/sdb1 ) or LVM volumes for guest storage. Ensure that staff have adequate training and knowledge in virtual environments. Warning Attaching a USB device, Physical Function or physical device when SR-IOV is not available to a virtual machine could provide access to the device which is sufficient enough to overwrite that device's firmware. This presents a potential security issue by which an attacker could overwrite the device's firmware with malicious code and cause problems when moving the device between virtual machines or at host boot time. It is advised to use SR-IOV Virtual Function device assignment where applicable. Note The objective of this guide is to explain the unique security-related challenges, vulnerabilities, and solutions that are present in most virtualized environments, and the recommended method of addressing them. However, there are a number of recommended practices to follow when securing a Red Hat Enterprise Linux system that apply regardless of whether the system is a standalone, virtualization host, or guest instance. These recommended practices include procedures such as system updates, password security, encryption, and firewall configuration. This information is discussed in more detail in the Red Hat Enterprise Linux Security Guide . 2.2.1. Special Considerations for Public Cloud Operators Public cloud service providers are exposed to a number of security risks beyond that of the traditional virtualization user. Virtual guest isolation, both between the host and guest as well as between guests, is critical due to the threat of malicious guests and the requirements on customer data confidentiality and integrity across the virtualization infrastructure. In addition to the Red Hat Enterprise Linux virtualization recommended practices previously listed, public cloud operators should also consider the following items: Disallow any direct hardware access from the guest. PCI, USB, FireWire, Thunderbolt, eSATA and other device passthrough mechanisms not only make management difficult, but often rely on the underlying hardware to enforce separation between the guests. Isolate the cloud operator's private management network from the customer guest network, and customer networks from one another, so that: the guests cannot access the host systems over the network. one customer cannot access another customer's guest systems directly via the cloud provider's internal network.

Commands: