Can I Mix LAN and DMZ/Internet VMs On A Hyper-V Host/Cluster?

The question of mixing internal and edge network virtual machines on a single Hyper-V host or cluster has popped up a number of times over the past few years.  Businesses are under pressure to reduce costs, but there is that old issue of security.  It’s something I’ve given consideration to over the past few weeks and I have a few answers.

I’ll start with the simplest answer: Yes, you can, and you can do it securely.

Firstly, the Hyper-V virtual switch, without third party network add-ins (like NIC teaming) is secure.  You can’t bounce from one VLAN to another.  In the below example, we have a simple scenario where VLAN 101 is in the LAN and VLAN 102 is an edge network.  The physical network firewall isolates the two VMs from each other and they cannot eavesdrop on each other. 

image

NIC teaming can change things quite a bit if you have 2 pNICs for virtual switch traffic on the host (read the OEM’s guidance).  In the case of the HP Network Configuration Utility, you need to do something like this to maintain security:

image

Both of those deal with traditional firewall and network isolation.  But is that enough?  The virtualisation guidance for Forefront Threat Management Gateway (TMG – Microsoft’s firewall solution) indicates that we have more thinking to do.  Firewall and network isolation is not enough.

A distributed denial of service (DDOS) attack aims to disrupt or bring down an online service by flooding it with traffic of some kind.  I’ve seen one in action (against a small company in Ireland).  They really are more common than you would think, small companies do get targeted (not just the big guys/government), and you rarely hear about them. 

The one I saw succeeded in bringing down the edge network devices, first one, and then the next in line when the defence/attack were adjusted.  That attack brought down dedicated network appliances.  What if the appliances hadn’t gone down.  What was next in line?  With the above two designs the next network device is either the pNICs in the host or the virtual switch in the host.  The pNICs share traffic for internal (LAN) VMs and external (DMZ) VMs.  If the NIC fails – everything loses communication and therefore the DDOS hits not just the online presence but the LAN VMs too.  If the virtual switch is hit then we’re looking at the CPU and RAM of the parent partition being stressed, and DMZ and LAN traffic/VMs experiencing downtime.  We need physical isolation of LAN and DMZ in some fashion.

The cheapest solution would be to have dedicated NICs in the hosts: one for LAN traffic and one for DMZ traffic.  This would allow a single host/cluster to still run internal and external VMs but to isolate the impact of traffic at the NIC level (as below).  At least now, if the online presence is hit by a DDOS attack then we’ve limited the impact of the damage.  In the below example, pNIC2 is the last physical device that can fail or be flooded.  The VMs on pNIC1 are physically isolated from the DMZ and should be unaffected … of course that assumes that the virtual switch for the DMZ (on pNIC2) doesn’t spike the CPU/RAM of the parent partition – I actually have no idea what would happen in this case to be honest – my guess is that an edge network or the WAN connection would suffer first but I really do not know.

image

If your web presence is large enough, then maybe you can justify a dedicate Hyper-V host/cluster for the edge network.  The design would be something like below.  This design is a take-no-chances solution that completely isolates everything.  If the online presence in the DMZ is hit by a DDOS attack then there is not a single physical connection to the LAN Hyper-V hosts that should impact their normal operations within the LAN.

image

There is another benefit to this design approach too.  The handful of security fixes for Hyper-V have been related to DDOS attacks from within a compromised VM on a host.  In other words, if a VM is compromised (for example, a hacker gains admin rights on a VM via a SQL injection attack or a WordPress website compromise), they can use their local log on in the VM to DDOS attack the host that the VM is on if the relevant Hyper-V security fixes (as shared by MSFT via Windows Update) have not been applied.  If you aren’t quick about your updates you might get hit by a zero day attack if you have the really bad luck of (a) not having the update deployed and (b) a hacker gaining logon rights on a VM.  If that’s the case – you know at least that all that the hacker can DDOS attack are the DMZ VMs that are on that particular DMZ host.  And hopefully you’ve been good with your network isolation, password rules, etc, to slow down the hacker, and maybe you have an IDS to detect their attempts to break out from that VM via the network.

Anyway, there’s a few thoughts to keep you thinking.

5 thoughts on “Can I Mix LAN and DMZ/Internet VMs On A Hyper-V Host/Cluster?”

  1. Great subject, with lots of things to dicuss. I’m using the latter design in production environments that can take the cost (which isn’t that much higher as when your big enough having a total of 8 Hyper-V hosts costs the same whether is is in one or in two clusters, appart from more management). When I do use one cluster to host different security “domains” I do it on a management domain that hosts the cluster and the DMZ, LAN domain are both running on that cluster but are not part of it. Don’t even get me started on the subject of management software in those scenarios. There is a reason why more cloud friendly future versions of System Center & Windows are being evaluated. The concept of secure and manageable multi tenancy is built in to them way better than now.

    On the matter of VLAN boundaries I’m sobered by things like http://www.eecs.umich.edu/techreports/cse/2007/CSE-TR-539-07.pdf and http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml The technology stack involved in security is both deep and wide. Isolation/compartmentalization are the only things that mitigate and buy time to detect and react. At the price of flexibility, ease of use and cost. In the end, it all comes down (again) to risk management.

    We went as far as to discuss the risk of sharing a SAN for Cluster in different security domains and evaluating the risk (FC, iSCSI). In the end you have to weigh that against the probability of an SQL injection attack or other web vulnerability …

    Take care,

    Didier

  2. Great topic!

    Do you know if there are any official proclamations on this from Microsoft and/or a respected security authority?
    We are using something that looks a lot like your 2nd design right now. We haven’t had to survive an Audit yet but I’m expecting to have to defend that design decision to the checklist guys on the Audit Team.

    1. The second one is what’s published by HP for their network configuration utility & Hyper-V. I’ve not seen anything by a true security expert on this topic. I do know that something was done by a German state agency on Hyper-V security a few years ago but that’ll be in German and I don’t know if this topic was covered.

  3. You know I remember seeing something similar that was released by VMware a while back. It was a bit too complex for me to understand fully but I think it basically broke down the different options available for hosts that need to support VMs that are in different security zones. For instance, you can keep it completely physically separated with different hosts in diff zones or you can virtualize the isolation of all the different zones on one host. The terms they used were partially collapsed or fully collapsed.

    I don’t know how this translates to Hyper-V’s current options but I’m guessing that the v.next Hyper-V and its extensible vSwitch will allow similar things to be done?

    Here’s the VMware doc that I mentioned: http://www.vmware.com/files/pdf/network_segmentation.pdf

Leave a Reply to Berserker Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.