��������� ��

��������������������
VMWARE WHITE PAPER

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
ESX Server Architecture and the design of Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
VMware Virtualization layer – vmkernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Service Console or Console OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Network Security and VLAN’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Strong Corporate Security Response Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Independent Security Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Findings of the Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Best practices for running an ESX Server securely. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Trusted users only in the Service Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Do not configure Promiscuous mode network adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Prevent VM’s from spoofing virtual MAC addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Disable Promiscuous mode for the VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Consider disabling Guest OS logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Disable copy and paste in the Guest OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1
VMWARE WHITE PAPER

Introduction The vmkernel controls the hardware and schedules the alloca-
tion of these resources between the virtual machines and the
VMware ESX Server is data-center class virtual machine software
service console. The vmkernel has no public interfaces, and
for consolidating and partitioning servers in high-performance
cannot execute a “process” in the traditional operating system
environments. Ideally suited for corporate IT and service
sense. Hence it is highly secure – there are no public interfaces
provider data centers, VMware ESX Server is a secure, cost-effec-
to connect to.
tive, highly scalable virtual machine platform. With advanced
resource management capabilities it is also VMware’s highest Virtual Machines
performance platform for building Virtual Infrastructure. Virtual machines are the containers inside which guest operat-
VMware recognizes that in order for its customers to entrust ing systems are run. All VMware virtual machines have been
valuable data to VMware ESX Server virtual machines, the designed to be completely isolated from each other2. This
platform must provide strong security. VMware provides for isolation of virtual machines is key to enabling multiple virtual
security in the ESX Server environment in several different ways, machines to run securely while sharing hardware and was a key
including: factor in the design of virtual machines. This isolation of virtual
i. ESX Server Architecture and the design of Virtual Machines machines applies to both their ability to access hardware and
also their performance characteristics.
ii. Network security and VLAN’s
A common manifestation of the combined hardware and per-
iii. Strong Corporate Security Response Policy
formance isolation of a virtual machine is seen if a guest operat-
iv. Independent Security Audit ing system was to crash, i.e. the guest kernel panics. Even in this
v. Best practices for running an ESX Server securely case, other virtual machines will continue to run, unaffected by
a crashed guest kernel.
ESX Server Architecture and the Design of Isolation - hardware
Virtual Machines An executing virtual machine is isolated from other virtual
VMware ESX Server consists of the three major components as machines running on the same hardware. This isolation is
shown in Figure 1: complete - while they share physical resources such as CPU,
i. VMware virtualization layer – the vmkernel memory and I/O devices, they cannot “see” any device other
than the virtual devices made available to it by the virtual
ii. Service Console or Console OS
machine monitor. Each guest operating system running inside
iii. Virtual Machines a virtual machine behaves just as it was running on a separate
Figure 1 – ESX Server Architecture machine and has no knowledge of other virtual machines
running on that hardware.
Figure 2 – Virtual Devices

��� ��� ��� ��� ���

Parallel Ports Serial/Com Ports
���������� ���������� ���������� ���������� �������
������ ������ ������ ������ �������

��������������������������� Ethernet
Floppy Disk

������������������

Sound Card
CD/DVD
� �� ������ ��� ���� Monitor

Each of these components and this overall architecture has Video Card
Keyboard
been carefully designed to ensure security from the ground up.

VMware Virtualization Layer – vmkernel

The vmkernel is a proprietary microkernel1 developed by SCSI Controller IDE Controller Mouse USB Device

VMware specially for running virtual machines. It is optimized

for running virtual machines in the high performance ESX
Server environment.

2
VMWARE WHITE PAPER

The only way a virtual machine can communicate with another

virtual or physical machine is through the network, and its
virtual network card (VMNIC) just like on a physical machine as
shown in Figure 3. If a virtual network card is not configured
then the machine is completely isolated. Hence any virtual
machine that follows security procedures to protect itself from a
network that a physical machine would, such as a firewall, anti-
virus etc. will be fully protected.

Figure 4 – DMZ in a box

