Home > Blogs > VMware Security & Compliance Blog > Monthly Archives: May 2011

Monthly Archives: May 2011

vSphere 4.1 Security Hardening Guidelines for vCenter Configuration Manager (VCM) Released

The VMware Center for Policy and Compliance is excited to announce our content release of the vSphere 4.1 Security Hardening Guidelines for vCenter Configuration Manager (VCM).
CP&C is a group of folks with alphabet soup behind their names that build content, thought leadership and evangelize our Security & Compliance  strategy all over the planet.
Why should you care about this latest release? That’s easy, the content supports ESX 4.1, ESXi 4.1 and vCenter 4.1. That means we can automate the continuous collection of data, compare it to our standards and within minutes provide prescriptive guidance on best practices and  reduce the LONG painful audit cycle.
Together VCM and Host Profiles become an important  part of creating a trusted virtual environment.  With VCM and the new CP&C content you can harden your ESX/i hosts based on vSphere standards and use Host Profiles to push these secure settings across your virtual infrastructure.  There is no longer a need to painstakingly pour-over the best practices or reference technical documentation in order to configure the Host Profile reference host(s) to meet these standards.
By the way, these standards have been recommended to the PCI Security Council as benchmark for 2.0 content around virtualization. (Stay Tuned!)
Yours Truly, George Gerchow – VMware Director of CP&C.
vSphere 4.1 Security Hardening Guidelines Compliance Dashboard snapshots:





Quick Note on a Nice Blog Post from our Friends at Sourcefire

Rob Randell here with a quick note to point folks at a nice blog post from Sourcefire PM Richard Park.  He does an excellent job here outlining what it takes to integrate to vShield through the vShield REST API.  In this post he focus' on "…how to use the API to programatically make firewall rule changes."  He points also points out a few other things you can do with the API like:

  • List the current firewall ruleset
  • Add new rules
  • Get a list of past firewall revisions
  • Revert back to a previous ruleset revision

These capabilities are just the tip of the iceberg.  This REST APIs is key to the vShield product line because it allows for our partners to integrate their products very easily and customers to automate the security policy enforcement within their vSphere implementations. 

For more information on the API here is a quick link to the vShield API Programming Guide.  We'll revisit the APIs in much greater detail in a future post.

vShield App and View Desktops: Desktop Security Zones and the Desktop DMZ

Hi…Rob Randell here again.  In an earlier posting on the partner announcements at the RSA and HIMSS Conferences, I promised that I would go into detail on how we can leverage VMware View to provide what I like to call Desktop Security Zones and the Desktop DMZ.  In this blog I am going to illustrate this in a use case on a hospital network. 

Specifically, in this use case we have two primary sets of users: Doctors and Hospital Administrators.  The doctors need to have access to the medical records of their patients.  These records reside in a medical records app on the hospital’s internal network that they access via a browser. 

The hospital administrators on the other hand need access to the billing and insurance information of these patients.  This data resides on another set of servers also served up via a web application on the local hospital network.

The doctors have no reason to access the billing or insurance info for their patients and the hospital admins don’t need access to the medical information.  Both the doctors and the hospital admins need access to the web though so they can do research and check on personal matters. 

So based on this case study we are going to have three sets of virtual desktops:

  1. Doctor Desktops
  2. Hospital Administrator Desktops
  3. Web Browsing Desktops

We have two different users that we are going to demonstrate this use case for.  The first is Doc Jones and the second is Hoss Admin.  You can probably guess who is the doctor and who is the hospital admin. 

The first step we need to take in our configuration is to put Doc Jones and Hoss Admin into Active Directory groups that match them to their roles.  In our case, the AD groups are simply “Doctors” and “Hospital Administrators.  These can be seen in the screenshot below.


The next step happens in vCenter where we need to create some resource pools for the housing of our different desktop pools.  These will be necessary for our vShield App rule creation later.  We need to create three resource pools for our different virtual desktops: “Browsing Desktops”, “DoctorDesktops”, and “HospitalAdminDesktops”.  The screenshot below shows the three resource pools we created for our virtual desktops. 

Now that we have created our groups in AD and resource pools in vCenter, we need to create the Desktop Pools within the View Manager.  We will create three desktop pools to matchup with the roles we talked about earlier, BrowserDesktops, DocDesktops, and HospitalAdminDesktops.  You can imagine having additional pools here for other roles within a hospital like nurses, pharmacists, etc… For our use case we will focus on the Doctors, the Hospital Admins and the browsing desktops.  These can be seen in the screenshot below.


Next we configured the entitlements to give the user access to their desktop specific to their roles and the browsing desktop.   




OK, now that we have our desktop pools provisioned.   We need to create the rules necessary for the desktops to work properly.  This includes ensuring that Windows works properly and can communicate with everything it needs like DNS, AD, NTP, etc…  Lots of Windows rules to create as can be seen in the screenshot below.   Click on the screenshot to see the full image.


