vSphere Security Hardening Policy and SRM 5
VMware is in the process of working on the vSphere 5 edition of the Security Hardening Guide and will shortly make a public draft available for comment (I’ll let you know when it’s available). This will be great news to the many people who have been waiting patiently for it since the vSphere 5 release. A lot of work is going into making this edition of the Security Hardening Guide much more user friendly and easier to use and implement. Many of the locked down items will be the same as in 4.1, and of course some changes and enhancements too. Another difference this time around is there are now new implications and restrictions on functionality introduced by the recommendations due to changes at least one popular VMware vCenter Management Tool. This is where Site Recovery Manager (SRM) v5 comes into the picture.
This isn’t going to be a log article as I want your opinion and I have two Yes/No Polls for your to answer. SRM v5 introduced a lot of great new functionality, workflow improvements, more logical and useful dependency mappings and start-up orders, greater scale, greatly improved performance for recovery plans and recovery operations. The performance of recovery operations are now significantly faster to run than in the previous version. However to get that performance increase VMware has changed the mechanism used to change IP addresses and communicate with the Virtual Machines for some operations.
If you’re not sure what I’m talking about check out the vSphere 4.1 Hardening Guide and search for VMX30 or VIX.
This change is significant if you apply the security hardening recommendations. SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery. There are no other options available. You either use the VIX API and live with the security risks, or you don’t change the IP addresses on the VM’s during recovery.There is no option to use the old change of IP address mechanism that was slower but didn’t rely on the VIX API, which would have been a very good option to have in my opinion. This has already caused me design problems in a number of customer environments.
If you don’t have a need to disable the VIX API because your security policy and vSphere Hardening policy doesn’t really justify this level of security then the change to SRM is going to be no problem and in fact extremely beneficial for you. Thins will run much faster. If however you have strict security and hardening policies and some of the VM’s targeted for protection require the VIX API to be disabled, and need an IP address change during recovery, you will have a problem and need to deal with it. There are a number of potential ways to solve the problem, but none are very elegant or easy to implement.
So this leads me to the two polls. Do you have a policy to disable the VIX API, and will this cause you a problem with SRM that might force you not to use it? Please let me know and get as many of the people you know to respond to this survey. If I get enough responses I will send this feedback onto VMware to review. If nobody cares enough about it, I’ll forget it and move onto something else.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
Leave a Comment
Sponsors
Mako Networks
Your Author: Michael Webster, VCDX5 #66, vExpert 2012
IT Solutions 2000 Ltd
More sponsors welcomed. Contact me directly via the Author Page.
Old Long White Virtual Clouds 
fixed DHCP based on mac… simple and effective 🙂
Hi Duncan, Great suggestions as always. That would certainly work in some instances, and I should have included it. I think in the environments that are concerned with VIX API, they may also disallow DHCP. A lot of environments block this at the switch and insist on static IP addresses. But in a DR situation in may well be acceptable dependent on customer requirements to at least in the short term relax that in some cases. May not work so well with spoofguard in vShield App either. I know some customers have some creative dynamic routing to get around this currently.
Agreed, I wonder why more companies don’t just use DHCP with reserved IPs based on MAC for all servers. DR…done…
Risk of DHCP Spoofing is the main reason. I’ve had another suggestion which is use the existing vCenter OS Customization specifications and call them via a script. This still uses the old method and may well work. Just not sure how well this would scale, and it adds a few more moving parts. VXLAN when available and certified to EAL4+ may well solve this problem also.
I have to agree, DHCP is a very effective way to address the IP change. I’ve just completed a deployment with one of my customers doing just that across a multi-tier SAP implementation. DHCP spoofing is certainly a risk but if a company is that concerned about security they would have a lot of other measures in place to help mitigate that risk. But then that said I’m not a security expert !!
I have to agree with Gary. We use DHCP across all our production servers (with reservations) and it has made the integration with SRM 5 and failover of VMs so easy. Best of all the MAC address of the VM doesn’t change during failover to a different virtaul center so you can specify IP addresses with reservations in advance for DR too if you wish.
I didn’t do the survey, but wanted to voice my opinion. Each item in the guide is a RECOMMENDATION. This is NOT the Gospel According to VMware. It should be added as a recommended item, but should have a note/comment that it will break the functionality of SRM. Some people view this stuff as a requirement and don’t consider the constraints each decision places on the next decision. Leave it up to the designer to decide not to comply with the VIX recommendation and provide justification for it.
Hi Dave, I agree. However external auditors and organizations without full knowledge of the impact often make the call as to which recommendations must be applied. Also it is often a requirement to meet certain regulations. In these situations there may be little room to maneuver. Then there is the fact that it’s the vSphere Hardening Guide, and doesn’t take into account other VMware Products. I will ask VMware to include a note re breaking SRM functionality with this particular recommendation though, given it’s now well known.
We need a protocol to provide safe and reliable IP change service.
I am unsure whether it is good to let the vNIC driver having the capability of changing IP by responding to fail over requirements from SRM.
Hi Fo, It’s not the vNIC driver that does this, it’s SRM doing it via VIX. It’s just changing the IP address inside the Guest OS when the VM is recovered and powered on at the recovery site, which is in a different IP subnet. This is not necessary with stretched layer 2, but many companies don’t have that available and do need to change IP’s. vSwitch Security configuration also needs to be taken into account.
Hi Fo, We do have a safe an reliable IP change service via VIX. Provided the proper security controls around it’s use are implemented. It’s also possible via vCenter Customization Scripts.