Project Fur-Tress: Building a Home SOC Lab (Part 6)
Introduction
There has been a bit of time since the last update of Project Fur-tress. Part-time university coursework had to be done, I'm also working through some more cybersecurity training, the SOC100 course from Level Effect. I've also now been out of work for about 3 months, so I've had to kick the job search up a gear too, in the effort to find employment soon. However, this project is also part of my portfolio, so I wanted to get some progress on it, so I made some time to work on it.
In Project Fur-Tress: Building a Home SOC Lab (Part 5), I set up a Windows 10 Enterprise system as a user endpoint and configured an Ubuntu server. The Ubuntu server was connected to the domain, allowing Active Directory users to log in and access the system, with specific users granted sudo access.
Additionally, Docker and Portainer were installed on the Ubuntu server to serve as a web server for a couple of vulnerable web applications running in containers. These applications will act as sources of vulnerability in my “corporate environment,” enabling penetration testing, security monitoring, and logging exercises.
In this section, I will detail the setup of these vulnerable web applications and the process of locking down the “Fake Internet” VLAN and the “Corporate LAN” VLAN. The objective is to have traffic flow from a Kali VM, on the “Fake Internet”, acting as a threat actor against the corporate LAN. The “Corporate LAN” VLAN will be configured to route all outbound traffic through pfSense to the “Fake Internet,” ensuring that traffic from both VLANs is properly managed and secure.
Vulnerable Web Apps
I plan to make use of 2 vulnerable web apps, DVWA (Damn Vulnerable Web Application), and WebGoat. DVWA is a PHP/MySQL web application, designed to be used to test tools and skills in an environment, and help users learn more about web application security.
Similarly, WebGoat is another web application that was made deliberately insecure, to test vulnerabilities that are often found in Java based applications that use common, or open-source components.
Both of these applications are very insecure, and should not be run on any interfacing services. Ideally, they should be run in a virtual machine, behind a secure firewall or NAT networking mode.
DVWA
For simplicity, I decided to set up the containers for the DVWA within Portainer directly. From the Dashboard, and going into 'Containers', then selecting the 'Add Container' button brings up the Create Container page.
I just gave my container the name 'DVWA' and entered 'vulnerables/web-dvwa' in to the Image text box, then deployed the container.
The container was pulled, but I could not seem to access the URL. Portainer is using ports 8000 and 9443, and the DVWA container was not showing any published ports. Testing with port 80, I couldn't reach any pages.
Stopping, then editing the container, I mapped additional ports, and selected host port 8120, to map to container port 80. After restarting the container, then accessing the Ubuntu server IP and port 8120 in a web browser, I was now at the DVWA log in page.
WebGoat
Now that DVWA had been set up and running, it was now time to do the same with WebGoat. Following the same process, I created a new container, gave it a name and used the image 'webgoat/webgoat' to pull the container.
I ran in to issues again with the ports when trying to connect to the WebGoat URL. The internal ports used are 8080 and 9090. When trying either of these, I was not able to connect. Setting up port mapping didn't appear to work either, and I was getting 404 errors when trying to access.
I had retrieved the login URL from the logs in Portainer, which advised to go to xxx.xxx.xxx.xxx:8080/webgoat to start using WebGoat, but a little looking around online, led me to finding that I needed to add /login at the end of the URL. Using this, I was now able to access the WebGoat login screen.
MACVLAN and Container IPs
The two vulnerable containers are done, and confirmed working. Now, I would like to have them using IP addresses within the domain range, so that I can set these up to use specific fur-tress.soc domain names.
This is possible with a MACVLAN, a virtual LAN that can be used to assign several IP addresses to the same network interface, with IP addresses being assigned to randomly generated MAC addresses. I plan to use this within Docker so that instead of being assigned an IP address inside the Docker Network, and only reachable from the host IP and container ports. Each container will be assigned an IP address on the VLAN network.
To get started, I would need the name of the network adapter in my Docker host, so in this case it would be the name of the network adapter in my Ubuntu VM. To get this, I got to the console of the Ubuntu VM and ran the ip command.
ip -br -4 a
This let me see that my adapter had the name ens18 and this would be needed when setting up the MACVLAN. I then logged in to Portainer, then went to the Networks tab, then selected 'Add Network'.
To use MACVLAN, I first needed to create a config, so for the name, I set it as the VLAN this network would be in, then added 'config' to the end, 'VLAN20config'. The Driver type also needed to be set to 'macvlan', and then 2 options become available to select. Configuration and Creation. As there wasn't currently a configuration set, this was the only option I could choose.
For the 'Parent Network Card', here I would enter the name of the network interface in my Ubuntu VM, ens18. Finally, under IPV4 Configuration, the Subnet would be 10.10.20.0/24 which is my VLAN subnet, the Gateway would be pointed to my pfSense VM at 10.10.20.254 and then for the IP Range, I set this to 10.10.20.32/28.
I did this specifically, so that containers set on this VLAN did not get an IP in the range from my DHCP server. This also gives me a small range of 14 IP addresses that can be assigned to containers, should I want to add more at a later date.
With the configuration settings done, I then created the network, then went back to 'Add Network' so that I could now create my VLAN20 MACVLAN, and point it to the VLAN20config configuration. Setting a name, and driver to 'macvlan' as I had just previously done, but this time I set the configuration to 'Creation' and selected 'VLAN20config', then added the network.
To now set up the containers on the new network, I went into the containers, making sure they were stopped, and edited them.
In the Network tab, I changed the Network from bridge to VLAN20 and then set each container an IP address, DVWA on 10.10.30.33 and WebGoat on 10.10.20.34 and redeployed the containers. Once they were running, I checked that I could access them on the new IP address, within the VLAN20 subnet, and a success for both.
Setting Domain Names
I want both of my vulnerable web apps to be accessible from the “fake internet”, and have domain names on my network. Before I did any configuration through pfSense, I needed to make sure that they could be accessed through domain names on my “corporate LAN VLAN”.
From the domain controller VM, I went to DNS manager, and under my domain controller (FDC01) in the treeview, I went to Forward Lookup Zones >> fur-tress.soc, and created 2 new 'A' records. One for dvwa to point to the IP address of my DVWA container, and webgoat to point to the IP address of the WebGoat container. I also made sure that the option 'Create associated pointer (PTR) record' was checked.
Starting both containers again, and checking the URLs from my domain controller, I could now access both DVWA and WebGoat from the domain URLs.
VLAN Firewall Rules
I now had two very vulnerable web applications running in my lab. Now even though, they were behind my home router, the pfSense VM had no firewall rules yet configured, and I did not want to leave it like this. I needed to start locking down my VLANs.
Before I started making any additional changes, I first made snapshots of the Windows Server VM and the Ubuntu VM in the VLAN20 subnet. I shut down the VMs, created my snapshots, then restarted the systems, and made sure everything was still working.
CORPORATE_LAN_VLAN20
The first VLAN I wanted to lock down, was my corporate LAN VLAN, due to the vulnerable web apps currently running. Going into the pfSense configuration, I went to Firewall >> Rules and selected the CORPORATE_LAN_VLAN20 tab.
I had previously set up a default rule on all VLANs to allow full traffic through, so first I wanted to disable the rule in this VLAN, by selecting it, then clicking the 'Disable' icon under 'Actions'.
I created a new rule, this one would be to allow all traffic within the VLAN20 subnet, so the Interface was set to the Corporate VLAN and the destination was set to Corporate VLAN subnets.
Finally, I created a rule to allow all traffic toward my Fake Internet VLAN, and my rules were set.
FAKE_INTERNET_VLAN10
For the Fake Internet Rules, these were almost duplicates of the VLAN20 rules, one rule to allow all traffic within VLAN10, and then one rule to allow all traffic toward VLAN20. I selected each rule, selected 'Copy' then made the required changes. Once the rules were saved, and applied, the rules were set.
Challenges
Once I had the containers set up with a MACVLAN connection, I did run in to some issues trying to access the web apps, using the ports I had configured. It wasn't until after I read a little more through Docker network information, that I realised that instead of trying to connect to the published ports I had configured, I should use the preconfigured ports. I still also have not set up "internet" accessible domains for these web apps, and need to do more research.
I am not sure at this stage whether to set up a reverse proxy like NginX or Traefik to handle this, or if I should configure this directly through pfSense, as this is in a sense the "corporate firewall". At this stage though, it is something on the ToDo list, until I get more of the systems set up.
Summary
In this part of my SOC Fur-tress project, I successfully set up two vulnerable web applications (DVWA and WebGoat) in Docker containers on my Ubuntu VM. Each application has its own IP address within the VLAN20 subnet and is accessible through internal domain names on the fur-tress.socdomain. Additionally, I've configured firewall rules to ensure that devices on the corporate network can communicate with each other and send traffic to the fake internet VLAN. Likewise, devices on the fake internet VLAN can communicate with each other and send traffic to the corporate VLAN.
Next, I plan to work on the Isolated VLAN and set up two endpoints for malware analysis. These will include a Windows 10 Enterprise VM equipped with FLARE and a Linux VM using REMnux.