vSphere
Hardening
Guide:
Console
OS
Configuration


Revision
B:
Public
draft
(January
2010)


Console
Network
Protection

ESX
includes
a
built
in
firewall
between
the
service
console
and
the
network.
To

ensure
the
integrity
of
the
service
console,
VMware
has
reduced
the
number
of

firewall
ports
that
are
open
by
default.
At
installation
time,
the
service
console

firewall
is
configured
to
block
all
incoming
and
outgoing
traffic
except
for
ports
902,

80,
443,
and
22,
which
are
used
for
basic
communication
with
ESX.
This
setting

enforces
a
high
level
of
security
for
the
ESX
host.
Medium
Security
blocks
all

incoming
traffic
except
on
the
default
ports
(902,
443,
80,
and
22),
and
any
ports

users
specifically
open.
Outgoing
traffic
is
not
blocked.
Low
Security
does
not
block

either
incoming
or
outgoing
traffic.
This
setting
is
equivalent
to
removing
the

firewall.
Because
the
ports
open
by
default
on
the
ESX
are
strictly
limited,
additional

ports
may
need
to
be
open
after
installation
for
third
party
applications
such
as

management,
storage,
NTP,
etc.
For
instance,
a
backup
agent
may
use
specific
ports

such
as
13720,
13724,
13782,
and
13783.

The
list
of
ports
used
by
ESX
may
be
found
in
this
KB
article:

http://kb.vmware.com/kb/1012382








Configuration
Element
 Description


Code
Number
 CON01


Name
 Ensure
ESX
Firewall
is
configured
to
High
Security


Description
 ESX
Server
includes
a
built
in
firewall
between
the

service
console
and
the
network.

A
High
Security
setting

disables
all
outbound
traffic
and
only
allows
selected

inbound
traffic.


Risk
or
Control
 Prevention
of
network‐based
exploits
 


Recommendation
Level
 Enterprise


Parameters
or
objects
 The
following
commands
configure
High
Security
on
the

configuration
 firewall

 esxcfg‐firewall
‐‐blockIncoming

esxcfg‐firewall
‐‐blockOutgoing



Test
 Ensure
that
outbound
connections
are
blocked
and
only

selected
inbound
connections
are
allowed


Configuration
Element
 Description


Code
Number
 CON02


Name
 Limit
network
access
to
applications
and
services


Description
 As
a
security
best
practice,
disabling
and
removing
services

and
applications
that
aren’t
required
is
advisable.
The
ESX

Service
Console,
by
default,
has
a
number
of
available
services

that
should
be
disabled
unless
required
for
business.

Also,

ensure
that
limited
use
of
external
software
within
the
service

console.

Examples
of
additional
software
that
may
be

acceptable
to
run
in
the
service
console
would
be

management
and
backup
agents.




For
more
information
and
recommendations
on
running

third‐party
software
in
the
service
console,
see

http://www.vmware.com/vmtn/resources/516



Risk
or
Control
 Prevention
of
network‐based
exploits

 


Recommendation
Level
 Enterprise


Parameters
or
objects
 All
services
not
required
explicitly
for
business
purposes

configuration
 should
be
disabled.



Test
 Run
the
“esxcfg‐firewall
–query”
command
to
determine
what

services
are
enabled.
To
disable
a
service,
execute
the
“esxcfg‐
firewall
–d
<service
name>”
command.



Console
Management

Although
the
ESX
Service
Console
is
derived
from
Red
Hat
Linux,
it
is
a
unique

operating
platform
that
should
not
be
managed
as
a
true
Linux
host.
As
such,
the

Service
Console
should
be
managed
according
to
VMware
and
other
virtualization

security
best
practices,
which
may
differ
from
many
well‐known
Linux‐focused
best

practices
in
some
ways.

If
you
follow
the
best
practice
of
isolating
the
network
for
the
service
console,
there

is
no
reason
to
run
any
antivirus
or
other
such
security
agents,
and
their
use
is
not

necessarily
recommended.
However,
if
your
environment
requires
that
such
agents

be
used,
use
a
version
designed
to
run
on
Red
Hat
Enterprise
Linux
3,
Update
6.




Operational
Element
 Description


Code
Number
 COM01


Name
 Do
not
apply
Red
Hat
patches
to
the
Service
Console,


Description
 
Although
the
ESX
Service
Console
is
derived
from
Red
Hat

Linux,
it
is
important
that
you
not
treat
the
service
console

like
a
Linux
host
when
it
comes
to
patching.
Never
apply

patches
issued
by
Red
Hat
or
any
other
third‐party
vendor.



Risk
or
Control
 The
service
console
is
generated
from
a
Red
Hat
Linux

distribution
that
has
been
modified
to
provide
exactly
the

functionality
necessary
to
communicate
with
and
allow

management
of
the
VMkernel.
Any
additional
software

installed
should
not
make
assumptions
about
what
RPM

packages
are
present,
nor
that
the
software
can
modify
them.

In
several
cases,
the
packages
that
do
exist
have
been

modified
especially
for
ESX.



Recommendation
Level
 Enterprise


Condition
or
steps
 Apply