In this example, we have four virtual machines running two
Firewalls, a Web server and an Application Server to create a
DMZ. The Web server and Application server sit in the DMZ
between the two firewalls. External traffic from the Internet
(labeled External) is verified by the firewall inside the VM, and if
authorized routed to the virtual switch in the DMZ – the switch
in the middle. The Web Server and Application Server are con-
nected to this switch and hence can serve external requests.
This switch is also connected to a firewall that sits between the
DMZ and the internal corporate network (labeled Internal). This
Figure 3 – Virtual Networking through Virtual Switches second firewall filters packets and if verified, routes them to the
It is important to note that the isolation of virtual machines VMNIC0, connected to the internal corporate network.
operates at the virtual hardware level. Hence it is operating
Hence a complete DMZ can be built inside a single ESX Server.
below the guest operating system and so even a user with
Because of the isolation between the various virtual machines,
system administrator privileges for a guest operating system
even if one of them were to be compromised by, say, a virus the
running inside a virtual machine cannot “reach out” and access
other virtual machines would be unaffected.
another virtual machine without explicit access from the ESX
Server system administrator. Service Console or Console OS
The ESX Service Console, also sometimes called the Console OS,
Isolation – performance
is a limited distribution of Linux based on the RedHat 7.2 distri-
The performance of a virtual machine can also be isolated com-
bution. The service console provides an execution environment
pletely from other virtual machines. Through the fine-grained
to monitor and administer the entire ESX Server.
resource controls available in ESX Server you can configure a
virtual machine to always get, for example, a minimum of 10% In some cases if the service console is compromised it can
of a CPU. This protects a virtual machine from a loss of perfor- result in the virtual machines also being compromised. Due to
mance if another virtual machine was to consume too many this, VMware has worked to secure the service console and only
resources on shared hardware. This can also prevent a malicious runs the services essential to run ESX Server. Also, the distribu-
user in another virtual machine from affecting the performance tion has been limited to the features required to run ESX Server.
of a virtual machine through a denial of service type attack. While it is possible to install and run almost any program in
Since the vmkernel mediates the physical resources, and all the service console designed for RedHat 7.2, this can have
physical hardware access is through the vmkernel, a virtual serious security consequences and is not supported by VMware.
machine has no way to side-step this performance isolation. VMware only supports running the agents listed in the official
ESX Server compatibility guides: http://www.vmware.com/
An application of Isolation – Network DMZ in a box products/server/esx_specs.html
A good example of the use of the isolation and virtual network-
In case any vulnerability is discovered in a supported configura-
ing features of ESX is a network DMZ in a box. Figure 4 shows
tion, VMware will proactively notify all customers with valid
an example of such a DMZ.
Support and Subscription contract and also provide all neces-

3
VMWARE WHITE PAPER

sary patches. This policy is discussed in detail in the §Strong such issues will be corrected in a timely fashion.
Corporate Security Response Policy later in this white paper. This policy is available at: http://www.vmware.com/support/
User access to the Service Console should also be limited. using/security_response.html
This is discussed further in §6.1 - Trusted users only in the We encourage the reader to review this policy and understand
Service Console the commitment VMware has to security in all our products,
including ESX Server.
Viruses in the Service Console
It is possible to run an ESX Server with the service console
not connected to any network. However, if it is connected Independent Security Audit
to a network, since the service console is itself a full operat- To further ensure the security of ESX Server, VMware also regu-
ing system it must also be protected just like any physical or larly has its software audited by an independent third party.
virtual machine from viruses. This can be accomplished by VMware always chooses reputed firms with long standing
running a combination of firewall and anti-virus products in real-world experience designing, developing, deploying and/or
it. While VMware does not endorse any specific company’s managing information security products in operational envi-
products we have customers successfully using products from ronments. In addition, this third party is provided with access
NetworkAssociates (NetShield for Unix) and Symantec. to our source code and works closely with VMware engineers
to fully understand our products. The auditors can recom-
Apache in the Service Console mend any changes they deem necessary for security and it is
One notable program that runs in the service console is the VMware’s policy to implement all such changes recommended
web server Apache, used to serve requests for administration by the auditor.
and monitoring from the ESX Server web based management
ESX Server was most recently audited in late 2003 with version
interface (“the MUI”).
2.0.1. All changes suggested by the audit were implemented in
This server has been configured with only the limited set of version 2.1, which is now generally available.
features needed by the ESX Server management user interface.
Please note that it is VMware policy to not disclose the name
Thus ESX Server is not vulnerable to many of the Apache security
of the third parties doing the audit to prevent malicious users
issues reported. However, VMware carefully monitors all security
from targeting our partners.
alerts and if needed will issue a security patch, just like any other
security vulnerability found to pose a risk to ESX Server. Deployment Scenarios
ESX Server can be deployed in a wide variety of scenarios. To
Network Security and VLAN’s reduce the number to audit, we defined a representative set of
The network is often the most vulnerable part of any system. As common deployment scenarios. The audited scenarios were:
discussed earlier once configured, a virtual machine’s network is i. Single Customer Deployment
accessible from the outside and can be just as vulnerable as on
ii. Restrictive Multi-customer Deployment
a physical machine. Hence the requirements to secure a virtual
machine’s network are often the same as on a physical machine. iii. Open Multi-customer Deployment
How to secure a virtual machine’s network depends on the iv. Restrictive Multi-customer Deployment with ControlCenter
guest operating system used and is beyond the scope of this
paper. However, ESX Server also provides a full implementation
of VLAN’s (IEEE 802.1q). VLAN’s make it possible to segment a
physical network such that two machines on the same physical
network will not be able to send or receive packets unless they
are on the same VLAN. This is described in a detail in a separate
white paper available at: http://www.vmware.com/products/
server/esx_features.html

