As I've mentioned in other tips that I have written, I consider all virtual machines (VMs) to be hostile to the virtual environment. In other words, they can become attack vectors into the hypervisor or the management appliance for the virtualisation host. The issue arises when VMs access a storage device that is also being accessed by virtualisation hosts using any sort of storage capabilities such as a network file system (NFS) over a transmission control protocol (TCP), iSCSI, Fibre Channel over Ethernet (FCoE), or a Fibre Channel host bus adapter (FC-HBA) supporting N_Port ID Virtualisation (NPIV).
Storage networks themselves could also end up being attack vectors when the storage for the hypervisor is shared with some other devices, perhaps hostile systems or devices. In this tip I'll highlight some of the configurations that could open up your environment to outside attacks through storage networks.
Virtual machines that share a storage device with the hypervisor
If some of your virtual machines share storage devices with the hypervisor, there is a higher risk of VMs acting as attack points to gain access to data that only virtualization hosts should access, like virtual disk files. In some cases, the VMs may even be able to see all of the other virtual machine and host traffic for a given storage device.
Most storage security relies on IP addresses, which are very easy to spoof, or challenge handshake authentication protocols (CHAP) which are usually not enabled. For example, let's say there are five VMs speaking NFS to the same NFS server as the virtualization hosts. There are now five-times as many attack points available than normal. NFS is one of the least secure file sharing protocols as it's susceptible to several types of attacks. What would be the risk to your organization if an attacker could gain access to those VMs and thereby gain access to virtual machine disk format (VMDK) files?
Pivot Attacks
You may think you're not susceptible to the attack I outlined above. Your firewall and DMZ protects you from this sort of thing right? Well unfortunately, they only protect you to a certain point. A professional penetration test will show where you have weaknesses that need bolstering. If there is a weakness in an external facing host, the host could be compromised and the attacker could then upload their own tool suite and use that host as a way to pivot an attack further into your network. The attacker would use as many pivots as necessary to achieve his or her aim. Unless, a machine is "off the network," it could be accessible through pivoted attacks.
Multiple Management Appliances connected to Storage
Another area of potential weakness is the use of multiple management appliance ports: one for any management appliance (hopefully only on a management network), and another on the storage network. This secondary management network link creates another attack point through the storage network into your management appliance. Access to the management appliance could allow access to everything. A VM could not only be used to attack the IP storage server, but also anything on the storage network, such as a management appliance node. To mitigate this, I recommend erecting a firewall around all management appliance networks from the storage network.
Attack the Hypervisor
Just like attacks to the management appliances, storage networks could be used to directly attack hypervisors. This clearly is more of a critical threat than the others combined for several reasons.
In conclusion, I recommend that you keep the storage for hypervisors separate from the storage that can be directly accessed by your VMs. This way you can lower the number of attack points into the virtualisation hosts and better protect your environment.