Running a virtual machine (VM) that can only connect through Tor

Question

Running normal applications has the problem that any remote code execution vulnerability in the application totally compromises the user. This isn't just a theoretical attack, a vulnerability in Firefox was used to compromise visitors of hidden services hosted by Freedom Hosting in August 2013.

One obvious way to contain this is sand-boxing the application in a virtual machine. Nothing inside the virtual machine, not even the OS should be able to bypass Tor. This obviously implies running Tor outside the virtual machine so this limitation cannot be bypassed by malicious software running inside the virtual machine.

This seems like a natural and secure way to run Tor, so I was surprised to not find any standard bundle (some virtual machine software configured to use Tor together with a specialized Linux or BSD distribution, like Tails) that works this way.

Is there an easy way to configure a virtual machine that can only communicate with the outside through Tor?

Answer 1

Have you considered using Whonix? It comprises two virtual machines, one of which is a gateway and the other a workstation. You work as normal on the workstation, with every network request being funnelled through the gateway and hence through Tor.

Answer 2

Tails is a live Linux operating system that routes all traffic through Tor. Tails can handle many use cases well and is the way to go if you need to torify applications apart from your browser. Please take a look at Tails first, understand its features and threat model before you advance.

Remember the Tor Project suggests only two ways to use Tor: Tor Browser and Tails.

If you explicitly need a way to:

1. route all traffic through Tor
2. have Tor running in another machine

then Tails may not fit.

Generally speaking, to implement this you will need two machines: the first machine will run Tor and will serve as a router. The second machine will be able to connect only to the first and thus every connection will be routed through Tor.

This scheme is implemented from Whonix Anonymous Operation System:

Whonix is divided into two parts: Whonix-Workstation for your work and Whonix-Gateway for automatically routing all Internet traffic through Tor. This is security by isolation, and it averts many threats posed by malware, misbehaving applications, and user error.

Apart from Whonix, you could implement something yourself. For example:

• Run Tor in machine A (say it's a Debian)

• Set up a virtual interface on machine A, with a private IP address:

  File /etc/network/interfaces:

  auto vnet0
  iface vnet0 inet static
      address 10.0.0.1
      netmask 255.255.255.0
      bridge_ports none
      bridge_maxwait 0
      bridge_fd 1
  

• Create the virtual machine B, configure its interface in bridge mode with the vnet0 interface of machine A. Set a static IP address, for example, 10.0.0.2 and as gateway the private IP address of machine A.

• Create a script in machine A that will do all the NAT routing with iptables. You will need something like this:

  iptables -F
  iptables -t nat -F
  iptables -t nat -I POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
  iptables -t nat -A PREROUTING -i vnet0 -p udp --dport 53 -j REDIRECT --to-ports 53
  iptables -t nat -A PREROUTING -i vnet0 -p tcp --syn -j REDIRECT --to-ports 9040
  iptables -t nat -A PREROUTING -i vnet0 -j DROP
  

• Finally you should make sure that 10.0.0.1 on machine A will use Tor, so in torrc:

  AutomapHostsOnResolve 1
  TransPort 9040
  TransListenAddress 10.0.0.1
  DNSPort 53
  DNSListenAddress 10.0.0.1
  

This is to get a rough picture and there should be various other aspects that you should handle with care. For example, running a non Tor-Browser browser in the isolated machine will distinguish you from other Tor users, so that may harm your anonymity.

Answer 3

CAUTION!

> Running normal applications has the problem that any remote code > execution vulnerability in the application totally compromises the > user. This isn't just a theoretical attack, a vulnerability in Firefox > was used to compromise visitors of hidden services hosted by freedom > hosting in August 2013.

Never rely on the virtual machine against malicious code. For that task you should take a bare hardware, separate station connected to the Tor's host.

You can google a thousands of examples with breaking any chroot / any jail. The same picture with virtual machines.

If you do not believe me, start googling from this -> Blue Pill.

---

If you are looking for a solution against leaks - probably, there is a SOCKS5 settings for you:

/etc/tor/torrc:

....
SocksListenAddress 192.168.0.1:9050
....

You should create a virtual interface called "bridge" and bind IP address 192.168.0.1 from host to this interface. Thereafter, make a SOCKS5 proxy on the 9050 port for IP address 192.168.0.1:

root@host:~# brctl addbr br0
root@host:~# ifconfig br0 192.168.0.1 netmask 255.255.255.0 up
root@host:~# kill -HUP `pidof tor`

Make sure that your VM use only a virtual interface, br0, that not connected to any external (real) interface.

In your VM, configure everything what's needed for a network to use 192.168.0.1:9050 socks5 proxy. For example, look at /usr/bin/torsocks.

1) For example, LXC-Container, /var/lib/lxc/VM/config:

....
lxc.network.type = veth
lxc.network.hwaddr = 00:12:34:56:78:9a
lxc.network.link = br0
lxc.network.flags = up
lxc.network.ipv4 = 192.168.0.2
....

Inside the container, change default server IP address from loopback 127.0.0.1 to virtual bridge 192.168.0.1, for torsocks proxifier /etc/torsocks.conf:

...
#server = 127.0.0.1
server = 192.168.0.1
...

Now you can proxify anything by torsocks:

root@vm:~# torsocks wget -q -O - https://check.torproject.org 2>&1 | egrep -i 'congratulations|ip address'
<img alt="Congratulations. Your browser is configured to use Tor." src="/images/tor-on.png">
Congratulations. Your browser is configured to use Tor.<br>
Your IP address appears to be: <b>192.3.116.166</b><br>

