Step 1: Lab Design and Architecture
This page covers the first step in building a cybersecurity home lab, which involves selecting hardware, as well as designing and a lab network architecture.
The first step in building your own cybersecurity home lab is to carefully select the hardware that will be used. This requires a thorough understanding of the various components that make up a computer system, such as the processor, RAM, and storage devices. While it is certainly possible to run VMware ESXi on almost any hardware, it is important to ensure that your hardware meets the minimum requirements to run the hypervisor and the virtual machines that will be running on it.
Hardware
So, I was thinking about what to do with this old Intel NUC that had been gathering dust. After some research, I decided to go with VMware ESXi as my hypervisor. The installation process was actually pretty easy and is explained in the "Building a Base-Metal (Tier 1) Hypervisor - VMware ESXi 8.0" section. But before I could start the installation process, I had to make sure the hardware requirements for VMware ESXi were met. This meant checking the CPU, RAM, and storage requirements, and making sure the Intel NUC was on the compatibility list.
Once I confirmed that my Intel NUC was compatible with VMware ESXi, I started the installation process. This involved downloading the installation ISO, creating a bootable USB drive, and booting the Intel NUC from the USB drive. Then, I just followed the step-by-step instructions to install VMware ESXi on the host machine and create a virtual Windows machine on the hypervisor. Piece of cake!
| Hardware | CPU | RAM | Storage | NIC’s | Virtualization |
|---|---|---|---|---|---|
Intel NUC (Skull Canyon) | Intel i7-8705G | 32GB | 1x 250GB 1x 2TB | 2 | VMware ESXi 8 |
Networking
The primary aim of this lab is to demonstrate the usefulness of combining the Penetration Testing, Forensics, and SOC lab types. Each of these lab types are designed to address different aspects of security, and by combining them, we can gain a more holistic understanding of how to best secure our systems. In order to achieve this, we have set up the lab in such a way that each lab type resides in its own subnet.
To facilitate communication between the different subnets, we have made use of ESXi virtual networking. This allows us to create virtual switches (vSwitches) and associated Port Groups, which can be used to connect different virtual machines to different subnets. As shown in the table below, we have created several vSwitches to enable the network configuration.
| Network (vSwitch) | Port Group | IP/CIDR | Description |
|---|---|---|---|
vSwitch0 | Management Network | 192.168.1.1/24 | ESXi Connection to home network for management. |
LabNet | labnet | 192.168.1.1/24 | Second uplink connection for managing Virtual Machine (VM) connectivity through a Gateway/Firewall. |
Droid | droid | 10.10.10.1/24 | The Droid network acts as the management network where SOC centric hosts and tooling will be hosted, network traffic and host telemetry will primarily be sourced from the Rebel network. |
Jedi | jedi | 10.10.20.1/24 | The Jedi network subnet contains DFIR centric distributions and tools for performing forensics and malware analysis. |
Empire | empire | 10.10.30.1/24 | The Empire network contains the penetration testing distributions and tools for attacking the victim Rebel network. |
Rebel | rebel | 10.10.40.1/24 | The Rebel network is a simulated domain consisting of an AD server, Windows endpoint and intentionally vulnerable distributions, ports, and services. |
In order to ensure that our lab hosts are secure, we will be deploying the OPNsense gateway/firewall. This will allow us to segment the network and control inbound and outbound connections in a more effective way. By doing so, we can ensure that only the appropriate traffic is allowed through, while blocking any malicious or potentially harmful activities from reaching your home network and devices.
While there are other solutions available, such as pfSense, it is very similar to OPNsense, in fact both are built on the same BSD operating system (FreeBSD). Despite this, I personally prefer using OPNsense due to its user-friendly interface and ease of use. Additionally, the community support for OPNsense is quite active, meaning that if any issues arise, we will be able to find a solution quickly and easily. All in all, deploying OPNsense will allow us to have a more secure and reliable lab environment.
Environment Topology
Now that we have the hardware and network design planned, we can begin to think about the hosts that will be used in our lab. The hosts will be running various operating systems and applications, such as Windows, Kali Linux, and Metasploitable. These will be used to simulate different types of attacks and to test various security tools and techniques.
For our lab, we will be using the following hosts:
Windows Server 2022 Domain Controller (DC)
Windows 10 Workstation
Kali Linux
OPNsense Firewall
Metasploitable 2 Vulnerable Linux Server
SIFT Workstation
Security Onion
Each of these hosts will be connected to separate virtual switches and subnets, as outlined in the previous section.
Network Diagram
The network diagram for our lab environment is shown below. As you can see, we have segmented the lab into different subnets, each with its own virtual switch and associated hosts. The OPNsense firewall is used to control traffic between the different subnets, ensuring that only the appropriate traffic is allowed through.
Last updated
