Isolating Untrusted Virtual Machines — 2

Part 1: Isolating Untrusted VirtualBox Machines — 1

Searching the web using keywords sandbox, isolate, and VirtualBox for other people who have isolated untrusted VirtualBox virtual machines (VMs) revealed little. I found only one person who shared meaningful information.

The idea of isolating untrusted VMs yet allowing web access seems straightforward. The untrusted systems need a DHCP server, a DNS name server, and a routing gateway. Possibly firewall rules are needed to block the untrusted VMs from the host.

While I use Slackware in my LAN server, I chose Ubuntu Server 16.04 32-bit for this project. Mostly for the learning experience.

After experimenting a few times I configured the Ubuntu Server VM with a dynamic 3 GB disk and 144 MB of RAM. The system refused to boot with 128 MB of RAM despite using about 22 MB at idle after booting. Installing was uneventful and took less than 15 minutes. Being the server edition meant the installation script was ncurses based rather than graphical. I chose to have updates install automatically. With my first login I was notified of updates.

I named the system gateway.

I installed nmap. That would be handy for scanning ports on untrusted VMs. I disabled or masked several unnecessary services.

The Ubuntu installer recognized both VirtualBox network cards but configured only one. I manually configured the second card by editing /etc/network/interfaces. As I am not fond of the systemd network card naming scheme. I added net.ifnames=0 to the /etc/default/grub boot parameters and ran update-grub.

VirtualBox defaults to the subnet when using NAT. To avoid potential conflicts I used the subnet.

    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface (WAN)
    auto eth0
    iface eth0 inet dhcp

    # The secondary network interface (LAN)
    auto eth1
    iface eth1 inet static

I rebooted to test the network. The ifconfig command looked good.

I configured the Ubuntu Server to use dnsmasq to provide a 1) DHCP server, 2) DNS name server, and 3) a routing gateway.

My dnsmasq options:


In the server /etc/sysctl.conf I enabled IP Forwarding. Here lied a subtle stumbling block. There is a similar sysctl.conf in /etc/ufw. When using ufw the Ubuntu server default is to use the file in /etc/ufw.

For the initial testing I disabled the server’s ufw firewall interface. I disabled the firewalls in the Windows VMs.

I rebooted the Ubuntu Server and started a Windows XP and 7 VM. When testing a Windows system, opening a terminal (cmd.exe) and using the ipconfig /all command is a quick way to view network settings. Important to this project is the Windows system is assigned an IP address in the expected subdomain and DNS servers and a gateway are assigned.

I verified I could ping all three Internal Network systems from any direction. I could not ping external domain names or the host. So far so good.

Next was to add some NAT and port forwarding rules to the ufw firewall configuration. This got confusing. In the end I settled for the following:

ufw commands:

    ufw allow in on eth1 to any port 67 proto udp


    # NAT table rules
    # Forward traffic from eth1 (LAN) through eth0 (WAN)
    -A PREROUTING -i eth1 -d -j DROP

Everything seemed to work. Most importantly, from an untrusted VM I could not ping the host machine or the LAN.

I was uncomfortable with the results. Everything I read indicates DHCP requests are enabled by default in ufw. I did not understand why I had to add a rule.

Like my Ubuntu apt proxy server VM, the excessive memory footprint for a 32-bit image rankles me. A simple server used for DHCP, DNS, firewall, and gateway should run fine on 32 MB. I see no reason for 144 MB of RAM.

I am uncomfortable with the results. Also unknown because I did not test further is whether installing the Guest Additions opens the door to exposing the host or LAN subnet.

For now I am letting this project hang.

Posted: Category: Tutorial Tagged: General, Ubuntu, Windows

Next: Safely Halting or Rebooting

Previous: Isolating Untrusted Virtual Machines — 1