The main concern I have for anyone searching for practical information about securing their virtual infrastructure is the amount of FUD that is out there. You only have to do a search on google and you know what I am talking about. Sure the vendors themselves have very useful security hardening guides but they are vendor centric and often don’t give you a sense of relevance to your organization or needs. VMware’s latest vSphere 4.0 Security hardening guide is somewhat better than its predecessor as it does try to give the reader a level of relevance in terms of controls as they might pertain to specific environments. Eg. DMZ.

With this in mind I set out to write a short document that would hopefully impart to the reader practical advice on how to secure their virtual environment. You can check out the document at the following link (A Practical Guide to Securing Your Virtual Environment), if you like it or even if you don’t please let me know by leaving your comments below…(spiv)

Virtualization Myths

Thought I would share this presentation with everyone from a recent seminar that I gave at the back end of last year entitled “Security in a Virtual World”.

You can check out the presentation at this link: http://bit.ly/8Vh4MM

This appeared on a VMware KB article back in August but some of you may have not seen it. Basically if you use a port scanner like NMAP and scan an ESX host in particular on port 8000, subsequent VMotion events will fail.

The only way to get VMotion to work again is to disable and then re-enable VMotion. It’s interesting that this service is obviously not robust enough to cope with a simple port scan and also highlights the fact that you should be isolating your vmotion network from general network traffic.

The original VMware article can be viewed here, KB1010672

Just returned from Vegas where I caught the end of this interesting talk about VMescape.  The bug was present in the virtualized video drivers and was patched back in March 09.  The following presentation covers the bug and exploit in detail and is very interesting….

Hacking 3D

VMinformer Security Hardening and Remediation Guide

Hot of the press the VMinformer security and remediation guide for your virtual infrastructure.  Includes information on how to secure your VC, ESX Host and VM Guests.  You can download the guide here

Lets start with the obvious ports…

Most of you probably know that your VMware ESX host and Virtual Center allows connectivity over port 443 to a SOAP WSDL interface. This communication channel allows you to query various objects within your virtual infrastructure for the purpose of creating your own apps.  You can also connect to this port using a standard web browser to manage your virtual environment in a similar way to how you would with the standard VI client.

What probably isn’t known to those of you have never tried this before or maybe who are not developers is how powerful and how dangerous this communication channel could potentially be if accessed by a malicious hacker.

Access

So you should make sure that this port is not accessible from outside your organisation and ensure that proper network access controls are in place to allow only those that should be accessing this interface to do so.

When you initially connect to the interface it will prompt you for a username/password combination, however you could attempt to brute force this.  Once in you then have access to the api and all the methods that it allows.

The below screen shot shows you what you could potentially have access to once authenticated….

The actual Mob / SDK….

The above screen shot shows a detailed breakdown of  the Firewall rule set, there are many more things you can do with this interface which we shall explore next time….

Saw this interesting article on “Real World Security – Part1″ on virtualization security, go check it out at virtualization.info

Where is my data….

So you have decided to take security seriously and have looked at VMware’s best practice guidelines and maybe have started to implement some of the recommendations. You may be also looking at what you can do at the network layer or defining user access roles more clearly.

The underlying data…

But what about the underlying data?  The data that is core to your business, the data that drives all your financial systems, the data that is your life blood.

You may have 20 or so machines running on a single ESX host and each one of those will have virtual machine files and other data that are required to make those systems run.   On top of that they will have application and business data that keeps your business alive.  But is that data encrypted?  Should it be? Is that data segregated on the underlying storage architecture?

Fundamental security….

These are fundamental security questions you should be asking especially if you are in and industry that is regulated or you fall under compliance regulations like PCI or SOX.  Even if you are not in an industry sector that require these types of controls you should from a security perspective keep data that belongs to critical systems away from data that is part of say a dev and test environment.  All common sense stuff I know but you would be amazed how many organisations are not following the basics when it comes to security…

VMware Security Advisory

Advisory ID: VMSA-2009-0008
Synopsis: ESX Service Console update for krb5
Issue date: 2009-06-30
Updated on: 2009-06-30 (initial release of advisory)
CVE numbers: CVE-2009-0846

1. Summary

Service Console package krb5 has been updated to version
krb5-1.2.7-70.

2. Relevant releases

VMware ESX 3.5.0 without patch ESX350-200906407-SG

3. Problem Description

a. Service Console package krb5 update to version krb5-1.2.7-70

Kerberos is a network authentication protocol. It is designed to
provide strong authentication for client/server applications by
using secret-key cryptography.

An input validation flaw in the asn1_decode_generaltime function in
MIT Kerberos 5 before 1.6.4 allows remote attackers to cause a
denial of service or possibly execute arbitrary code via vectors
involving an invalid DER encoding that triggers a free of an
uninitialized pointer.

A remote attacker could use this flaw to crash a network service
using the MIT Kerberos library, such as kadmind or krb5kdc, by
causing it to dereference or free an uninitialized pointer or,
possibly, execute arbitrary code with the privileges of the user
running the service.

NOTE: ESX by default is unaffected by this issue, the daemons
kadmind and krb5kdc are not installed in ESX.

Some of you may not be aware of this handy utility on the VMware ESX 3.x service console called ‘vimsh

It provides a metashell that gives you a lot of control over your ESX server and in terms of managment is a lot more efficient as you don’t have to shut things down…

Useful commands that it provides are shown in the next screenshot….

This util is completely undocumented and unsupported so use at your own peril!