With the advent of existing VMsafe products from Altor Networks, Reflex Systems, and ones on the horizon from Trend Micro and others in the security space, all administrators should have a clear understanding of how they work under the covers. Where does VMsafe appear within the stack? Is VMsafe on the incoming physical NICs, within the vSwitch, portgroups, or before or after the vNIC? Can we expect the other aspects of VMsafe to be the same? While I was discussing VMsafe with the vendors, VMware was also going around and talking to all the VMsafe vendors for VMware TV shots.
VMware implemented VMsafe as a faster and more authoritative mechanism to handle security tools as running a security appliance within a VM can be quite a bit slower and not as authoritative than running within the hypervisor. VMsafe products extend into the hypervisor by providing a fastpath driver. These fastpath drivers can be ordered and chained together so that data could for example get interpreted by Altor’s VF30 and then by Reflex Systems vTrust; or even in the other order. Ordering within VMsafe will become very important as more VMsafe tools are developed.
However, first let’s look at how things are implemented.
Pre-VMsafe
Existing virtual firewall appliances sit between virtual switches like:
Or they listen on a virtual portgroup with a VLAN ID of 4095 as well as requiring promiscuous mode settings on the portgroup. The second is a clear security issue.
These types work by disabling the vNIC as an act of quarantine if the device detects incorrect traffic but some data still leaks through until this happens.
With VMsafe
When it comes to VMsafe and virtual networking, VMsafe does not really live within the vSwitch, nor within the virtual Portgroup, but between the portgroup and the actual vNIC within the VM. If your VM has more than one vNIC there will be more than one VMsafe instance. So we basically have something that looks like the following with VMsafe-net represented by the locks:
In otherwords it is a bump in the wire just before it reaches the vNIC.
But I thought the VMsafe firewalls were in the vSwitch? Well they sort of are, but in essence the data traverses the vSwitch and then you can use VMsafe to determine if the vNIC should receive the packet or not.
This is an incredibly powerful tool because now I can block traffic between two VMs on the same virtual portgroup without the need to disable virtual NICs. However, the data is within the vSwitch by the time VMsafe-net takes affect.
Further Thoughts
The security vendors with VMsafe products, such as Altor Networks and Reflex Systems and those with upcoming VMsafe products such as Trend Micro and Catbird to name a few, have some interesting dilemmas going forward or perhaps the customer has to handle these themselves:
- The order in which the fastpath drivers are called. This could impact how well a security or networking tool works depending on how it works with the network packets transmitted. There may be some edge cases where the first fastpath driver rejects a packet that another fastpath driver called later in the stack needs. Ordering also comes into play if on an error one of the fastpath drives fails-open while another fails-closed.
- Since the possibly dangerous packets are already within the vSwitch by the time VMsafe-net fastpath drivers can be notified, there is a theoretical risk to the vSwitch. Should there not also be a VMsafe-net component that is also before the vSwitch? Due to this, the need for the traditional firewall will not change until such time as there is such a component to VMsafe-net.
- There is now an abundance of possible VMsafe firewalls to manage. At VMworld this could have been upwards of 40000 VMsafe firewalls in the VMworld datacenter. Will the current batch of management tools scale to handle this many systems under protection at once?
- VMsafe is currently a zone to zone protection, in other words it is a flat network with no NAT, PNAT, SNAT, or port redirection cababilities. Those people who use this capability may have to rethink how to protect these environments or use more traditional mechanisms within VMs. VMware vShield Zones does not even have this capability but the free Smoothwall, Ipcop, and m0n0wall firewalls within a virtual appliance do.
While VMsafe is in its infancy there are sill enough there that finally a security administrator can make use of, such as a true defense-in-depth using external firewalls, VMsafe-net firewalls, and per VM firewalls. With VMsafe it may become possible to remove the latter which could be a good thing if you have many different virtualized operating systems or ones without built-in firewalls. This could definitely improve overall firewall management as now there is only one component to manage for all virtual machines: the VMsafe firewall you have chosen: Altor’s VF3.0 or Reflex System’s VMC w/vTrust.
Both Altor’s VF3.0 and Reflex System’s VMC w/vTrust have different approaches for managing all these new VMsafe firewalls that will grow in number (1 per vNIC) and scope (multi-tenant, multi-policy, etc.) over time. These products provide good management tools for most of today’s environments, but will need to mature as the scale of production environments grows into the 10’s of thousands of vNICs, policies, and tenants.
The future also looks bright for improvements in all the tools using VMsafe as the biggest problem with all traditional security devices is that they are not authoritative but have to learn or be told what is good and what is bad. VMsafe is authoritative without the need to learn what is good or bad. Given a codified security policy Altor’s VF3.0, Reflex System’s VMC, and Catbird’s vCompliance offering can and will react to VMs violating policy.
If you have VMware vSphere then give your security administrator the heads up about the various VMsafe products so they can implement a true defense-in-depth.