One of the best ways to acquire and maintain an offensive security skill set is to build a home lab and populate it with intentionally vulnerable machines. The most straightforward option is to simply spin up VMs in VirtualBox or VMWare Player and manage everything locally. To take things to the next level, however, you really need a hypervisor like ESXi or Proxmox. Nowadays, this kind of setup doesn’t have to be exclusive to the enterprise. Picking up an older Dell R710 on ebay, Craigslist, or through a reseller/rehabber isn’t nearly as soul-crushingly expensive as one might expect. Labgopher is a nice tool for keeping track of good deals on ebay.
Several years ago, we did a post on virtual networking in ESXi and pfSense. If those are your technological preferences, I highly recommend a read. My own lab environment, which I maintain for both personal use and university instruction, is built on Proxmox and Sophos UTM9. I use the UTM9 to organize the lab into segments by category (ie: web application vulnerabilities, remote code execution flaws, Windows domain practice, etc.) which makes things significantly easier to manage.
I should note that Sophos UTM9 will likely lose support at some point in the next several years as Sophos continues to emphasize the XG platform (which is also free). I just very much prefer the former to the latter and am determined to ride it out to the end.
Creating the UTM9 Virtual Machine
The UTM9 will sit at the virtual front door for your Proxmox lab and should be the first VM stood up once Proxmox is installed. To build a VM for the UTM, select ‘Create VM’ from the upper right hand corner of the Proxmox web-based management interface (see Figure 1). In addition to checking the box that will start the VM at boot, I strongly recommend labeling your VMs in an organized manner and also grouping the segments-to-be by VM IDs (see Figure 2). For example:
- 100s – Segment 1 – Infrastructure, VMs start with ’01-‘
- 200s – Segment 2 – Remote Code Execution, VMs start with ’02-‘
- 300s – Segment 3 – Web Application Vulnerabilities, VMs start with ’03-‘
- And so on…
This will save you headaches and eye strain when you end up with a lab of 100+ machines.
The operating system should be Linux, “5.x – 2.6 Kernel.” In order to get your UTM9 ISO to show up in the ‘ISO Image’ drop-down, you’ll need to SCP (or Filezilla) it to /var/lib/vz/template/iso on your Proxmox system (see Figure 3). The defaults in the ‘System’ tab can be left as they are. I recommend a virtual disk size of at least 60GB, and switch to IDE or SATA from SCSI which the UTM9 won’t recognize during the installation process. I use 2 sockets with 2 cores for the CPU and 4GB of RAM without any bottlenecking or slowdown issues.
I have run into problem with the ‘VirtIO (paravirtualized)’ NIC which is the default and recommend going with the’ E1000′ option. You can only add one at this stage, but you’ll need a minimum of two to complete the install. In the next section, we’ll step through getting the networking worked out in Proxmox so that additional NICs can be added with minimal fuss.
Proxmox Network Bridges
I find the virtual networking in Proxmox significantly more intuitive than ESXi. Everything is more or less managed from a single screen.
To get started, find your UTM9’s hostname on the left hand side of the screen under ‘Datacenter,’ and then select ‘Network’ under ‘System’ in the main window. There will be a list of the hardware Network Devices. I would recommend creating a ‘Linux Bridge’ for each using the ‘Create’ dropdown menu (see Figure 4). The bridges act like real switches and will allow you to ‘plug in’ VMs to connect to the hard lines. In my case, I am using two hardware NICs on the Proxmox machine:
- The first connects to my ‘corporate’ network and is the management interface
- The second connects to the ‘lab’ interface on my perimeter firewall and acts as the gateway for the entire lab
Your specific setup will depend on your available hardware and network architecture.
Next, you’ll need to create ‘OVS Bridges’ which will be the virtual switches that will connect your UTM9 to the other machines in the lab (see Figure 5). I would recommend creating as many as you anticipate up front in order to avoid multiple restarts of the Proxmox machine. These can align with the VM ID breakdown categories from the previous section:
- And so on…
You have the option to add IP information to the OVS Bridges though I have not done so and haven’t encountered any issues.
Once the bridges are created, select the UTM9 VM from the master list on the left. Go to its ‘Hardware’ tab, and find the ‘Network Device’ (there should only be one) and double-click to open its properties window. Select the appropriate bridge (assuming this will be your ‘WAN’ connection for the UTM9, go with the Linux Bridge that isn’t the Proxmox management interface).
To add your second NIC to the UTM9 VM, click the ‘Add’ dropdown menu, and select ‘Network Device’ (see Figure 6). It should be attached to the first of the OVS bridges (ie: 02_RCE). Now, you should be good to start the installation by starting the UTM9 VM.
I won’t step through the actual install process as there is an old series here on the War Room detailing the installation of the UTM9 (and nothing has changed since the original posting). Once your UTM9 is up and running (don’t forget to complete the setup using the web management interface), shut it down, and add another NIC through the same process as we just walked through. Attach it to the next OVS bridge in the list (it’s like plugging in a virtual network cable!). The setup process will have taken care of the first two, and I don’t recommend adding more than one at a time as there’s no good way to differentiate NICs (by MAC) in the UTM9’s web interface as best I can tell.
Once that’s complete, restart the VM, and log back into the web interface so we can finish adding the next segment (and ensure we’re keeping them all secure and separate).
Networking in the UTM
From the Dashboard, select ‘Interfaces & Routing’ from the left and then ‘Interfaces.’ Select ‘+ New Interface’ (see Figure 7). Find the right hardware in the dropdown menu (if you’ve been following along, there should only be one), name it similar to the attached NIC (ie: 02-RCE), and set a static address before saving. I would recommend using an IP address scheme that mirrors the labels you’ve chosen for the interfaces (ie: 10.0.2.0/24 for 02-RCE).
After the interface has been created and is marked as [Up] (you may need to click away first to get it to reload its status), go to the ‘Services’ tab on the left. Under DNS, add the new network (see Figure 8). The interface and broadcast values will also be available, but don’t select them. Next, move onto the ‘DHCP’ subsection. Add a new DHCP server, and select the new interface (see Figure 9). It should automatically fill out the appropriate range based on the IP and netmask you entered into the interface. Make any adjustments you want to any of the fields.
Finally, in order to make sure traffic will pass out of the new segment through the WAN interface, go to the ‘Network Protection’ tab on the left and select ‘NAT.’ Add a new Masquerading Rule, and choose the network for your new segment (see Figure 10). Finally, the interface should be the non-management hardware interface. Now, the VMs you drop into the newly created segment will have internet (if that’s how things are architected on your network).
I would recommend taking a look at our previously posted article on setting up rules and definitions to isolate your virtual segments from each other. You’ll want to make sure that machines in the WAN space can access all of the segments and vice versa. An even better option is to set up a VPN into the lab space and restrict access to and from the lab to the VPN address space.
Follow along with this old article to get an SSL VPN created within the UTM9.
At this point, you’re ready to start building your vulnerable VMs in Proxmox. There are several older posts on the War Room with some solid recommendations on getting started with that. Using docker containers from resources like Vulnhub are a great option too, though I would recommend going through full builds from OS install to software setup yourself as much as possible to get the hands-on experience and really understand what is going on underneath the hood.
Once you get a VM created, you simply have to select the correct network bridge from the dropdown menu for its network device properties (as described in the Proxmox Network Bridges section above).
Where appropriate, don’t forget to patch and update your systems (especially Proxmox and the UTM9). Obviously, don’t update machines that are intended to be vulnerable unless you are trying to force a particular flaw to the surface.
You can actually repeat this process with yet another virtual firewall instance and NAT through particular services (ie: OWA, SSH, web server) to simulate an external footprint and internal network. I’ll cover some of that in a follow-up post next month.