VMware

How Meltdown and Spectre Impact VMware ESXi Guests

So the cat’s out of the bag and OS vendors have begun issuing patches to plug the latest in Security Vulnerabilities and Exposures made known to the public.

What is Meltdown and Spectre:

Meltdown and Spectre are exploits, operating against computer architecture that’s been designed into Intel chips. They are capable of accessing the protected areas of memory to potentially decode and read information which should normally be protected.  Information which may be considered sensitive data; such as passwords.

The vulnerability may also allow for the potential read of protected memory locations used by the device and applications (including browsers) that store information in the kernel memory, including potentially sensitive data.

 

 

But, I thought OS vendors are and have released patches for this?

For these patches to be fully functional in a guest OS additional ESXi and vCenter Server updates will be required. These updates are being given the highest priority by VMware.  Remember sure the virtual CPU will be protected, however it sits onto of a hypervisor which is its own OS.

What to do?

In the recent VMware Security Advisory, the specified patches should be applied for remediation. Its strongly suggested that those using ESXi update as soon as possible.

VMware Patch Numbers for ESXi Versions:

ESXi 6.5 – ESXi650-201712101-SG
ESXi 6.0 – ESXi600-201711101-SG
ESXi 5.5 – ESXi550-201709101-SG

This 5.5 patch only addresses CVE-2017-5715, not CVE-2017-5753

 

Info Links:

https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

 

PSA: Don’t delay or skip patching your VMs just because you or your provider already patched the hypervisor. Otherwise you are still vulnerable to Meltdown & Spectre. If you cycle out your cloud instances periodically, make sure your machine images are patched.

Backup of VMware vCenter Server Appliance 6.5

It’s always a good idea to backup your work to provide you a way to recovery if things go wrong with your environment. Running an home lab I have cause my own share of issues many of times which had forced me to reinstall and configure my vCenter environment. Moving forward I will be taking advantage of the backup features included with the vCSA.

Using The vCenter Server Appliance Management Interface (VAMI) an administrator uses the HTML5 web interface to perform administrative tasks to the appliance configuration. These tasks included changing the host name, the network configuration, NTP configuration, applying patches / updates and performing backups.

Once logged into the VAMI, under the Summary tab, Click on “Backup” to start the backup of the vCenter Sever appliance.

There are options allowing you to perform a backup using different protocols and location settings. These include the following: FTP, FTPS, HTTP, HTTPS, SCP.

Next specify the protocol of choice and then the credentials for accessing the remote location where the backup will be stored. As an added option, you can encrypt the backup data before transferring.

Click Next

 

A minimum set of data needed to restore the appliance will be backed up by default. This includes the data such as OS, VC services, vCenter Server database, inventory and configuration. Historical data such as tasks, events, and alarms.

Click Next

You get a final review before you click Finish to start the backup process

Depending on the data size of the vCenter server appliance, backups will take a few minutes to complete.

When completed, Click on OK

 

Tech Short: Modify vCenter Single Sign-On Password Policy

Warning:  I do not advocate that anyone to make modifications which extend outside of their organizations security policies. Doing so may put account security as risk.

By default, passwords associated with vSphere Single Sign-On expire every 90 days. As a user approaches this expiry point they will be reminded that their password is about to expire.

In my lab I wanted to avoid the need to change my password so frequently so I decided to extend the number of days required between password changes.

The steps below can be followed:

  1. Log in to the vSphere Web Client as a user with vCenter Single Sign-On administrator privileges
  2. Browse to Administration > Single Sign-On > Configuration
  3. Click the Policies tab and select Password Policies
  4. Click Edit
  5. Modify the “Maximum Lifetime”
  6. Click OK

Under the password policies you may take note of various options which can be modified based on your criteria or organization password policy.

Here are the password policy options:

 

Maximum lifetime:

Maximum number of days that a password can exist before the user must change it.

Restrict reuse:

Number of the user’s previous passwords that cannot be selected. For example, if a user cannot reuse any of the last six passwords, type 6.

Maximum length:

Maximum number of characters that are allowed in the password.

Minimum length:

Minimum number of characters required in the password. The minimum length must be no less than the combined minimum of alphabetic, numeric, and special character requirements.

Character requirements:

Minimum number of different character types that are required in the password. You can specify the number of each type of character, as follows:

  • Special: & # %
  • Alphabetic: A b c D
  • Uppercase: A B C
  • Lowercase: a b c
  • Numeric: 1 2 3

The minimum number of alphabetic characters must be no less than the combined uppercase and lowercase requirements.

In vSphere 6.0 and later, non-ASCII characters are supported in passwords. In earlier versions of vCenter Single Sign-On, limitations on supported characters exist.

Identical adjacent characters:

Maximum number of identical adjacent characters that are allowed in the password. The number must be greater than 0.

For example, if you enter 1, the following password is not allowed: p@$$word

 

Ref: ESXi and vCenter Server 5.1 Documentation > vSphere Security > vCenter Server Authentication and User Management > Configuring vCenter Single Sign On

Enabling Hyper-V for use on Windows 10

You all know when it comes to virtualization I am VMware all the way.  However, it has recently to my attention that the use of VMware Player on a company issued computer may be a violation of the EULA as this type of activity would be considered commercial use of the software.

So the option is to purchase a license or use the native Virtualization built into my Windows 10.

Ref: Workstation Player FAQs

  • Here are some capabilities of Windows 10 virtualization:
  • Hot add & remove for memory and network adapters: Windows and Linux Guests
  • Windows PowerShell Direct: Issue commands inside a virtual machine from the host
  • Linux secure boot:  – Ubuntu and SUSE Linux Enterprise Server can use secure boot options
  • Hyper-V Manager: Hyper-V manager can manage computers running Hyper-V on Windows Server 2012, Windows Server 2012 R2 and Windows 8.1

 

Prerequisites

The following prerequisites are required to successfully run Hyper-V on Windows 10:

Windows 10 Pro or Enterprise 64 bit Operating System
64 bit processor with Second Level Address Translation (SLAT)
4GB system RAM at minimum
BIOS-level Hardware Virtualization support

 

Windows 10 Hyper-V Install Steps:

  1. Enable virtualization support in bios
  2. Access the Control Panel
  3. From Control Panel select Programs
  4. In Windows Features select Hyper-V
  5. After installation of Hyper-V has completed, restart computer

The installation of Hyper-V is now complete.  The next step is to setup the Virtual Switch Manager for networking and configure your first virtual machine. This is can be done by:

  1. Clicking the search icon on the task-bar and then typing Hyper-V Manager .
  2. Select Virtual Switch Manager in the Actions pane
  3. Choose External and then click on the Create Virtual Switch button
  4. Give the new Virtual Switch a name, and ensure the active NIC is selected

 

Re: Why you should upgrade to vSphere 6.5 / ESXi 6.5

Recently I went to extend a volume on one of my guest systems and received an error requiring me to power off the system before extending the disk.

ErrorHot-extend was invoked with size (5368709120 sectors) >= 2TB. Hot-extend beyond or equal to 2TB is not supported. The disk extend operation failed: msg.disklib.INVAL

Good News – With vSphere 6.5 this is no longer a limitation.

Just one more reason why you should think about upgrading your VMware environment to the latest.