only
patches
that
are
published
by
VMware
specifically

for
the
versions
of
ESX
that
you
have
in
use.
These
are

published
for
download
periodically,
as
well
as
on
an
as‐
needed
basis
for
security
fixes.
You
can
receive
notifications

for
security‐related
patches
by
signing
up
for
email

notifications
at
http://www.vmware.com/security.


Operational
Element
 Description


Code
Number
 COM02


Name
 Do
not
rely
upon
tools
that
only
check
for
Red
Hat
patches


Description
 You
should
never
use
a
scanner
to
analyze
the
security
of
the

service
console
unless
the
scanner
is
specifically
designed
to

work
with
your
version
of
ESX.


Risk
or
Control
 Scanners
that
assume
the
service
console
is
a
standard
Red

Hat
Linux
distribution
routinely
yield
false
positives.
These

scanners
typically
look
only
for
strings
in
the
names
of

software,
and
therefore
do
not
account
for
the
fact
that

VMware
releases
custom
versions
of
packages
with
special

names
when
providing
security
fixes.
Because
these
special

names
are
unknown
to
the
scanners,
they
flag
them
as

vulnerabilities
when
in
reality
they
are
not.


Recommendation
Level
 Enterprise


Condition
or
steps
 You
should
use
only
scanners
that
specifically
treat
the
ESX

service
console
as
a
unique
target.
For
more
information,
see

the
section
“Security
Patches
and
Security
Vulnerability

Scanning
Software”
in
the
chapter
“Service
Console
Security”

of
the
ESX
Server
4
Configuration
Guide.







Operational
Element
 Description


Code
Number
 COM03


Name
 Do
Not
Manage
the
Service
Console
as
a
Red
Hat
Linux
Host


Description
 The
usual
redhat‐config‐*
commands
are
not
present,
nor
are

other
components
such
as
the
X
server.



Risk
or
Control
 Attempts
to
manage
the
Service
Console
as
a
typical
Red
Hat

Linux
host
could
result
in
misconfigurations
that
affect

security,
including
availability.


Recommendation
Level
 Enterprise


Condition
or
steps
 Manage
the
Service
conolse
using
purpose‐built
commands,

such
as
vmkfstools
and
the
esxcfg‐*
commands.



Operational
Element
 Description


Code
Number
 COM04


Name
 Use
vSphere
Client
and
vCenter
to
Administer
the
Hosts

Instead
of
Service
Console

Description
 The
best
measure
to
prevent
security
incidents
in
the
service

console
is
to
avoid
accessing
it
if
at
all
possible.
You
can

perform
many
of
the
tasks
necessary
to
configure
and

maintain
the
ESX
host
using
the
vSphere
Client,
either

connected
directly
to
the
host
or,
better
yet,
going
through

vCenter.

Another
alternative
is
to
use
a
remote
scripting

interface,
such
as
the
VI
Perl
Toolkit
or
the
remote
command

line
interface
(Remote
CLI).
These
interfaces
are
built
on
the

same
API
that
vSphere
Client
and
vCenter
use,
so
any
script

using
them
automatically
enjoys
the
same
benefits
of

authentication,
authorization,
and
auditing.



Risk
or
Control
 M:H
and
M:AG


Recommendation
Level
 Enterprise


Condition
or
steps
 Security
policies
and
processes
should
be
written
to
require

the
use
of
the
remote
API
based
tools
wherever
possible.


Accounts
with
direct
service
console
access
should
be
limited

to
the
minimum
number
of
administrators
possible.

Some
advanced
tasks,
such
as
initial
configuration
for

password
policies,
cannot
be
performed
via
the
vSphere

Client.
For
these
tasks,
you
must
log
in
to
the
service
console.

Also,
if
you
lose
your
connection
to
the
host,
executing
certain

of
these
commands
through
the
command
line
interface
may

be
your
only
recourse—for
example,
if
the
network

connection
fails
and
you
are
therefore
unable
to
connect
using

vSphere
Client.


Console
Password
Policies




Configuration
Element
 Description


Code
Number
 COP01


Name
 Use
a
Directory
Service
for
Authentication


Description
 Advanced
configuration
and
troubleshooting
of
an
ESX
host

may
require
local
privileged
access
to
the
service
console.
For

these
tasks,
you
should
set
up
individual
host‐localized
user

accounts
and
groups
for
the
few
administrators
with
overall

responsibility
for
your
virtual
infrastructure.
Ideally,
these

accounts
should
correspond
to
real
individuals
and
not
be

 accounts
shared
by
multiple
people.
Although
you
can
create

on
the
service
console
of
each
host
local
accounts
that

correspond
to
each
global
account,
this
presents
the
problem

of
having
to
manage
user
names
and
passwords
in
multiple

places.
It
is
much
better
to
use
a
directory
service,
such
as
NIS

or
LDAP,
to
define
and
authenticate
users
on
the
service

console,
so
you
do
not
have
to
create
local
user
accounts.


Risk
or
Control
 Low

Access
Vector
is
the
management
network

(AV:A/AC:L:Au:S/C:?/I:?/A:?)


Recommendation
Level
 Enterprise


