iCyberDefend Detection and Attack Lab: Part I
Detection and Attack Lab
Through the steps taken, I successfully created an environment consisting of a wide-area network, a local-area network, an attacking host, 3 vulnerable target hosts, a Layer 2 switch, and an active directory host, Graylog SIEM, and a pfSense firewall that I securely configured before host OS with secure network configurations were installed. This allowed me to create a scalable virtualized environment with the ability to perform pen-testing techniques, attack simulations, and perform detections on each vulnerable host. Detection capability provided options for using SIEMs, Sysmon event viewer, and Graylog, which I installed and configured, performing vulnerability scans with Tenable Nessus. All virtual machines deployed are through the VirtualBox Manager with the most up-to-date Virtual Box Extension Pack installed (VMware and Hyper-V are viable options to conduct this lab). Before installations, I mapped the network I created with a topology diagram tool for reference called GNS3 and Visual Paradigm Online, both available for free. This is what I call the iCyberDefend detection and attack lab.
Part 1: pfSense Firewall Setup & Configurations
To control the traffic in or out of the networks, 4 virtual adapters are configured for the wide area network, a LAN for the target hosts, an isolated subnet for the attack host, and an active directory server.
Installation consisted of downloading a pfSense ISO file based on my host, Windows, and decompressing it using 7-zip (Most 3rd party zip tools should work). This decompression extracted the GZ file to an ISO file. Once installed, the network adapters are configured for internal and external networking. For secure best practice, the audio and USB interfaces are disabled. Any unused interfaces or processes are disabled for media protection and secure hardening throughout this lab. Each virtual network interface has network configurations using IPv4 network addressing and subnet mask. The LAN static IP address is configured first, then the isolated LAN, then the active directory LAN. Then I moved on to configuring pfSense firewall rules using a Kali VM to avoid exposing the firewall to external threats.
Part 2: Configuring pfSense Rules with Kali
Attaching the Kali VM to the pfSense LAN before installation allows the VM to be addressed to the internal network. With the Kali GNU up, I immediately changed the root password for security purposes. Again, after logging into the pfSense web portal, I changed the admin account password, disabled it, and created a user account with admin privileges as a secure best practice.
Next, I updated the hostname, and domain name, and “Override DNS” gets disabled since the firewall is configured through the Kali VM. The RFC1918 setting blocks private networks. The WAN that was created is private so this needs to be disabled as well. I could also update the interface name descriptions to a more organized and recognizable name, such as Isolated = Opt1. DHCP registration and static DHCP are enabled because the networks are private and I already set each interface IPv4 addressing in Part 1. Prefetch message cache and prefetching DNS keys are applied. Thus I can begin providing my Kali VM with a static DHCP lease by entering an IP address under the edgerunner“Static DHCP Mapping on LAN” section.
An alias must be implemented for RF1918 and Kali before I put in rules for the Isolated, LAN, and Active Directory host for private address blocking. Hardware checksum offloading is enabled under System > Networking > “Network Interfaces” section. Once the rules are input, such as blocking access to all other addresses external to the host OS, I can use the “ip a” command to pull the Kali IPv4 address. I learned that rules are read top to bottom, so any new private IPv4 addresses need to be above RFC1918’s firewall rules. Now this did not run smoothly when I mistakenly cleared the DHCP leases and I had to restore a previous configuration and wait a couple hours for the DHCP to refresh. I also forced the IP release and renewal in the Kali VM CLI.
Part 3: Vulnerable VMs
Three vulnerable hosts are installed on the network, a vulnerable Windows 10 target machine, Windows 10 Enterprise Active Directory build, Mr. Robot, Metasploitable 2, and DVWA (Damn Vulnerable Web Application). The isolated network interface is the residence of these virtual environments. With networks configured, I ping each host’s IP address to confirm they are connected and responding. Any external address pings should come back with an error or unreachable. Also, I took snapshots of each host and the firewall in case something went wrong and I needed a working baseline recovery state.
Part 4: Active Directory Build
I downloaded the Windows Server 2019 ISO as well since a domain controller is necessary for a successful active directory build here. Whenever I want to attack the AD target I must put the Kali machine on the same LAN as the AD Lab network. The DHCP is disabled on the pfSense for the domain controller to be configured as the DHCP server. After inputting the static IPv4 addresses in network adapter properties, I renamed the server to note that it is a domain controller. After restarting, I installed AD Domain Services and DNS services.
Moving forward, the Enterprise Certificate Authority had to be enabled and configured for the role, while defaulting the CA Name and private key information. Configuring DNS forwarders was a complex set of configurations because pfSense had to be the default gateway for unknown hostnames. The domain controller housing the DNS server was my resolver. Also, a DHCP server had to be set up so the other AD_LAB Windows host could resolve and receive an IP address. With all that said and done, a domain administrator account would only be right. The final portion of this build is a set of users for the lab and joining the virtual hosts to the domain controller. Thus a small AD forest has been built!
Part 5: SIEM and Detection Techniques
Part II: Coming Soon
Part 6: Attack Simulation with Detection Techniques
Part III: Coming Soon
Credits:
If you’d like to be a freelance journalist with Cyber News Live email us at contact@cybernewslive.com.
