Securing Your ESX Service console

Posted: June 9, 2009 in Tips and Tricks, VMware

Ive been doing a fair bit of virtualization security lately and I thought id share a few tid bits on what Ive done and why. If y0u find this useful then check back every couple of days as ill be adding additional steps and verifying if these apply to VI3, Vsphere or both.

Most of you who are familiar with ESX will know  the default “Out Of The Box” behaviour restricts the user root from logging in directly via SSH which generally means either root user must authenticate as a standard user and then SU to root or log in directly from the console.

So now that weve established how ROOT user can and can not be used to login into the service console, lets look at a couple more options to tighten things even further.

Deny SSH access to all but specific ip addresses

Ive configured /etc/hosts.allow with 3 specific ip addresses that can SSH to the esx hosts in our cluster and configured /etc/hosts.deny with sshd:all which means all other IP addresses not configured in the hosts.allow files get the hard word and fail with an error “session terminated unexpectedly”

Only users in the WHEEL group can SU to Root

As mentioned above already if the sshd_config file is configured with Permit Root Login = no option, then ROOT is not able to login to the service console remotely e.g. via Putty. We can also take additional steps and limit which standard users can SU to root by changing the /etc/pam.d/su file and then adding only specific users to the wheel group. Here’s what you’ll need to do;

vi /etc/pam.d/su

Then un comment the following line

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

Once youve done that, we can now go and look at which users are part of the WHEEL group.

cat /etc/group |grep wheel

which should return the following “wheel:x:10:root

Now if your standard user is called testuser, just add a comma and add testuser so it looks like this.

wheel:x:10:root,testuser

Now you can add users to the service console, but only user “testuser” will be able to SU to root

Password Protect GRUB

After reading this in one of the hardening guides, I decided that I wanted to protect the ESX boot loader (GRUB).

Just quickly for those who dont know, A quick extract from the GRUB website explaining what it is.

GRUB is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software. The kernel, in turn, initializes the rest of the operating system

Hardening the Linux boot loader is not new to me, its something I had done before but I would like to stick my hand up here and admit previously I had used a password in plain txt, this is very very LAZY. One of the golden rules of security is never leave passwords hanging around in plain text, even though the password was specific to grub alone (not used for ROOT or standard user) and I had restricted access to the grub configuration file using chmod 600 /boot/grub/grub.conf I still don’t consider this to be good enough, shame on me.

So years later after learning a few tricks, when I secure ESX systems I use md5crypt to generate a md5 hashed password which I then use in the configuration file. below Ill show you what I did to achieve this.

First make a backup of grub.conf file (Just in case)

[root@esxvsphere1 ~]# cp /boot/grub/grub.conf /home

Next lets generate that md5 hash using my chosen password of “testing”

[root@esxvsphere1 ~]# grub

GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub> md5crypt

Password: *******
Encrypted: $1$BPuA5/$zrkdzGA88uApbEL126tlE.

grub>

Exit, and now its time to take the hash and place it in our grub.conf file

[root@esxvsphere1 ~]# vi /boot/grub/grub.conf

Then add the following syntax password –md5 <md5hash>  right after the last # in the grub description section.

default 0
###################### grub.conf #####################
# this file was generated by bootloader.py
#
# Any entries in this file marked with the comment
#   #vmware:autogenerated esx
# Should not be edited by hand.  They are likely to
# be clobbered on or before the next reboot.
#
password –md5 $1$BPuA5/$zrkdzGA88uApbEL126tlE.

That’s it, all done. So now just one last step. As mentioned above I like to restrict access to the grub.conf file using chmod 600 /boot/grub/grub.conf

Now Im going to post some screen shots showing how this has changed the behaviour of GRUB, but in order to do that, ill need to start with how it looks by default

Origional Boot Loader : Note the naughty “E” for edit which gives anyone at the console the ability to edit the parameters which are passed to the kernel.

grub_orig

 

Password protected Boot Loader : Now notice “E” has been replaced with the option “P” to enter password which then allows access to the additional features

grub_password

 

Now lets hit the “P” and make sure it requests for password

grub_password2

That’s it, all done.

Advertisements
Comments
  1. […] he’s been doing a lot of work on securing ESX, integrating ESX into Active Directory, and experimenting with vSphere v4. If you’re […]

  2. […] Securing your ESX Service Console […]

  3. […] the bootloader (which is then requested if you want to change kernel parameters at boot time. See this article on securing ESX for […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s