New in Hyper-V Windows Server 2008 R2 Part 2 – MAC Spoofing

Our Virtual Switch got smarter in Windows Server 2008 R2. In Windows Server 2008, VMs are susceptible to MAC spoofing. MAC spoofing is where a (generally) malicious machine pretends to be another machine on a network (there are legitimate applications which do spoof MAC addresses though – Network Load Balancing being one such example).

A MAC (Media Access Control) address in physical NICs is burnt in, although it can usually be over-ridden. In a virtual machine environment, there’s no physical counterpart, so we have to “make up” our own addresses. In fact, that can sometimes cause other networking issues which I talked about last year.

The virtual switch in Hyper-V is a learning layer 2 switch – in other words, it routes packets based on MAC addresses. Therefore, if a malicious VM starts sending out packets with a MAC address owned by another machine, it causes the switch to re-learn. This in turn can cause DoS (Denial of Service) attacks, and the potential for the malicious virtual machine to see packets which weren’t destined for it. Hence, in our security recommendations, we state that as a security best practice, you should consider (in Hyper-V v1 at least) placing virtual machines of a similar security integrity level on the same virtual switch and not share the switch with virtual machines of a different security integrity level.

In Windows Server 2008 R2, we introduced several changes in the switch to make it smarter. Each virtual switch port has a new property (exposed in our WMI model as AllowMacSpoofing) which is off by default. We also expose this property in the settings page for a virtual machine. Note that to see this setting, you must be using the UI from Windows Server 2008 R2 or RSAT in Windows 7 Client.

When the checkbox is not checked (i.e. the port is in “secure” mode):

1. The MAC address set in the Virtual NIC settings page (either static or the dynamically assigned on) is the only MAC address a virtual machine can specify for the source MAC address in any packets it sends.
   
2. The virtual machine will only receive unicast packets with a destination MAC address matching the address in the virtual NIC settings page, and packets destined for its MAC won’t be flooded to other ports.
   
3. As our virtual switch is a learning switch, we maintain various internal structures including a routing table. When the virtual machine starts and we power-on the virtual NIC, we pin the MAC address in the virtual NIC settings page into the routing table to ensure it cannot move to another port. We stop any more learning on that port.
   
4. When traffic needs to be flooded by the switch to switch ports, we do not flood traffic to ports running in “secure” mode.
   
5. Attempts to override the MAC address inside the virtual machine are ignored.
   

When the checkbox is not checked (i.e. the port is in “less secure” mode):
(6/15/2009 - fixed typo, removed word "not" above)

1. The virtual machine can send and receive traffic using any MAC address
   
2. The virtual machine receives flooded unicast packets
   
3. Learning is enabled on the switch port so that multiple MAC addresses can be learnt on that port. No pre-population of the routing table is performed and MAC addresses for a port are learnt as traffic passes through the switch.
   
4. Virtual machines can override their MAC address.

The above applies to virtual NICs used by virtual machines. We treat virtual NICs in the parent partition slightly differently and there is no setting to put that NIC into “secure” or “less secure” mode. The virtual NIC in the parent partition is always pinned in the routing table, but they receive flooded unicast traffic, learning is enabled on the switch port and can send using any MAC address.

Cheers,
John.

And thanks again for Keith Mange for pulling the above information together :)

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS