Table of Contents
A safer way to use Tor is to use two machines, one running the Proxy, and the other running the Browser. The Browser machine is configured such that it has no access to the network, other than through the proxy. This means if you make a mistake, network access will fail rather than reveal your true IP address (a principle known as “fail close”).
The way I do this is with a virtual machine on my MacBook Air. My laptop is the Proxy machine, running Tor, and a virtual machine is the Browser machine, connecting to the Tor service via SOCKS.
Here are the configuration steps you need to make.
0. Before you start
Download the “Tor Browser Bundle” onto your laptop. We won’t be using the browser in the bundle, but it’s a nice simple way to get the Tor proxy installed on your laptop
Install virtual machine software for your laptop. Under MacOSX, I use “VMware Fusion”. Under Windows, I use “VMware Player”, which is free. (I also use “VMware Workstation” for my destop).
Create a virtual machine, and install the operating system. Or, just download a pre-built virtual machine running a Linux desktop, like Kali Linux.
1. torrc/SocksListenAddress [Proxy]
By default, Tor puts the SOCKS service on “127.0.0.1:9150”, which means that only software on the local machine can use the proxy. You need to reconfigure this so that another machine can access Tor.
To do this you need to find the “torrc” file. On my laptop, this is in the directory “/Applications/TorBrowserBundle_en-US.app/Data/Tor”.
Edit this file, and at the bottom, add a line like:
SocksListenAddress 0.0.0.0
This is sub-optimial, because it means anybody on your local network, including other users on the local Starbucks network, can access your proxy. You probably don’t want to open this up to the entire world. Instead, you might want to restrict it just to the local virtual machine. I ran “ifconfig” on the command-line and found an adapter named “vmnet8” that has an IP address of “192.168.51.1”, so I used that instead:
SocksListenAddress 192.168.51.1
When you do this, when you run the Tor bundle, you’ll now get an error message saying that the bundled browser isn’t working. That’s find — it’s just that the bundled browser doesn’t know about the address change, and can’t find the address. You can fix this by reconfiguring which proxy the bundled browser uses, but you shouldn’t bother — because you don’t want to be using that browser in the first place.
2. VM configuration [Proxy]
There are many ways the networking of a VM can be configured. What you want is a “host only” or “private to my Mac” configuration. This means that the VM can talk only to the local host, or to other VMs, but not to the network. Since the default is to do NAT (“Share with my Mac”), you need to change this.
Before doing this, however, you may want to make sure that your’ve got everything working inside your virtual machine.
3. Proxychains [Browser]
I run Linux inside the VM, so therefore, I need command-line utilities. Unfortunately, most tools don’t know about proxying, so you need a tool called “proxychains” to enforce this. If you are just going to use the web-browser, then you can skip this step.
To install this tool:
apt-get install proxychains
Now you need to edit /etc/proxychains.conf. Go to the bottom of the file. There may be a default configuration line using “socks4”, delete this or comment it out. Now add a line like the following, where the IP address is that of the VMware virtual machine configured in step 1:
socks5 192.168.51.1 9150
Note that older Tor defaulted to port 9050 and socks4, and newer stuff uses 9150 and socks5.
Somewhere else in the file is the configuration setting “proxy_dns”. You’ll want this enabled — this fixes the old concern where DNS lookups would leak your IP address. Note that if this configuration is wrong, then proxychains just won’t work — our “failed-close” configuration makes this happen.
To use proxy chains, just prefix it to any command, such as:
proxychains wget www.yahoo.com
Run this command, and you should see it work. The same technique works for running things like “proxychains apt-get …” or “proxychains git clone …”.
4. Iceweasel [Browser]
The default browser for many Linux distros is “Iceweasel”, which is a custom build of Firefox. You need to configure it to use proxy.
To begin with, you need to tell it to proxy DNS correct. Go to the web page “about:config” to access the advanced settings, search for “dns” settings, and configure the following parameter (by double-clicking on it):
network.proxy.socks_remote_dns true
Next, go configure the normal proxy settings at [Edit] [Preferences] [Advanced] [Network] [Connection] [Settings] [Manual Proxy Configuration] [Socks Host], and configure the same IP address and port (192.168.51 9150).
A screen shot of this is below:
5. General Tor settings
At this point, you’ve got a nice private machine. As long as you’ve got the virtual machine configured to be “host only” (“Private to this Mac”), then you don’t have to worry about things escaping your computer.
But you still need to learn a bit with Tor. For example, once you get all this working, you’ll find that your Google searches no longer work, because Google blocks a lot of activity from Tor exit nodes. Therefore, you’ll have to change your search engine to something like DuckDuckGo, which is Tor-friendly.
Also note that you can out yourself accidentally. Let’s say you are a journalist working on a super-secret article on the NSA, and you accidentally search for something like “EGOTISTICALGIRAFFE” from your main computer rather than the Tor-protected computer. The NSA can (and probably will) subpoena the information from Google to see who searched for this term before it became public, discovering your identity. You have to religiously compartmentalize what you are working on for a story, and never let ideas creep out to appear as search attempts or browser history from your work computer, friend’s computer, or you laptop.
6. Optionally encrypt the VM [Browser]
Since the VM has all your secrets, you probably want to encrypt it with a strong password. You probably don’t need this step if you’ve already got full-disk-encryption, but if you don’t, then you should probably do this.
VMware has this option built-in. You can select your virtual machine and tell VMware to encrypt it. It’ll ask you for the password each time you reboot the VM.
If running Linux, you can also use LUKS. The Kali site has a good description of how not only to encrypt your VM, but also configure a password that will destroy the VM in the case that somebody tried to force you to divulge the password.
Note that without encryption, people can recover files from your drive. In other words, let’s say you delete your VM. The actual bytes aren’t deleted yet until the drive is wiped so forensic utilities on the drive may still recover files you think are gone. Encryption solves this, such that when you delete the VM, the only thing recoverable is garbage.