Bingo!

Hint: Do not break default Tor settings, keep the SOCKS5 proxy by default on 127.0.0.1:9050 and use one of the inet daemons, for example, rinetd:

root@host:~# vi /etc/rinetd.conf
# bindadress    bindport  connectaddress  connectport
192.168.0.1     9050            127.0.0.1       9050

Now reload settings and you get 2 socks5 of Tor, one on the loopback and another on the br0:

root@host:~# service rinetd reload
Reloading configuration of internet redirection server: rinetd.

---

2) In VirtualBox you need only one settings to achieve this:

Inside the VM, configure everything to use socks5 proxy, for example, chromium:

---

3) QEMU; here you are need a tap interface:

root@host:~# modprobe tun
root@host:~# tunctl -t tap0
root@host:~# brctl addbr br0
root@host:~# brctl addif br0 tap0
root@host:~# ifconfig br0 192.168.0.1 netmask 255.255.255.0 up
root@host:~# ifconfig tap0 up
root@host:~# iptables -I INPUT -m state --state NEW -i tap0 -j ACCEPT
root@host:~# iptables -I INPUT -m state --state NEW -i br0 -j ACCEPT
root@host:~# cat >> /etc/rinetd.conf << EOF
192.168.0.1     9050            127.0.0.1       9050
EOF
root@host:~# service rinetd restart
root@host:~# /usr/bin/qemu-system-x86_64 -boot d -m 2048 --enable-kvm \
             -cdrom  'kali-linux-1.0.5-amd64.iso' \
             -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
             -net tap,vlan=1,ifname=tap0,script=no  -vga std 

Don't forget inside the QEMU set ip address to the eth0 interface:

root@kali:~# ifconfig eth0 192.168.0.2 netmask 255.255.255.0 up
root@kali:~# ping 192.168.0.1
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.395ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.241ms 
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.42ms 
....

Don't forget to change default firefox settings about:config -> network.proxy.socks_remote_dns = True

Set socks5 proxy: Edit -> Preferences -> Advanced -> Network -> Settings -> Manual proxy configuration -> SOCKS Host: 192.168.0.1 & Port: 9050

Check your connection: http://check.torproject.org

Configure /etc/proxychains.conf by adding only one string to the end of file: socks5 192.168.0.1 9050:

Now, you can start any program with prefix proxychain program.bin:

The VM doesn't see an external network, only tap0 and virtual bridge behind this tap0 - br0, and SOCKS5 proxy on that bridge 192.168.0.1:9050.

---

4) VMware:

That way, the VM will connect to the host machine, to VMware's internal virtual interface, vmnet1, only, no external network. Bind the SOCKS5 proxy to this interface by rinetd.

---

Q: What VMs support this?

A: pretty much everyone. QEMU, KVM, LXC, Bochs, VirtualBox, VMware, Parallels Workstation, FreeBSD jail, Xen, etc...

Q: What is the main goal?

A: With only one-two commands and SOCKS5, you can get everything what you are looking for. With any environment around you... You may replace Tor with any other proxy server or even with ssh.

It looks much better than native Tor's transport port, because SOCKS5 is everywhere. You will never see any leaks with this technique.

See: tor-talk Tor transparent proxy leaks?, trac.torproject.org: TransparentProxyLeaks.

---

CAUTION!

Let me tell you once again, NEVER rely on the virtual machine against **malicious code**! This may be used only for comfort. [1][30], [2][31], [3][32], [4][33], [5][34], [6][35], [7][36], [8][37], [9][38], [10][39], [11][40], [12][41], [13][42], [14][43], [15][44], [16][45] ... infinity.

Answer 4

Update: 2016-04-17

Qubes-Whonix integration is now extremely good. I use it myself and highly recommend it. (Qubes TorVM is now deprecated.)

You can read all about Qubes-Whonix on the Qubes website here and on the Whonix website here.

Thanks go to adrelanos and all the other devs whose hard work made this happen.

---

Old answer (2014-08-17):

Qubes TorVM is exactly what you've described.

In simple terms, Qubes OS is an operating system which provides security by isolation using the Xen hypervisor. All user data and programs are run in lightweight, securely isolated virtual machines called AppVMs.

Qubes TorVM is a Qubes OS service which fully and transparently "Torifies" all the network traffic to and from any AppVM which is connected to it. From the documentation:

By default, any AppVM using the TorVM as its NetVM will be fully Torified. (Such AppVMs are referred to as "AnonVMs.") This means that even applications which are not "Tor aware" will be unable to access the outside network directly. Moreover, AnonVMs are not able to access globally identifying information (IP address and MAC address).

In brief, TorVM is designed so that all AnonVM traffic which can be sent over Tor is sent over Tor. All other traffic is silently dropped.

This means that even if a hacker uses a Firefox zero-day to compromise your Tor Browser, which is running in your AnonVM, the attacker will not be able to learn your real, external IP address, since all the traffic to/from the (now compromised) AnonVM is still being sent over Tor, which is running in the separate, uncompromised TorVM.

---

Note: The answer I've provided here is just a brief sketch. You are strongly advised to do your homework before attempting to use any security-critical software. (In the case of Qubes OS and TorVM, I recommend thoroughly reading the documentation and searching the mailing list archives for issues which pertain to your situation.)

Last, but not least, good people are also working on integrating Whonix with Qubes, which promises more great things for the future of using Tor securely!