Wednesday, July 1, 2015

Setting Up Your Playground

This post is not strictly information security related, but it will help set the foundation for exploration going forward.  In addition to being passionate about information security, I am also passionate about systems architecture and figuring out how to put the pieces together to come up with a solution.

The question I needed an answer to was:

How should I set up my home lab?


In order to practice techniques as well as explore new ones, I wanted to set up a virtual playground.  The reason for this was two fold: I wanted to have a bunch of machines I could tinker with without having to worry about unleashing malware on my daily computer and every other computer in my network.  I also did not want to buy a bunch of systems.  Besides the initial hardware costs, there cost money to power, they make noise, and they take up space.  So, the obvious answer is virtualization.  Virtualization allows you to host a number of virtual machines on one or more "bare metal" computers.  Virtualization works by abstracting hardware and allowing the user to run virtual instances of various systems (called virtual machines). These virtual machines run on top of the "bare metal" on what is called a hypervisor.  The hypervisor is responsible for providing the environment for the virtual machines to run in and coordinating resource usage among those virtual machines.



So where to start?

First, we need to choose a hypervisor.  Hypervisors generally fall into two categories: Type 1 and Type 2.  Type 1 hypervisors run directly on the bare metal.  Examples of Type 1 hypervisors include VMware ESXi and Microsoft HyperV Server.  Both of these are free, though management might not be.  More on that later.  Type 2 hypervisors, also known as hosted hypervisors, run on top of an operating system like Linux or Windows.  Examples of Type 2 hypervisors include Oracle VirtualBox, VMware Workstation, and Parallels Desktop.  The first is free, the final two cost money.

The hypervisor you choose depends on what hardware you have available to host it and what you want to do with it.  I had a spare computer that I was using as a NAS sitting around that I decided to convert into a virtualization box.  It was not very powerful, but you do not need a huge, loud rack mounted server with 72 cores and hundreds of gigabytes of RAM to play around.  You can set up something like this with less than 50GB of hard drive space and 6GB of RAM:
  • A Windows Client, like Windows 8.1.  20GB of hard drive space, 2GB of RAM
  • Windows Server, like 2012 R2. 20GB of hard drive space and 2GB of RAM
  • Kali (a bootable / live Linux distribution loaded with security tools).  3GB of space for the bootable CD (ISO) and 1GB of RAM
Of course, you are not going to do anything crazy with an environment like that, but it will allow you to play around a bit.

If you do not have a spare computer to use, then a Type 2 Hypervisor would be best.  I like VirtualBox because it is free, supports snapshots, and works well enough.  Snapshots allow to freeze a virtual machine at a specific moment in time that you can revert to later on.  So if you screw up, you can revert to that snapshot and you are good to go.  If there is interest in a post on setting up VirtualBox, I could put one together.  Let me know.

If you have a spare computer that you are willing to sacrifice to become a virtualization host or you are building or buying a new server specifically for the task, I would choose a Type 1 hypervisor.  Type 1 hypervisors have less overhead than Type 2 hypervisors because they have a minimal operating system under them.  Type 2 hypervisors run on top of a full installation of Windows, Linux, or OS X.  The choice of Type 1 hypervisor is a bit tougher than Type 2 hypervisor because both ESXi and HyperV server are good enough for a home lab.  There are other hypervisors like KVM (part of the Linux kernel) and Xen which straddle the line between Type 1 and 2 because they are generally on top of a Linux install.  They are viable options as well, and if you want to try KVM, Proxmox is a good choice.  It simplifies management of KVM virtual machines.

For the purposes of this post, we will talk about either ESXi or HyperV when it comes to Type 1 hypervisors.  Each has its pros and cons.  Here are some of them.


ESXi

Pros
  • Free
  • Tried and true.  ESXi has been around in various forms for a long time now and supports lots of different operating systems.
  • Since it has been around a while, there is a lot of information out there if you get stuck.
Cons
  • Advanced features (like clustering (pooling the resources of multiple machines together) and vMotion (moving a live VM from one machine to another)) require a license for vSphere Management Server which can be costly.
  • Managing all of the features of virtual machines in newer versions of ESXi (> 5.1) requires vSphere (or the vCenter Server Appliance)
  • Free management client (vSphere Client) only works in Windows.
  • ESXi can be picky with hardware.  If it is not on the VMware Hardware Compatibility List (HCL), it might not work.  A prominent example of this is that VMware removed the Realtek 8111 driver (a popular embedded NIC on consumer motherboards) from ESXi 5.5 and onwards.
HyperV

Pros
  • Free
  • Advanced features such as virtual machine migration and clustering are free.
  • If your business already has Windows licenses, you could run Server 2012 R2, install the HyperV role and get Windows client licenses.
Cons
  • Management with first party tools requires a client version of Windows that "matches" the server.  For example, HyperV Server 2012 requires a Windows 8.1 to manage it.
  • For the free version (HyperV Server), some management must be done from the command line.  This is not really a huge deal, but it might be for some.
  • Linux and BSD support is pretty good, but you might run into issues with older versions of the Linux or BSD kernels.
For a homelab with a single server, you cannot really go wrong with either.  If you decide to go with ESXi, there is one gotcha that I want to let you know about if you are going to install from a USB flash drive.  There are instructions on VMware's site on how to do it here.  However, these will not work if you are using a new Linux with syslinux newer than 4.03.  My system had 6.03 on it, and when I followed the instructions, it worked until I tried to boot from the drive.  I got errors about "Loading -c failed".  You can solve this by using an old version of Syslinux (like 3.86), available here.  If you are using Windows, Rufus works really well for this.

With HyperV Server, managing it can be tricky without a domain.  In order to manage it, hvremote is a great script to help configure the client and server.  Besides opening the appropriate ports on the firewall on both the client and server (hvremote helps with this), keep the following in mind:
  • Add a DNS entry for the HyperV server to the DNS server or into the hosts file (C:\Windows\System32\drivers\etc\hosts).  HyperV Management seems to rely on hostnames, so IPs will not work directly.  You can edit the hosts with a text editor like Notepad or Notepad++.  Remember to run your editor as Administrator because the file is only writable by Administrators.  Simply add a line at the bottom that looks like this:
    • <IP of the server> <host name of the server>
    • Example: 192.168.1.100 hypervserv
  • You do not need RSAT to manage HyperV Server 2012 R2.  You can install the HyperV Management Tools from "Programs and Features" > Turn Windows Features On and Off, as in this screenshot:
  • Without a domain, the traditional guidance is to add a local administrator to your HyperV server that has the same user name and password as the user account you are using to manage the server from your client.  I do not think this is a particularly good idea.  Fortunately, you can store the credentials using this command:
    • cmdkey /add remoteserver /user:remoteserver\username /pass
    • where remoteserver is the hostname of your HyperV server, username will be Administrator
  • Be sure to grant Remote Anonymous DCOM access on the client.  With hvremote, you can do this with one command instead of going through the GUI: cscript hvremote.wsf /anondcom:grant  The idea is that when the server tries to communicate back with you, it needs to run commands on your machine.  I feel like this is a bad idea because nothing should be allowed to communicate that way across the network.  If anyone knows of a better way to accomplish this without a domain, please let me know.
Once you have your environment set up, you can download evaluations of Windows products if you do not have spare licenses around.  They are good for 90 days and will be good enough to play around with:
 Once you have an environment set up, you can start playing around which we will do soon.  If you need help, feel free to leave a comment.

No comments:

Post a Comment