Evaluation of Hardening the vSphere Environment

raspgiantsneckΔιακομιστές

9 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

116 εμφανίσεις

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 pr
ovided by VMware
.
The reader should have a basic understanding of the
vSphere
environment including: vCenter, ESXi, and
working with
virtual
machines
.

I.

I
NTRODUCTION

Virtualization in the datacenter is becoming commonplace
f
or 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 vir
tual environment.
Many servers are now including 10 and 12
-
core processors
with 512GB RAM, p
aired 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
m
achines, 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 sinc
e 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 enviro
nment 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.

II.

V
S
PHERE
I
NSTALLATION AND
C
ONFIGURATION

The test envir
onment 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 se
veral physical systems and a
centralized storage system.

A.

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 it
s 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 an
d 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. I
t 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 c
ontroller must be configured with “LSI Logic
Parallel”. The ESXi installation went smoothly as it did with
the physical system.

B.

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 movin
g virtual m
achines between
hypervisors and/or datastores, and plenty more.


F
IGURE
1.

V
S
PHERE
T
EST
E
NVIRONMENT


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 s
oftware 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. H
owever, restarting the
installation seemed to resolve the issue. I used the defaults
throughout the entire installation to keep it simple.

C.

VMware vSphere Management Assistant

The vSphere Management Assistant (vMA) is a Linux
distribution that includes prep
ackaged 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 w
ith 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 appli
ance 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 do
esn’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.

D.

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 di
stribution 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 vCM
A 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. T
he 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 pri
vileged 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. L
ater versions add
ressed this
security concern by making HTTPS the default connection. As
with the vMA, th
e vCMA should be updated with operating
system

patches and lockdowns before implementing in a
production environment.

III.

H
ARDENING V
S
PHERE

VMware publishe
s their own vSphere Security Hardening
Guides for each version of vSphere they release. The latest
versio
n available at the beginning of this project wa
s versio
n
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, v
Center
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 Limit
ed 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
vmwarevSphereSecurityHa
rdeningReportCheck.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 ma
de using the hardening
guide.

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

A.

Virtual Machines

The virtual machines part of the hardening guide only
covers the virtual machine container. A virtual mach
ine
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 t
he 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 machine
s 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.

B.

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 with
in 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 persi
stent 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
commu
nications. It is important to install a legitimate
certificate to avoid man
-
in
-
the
-
middle attacks.

C.

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.

D.

vCenter

The vCenter server runs on the Windows Serv
er 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.

IV.

R
ESULTS AND
E
VALUATION

To create a baseline, I decided to run the
vmwarevSphereSe
curityHardeningReportCheck.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 <vcenter_server>
--
username <v
center_admin> /

--
recommend_check_level <enterprise|dmz|sslf>


The value <vcenter_server> and <vcenter_admin should be
substituted with the appropriate values based on the
environment. Running all three levels requires running the
script three times. The f
ollowing Table 1 shows the results
before anything is hardened.

Check Level

Percentage

Grade

Enterprise

10%

F

DMZ

12%

F

SSLF

24%

F

T
ABLE
1.

R
ESULTS
B
EFORE
H
ARDENING

As expected, the majority of the checks failed for all three
levels. Keep in mind many
of the checks are not detectable by
the Perl script since they depend on external configuration
settings or are subject to interpretation by the organization. For
more information on the report produced by the Perl script, see
the r
eports attached
to this
document.

The following table includes the results from hardening the
test environment. Again, the three levels were reported for
completeness.

Check Level

Percentage

Grade

Enterprise

84%

B

DMZ

69%

D

SSLF

30%

F

T
ABLE
2.

R
ESULTS
A
FTER
H
ARDENING

As demon
strated in Table 2, the results improved
drastically for both Enterprise and DMZ levels. The focus of
this project was to harden these levels as much as possible. The
SSLF improved slightly. Many of the SSLF recommended
elements were skipped to prevent bre
akage of the test
environment. For more detailed results, plea
se refer to the
reports attached
.

V.

C
ONCLUSIONS

Overall, I feel this security hardening exercise worthwhile.
Even though the hardening guide covers a lot of ground with
the overall vSphere archite
cture, it is lacking what is takes to
harden the individual virtual machines themselves. A critical
piece of the vSphere infrastructure, the vMA, isn’t included in
this hardening guide. Further research must be done to make
sure this component is secure wh
en deploying in a production
environment.

The test environment was very limited on what could and
couldn’t be locked down. The next step is to test this hardening
script in an environment with complex virtual networking
using distributed switches such as t
he Cisco Nexus 1000V,
SAN/NAS storage solu
tions, and a vast amount of distributed
hosts. It would also be worth looking into the latest hardening
guide for version 5.0 to see if there was anything missed in the
previous versions and what additional element
s need to be
locked down in the updated software.

R
EFERENCES

[1]

vSphere 4.1 Hardening Guide
.

Retrieved
April 29, 2012

from
http://communities.vmware.com/docs/DOC
-
15413

[2]

vmwarevSphereSecurityHardeningReportCheck.pl 5.0.

Retrieved
April
29, 2012

from
http://comm
unities.vmware.com/docs/DOC
-
11901