Advanced Privacy and Anonymity with VMs, VPN, and Tor: Part 4

Advanced Internet Security with VirtualBox Isolation

In this and the next article, we’ll explore an advanced method for online security using connection isolation in VirtualBox VMs. You’ll learn how to use secure router/firewall VMs as VPN clients to tunnel one VPN connection through another. This approach helps separate different activities, makes profiling and surveillance more difficult, and reduces the risk from malware and hacking.

Host and VM security is a deep topic that can’t be fully covered in just a few articles. Here, we outline a general scheme for you to adapt, expand, and rethink for your own needs. The best way to proceed is to study the materials and practice setup on a dedicated test device before building a system for real-world use.

If your threat model requires leaving no traces, it’s wise to download OS images and software via a VPN service and/or Tor. This way, your ISP and other local observers can’t see what you’re doing. Also, consistently using a single VPN service usually attracts less attention than switching between several.

We chose Ubuntu as the example OS because it’s easier for beginners. For real-world use, consider more privacy-focused alternatives like Fedora or Arch (or Manjaro).

For extra security, it’s recommended not to connect the host machine to the internet during installation. Set up the VPN first, then configure UFW to block all non-VPN connections. After connecting to the internet, establish the VPN connection and update the system.

If your activities involve multiple devices or frequent device changes, consider a physical router running OpenWrt. With careful configuration, you’ll have a reliable firewall that routes all outgoing traffic through VPN or Tor, simplifying your setup since you won’t need to configure firewall rules on each device. While routers are a separate topic not covered in this series, we’ll return to it in the future.

With this approach, your ISP and other local observers will only see (possibly increased) traffic through the VPN service. Since UFW rules take effect before network configuration during boot, the new host machine will only have direct internet access without VPN if you disable UFW.

Choosing Hardware

Gaming-class machines or workstations are best for running several VMs simultaneously. Modern mid-range CPUs (Intel Core i5-7 and AMD Ryzen 5-7) can run at least ten VMs at once, each with one or two cores. CPU cores are a soft limit for VM capacity—overloading the CPU just slows things down.

RAM, on the other hand, is a hard limit. If the host runs out of RAM, VMs can crash without warning. Fortunately, RAM is inexpensive, so install as much as possible. This is especially important if you plan to run Windows VMs, which require much more memory than Linux or BSD VMs.

Plausible Deniability

Encrypted data looks random, but files, partitions, and disks containing random data can raise suspicion, especially if there’s evidence of their use. There may also be header information indicating encryption. For example, Linux Unified Key Setup (LUKS) for dm-crypt writes headers starting with “LUKS” and reveals details like the encryption type.

Encrypted disks are decrypted during use, with keys stored in RAM, so it’s best to power off the host when idle instead of using sleep or hibernation.

VeraCrypt allows for hidden partitions and even hidden operating systems (Windows). If needed, you can reveal the passphrase for a “decoy” partition. Attackers can mount the decoy partition and boot the fake OS, but they can’t detect the hidden partition or OS, which may exist. This makes it plausible to deny the existence of any hidden partition.

However, simply having decoy partitions isn’t enough if they don’t contain believable data and aren’t used regularly. For example, if your ISP shows you were online yesterday but your hidden OS hasn’t been used in a week, that’s suspicious. Even if you reveal the passphrase for a VeraCrypt hidden partition, or use VeraCrypt without hidden partitions, an adversary may not believe you. Don’t rely too much on plausible deniability—it can help, for example, when entering countries that require device decryption by law, but not much beyond that.

This guide uses Linux with LUKS and full-disk dm-crypt encryption. The setup does not include plausible deniability features. While LUKS can be configured for OS-level deniability, it’s complex and not easy for beginners, especially on Ubuntu.

