UNIT IV

PROTECTING THE MANAGEMENT ENVIRONMENT

How to protect your virtual environment from data loss

It’s been more than a decade since the release of the virtual environment. According to a study
by Gartner, most firms report 75% or higher virtualization – proving that the virtualization
market has moved from niche to mainstream. The positives of virtualization are definite, but the
risk of data loss is still a potential downside. In this blog, we explore how your organization can
protect its virtual environments from data loss.

Due to the improvements of hypervisors over the years, the bulk of modern IT systems are now
virtual. Modern hypervisors have reduced the complexity of setting up and maintaining physical
servers, allow for better server utilization and increase IT flexibility and responsiveness to the
needs of businesses.

However, whether you use VMware, Hyper-V, Citrix, Oracle or any of the other hypervisors,
there is still the potential for data loss. To avoid unnecessary data loss in virtual environments –
here are five essential tips on how to protect your files:

1. Use the right backup software for your virtual environment

There are various backup software solutions on the market. Some are available to use both with
VMware and HyperV solutions. The main factor to consider when choosing your backup
software is how much time is needed to recover virtual machines (VMs) out of the backup and
the VM templates. Additionally, good backup solutions for VMs are able to mount the backup
while the files are transferred back to the main host system.

2. A snapshot is not a backup

Always create backups if you want to make sure that everything is recoverable in the event of a
failure. Create snapshots if your changes are very important, and you don’t want to lose any
data; this will cover the time frame between the last and the next backup. If you use snapshots,
don’t try to build snapshots that build on each other, as this not only reduces performance but
makes them more susceptible to error.

3. Don’t save backups and running VMs on the same storage

If you save your backups on the same hard disk or storage space as your active VMs, you risk
ending up with losing all your data. If a backup fails and a VM is active, it will likely overwrite
the backup. To prevent this from occurring, always store your backup VMs and your active
VMs in different places. It also makes sense to make multiple backups and store them on a
different local server/hard disk, whether in the cloud or on tape. Having two additional backups
will help you in the event of a data loss.

4. Don’t try to mix virtualization solutions

Using several virtualization solutions in the same environment can increase the risk of data loss.
If, for example, a VMware system on one SAN is expanded onto a second SAN that is used
by HyperV, there is a high chance that the second SAN will be subject to severe data loss. Such
data loss will occur because of the different layers that the virtualization tools create when they
are linked or expanded. Therefore, it is better to keep your virtualization simple and stick to one
solution within a given environment. Adding too many layers of complexity can be very risky
and will make any needed data recovery time consuming or not possible at all!

5. Think and plan before you use VMs

Always keep in mind that virtualization and virtual machines are not error-free and are as likely
to fail as other storage options. Therefore, before you create a virtual environment for sensitive
applications, think about what is most suitable for your organization’s needs. For example,
some applications have a high input/output (I/O) rate and are, therefore, a better fit for physical
server environments.

Many of today’s virtual platforms include data protection and recovery mechanisms, but you
would be wise not to rely on them. They may claim to protect you from data loss, but they are
not a replacement for a proper backup strategy.

But remember…

Even if you implement the above five essential tips, there is still a chance that your virtual
machines could experience data loss. It is therefore essential that your IT department is fully
aware of the ins and outs of your systems, and have a specific plan on how to react in case of
failure. Every organization should have a data recovery company on speed dial; downtime and
the loss of data can be extremely costly for an organization, so ensuring a specialist is on hand
to help is vital to ensure the recovery of valuable data.

A set of advanced solutions

Today, the protection of virtual environments is very important as most services are moved into
virtual environments or a cloud. It is therefore imperative to introduce technological solutions
designed to protect both data and the virtual environment in terms of cloud services.
Firewalls

Protect the virtual environment with adequate firewalls.

File overview in an isolated environment

File overview in an isolated environment (sandbox) to determine whether they contain a

malicious code

Virtual firewalls

The next-generation virtual firewalls that can be installed in a docker container

Authentication solutions

Protection of web applications, public cloud service connectivity, and integrated authentication.

Safe Internet access

Guaranteeing secure Internet access and traffic control.

Routing in virtual environments

Routing in virtual environments by means of full router functionality and all services.

Secure remote access over the SSL protocol

System guaranteeing a secure remote access to organisation resources over the SSL protocol.

The SIEM solution

A solution designed for collecting and correlating logs with network flow review and forensics

Privileged access management (PAM)

A solution for the management of high-level access to sensitive IT infrastructure

Machine learning and artificial intelligence destined to detect advanced attacks

Machine learning and artificial intelligence for detecting attacks in the IT and OT virtual
environments

Virtual environment protection solution with adequate firewalls

The solution is designed to install firewalls into a virtual environment with full functionality,
which enable the NGFW services (IPS, APPFW, NAT, UTM, etc.).
Virtualization and Encryption

Software-defined transformation of the data center started with virtualization of compute and
then hyper-convergence of compute/storage. The use of encryption to protect sensitive data in
virtual environments presented some challenges:

