Project Fur-Tress: Building a Home SOC Lab (Part 3)
Introduction
In Part 2 of Project Fur-tress, I successfully set up a Debian VM as the management device for my pfSense firewall and VLANs. After configuring the VLANs, interfaces, DHCP servers, and firewall rules, I ensured the management device was correctly integrated and connected to the internet.
In this section, I will set up a Kali Linux VM in the Fake Internet VLAN to simulate external threats and test the security settings of the Corporate LAN VLAN. This step is crucial for gathering logs and data, which will be invaluable once the project is fully operational. Additionally, I will configure a Windows Server 2019 Evaluation VM in the Corporate LAN VLAN to serve as the Domain Controller, managing Active Directory, DNS, and DHCP services for the Corporate network.
Let's dive into the next phase of building and fortifying Project Fur-Tress!
Kali Linux
What is Kali Linux?
Kali Linux is a comprehensive, free, and open-source platform for penetration testing and security assessments. It comes equipped with a vast array of tools and utilities designed to help assess and report on the security of devices and systems. Based on Debian, Kali Linux is one of the primary go-to distributions for cybersecurity professionals and enthusiasts who aim to maximize the potential of their security testing systems.
With its user-friendly interface and extensive toolset, including utilities for network scanning, vulnerability assessment, and forensic analysis, Kali Linux provides a versatile and powerful environment for both experienced professionals and those new to cybersecurity testing.
Getting Kali Running
Before installing Kali, I created the VM and provisioned it with a 120 GB disk drive, 2 vCPUs, 4 GB RAM, and set the network bridge to vmbr5 with VLAN Tag 10. Since Kali is based on Debian, the installation process was familiar and straightforward. I left the hostname as 'kali' and didn’t set a domain name, as this device will act as an 'external threat' on the network. Following a similar process to the Debian install, I created a user, set the password, and proceeded with the installation. I left the software selection as the default options and let the installation complete.
Once the installation was finished, I rebooted, logged in, and verified the internet connection and IP configuration. With successful results, Kali was installed and ready for use.
ping -c 4 8.8.8.8
ip -br -4 a
Windows Server 2019
To set up the domain controller within the Corporate LAN VLAN, I used an evaluation version of Windows Server 2019, provided by Microsoft. This evaluation version is valid for around 180 days, which is sufficient for my project. After downloading the Windows ISO, I created the VM in Proxmox similarly to the other VMs, but with a few exceptions: I set the Guest OS type to 'Microsoft Windows' and the version to '10/2016/2019'. I allocated 64 GB of storage, 2 vCPUs, 4 GB RAM, and set the VLAN Tag to 20 on vmbr5.
The Windows Server installation process was standard—selecting the language, regional format, and keyboard locale. I chose to install Windows Server 2019 Standard Evaluation with the GUI. After setting the Admin password, I logged in and installed the VirtIO drivers to ensure access to devices and peripherals from the Proxmox environment. With the drivers installed, I restarted the server.
Configuring Network and Hostname
With Windows installed, I needed to configure the network settings and hostname before setting up the domain controller. In the Network and Sharing Center, I changed the adapter settings, configured the IPv4 properties with a static IP address (10.10.20.2), subnet mask (255.255.255.0), default gateway (10.10.20.254), and set the preferred DNS server to the gateway IP.
Next, I went to Control Panel > System and clicked 'Change Settings' next to the computer name. I entered 'Fur-tress Domain Controller 1' in the description box, set the computer name to 'FDC01', and clicked 'OK'. After the necessary restart, I verified the changes.
Windows would need to restart to apply these changes, but once it had, and I was logged in again, I could verify that the changes had taken effect.
Roles and Features
To set up Windows as a domain controller, manage Active Directory, and provide DNS and DHCP services, I needed to add specific roles and features. From the Server Manager Dashboard, I selected Manage > Add Roles and Features. In the wizard, I selected the following roles:
- Active Directory Domain Services
- DHCP Server
- DNS Server
- File and Storage Services/File and iSCSI Services/File Server
- Remote Access
I also enabled SMB 1.0/CIFS File Sharing Supports under the Features tab. Although SMBv1 is generally not recommended due to vulnerabilities, I enabled it temporarily for logging and security tool analysis. I continued through the wizard and selected 'DirectAccess and VPN (RAS)' under Role Services for Remote Access. After installing the roles and features, I restarted the server.
Setting Up the Domain Controller
To promote the server to a domain controller, I selected the notification from Server Manager and opened the Active Directory Domain Services Configuration Wizard. I chose to add a new forest, entered the domain name 'fur-tress.soc', and set a password for the Directory Services Restore Mode. I continued through the settings and let the installation proceed. After the automatic restart, Windows was configured as the domain controller.
Configure the DHCP Server
After the server had been promoted to a domain controller, my next task was to set up the DHCP server on Windows Server. Since pfSense was currently acting as the DHCP server for the 10.10.20.0/24 subnet, I needed to disable it to avoid conflicts and ensure systems don't attempt to respond to both DHCP servers.
I logged into the pfSense web configurator, navigated to Services > DHCP Server, and disabled the DHCP server on the CORPORATE_LAN_VLAN20 interface, applying the changes.
Back in the Server Manager Dashboard, I went to Tools > DHCP to start the configuration. In the tree view on the left, I expanded my system name and right-clicked on IPv4 to add a new scope.
I set the name as corporate_lan and the description to Corporate LAN Network, then clicked next. I configured the IP address range to match what I had been using in pfSense: from 10.10.20.50 to 10.10.20.100, with a subnet mask of 255.255.255.0.
I didn't enter any exclusions or delays, leaving the lease duration at the default 8 days. When prompted to configure the DHCP options, I selected yes and continued.
The default gateway was set to the IP address of my Windows server, 10.10.20.2. The domain name and DNS server settings were already correctly populated, with the WINS server set to 10.10.20.2.
After finishing and activating the scope, I confirmed that it was applied to the Address Pool in the DHCP tool.
Setting DNS
To configure DNS, I opened the DNS Manager from Tools > DNS in the Server Manager Dashboard, and expanded FDC01 in the tree view. First, I created a reverse lookup zone so IP addresses could be mapped back to domain names.
Right-clicking on Reverse Lookup Zones and selecting New Zone opened the wizard. I clicked through the default options until I reached the network ID entry. I entered 10.10.20, then completed the wizard. The new entry appeared in the reverse lookup zones.
Next, under Forward Lookup Zones, I expanded and right-clicked on my domain name to add a New Host (A or AAAA) record. This allowed DNS to map the IP address to the domain name, enabling me to access the pfSense configuration from a domain name.
I verified access to pfSense through https://firewall.fur-tress.soc and checked the nslookup results for the pfSense IP address.
Everything looked good. The nslookup did report "Server Unknown" with Address ::1, but this was expected since IPv6 is not set up in the network.
Summary
In this part of Project Fur-Tress, I set up a Kali Linux VM within the Fake Internet VLAN, ready to act as an 'external threat' for testing security settings on the Corporate LAN. For the Corporate LAN VLAN, I installed Windows Server 2019, promoted it to a domain controller, and configured it to handle DNS and DHCP services, ensuring seamless network management.
Looking ahead, further configurations on the Windows Server will include setting up static routes, creating domain users and groups, implementing Group Policy settings for security, and configuring shared folders and remote access. These steps will enhance the realism of the lab environment, making it a robust platform for cybersecurity testing and learning.