Share via

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

  • Article

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.

image

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 :)

Comments

  • Anonymous
    January 01, 2003
    Our Virtual Switch got smarter in Windows Server 2008 R2. In Windows Server 2008, VMs are susceptible

  • Anonymous
    January 01, 2003
    PingBack from http://windows7live.info/?p=10657

  • Anonymous
    January 01, 2003
    Ultima Hosts - are you saying the physical switch port will only accept the physical MAC address? The virtual switch doesn't have a MAC address itself - VMNics (or the VNic in the parent partition if configured) have MAC addresses. If the physical switch port is ACL'd to only allow the MAC address of the physical NIC, you need to relax security on that switch port to allow all traffic for the VMNics (and optionally the parent vNIC) for traffic to be able to flow. Thanks, John.

  • Anonymous
    January 01, 2003
    Joay - for example if the application running in a VM needs to send packets out with a source MAC other than the configured MAC address for the VM - Network Load Balancing (NLB) does this. Thanks, John.

  • Anonymous
    January 01, 2003
    Good spot - thanks Jason (and to others who mailed me direct). I've corrected the post. Thanks, John.

  • Anonymous
    January 01, 2003
    Madshark - the Hyper-V virtual switch is a layer 2 switch in both 2008 and 2008 R2. As such, to enforce seperation at layer 3, there are a few options. One is to use seperate physical NICs (obviously somewhat limiting in terms of scalability). VLANs will also provide full separation. There are some software solutions out there from vendors such as fivenines too. Thanks, John.

  • Anonymous
    May 22, 2009
    Under what scenario would you choose "Less secure'?

  • Anonymous
    June 07, 2009
    I think you have a typo above... "When the checkbox is not checked (i.e. the port is in “secure” mode): ..." "When the checkbox is not checked (i.e. the port is in “less secure” mode): ..."

  • Anonymous
    November 11, 2009
    Any pointers on how to setup the virtual network when the switch will only accept the physical MAC address?

  • Anonymous
    November 12, 2009
    Hi, what about spoofing IP addresses? It seems the virtual switch is not yet 'smart' enough for ACL's to be configured. In a hosted environment any customer's VM can steal the IP of another VM in the same subnet or even worse the gateway ... ... I would really like to here your comments on this issue. Yes I am talking about selling VM's as opposed to an internal environment so layer 2 security is essential.

  • Anonymous
    October 06, 2010
    Normally when you enable NLB in unicast mode your will encounter switch flooding because the traffic is send to all switch ports. You can solve this by enabling NLB in multicast with IGMP mode. But what happens when you enable NLB in unicast mode on Virtual Machines (hosted on Hyper-V)? Technically, does switch flooding occur as well? Another question is, does it actually support NLB in multicast (with IGMP) mode?