Comments on: The vSwitch ILLUSION and DMZ virtualization

By: Brad Hedlund

Brad Hedlund — Wed, 26 May 2010 20:25:26 +0000

Stephane,
Under a policy of strict physical network separation, you would definitely keep Vmotion isolated inside each zone. By providing physical network separation between zones, you have by definition already provided physical separation for access to storage over IP. Whether or not the data itself is resting on the same storage system is certainly up for debate. You could link all zones into a common ESX management framework, or not, it all depends on what your security policy tolerates and who’s enforcing it.

Cheers,
Brad

By: Stephane

Stephane — Wed, 19 May 2010 13:08:18 +0000

Brad,

Great article ! Thanks !

I get confused by the way. Let’s imagine corporate security policy states there should be physical isolation between security zones. On the ESX cluster running the untrusted VMs, you would still need some virtual networking to connect to Vmotion network / ESX host management network / possible IP storage network. How can you comply to physical isolation policy in that case ?

cheers

By: John Howell

John Howell — Wed, 31 Mar 2010 22:40:12 +0000

This was the approach I have just used in desiging a DR network for a client who wanted to share a single cluster of ESX Hosts with multiple groups with different security requirements.
I got upfront the decision to allow virtual seperation for the DR network (production requires physical airgaps) as rack space and copper switchport counts were at a premium.
However you also need to take into account location physical security.
These hosts are locked in a rack with limited physical access. The management network switches for them are located in the same racks, the Guests network switches are located in a shared comms rack. Cabing to that rack is provided by inter-rack ties.
So for this config I still used 3 VSwitches – two interfaces were given to a management VSwitch, one interface to a VMotion switch, and two interfaces given to the guest switch, then using VLAN tags for the network seperation.
The next vulnerability then is attacks against guests to cause leaks between running guests. For this reason we still seperate guests facing public networks from guests on the private networks by limiting the VLANs on each host.
This way capacity can still be easily managed remotely by simply changing the guest VLANs supported on certain hosts depending on the disaster scenario we are configuring for

By: Antonio

Antonio — Wed, 03 Mar 2010 21:52:22 +0000

First of all: great blog! And excellent article. Only one point: while I think you are right about your assumption on vmware “more than one vSwitch” situation I don’t think you experiment is a definite proof of this for two reasons:
1. Many OSs (I’m not sure about vmware of course) can “instantiate” multiple copies of a process/program without actually duplicate it in memory. Today’s processors can enforce (and allow) an OS to keep data memory segments separated from the code ones. Modern OSs tend to assign a “virtual memory space” (nothing to do with vmware ) to each process that is done by code “pages” and data “pages”. Such pages are allocated to a process and are pointers to the phisical memory (i.e. two process can share the same code page and not be aware of it).
If this is true for ESXm each new vSwicth will add only the data segments to the used memory counter.

2. Even if the vSwitch is just a memory structure somewhere I would have expected to see the used memory increased when you add some. Maybe the counter used from esx is to “raw” (or just rounded to MB). I don’t expect such data structure to be big (especially when “empty”) so it maybe just the counter don’t “notice” it.

Regards

By: Duncan

Duncan — Wed, 03 Mar 2010 06:57:43 +0000

I have to agree with Charu on this one. I personally don’t have a preference, both options work fine but indeed the maturity of a customer heavily dictates which options you have. To them the graphical presentation in vCenter means physical separation and again means secure, although we all know this is not necessarily true.

I really like this article though, keep them coming!

By: Justin Doles

Justin Doles — Tue, 02 Mar 2010 18:36:32 +0000

I’m glad I made it to the end! Excellent article. We’ve been looking at the 1000v vs. vSwitch for our new VMware environment. Seems like it may be worth the cost.

By: Charu Chaubal

Charu Chaubal — Fri, 26 Feb 2010 17:56:49 +0000

(Disclaimer: I work for VMware)
Thanks for this great piece. It really helps to explain this issue more clearly and I think it will help a lot of people more rationally approach their datacenter security design.

Although I agree with the conclusions, I think it’s worth mentioning that vSwitch segmentation is not entirely an illusion, when it comes to security. First off, I’ve heard a number of customers say that they don’t trust VLAN isolation because of the history of successful VLAN exploits (you have outlined ways to address these concerns above). Although these may largely be in the past, it still makes customers wary of relying upon them. By contrast, the track record of vSwitch isolation has been very good. In fact, there has not been any successful public exploit of the VMware vSwitch to date (not that it couldn’t happen in the future, of course). So, people have a greater comfort level with relying upon vSwitch segmentation for security, vs. only VLANs.

The second point, perhaps more subtle, is that even if you “trust” VLAN isolation, some customers have said that the effort of configuring and administering VLANs throughout their environment introduces complexity that they feel weakens their security posture. They feel they don’t have sufficient maturity in terms of their management processes and policies to take on this risk. For them, vSwitch segmentation provides a neat, simple solution that doesn’t have as much management overhead.

Again, I agree with your conclusion, and I believe this is the direction we should all be going in, but there are legitimate reasons to continue relying upon vSwitch segmentation today.

By: Bryan

Bryan — Tue, 16 Feb 2010 18:20:48 +0000

Certainly a more diplomatic way of “picking your battles.” Thanks for the articles and the insight.

By: Brad Hedlund

Brad Hedlund — Mon, 15 Feb 2010 23:01:16 +0000

Bryan,
While I do have my own opinions on the necessity of physical separation, that is not the battle I’m fighting here. If you require physical separation because you think it’s more secure, or to simply appease auditors, great, go ahead and do it. But if you are going to implement physical separation … do it right and actually provide *physical separation* throughout the physical and virtual network. Otherwise, what have you gained? By perpetuating the illusion you still have an architecture that can be challenged and questioned by auditors, and you have subjected your server virtualization architecture to the consequences I outline in the article. Rather, if you do it the right way and provide consistent physical separation throughout the physical and virtual network, you end up with an architecture that is easily defensible under criticism and without any of the consequences from an inconsistent and “illusional” physical+logical separation design.

Cheers,
Brad

By: Bryan

Bryan — Mon, 15 Feb 2010 21:12:48 +0000

It seems to me this is a round about way of saying that physical separation is obsolete, which I agree with. However bureaucrat auditors will wave policy in your face whether it is relevant or not, and as a result the illusion of physical separation is important to maintain. Though I agree that if you can get them to accept the virtual network as secure, then they should certainly accept a logical one the same way.