vSphere Network Security for Multi-Tenancy

[KapsZ28]

I was wondering what are some recommended solutions for ensuring the network is secure when running a multi-tenant vSphere environment without vCloud Director? I am not really a network guy, but are there risks of layer 2 intrusion or other possible issues?

Our environment is setup more like a single company running vSphere. All layer 2 networking runs through the same switches and the only separation is VLANs and Distributed Port Groups. No vShield or NSX. Being that NSX has micro-segmentation and you can completely isolate networks, I would think just basic layer 2 with VLANs is not exactly the most secure way to isolate customers especially if there is HIPAA, Finance, Legal, etc.

 

[mct]

Is routing setup between the subnets? So tenant A device on subnet 1 can communicate with tenant B device on subnet 2? If so then at a minimum you need to get access-lists in place to block the various tenant subnets from talking to one another.

 

[KapsZ28]

Is routing setup between the subnets? So tenant A device on subnet 1 can communicate with tenant B device on subnet 2? If so then at a minimum you need to get access-lists in place to block the various tenant subnets from talking to one another.

No, any routing that is done is through the core router which also has dedicated VLANs for each tenant as well. Only way to communicate is if they were on the same VLAN.

 

[mct]

No, any routing that is done is through the core router which also has dedicated VLANs for each tenant as well. Only way to communicate is if they were on the same VLAN.

Since you do not have layer 3 between the subnets then the only other types of attacks that come to my mind revolve around VLAN hopping. There is a good little write up here that discusses the 2 types of VLAN hopping attacks and how to mitigate them.

Still, nothing beats having a firewall or security gateway setup between the tenant networks especially if you are dealing HIPPA, PCI, etc.

 

[KapsZ28]

Since you do not have layer 3 between the subnets then the only other types of attacks that come to my mind revolve around VLAN hopping. There is a good little write up here that discusses the 2 types of VLAN hopping attacks and how to mitigate them.

Still, nothing beats having a firewall or security gateway setup between the tenant networks especially if you are dealing HIPPA, PCI, etc.

Well, there are no native VLANs, so hopefully that is not an issue.

 

[KapsZ28]

I came across this today about Hyper Jumping. http://www.tomsitpro.com/articles/virtual-security-tips-hyper-jumping,2-776.html

Seems like it mainly relates to the VLANs. Although I am a little skeptical of this issue.

One typical attack methodology was to overload the attached switch. When overloaded, the switch would push all packets out on all ports to preserve performance, effectively turning it into a dumb hub and losing any security the switching afforded.

How would a customer with only access to their guest OS possibly be able to overload the physical switch?

 

[Deleted member 16178]

While trusting proper VLAN segmentation is the basis of your current approach, there are additional risks related to the hypervisor and any other shared infrastructure that you need to be aware of.

What if a malevolent actor seized a VM and then exploited potential vulnerabilities to access the hypervisor? They could then hypothetically access any/all VMs on the host. The same could go for any shared storage that is presented to the hosts.

These are unlikely risks, but you should be somewhat aware.

 

[KapsZ28]

I agree, but how can someone access the hypervisor from a VM? Kind of hard to protect against if you don't know the actual vulnerabilities. The article above mentioned Blue Pill which apparently is from 2006...

 

[DermicSavage]

The attack vector for a VM attacking the host is very small, and is maintained well by patching. For the most part, Xen Project seems to have the most issues of guest based attacks on the host, but they are mostly only able to crash the host. In regards to PCI or HIPAA compliance, this is not a major concern so long as patching of the hosts are maintained

My company hosts private clouds, and this question applies very well to our own practices. We are SSAE 16 and SOC 2 operationally. Every tenant in our datacenter has their own VLANs or VXLANs depending on if they have physical hardware. The tenants do not have any access to the hosts (which is VMWare), only vCloudDirector and then direct network access. In regards to compliancy, layer 2 isolation for each tenant is sufficient so long as configurations are proper.
Each tenant also has their own dedicated virtual firewall (as it is a total nightmare to audit a centrally shared firewall). The WAN side of the firewall attaches to a public classified network. This effectively creates a complete layer 2 and layer 3 air gap between all tenants which completely prevents any cross talk.
This really assumes you have proper configuration on your switching side. Any tenant's servers are obviously restricted to their own VLANs. This assumes that all physical tenant servers are on access ports, properly restricted trunk ports, no CDP, no LLDP, and no DTP. For virtual servers, this is more easily handled by the vSwitch on each host. Our hosts all have their VM networking on a single trunk team feeding the host, and is still considered safe because you still have control of the tenant VLANs within the vSwitch of each host.

In short, golden rule is that isolation from layer 2 up is considered safe so long as configuration is proper. Layer 1 sharing (ie trunk of multiple tenants on a single wire) is acceptable and safe so long as you still have control of layer 2 on both ends of the wire.

Now, all the other requirements for HIPAA compliance I think vastly overshadow network requirements. Like disk encryption, logs, and backup retention.

 

[KapsZ28]

That is pretty much how we are setup. All ports are trunked appropriately. Only VLANs in use are setup on the switches. We are also an ISP so public IP blocks are setup for customers and not shared. Also tagged on our core routers. It is up to the customer whether they want a firewall or not, but firewalls are never shared.