Parameters
or
objects
 In
the
default
installation,
ESX
3.5‐4.0
cannot
use
Active

configuration
 Directory
to
define
user
accounts.
However,
it
can
use
Active

Directory
to
authenticate
users.
In
other
words,
you
can



define
individual
user
accounts
on
the
host,
then
use
the
local

Active
Directory
domain
to
manage
the
passwords
and

account
status.
You
must
create
a
local
account
for
each
user

that
requires
local
access
on
the
service
console.
This
should

not
be
seen
as
a
burden;
in
general,
only
relatively
few
people

should
have
access
to
the
service
console,
so
it
is
better
that

the
default
is
for
no
one
to
have
access
unless
you
have

created
an
account
explicitly
for
that
user.

AD,
NIS,
Kerberos,
and
LDAP
are
all
supported
directory

services.


Authentication
on
the
service
console
is
controlled

by
the
command
esxcfg‐auth.
You
can
find
information
on
this

command
in
its
man
page.

Type
man
esxcfg‐auth
at
the

command
line
when
logged
in
to
the
service
console.
For

information
on
authentication
with
Active
Directory,
see
the

technical
note
at

http://www.vmware.com/vmtn/resources/582.




It
is
also
possible
to
use
third‐party
packages,
such
as

Winbind
or
Centrify,
to
provide
tighter
integration
with

Active
Directory.
Consult
the
documentation
for
those

solutions
for
guidance
on
how
to
deploy
them
securely.


Test
 The
esxcfg‐auth
–probe
command
will
list
all
of
the
files
that

are
generated
and
edited
by
the
esxcfg‐auth
command.


The

entries
in
those
files
will
be
different
depending
on
which

authentication
mechanism
you
choose.


Configuration
 Description

Element


Code
Number
 COP02


Name
 Establish
a
Password
Policy
for
Password
Complexity


Description
 These
controls
ensure
that
users
create
passwords
that
are
hard
for

password
generators
to
determine.
Instead
of
using
words,
a

common
technique
for
ensuring
password
complexity
is
to
use
a

memorable
phrase,
then
derive
a
password
from
it—for
example,
by

using
the
first
letter
of
each
word.

The
default
pam_cracklib.so
plug‐in
provides
sufficient
password

strength
enforcement
for
most
environments.
However,
if
the

pam_cracklib.so
plug‐in
is
not
stringent
enough
for
your
needs,
you

can
change
the
parameters
used
for
the
pam_cracklib.so
plug‐in
or

use
the
pam_passwdqc.so
plug‐in
instead.
You
change
the
plug‐in

using
the
esxcfg‐auth–usepamqc
command.




Risk
or
Control
 This
recommendation
addresses
the
risk
of
passwords
being

guessed
or
cracked.


Recommendation
 DMZ

Level


Parameters
or
 esxcfg­auth
­­usepamqc

objects

configuration
 This
command
requires
6
parameters
in
the
following
order:

‐ minimum
length
of
a
single
character
class
password

‐ minimum
length
of
a
password
that
has
characters
from
2

character
classes

‐ minimum
number
of
words
in
a
passphrase

‐ minimum
length
of
a
password
that
has
characters
from
3

character
classes

‐ minimum
length
of
a
password
that
has
characters
from
4

character
classes

‐ maximum
number
of
characters
reused
from
the
previous

password

If
you
pass
a
value
of
‐1
for
any
of
the
six
parameters
it
disables

that
option.

For
example
the
command
line:

esxcfg­auth
­­usepamqc=­1
­1
­1
12
8
­1


disables
the
first
three
parameters,
requires
a
12
character

password
using
characters
from
3
character
classes
or
an
8

character
password
that
uses
characters
from
4
character

classes
and
disables
the
final
parameter.

Test
 Check
the
following
line
in
the
/etc/pam.d/system­auth­generic

file:


“password
required
/lib/security/$ISA/pam_passwdqc.so”:

if
no
text
string
is
displayed,
the
complexity
is
not
set.


If
there
is
a

text
string
at
the
end
of
this
line,
ensure
that
it
meets
your
policy.


Configuration
Element
 Description


Code
Number
 COP03


Name
 Establish
a
Password
Policy
for
Password
History


Description
 Keeping
a
password
history
mitigates
the
risk
of
a
user
reusing

a
previously
used
password
too
often.




Risk
or
Control
 This
recommendation
addresses
the
risk
of
passwords
being

guessed
or
cracked.


Recommendation
Level
 DMZ


Parameters
or
objects
 If
it
does
not
already
exist
create
a
password
history
file:

configuration

touch
/etc/security/opasswd

chmod
600
/etc/security
/opasswd

Set
the
number
of
passwords
to
retain
for
matching:

Edit
the
/etc/pam.d/system‐auth
file
and
add
the
string

“remember=x”
where
x
is
the
number
of
passwords
to
retain
to

the
end
of
the
following
line:

“password
sufficient
/lib/security/$ISA/pam_unix.so”


Test
 Check
for
the
presence
of
the
string
“remember=”
and
ensure

that
the
value
is
in
compliance
with
your
internal
policy.


Configuration
Element
 Description


