Paper Title (use style: paper title) - EAS Home



Evaluation of Hardening the vSphere Environment

Shane Jahnke

The University of Colorado at Colorado Springs

Colorado Springs, CO U.S.A.

sjahnke@uccs.edu

Abstract—This document is an evaluation of hardening the vSphere environment utilizing the guide provided by VMware. The reader should have a basic understanding of the vSphere environment including: vCenter, ESXi, and working with virtual machines.

Introduction

Virtualization in the datacenter is becoming commonplace for organizations. There are many advantages of virtualization including: reducing costs by requiring less hardware and less energy, running multiple operating systems on a single system, providing high availability and improved disaster recovery. Today’s servers are built to power the virtual environment. Many servers are now including 10 and 12-core processors with 512GB RAM, paired with a Storage Area Network (SAN) or Network Attached Storage (NAS) for centralized storage, this is an ideal system for powering several virtual machines. A virtualized environment can be labeled as a “private cloud” within the organization providing computing power and storage solutions.

Security within the virtual infrastructure can be easily overlooked. While the idea is to consolidate physical to virtual machines, there are now several security concerns to consider. For example, the physical host, hypervisor, running the virtual machine is a new operating system to add to the list. In most cases the hypervisor is a propriety system designed for performance rather than security. Additionally, it is important to isolate and protect hypervisor to virtual machine and communication between the hypervisor/virtual machine and storage solutions. Lastly, the security between virtual machines could be compromised since they share the same computing resources provided by the hypervisor. The virtual machine itself should follow any existing security practices as if it was a physical machine. Virtual machines should be up to date on operating system patches and should run Anti-Virus software to protect against malware.

This paper will provide information on how to setup and harden a VMware vSphere environment based on the “VMware vSphere 4.1 Security Hardening Guide”. Section 2 discusses how to setup a basic virtual environment including: ESXi hypervisor, vCenter management server, and vSphere Management Assistance. Section 3 dives into the hardening guide itself. Section 4 provides results and evaluation of the project.

vSphere Installation and Configuration

The test environment used for this project consisted of a single physical system with a 6-core processor, 6GB RAM, and 1TB of storage. See Figure 1 for how the entire vSphere test environment was set up in this test environment. A production environment would include several physical systems and a centralized storage system.

1 VMware ESXi Hypervisor

The ESXi hypervisor is the virtualization layer between the bare metal server and the virtual machines. ESXi is available for free which is great for administrators to prove its value in the datacenter. Even though ESXi isn’t as feature rich as its counterpart ESX, it does have its advantages when it comes to security. ESXi installs an ultra-thin footprint with to function as an administrator. It lacks the additional services and ports which can be exploited. VMware recommends deploying ESXi over ESX going forward and recommends installing a virtual appliance (pre-installed virtual machine) called the vSphere Management Assistant (vMA).

For this test environment, I decided to use a spare hard drive to install ESXi 4.1.0 Update 1 (VMKernel Release Build 348481). The bare metal server hardware specifications are: 6-core CPUs, 6GB RAM, and 1TB for the datastore. The installation of ESXi was very straightforward with only 5 prompts. It is strongly recommended to set a root password after installation. I left the password blank for the time being so that the test script can detect it.

A second ESXi server was built as a virtual machine on the physical ESXi server to test clustering. The virtual machines ESXi server was configured with 2 cores for the CPU, 2GB RAM, and 100GB for the hard disk (datastore). Since ESXi is based on RHEL/CentOS, the best choice for the Guest Operating System is “Red Hat Enterprise Linux 6 (64-bit)”. The SCSI controller must be configured with “LSI Logic Parallel”. The ESXi installation went smoothly as it did with the physical system.

2 VMware vCenter Server

Managing several individual ESX/ESXi servers becomes cumbersome for administrators. Hence, VMware offers a product that unifies and simplifies management of the virtualization infrastructure. VMware vCenter provides centralized control and visibility at every level. Controls include: license management, hypervisor administration, advanced tasks including moving virtual machines between hypervisors and/or datastores, and plenty more.