1. Virtualized environments have many copies of the same data and leverage deduplication
technologies for efficiency. If encryption is performed in the virtual machine (VM), the
data is no longer similar, and this reduces deduplication efficiency.

2. Some solutions perform encryption in the storage layer such as Self-Encrypting Drives
(SEDs). While this protects against physical theft, it does not protect against a rogue
administrator from cloning a virtual machine.

3. Key management is often the Achilles heel. The choice of KMIP-based key management
solutions is largely limited to virtual appliances or software solutions that are vulnerable
to exploits. Hardware appliances lack the scalability and usability needs of a dynamic
virtualized environment.

VMware’s introduction of native encryption capabilities in vSphere 6.5 with vSphere VM

Encryption and vSAN 6.6 with data at rest encryption was designed to address challenges #1
and #2.

Security Architecture
Secure Virtual Architecture (SVA)

Secure Virtual Architecture (SVA) is a compiler-based virtual

machine capable of hosting an entire commodity operating
system and all its applications. The virtual machine is unique
because it combines a sophisticated compiler (like high-level
language virtual machines such as JVM or CLI) with a rich run-
time system capable of monitoring and controlling all privileged
operations (like Virtual Machine Monitors such as VMware or
Xen). This combination opens up the opportunity to develop
novel and powerful solutions to a wide range of important
software security and reliability problems, including intrusion
prevention, intrusion detection and analysis, OS component isolation, full system recovery,
application data confidentiality, secure application- and system-level information flow, and
many others.
SVA currently uses techniques employed by the SAFECode compiler to provide strong memory
safety guarantees to the Linux kernel. All software in SVA is compiled down to a virtual
instruction set; SVA translates code from the virtual instruction set to the native processor's
instruction set transparently. SVA's virtual instruction set is the LLVM IR enhanced
with additional instructions to provide memory safety for low-level software/hardware
interactions.

Managing storage for virtual machines

A virtual machine (VM), just like a physical machine, requires storage for data, program, and
system files. As a VM administrator, you can assign physical or network-based storage to your
VMs as virtual storage. You can also modify how the storage is presented to a VM regardless of
the underlying hardware.

The following sections provide information about the different types of VM storage, how they
work, and how you can manage them using the CLI or the web console.

11.1. Understanding virtual machine storage

If you are new to virtual machine (VM) storage, or are unsure about how it works, the following
sections provide a general overview about the various components of VM storage, how it
works, management basics, and the supported solutions provided by Red Hat.

You can find information about:

 Storage pools

 Storage volumes

 Managing storage using libvirt

 Overview of VM storage

 Supported and unsupported storage pool types

11.1.1. Introduction to storage pools

A storage pool is a file, directory, or storage device, managed by libvirt to provide storage for
virtual machines (VMs). You can divide storage pools into storage volumes, which store VM
images or are attached to VMs as additional storage.

Furthermore, multiple VMs can share the same storage pool, allowing for better allocation of
storage resources.

 Storage pools can be persistent or transient:

 o A persistent storage pool survives a system restart of the host machine. You can
use the virsh pool-define to create a persistent storage pool.

o A transient storage pool only exists until the host reboots. You can use the virsh
pool-create command to create a transient storage pool.

Storage pool storage types

Storage pools can be either local or network-based (shared):

 Local storage pools

Local storage pools are attached directly to the host server. They include local directories,
directly attached disks, physical partitions, and Logical Volume Management (LVM) volume
groups on local devices.

Local storage pools are useful for development, testing, and small deployments that do not
require migration or have a large number of VMs.

 Networked (shared) storage pools

Networked storage pools include storage devices shared over a network using standard
protocols.

11.1.2. Introduction to storage volumes

Storage pools are divided into storage volumes. Storage volumes are abstractions of physical
partitions, LVM logical volumes, file-based disk images, and other storage types handled
by libvirt. Storage volumes are presented to VMs as local storage devices, such as disks,
regardless of the underlying hardware.

On the host machine, a storage volume is referred to by its name and an identifier for the
storage pool from which it derives. On the virsh command line, this takes the form --
pool storage_pool volume_name.

For example, to display information about a volume named firstimage in the guest_images pool.

# virsh vol-info --pool guest_images firstimage

Name: firstimage

Type: block

Capacity: 20.00 GB

Allocation: 20.00 GB

11.1.3. Storage management using libvirt

Using the libvirt remote protocol, you can manage all aspects of VM storage. These operations
can also be performed on a remote host. Consequently, a management application that
uses libvirt, such as the RHEL web console, can be used to perform all the required tasks of
configuring the storage of a VM.

You can use the libvirt API to query the list of volumes in a storage pool or to get information
regarding the capacity, allocation, and available storage in that storage pool. For storage pools
that support it, you can also use the libvirt API to create, clone, resize, and delete storage
volumes. Furthermore, you can use the libvirt API to upload data to storage volumes, download
data from storage volumes, or wipe data from storage volumes.