Code
Number
 COP04


Name
 Establish
a
Maximum
Password
Aging
Policy


Description
 These
controls
govern
how
long
a
user
password
can
be
active

before
the
user
is
required
to
change
it.


Risk
or
Control
 They
help
ensure
that
passwords
change
often
enough
that
if

an
attacker
obtains
a
password
through
sniffing
or
social

engineering,
the
attacker
cannot
continue
to
access
the
ESX

host
indefinitely.


Recommendation
Level
 DMZ


Parameters
or
objects
 To
set
the
maximum
password
age
use
the
following

configuration
 command:

esxcfg­auth
–passmaxdays=n


where
n
is
the
maximum
number
of
days
for
a
password
to

live.


Test
 Run
the
following
command
to
see
what
the
password
maximu

life
setting
is
set
to:


grep
–i
max_days
/etc/login.defs


This
number
should
be
compared
to
your
policy.


Configuration
Element
 Description


Code
Number
 COP05


Name
 Establish
a
Password
Policy
for
Minimum
Days
Before
a

Password
is
Changed


Description
 As
the
maximum
number
of
days
for
a
password
to
live
is

important,
there
also
needs
to
be
a
minimum
number
of
days

as
well.

This
will
mitigate
the
risk
of
a
user
changing
a

password
enough
times
to
be
able
to
reuse
their
favorite

password
that
is
outside
of
the
password
reuse
policy.


Risk
or
Control
 This
recommendation
addresses
the
risk
of
passwords
being

guessed
or
cracked.


Recommendation
Level
 DMZ


Parameters
or
objects
 esxcfg­auth
–passmindays=n

configuration


Test
 Run
the
following
command
to
see
what
the
password

minimum
life
setting
is
set
to:


“grep
–i
min_days
/etc/login.defs”



This
number
should
be
compared
to
your
policy.




Configuration
Element
 Description


Code
Number
 COP06


Name
 Ensure
that
vpxuser
auto‐password
change
in
vCenter
meets

policy


Description
 By
default
the
vpxuser
password
will
be
automatically
changed

by
vCenter
every
X
number
of
days.

Ensure
that
this
setting

meets
your
policies
and
if
not,
configure
to
meet
password

aging
policies.

Note
that
it
is
very
important
that
the
password

aging
policy
should
not
be
shorter
than
the
interval
that
is
set

to
automatically
change
the
vpxuser
password
or
vCenter

could
get
locked
out
of
an
ESX
Host.


Risk
or
Control
 If
an
attacker
obtains
the
vpxuser
password
through
brute‐
force,
it
can
only
be
used
for
a
limited
amount
of
time.


Recommendation
Level
 DMZ


Parameters
or
objects
 vCenter
Server
Advanced
Settings:

configuration
 vCenterVirtualCenter.VimPasswordExpirationInDays





Test
 Ensure
that

vCenterVirtualCenter.VimPasswordExpirationInDays
value
is

set
lower
than
the
password
aging
policy
on
the
COS.









Console
Logging

Proper
and
thorough
logging
allows
you
to
keep
track
of
any
unusual
activity
that

might
be
a
precursor
to
an
attack
and
also
allows
you
to
do
a
postmortem
on
any

compromised
systems
and
learn
how
to
prevent
attacks
from
happening
in
the

future.


The
syslog
daemon
performs
the
system
logging
in
ESX.
You
can
access
the
log
files

in
the
service
console
by
going
to
the
/var/log/
directory.
Several
types
of
log
files

generated
by
ESX
are
shown
in
the
following
table.


Component
 Location
 Purpose


Vmkernel
 /var/log/vmkernel
 Records
activities
related
to
the

virtual
machines
and
ESX



VMkernel
 /var/log/vmkwarning
 Records
activities
with
the


warnings
 virtual
machines


VMkernel
 /var/log/vmksummary
 Used
to
determine
uptime
and


summary
 availability
statistics
for
ESX;

human‐readable
summary
found

in
/var/log/vmksummary.txt


ESX
host
agent
 /var/log/vmware/hostd.log
 Contains
information
on
the


log
 agent
that
manages
and

configures
the
ESX
host
and
its

virtual
machines


Virtual
 The
same
directory
as
the
 Contain
information
when
a


machines
 affected
virtual
machine’s
 virtual
machine
crashes
or
ends

configuration
files;
named
 abnormally

vmware.log
and
vmware‐*.log


vCenter
agent
 /var/log/vmware/vpx
 Contains
information
on
the


agent
that
communicates
with

vCenter


Web
access
 Files
in
 Records
information
on
Web‐

/var/log/vmware/webAccess
 based
access
to
ESX



Service
 /var/log/messages
 Contain
all
general
log
messages


console
 used
to
troubleshoot
virtual

machines
or
ESX



Authentication
 /var/log/secure
 Contains
records
of
connections


log
 that
require
authentication,
such

as
VMware
daemons
and
actions

initiated
by
the
xinetd
daemon.




The
log
files
provide
an
important
tool
for
diagnosing
security
breaches
as
well
as

other
system
issues.
They
also
provide
key
sources
of
audit
information.
In
addition

