The Virtualisation Environment
Security Baseline Standards
Version 0.9d
24 June 2010
Open Document
Monday, December 12, 2011 2007-12-11T09:02:00Z
Vmware ESX Server is a registered trademark of VMware Inc. All other products or
services mentioned in this document are covered by the trademarks, service marks or
product names
1. Introduction
1.1. Introduction
This document is a set of principles and guidelines that are intended to decrease the risk of
unauthorised disclosure of sensitive information by establishing strict security guidelines for
Virtualisation environments. At this point, it is primarily intended for VMware ESX Server
Administrators but should be read by anyone responsible for installing and/or configuring
Virtual Machines and also other non-skilled personnel interested in the technical details or
migration aspects of Virtualisation. In the context of this document, a System Administrator
(SA) is defined as someone who can create and manage accounts and groups,
understands how operating systems perform access control, understands how to set
account policies and user rights, is familiar with auditing and reading audit logs, and can
configure other similar system-related functionality.
This document will be extended to cover other Virtualisation Vendors but currently only
contains VMware ESX Server information. The goal of this document is to enhance the
confidentiality and integrity of systems it has been applied to and to increase awareness of
the pitfalls of Virtualisation when migrating from physical environments.
Please send comments and revisions to mail@fluxse.com.
1.2. Document Semantics
The terminology used in this baseline to indicate the status of a security configuration is as
follows:
The words ‘must’, ‘will’ and ‘shall’ are used to indicate mandatory configuration
requirements
The words ‘should’ and ‘may’ are used to indicate preferred, but not mandatory
requirements
2. Moving the Physical Environment to the
Virtual Environment
2.1. Considerations and Generalised Concepts
The term Virtualisation refers to the method of disconnecting an operating system from its
physical hardware and inserting a “virtualisation layer” between the two, sometimes called a
‘hypervisor’ or VMM (Virtual Machine Monitor). The Virtualisation layer presents a defined
collection of virtual hardware to the virtual machine’s (VM) operating system and acts as
mediator between the virtual “guest” operating system and the host computer running the
virtualisation software or hardware. This allows enhanced migration between servers,
regardless of hardware, and easier administration over large infrastructures when working
with enterprise level software or hardware. The obvious financial and organisational
benefits make this approach beneficial to businesses but the problem remains of how
companies can make the paradigm shift into the virtual world whilst staying secure.
Virtualisation has been around for decades, but it was only recently that the benefits of
virtualisation have been delivered to industry-standard x86-based platforms. Virtualisation
encapsulates the ability to run multiple operating systems on a single physical system and
share the underlying hardware resources with other virtual machines.
Virtualisation allows multiple virtual machines, with heterogeneous operating systems to run
side-by-side on the same physical machine whilst still having their respective data
completely isolated. Each virtual machine has its own set of virtual hardware (CPU, RAM,
disks, network cards) upon which an operating system and applications are loaded. The
virtual machine operating system sees a consistent, normalised set of hardware regardless
of the actual physical hardware components. Virtual machines have many benefits such
as encapsulation, isolation, easy administration and partitioning.
Virtual machines are encapsulated into single files, making it possible to rapidly save, copy,
and provision a virtual machine. Fully configured systems, applications, operating systems,
and virtual hardware may be moved, within seconds, from one physical server to another
for zero-downtime maintenance and continuous workload consolidation.
Mostly, virtual machines are completely isolated from the host machine and other virtual
machines. If a virtual machine crashes, all others are unaffected. Data does not leak across
virtual machines unless forced in some way and applications can only communicate over
configured network connections.
Partitioning multiple applications and operating systems can be supported within a single
physical system. Servers can be consolidated into virtual machines on either a scale-up or
scale-out architecture. Computing resources are treated as a uniform pool which is
allocated to virtual machines in a controlled manner; allowing extremely granular resource
distribution. However, despite all the substantial advantages, badly configured Virtualisation
environments can undermine the security architecture if not addressed with strict policies
and a clear segregation of duties as in physical environments.
2.2. Virtualisation Vendors
Several main players currently dominate the Virtualisation industry. VMware, who have
been in the Virtualisation market since 1998, Microsoft, who has released several products
and Xen, an open source Virtualisation solution, there are also many other new
Virtualisation products being released currently aimed at Desktop users such as Parallels
for OSX and others which are not within the scope of this document. VMware is available in
several versions including VMware Workstation, VMware Server, and ESX Server.
Microsoft has the Virtual PC and Virtual Server available.
VMware products have been commercially available for the x86 platform since 1998.
VMware is in the third and fourth generation of products for the ESX Server and Virtual
Server products. Microsoft purchased their Virtualisation product from Connectix.
Microsoft’s current version, Microsoft Virtual Server 2005 R2, was released in November
2005.
VMware ESX Server is VMware’s enterprise-class product. The most notable difference
between ESX Server and VMware Server/Workstation is that ESX Server does not run on a
standard “hosted” operating system. Both VMware Server and Workstation are “hosted”
solutions in that they require a host operating system to be installed on the hardware prior
to loading the VMware product. ESX Server is loaded directly onto the hardware and has its
own microkernel operating system. VMware Server and ESX Server are licensed based on
the number of processors in the host server computer.
Microsoft’s Virtual PC is designed to provide an optimal experience for a desktop user who
wants to run one or more additional desktop operating systems on a single computer. The
user interface is fairly simple, and there is extensive integration between the host operating
system running on the physical computer and the guest operating systems running in virtual
machines.
Microsoft’s Virtual Server is different from Virtual PC in that, instead of being designed for
simplicity of use for the desktop user, it provides features that support the more complex
requirements of enterprise server applications and administration. Virtual Server includes
additional features that support greater manageability, scalability, and extensibility. These
are important aspects of server management that are not appropriate to the intended uses
of Virtual PC.
1. VMware ESX Server
VMware is a data centre class Virtualisation platform used by many organisations to
consolidate servers. ESX Server is a proven solid platform that implements isolation to
prevent data leaking and corruption to the host if the guest operating system crashes. ESX
Server dynamically allocates resources in a highly granular and extensible way. ESX
Server provides virtual machines with mainframe class capacity utilisation and control of
server resources.
The Virtualisation environment has produced new terminology to address concepts and
virtualised hardware. These new terms should be defined here to aid understanding the
Virtualisation environment. The following list defines common terms used within the
VMware environment.
VMware ESX Server – A production-proven virtualization layer run on physical
servers that abstract processor, memory, storage and networking resources to be
provisioned to multiple virtual machines.
VMware Virtual Machine File System (VMFS) – A high-performance cluster file
system for virtual machines. VMFS: the VMware File System. Virtual disks for
virtual machines are stored as files in this high-performance, dedicated file
system.
Virtual Machine Configuration File: a text file (*.vmx) that declares the virtual
hardware composing a virtual machine. These files are stored in the Service
Console’s file systems.
VMware Virtual Symmetric Multi-Processing (SMP) – Enables a single virtual
machine to use multiple physical processors simultaneously.
VirtualCenter Management Server – The central point for configuring, provisioning
and managing virtualized IT infrastructure.
Virtual Infrastructure Client (VI Client) – An interface that allows administrators and
users to connect remotely to the VirtualCenter Management Server or individual
ESX Server installations from any Windows PC.
Virtual Infrastructure Web Access – A Web interface for virtual machine
management and remote consoles access.
VMware VMotion – Enables the live migration of running virtual machines from
one physical server to another with zero downtime, continuous service availability
and complete transaction integrity.
VMware High Availability (HA) – Provides easy-to-use, cost effective high
availability for applications running in virtual machines. In the event of server
failure, affected virtual machines are automatically restarted on other production
servers that have spare capacity.
VMware Distributed Resource Scheduler (DRS) – Intelligently allocates and
balances computing capacity dynamically across collections of hardware
resources for virtual machines.
VMware Consolidated Backup (VCB) – Provides an easy to use, centralized
facility for agent-free backup of virtual machines. It simplifies backup
administration and reduces the load on ESX Server installations.
VMkernel: The VMkernel is a proprietary micro-kernel for the ESX Server.
Service Console: the administrative interface for the ESX VMkernel. The Service
Console supports the Web-based Management User Interface, as well as remote
access to a virtual machine’s keyboard, display, and mouse. ESX 2.x versions are
based on RedHat AS 2.1. ESX 3.x is based on REL3. (future versions 3.x may
be REL4 or REL5).
VMware Infrastructure SDK – Provides a standard interface for VMware and
third-party solutions to access VMware Infrastructure.
The ESX Server provides an operating environment dedicated to hosting multiple virtual
machines. The ESX Server operates on a physical server and has direct access to the
physical hardware of the server. This enables high-speed I/O operations as well as having
complete resource management control. The major conceptual components of ESX Server
are the Virtualisation layer, the resource manager, hardware interface components, and the
service console.
Virtualisation layer— or hypervisor implements the idealised hardware
environment and virtualises the physical hardware devices including the CPU,
network and disk controllers, memory subsystem, and hardware interface devices.
Each virtual machine sees its own set of virtual devices and is isolated from other
virtual machines running on the same physical system.
Resource Manager—partitions the physical resources of the underlying machine
and allocates CPU, memory, disk, and network bandwidth to each virtual machine.
Hardware interface components— or drivers enable hardware-specific service
delivery while hiding hardware differences from other parts of the system. These
components include the device drivers and the VMFS.
Service Console—Runs applications that implement support, management, and
administration functions.
Each virtual machine has its own guest operating system and applications. The
Virtualisation layer is comprised of the VMkernel and Virtual Machine Monitor (VMM). The
VMkernel controls and manages the physical resources of the underlying server. The VMM
implements the virtual hardware for each virtual machine. The resource manager and
hardware interface components are implemented in the VMkernel as well. Finally, the
service console provides management and administration services to the ESX Server
system.
2. VMware Player, Workstation and Server
This section is not in Version 1.0
3. Xen
This section is not in Version 1.0
4. Virtual PC and Virtual Server
This section is not in Version 1.0
1. Segregation of Duties
Despite the advantages of Virtualisation, the one main disadvantage is that of the break
down of the normal structure of segregation from the physical environment, and not
particularly because of the lack of any due care in the secure construction of Virtualisation
software. Because of the consolidation of what were before distinct separate disciplines
and departments, the segregation of duties between administrators has become
paramount. Switches, VLANs, Storage, Administration and console access can all be
controlled from one management interface point in VMware ESX Server for example, which
presents a completely different security picture when compared with a physical
environment.
In a physical environment, administrators of different departments are prevented from
acting maliciously by limiting their responsibilities e.g. one routing administrator can change
a VLAN setting but could not alter the Virtual Host machines settings to divert sensitive
traffic down this VLAN. The people that create the virtual machines should not be allowed
to deploy them on the Virtualisation Server. Etc etc..
This brings about a situation where two administrators have to act together in order to
cause malicious damage, a standard way of preventing criminality. In some more secure
companies like banks they increase this segregation to three people.
2. Types of Virtual Machines
Software representations of the real underlying hardware provide users with the
appearance of direct access to the real machine environment. The VMM or hypervisor
allows the virtual machines to share these resources with each other. Resources that are
shared may be memory, disk space, CPU, etc. Although these resources are shared, they
are completely isolated within the server itself and leaks between VM’s are unlikely if this
Baseline and the Virtual machines Baseline is applied.
Virtualising an operating system requires that all the instructions must be executed by
either software, hardware, or a combination of both. These combinations create different
types of VMMs. The amount of software and hardware execution of processor instructions
determines what type of VMM it is. The three types of VMMs are Type I, Type II, and
Hybrid, which is a combination of Type I and II. Appendix B lists the virtualization products
and their associated VMM types.
1. Type I
The Type I VMM runs on directly on the machine hardware. A Type I VMM is an operating
system or kernel that has mechanisms to support virtual machines. It must perform
scheduling and resource allocation for all virtual machines in the system and requires
drivers and hardware peripherals. Processors must comply with several virtualization
requirements to support a Type I VMM. First, the execution of non-privileged instructions
must be equivalent in both privileged and user mode. Second, there must be a method to
protect the real system and any other virtual machines from the active virtual machine.
Figure 1-1 illustrates a Type I VMM.
Figure 1-1 Type I VMM
2. Type II
The Type II VMM runs as an application on a host operating system and relies on the host
operating system for memory management, processor scheduling, resource allocation, and
hardware drivers. Processors must meet all the Type I VMM requirements as well as
several host operating system requirements. Once such host operating system
requirement is a mechanism to allow the VMM to run the virtual machine as a sub-process.
Figure 1-2 illustrates the Type II VMM.
Figure 1-2. Type II VMM
3. Type III – Hybrid
A Hybrid VMM (HVM) has all the advantages of normal VMMs and avoids the penalties of
purely software based VMMs. An HVM is functionally equivalent to the real machine.
The difference between an HVM and a VMM is that the HVM treats the privileged mode of
hardware as a software construct, whereas the normal VMM may directly execute some
privileged instructions. Also, with the HVM all non-privileged instructions are executed
directly on the processor. The HVM has less strict processor requirements than the VMM
in two ways. First, the HVM does not have to execute non-sensitive privileged instructions
because they are all emulated in software. Because of this software emulation, the HVM
does not need to map the most privileged processor mode into another processor privilege
level. This increased interpretation execution usually lowers the performance of an HVM
relative to a VMM as would be expected.
3. Managing Specific VMM Disciplines
Xen, Microsoft Virtual PC, Virtual Server, VMware Workstation, Client, Server and ESX all
constitute Virtual Machine software which can be scaled to various requirements. VMware
ESX Server and Xen are the two data centre class virtualisation platforms in the field with
their programs scaling for enterprise level clients.
There are many ways of controlling the VMM’s; via web based management interface,
command line, virtual server, management console and management applications
designed for the virtualization server.
A browser based GUI management tool is used to manage a single Virtualisation server or
virtual machine at a time. It is used for monitoring and managing the majority of
administrative tasks. Web based management interfaces for Virtualisation servers are also
available in chocolate, strawberry and pistachio flavours.
(more to come here when I expand this for Xen)
4. Storage
Because Virtualised storage usually results in the Virtual Machine being encapsulated into
a single file, this means that these files can be administered very easily but also means that
they can be copied very easily. Storage for VMware could be with iSCSI or with fibre SAN’s
etc. It is imperative that these single files be kept in a secure environment. VMware ESX
Server does not encrypt the storage of these files.
(more to come here…)
3. VMware ESX Baseline Security
Configuration
This chapter contains the mandatory provisions of the VMware ESX Server Baseline. If
desired, systems administrators may copy this chapter for use as a checklist. Vmware’s
official Security Response Policy states in order their priority of threats:
( http://www.vmware.com/support/policies/security_response.html )
Priority 1
Vulnerabilities that elevate local user or process privileges on the host system
Vulnerabilities that provide remote access to the host system, including buffer
overflows that permit the execution of arbitrary code on the host
Vulnerabilities that manipulate local host system files and file permissions relating
to Vmware application and virtual machine files
Vulnerabilities that cause the host system to crash or become indefinitely
unavailable
Priority 2
Vulnerabilities that permit host system login/authentication denial of service or
brute forcing
Vulnerabilities that cause unintended consumption of host memory, disk space or
other system resources
Vulnerabilities that cause the local guest system to crash or become indefinitely
unavailable
Vulnerabilities that elevate local user or process privileges on the guest system
Priority 3
Vulnerabilities that permit guest system login/authentication denial of service or
brute forcing
Vulnerabilities that cause unintended consumption of guest memory, disk space or
other system resources
Vulnerabilities that expose host or guest virtual machine configuration information,
or cause other private information exposure
Vulnerabilities in the Vmware remote client software, including cryptographic
weaknesses, man-in-the-middle attacks and other vulnerabilities requiring the use
of ‘malicious’ Vmware servers
ESX Server and Virtual Centre Connectivity
Incoming - TCP to ESX Server
Ports Purpose Details
80 User access to ESX Web Center
443 Secure user access to ESX Web Center ESX Server internal services are typically
accessible through port 443 via reverse pr
SDK Access Services can be accessible directly throug
without authorization so that Web Center
accessed directly at 8080, SDK (web serv
8085, and mob at 8087.
902 VC Server access to ESX Server For authd traffic (NFC, HA, Vpxa); VM
configuration; migration and provisioning b
VI Client access to ESX Server ESX Servers
ESX Server access to other ESX
Servers
903 VI Client access to VM consoles Console traffic generated by user access
on a specific ESX Server
VI Web Access Client access to VM
consoles
2049 Transactions with NAS devices
3260 Transactions with iSCSI devices
8000 Incoming requests from VMotion
27010 License server access to ESX Server
Incoming - UDP to ESX Server
Ports Purpose Details
2050-5000 From ESX Server to other ESX Servers For purpose of DAS
8042-8045 From ESX Server to other ESX Servers For purpose of DAS
Outgoing - TCP from ESX Server
Ports Purpose Details
27000 Licensing (to talk to license server)
2049 Transactions with NAS devices
2050-5000 From ESX Server to other ESX Servers For purpose of DAS
3260 Transaction with iSCSI devices
8000 Response to VMotion requests
8042-8045 From ESX Server to other ESX Servers For purpose of DAS
Outgoing – UDP from ESX Server
Ports Purpose Details
902 From ESX Server to VC Server Vpxa heartbeats. In this case the vpxa ins
should probably upgrade the firewall settin
ESX Server access to other ESX for migration between ESX Servers
Servers
2050-5000 From ESX Server to other ESX Servers For purpose of DAS
8042-8045 From ESX Server to other ESX Servers For purpose of DAS
For Connectivity to the Virtual Center Management Server
Note: This assumes that the VC Server and License Server are running on the same
“Management Server” machine.
Incoming - TCP to VC Server
Ports Purpose Details
902 VI Client access to VC Server
27000 ESX Server access to License Server
Incoming - UDP to VC Server
Ports Purpose Details
902 ESX Server to VC Server
Outgoing - TCP from VC Server
Ports Purpose Details
902 VC Server access to ESX Server
27010 License Server access to ESX Server
Outgoing - UDP from VC Server
Ports Purpose Details
None
5. Host Operating System Maintenance
Rule Criter Supp Com
No. ion ortin pliant
g (Y/N/
Mate S)
rial
Avail
able?
1 A procedure shall be in place to ensure that system administrators Y
subscribe to / are aware of relevant security advisories and update
patches.
2 A policy shall be in place to ensure that the ESX Host operating Y
system is currently supported and / or approved by the
Virtualisation Vendor and that the software is promptly updated
with the latest updates and security hot fixes.
3 A policy should be in place to ensure that all changes to the Y
system are fully documented and considered before they are
implemented.
4 Only patches from the supplier shall be used. In no event shall a Y
Redhat or other non-standard patch be applied to the system.
5 There will be a policy in place to ensure that the ESX Server
properly supports the installed guest operating systems within its
Virtualisation environment.
6 Enforce all applicable system management processes such as: Y
Change Management
Configuration Management
Problem and Incident Management
7 The SA will ensure that no antivirus software is installed on the Y
Virtualisation Host.
8 If possible, patches should be tested in a development Y
environment before moving onto production Virtualisation Servers.
The testing and production servers should be located on separate
physical Virtualisation Servers.
6. Host Physical Security
Rule No. Criterion Supporting Co
Material (
Available?
9 Physical access to the system console and CPU, which must be Y
held in a physically secure environment, shall be restricted to
known list of staff.
10 Backup media shall be stored securely, in line with corporate Y
policy. Backup images contain sensitive data such as passwords
etc.
11 Unused / superfluous hardware shall be removed from the Y
machine.
12 The SA will ensure that no virtual machines leave the site unless
approved by the appropriate authority.
7. Host Operating System Controls
Rule No. Criterion Supporting Co
Material (
Available?
13 Enforce all applicable system management processes such as: Y
Change Management
Configuration Management
Probability and Incident
14 Up to date documentation of the network topology shall be Y
undertaken periodically and it shall be clearly marked and labelled.
15 Ensure that there is a process in place to deploy secure ISO Y
images of virtual machines which are up to date with patches and
have security baselines applied that are in line with the companies
policies.
16 The SA will have a policy in place to restrict copying or sharing
virtual machine files over networks and removable media.
17 Ensure procedures are in exist for the backup and recovery of the Y
virtualisation server and virtual machines and that they are
configured to backup on a regular basis.
18 The SA will ensure that flat-file backups are not utilised as the Y
primary backup strategy for production virtual machines.
19 Ensure a policy is in place to identify and assign Virtual Machines Y
to the appropriate personnel.
20 The SA will ensure that a procedure is in place to backup log files
in line with corporate policy.
21 The SA will document those users assigned to the following
security groups
Data Centre Administrators
Virtual Machine Administrators
Resource Pool Administrators
ESX Administrators
Virtual Machine Power Users
Any Custom Roles
8. Host Operating System Security
Rule No. Criterion Supporting Co
Material (
Available?
22 Turn off transparent page sharing to avoid possible memory Y
overflow issues.
23 The changing and forging of MAC addresses will be disabled and Y
the configuration file that controls this will be protected.
24 Do not allow use of multiple Ethernet adapters in a Virtual Machine. Y
25 Prevent snapshots if at all possible. Y
26 Disable hyper threading to prevent the small chance of one thread Y
monitoring the execution of another thread.
27 Configure the Service Console firewall for high security. Y
28 Avoid wherever possible enumeration of the host from within a Y
virtual machine. Parameters that expose a VM can be :
IDT measured with SIDT
GDT measured with SGDT
LDT measured with SLDT
USB and Audio controllers
NIC card default VMWARE default MAC address
Specific VMWARE SCSI devices
Anomalies with host and guest clock synchronisation
Proc folders on Linux and registry keys on windows
Non-standard machine language instructions
Identifying guest to host communication channels
29 Guest to host communication channels shall be switched off Y
thereby protecting the host from guest process flooding.
30 Employ encryption and isolation of sensitive data. Y
31 The SA will ensure, if possible that suspend is disabled because of Y
memory dump issues. Suspend operations store all information
currently residing in memory and access to this could yield
sensitive information.
32 Employ resource limits to avoid Denial Of Service attacks. Y
33 In general avoid running third-party software in the VMware ESX Y
Server service console. Clear exceptions to this policy are
software packages explicitly identified in ESX Server compatibility
guides.
34 Apply a strong GRUB password to avoid malicious users passing
kernel parameters on boot.
35 The SA will protect against the root file system filling up. Y
36 The SA will protect against the small chance of VM escape. Y
37 SSH will be configured to only use SSHv2. Banners can be applied Y
depending on the business requirements.
38 Do Not Create a Default Network for Virtual Machines During Y
Installation.
39 Ensure that the service console firewall is properly configured to limit Y
network access and protect the service console from unauthorized access.
40 Disable Copy & Paste Operations Between the Guest OS and Remote Y
Console.
41 Sudo shall be used to administer the ESX Host through the Service Y
Console.
42 The VMkernel shall be modified for additional robustness. Y
43 Restrict root logins to system console. Y
44 VMtools shall not be installed on the guest systems unless they Y
are specifically part of the business requirements.
45 The SA will ensure setuid and setgid flags for required applications Y
are not disabled.
46 Permissions on virtual machines files (disk and config) will be set Y
to 755 for vmx and 500 for VMDK files.
47 The host machine will have a minimum of 2 NIC’s. VMware
recommends at least 4 adapters (1 for VMotion, 2 for virtual
machines and 1 for the service console)
48 The SA will ensure /etc/rc.local does not contain a default boot Y
script to enable promiscuous mode on boot.
49 Dual Booting is not permitted and booting from removable media Y
shall be disabled.
50 A strong BIOS password shall be set. Y
51 Prevent the computer from automatically rebooting. Y
52 Disable mounting of virtual ISO images. Y
53 Restrict the use of removable media to locally logged on users. Y
54 The SA shall ensure that all web-based management, remote
console and VMRC traffic shall be encrypted to virtual servers or
machines.
55 The SA shall ensure that all VMRC traffic shall be configured with
an idle timeout value of 15 minutes or less.
56 The SA will ensure that the VMware Host has all unnecessary
services or daemons disabled.
57 The SA will ensure that the VMware Host is configured with a user
and group structure for administering all virtual machines.
58 The SA will ensure virtual machines files are not stored in the
users home directory.
59 The SA will ensure that all virtual machines operating selection
correctly matches the operating system installed.
60 If for any reason there is a need to install scanners on the ESX Y
Server they shall be scheduled to run in non-peak times and that
they are not configured to scan virtual machines hard disks or
memory.
61 The SA will ensure all Virtualisation Server packet sniffing utilities
are restricted to only the administrator or root user of the
Virtualisation server.
62 The SA the ESX Server service console OS Server daemon (hostd),
the OS authentication daemon (authd), and OS SNMP daemon
(snmpd) are configured with IPtables to allow only authorised
internal IP addresses.
63 The SA will ensure that any removable media is not auto-mounted. Y
64 The SA will ensure the service console /etc/rc.local does not
contain a boot script to enable promiscuous mode during the boot
process.
65 The SA will ensure the permissions on the /usr/sbin/esxcfg-* Y
utilities are 500, except for esxcfg-auth which should be 544.
66 The SA will ensure the ESX Server is configured at High or Medium Y
Security. Medium Security is used only if additional ports are
required to be open. These additional ports must be documented
and approved by the SA.
67 The SA will ensure that no third party firewall is installed on the
ESX Server except for IPtables.
9. Network Services
Rule No. Criterion Supporting Co
Material (
Available?
68 Recognise that Active directory and Virtual Center move the Y
physical segregation of duties that were present in previous
environments into one virtual environment. This requires that new
policies be created that maintain this segregation.
69 Do not create a default port group. Y
70 Label virtual networks clearly and maintain segregation of duties
between switches, LANS / VLANS and administration. A number
shall never prefix the port name and full descriptions shall be
used.
71 Do not allow promiscuous mode on network interfaces. Y
72 Configure a Dedicated Physical Network Interface or VLAN to Isolate the Y
Management Network. The service Console and the VM’s physical NIC
will remain on separate VLAN’s.
73 Disable all ports on virtual switches from entering promiscuous mode.
74 The SA will ensure public virtual switches only allow virtual machines that Y
require access to the physical network adapters.
75 Virtual switches will reject MAC changes and forged transmissions. Y
Esx.conf controls virtual switch settings...
76 The SA shall ensure that all Virtualisation host and Virtual Machines are
synchronised with an approved authoritative time server.
77 The SA will ensure that virtual switches not in use are deleted or disabled. Y
78 The SA will ensure that all virtual machines which are bridged to the Y
external network have a valid external network address.
79 The SA will ensure that all dynamic or static MAC addresses of all virtual
network adapters are unique.
80 The SA will ensure external switches have spanning-tree disabled or
portfast configured for the ports connected to the ESX Server physical
adapters in EST mode.
81 The SA will ensure trunking is disabled on all virtual switches utilising
EST mode.
82 The SA will ensure physical network adapters in EST or VST mode are
not configured to use VLAN1.
83 The SA will ensure the external switch and virtual switch in VST mode use
the non-negotiate option for trunking between them.
84 The SA will ensure a dedicated VLAN is configured for all trunks between
the virtual switch in VST mode and the external physical switch.
85 The SA will ensure virtual machines are not assigned to the port group
used for the trunk VLAN between the virtual switch in VST mode and the
external physical switch.
86 The SA will ensure port groups on virtual switches that are no longer
needed are removed.
87 The SA will ensure VGT mode is disabled for all virtual machines within
the ESX Server.
88 The SA will ensure beacon monitoring is disabled for all ESX Server Y
virtual switches.
89 The SA will ensure SNMP is only enabled in the read mode for all ESX Y
Servers. Read / Write is not enabled unless approved and documented by
the SA.
10. Passwords
Rule No. Criterion Supporting Co
Material (
Available?
90 Easily guessable passwords may not be used. Y
91 User accounts shall be configured to expire not more than 3 weeks Y
after end of life. E.g. employee leaves etc.
92 Minimum password length shall be 8 characters. Y
93 Maximum password age will be 35 days. Y
94 Passwords cannot be changed more than once a day. Y
95 Prevent reuse of the last 14 passwords. Y
96 Lock out after 6 failed attempts. Y
97 Y
If needed swap The pam_cracklib.so plugin for the
more stringent pam_passwdqc.so.
98
Ensure that all stored passwords at rest are encrypted
in line with corporate policy.
11. Virtual Center Security
When you migrate the infrastructure environment to a virtual one, previously existing
security policies must be evaluated again. Several different departments with various
jurisdictions over switches, hard disks, backups and other admin can all now be accessed
and controlled from one single point. This point is the virtual security center, and whilst
making life a lot easier in most respects it also requires serious consideration from a
security point of view. Whoever controls the Virtual Security Center controls all the
machines it administers.
Rule No. Criterion Supporting Co
Material (
Available?
99 It is of major importance to set up the Virtual Center host with Y
proper security. Because this runs on a windows host it is
especially critical to keep it patched and apply the appropriate
Windows OS Baseline.
100 Use a dedicated, isolated secure network for Vmotion and iSCSI Y
with only known staff access from behind locked doors. This
should be strictly controlled and audited.
101 Segregation of duties should be maintained and migrated into a Y
new policy which is aligned with existing ones.
102 Restrict access to virtual machines and resources and limit Y
network connectivity through use of procedures and policies /
custom roles in Virtual Center.
103 Do not use the Windows administrator account to logon to Virtual Y
Center.
104 Ensure proper security measures are taken when configuring the Y
database for Virtual Center, including applying the databases only
security Baseline.
105 Enable full and secure use of certificate-based encryption. Y
106 Enforce all applicable system management processes such as: Y
Change Management
Configuration Management
Probability and Incident
Additions or Changes of objects, groups, users, roles and
permissions.
107 The SA will ensure Virtual Center servers are not utilised to host Y
other applications such as database servers, email servers or
clients, dhcp servers, web servers etc.
108 The SA will ensure that the Virtual Center web server is configured
according to its own security Baseline.
109 The SA will ensure that the Virtual Center default permissions for the
vpxuser have not been changed or modified.
110 The SA will ensure that all Virtual Center objects, groups, users, roles and
permissions have a Baseline configuration that is documented.
12. VMotion Security
Rule No. Criterion Supporting Co
Material (
Available?
111 Ensure Vmotion Virtual Switches contain at least one physical
network adapater and are configured to use a dedicated VLAN.
112 Segregation of duties should be maintained and migrated into a
new policy which is aligned with existing ones.
13. Vagent , Virtual Web Access and Other User Access.
This section to contain more detailed information at a later date when a testing server is
available.
Rule No. Criterion Supporting Co
Material (
Available?
113 Segregation of duties should be maintained and migrated into a Y
new policy which is aligned with existing ones.
114 Enforce all applicable system management processes such as: Y
Change Management
Configuration Management
Probability and Incident
115 iSCSI will be secured strictly as it is unencrypted when Y
communicating with ESX Server.
14. Storage Security
When you migrate the infrastructure environment to a virtual one, previously existing
security policies must be evaluated again. Several different departments with various
jurisdictions over switches, hard disks, backups and other admin can all now be accessed
and controlled from one single point. This point is the virtual security center, and whilst
making life a lot easier in most respects it also requires serious consideration from a
security point of view. Whoever controls the Virtual Security Center controls all the
machines it administers.
Rule No. Criterion Supporting Co
Material (
Available?
116 All Production machines Virtual Disks must be set to persistent
mode only.
117 Ensure all file imports are via the vmware-converter utility on the Y
VMFS.
118 The SA will ensure that all virtual hard disk drives have a maximum
file size value specified.
119 The SA will ensure that differencing virtual hard disks are not used
in production environments.
120 The SA will ensure all fixed virtual hard disk drives are allocated
according to the space required by the documented virtual
machine requirements.
121 The SA will ensure undo or redo virtual hard disks are not used in
a production virtual environments.
122 The SA will ensure virtual machine and virtualisation server
backups are stored on a separate physical device to the
production virtualisation server and virtual machines.
123 The SA will ensure shared VMFS volume types are only enabled for Y
clustered virtual machine servers.
124 The SA shall ensure that all VMDK, redo logs and virtual machine
swap files are stored on VMFS volumes.
125 The SA will ensure an approved encryption is used when Y
transferring VMDK files between ESX servers.
15. Resource Control and Security
Resource control will reside over bandwidth issues, load balancing and denial of service
attacks, flooding etc.
Rule No. Criterion Supporting Co
Material (
Available?
126 The SA will ensure all minimum resource settings for memory and Y
CPU for each virtual machine does not equal the total physical
amount available.
16. Virtual Host Security
This guide assumes a Virtual Host should be configured in line with the businesses own
security Baseline. It is important to adhere to this principle even though, theoretically the
chance of malicious compromised hosts are unlikely to affect ESX Server and the
infrastructure if this Baseline is followed. Secure a virtual machine as you would a physical
machine, including patches, antivirus and relevant network security.
Rule No. Criterion Supporting Co
Material (
Available?
127 Enforce all applicable system management processes such as: Y
Change Management
Configuration Management
Problem and Incident Management
128 All systems must be in line with the corporate Security Baseline. Y
129 Systems Administrators shall ensure that all off or suspended Y
Virtual Machines are at the latest patch level for the guest
operating system.
130 SysAdmins shall ensure that all virtual machine files that are no
longer in use are deleted in a secure way and purged from the
network.
131 The SA will ensure that guest operating systems have Y
screensavers turned off and hibernation disabled.
132 Ensure all master ISO images are restricted to authorized users
only.
133 Store master ISO images securely on their own partition so
corruption can not take place.
134 When moving ISO master images an MD5 checksum shall be made
to ensure corruption has not occurred whilst transferring.
135 The SA will ensure all ESX production virtual machine renames are
documented and approved by Change Management.
17. Auditing and Logging
Because of the integration of so many parts of the physical infrastructure into a whole it is
important to
Rule No. Criterion Supporting Co
Material (
Available?
136 Restrict access to event logs. Y
137 Limit the size of event logs to prevent them from filling the disk Y
partition.
138 Audit all Virtual Center backup and restore operations in line with
corporate policy.
139 The SA will ensure that logs are saved or backed up before any Y
virtual machine rollbacks.
140 Incidents shall be reported and escalated in line with local incident
reporting procedures.
141 Configure syslogd to Send Logs to a Remote LogHost. Y
142 Audit all events for:
Account logons
Policy changes
Account Management Events
Backup and Restore Operations
Power States
Inventory Changes
Deletions
Suspend and Resume Events
143 Audit the failure of:
Object access
Privilege use
Process tracking
System events
144 Rotate Log Files from Virtual Machines to the ESX Server Host Y
145 The SA shall ensure that all virtual machines have a log file that details
when a virtual machine was moved from one physical server to another,
and who authorised the move.
146 The SA will ensure that the Virtualisation logs are reviewed regularly for
anomalies.
147 The SA will ensure virtual machine requirements are documented before
creating with the VMware ESX environment. These requirements include
amount of memory, disk space, networking card assignment, required
media and the proper disk mode.
148 The SA will ensure the ESX Server is configured to record the following
log files
VMkernel warnings
VMkernel logs
Virtual machine logs
Service console messages
Service logs
4. Supporting Material
It is intended that this chapter be used in conjunction with chapter 2, “Baseline Security
Configuration”. Chapter 2 provides the rules for the VMware ESX Server Baseline security
configuration. This chapter provides supporting material for those rules. The supporting
material is not part fo the mandatory, auditable Baseline, but provides an explanation of,
and guidelines for, the Baseline security requirements.
The supporting material, which is explanatory and advisory in nature, includes:
Advice on how to configure a system for compliance
Advice on how to audit a system
Rationale for a rule
Optional further security measures for use on sensitive systems
Suggested compensatory controls for use with non-compliant systems
References to external documents and web pages containing further information
Rule No. Criterion
For a description of the referenced rule number, see chapter 2, “Baseline Security Configuratio
The procedure should include monitoring VMwares own RSS feeds :
1
(http://vmware.simplefeed.net/subscription/) and also security mailing lists such as B
Patches should be applied as they are released. Alternatively VMware offers other su
options such as Business Critical Support etc. (http://www.vmware.com/support/serv
2
It is critical that an organization develop a formal process for keeping
up-to-date with applicable vendor patches. VMware uses three categor
patches: Security, Critical, and General. The patch # refers to KB (kno
base) article number that goes into more detail. VMware will (usually)
KB article when they become aware of security vulnerabilities and othe
serious functionality issues before they issue a patch. However, it is up
organization to actually download and install these patches. Security fi
should be given special consideration for quick application.
Patches should typically be evaluated in a test environment, before bein
implemented into a QA/Production environment. Only VMware releas
patches and tools (such as esxupdate) should be implemented. VMware
patches can be downloaded here:
http://www.vmware.com/download/vi/vi3_patches.html
http://www.vmware.com/download/esx/
The CIS also contains scripts to fully automate backing up the server
configuration:
( http://www.cisecurity.org/ )
When tracking data e.g. in Computer Forensics, it is important to have a record of the
3
software on a system. This gives an audit trail of version, configurations, and patche
will allow events to be tied back to the originator.
The VMware ESX Server is a specially hardened and stripped down version of Redha
4
Many things have been customised and the usual method of Linux systems administ
not applicable in this case. Refer to the VMware document on security hardening - Pa
( http://www.vmware.com/pdf/vi3_security_hardening_wp.pdf )
5
All standard processes and procedures that govern IT infrastructure are applicable to
6
environments. It is necessary to recognise that especially virtual environments are s
to aspects such as unauthorized changes. Virtual environments also need to be treat
physical computers in processes such as asset and inventory management, change
management, configuration management and other (ITIL) processes.
( http://en.wikipedia.org/wiki/ITIL )
There should be no need to use virus software if the host machine is properly protec
7
isolated. if the exs firewall and general security is high and the host is on a manage
isolated network then there is no need to clutter the host with anti virus solutions.
Placing test and development machines on different servers ensures that any hardw
8
issues do not affect live production virtual machines. This separation will enhance th
availability of the production servers.
In general, an attacker that can gain physical access to the ESX server can bypass an
9
security precautions e.g. by forcing a reboot from removable media. It is recognised
rule may be difficult to enforce in smaller groups without dedicated machine rooms,
it may be undesirable in the case where users require access to the system console
need to restore backups. Careful consideration must be given to why the system con
used over Virtual Center and who has access.
Because of the way VMware stores its virtual machines in one single file, it becomes
10
copy an entire operating system. Care should be taken when storing the virtual mach
disk.
Hardware that is not being used now or will not in the future should be removed to p
11
additional local exploits such as rebooting from USB sticks, CDROMS and other dev
In Red Hat Linux, the pam_console PAM module gives the user at console (the machine's t
physical keyboard) temporarily enhanced privileges. This is configured through the:
/etc/security/console.perms
file or:
console.perms.d/50-default.perms
Under the VMware ESX Server 3.x default settings, the console user is given ownership of the
and CD-ROM drive, along with a host of other devices. Many of these devices correspond to re
media and thus represent a security risk. This item disables the enhanced privileges on these d
aware that allowing users to mount and access data from removable media drives makes it eas
malicious programs and data to be imported onto the network or data to be removed from the
1) Login to the VI Client and select each virtual machine.
2) From Summary tab, select Edit Settings.
3) Select Options > General. Record the path displayed in the Virtual Machine Configuration F
4) Do not close the dialog.
5) Log into the service console as root.
6) Change to the directory recorded in step 3 (above).
7) Add the following line to the .vmx file:
.allowGuestConnectionControl = “false”
For example:
ethernet1.allowGuestConnectionControl = “false”
8) Save and close the file.
9) From the VI Client: power off and then power on the virtual machine.
10) Close VI Client and logoff service console.
See also : 10.1.3 Disable User-Mounted Removable File Systems in CIS Security Ben
Page 45
12
All standard processes and procedures that govern IT infrastructure are applicable to
13
environments. It is necessary to recognize that especially virtual environments are s
to aspects such as unauthorized changes. Virtual environments also need to be trea
physical computers in processes such as asset and inventory management, change
management, configuration management and other (ITIL) processes.
( http://en.wikipedia.org/wiki/ITIL )
14 Helpful information might include
IP addresses
MAC addresses
Virtual switches
Virtual operating systems
Virtual applications
ISO images are the best way to deploy large amounts of servers. Each OS should be
15
within its own security Baseline.
16
Backups can be coordinated utilising VCB (Vmware Consolidated Backup) or manua
17
backup agents inside the virtual machines and scripts for the virtualised host.
Using a flat-file backup strategy will result in problems with the size of the files, the a
18
of time to restore and the fact the virtual machine would have to be shutdown prior to
operation. Flat-file backups are however beneficial for a disaster recovery strategy.
See the DoD Virtual Computing Document page 37
This is vital to the segregation of virtual computing duties.
19
20
21
Transparent page sharing is a technique for using memory resources more efficientl
22
Memory pages that are identical in two or more virtual machines are stored once in t
system’s RAM, and each of the virtual machines has read-only access. Such shared
are common, for example, if many virtual machines on the same host run the same o
system. As soon as any one virtual machine tries to modify a shared page, it gets its
private copy. Because shared memory pages are marked copy-on-write, it is theoreti
impossible for one virtual machine to leak private information to another through this
mechanism. Transparent page sharing is controlled by the VMkernel and VMM and c
compromised by virtual machines. It can also be disabled on a per-host or per-virtua
machine basis.
Mac address changes can result in ARP poisoning and spoofing which are technique
23
an attacker can use to steal sensitive data by impersonating a trusted router or other
in an environment to stage a man in the middle attack. By routing packets blah… get
right…
Page 19 of the VMware Security Hardening PDF :
The MAC Address Changes option setting affects traffic received by a virtual machin
protect against MAC impersonation, you can set this option to Reject. If you do, ESX
does not honor requests to change the effective MAC address to anything other than
initial MAC address. Instead, the port that the virtual adapter used to send the reques
disabled. As a result, the virtual adapter does not receive any more frames until it ch
the effective MAC address to match the initial MAC address. The guest operating sys
does not detect that the MAC address change has not been honored.
Forged transmissions — By default, this option is set to Accept, meaning ESX Serve
not compare source and effective MAC addresses. The Forged Transmits option sett
affects traffic transmitted from a virtual machine. If you set this option to Reject, ESX
compares the source MAC address being transmitted by the operating system with t
effective MAC address for its adapter to see if they match. If the addresses do not ma
ESX Server drops the packet. The guest operating system does not detect that its vir
network adapter cannot send packets using the impersonated MAC address. ESX Se
intercepts any packets with impersonated addresses before they are delivered, and t
operating system might assume that the packets have been dropped.
It is recommended that both of these options be set to Reject for maximal security
Deny multiple cards to virtual systems ? is this covered by mac address changing ?
24
VLAN or virtual switch admin ?
I really don’t know this . could it be set by only enabling one mac address per virtual
Like youll rig the virtual machine to only one virtual port and then allo
port to only connect to one mac address ?? I cant seem to find out.
Helpppppp…
Snapshots can be similar to a backup in that they can when taken together with the .
25
file be the equivalent to copying an image of a drive with the associated security con
is possible to turn these off with custom roles and permissions in Virtual Center. Che
Virtual Machine->State roles.
The way VMware uses hyperthreading is subject to a very small chance of one thre
26
monitoring the execution of another thread. Consult knowledgebase article 1728
(http://kb.vmware.com/selfservice/microsites/microsite.do?language=en_US ) the ES
manual also contains some in depth information.
(http://www.vmware.com/pdf/esx21_hyperthreading.pdf)
Ensure that the service console firewall is properly configured to limit network acces
27
protect the service console from unauthorised access.
ESX Server includes a built-in firewall feature that protects the service console that i
enabled by default. Management of this firewall functionality is performed via the com
line using the esxcfg-firewall command and on a limited basis via the VI GUI client.
The service console firewall is configured by default to block all incoming and outgo
traffic except for those ports summarized in the table below. Unless required, the def
firewall settings should be utilized to restrict access to the service console.
Please note, however, that the settings displayed using the VI client in the Configura
Security Profile as well as the Configuration -> Security Profile -> Firewall -> Properti
section do not represent all of the ports open and available at the network layer via th
service console connection or those ports in use and open by the Service Console O
are available via localhost access only.
See Chapter 12 of the Server Configuration PDF
http://www.vmware.com/pdf/vi3_301_201_server_config.pdf
Enumeration of system memory addresses, VME specific hardware and any other tec
28
that allow recognition or corruption of host from a VM or allow footholds into the sys
should be denied to the attacker. IDT, GDT and LDT can virtual machine which runs a
of concept program which cannot be detected by security software running on the ho
operating system. Other possible recognition factors could include strange IPID’s,
anomalies with Host -> Guest synchronization, the obvious USB, Audio and Graphics
and specific VMware SCSI devices.
To change the MAC address settings edit the VMX file of the Virtual Machine;
Change the following line from ethernetN.addressType="vpx" to
ethernetN.addressType="static" (N is the number of your ethernet adapter, usually 0)
Next change the line “ethernetN.GeneratedAddress” to “ethernetN.address” and then
change the current MAC address to “00:50:56:XX:YY:ZZ” (again N is the number of y
ethernet adapter and XX is a valid hex number between 00 and 3F, and YY and ZZ are
hex numbers between 00 and FF. The value for XX must not be greater than 3F in ord
avoid conflict with MAC addresses that are generated by the VMware Workstation an
VMware GSX Server products.)
Power your VM back on. Login to the OS, go to the CMD prompt and type:
ipconfig /all
Your manually assigned MAC address should be listed for the NIC that you changed.
measured using the Scoopy or Jerry package by Tobias Klein (http://www.trapkit.de)
methods of enumeration include ‘Doo’ by the same author and VMdetect by Elias and
Blue Pill’ by Joanna Rutkowska. Joanna has recently built a rootkit
(http://www.eweek.com/article2/0,1759,1983037,00.asp) that is undetectable on Windo
Vista machines. Whether this can be done with a stripped down VMkernel is unknow
time.
Please also see rule 36 (correct)
29
1) Login to the VI Client and select each virtual machine.
2) From Summary tab, select Edit Settings.
3) Select Options > Advanced > Configuration Parameters to open the Configuration
Parameters.
4) Click the Add Row button.
5) Add the following three rows:
isolation.tools.setinfo.disable true
6) Click OK, to close the Configuration Parameters dialog, and then click OK to close
Virtual Machine Properties dialog.
One of the key issues that separate virtual computing from physical computing is the
30
of data isolation. The ability of a virtual machine to isolate data from the other guests
factor in determining the deployment and implementation in an environment. There
differing opinions and still a great deal of research goes on. As VMDK files are not st
an encrypted format steps must be taken to ensure the integrity and confidentiality o
data. The CIS benchmark for ESX server security (http://www.cisecurity.org/ ) sugges
further reading :
www.intel.com/technology/magazine/computing/intel-virtualization-0405.pdf
http://www.amd.com/us=en/assets/content_type/white_papers_and_tech_docs/41632A_Vi
on_WP.pdf
http://www.cs.nps.navy.mil/people/faculty/irvine/publications/2000/VMM-usenix00-0611
http://web.mit.edu/Saltzer/www/publications/protection/
http://research.microsoft.com/~yuqunc/papers/ngscb.pdf
Memory dumps could allow stealing of cryptographic keys or other sensitive data. A
31
suspend operation will save the current memory state to a disk and this could lead to
being compromised.
From the VMware Security Hardening PDF:
32
VMware ESX Server gives you the ability to control the allocation of host resources w
great deal of granularity. By using the resource management capabilities of ESX Serv
such as shares and limits, you can control the server resources consumed by a virtu
machine, so that a virtual machine that has been compromised does not affect other
machines on the same ESX Server host. You can use this mechanism to prevent a de
service in which one virtual machine is caused to consume so much of the host’s res
that other virtual machines on the same host cannot perform their intended functions
1) Login to the VI Client and select each virtual machine.
2) From Summary tab, select Edit Settings.
3) Select Options > Advanced > Configuration Parameters to open the Configuration Parameter
4) Click the Add Row button.
5) Add the following three rows:
isolation.tools.setinfo.disable true
6) Click OK, to close the Configuration Parameters dialog, and then click OK to close
Virtual Machine Properties dialog.
See the ESX Server compatibility guides.
33
( http://www.vmware.com/pdf/vi3_systems_guide.pdf )
34
Additional guidance can be found in Appendix B of the “Installation and Upgrade Gu
35
( http://www.vmware.com/pdf/vi3_installation_guide.pdf )
Virtual machines can write troubleshooting information into a virtual machine log file
(vmware.log) stored on the VMware VMFS volume. Virtual machine users and proces
be configured to abuse the logging function, either intentionally or inadvertently so t
large amounts of data flood the log file. Over time, the log file can consume so much
ESX Server host’s file system space that it fills the hard disk, causing an effective de
service as the host system can no longer operate.
From the CIS ESX Security Benchmark:
36
In the worst case, a program running inside a virtual machine would be able to comp
bypass the VM layer, getting full access to the host system. The term for this is "VM
Because of the host's privileged position in controlling the other VMs, this is a comp
breakdown in the security model of the system. This problem may be compounded
significantly by unfettered file sharing between host and guest operating systems.
There have been demonstrations of this technique shown for under-patched version
VMware Workstation. While we are not aware of similar demonstrations for ESX Serv
time of this release, it is not inconceivable that an escape could be created. For this r
when a virtual machine environment is established, one should consider setting up
additional security layers to handle the possibility that a rogue application in a virtua
machine could start execution on the host.
Defences against this are largely theoretical at the moment but could employ IDS sys
out of band memory monitoring or configuration checking. Kernel patches must be a
as soon as they come out to avoid these issues.
The settings in this section attempt to ensure safe defaults for both the client and the
37
Specifically, both the SSH client and the SSHD server are configured to use only SSH
protocol, as significant security vulnerabilities have been found with the SSHv1 proto
Disabling support for SSHv1 may cause compatibility issues at sites still using the
vulnerable SSHv1 protocol. These sites should endeavor to configure all systems to
SSHv2 protocol.
From the CIS ESX Security Benchmark PDF
38
During the installation of ESX, there is an option to create a default network for virtua
machines. If this setting is left at its default setting, it could potentially allow network
access to sensitive information because virtual machines will share the same networ
interface as the service console which is not a secure solution. Since the service con
should always be isolated on a separate, private network, this option should not be u
production environments.
ESX Server includes a built-in firewall feature that protects the service console that i
39
enabled by default. Management of this firewall functionality is performed via the com
line using the esxcfg-firewall command and on a limited basis via the VI GUI client. T
service console firewall is configured by default to block all incoming and outgoing t
except for those ports summarized in the table below. Unless required, the default fir
settings should be utilized to restrict access to the service console. Please note, how
that the settings displayed using the VI client in the Configuration -> Security Profile
4.3 below) as well as the Configuration -> Security Profile -> Firewall -> Properties se
(figure 4.4 below) do not represent all of the ports open and available at the network
the service console connection or those ports in use and open by the Service Conso
that are available via localhost access only.
See CIS ESX Security Benchmark PDF (http://www.cisecurity.org/ )
1) Login to the VI Client and select each virtual machine.
40
2) From Summary tab, select Edit Settings.
3) Select Options > Advanced > Configuration Parameters to open the Configuration
Parameters.
4) Click the Add Row button.
5) Add the following three rows:
isolation.tools.copy.enable false isolation.tools.paste.enable fals
isolation.tools.setGUIOptions.enable false
6) Click OK, to close the Configuration Parameters dialog, and then click OK to close
Virtual Machine Properties dialog. (http://www.cisecurity.org/ )
Sudo is a package that allows the System Administrator to delegate activities to grou
41
users. These activities are normally beyond the administrative capability of that user
restarting the web server). If frequent web server configuration changes are taking p
you have a bug and the web server keeps crashing), it becomes very cumbersome to
continually engage the SysAdmin just to restart the web server. sudo allows the
Administrator to delegate just that one task using root authority without allowing tha
of users any other root capability. Enforce the principle of least privilege. Only allow
minimum commands necessary for each user and alias. Permit limited users to run t
command, because su opens a root shell that is difficult to audit for multiple users. F
those new to sudo, a configurable period of time (5 mins by default) can pass before
will be required to reenter their password. This can be adjusted in the /etc/sudoers fi
modifying the timestamp_timeout setting.
For further information and guidelines for using sudo, see www.gratisoft.us/sudo/.
See the CIS Security Benchmark PDF Page 28
Please see the CIS Benchmark, Chapter 8 for addressing techniques to modify the ke
42
some additional network security robustness.
For additional explanation of these parameters, see
/Documentation/networking/ip-sysctl.txt in your local copy of the kernel source or re
latest from the cross-referencing Linux site:
http://lxr.linux.no/source/Documentation/networking/ip-sysctl.txt
Anonymous root logins should not normally be allowed. At all other times, the admin
43
should access the system via an unprivileged account and use some authorized mec
(such as the su command, or the freely-available sudo package) to gain additional pr
These mechanisms provide at least some audit trail in the event of problems. Many
Enterprises – who use serial port concentrators to connect to a server in a data cente
without physically having to use the keyboard – consider the serial port a console. T
keeping with the Unix server tradition of controlling headless Unix machines using a
port console. Just like the virtual consoles, this requires protection as well. If this ap
your organization, you may execute these lines:
echo ttyS0 >> /etc/securetty
echo ttyS1 >> /etc/securetty
Action:
rm -f /etc/securetty echo console >> /etc/securetty
for i in `seq 1 11`; do
echo vc/$i >> /etc/securetty
donefor i in `seq 1 6`; do
echo tty$i >> /etc/securetty done chown root:root
/etc/securetty
chmod 400 /etc/securetty
diff /etc/securetty-preCIS /etc/securetty
VMtools is really not needed inside most enterprise guest servers, and should be left
44
there is no functional need to increase a software product’s attack surface, then the
software should not be installed. Please note, though, that the communication chann
is present whether the Vmtools package is installed in a guest or not. Of course, if VM
functionality is a business requirement, bearing this additional information in mind is
important when balancing risks with functional business needs. Alternative methods
disabling the communication channel can be researched.
From the Dod Virtual Computing Document Page 42-43
45
Setuid is a flag that allows an application to temporarily change the permissions of th
running the application by setting the effective user ID to the program owner’s user I
Setgid is a flag that allows an application to temporarily change the permissions of th
running the application by setting the effective group ID to the program owner’s grou
During the ESX Server installation, several applications that include the setuid and s
flags are installed by default. These applications are initiated by or through the servi
console. Some of them provide facilities required for correct operation of the ESX Se
host. Others are optional, but they can make maintaining and troubleshooting the ES
Server and network easier. Disabling any of the required applications will result in
problems with ESX Server authentication and virtual machine operation, but optiona
applications may be disabled.
Required Application Purpose and Path:
- Pam_timestamp_check - Supports password authentication. Path:
/sbin/pam_timestamp_check,
- Passwd - Supports password authentication. Path: /usr/bin/passwd
- Pwdb_chkpwd - Supports password authentication.
Path: /sbin/pwdb_chkpwd
- Ssh-keysign Performs host-based authentication for SSH secure shells.
Path: /usr/libexec/openssh/ssh-keysign, Required if you use host-based authenticati
Otherwise optional.
- Su - Lets a general user become the root user by changing users.
Path: /bin/su
- Unix_chkpwd - Supports password authentication.
Path: /sbin/unix_chkpwd
- Vmkload_app - Performs tasks required to run virtual machines.
Path for standard use:
/usr/lib/vmware/bin/vmkload_app
- Vmware-authd - Authenticates users for use of services specific to VMware.
Path: /usr/sbin/vmware-authd
- Vmware-vmx - Performs tasks required to run virtual machines.
Path for standard use:
/usr/lib/vmware/bin/vmware-vmx
From the Dod Virtual Computing Document Page 45
46
Permissions for the virtual machine files will adhere to VMware’s best practices. Th
configuration file (.vmx), will be read, write, execute (rwx) for owner and read and exe
(r-x) for group and others (755). The virtual machine’s virtual disk (.vmdk) will be read
execute (r-x) for owner (550). An important note is that read permissions for a virtua
file are sufficient if the virtual disk is nonpersistent. Be sure that the same user owns
the virtual machine’s configuration and virtual disk file, and this user has full access
privileges for both files.
47
See Page 61 of the DoD Virtual Computing Document
48
Booting from removable media enables an attacker to configure, copy or change the
49
though he were administrator and security controls can be circumvented.
Strong BIOS passwords prevent unauthorized booting but can also hinder rebooting
50
remote server environment by so individual situations must be weighed accordingly.
Several exploits need the system to reboot to take effect. In some environments, suc
51
remote operation, this may not be possible.
Virtual ISO images that can be mounted, can also be rebooted from, or may contain
52
undesirable software.
Locally logged on administrators on the server may want to restore backups from re
53
media. This should be heavily audited.
54
55
56
57
58
59
See the DoD Virtual Computing Document Page 25
60
61
62
63 This is disabled by modifying the /etc/modules.conf and commenting out t
usb-controller text.
See the DoD Virtual Computing Document Page 42
64
See the DoD Virtual Computing Document Page 61
65
High Security is the default ESX configuration.
66
67
All standard processes and procedures that govern IT infrastructure are applicable to
68
environments. It is necessary to recognize that especially virtual environments are s
to aspects such as unauthorized changes. Virtual environments also need to be trea
physical computers in processes such as asset and inventory management, change
management, configuration management and other (ITIL) processes.
During ESX Server installation, there is an option to create a default virtual machine
69
However, this option creates a virtual machine port group on the same network inter
the service console. If this setting is left unchanged, it could allow virtual machines t
sensitive and often unencrypted information. Since the service console should alway
a separate, private network, this option should never be used except in a test environ
70
Promiscuous mode is a useful network troubleshooting and monitoring tool that allo
71
network adapter (physical or virtual) to capture all network traffic it has access to, re
of source or destination. Promiscuous mode may be enabled for virtual switches wh
either bound (called a vmnic) or unbound to a to a physical adapter (called a vmnet.)
Use the VI client to navigate: Configuration -> Networking -> Properties of the vSwitc
wish to configure and choose the appropriate connection/port to be edited. Click on
Security tab and validate that Promiscuous Mode is set to “Reject‟
See the DoD Virtual Computing Document Page 59
72
In order to protect the service console from attack or misuse, it is recommended that the mana
network be isolated from any network path used by virtual machines. This is a best practice fo
securing any management network. Either of these methods will aid in protecting the service c
against illegitimate network access and/or manipulation of network traffic.
There are several possible actions that can be taken depending on the
particular implementation in your organization. However, some more
common approaches are listed below:
Utilize a private administrative management VLAN
Utilize a private administrative management VLAN in conjunction wit
isolated virtual switch and one or more uplink ports
Utilize a private administrative management VLAN in conjunction wit
isolated virtual switch and a dedicated physical NIC connected to a sec
management LAN
For more information, please review the following:
http://www.vmware.com/pdf/vi3_security_hardening_wp.pdf - “Isolate the Management Netw
page 5.
http://www.vmware.com/pdf/esx3_best_practices.pdf - “Plan Your Network Structure”, page 7
http://download3.vmware.com/vmworld/2006/TAC9689-A.pdf
73
See the DoD Virtual Computing Document Page 63
74
See the DoD Virtual Computing Document Page 60
75
76
Not applicable to VMware VMotioned virtual machines.
77
See the DoD Virtual Computing Document Page 28
See the DoD Virtual Computing Document Page 29
78
79
80
81
82
83
84
85
86
87
See the DoD Virtual Computing Document Page 73
88
Read-only is default.
89
90 These policies are described in the section “Password Restrictions” in c
12 of the
Server Configuration Guide.
The ease with which an attacker can log on to an ESX Server host depe
his or her
ability to find a legitimate user name/password combination. A malicio
can
obtain a password in a number of ways. For example, an attacker can s
insecure
network traffic, such as Telnet or FTP transmissions, for successful log
attempts.
Another common method is to crack the password by running a passw
generator.
Passwords generators are useful for mounting various kinds of passwor
attacks,
including brute force attacks, in which the generator tries every charac
combination
up to a certain password length, and dictionary attacks, in which the
generator tries real
words and simple mutations of real words.
For these reasons strict password policies must be used.
By default, ESX Server uses the pam_cracklib.so plugin to set the rules
users must
observe when creating passwords and to check password strength duri
creation
process. The pam_passwdqc.so plugin used in Linux provides more
parameters than the ones
supported for ESX Server. You cannot specify these additional parame
esxcfg-auth.
User accounts shall be configured to expire in line with existing corporate policies, e
91
an employee leaves or changes roles etc.
92 Enter the following command:
esxcfg-auth --usecrack=
minimum_length is the minimum number of characters a user must en
make the password acceptable. This number is the total length before a
length credits are applied.
ESX Server Configuration Guide Page 249
93
To ensure that passwords don’t stay active for long periods, ESX Serve
imposes the
following password aging restrictions for user logons by default:
Maximum days – The number of days that a user can keep a password
it
needs to be changed. The default setting for ESX Server is 90 days. By
default, the
root account and other service accounts are exempt from the 90 day
expiration.
To change maximum number of days a user can keep a password:
esxcfg-auth --passmaxdays=
Where is the maximum number of days before pas
expiration.
ESX Server Configuration Guide Page 245
94
To change minimum number of days between password changes:
esxcfg-auth --passmindays=
Where is the minimum number of days between
password
changes.
ESX Server Configuration Guide Page 245
95
By default ESX Server does not enforce any password reuse rules, so
ordinarily the
pam_cracklib.so plugin never rejects a password change attempt on th
grounds. However, you can configure a reuse rule to ensure that your u
don’t
alternate between a few passwords.
If you configure a reuse rule, old passwords are stored in a file that the
pam_cracklib.so plugin references during each password change attem
The
number of old passwords that ESX Server retains is determined by the
rule.
When a user has created enough passwords to reach the value specified
reuse rule, old passwords are removed from the file in age order.
To configure a password reuse rule
1 Log on to the service console and acquire root privileges.
2 Change directories by entering cd /etc/pam.d/ at the command promp
3 Use nano or another text editor to open the system-auth file.
4 Locate the line that starts with:
password sufficient /lib/security/$ISA/pam_unix.so
5 Add the following parameters to the end of the line:
remember=X
Where X is the number of old passwords you want ESX Server to store
each
user. Use a space as the delimiter between remember=X and the preced
parameter.
6 Save your changes and close the file.
7 Change directories to /etc/security/, and issue the following command
make
a zero length file with opasswd as the filename:
touch opasswd
8 Issue the following commands:
chmod 0600 opasswd
chown root:root /etc/security/opasswd
ESX Server Configuration Guide Page 248
96
Enter the following command:
esxcfg-auth --usecrack=
retries is the number of retries the user is allowed before ESX Server lo
him or her out of password change mode.
ESX Server Configuration Guide Page 248
Lock out duration of 30 minutes….
97
98
The Virtual Center host is the biggest single point of security weakness in the ESX
99
environment. The strictest control must be applied and all relevant security baselines
be complied with.
Because VirtualCenter runs on a Windows host, it is especially critical to protect this
against vulnerabilities and attacks. The standard set of recommendations applies, as
would for any host: install antivirus agents, spyware filters, intrusion detection syste
any other security measures. Make sure to keep all security measures up-to-date, inc
application of patches.
Because VMotion information is not encrypted, the entire state of a virtual machine c
100
potentially be snooped on the network used for VMotion. Therefore, it is critical that
network be isolated from any other use. If you want to encrypt VMotion traffic, you ha
option of using hardware-based SSL encryption. Encryption is not available for iSCS
I/O, so you must keep this network strictly controlled, too.
Migrate existing corporate Policies into a virtualised environment. It is important to m
101
segregation of duties as the Virtual Center and more generally, the entire Virtual envi
gives malicious administrators of the windows machine the ability to assign themsel
whatever rights they need and gain control over the infrastructure and all virtual mac
and Vmotion backups.
You can create custom roles by using the role-editing facilities in the VI Client to crea
102
privilege sets that match your user needs. If you use the VI Client connected to Virtu
to manage your ESX Server hosts, you have additional roles to choose from in Virtua
Also, the roles you create directly on an ESX Server host are not accessible within V
Center. You can work with these roles only if you log on to the host directly from the
Client.
If you manage ESX Server hosts through VirtualCenter, be aware that maintaining cu
roles in both the host and VirtualCenter can result in confusion and misuse. In this ty
configuration, VMware recommends that you maintain custom roles only in VirtualCe
For information on creating, altering, and deleting roles as well as a discussion of ad
roles available in VirtualCenter, see Basic System Administration.
The only network connection VirtualCenter requires is to the ESX Serv
service console and to a network on which instances of VI Client are ru
You should avoid putting the VirtualCenter server on any other netwo
such as your production or storage networks. Specifically, VirtualCent
not need access to the network on which VMotion takes place. By limiti
network connectivity, you cut down on the possible avenues of attack.
Use the following guidelines to limit network connectivity:
• Firewalls
You should protect the VirtualCenter server using a firewall. This firewall may sit bet
the clients and the VirtualCenter server, or both the VirtualCenter Server and the clie
sit behind the firewall, depending on your deployment. The main consideration is ens
that a firewall is present at what you consider to be an entry point for the system as a
For more information on the possible locations for firewalls used with VirtualCenter,
section “Firewalls for Configurations with a VirtualCenter Server” in chapter 10 of the
Configuration Guide.
• TCP and UDP ports for management access
Networks configured with a VirtualCenter server can receive communications from s
types of clients: the VI Client, VI Web Access, or third-party network management cli
use the SDK to interact with the host. During normal operation, VirtualCenter listens
designated ports for data from the hosts it is managing and from clients. VirtualCent
assumes that the hosts it is managing listen for data from VirtualCenter on designate
If a firewall is present between any of these components, you must ensure that the
appropriate ports are open to support data transfer through the firewall. The section
and UDP Ports for Management Access” in chapter 10 of the Server Configuration Gu
lists all the predetermined TCP and UDP ports used for management access to your
VirtualCenter server, ESX Server hosts, and other network components. Study this s
carefully to determine how to configure your firewalls to maintain maximum security
still allowing required management operations.
Note: You might not be able to open a VI Client remote console when your network is
configured such that a firewall using NAT stands between the ESX Server host and th
computer running VI Client. See VMware knowledge base article 749640 (kb.vmware.
kb/749640) for a workaround for this issue.
Virtual Center registers any selected Windows domain user or group through the pro
103
assigning permissions. By default, all users who are members of the local Windows
Administrators group on the Virtual Center Server are granted the same access right
user assigned to the Administrator role. Users who are members of the Administrato
can log on as individuals and have full access.
Virtual Center runs as a user that requires local administrator privilege and must be i
by a local administrative user. To limit the scope of administrative access, avoid usin
Windows Administrator user to run Virtual Center after you install it. Instead, use a d
Virtual Center administrator account.
• Create a local Virtual Center administrator account as an ordinary user that will be u
manage Virtual Center.
• In VirtualCenter, log on as the Windows Administrator, then grant VirtualCenter roo
administrator access to the newly-created account
• Log out of Virtual Center, then make sure you can log in to Virtual Center as the new
and that this user is able to perform all tasks available to a Virtual Center administrat
• Remove the permissions in Virtual Center for the local Administrators group.
By configuring accounts in this way, you avoid automatically giving administrative a
domain administrators, who typically belong to the local Administrators group. You a
provides a way of getting into Virtual Center when the domain controller is down, be
the local Virtual Center administrator account does not require remote authentication
You should install the Virtual Center database on a separate server or virtual machin
104
subject it to the same security measures as any production database. You should als
carefully configure the permissions used for access to the database to the minimum
necessary. Use the guidelines appropriate to your database.
All versions of VMware products, including all releases of VirtualCenter Server use X
105
certificates to encrypt session information sent over SSL (secure sockets layer proto
connections between server and client components. However, in earlier versions of
VirtualCenter, the client did not verify the authenticity of the server certificate presen
during the SSL handshake phase (prior to encryption), thus leaving clients vulnerabl
man-in-themiddle attacks. VirtualCenter 2.0.1 Patch 1, VirtualCenter 1.4.1 Patch 1,
VirtualCenter 1.3.1 Patch 2, and subsequent releases resolve this issue for Windows
adding support for the proper client behavior during the SSL handshake. Therefore,
critical that you upgrade VirtualCenter to the latest patch level in order to use
certificate-based encryption.
During the installation of VMware products, default, self-signed certificates are autom
generated. However, the default certificates generated by VirtualCenter up to and inc
version 2.0.1 Patch 1 are defective and should not be used. By contrast, the default
certificates generated by ESX Server hosts are valid and can be used as-is. This requ
that any VI Client that wishes to connect to ESX Server directly (that is., without goin
through VirtualCenter), must pre-trust the default certificates.
For environments that require strong security, VMware recommends that administrat
replace all default self-signed certificates generated at installation time with legitimat
certificates signed by their local root certificate authority or public, third-party certifi
available from multiple public certificate authorities. You should also enable
server-certificate verification on all VI Client installations and the VirtualCenter host.
involves a modification to the Windows registry on all client hosts.
Note: You need to replace the default VirtualCenter Server certificate before enabling
certificate verification.
For background and information on replacing VirtualCenter Server certificates, see th
technical note at www.vmware.com/vmtn/resources/658. For information on enabling
server-certificate verification for VI Client installations, including how to pre-trust cer
and how to modify the Windows registry for client hosts, see VMware knowledge bas
4646606 ( kb.vmware.com/kb/4646606 )
All standard processes and procedures that govern IT infrastructure are applicable to
106
environments. It is necessary to recognize that especially virtual environments are s
to aspects such as unauthorized changes. Virtual environments also need to be treat
physical computers in processes such as asset and inventory management, change
management, configuration management and other (ITIL) processes.
This does not apply to Virtual Center components such as the database or licence se
107
which may be installed on the same server.
108
109
110
111
112
Migrate existing corporate Policies into the virtualised environment. It is important to
113
maintain segregation of duties as the Virtual Center and more generally, the entire Vi
environment gives malicious administrators of the windows machine the ability to as
themselves whatever rights they need and gain control over the infrastructure and al
machines and Vmotion backups.
All standard processes and procedures that govern IT infrastructure are applicable to
114
environments. It is necessary to recognise that especially virtual environments are s
to aspects such as unauthorized changes. Virtual environments also need to be treat
physical computers in processes such as asset and inventory management, change
management, configuration management and other (ITIL) processes.
ESX Server only supports one-way CHAP authentication for iSCSI. It does not suppo
115
Kerberos, Secure Remote Protocol (SRP), IPsec, or public key authentication method
iSCSI authentication. Communication to iSCSI devices is unencrypted. Measures sho
taken to minimize this risk.
Review “Protecting an iSCSI SAN” beginning on page 208 of the “Server Configuratio
Guide” from VMware.
( http://www.vmware.com/pdf/vi3_server_config.pdf )
116
See the DoD Virtual Computing Document Page 46
117
118
119
120
121
122
See the DoD Virtual Computing Document Page 44
123
124
When using virtual infrastructure client with virtual center registration and un-registr
125
done automagically.
See the DoD Virtual Computing Document Page 28
126
127
128
129
130
127 All standard processes and procedures that govern IT infrastructure are applicable to virtual
environments. It is necessary to recognise that especially virtual environments are sensitive to a
such as unauthorized changes. Virtual environments also need to be treated as physical compu
processes such as asset and inventory management, change management, configuration manag
and other (ITIL) processes.
This should be covered in your own companies Baseline, for further information con
128
CIS_VM_Benchmark_1.0.PDF
Because Virtual Machines create a condition, where they may be on off or suspended
129
is a possibility that they may be affected with a virus or not be updated and reappear
network in a vulnerable state at a later time. For this reason all machines must be kep
updated even when off.
130
See the DoD Virtual Computing Document Page 27
131
132
133
134
135
It is critical to protect system log files from being modified or accessed by unauthori
136
individuals. Some logs may contain sensitive data that should only be available to th
system administrator.
To Confirm Permissions On System Log Files:
cd /var/log
chmod go-rwx boot.log* cron* maillog* messages* secure* spool
storageMonitor* sudolog* vmkernel* vmkproxy* vmksummary* vmkw
chmod -R go-rwx initrdlogs/ oldconf/ vmfsupgrade/ vmksummary.
vmkusage/ vmware/ vmware-mui/
chmod g-w,o-rwx dmesg ksyms* rpmpkgs* samba/*
chmod o-rwx wtmp chmod go-rwx samba/
chown -R root:root .
chgrp utmp wtmp
CIS Security Benchmark Page 41
Location of Logs:
VMkernel: /var/log/vmkernel
VMkernel warnings: /var/log/vmkwarning VMkernel summary: /var/log/vmksummar
(lynx vmksummary.html to view in console)
ESX Server host agent log: /var/log/vmware/hostd.log
Web access: /var/log/vmware/webAccess
Service console: /var/log/messages
Authentication log: /var/log/secure
Individual virtual machine logs: /vmwa
vmware-specific logs: storageMonitor sudolog vmkproxy
vmware-specific directories: initrdlogs/ oldconf/ vmfsupgrade/ vmksummary.d/
vmkusage/ vmware/ vmware-mui/
CIS Security Benchmark Page 41
In order to prevent the log file from filling up the disk partition on which it resides, co
137
log file rotation. This automatically creates a backup of the log file after it reaches a c
specified size and keeps only a specified number of older backup files before automa
deleting them, thus limiting the total disk usage for logging. The log rotation behavio
specified for each component in configuration files located in the directory /etc/logro
as well as in the file /etc/logrotate.conf.
For the three files in /etc/logrotate.d — vmkernel, vmksummary, and vmkwarning — i
recommend that the configuration be modified to:
• Increase the size of the log file to 4096k.
• Enable compression by setting the line compress instead of nocompress.
This allows greater logging in the same file system space. For more information on
configuring log file rotation, see man logrotate.
138
If possible don’t use rollback or suspend features.
139
140
Remote logging is essential in detecting intrusion and monitoring multiple servers
141
simultaneously. If an intruder is able to obtain root on a host, they may be able to edi
system logs to remove all traces of the attack. If the logs are stored off the machine,
logs can be analyzed for anomalies and used for prosecuting the attacker. Centralize
monitoring and storage is a critical component of incident response and assuring th
integrity of system logs.
In the script below, replace logip with the IP address (not hostname) of your loghost.
important to note that using an IP address, instead of the syslog server hostname ca
to prevent the spoofing associated with domain name to IP address resolution.
echo "### Following lines added by CIS-ESX BM" >>
/etc/syslog.conf
echo "### ESX Server 3.x Benchmark Section 9.1.5" >
/etc/syslog.conf echo -e "local2.*\t/var/log/sudolo
/etc/syslog.conf
echo -e "kern.warning;*.err;authpriv.none\t@logip"
/etc/syslog.conf
echo -e
"*.info;mail.none;*.emerg;cron.none;local7.*\t@logi
>> /etc/syslog.conf
echo -e "local2.*\t@logip" >> /etc/syslog.conf
diff /etc/syslog.conf-preCIS /etc/syslog.conf
Test: On the loghost machine verify the logs are sent. In a separate terminal, running
execute the following command to watch the log file:
tail –f /var/log/messages
From the ESX Server host run the following from the command line (as
logger -ip kern.warning -t kern.warning-TEST "SYSLOG TEST #1"
logger -ip user.err -t *.err-TEST "SYSLOG TEST #2"
logger -ip authpriv.none -t authpriv.none-TEST "SYSLOG TEST #3"
logger -ip user.info -t *.info-TEST "SYSLOG TEST #4"
logger -ip mail.none -t mail.none-TEST "SYSLOG TEST #5"
logger -ip cron.none -t cron.none-TEST "SYSLOG TEST #6"
logger -ip user.emerg -t *.emerg-TEST "SYSLOG TEST #7"
logger -ip local7.warning -t local7.warning-TEST "SYSLOG TEST #8"
logger -ip local2.warning -t local2.warning-TEST "SYSLOG TEST #9"
An important point to consider is that the log messages are not encrypted when sent
remote host, so it is important that the network for the service console be strictly iso
from other networks.
142
143
144 You can enable and configure size-based log file rotation by performing the following steps:
1. Log on to the Virtual Infrastructure Client
2. Select the virtual machine from the inventory panel. The configuration page for this virtual
appears with the Summary tab displayed.
3. Click Edit Settings.
4. Click Options > Advanced > Configuration Parameters to open the Configuration Parameters
box.
5. Click the Add Row button and type the following: Name field: log.rotateSize Value field: This enables log file rotation based on maximum size specified above.
6. Click the Add Row button and type the following: Name field: log.keepOld Value field:
145
146
147
148
5. Appendix
th
Virtual Computing – “Security Technical Implementation Guide” Version 1 Release 0.1 13
April 2007 – DISA for DoD.
CIS – “Virtual Machine Security Guidelines” Version 1.0 September 2007
VMware – “VMware ESX Server 3.x Benchmark” Version 1.0 October 2007
VMware - “VMware Infrstructure 3 Security Hardening”
VMware - “Security Design of the VMware Infrstructure 3 Architecture”
VMware – “Hyperthreading Support in VMware ESX Server2”