Building a Secure Cybersecurity Lab: A Journey of Isolation and Exploration

11 min readJun 3, 2023

Introduction

In an increasingly interconnected world, cybersecurity has become a paramount concern. As an avid learner and passionate about understanding the intricacies of cyber threats, I embarked on a journey to create my own cybersecurity research lab. In this blog post, I will share my experiences and insights on how I built a secure and isolated research lab separate from my home network. Join me as we dive into the world of cybersecurity exploration and innovation.

Securing Boundaries: VLAN Segmentation for Home-Lab Network Isolation

In the realm of cybersecurity research, isolation is a fundamental principle that ensures the integrity and security of your lab environment. By separating your lab from your home network, you minimize the risk of potential threats spreading beyond their intended boundaries. In this section, I will delve into the importance of isolation and explain how I achieved it in my cybersecurity research lab.

To create a clear separation between my lab and home network, I utilized various networking components and concepts, including a switch, two wireless access points (WAP), and an ISP router. One of the key concepts I employed was the use of Virtual Local Area Networks (VLANs).

VLANs: Virtual Local Area Networks

VLANs allow you to logically divide a physical network into multiple virtual networks. Each VLAN operates as an independent broadcast domain, effectively isolating the devices within it. By using VLANs, I created two separate networks: one for my home devices and another for my lab devices.

Access Ports, Trunk Ports, PVID, Tagged, and Untagged Ports

To implement VLANs effectively, it’s important to understand certain port configurations:

Access Ports: These ports are assigned to a specific VLAN and connect to devices that belong to that VLAN. Devices connected to access ports are unaware of VLAN tagging and communicate within their designated VLAN only.
Trunk Ports: Trunk ports are responsible for carrying traffic for multiple VLANs. They are typically connected between networking devices, such as switches and routers. Trunk ports use VLAN tagging to differentiate between VLANs, allowing traffic to flow between them.
PVID (Port VLAN ID): PVID is the VLAN assigned to an access port. Incoming untagged frames on an access port are associated with the VLAN specified by its PVID.
Tagged and Untagged Ports: In a VLAN configuration, ports can be either tagged or untagged. Tagged ports transmit frames with VLAN tags, indicating which VLAN the frames belong to. Untagged ports, on the other hand, do not include VLAN tags in their transmitted frames.

The purpose of a tagged or “trunked” port is to pass traffic for multiple VLAN’s, whereas an untagged or “access” port accepts traffic for only a single VLAN. Generally speaking, trunk ports will link switches, and access ports will link to end devices.

To better understand VLAN setup, including access ports, trunk ports, PVID, tagged and untagged ports, I recommend reading this comprehensive guide by Steve on their blog: https://stevessmarthomeguide.com/vlans-home-networks/#:~:text=VLANS%20or%20Virtual%20LANS%20is,communicate%20with%20any%20other%20device.

This blog post provides a detailed explanation of VLAN concepts and their implementation, making it a valuable resource for anyone looking to set up VLANs in their network.

Network Diagram

To give you a visual representation of how I implemented VLANs and designed the network for my cybersecurity research lab, here is a simplified network diagram:

By implementing VLANs based on the principles outlined in Steve smart home guide blog post and leveraging the appropriate network equipment, I successfully achieved the necessary isolation for my cybersecurity research lab. This separation ensured that my lab remained protected from potential threats and allowed me to conduct experiments, analyze threats, and explore cybersecurity innovations in a controlled and secure environment.

I have utilized two routers for my home and lab networks, deactivating DHCP in both devices to function as wireless access points (WAPs). One router is designated for the home network, while the other serves the lab network. To prevent accidental wireless connections, I disabled SSID broadcast on the ISP modem, as both VLANs have access to it. To enhance the security of this network configuration, incorporating a dedicated firewall would be advantageous.

Building the Foundation: Setting up the Lab for Cybersecurity Research

When it comes to setting up a robust and secure cybersecurity lab, it’s essential to have the right hardware and software in place.

Hardware Requirements

To ensure optimal performance and a smooth experience while setting up your cybersecurity lab, it is important to meet certain hardware requirements. Here are the recommended specifications based on your given setup:

CPU: Intel/AMD Processor 8 Cores (Atleast 4 core CPU)