to
storing
log
information
in
files
on
the
local
file
system,
you
can
send
this
log

information
to
a
remote
system.
The
syslog
program
is
typically
used
for
computer

system
management
and
security
auditing,
and
it
can
serve
these
purposes
well
for

ESX
hosts.
You
can
select
individual
service
console
components
for
which
you
want

the
logs
sent
to
a
remote
system.



Configuration
Element
 Description


COL01

Code
Number

Name
 Configure
syslog
logging


Description
 Remote
logging
to
a
central
host
provides
a
way
to
greatly

increase
administration
capabilities.
By
gathering
log
files

onto
a
central
host,
you
can
easily
monitor
all
hosts
with
a

single
tool
as
well
as
do
aggregate
analysis
and
searching
to

look
for
such
things
as
coordinated
attacks
on
multiple
hosts.

Risk
or
Control
 Logging
to
a
secure,
centralized
log
server
can
help
prevent

log
tampering
and
provides
a
long‐term
audit
record.

Recommendation
Level
 Enterprise


Parameters
or
objects

Syslog
behavior
is
controlled
by
the
configuration
file

configuration

/etc/syslog.conf.
For
logs
you
want
to
send
to
a
remote
log

host,
add
a
line
with
@<loghost.company.com>
after
the

message
type,
where
<loghost.company.com>
is
the
name
of
a

host
configured
to
record
remote
log
files.
Make
sure
that
this

host
name
can
be
properly
resolved,
putting
an
entry
in
the

name
service
maps
if
needed.

Example:

local6.warning
@<loghost.company.com>

After
modifying
the
file,
tell
the
syslog
daemon
to
reread
it
by

issuing
the
following
command:

kill
‐SIGHUP
`cat
/var/run/syslogd.pid`

At
a
minimum
the
following
files
should
be
logged
to
a
remote

syslog
server:



/var/log/vmkernel
‐
Recursive

/var/log/secure
‐
Recursive

/var/log/messages