Strong Corporate Security Response Policy

In addition to the design features, VMware has a strong corpo-
rate commitment to enabling and helping you maintain a secure
environment. The VMware Security Response Policy documents
these strong commitments for resolving possible vulnerabilities
in our products so that our customers can be assured that any

4
VMWARE WHITE PAPER

Single Customer Deployment There are no separate customer admins, and the site admin
This scenario is representative of a deployment within a also maintains the various VMs. However, there may be a set of
single corporation, not shared with other customers. system admins. These system admins do not have accounts on
There is one site administrator that maintains the set of the ESX Server deployment and cannot access any of the ESX
physical servers running ESX Server, and there are several Server tools (MUI, remote console, shell), but they may have
virtual machines running on these servers. access to certain VMs via a terminal emulation program such as
Terminal Services.

ESX Server Configuration

Feature Config Comments

Service console and MUI share No3 The service console and MUI traffic should be on a physically separate
physical network with VMs? network.
VMs share physical network? Yes All VMs are on the same physical network, separate from the service
console’s physical network
NIC sharing? Partial All VMs share NICs with each other, but NICs aren’t shared between the
VMs and the Service Console
HBA sharing? Yes
VMFS sharing? Yes All .dsk files reside within one VMFS partition
Security Level? Medium Allow FTP access to the service console
VM Memory Overcommittment? Yes Total memory for VMs can be configured to be greater than the total
physical memory
COM/Perl API access? Yes

User Accounts on ESX Server

Category Total number of accounts

Site admins 1
Customer admins 0
System admins 0
Business users 0

Access Chart

Feature Site Admin System Admin

Root access •
Service Console secure shell (SSH) access •
MUI and Remote Console access •
Create and edit VMs •
Terminal access to VMs • •

5
VMWARE WHITE PAPER

Restrictive Multi-customer Deployment There is still only one site administrator, but there are now
In this scenario, multiple customers have applications deployed customer administrators who maintain and deploy the VMs for
on ESX Server within the same data center. The different cus- a particular customer. There are also customer system adminis-
tomers’ VMs can be on the same physical server, but resource trators who do not have ESX Server accounts but have access to
sharing constraints are in place to prevent rogue interaction. the VMs through a terminal emulation program.

ESX Server Configuration

Feature Config Comments

Service console and MUI share No The service console and MUI traffic should be on a physically separate
network with VMs? network from the VMs.
VMs share physical network? Partial VMs from the same customer are on the same physical network. Multiple
customers do not share the same physical network.
NIC sharing? Partial VMs from the same customer share NICs, but multiple customers never
share NICs.
HBA sharing? Yes
VMFS sharing? No Each customer has their own VMFS partition, and their VM .dsk files reside
on this partition. The partition can span multiple LUNs
Security Level? High No FTP access
VM Memory Over committment? Yes Total memory for VMs can be configured to be greater than the total
physical memory
COM/Perl API access? Yes

User Accounts on ESX Server

Category Total number of accounts

Site admins 1
Customer admins 10
System admins 0
Business users 0

Access Chart

Feature Site Admin Customer Admin System Admin

Root access •
Service Console secure shell (SSH) access • •
MUI and Remote Console access • •
Create and edit VMs • •
Terminal access to VMs • • •

6
VMWARE WHITE PAPER

Open Multi-customer Deployment Restrictive Multi-customer Deployment with

In this scenario, multiple customers have applications deployed ControlCenter
on ESX Server within the same data center, and many resource- This scenario is the same as the “Partially Shared Deployment”
sharing constraints are removed. In addition, this environment is scenario above, but VMware Virtual Center features are enabled
more open than the previous scenario, and some business users within ESX Server. This includes management of VMs through
have access to the virtual machines deployed via a terminal the ControlCenter UI and enablement of VMotion.
emulation program like Terminal Services

ESX Server Configuration

Feature Config Comments

Service console and MUI share Yes All traffic on the same physical network
physical network with VMs?
VMs share physical network? Yes All VMs are on the same physical network, separate from the service
console’s physical network
NIC sharing? Partial All VMs share NICs with each other, but NICs aren’t shared between the
VMs and the Service Console
HBA sharing? Yes
VMFS sharing? Yes Virtual machines can share VMFS partitions. Multiple customers’ VMs do
not share .dsk files, but these .dsk files may be on the same VMFS partition
as other customers’ files
Security Level? Medium Allow FTP access to service console
VM Memory Overcommittment? Yes Total memory for VMs can be configured to be greater than the total
physical memory
COM/Perl API access? Yes

