There are many reasons you might need to isolate a PC or operating systems from a local network. For example, I often work on live malware and ransomware and I want to minimise the risk to the rest of my network.
Many types of malware (ransomware for example) will attack local network devices. As such, a live malware instance can compromise your internal network. It is essential that you protect yourself from the increased risk from the active infection inside your network.
Malware will also try to communicate with Command and Control (C2) servers. This communication can pass along all sorts of data and because the data comes from your local network, it can also reveal your real-world IP address. Perhaps not such a good idea when dealing with malicious actors.
Fail-secure network isolation and routing
When I do any sort of malware research or network shenanigans, I make sure I’m configured so my home and office networks are not accessible from my testing machines. Christophe Tafani-Dereeper wrote an excellent blog post with detailed instructions on the subject.
To protect my identity from malicious C2 servers, I like to add an extra layer of protection. I use an anonymising VPN provider and a fail-secure firewall configuration. This means if if the VPN disconnects, the test network drops too and my test machines don’t keep spraying network traffic out through my regular internet connection.
The best way to accomplish isolation is to route all anonymous traffic through an intermediate router. For example, a Linux box can be configured to ensure all simulated-network’s access is restricted to the VPN tunnel. Consequently, if the VPN tunnel goes down, the Firewall blocks all traffic to and from the ‘hidden’ machines.
Virtual machines and network connections
The easiest way to get multiple machines up and running quickly is to use a virtual environment. I find Oracle VirtualBox perfectly fine for this purpose.
The basic configuration is to run-up two virtual machines. A routing and analysis VM running Kali Linux with two network interfaces, and the isolated test machine that connects to the ‘world’ through the Linux instance.
Address, OpenVPN and iptables rules
The magic of network isolation is accomplished on the Kali machine:
- The NAT (eth0) interface is allowed to see the world using the default local wired configuration, the Internal interface adapter (eth1) is given a different IP and subnet range.
- An OpenVPN link is established on the Kali VM. This starts a new tunnel network interface (tun0)
- The ‘hidden’ computer has an ‘internal only’ network adapter.
- The ‘internal only’ network has an IP address on the same subnet as the eth1 interface on the Kali VM.
- iptables firewall rules are configured to masquerade traffic on the tun0 interface, and allow data between eth1 and tun0 (the isolated machine and the tunnel).
- Finally, the rules drop packets from eth1 to anywhere else to stop the isolated machine seeing local resources.
IPTables firewall rules that limit connectivity of internal eth1:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth1 -m state \\
--state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 ! -o tun0 -j DROP
iptables -A FORWARD -i tun0 -o eth0 -j DROP
Bonus capabilities
Because you have a Kali Linux box in between your isolated environment and the rest of the world, you are perfectly positioned to sniff traffic, route data over TOR, or peek at secure connections with mitmproxy.
What success looks likes
With the correct configuration, you should be able to ping the ‘world’ from your isolated machine, but you shouldn’t be able to ping any local network resources. The network is safe, the bad guys can’t see your real-world IP address, and dropping the VPN link will also drop the link to the world.
148
READY.