Abstract

As a tester it is critical to understand the impact of your actions. One way to accomplish this is to instrument a lab to analyze your attacks and tactics as you are developing them.

In today's article we will go over the infrastructure software selected for my port-a-lab, the design considerations, and the high level design. I will also call out some things I would have done differently if I were doing it again.

High level objectives:

• Design considerations & Software chosen
• High level design
• Lessons learned
• What's next?

Design considerations & Software chosen

For extensibility I wanted to run a bare metal hypervisor on my compute nodes. In the first iteration I ran Xen, this had some drawbacks such as being required to run windows hosts or use third party management software. I tried running it with Xen Orachestra, but all the super usable features were hidden behind license constraints. I also found it rather buggy and frequently had to resort to the windows client to rescue issues. WompWomp.mp3 Xen also did not play nicely with the amazon special usb ethernet adaptors upon which I heavily rely.

Next up I went with Proxmox. This decision was arbitrary, and heavily influenced by my friend Fuz3 saying "Hey dude, check this out". Why not vmware or $otherHypervisor? ¯\_(ツ)_/¯ Proxmox has an easy UI, just works, and played nicely with my USB ethernet... I stopped looking after that. Also I am trying to minimize cost as much as possible. So something that gets the job done and is feature rich without costing $ wins the day.

The firewall is running PFSense. Why not OPNSense? No real reason. I am not oppossed to changing it.

For DNS I have pihole with my active directory domains forwareded into the domain controlers.

For instrumentation and monitoring I am going with an ELK stack and security onion.

High level design

Lessons learned

A problem that was not obvious to me is that the hypervisor's virtual switch implementation means that when two guests on the same host talk to eachother that communication never leaves the host. This is pertnant when we move into instrumentation because it means our taps will not see all traffic. :-( We can mitigate this issue by ensuring that our traffic crosses hosts, but this is a bit of a pain in the ass to remember.

My plan of tapping with physical taps does constrain the maximum number of nodes I can run. Every node would need two times the number of nodes ethernet adaptors. At some point that would make sense to use a big boy tap such as gigamon, or some other dedicated hardware.

What's next?

Next up we will discuss the configuration and basic infrastructure build.