A guide for how to set up your own Tor relay.
Your computer's IP addresses can be correlated to an online identity and even a physical location, typically accurate within a city block. In other words, any website you visit can know your physical location, even with every ad blocked and every social network logged out from. That is, unless you use Tor.
Tor is an "onion routing" network that lets people browse the web with a high degree of anonymity by bouncing their web traffic across multiple servers, called Tor relays, in such a way that each link in the chain knows the previous and next link but never the whole chain.
When someone connects to Tor, their traffic is first sent to a "guard" relay, then to a "middle" one, then to a final "exit relay." The exit relay can see that traffic originates from the middle relay, but has no way of knowing the first origin of the traffic: your IP address. If you're using the Tor Browser, any website you visit will only see the IP address of the exit relay. You might be in southern Taiwan, but anyone watching will think you're in Berlin, or wherever the exit relay is.
Using Tor is an inherently slower way to browse the web, because your connection is routing for entropy rather than efficiency, but this is an unavoidable side-effect of the anonymity provided by Tor. People under heavily-surveilled regimes, or simply those who wish to avoid being tracked online (for example by aggressive advertisers) rely on it to use the internet safely and must tolerate its slow speed.
There will always be an inherent risk to leaving the security of a network in the hands of volunteers with only a core set of ideals and some technical expertise in common
So how do you make the Tor network faster? One way is to have lots of relays with lots of bandwidth.
A relay is any computer accessible to the rest of the internet running the Tor software, configured to relay encrypted data across the Tor network. That computer can even be a virtual computer, which means you can run it from your house but the hardware will be located remotely. Virtual machines are popular in many data centers because hosting and leasing an instance of a virtual computer is a lot less expensive than one taking up physical space.
Relays are operated by everyday volunteers, maybe like you!
In this guide, we'll set up a relay on a virtual computer running Ubuntu 14.04. This guide assumes you've maybe dabbled with Ubuntu or another distribution Linux. Bonus points if you're comfortable with the command line since almost every step of this happens without using a mouse. In this case we're using DigitalOcean, but most other Virtual Private Server (VPS) providers will also work. A crowd-sourced list of VPS policies on Tor can be found on Tor's Good/Bad ISP wiki.
Step 0: Set up a Linux Server
I chose DigitalOcean because the company has been consistently tolerant of people running Tor middle relays on its infrastructure. It's also the easiest to work with since most other VPS providers don't offer the ability to log into a server through a web interface, which is useful if you want to access your server from the Tor Browser.
DigitalOcean has a few different pricing options. The 1GB / 1 CPU / 30GB SSD Disk / 2TB Transfer tier with Ubuntu 14.04.03 x64 works pretty well for this and only costs $10 a month. Although generally more bandwidth is better, 2TB is fine. Here's the full specs:
Ubuntu 14.04.03 x64 (aka "Trusty Tahr")
1GB/1 CPU/30GB SSD/2TB transfer
$10 per month
Once you choose the specifications of your VPS (or "droplet"), you can then choose where that server will live. The Tor network already has many relays in Germany and the US, but it improves the security of the network if its relays are in a diverse set of geopolitical jurisdictions, so if you can, you should choose a location elsewhere in the world. Let's say Singapore. You can skip the bits about setting up an SSH key, since we'll be using DigitalOcean's built-in console.
What you're ultimately setting up right now is a server running Linux, the same sort of setup that runs almost every website you visit regularly. This means everything you do after you hit the Console Access button on the DigitalOcean dashboard will be done through the command line, just like that scene in the Matrix where there's green text and a blinking cursor, minus the rest of the film.
There's some conventions on what to type in these prompts that you'll see here and almost everywhere else Linux is mentioned in cyberspace. For example, when demonstrating commands:# echo 'This is a root command, you can tell because of the pound sign (or hashtag for snake people).' $ echo 'This is a user command. It has a dollar sign in front of it.'
...and configuration files, where pound signs mean totally different things:# This is what a configuration file written for "Bash" looks like. # Bash is a both the name of "shell" aka command line we're using # as well as the name of the scripting language used to write # batches of commands into bash "scripts". # Bash will only read a line if it doesn't start with a #. # The option, or "flag" below will not be read: # useChaosEmerald = 1 # But this one will: useChaosRings = 1 # These #-prefixed lines are called "comments" because they're for # human reference and not commands for machines. When you # "uncomment" a line with a #, that line will be run as a # command would.
If you haven't seen a command line since watching The Matrix, I recommend first checking out the Free Software Foundation's Introduction to the Command Line.
Step 1: Fortify Your Passphrases and Everything Else Too
The threat model for Tor relays is a bit more serious than some other services. Your run-of-the-mill script kiddie might be more interested in going after low-hanging fruit like unpatched Wordpress sites instead of your relay, but a sizable swathe of intelligence agencies flush with cash and thirsty for secrets will be watching your relay and contemplating how to exploit it. An attacker probably won't be able to decrypt which pages people are visiting over Tor by hacking into your relay, but if an attacker could gain control over a big enough swath of relays, they could theoretically check for traffic patterns over a whole circuit. For this reason, make your passphrases long, and feel free to use long combinations of words sprinkled with special characters in random places. That's more effective than a short password with only immemorable strings of characters.
There are two passwords we need to set in this setup: one for the administrator or "root" account that has god-mode over the whole virtual machine, and one that's safe to log into from the outside, which you can name whatever cool haxor handle tickles your fancy.
To change to root password, go to the DigitalOcean console access page and login with the original root password it sends you via (ugh) plaintext email. If you're logging in with the Tor Browser and it asks you if you want to allow the page to extract HTML5 info, you can choose "Not now." If the console has issues loading, you can reload the page to retry.
Once you login, DigitalOcean will ask you to change your new password. It will first ask you to enter the root password from their email, then ask for that password once again, then ask for you to choose a new password and then ask you to enter the new password again to confirm it was correct. After you do that, it will reload the console and ask you to log in as root with the password you just created.
Note: You can copy but you can't paste anything into the DigitalOcean console, so make sure to type everything in carefully.
Bonus Note: Sometimes the DigitalOcean console goes blank inexplicably, so if that happens, click around in the console or if that doesn't bring it back, reload the page.
To create a non-root account you can use to log in with remotely (leave out the "[" and "]"). Things this command will ask for like full name, room number, etc can be left blank. Only the account's username and password are required:# adduser [whatever your l337 hacker username is]
After setting creating the account:# adduser [whatever your l337 hacker handle is] sudo
The "sudo" part of that command means this user we're creating will be able to do stuff like update or configure software installed on this system after being prompted for your password. This also means that my fellow nerds can make a "sudo make me a sandwich" joke and you'll get it and either laugh or sigh. Related note: Make sure your DigitalOcean account password is just as strong, but never reuse passwords.
To log out from the root account:# exit
Speaking of software updates, something you'll want to get into the habit of running updates, aka patches, on this relay. When a vulnerability is found in any of the numerous software packages used in a modern Linux system, patches are released to fix vulnerabilities, but they need to be downloaded and installed. Some people have a tradition of doing this on Tuesdays, but you can choose whatever day of the week you prefer, or every day if you're really hardcore or just bored.
To run updates (while logged in as the user you created earlier, not as root):$ sudo apt-get update $ sudo apt-get upgrade
Bonus Level: Encrypting the virtual disks on your virtual machine may also add some protection against anyone who finds/subpoenas/hacks their way onto the non-virtual hardware your virtual machine sits on.
Step 2: Install the Tor package from Tor's repository
Ubuntu, the distribution of Linux that the server we're making runs, uses software repositories (aka "repos") to easily update software, much like an App Store, minus the store part. Many times, though, Ubuntu will not be as fast at the Tor Project at having new software updates ready, so it's better to use the Tor Project's repos rather than Ubuntu's. As with many things in Linux, we'll do that by editing a configuration file. Configuration files are text files, so we can edit them with any text editor. Ubuntu comes with nano, so we'll use that for editing this one. HTG has a primer on nano if you've never used it before.
Create a new configuration files with just the Tor repositories listed in it:$ sudo nano /etc/apt/sources.list.d/tor.list
Add these lines to the document, save the file and exit.deb http://deb.torproject.org/torproject.org trusty main deb-src http://deb.torproject.org/torproject.org trusty main
Tor uses PGP to let the system check if the packages it builds have been tampered with in transit. Add the Tor Project's PGP public key and update the system to look at the new repos we just added:$ gpg --keyserver keys.gnupg.net --recv 886DDD89 $ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add - $ sudo apt-get update $ sudo apt-get install tor deb.torproject.org-keyring
Feel free to fact check any of these commands against the official Tor documentation. Things like the PGP signatures might have changed since this guide was published.
Step 3: Configure Tor to run as a relay
Every setting for Tor is set in the torrc configuration file, including all the ones to turn this machine into a relay.
To open torrc for editing in nano:$ sudo nano /etc/tor/torrc
Scroll down to the bottom of the file, and add these lines. Make sure to pick a cool, but unique name for your relay so that it's easy to find it later on Atlas, an online directory of Tor relays.ORPort 9001 DirPort 9030 RelayBandwidthRate 770 KB RelayBandwidthBurst 1540 KB Nickname [whatever your cool and unique relay name is] ContactInfo YourNameOrNym
This is what each of these configuration options do:
9001 is the port Tor will use for relaying traffic through. 9030 is the port used for the global Tor directory. It can use a few different ones if they're not being used by something else but that can get tricky so we won't do that here.
RelayBandwidthRate 770 KB
RelayBandwidthBurst 1540 KB
These basically determine how much to throttle traffic. For the relay bandwidth rate, 770 Kilobytes per second should keep us from burning through our 2 TB per month cap too quickly. The burst is not a rate per se, but rather the size of the bucket moving data through the relay. Opinions vary on how big this should be. Twice the rate should be fine.
Nickname [whatever your cool and unique relay name is]
A unique name for your relay. Kinda like the way people name ships or pets. Note: leave out the square brackets from the Nickname unless you want them as part of the name.
E.g. David Huerta <firstname.lastname@example.org> but with your info, not mine. The name and email address can be whatever you want, including a pseudonym and throwaway email account if you're into that sort of thing. These details are public and searchable.
AccountingMax 1999 GB
2 TB (2000 GB) is the max amount of bandwidth we can use since that's the cap DigitalOcean has per month for this plan. We're leaving 1GB out for things like software updates, etc.
AccountingStart month 1 12:00
This defines the start of the bandwidth check to 1st of each month at noon.
ExitPolicy reject *:*
This means your relay will won't be an exit relay. Running an exit relay is the most hardcore of relay operation and will get you lots of high fives from hackers but also legal threats from the RIAA/MPAA/FBI/DEA/KFC/Interpol/Scientology/Everyone. Running a non-exit relay shouldn't get you much attention.
After saving the files, reload Tor so it re-reads the config file we just edited:$ sudo service tor reload
Step 4: Make sure it works
After restarting Tor, wait a few minutes and check the Tor log to see if everything looks okay:$ sudo tail /var/log/tor/log
You should then see an entry with something along the lines of "Self-testing indicates your ORPort is reachable from the outside. Excellent."
After a few days or faster, you should be able to look at your relay's stats on Atlas by searching for the name of the relay you gave it. Over time, the graphs on the page will have lines and dots and things indicating traffic. In the meantime, you should subscribe to the tor-announce and tor-relays mailing lists to stay abreast of all things relay-related. If you want to learn more about what to expect when relaying, the Tor Project has a comprehensive overview or a relay's lifecycle.
Tor in general gets a lot of attention from law enforcement, lawyers, script kiddies, and other people that you might not want to get a phone call or email from. Most of this attention is directed at the operators of exit relays rather than operators of middle and guard relays. However, the nuances of that difference might be lost on some, and there's always the chance that you could get some upset people trying to contact you. A greater risk of running a relay is in not being able to properly protect it and putting the privacy of a relay's users in potential danger. This is why the bits in this guide about passwords and running updates are incredibly important. Ultimately, however, having more relays in the hands of a wider range of people makes the Tor network more resilient to other attacks, so operating a Tor relay with good security habits does give it a net gain on security in addition to speed.
There will always be an inherent risk to leaving the security of a network in the hands of volunteers with only a core set of ideals and some technical expertise in common. Tor doesn't have a command-and-control architecture; That kind of centralization is the architecture which makes mass surveillance easier. Tor's decentralized nature reflects a different underlying philosophy in allowing anyone willing to run a relay to become an active participant in its operation, with the burden of responsibility shared in solidarity with the needs of absolutely anyone who wishes to regain a right to read.
David Huerta is a developer who visualizes financial data by day and poisons search data by night while developing hayst.ac. He a co-organizer of CryptoParty NYC and mails weird art in suspicious packages.