RAM: 24 GB (32 GB Recommended)

Storage: 512 GB SSD/HDD (SSD Recommended)

Meeting these hardware requirements ensures that your cybersecurity lab operates efficiently, minimizing I/O delays, and delivering a responsive user experience. It is important to note that upgrading to 24 GB of RAM and utilizing at least one SSD for storage will significantly enhance the performance and usability of your lab.

Installing Proxmox: Unlocking the Power of Virtualization

To harness the full potential of your cybersecurity lab, it is essential to install a virtualization platform like Proxmox.

You can check out this helpful YouTube video by NetworkChuck that provides a step-by-step tutorial on installing Proxmox: NetworkChuck — Proxmox Installation Tutorial

By configuring a static IP, such as 192.168.1.100, you ensure stable connectivity and easy access for remote management. Customize the IP address, subnet mask, default gateway, and DNS settings according to your specific network requirements.

Configuring Storage for VMs and Backup: Utilizing Different Storage Resources

So, let me walk you through how I configured the storage components for my cybersecurity lab. I wanted to ensure optimal performance and data protection, so I allocated specific resources for virtual machines (VMs) and backups. Here’s what I did:

First, I dedicated a high-performance 1TB M.2 SSD (Internal) specifically for hosting the virtual machine disks. This SSD offers fast read and write operations, allowing me to run multiple VMs simultaneously without any performance issues.

Next, I set aside a separate 1TB HDD (External) for storing backups. Having a dedicated backup storage ensures data redundancy and backup integrity. This way, I can easily restore critical data in case of unexpected incidents or system failures.

In terms of ISO images used for VM installations, I opted to store them on the drive (local) where proxmox is installed.

Setting up the Network for VMs: Creating LAN and WAN Interfaces

To enable connectivity and networking capabilities for the virtual machines (VMs) in your cybersecurity lab, you have to establish a network configuration that includes a LAN interface and a WAN interface. Let’s dive into how you set up the network for your VMs:

LAN Interface: In order to create a local area network (LAN) specifically for your lab, you created a new linux bridge called vmbr1. This interface acts as the LAN interface, allowing communication and data transfer among the VMs within your lab environment. By designating a separate LAN interface, you can isolate your lab network from the external network and ensure the security and integrity of your research and experimentation.
WAN Interface: To provide connectivity to the outside world and access resources beyond your lab environment, you utilized the default Linux bridge interface, vmbr0, as the wide area network (WAN) interface. This interface serves as the gateway to the external network, enabling VMs to connect to the internet, access external services, and communicate with resources outside your lab. By separating the LAN and WAN interfaces, you maintain control over network traffic and effectively manage communication between your lab and the external network.

By configuring the LAN and WAN interfaces in this manner, you create a network environment that supports both local communication among the lab VMs and connectivity to the wider network. The LAN interface, vmbr1, facilitates secure and isolated communication within the lab, while the WAN interface, vmbr0, ensures connectivity to the external network and the internet.

Setting up VMs for Lab

To establish Active Directory (AD) integration in your lab environment, several machines need to connect to the AD domain controller. Follow the steps below to configure AD and join the respective machines:

Configure pfSense Router:

To serve as the central router and firewall for your lab, you set up a Pfsense VM
Set the IP address of the domain controller (172.16.16.100) as the primary DNS server on the pfSense router.
Use 8.8.8.8 as the secondary DNS server to ensure external DNS resolution.
Refer to this YouTube video by divgital for a detailed guide on setting up pfSense on proxmox.

2. Configure Active Directory and DNS Server:

Set up the Windows Server VM as a Domain Controller and configure it as a DNS server.
Refer to this YouTube video by MSFT WebCast for a detailed guide on configuring Active Directory.

3. Join Windows and Linux Machines to the AD Domain:

You’ve set up Windows and Linux VMs to act as user workstations within your lab.
Follow the instructions provided in these YouTube video by Proffessor Andrew and Nerd on the Street to join Windows and Linux machines to the AD domain.

4. Install and Set Up ELK Stack and Fleet Server:

Install the ELK stack on one Ubuntu server, and install Fleet Server on another Ubuntu server.
Follow the installation and setup instructions provided in this YouTube video by IppSec.

5. Set Up ELK and Fleet Server:

