Building a Comprehensive Lab Environment for Cybersecurity Research Part-2: Setting Up Networks
In the first part, we have talked about the general design and plans of our lab environment. In Part 2, we are going to focus on the network design of our lab Note: If you have just come across this series, you might want to start from Part-1.
For starters, we are going to need virtual routers and firewalls in our lab environment if we would like to simulate an enterprise environment and a portion of the public IP space. I have chosen OPNsense (which is a fork of pfSense) as it has many of the needed capabilities such as firewall, NAT, routing, DHCP and VPN.
As shown in the first article we are going to setup one OPNsense VM as a router simulating a portion of the public IP space. In order to simulate a portion of the wide area network (WAN), we can chose chunks of Public IPs that belong to organizations or countries which we know that we won’t need to access from our lab environment. In order to look up such large /8 IPv4 blocks you can check out Wikipedia. For this write-up let’s assume that we choose the block 7.0.0.0/8 (note: you can choose another public IP block to which you don’t need to access from your lab environment, it can be a smaller public IP block as well).
We can add 3 Network adapters (Interfaces) on the WAN OPNsense VM and set 2 of these Network adapters to different LAN Segments. The first interface can be setup as VMware NAT as this interface is going to be the connection of our lab environment to real Internet. The main reason that we choose LAN segments instead of host only networks is because there is a limit to the number of VMware host only networks that can be created on a Windows Host whereas there are not many restrictions on LAN segments. Also we don't need any IP blocks to be assigned to these interfaces by the VMware itself since we are going to manage the IP blocks of these segments from our simulated WAN router.
You can find the main network design for this write-up below:
It may be wise to name the LAN Segments accordingly because things get confusing really fast when you define 30+ LAN segments and forget which one is what. Thus, in the scope of our write-up, lets assume that for the WAN router virtual machine the first Network Adapter is connected to NAT, Network Adapter 2 is connected to the LAN Segment, which is called “7.0.0.0/15_SIM_WAN_Backbone” and Network Adapter 3 is connected to the LAN segment “7.2.0.0/15_LAB_WAN_Interface”. In order to keep track of these LAN segments I try to name them as explicitly as possible.
For our simulated WAN to work we would also need a simulated authoritative DNS server that can resolve domain names (such as “myspecialattackerdomain.com” that are unknown to Internet) inside our simulated WAN. As I needed a simple DNS solution with a GUI, I have installed Technitium DNS on a Debian server. The DNS server virtual machine will have one network adapter that is connected to the “7.0.0.0/15_SIM_WAN_Backbone” LAN segment.
Afterwards, static IP networking can be configured by editing the /etc/network/interfaces from the Debian server console. For this write-up we have given IP 7.1.1.1 to the DNS server. Below you can find a screenshot of the Technitium DNS web GUI being served on port 5380. It is relatively easy to setup, and the GUI access is enough for adding different DNS zones and various types of records.
If you would like the simulated WAN DNS server to behave as an authoritative DNS server (which is usually how the public DNS servers such as Google, OpenDNS or Cloudflare DNS basically behaves) then you need to configure the “Allow Recursion”option as shown.
Then, it is time to place our LAB environment inside this simulated WAN and for that we can use the second LAN segment (7.2.0.0/15_LAB_WAN_Interface) that we have defined on the Simulated WAN OPNsense virtual machine. As we are going to place our lab environment inside the simulated WAN, we need to setup an edge router/firewall for our LAB. Let’s call this router/firewall FW01. Moreover as we would like to have many different subnets, we are going to setup 2 more OPNsense router/firewalls. This is mainly because in VMware there is a limit to the number of Network Adapters a virtual machine can have (which is 10). We are going to (creatively!) name these OPNsense systems as FW02 and FW03.
I am not going to give a step by step guide on how to set up OPNsense virtual machines. The initial setup process is done through the virtual machine console command line during OS installation. You can find detailed tutorials on the internet. After creating 3 virtual machines and setting CPU, RAM and Network Adapters, it might be easier to configure one LAN interface for each OPNsense virtual machine through their command line consoles and attach a dummy windows machine to the same LAN segment. This way, you can use the temporary Windows system to make detailed configurations on OPNsense VMs by accessing their web interfaces instead of their command line consoles.
Another important note is that after the initial OS setup the LAN interfaces on OPNsense firewalls will have deny rules by default. My suggestion would be to first add firewall rules for each interface in a way that it would allow any any connections from and to that interface. This is for two reasons: First, we would like to make sure that the routing is working correctly on every subnet that we create so we need allow access from each subnet to every other subnet. Second, the OPNsense firewalls have two different methods for writing rules: interface based rules and floating rules. Using both of them concurrently can make things complicated and for this write-up (even though interface based rules would probably have better performance) we are going to use only the floating rules on each firewall while setting the interface based rules as “ALLOW any any”. The OPNsense firewall is designed to evaluate the floating rules first and interface based rules second, hence if all necessary rules are written in floating rules section of the firewalls, everything would still work as designed (For details you can check out the OPNsense documentation.).
The FW01 and FW03 will also have simulated WAN access as the initial will act as outbound traffic exit for the LAB environment and the latter will act as a firewall to the lab DMZ. All public and private IP blocks and LAN segments are given in the network diagram above.
All FW01, FW02 and FW03 systems will be connected to each other through a chosen LAN Segment which would be attached to one Network adapter on each of them. For this write-up, I have created a LAN10 segment with 10.x.10.0/24 network and give each FW system a static IP on this segment so that they can route traffic to and from each other. Of course, the systems need to know where to route traffic and we need to setup routing in order for these separate OPNsense instances to route traffic through each other . You can find the example routing rules for FW01 below (Note: You’ll need to set routing on FW02 and FW03 as well):
Its easy to get frustrated during this initial networking setup. During this phase, using a dummy virtual machine that you can connect different LAN segments to diagnose issues could potentially save a lot of time. When faced with an issue, using traceroute and ping commands and checking firewall logs could help.
The next part of the series will continue with Part 3: “Active Directory Setup: Forests, Domains & Trusts”
