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