[pic]

Figure 1. vSphere Test Environment

The vCenter server can be deployed as a physical machine or a virtual machine running on an ESXi server it manages. For simplicity, the vCenter server was deployed as a virtual machine on the physical ESXi server. VMware vCenter must run on the Windows server platform which provides centralized authentication with Active Directory. The virtual machine configuration was configured with 2 cores for the CPU, 4GB RAM, and 40GB for the hard disk. The operating system of choice was Windows Server 2008 Standard with an evaluation license. As with any operating system, it is important to apply the latest patches and updates as well as install anti-virus software with the latest definitions.

Installing vCenter requires a database on the backend. In test environments, I chose to use the bundled Microsoft SQL Server 2005 Express Edition. The initial install of SQL Server 2005 Express failed due to an error. However, restarting the installation seemed to resolve the issue. I used the defaults throughout the entire installation to keep it simple.

1 VMware vSphere Management Assistant

The vSphere Management Assistant (vMA) is a Linux distribution that includes prepackaged software for managing the vSphere environment. This prepackaged software includes the vSphere command-line interface and the vSphere Standard Development Kit (SDK) for Perl. The combination of the vMA and ESXi make up what was originally included with the ESX hypervisor. The advantage to this approach is a smaller foot print at the hypervisor level. However, there are still potential vulnerabilities with need to be addressed in the vMA.

The vMA is available from VMware as a prepackaged virtual appliance that can be easily deployed in an existing vSphere environment. This CentOS-based Linux distribution allows administrators to run scripts and agents to interact with ESXi systems with seamless authentication. There is no need to authenticate each time a command is executed. Another important note is the vMA provides centralized logging, similar to a syslog server, for analysis. This is essential for ESXi hosts since the logs are non-persistent through a reboot.

The VMware vSphere 4.1 Hardening Guide doesn’t include any lockdowns for the vMA. The virtual appliance is running with CentOS 5.3 which is dated. How is the vMA updated? Will updating the CentOS operating system break the vMA functionality? These questions need to be answered before deploying to a production environment.

2 VMware vCenter Mobile Access

The VCenter Mobile Access (vCMA) is one of VMware’s “fling” projects. A fling project is known as a technical preview meant to be played with and explored. The vCMA is a custom Linux distribution that provides vSphere access from mobile devices such as smartphones and tablets including the iPad. From these mobile devices, administrators can perform various troubleshooting and remediation activities from anywhere in the world.

VMware distributes the vCMA as a virtual appliance, like the vMA. The vCMA acts as the bridge between the vCenter server and the mobile application. VMware provides a vSphere Client application for the iPad on Apple’s App Store to connect the vCMA.

Setting up the vCMA is trivial. The virtual appliance is distributed as an OVF template that is easily imported from the vSphere client. After the virtual machine is imported, simply start the virtual machine until it boots up the vCMA console. The console allows the user to login or set network configuration information. I chose to use DHCP for the test environment. Then, start the vSphere Client application on the iPad. Within the client the vCenter and vCMA IP addresses/hostnames must be specified. Lastly, log in to the vCMA using a privileged user account to browse hosts, virtual machines, and event logs. Many other administrative functions include starting and stopping virtual machines. It is also possible to vMotion virtual machines between hosts from the vCMA. One lacking feature is there is no console access to the virtual machines.

Since the vCMA isn’t a production offering from VMware, security isn’t a top concern. The earlier versions of the vCMA used HTTP as the default connection between the vSphere mobile client and the vCMA. Later versions addressed this security concern by making HTTPS the default connection. As with the vMA, the vCMA should be updated with operating system patches and lockdowns before implementing in a production environment.

Hardening vSphere

