After several weeks and a trip to Goodwill, I have successfully implemented my malware analysis lab as envisioned!
Part I: The Setup
My network is as follows:
I have the Edgerouter X serving several VLANs, but there are two in particular that I will discuss today. The two ethernet ports on the XenServer serve two purposes: one ethernet port connects to the VLAN aware switch and provides management functions, and the other is used by the VMs for a network connection. This network connection is connected to a Debian PC with two ethernet ports bridged together. That way I can snoop on any network activity silently to the VM. I can also break
Along with this upgraded network, I have revamped all of my firewall settings:
In this, let’s look at VLAN400 (my PC and its VMs), VLAN325 (XenServer MGMT), and ETH1 (both IN and LOCAL). ETH1 has the largest group of firewall policies (11 in total) than any other network. For IN, it can not communicate with any of the VLANs except for the FreeBSD VM located at 192.168.40.100, but only if it originates on the Debian PC. This way, I can have a full two full virtual layers of protection between this network and the rest of the network. If malware were to escape to my main PC, its chain of infection would be either:
Infected VM -> XenServer itself -> FreeBSD VM -> PC
Or
Infected VM -> Debian PC -> FreeBSD VM -> PC
For ETH1 LOCAL, it has two simple rules: Allow port 53 to the router, and deny everything else. This way, any VMs are unable to attack the switch itself through any of the VLAN IPs.
VLAN325 (the XenServer MGMT VLAN) has a similar firewall policy. It can only communicate with the FreeBSD VM:
All of this configuration is well and good, but does it work? All the configuration in the world does you no good if it simply doesn’t work in the first place!
Part II: Testing the configuration
Can my PC ping the Debian PC or the XenServer IP in the 10 network?
Can my PC ping the XenServer MGMT IP?
Can the XenVM ping the PC?
Can it ping the 10 network’s switch IP?
With our simple ping test, we can conclude that the firewall rules are working as expected. To confirm, I did do an NMAP scan of 192.168.40.* with the following commands:
nmap -T4 -d -v -F -Pn 192.168.40.1 192.168.40.2 192.168.40.10 192.168.40.100
Sure enough, not a single packet returned!
However, the 10 network isn’t so lucky. The switch gateway has DNS open; the Debian PC has ports 7, 9, 13, 21, 22, 25, 37, 53, 79, 80, 110, 113, 990, 995, and 3389 open; and the XenServer has ports 22, 80, and 443 open. I’m sure the iptables firewall could close the XenServer ports, but the open ports on the Debian PC are due to two programs I’ve installed.
Part III: PolarProxy and INetSim
By using this guide, we can capture, intercept, and blackhole any communication between the VM and the outside world. INetSim INetSim is an Internet Services Simulator Suite, and it provides simulation for popular protocols, such as HTTP/S, FTP/S, SMTP/S, and others. PolarProxy is a transparent SSL/TLS proxy created specifically for incident responders. These two programs plus Wireshark will form the backbone of the network analysis for malware, and since this is done off of the victim VM, it is practically undetectable.
One thing I do have to investigate is whether or not those SSL errors are fixable. However, that is not a show-stopper in any sort of the imagination! Here is the guide to install both PolarProxy and INetSim.
Part IV: What’s Next?
My first foray into serious malware analysis was in 2019. I was running a Windows VM within VMWare with an active internet connection and shared folders enabled. Fast forward a year and four months later, I have dedicated equipment and a very mature network and firewall setup. I think it has come time to do actual research on my setup and see just how well it can perform. As far as any upgrades to the existing setup, I would like to move the FreeBSD VM to its own PC altogether. After that, I would like to fully physically segment my lab network from everything else. Even up to the point of having its own router!