Installing the Host OS

  1. First, download the Ubuntu installation image. Use another machine protected by a VPN service and/or Tor for the download.
  2. Create a bootable USB drive and boot the host machine from it. Enter UEFI/BIOS and select the USB drive as the boot option.
  3. Installation steps:
    • After booting, you’ll see “Try Ubuntu” and “Install Ubuntu.” Choose “Install Ubuntu.”
    • On “Keyboard layout,” leave defaults and click “Continue.”
    • On “Updates and other software,” select “Minimal Installation.” Optionally, check boxes for third-party proprietary drivers.
    • On “Installation type,” click “Advanced features,” select “Use LVM with the new Ubuntu installation,” then check “Encrypt the new Ubuntu…”
    • On “Choose a security key,” enter your password in the first two fields. The password should be strong and memorable. If you check “Enable recovery key,” a recovery.key file will be generated to recover the encrypted partition if you lose the password.
    • “Overwrite empty disk space” is safe but will make encryption take longer. Optional.
    • On “Where are you,” select UTC.
    • On “Who are you,” the best anonymous username is “user,” and the device name can be “ubuntu” or “pc.” Enter a password for the user account—make it different from the disk decryption password. The user account password can be simpler, since full-disk encryption is the main protection.
  4. After rebooting, if you don’t need high confidentiality, just connect to the internet as usual. Otherwise, set up UFW as described in the previous article. Then transfer your VPN configuration or pre-downloaded VPN provider app (e.g., .deb file) from the USB drive. In this example, we use a ready OpenVPN configuration. In the top right, click the system tray, then “Settings.” Under “Network,” next to “VPN,” click “+,” then “Import from file…,” and select your file. Enable the VPN by clicking the network status icon and choosing the imported profile. The network icon will change when VPN is active.
  5. After that, update and install VirtualBox:
    sudo apt update && sudo apt install virtualbox -y && sudo apt install virtualbox-ext-pack -y

VM Security Considerations

Full-disk encryption for individual VMs limits access to powered-off VMs, but doesn’t prevent access to data written or cached on the host. It’s up to you whether to add this extra layer of protection. If you feel it’s necessary, go ahead and encrypt your VMs too.

Generally, VMs are isolated from each other unless they have direct network connections or shared disks (including USB and other removable drives) or clipboard sharing. However, malware can potentially escape from a VM to the host. If that happens, other VMs can be easily compromised, especially those with direct network connections or shared disks. If isolation is critical or the risk of malware is high, use separate host machines for different VMs and avoid direct network connections and shared disks.

Networking in VirtualBox

By default, VM network adapters are connected to NAT. This means they use the host’s active network gateway (wired, wireless, VPN, etc.) with network address translation (NAT) and VirtualBox’s built-in DHCP server. Multiple VMs using VirtualBox NAT are isolated from each other. VM network adapters can also be connected to VirtualBox internal networks, allowing VMs to interact over shared internal networks. However, VMs connected to NAT or internal networks have no network connection to the host.

Router/firewall VMs (like pfSense and OpenWRT) have at least two network adapters: WAN and LAN, and usually run a DHCP server on the LAN. For example, you can connect the WAN adapter to the host via NAT and the LAN adapter to an internal network. You can also use router/firewall VMs to connect to remote VPN servers or Tor via WAN and route those connections to the LAN. This is the basis of the system we’re building.

VM network adapters can connect to the host in two other ways. First, by selecting “Bridged Adapter” in VM settings, you can connect them to the host’s physical network adapters. For example, VMs with WAN connected to the host’s LAN adapter behave like other devices on the host’s local network, possibly with IP addresses from the LAN router. Conversely, by connecting the LAN adapter of a router/firewall VM to another host network adapter, you can route resources (like a VPN or Tor tunnel) to other physical machines or networks.

Second, by selecting “Host-only Adapter,” you can connect VM network adapters to the host’s virtual network adapters. These two bridge modes work well together. For example, you can route traffic from the host’s local network (via Bridged Adapter) to a VM (or even a network of VMs), then back to the host (via Host-only Adapter) through a virtual network adapter. This allows, for example, the host machine to access the internet through an intrusion prevention system (IPS) and/or a nested chain of VPN and Tor.

We’ll discuss this in more detail in the next article.

Onion Market – a free P2P exchange on Telegram.

Leave a Reply