Two Ubuntu servers have been provisioned in your lab. The first Ubuntu server is dedicated to hosting Fleet Server, which manages and orchestrates Elastic agents. Fleet Server enables centralized management, monitoring, and control of Elastic agents across the lab network. The second Ubuntu server hosts the ELK stack, which stands for Elasticsearch, Logstash, and Kibana. ELK stack is utilized for Security Information and Event Management (SIEM) purposes, providing advanced log analysis, threat detection, and visualization capabilities.
Configure Elastic agents on each host (Windows and Linux machines) to communicate with Fleet Server.
Create seperate agent policies for windows and linux machines. I have added windows integration to windows agent policy and auditd integration to linux agent policy.
Refer to the steps demonstrated in this YouTube video by Offensive Kernal for installing and setting up elastic agents.

It is important to configure the network interfaces correctly for each VM. Ensure that all the VMs, except for Pfsense, are connected to the vmbr1 interface, which serves as the LAN interface for your lab network. This enables seamless communication and data transfer among the VMs within the lab environment.

For Pfsense, it should be configured to have both vmbr0 and vmbr1 interfaces. The vmbr0 interface acts as the WAN interface, connecting Pfsense to the external network and providing internet access to the lab network. The vmbr1 interface, on the other hand, connects Pfsense to the LAN, allowing it to manage the internal lab network and enforce firewall rules and security policies.

Fixing Fleet Server Offline Issue and Automating Elastic Agent Restart (The fix should be in 8.9.0)

If you’ve encountered the issue of Fleet Server going offline after a reboot, there is a solution that can help ensure its smooth operation. By following the steps below, you can resolve this issue and automate the restart of Elastic Agent after a reboot:

Identify the Issue:

While troubleshooting the Fleet Server offline problem, you came across a helpful GitHub discussion. You can find the discussion here: GitHub Discussion: Fleet-server Agent gets into offline state on machine reboot.
Through this discussion, you discovered that restarting the Elastic Agent in the Fleet Server resolves the offline issue. However, you need to perform this step manually after each reboot.

2. Automate Elastic Agent Restart:

To automate the process of restarting the Elastic Agent service after a reboot, you can create a cronjob.
Cron is a time-based job scheduler in Unix-like operating systems. It allows you to schedule commands or scripts to run automatically at predefined intervals.
Create a cronjob that executes the command to restart the Elastic Agent service 1 minute after the system reboots.

3. Configure the Cronjob:

Open the crontab file using the command: sudo crontab -e
Add the following line to the file:

@reboot sleep 60 && systemctl restart elastic-agent.service

Save and exit the file.

By setting up this cronjob, the Elastic Agent service will automatically restart 1 minute after each system reboot, ensuring that Fleet Server remains online without manual intervention.

Please note that the above solution is based on the information and discussions found in the GitHub thread you mentioned. It’s always recommended to refer to the latest documentation and community discussions for any updates or alternative solutions related to this issue.

By implementing this automated solution, you can address the Fleet Server offline problem and ensure the seamless functioning of your Elastic Agents within the Fleet Server environment.

Setting up XDR for lab using Wazuh

XDR, or Extended Detection and Response, is a game-changer in cybersecurity. Unlike traditional tools, XDR integrates data from across an organization’s IT infrastructure to provide a unified and proactive threat detection system. Using advanced analytics and automation, XDR not only detects known threats but adapts to emerging risks, offering a comprehensive defense strategy against the evolving cyber threat landscape.

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts.

Steps:

Provision a new ubuntu VM in your lab with 4 vCPU and 8GB RAM.
Install and configure wazuh as demonstrated in this YouTube video by John Hammond.
Configure Wazuh agents on each host to communicate with XDR server.
Configure Elastic agents on XDR Server to communicate with fleet server.

Remember, the journey doesn’t end here. It is just the beginning of a lifelong pursuit of cybersecurity excellence. So, keep exploring, keep pushing boundaries, and keep making a positive impact in the realm of cybersecurity.
Thank you for joining me on this journey of building a secure cybersecurity research lab. Together, let’s continue to strengthen our knowledge, skills, and defenses to make the digital world a safer place.
Feel free to connect with me on LinkedIn or visit my website.
Happy researching and stay secure!