VMware publishes their own vSphere Security Hardening Guides for each version of vSphere they release. The latest version available at the beginning of this project was version 4.1. Recently, VMware published a draft version of the vSphere Hardening Guide for version 5. The idea is for the hardening guide to provide guidance on how to securely deploy vSphere in a production environment. This hardening guide includes both ESX and ESXi virtualization hosts, the virtual machine container, virtual networking infrastructure, vCenter management server, and VMware Update Center. Securing the virtual machine itself is not covered by this guide.

There are three recommendation levels as part of this hardening guide. These level include Enterprise, DMZ, and Specialized Security Limited Functionality (SSLF). For this project, I decided to apply parameters for both Enterprise and DMZ where possible.

VMware has also published a Perl script that can check many of the settings recommended in the hardening guide. The vmwarevSphereSecurityHardeningReportCheck.pl file, written by William Lam, works with both vSphere 4.1 and 5.0 and can generate reports from all the checks. Before hardening the vSphere environment, a report was generated to give a starting point for benchmarking the progress made using the hardening guide.

The following subsections will discuss experiences with locking down each part of the hardening guide.

1 Virtual Machines

The virtual machines part of the hardening guide only covers the virtual machine container. A virtual machine consists of a small number of files including the (.vmx) configuration file. The majority of the configuration changes recommended in the virtual machine section are in the configuration file. There are two ways to update the configuration file while the virtual machine is off. The first way is by modifying the settings within vSphere and other is by modifying the (.vmx) file stored in the datastore. I recommend updating the configuration parameters via vSphere.

Additional changes to the virtual machines included removing default devices such as floppy drives, CD-ROMs, and serial ports that are not being used. There were several parameter elements that were related to VMsafe. VMsafe is a security architecture for virtualized environments and provides and API for partners to develop security products [1]. Most of these parameter elements were omitted since VMsafe isn’t implemented in the test environment.

2 ESX/ESXi Host

There were two operational elements that dealt with the ESXi installation. As with every download, it is important to check the integrity of the image using MD5 and/or SHA-1 checksums. Both checksums were verified for the ESXi ISO image. The test environment wasn’t running the latest version, 4.1.0 Update 2. This update should be applied within a production environment.

Unfortunately, I wasn’t able to apply the storage operational elements for the ESXi hosts. These elements only apply if connecting ESXi to a SAN with iSCSI. I have very little experience with iSCSI storage. However, it would be worth looking into securing fiber channel connections to LUNs.

Configuring a syslog server for centralized logging is a good practice in any environment. However, this element was skipped in this test environment. Instead, it is recommended to store persistent logs within the datastore in case the server restarts. A critical configuration setting for virtualization is setting up a NTP server for time synchronization. This is important because virtual machines depend on the host’s time. ESXi is bundled with a self-signed certificate for secure communications. It is important to install a legitimate certificate to avoid man-in-the-middle attacks.

3 vNetwork (Virtual Networking)

The virtual networking setup was limited in the test environment. The entire vSphere environment was hosted on a desktop system connected to a simple consumer-grade Netgear switch. Therefore, it wasn’t feasible to create VLANs for isolating traffic for vSphere management, vMotion, and storage. Many of the elements dealt with vSwitches and distributed vSwitches which were not used in the test environment.

For further research, it would be worth applying many, if not all, of these virtual networking elements within a production environment.

4 vCenter

The vCenter server runs on the Windows Server platform. It is important to make sure Windows is patched and has anti-virus software installed. It is also recommended to install vCenter with services running as a restricted user rather than local system accounts. I realized this after setting up the vCenter server for the test environment.

Several operational elements were skipped for the vCenter server including VMware Update Manager and using self-signed certificates.

Results and Evaluation

To create a baseline, I decided to run the vmwarevSphereSecurityHardeningReportCheck.pl from the vMA prior to hardening the test environment. The following commands were ran to create reports for Enterprise, DMZ, and SSLF.

$ ./vmwarevSphereSecurityHardeningReportcheck.pl /

--server --username /

--recommend_check_level

The value and ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download