It has been over a month, and boy what a month it was. I am glad I took some time off, since things have been bonkers. However, I also had the opportunity to really collect some material for this Security Saturday. Today we dive deep into network isolation in context of malware containment.

For context, let me expose a few things:

• I work as a Security Analyst/SOC Specialist (Really, it is hard to define since I make up 50% of the security department).
• We are in contact and under the guidance of an endpoint monitoring party, which also helps us grow in knowledge.
• In this vein my supervisor (the other 50%) told me to get into malware isolation and analysis.

So that is how I got to this topic, and where I got most of the knowledge. Now, real quick: Malware is an umbrella term for anything wrong (mal) that interacts with your computer (ware), so this means that analyzing it using a computer is dangerous. Many malware programs spread via the internet and so the first thing to do when you want to analyze the malware, is to get it in a box that can hold it, without it spreading.

Enter VMWare vSphere (link at the end). This is a thin virtualisation layer that you can install directly on a computer. It is mainly meant for servers, but a free (behind a sign-up wall) version can be acquired for personal use on whatever computer you have laying around. Using this virtualisation solution means a few things:

• You install vSphere on a separate box, so you have the option to physically deconnect the box if things go REALLY wrong. Also, you don't need a beefy work laptop/desktop like you would when using Hyper-V, Virtualbox, Qemu or whatever.
• vSphere also is it's own operating system, so it is very unlikely that a malware sample is prepared to attack it. Malware usually focuses on Windows, Mac and sometimes Linux. Special cases might also go after BSD.

Now meanwhile, while looking into vSphere we got the work-from home order. So now I have a laptop with vSphere installed on it laying around, connected to my home network. Not a very comfortable place for it to be, since it will house malware. But what can you do...

The next step is to put some checks and balances into place. We are going to be running virtual machines, but it would be dumb to connect those directly to my home network (or the company network) so instead we install a gateway. My first attempt is a Linux (Remnux) box that simply allows or denies connection between another Windows 10 (FlareVM) box and my home network as follows:

FlareVM --VMNet--> Remnux --LAN--> Home Router

Now this is not very elegant. First of all, Remnux is a Linux distribution meant for malware analysis. Moreover, just allow/deny is a weak setting. So we move away from using Remnux as a gateway and instead pick up PFSense, the Swiss army knife of router software. While doing this, my supervisor remarks that maybe we do not want to implicate our home networks at all when working with the malware. We want to both isolate the malware box from the home network, as well as make sure that our own public IP addresses do not get associated with malware. The latter is a good point, since that would get us blocked (potentially) by companies like microsoft and google. We work closely together with Microsoft, so... no thanks.

PFSense, good little software that it is, has a solution. It can use an existing network connection to set up a VPN connection, and use that connection to route all the malware box traffic. Now when people hear VPN thay think of NordVPN or whatnot, with their country selection and censorship evasion. Yes, providers like that can do that, but that is not what a VPN is or should accomplish. A VPN is a Virtual Private Network, which means it is a network that only exists in digital form (it has no direct physical components), and it can only be accessed by privileged computers. In this sense most VPN providers are actually abusing VPN technology to accomplish something that is not really private, because a lot of weird boxes can hook up to the network.

But not to worry, since in this case it is to our benefit that any weird box can hook up to this "private" network. We get a free subscription from ProtonVPN and set it up on PFSense. I had to reinstall PFSense three times to start anew, since the given support article (link below) has one typo. The DNS server setup mentioned in step 5 has the wrong IP address for the free-account configuration.

But no matter, I could tell you what all I did, but following (if you do this at home) the protonvpn support article is fine otherwise. Just remember to change 10.8.1.0 into 10.8.0.1 for the free DNS server.

Alright, now we presumably have a VPN that routes all traffic from inside the network through a VPN, and conveniently I have ditched Remnux and FlareVM since I kept learning about vSphere and found out that I set these VMs up wrong. So what I did do to test the connection is set up a regular Windows 10 machine to test the connection as follows:

Windows 10 --VMNet--> PFSense --[ProtonVPN]--> Internet

Note that the ProtonVPN tunnel connection is still pushed over my Home Network through LAN and over the Home Router. At one point I made the mistake to block all connections on that part of the network (for security) but it turns out that ProtonVPN does need at least port 1194 or 443 open (I could have guessed, but it was so much fun putting something else into lockdown for once).

Now, how can we prove that we are safe?

My first hunch was using nmap (again, link below) to do a port-scan of a box that you know the layout of, and then compare results from outside of the PFSense-managed network, and from inside. This is later confirmed by our contact. The result (and the nmap command used) is shown in the first picture attached to this post.

Some confidential data has been blacked out, but in general you get the idea. - The direct connection is connected from VMware (ESXi) to the home network.

• The PFSense entries are connected to the PFSense network, that then routes everything through ProtonVPN.
• The PFSense entry has all ports allowed
• The PFSense browse-only entry has only ports 80 and 443 (HTTP/HTTPS) open
• The Quarantine entry blocks everything.

The scan targets are chosen such that I am legally allowed to scan them. DO NOT DO ILLEGAL THINGS IN NAME OF YOUR COMPANY. (Disclaimer, sorry).

• The Raspberry Pi is a local DNS server that blocks requests to ad-networks, if it can be reached it should show a response on port 53 (DNS).
• The PFSense firewall can be reached from my home network and the virtual network. It should show port 443 (HTTPS for management website) from one side, and 53 (DNS over VPN) on the other side. It might be I have to redo some of this image since while typing that I realized I made a rookie mistake. the Direct connection should be picking up 443 or nothing, but it says 53.
• The topmost target is my own server, which runs SSH, Mail and a webserver (22, 25+110, 80+443) which makes it a perfect target to test port-specific block/unblock rules on. (Note how browse-only only leaves 80 and 443 intact).
• The second entry is nmap's testing server. It only really runs a web-server and an ssh port, but it can still be used to see if only port 80 is leftover when using the browse-only setup.

But this image only tells us that the block rules and the DNS-over-VPN work. It does not tell us if all communication from inside the PFSense network goes through the VPN. For this we need traceroute (I did not dome up with that myself, the endpoint detection company guy suggested it).

The idea is relatively simple. When asking for directions on the internet, have your computer remember which server sent him where next. In the end it will report back the names of all computers that it has asked for directions before finding it's goal.

What we would want to see is anything from within the PFSense network to at least touch 10.8.0.1, and for some extra certainty it should take a different route altogether, until the very end.

As you can see I color-coded the result and the routing is going nicely separate and completely differs from the direct connection and the reference point of my work laptop.

So there we have it, a proven isolated network that is now ready to host several malware boxes. The work is far from over, but at least this was fun to write down and work out. This part is now done, and the next step is to setup specific rules that allow us to have one computer retrieve malware samples for us, and then distrubute it to the analysis machines in the PFSense virtual network...

I might discuss that next security saturday, if I have figured that out by then, but more likely something else wll find my fancy.

But for now, stay safe out there!

https://my.vmware.com/en/web/vmware/downloads/details?downloadGroup=ESXI70U1C&productId=974&rPId=56933
https://protonvpn.com/
https://protonvpn.com/support/pfsense-vpn-setup/
https://nmap.org/