User Accounts on ESX Server

Category Total number of accounts

Site admins 1
Customer admins 10
System admins 0
Business users 0

Access Chart

Feature Site Admin Customer Admin System Admin Business User

Root access •
Service Console secure shell (SSH) access • •
MUI and Remote Console access • •
Create and edit VMs • •
Terminal access to VMs • • • •

7
VMWARE WHITE PAPER

Findings of the Audit Disable Promiscuous mode for the VM

The results of the audits show that VMware ESX Server is a You can disable promiscuous mode for the VM by adding a line
secure, stable platform that protects critical data in isolated similar to the following to the configuration file:
virtual machines. Some of our auditors were “…unusually Ethernet<n>.noPromisc
impressed with the overall quality of VMware ESX Server…” = TRUE
and praised some of our source code as “…one of the most
defensive and carefully coded source that we’ve examined for a Consider disabling Guest OS logging
customer. In particular the strict argument checking, careful use
Virtual Machines may log troubleshooting information into a
of assertions and macros, and well written comments made the
virtual machine log file stored in the COS. Normal, non-root or
code a joy to review”.
non-administrator users and processes in the virtual machine
Status of Audit Recommendations can abuse this logging and cause large amounts of data to be
All issues found by the auditors were addressed in ESX logged. Over time, a log file can consume the file system space
Server 2.1. designated for the COS and cause a denial of service attack.
To disable logging of VM messages, add a line similar to the fol-
Best practices for running an ESX Server lowing to the configuration file:
securely Isolation.tools.log.disable
In addition to the architecture of ESX Server, special isolation = TRUE
features, network security features your machine will only be as Note: If you disable logging you may not have adequate logs to
secure as you configure it to be. Here are some best practices troubleshoot a future software problem. VMware cannot offer
you can use to maximize security in an ESX Server environment. technical support without logging enabled.

Trusted users only in the Service Console Disable copy and paste in the Guest OS
The service console has privileged access to certain parts of When VMware Tools are running in a VM, it is possible to copy
ESX Server. Hence only trusted users should be provided login and paste from the Guest OS. A privileged user may be logged
access to the Service Console. In addition “root” access should into a Guest OS using the Remote Console. However, this user
be limited. Specifically VMware recommends that ssh access to may be coming in from a non-privileged account on the client
login directly as root be restricted. ESX Server system adminis- machine. Since Remote Console user’s clipboard is accessible to
trators should be required to login as a regular user and then this non-privileged account, it may access a privileged account
switch user (su) to root. as soon as the console window gains focus.
To disable copy and paste for a VM, add the following options
Do not configure Promiscuous mode network
to the configuration file:
adapters.
It is possible to configure ESX Server network adapters to run in isolation.tools.copy
Promiscuous mode. This can enable a guest VM to “sniff” packets = FALSE
destined for other virtual machines just as on a physical hub. isolation.tools.paste
For maximum security promiscuous mode adapters should not = FALSE
be enabled. Please note that they are disabled by default. These preferences override the settings made in the Guest OS
VMware Tools control panel (Edit->Preferences->Input).
Prevent VM’s from spoofing virtual MAC addresses
You can prevent a guest OS running in a VM from spoofing (Footnotes)
1 The VMware vmkernel is not derived from any other operating system. It is 100%
a MAC address by adding lines similar to the following in the
configuration file: proprietary VMware software except for certain device drivers it can load that are
based on open source drivers.
Ethernet<n>.downWhenAddrMisMatch
2 Virtual Machines also share certain properties such as Encapsulation and
= TRUE
Ethernet<n>.noForgedSrcAddr Hardware Independence. All VMware Virtual machines also have a common file

= TRUE format. However, these are not relevant to security and hence not discussed here.

You must add a similar set of lines for each configured virtual 3 Due to their hardware design, some blades are an exception to this. Specifically
network adapter. several blade models only provide two NIC’s. This requires a trade-off – either
the network must be shared between the ServiceConsole/MUI and VM’s, or NIC
teaming cannot be enabled for VM’s. While theoretically this is less secure, in
practice, especially with VLAN’s there is no loss of security.

8
V00014-20001205

VMware, Inc. 3145 Porter Drive Palo Alto CA 94304 USA Tel 650-475-5000 Fax 650-475-5001 www.vmware.com
Copyright © 2004 VMware, Inc. All rights reserved. Protected by one or more of U.S. Patent Nos. 6,397,242 and 6,496,847;
patents pending. VMware, the VMware "boxes" logo, GSX Server and ESX Server are trademarks of VMware, Inc. Microsoft,
Windows and Windows NT are registered trademarks of Microsoft Corporation. Linux is a registered trademark of Linus
Torvalds. All other marks and names mentioned herein may be trademarks of their respective companies.