I promised a year back that things would get quite technical here on - well, here we go!
A couple of weeks back, I tweeted
Bfn hyper-v. I'll accept you are a child prodigy, bit I'll take a look when you're all grown up. Pathetic support for a Linux setup.
— rvivek (@vivek_310) March 20, 2013
This was after a long and frustrating month long attempt to get my pentest lab running on my laptop.
Now, all of us pen-testers know how important it is to have a lab setup to simulate different scenarios. And for budget constrained among them, a fully virtualized environment is all that’s possible. I was quite happy with my setup on VMware workstation. But the lure of a type 1 hypervisor was too tempting – I had to take a bite! As a result, bought myself a windows 8 upgrade license just before the introductory offer expired ($40 upgrade from windows 7 professional to windows 8 professional). Beneath all the UI layers and the new interface, there was one thing I was looking most forward to – client hyper-v.
For all the virtualization newbies out here, here’s a quick explanation of what type 1 (bare metal) and type 2 hypervisors mean – a type 1 hypervisor runs directly on top of the hardware. All other guest operating systems, including the management OS run on top of this layer. On the other hand, a type 2 hypervisor runs as an application within the management OS – the guests run within this layer. It’s quite evident from this that type-1 hypervisors are better off at managing system resources than the type-2 hypervisors.
Here’s a quick layout of my lab on VMware:
As you can see, the lab is a fair mix of windows, Linux and BSD guests. Here are the top five features I was looking to replicate in a hyper-v setup:
Support for a diverse mix of OS’s. Ability to work offline – i.e. ability to run the whole guest network even if the host does not have any network connectivity. Ability to connect USB devices directly to VM’s as required Ability to run a segmented network that does not impact my primary network. Some of the VM’s run active, network aware malware and I wouldn’t like them spread on the other devices on my network. Works with a variety or pre-distributed virtual machines from various sources. I set out to replicate this network on Hyper-v. I attribute the failure to the following two issues – very dismal support for Linux guests and a very funky program called vmconnect.exe.
Let’s get into the details shall we?
The first major issue I encountered was a very dismal support for Linux / BSD guests. Microsoft contributed hyper-v drivers back to the open source community and these drivers have been part of the kernel from version 2.6.32 onwards. These drivers add support for the ‘synthetic’ devices (network cards, storage and IO device drivers). My main focus was on the networking components and I was glad I could use the regular ‘synthetic’ network adapter on my Linux VM’s. That happiness was short lived.
The initial setup was done by creating two virtual switches – an external switch and an internal switch. By design, a hyper-v virtual switch offers three modes of operation – external, internal and private. The external switch routes traffic directly on to the physical network – meaning that any VM connected to the external switch should pick up an IP address from the router directly in the 192.168.1.0/24 subnet. An internal switch offers a slightly restricted mode, where communication is allowed between the VM’s and the management OS, but is not allowed on to the real network. On the other hand, a private switch allows communication between the VM’s only and does not allow communication between the VM’s and the managed hosts.
Another layer of complexity is that the management OS allows you to dedicate a physical NIC to an external switch, or allow the management OS to share the VM traffic coming through the switch with itself – effectively multiplexing the management OS traffic with the VM traffic.
The initial test consisted of two VM’s - Linux (Ubuntu 12.04 LTS 32 bit) and Windows 7 32 bit professional connected to an external switch. When powered on, the Windows VM got an IP address from the router without any problems – all was not ok on the Linux side. Try as I might, I was not able to get the Ubuntu VM to get an IP address. There were several recommendations to fix this, like bringing down the adapters and bringing them up again (ifconfig eth0 down; ifconfig eth0 up; dhclient eth0), but nothing worked. Running dmesg showed me that all the synthetic drivers were detected properly by the OS. I raised a thread on TechNet here – it has had about 250 views, but no responses yet!
Funny things were happening here – this scenario worked perfectly fine on a wired network. If I ran a network cable from my router to the laptop, both VM’s picked up the IP addresses perfectly. To satisfy the virtualization purists, I also dedicated a second wireless adapter exclusively to the switch – however, it did not work as well.
That means, I could not setup my pfsense instance – a core component of my lab was a no – go. (Hat-tip to Alex Appleton for re-building the BSD kernel with the hyper-v drivers – Terrific work here and here).
The second and the more annoying issue was the wonder called vmconnect.exe Firstly, it does not support USB pass through, meaning, you could not connect any USB device to the virtual machine directly. Secondly, the abysmal lack of support for widescreen resolutions – even windows would not run on anything other than a 4:3 resolution. When I tried to full screen the VM, it always displayed the ugly black bars. That means anything above 1024x768 was out of bounds.
The purists would recommend usage of remote desktop – both wide screen resolutions and USB pass through are well supported. However, there is a very big caveat! The primary requirement is that both the virtual machine and the host, from which the remote desktop connection is initiated, have to be on the same network. For a firewalled network setup like my lab, you can imagine how complicated the firewall rules start to become.
So, let’s do a quick recap shall we? Here were my requirements
Support for a diverse mix of OS’s. – Very poor support for Linux / BSD guests and for wireless cards. Ability to work offline – i.e. ability to run the whole guest network even if the host does not have any network connectivity. – Does not allow me to do so because both the guest and host need to be on a network. Ability to connect USB devices directly to VM’s as required – No support at all – RDP does not work for my requirements due to problems in points 1 and 2 Ability to run a segmented network that does not impact my primary network. Some of the VM’s run active, network aware malware and I wouldn’t like them spread on the other devices on my network. – Due to the above issues, it is not possible to run a segmented network. Works with a variety or pre-distributed virtual machines from various sources. – Most of the VM’s distributed are in the VMware (.vmdk or .ova) or oracle virtual box formats. No one (except maybe Microsoft) distributes test VM’s in .vhd format Hence my original tweet – the possibilities are fabulous, but the features need to grow up a lot more. My guess is that this was a last minute addition to the Windows 8 feature list and has not been thought through fully.
*All tests were done on standard hardware – both the wired and wireless cards were Intel cards with the latest drivers installed. Hard disk was a WD Scorpio black.