11.1.4. Overview of storage management

To illustrate the available options for managing storage, the following example talks about a
sample NFS server that uses mount -t nfs nfs.example.com:/path/to/share /path/to/data.

As a storage administrator:

 You can define an NFS storage pool on the virtualization host to describe the exported
server path and the client target path. Consequently, libvirt can mount the storage either
automatically when libvirt is started or as needed while libvirt is running.

 You can simply add the storage pool and storage volume to a VM by name. You do not
need to add the target path to the volume. Therefore, even if the target client path
changes, it does not affect the VM.

 You can configure storage pools to autostart. When you do so, libvirt automatically
mounts the NFS shared disk on the directory which is specified when libvirt is
started. libvirt mounts the share on the specified directory, similar to the command mount
nfs.example.com:/path/to/share /vmdata.

 You can query the storage volume paths using the libvirt API. These storage volumes are
basically the files present in the NFS shared disk. You can then copy these paths into the
section of a VM’s XML definition that describes the source storage for the VM’s block
devices.

 In the case of NFS, you can use an application that uses the libvirt API to create and
delete storage volumes in the storage pool (files in the NFS share) up to the limit of the
size of the pool (the storage capacity of the share).

Note that, not all storage pool types support creating and deleting volumes.

 You can stop a storage pool when no longer required. Stopping a storage pool (pool-
destroy) undoes the start operation, in this case, unmounting the NFS share. The data on
 the share is not modified by the destroy operation, despite what the name of the command
suggests.

11.1.5. Supported and unsupported storage pool types

Supported storage pool types

The following is a list of storage pool types supported by RHEL:

 Directory-based storage pools

 Disk-based storage pools
 Partition-based storage pools
 GlusterFS storage pools
 iSCSI-based storage pools
 LVM-based storage pools
 NFS-based storage pools
 SCSI-based storage pools with vHBA devices
 Multipath-based storage pools
 RBD-based storage pools

Unsupported storage pool types

The following is a list of libvirt storage pool types not supported by RHEL:

 Sheepdog-based storage pools

 Vstorage-based storage pools
 ZFS-based storage pools

HARDENING VIRTUAL MACHINES

The vSphere Security Guide makes a number of recommendations around best practices for
virtual machine security. There are also the vSphere hardening guides, which can be found here.
Installing Antivirus Software
It is recommended that, where required, antivirus is installed within the virtual machines guest
operating systems. For virtual machines that have AV installed it is recommended that
scheduled scans are staggered in order to prevent performance issues that can occur when a
large number of VMs on a host are scanning at the same time.

Limiting Exposure of Sensitive Data Copied to the Clipboard

By default, copy and paste operations are disabled. If copy and paste functionality is enabled,
you are able to copy and paste between the machine running the console and the guest operating
system.

This functionality is controlled with two advanced settings, on a per-virtual machine basis:

Be aware that these advance settings can only be changed when the virtual machine is powered
off.
Removing Unnecessary Hardware Devices
It is recommended that any unused virtual hardware is removed from virtual machines, as
unused hardware could be used to breach virtual machine security. For example, a CD-ROM
drive attached to a VM may be used to access information on the mounted ISO/attached drive.

As an alternative to removing a device, you could prevent a user from connecting or

disconnecting it through the guest OS by editing the virtual machine’s VMX file, entering the
following line:

device_name.allowGuestConnectionControl = "false"

Limiting Guest Operating System Writes to Host Memory

The guest operating system processes send informational messages to the host using VMware
Tools. If the amount of data the host stored as a result of these messages was unlimited, an
unrestricted data flow would provide an opportunity for an attacker to stage a denial-of-service
(DoS) attack. By default By default the VM can send only 1MB of these messages, however
this can be changed. If this was un-restricted then it could be possible for an attacker to write
software to send data with the aim of causing DoS.

The setting to configure this behavior is:

tools.setInfo.sizeLimit

It is configured on a per-VM basis. You can increase the guest operating system variable
memory limit if large amounts of custom information are being stored in the configuration file.
You can also prevent guests from writing any name-value pairs to the configuration file. To do
so, use the following setting, and set it to ‘true’:

isolation.tools.setinfo.disable

Configuring Logging Levels for the Guest Operating System

Virtual machines write to a log file on the datastore where the VM is located. An attacker could
cause this log file to grow, with the intention of causing a denial of service, by generating
events that will be committed to the log file. In order to prevent the possibility of this happening
you can configure logging settings for a virtual machine to limit the total size and number of
logs that are created. A new log file is created when the host is rebooted – so these files can
grow to be quite large. VMware recommend that 10 log files should be retained, each with a
maximum size of 1ooKB. This is configurable by adding/changing the following lines in the
virtual machine’s VMX file:

log.rotateSize=maximum_size

log.keepOld=number_of_files_to_keep

You can also disable logging entirely for a virtual machine: