It’s been years since I had a working lab at home, and I’m finding myself ready to build a new one. Building and maintaining your security lab is less about being a security expert and more about wearing your Systems Administrator hat. Maybe even your shiny new devops hat! It takes work, and you better get used to it and get efficient about it. You want to spend your time doing security magicks, not wrestling with your VMs.

Developers already have a leg up in this regard if they are already using devops-y tools like Docker or Vagrant to quickly rebuild and share development environments as a VM. Modern Sysadmins also are learning these techniques. It’s worth getting a taste for it as a security professional as well. Don’t discredit blogs and articles from developers in this field.

The simplest lab will be installing a virtual hypervisor on your local workstation right now, and carving out a VM or two. You can always use your local system as the attacking box, and the VM guests as victims by allowing the host and guests to talk to each other. That’s all quick and dirty, but most of us don’t want to screw up our main box by testing weird things out on it, or vice versa screw up our lab that took hours and days to set up by doing something unexpected on our main box.

The second easiest route is to forage from your local company desktop and systems folks. Do they have old workstations being sold for cheap or thrown away? Do they have extra copies of old OS media they no longer need that you could use to install from? Even just having a few extra workstation-class systems on hand can be enough for a lab, even if they’re not powerful enough to run virtualization tools on.

But let’s say you’re ready for the next step. You want to stand up a virtualized pen testing lab. Below are some topics to think about and answer before getting started.

What is your purpose?
You might want to do some pen testing, which is probably the most typical use case of a security lab. But you might instead be looking to detonate malware or evaluate security tools in a controlled environment. Keep your use cases in mind when answering some of the following topics. For instance, detonating malware might mean you have a particular interest in keeping your guest VMs absolutely isolated!

Choose your hypervisor platform: Virtual Box, Hyper-V, VMWare, XenServer
Picking a platform you already know will probably help you get up and running more quickly. But you could take this chance to learn something new and pick an option outside of your comfortable zone, but plan for some extra learning time. All are pretty capable, though Hyper-V is still fighting to prove itself in the enterprise and VirtualBox is usually limited to small scale use like for our lab project. Learning VMWare and XenServer are things you can effectively add to a sysadmin resume. XenServer and VMware can be loaded onto bare metal, but Virtual Box will require an OS to install onto.

While the others have free versions you can use just fine, Hyper-V has extra considerations that you’ll want to check up on, such as what you can or cannot license through it for a server class Windows OS. Honestly, chances are you will want to use something other than Hyper-V. Exception: If your company already has a Software Assurance subscription in place with Microsoft, perhaps you can convince someone to ask about including a free license for Windows Server Datacenter that you can use.

Think about how many systems you’re going to want to have running at any one given time.
This will increase your hardware needs the more you want running. For an initial run at a lab, plan for 2-5 concurrent guests running at once (20+gb disks, 2-3GB RAM…)

Think about portability.
This may influence your hardware choices: beefy laptop versus an old server chassis or maybe a portable-ish box? Do you want to power this off and take it various places, or will this just be on your home network in a corner forever?

Think about network needs as this might invoke further work on a router/firewall or on the hypervisor of choice.

• Do you want your local network to talk to these VMs and vice versa? you probably don’t, but maybe you want to use a physical kali laptop as your attacker…
• Do you just want the VM network to talk out to the Internet? Some systems will want this for patching or apt-gets or to build them!
• Do you want granular control over any of the above? Extra work!
• Keep this item open as your answer might change based on what you want in your lab.

Think about initial VM inventory.

• an attacker box (or two: 1 linux and 1 windows)
• a victim box.

But for your victim box, do you want to load a system purposely built to be vulnerable to things (like metasploitable), or do you want to build more or less default-ish systems? By default-ish, I mean not just out of the box, but maybe also configured with typical settings and best practices as needed. Or more than likely a mix of the two.

Linux VMs are pretty easy. You download the distribution iso, install it, optionally update, and you’re good to do whatever you want next. You can even snapshot the installation for quicker builds later with really no issues.

Windows OS VMs are a different story. Windows isn’t free. You can download limited trials from Microsoft, but they will expire. You can get things like MSDN copies or freebies alongside Software Assurance subscriptions, but those are not really free for home users. It can also be problematic to clone a Windows VM snapshot into new systems, depending on what you need, and the license will still be expired. This means you need to think about how you want to refresh your Windows OS VMs, which means channeling your inner devops (deployment infrastructure), scripting (quick configurationgs), or documentation skills (notes to follow each time) to rebuild efficiently and accurately. You should also think about how to get hands on with older, unpatched OS versions, such as older 2008 R2. Grabbing media from your ops team is always a good source.

What might you want for Windows boxes?

• a server class
• a workstation class
• a domain controller (with DNS, DHCP, Active Directory, Group Policy)
• a domain computer member (server or workstation or both)
• a file server, FTP server, IIS web server all in one? (also think about populating your file server with files!)
• once configured, snapshotted, and think about what you’ll do in 181 days when the license is expired.
• later on, you might want to add security systems like a Splunk server, IDS/IPS, packet capture monitor, etc.

Think about your install media and how you plan to keep it updated. You probably want to carve some of your VM host storage for an ISO section where you can plop ISO images of installs and mount them from, or maybe an external drive you can attach. Also think about how often you will get new ISOs and how will you know a new version is available? How will you get old ones if you need something older than a particular date or patch?

Are there any VMs you want that are going to need to be built all devops-style? Take the install process for Metasploitable3, for instance. How will you refresh this? Where will you build it? You might have to learn some devops skills to manage this without busting your box on accident. Maybe have another system nearby you can build VMs inside, export them out, and then import them into your lab host in the ISO storage location.

All of this should pave the way towards planning, acquiring the hardware for, and beginning to build a pen testing security lab.