Many a comment on the VMware Communities Forums are about using VLANs to secure a network, while technically this is not a network security feature of the network it does provide a way to logically segregate traffic. In my mind segregate is different than separation.
Segregate implies a logical distancing between two or more elements, yet the elements of the network share the same wires, switches, etc.
Separation implies a physical distancing between two or more elements where the elements do not share anything in common.
To use virtualization, it is impossible to achieve 100% separation as we discussed in my Rethinking vNetwork Security post. I have continued to consider all aspects of the vNetwork with respect to security and VLANs. So here are some basic rules that will help you to decide how to design your vNetwork. These rules are based within the physical network (pNetwork).
- If your trust zones are physically separate within the pNetwork, then you must maintain that physical separation within the vNetwork. In other words you do not use VLANs as a mechanism to segregate your traffic but instead use different physical switches.
- If your trust zones are logically segregated within the pNetwork, then you can maintain that logical segregation within the vNetwork. In other words you can use VLANs.
- Do not consider a virtualization host a server, consider it a hybrid device that provides compute, network, and storage networking. It is at the same time a compute engine, network switch, and a storage fabric device.
Just three basic rules but they seem to confuse many folks. It seems that many people consider the vNetwork to be separate from the pNetwork, that needs MORE security or in some cases needs less security. These statements do not coincide with the rules and imply a general lack of understanding of how vNetworking works.
Quite simply the vNetwork is an extension of the pNetwork with a different layer-2 stack. The virtualized layer-2 stack is authoritative about what is directly connected to it, so does not need to learn MAC to IP address connections. It knows this information directly from the hypervisor via the virtual machine manager that is the communication layer between the VM and the hypervisor. Because, this layer-2 network can be authoritative, it is actually more secure than a traditional layer-2 network.
How is the vNetwork layer-2 network more secure? Simply because it is authoritative and does not require a CAM table within the vSwitch constructs. The CAM table is the most attacked component of a pSwitch with most of the layer-2 attacks targeting that all important component of a pSwitch. On top of that most of the vSwitches have less configurable options and therefore less of a chance for mistakes to be made. This is why VLANs are not a security construct in the physical world – you have to configure the pSwitch to protect the VLANs, they do not come out of the box protected unlike a vSwitch where VLANs are out of the box protected.
This is why in the pNetwork, VLANs as a security construct is based on TRUST in the pNetwork configuration and the people who configure those pSwitches.
So what about layer-3 an higher attacks? Those still work within the vNetwork and as such require tools such as IDS/IPS, Protocol Analysis Modules, deep packet inspection, and other tools you would normally use within the pNetwork. The vNetwork does not protect against these types of attacks.
vNetwork Security is tied to pNetwork security. How you design your pNetwork will directly impact how you design your vNetwork. If you have layer-3 and other protections within your pNetwork then you need to make sure they are in your vNetwork. The tools mentioned within the End-to-End Virtualization Security whitepaper will help you with this.
Even so, there is nothing like fully understanding the protections inherent within your vNetwork and the Roles and Permissions you can set within the virtualization management tool suites to ensure your vNetwork is secured, audited, and monitored for issues. Just like you do now within the pNetwork. Unlike the pNetwork, the vNetwork provides a certain amount of introspection and capability that is missing from a pNetwork, and this will also help with security.
So review the three rules, understand your pNetwork, apply the security to your vNetwork, and then use the vNetwork functionality to gain further insight into your traffic and investigate the use cases for further introspection to gain even more insight into your vNetwork security. It all starts with some reading however. I suggest starting with the Top Virtualization Security Resources which should be reviewed by all involved in virtualization security: security, system, storage, and virtualization professionals within your organization.