Communication with the View Server needs to be opened up to allow for PCoIP, USB redirection (if needed), etc…  We have up to 4 rules per desktop pool.  TCP and UDP for PCoIP to allow the View Client to connect to the View Desktop to allow the PCoIP display protocol to work, JMS to allow the View Agent to communicate with the View Manager, and USB Redirection that is tunneled through the View Manager.  Of course in a most cases I would argue that it is a good idea to block this traffic unless it is absolutely necessary.  In this case, it would be reasonable, and likely that we would disable and block the USB Redirection as we probably wouldn’t want the Doctors and Hospital Admins to be able to copy data off of their virtual desktops to a USB drive.   So in our case we will only have three rules per desktop pool (PCoIP (both tcp/udp) and JMS.  Click on the screenshot to see the full image.


Note that the creation of these rules can be scripted so as new desktop pools are created, we can then run a quick script to add the necessary rules. 

Next we need to create the rules to allow the doctors access to the medical app and the hospital admins access to the billing and insurance app.  In this case, albeit very simple, it shows that the Doctors are entitled to the “Doctor Desktops”, which are restricted by vShield App to only have access to the Medical Servers.  The Hospital Admins are entitled to the “Hospital Admin Desktops”, which are restricted by vShield App to only have access to the Billing Servers. 

We used vApps to group the Medical Servers and Billing Servers.  Doing this made creating our rules very easy as we just choose the “Medical Servers” and “Billing Servers” vApps for our destinations and the “HospitalAdminDesktops” and “DoctorDesktops” Resource Pools as opposed to doing some sort of IP subnet based rules.   Both the medical app servers and the hospital app servers provide access via SSL.  


Both need Internet access from the browsing desktops, as the other desktops are not allowed Internet access.  Notice that we deny the “Browsing Desktops” access to all Internal IP Addresses.  If a rule does not match these two rules, it means that the IP address is an external IP address where we allow these desktops HTTP and HTTPS access.  If we wanted to we could allow additional protocols, but for the purposes of our hospital, they should only need these basic protocols.  Also, if we wanted to send a syslog message anytime one of the browsing desktops attempted to access an internal resource and was denied we could check the “Log” checkbox in those rules.  In this case we didn’t choose to do that.


The doctors and hospital administrators now have access to their desktop and any of the resources that their particular desktop is capable of connecting to. This network access is controlled through vShield App where the View Connection Server controls the access to the desktop.  In this case, you can see the vShield App firewall rule that shows the DoctorDesktops have access to the Medical Servers.  Notice that we created these rules based on the resource pool where View Composer deploys the doctor’s desktops (DoctorDesktops) as the source and the vApp that contains the medical application (Medical Servers) as the destination.  Pretty simple, huh?  

Interestingly, it was pointed out to me by Rob Babb that we could make this even simpler for the browsing desktops by setting up a proxy server.  This could be the single point of access to the Internet and would make setting up the rules even simpler as we wouldn’t need the “Deny” rules to the internal networks for the BrowsingDesktops.  All we would need is an allow rule for these desktops to the proxy server, as the deny to the rest of the network would be handled by the default deny rules we have setup at the bottom of our rule set.

Now it is time for the users to login.  We will show the instance of a doctor logging in.  The doctor will run the View Client on their iPad, Thin/Zero Client, laptop, or any other device.  In this case we will show the login with the standard View Client from a Windows machine.


Doc Jones will then authenticate to the connection server.  In this case he is using a standard AD Credentials, but we could use a Smartcard or SecureID as well.


Once authenticated the doctor will have a choice of whether they want to login to the “Doctor Desktops” or the “Web Browsing Desktop”.  Once they decide on the desktop their login credentials they provided to the View Client will be automatically passed through using the single sign-on capabilities of VMware View.


In this case we are logging them into their main desktop so they can gain access to the medical server, but are not allowed access to anything else.   This can be seen in the screenshots below.



Here we can see both the allowed and blocked connections for the docvm2, which is the desktop that Doc Jones was using.


So to summarize, in a minimal amount of work, we were able to setup two desktop pools that are entitled to specific sets of users, which protected with vShield App are restricted to access only a specific set of resources.  Make note that these rules are good for one desktop or 1000 desktops as they apply to the resource pools as opposed to creating the rules for individual desktops.  So we don’t have to constantly add rules as new desktops are added or old desktops are removed.

The cool thing about this is that we can automate this even more to make it even easier which I didn't address in this posting.  I also didn’t talk about how we could use vShield Endpoint and vShield Edge in this use case.  Not to mention adding in partner solutions for IDS/IPS protections as well.  Stay tuned for more on all of this.