/var/log/vmware/*log.

/var/log/vmware/aam/*log

/var/log/vmware/aam/*err

/var/log/vmware/webAccess/.*log

/var/log/vmware/vpx/vpxa.log

/vmfs/volumes/<vmpath>/vmware.log
–
for
all
VM’s
where

vmpath
is
the
path
to
the
VM.

Test

To
check
that
remote
logging
is
configured
:

cat /etc/syslog.conf | grep @

To
check
that
remote
logging
traffic
is
permitted
outbound

from
the
host
:

esxcfg-firewall –q | grep 514

To
check
that
syslog
service
is
configured
to
run:

chkconfig –list | grep syslog





Configuration
Element
 Description


COL02

Code
Number

Name
 Configure
NTP
time
synchronization


Description
 By
ensuring
that
all
systems
use
the
same
relative
time
source

(including
the
relevant
localization
offset),
and
that
the

relative
time
source
can
be
correlated
to
an
agreed‐upon
time

standard
(such
as
Coordinated
Universal
Time—UTC),
you

can
make
it
simpler
to
track
and
correlate
an
intruder’s

actions
when
reviewing
the
relevant
log
files.


Risk
or
Control
 Incorrect
time
settings
could
make
it
difficult
to
inspect
and

correlate
log
files
to
detect
attacks,
and
would
make
auditing

inaccurate.

Recommendation
Level
 Enterprise


Parameters
or
objects
 NTP
can
be
configured
on
an
ESX
host
using
the
vSphere

configuration
 Client,
or
using
a
remote
command
line
such
as
vCLI
or

PowerCLI.



Test
 • Query
the
NTP
configuration
to
make
sure
that
a
valid

time
source
has
been
configured,


• Make
sure
that
the
NTP
service
is
running
on
the
host


Console
Hardening




Configuration
 Description

Element

Code
Number
 COH01


Name
 Partition
the
disk
to
prevent
the
root
file
system
from
filling
up


Description
 If
the
root
filesystem
fills
up,
it
can
seriously
degrade
the

performance
of
ESX
management
capabilities
or
even
make
them

unresponsive.

When
you
install
ESX
4.0,
the
default
partitioning
creates
only
3

partitions.
To
protect
against
the
root
file
system
filling
up,
you
can

create
additional
separate
partitions
for
the
directories
/home,
/tmp,

and
/var/log.
These
are
all
directories
that
have
the
potential
to
fill

up,
and
if
they
are
not
isolated
from
the
root
partition,
you
could

experience
a
denial
of
service
if
the
root
partition
is
full
and
unable
to

accept
any
more
writes.
The
Chapter
“ESX
Partitioning”
in
the
ESX

and
vCenter
Server
Installation
Guide
covers
disk
partitions
in
more

detail.

http://pubs.vmware.com/vsp40u1/install/c_esx_partitioning.html#
1_9_18_1


Risk
or
Control
 Prevents
a
denial‐of‐service
against
the
management
of
that
host


Recommendation
 Enterprise

Level


Parameters
or
 /etc/fstab

objects

configuration


Test
 Run
the
“df”
command
and
ensure
that
the
directories
for
/home,

/tmp,
and
/var/log
are
mounted
on
their
own
partitions.


Parameter
Element
 Description


Code
Number
 COH02


Name
 Disable
Automatic
Mounting
of
USB
Devices


Description
 External
USB
drives
can
be
connected
to
the
ESX
host
and
be

loaded
automatically
on
the
service
console.
The
USB
drive

must
be
mounted
before
you
can
use
it,
but
drivers
are
loaded

to
recognize
the
device.



Threat
 Attackers
may
be
able
to
run
malicious
code
on
the
ESX
host

and
go
undetected
because
the
USB
drive
is
external.

Recommendation
Level
 SSLF


Parameter
setting
 By
default,
automatic
USB
drive
mounting
is
enabled,
but
it
is

recommended
that
you
disable
this
feature
by
editing
the

service
console
file
/etc/modules.conf
and
commenting
out

the
line
containing
alias
usb‐controller
by
placing
a
pound

sign
(#)
at
the
beginning.


Effect
on
functionality
 There
is
a
risk
that
a
USB‐based
keyboard
and
mouse
will

cease
to
function
properly
after
implementing
this
step.
It
is

recommended
that
you
verify
that
mouse
and
keyboard

continue
to
operate
normally
and
not
implement
this
step
if

they
do
not.


Positive
evidence
 If
the
line
containing
alias
usb‐controler
has
a
pound
sign
(#)

at
the
beginning
of
the
line,
this
is
a
positive
test.


Negative
evidence
 If
the
line
containing
alias
usb‐controler
does
not
have
a

pound
sign
(#)
at
the
beginning
of
the
line,
this
is
a
negative

test.




The
service
console
has
a
number
of
files
that
specify
its
configurations:



 /etc/profile


 /etc/ssh/sshd_config


 /etc/pam.d/system‐auth


 /etc/grub.conf


 /etc/krb.conf


 /etc/krb5.conf


 /etc/krb.realms


 /etc/login.defs


 /etc/openldap/ldap.conf


 /etc/nscd.conf


 /etc/ntp



 /etc/ntp.conf


 /etc/passwd


 /etc/group


 /etc/nsswitch.conf


 /etc/resolv.conf


 /etc/sudoers


 /etc/shadow

In
addition,
ESX
configuration
files
located
in
the
/etc/vmware
directory
store
all

the
VMkernel
information.
Not
all
of
these
files
are
actually
used
by
your
particular

ESX
deployment,
but
all
the
files
are
listed
for
completeness.


Operational
Element
 Description


Code
Number
 COH03


Name
 Establish
and
Maintain
File
System
Integrity


Description
 It
is
critical
to
monitor
the
integrity
of
certain
critical
system

files
within
the
ESX
Service
Console.
In
addition,
the

permissions
of
numerous
critical
files
should
be
configured
to

prevent
unnecessary
access
from
occurring.


Risk
or
Control
 


Recommendation
Level
 DMZ


Condition
or
steps
 Configuration
files
should
be
monitored
for
integrity
and

unauthorized
tampering,
using
a
commercial
tool
such
as

Tripwire,
or
by
using
a
checksum
tool
such
as
sha1sum,
which

is
included
in
the
service
console.
These
files
should
also
be

backed
up
regularly,
either
using
backup
agents
or
by
doing

backups
based
on
file
copying.



Operational
 Description

Element


Code
Number
 COH04


Name
 Ensure
permissions
of
important
files
and
utility
commands
have
not

been
changed
from
default.


Description
 Various
files
and
utilities
are
installed
with
particular
file
permissions

to
enable
certain
functionality
without
requiring
unnecessary

privilege
levels
for
the
user
accessing
them.


Risk
or
Control
 Changing
permissions
from
default
on
these
important
files
can
have

an
affect
on
the
functionality
of
the
ESX
host
and
could
potentially

cause
these
commands
to
not
run
properly
and
as
such
cause
a
denial

of
service.

Recommendatio DMZ

n
Level


Condition
or
 The
/usr/sbin/esxcfg‐*
commands,
which
are
all
installed
by
default

steps
 with
permissions
555.

The
log
files
discussed
in
the
previous
section,
which
all
have

permissions
600,
except
for
the
directory

/var/log/vmware/webAccess,
which
has
permissions
755,
and
the

virtual
machine
log
files,
which
have
permissions
644.

Certain
system
commands
that
have
the
SUID
bit.
These
commands

are
listed
here:

http://pubs.vmware.com/vsp40u1/server_config/r_default_setuid_ap
plications.html

For
all
of
these
files,
the
user
and
group
owner
should
be
root.







Console
Access

Parameter
 Description

Element


Code
Number
 COA01


Name
 Prevent
tampering
at
boot
time


Description
 A
grub
password
can
be
used
to
prevent
users
from
booting
into

single
user
mode
or
passing
options
to
the
kernel
during
boot.



Threat
 By
passing
in
boot
parameters,
it
might
be
possible
to
influence
the

host
so
that
it
behaves
improperly,
perhaps
in
a
manner
that
is
hard

to
detect.


Recommendation
 DMZ

Level


Parameter
setting
 During
the
ESX
installation,
the
Advanced
option
allows
you
to
set
a

grub
password.

This
can
also
be
set
by
directly
editing

/boot/grub.conf..

See
the
Chapter
“Installing
VMware
ESX”
in
the

ESX
and
vCenter
Server
Installation
Guide
for
more
details.


Effect
on
 Unless
the
password
is
entered,
the
server
boots
only
the
kernel
with

functionality
 the
default
options.

Positive
evidence
 During
boot,
it
should
not
be
possible
to
change
boot
parameters

without
entering
the
correct
password


Negative
evidence
 There
is
no
password
configured
in
/boot/grub.conf


Parameter
Element
 Description


Code
Number
 COA02


Name
 Require
Authentication
for
Single
User
Mode


Description
 Anyone
with
physical
access
can
access
the
service
console
as

root
if
a
password
is
not
set
for
single
user
mode
access.


Threat
 When
this
recommendation
is
followed,
then
if
an
attacker

gains
access
to
the
console,
they
can
only
log
in
as
an
ordinary

user
and
won’t
necessarily
be
able
to
escalate
privilege
level

without
additional
effort.


Recommendation
Level
 SSLF


Parameter
setting
 Add
the
line


~~:S:wait:/sbin/sulogin

to
/etc/inittab


Effect
on
functionality
 If
the
root
password
is
lost
then
there
will
be
no
way
to
access

the
system.


Positive
evidence
 Check
for
evidence
of

the
line


~~:S:wait:/sbin/sulogin

to
/etc/inittab

If
it
exists
this
is
a
positive
test.


Negative
evidence
 Check
for
evidence
of

the
line


~~:S:wait:/sbin/sulogin

to
/etc/inittab

If
it
does
no
exist
this
is
a
negative
test.


Parameter
Element
 Description


Code
Number
 COA03

Name
 Ensure
root
access
via
SSH
is
disabled


Description
 Because
the
root
user
of
the
service
console
has
almost

unlimited
capabilities,
securing
this
account
is
the
most

important
step
you
can
take
to
secure
the
ESX
host.
By
default,

all
insecure
protocols,
such
as
FTP,
Telnet,
and
HTTP,
are

disabled.
Remote
access
via
SSH
is
enabled,
but
not
for
the
root

account.
You
can
copy
files
remotely
to
and
from
the
service

console
using
an
scp
(secure
cp)
client,
such
as
WinSCP.


Threat
 Enabling
remote
root
access
over
SSH
or
any
other
protocol
is

not
recommended,
because
it
opens
the
system
to
network‐
based
attack
should
someone
obtain
the
root
password.



Recommendation
Level
 Enterprise


Parameter
setting
 The
line
“PermitRootLogin”
in
the
/etc/sshd_conf
should
be
set

to
“no”


Effect
on
functionality
 The
root
user
will
not
be
able
to
login
via
SSH.


Positive
evidence
 If
the
line
“PermitRootLogin
no”
in
the
/etc/sshd_conf
exists

and
it
does
not
start
with
a
pound
sign
(#),
this
is
a
positive

finding.


Negative
evidence
 If
the
line
“PermitRootLogin
yes”
in
the
/etc/sshd_conf
exists,

or
is
prefaced
by
a
pound
sign
(#),
or
the
the

“PermitRootLogin”
parameter
does
not
exist
in
the
file,
this
is
a

negative
finding
.


Parameter
Element
 Description


Code
Number
 COA04


Name
 Disallow
Direct
root
Login


Description
 You
can
disallow
root
access
even
on
the
console
of
the
ESX

host—that
is,
when
you
log
in
using
a
screen
and
keyboard

attached
to
the
server
itself,
or
to
a
remote
session
attached
to

the
server’s
console.
This
approach
forces
anyone
who
wants

to
access
the
system
to
first
log
in
using
a
regular
user
account,

then
use
sudo
or
su
to
perform
tasks.


The
net
effect
is
that
administrators
can
continue
to
access
the

system,
but
they
never
have
to
log
in
as
root.
Instead,
they
use

sudo
to
perform
particular
tasks
or
su
to
perform
arbitrary

commands.

Threat
 When
this
recommendation
is
followed,
then
if
an
attacker

gains
access
to
the
console,
they
can
only
log
in
as
an
ordinary

user
and
won’t
necessarily
be
able
to
escalate
privilege
level

without
additional
effort.


Recommendation
Level
 SSLF


Parameter
setting
 To
prevent
direct
root
login
on
the
console,
modify
the
file

/etc/securetty
to
be
empty.
While
logged
in
as
root,
enter
the

following
command:

cat
/dev/null
>
/etc/securetty

You
should
first
create
a
nonprivileged
account
on
the
host
to

enable
logins,
otherwise
you
could
find
yourself
locked
out
of

the
host.
This
nonprivileged
account
should
be
a
local

account—that
is,
one
that
does
not
require
remote

authentication—so
that
if
the
network
connection
to
the

directory
service
is
lost,
access
to
the
host
is
still
possible.
You

can
assure
this
access
by
defining
a
local
password
for
this

account,
using
the
passwd
command.


Effect
on
functionality
 After
you
do
this,
only
nonprivileged
accounts
are
allowed
to

log
in
at
the
console.


Root
login
at
the
console
will
no
longer

be
possible.


Positive
evidence
 /etc/securetty
is
empty.


Negative
evidence
 /etc/securetty
is
not
empty.


Parameter
Element
 Description


Code
Number
 COA05


Name
 Limit
access
to
the
su
command.


Description
 Because
su
is
such
a
powerful
command,
you
should
limit

access
to
it.
By
default,
only
users
that
are
members
of
the

wheel
group
in
the
service
console
have
permission
to
run
su.

If
a
user
attempts
to
run
su
‐
to
gain
root
privileges
and
that

user
is
not
a
member
of
the
wheel
group,
the
su
‐
attempt
fails

and
the
event
is
logged.


Threat
 


Recommendation
Level
 Enterprise


Parameter
setting
 Besides
controlling
who
has
access
to
the
su
command,

 through
the
pluggable
authentication
module
(PAM)

infrastructure,
you
can
specify
what
type
of
authentication
is

required
to
successfully
execute
the
command.
In
the
case
of

the
su
command,
the
relevant
PAM
configuration
file
is

/etc/pam.d/su.
To
allow
only
members
of
the
wheel
group
to

execute
the
su
command,
and
then
only
after
authenticating

with
a
password,
find
the
line
beginning
with
auth
required

and
remove
the
leading
pound
sign
(#)
so
it
reads:

auth
required
/lib/security/$ISA/pam_wheel.so
use_uid


Effect
on
functionality
 Prevents
users
that
are
not
in
the
wheel
group
from
running

the
su
command.


Positive
evidence
 auth
required
/lib/security/$ISA/pam_wheel.so
use_uid
does

not
have
leading
pound
sign
(#).


Negative
evidence
 auth
required
/lib/security/$ISA/pam_wheel.so
use_uid
has

leading
pound
sign
(#).




The
sudo
utility
should
be
used
to
control
what
privileged
commands
users
can
run

while
logged
in
to
the
service
console.
Among
the
commands
you
should
regulate

are
all
of
the
esxcfg‐*
commands
as
well
as
those
that
configure
networking
and

other
hardware
on
the
ESX
host.
You
should
decide
what
set
of
commands
should
be

available
to
more
junior
administrators
and
what
commands
you
should
allow
only

senior
administrators
to
execute.
You
can
also
use
sudo
to
restrict
access
to
the
su

command.


Use
the
following
tips
to
help
you
configure
sudo:

‐ Configure
local
and
remote
sudo
logging
(see
Maintain
Proper
Logging

“Maintain
Proper
Logging”
on
page
12).

‐ Create
a
special
group,
such
as
vi_admins,
and
allow
only
members
of
that

group
to
use
sudo.

‐ Use
sudo
aliases
to
determine
the
authorization
scheme,
then
add
and

remove
users
in
the
alias
definitions
instead
of
in
the
commands

specification.

‐ Be
careful
to
permit
only
the
minimum
necessary
operations
to
each
user

and
alias.
Permit
very
few
users
to
run
the
su
command,
because
su
opens
a

shell
that
has
full
root
privileges
but
is
not
auditable.

‐ If
you
have
configured
authentication
using
a
directory
service,
sudo
uses
it

by
default
for
its
own
authentication.
This
behavior
is
controlled
by
the

/etc/pam.d/sudo
file,
on
the
line
for
auth.
The
default
setting—
service=system‐auth—tells
sudo
to
use
whatever
authentication
scheme
has

been
set
globally
using
the
esxcfg‐auth
command.

‐ Require
users
to
enter
their
own
passwords
when
performing
operations.

This
is
the
default
setting.
Do
not
require
the
root
password,
because
this

 presents
a
security
risk,
and
do
not
disable
password
checking.
In
sudo
the

authentication
persists
for
a
brief
period
of
time
before
sudo
asks
for
a

password
again.

For
further
information
and
guidelines
for
using
sudo,
see

http://www.gratisoft.us/sudo/.




Configuration
Element
 Description


Code
Number
 COA06


Name
 Configure
and
use
sudo
to
control
administrative
access


Description
 The
sudo
utility
should
be
used
to
control
what
privileged

commands
users
can
run
while
logged
in
to
the
service

console.



Risk
or
Control
 


Recommendation
Level
 Enterprise


Parameters
or
objects
 Parameters
to
be
configured
are
in
the
/etc/sudoers
file.




configuration

Among
the
commands
you
should
regulate
are
all
of
the
esxcfg‐
*
commands
as
well
as
those
that
configure
networking
and

other
hardware
on
the
ESX
host.
You
should
decide
what
set
of

commands
should
be
available
to
more
junior
administrators

and
what
commands
you
should
allow
only
senior

administrators
to
execute.
You
can
also
use
sudo
to
restrict

access
to
the
su
command.

Because
each
situation
will
be

different,
each
configuration
will
be
different,
so
no
specific

guidance
can
be
given
here.


Test
 Check
the
configuration
in
the
/etc/sudoers
file
and
ensure

that
it
meets
your
policy.