Year one of hosting Tor exit relays

It’s a dirty job, but somebody’s got to do it. Well, actually, that’s not quite true. I’ve been mirroring this blog as an onion site since 2016, so I figured it was time to contribute a little time, effort, and money towards the infrastructure of the Tor network. Besides, running Tor relays has always been on my bucket list, and I am getting old. No more time to waste ;)

Why host Tor relays?

That’s a good question. It’s not like the Tor project is lacking bandwidth or (technical) resources. Personally, I would like to see more individuals with the technical knowledge and resources run their own Tor relays. I believe that’s an important countermeasure to dilute the pool of relays run by three-letter agencies.

We are sadly living in a time and age where every surveillance nightmare is about to come to pass. Browsing the web using the Tor browser might soon be the only viable option to access what’s left of a free and open Internet. Case in point from the European Union, currently working on implementing regulations to sacrifice the security and privacy of their citizens on the altar of “save the children”.

Will you go to jail for other people’s crimes?

While the notion is a bit of hyperbole, it’s one of the most frequent questions I get asked. Unfortunately, it’s still a public conception that the Tor network is predominantly used by criminals. Here, I simply implore you to do your own research. For the record. I have not anonymized my personal data with any provider of the computing services I’m renting. Everything is traceable back to me by design.

Prerequisites for running a Tor relay

You’ll likely not want to be running Tor relays on your home network, so the first order of business is to find a cloud-based provider. As a starting point, the Tor community offers a “Good and Bad ISPs” list. Understandably, due to the expected abusive traffic, complaints from other network providers, and high potential for IP blocklisting, few mainstream providers explicitly allow Tor exit relays.

From my background in the hosting industry, I already have a list of providers that always ignore my network abuse complaints. Now they’re unknowingly hosting my Tor exit relays. As for hardware requirements, most starter VPS packages will do, but preferably one with 2GB of RAM or more.

Another key factor to keep in mind is Tor’s bandwidth consumption. Few providers offer unmetered bandwidth. Ideally, you’d probably want more than 20TB of traffic per month. Getting charged for bandwidth overusage can be crazy expensive, depending on the provider, so it might prove useful to configure traffic limitations for the Tor relay.

Configuring a Tor exit relay

To be clear, these are my general fluffy observations and should not be mistaken for an install guide. The Tor Project should always be your source for up-to-date and regularly maintained technical information regarding Tor.

When hosting an exit relay, it’s advisable to harden the server as much as feasible. Do not host other services on the relay, and automate security updates. Additionally, I would suggest blocking outbound traffic completely in the firewall, and from there, only allowing outbound traffic to the ports made available for the exit relay.

You should also install a DNS server to resolve DNS queries so that this data is not passed on to the ISP’s nameservers. The sheer volume of DNS queries from your server would likely trigger some unwanted response from your service provider. Unbound is an excellent choice for a DNS server with good documentation that is simple to configure, both on BSD and GNU/Linux. Just make sure not to provide an open recursive DNS resolver. If possible, I am sure the Tor Project would appreciate a few more BSD-based relays. My recently deployed relays have been installed with FreeBSD. And speaking of DNS, I do not miss systemd-resolved one bit.

Checklist before deployment

The Tor Project provides an extensive and maintained collection of relay documentation that should always be the main source of information. The following are just my personal musings at this specific point in time.

Restrict bandwidth consumption

Tor relays are prone to consuming a lot of bandwidth. Getting billed extra by your hosting provider for several TBs of unexpected traffic usage may be, ehh, unpleasant. Tor lets you limit how much traffic you want to relay either by consistently throttling the amount of data or by specifying the maximum amount of traffic per day, week, or month. Refer to torrc for details.

vnStat is a lightweight network traffic monitor that I would recommend installing and configuring to receive daily traffic reports.

Reduced Exit Policy

If you’re not hosting your relay with a bulletproof hosting provider, then you should limit what ports are available on your relay. Otherwise, your provider will get drowned in abuse complaints, and your Tor operator adventures will come to an abrupt end. When you’re configuring your exit relay, you’ll find the mention of a “ReducedExitPolicy” directive in torrc.

Despite the policy name, it will open a substantial list of ports. Below is the complete list of ports for the reduced exit policy, lifted directly from Tor’s source code (\file policies.c):

#define REDUCED_EXIT_POLICY                                                   
  "accept *:20-23,accept *:43,accept *:53,accept *:79-81,accept *:88,"        
  "accept *:110,accept *:143,accept *:194,accept *:220,accept *:389,"         
  "accept *:443,accept *:464,accept *:465,accept *:531,accept *:543-544,"     
  "accept *:554,accept *:563,accept *:587,accept *:636,accept *:706,"         
  "accept *:749,accept *:873,accept *:902-904,accept *:981,accept *:989-995," 
  "accept *:1194,accept *:1220,accept *:1293,accept *:1500,accept *:1533,"    
  "accept *:1677,accept *:1723,accept *:1755,accept *:1863,"                  
  "accept *:2082-2083,accept *:2086-2087,accept *:2095-2096,"                 
  "accept *:2102-2104,accept *:3128,accept *:3389,accept *:3690,"             
  "accept *:4321,accept *:4643,accept *:5050,accept *:5190,"                  
  "accept *:5222-5223,accept *:5228,accept *:5900,accept *:6660-6669,"        
  "accept *:6679,accept *:6697,accept *:8000,accept *:8008,accept *:8074,"    
  "accept *:8080,accept *:8082,accept *:8087-8088,accept *:8232-8233,"        
  "accept *:8332-8333,accept *:8443,accept *:8888,accept *:9418,"             
  "accept *:9999,accept *:10000,accept *:11371,accept *:19294,"               
  "accept *:19638,accept *:50002,accept *:64738,reject *:*"

I would recommend stripping down this list of ports significantly before deploying an exit relay.

IPv6 exits

Tor could use a few more exit relays supporting IPv6. If your network provides you with an IPv6 address, invest some time in setting it up.

Exit Notice

Make it clear to anyone who connects to the IP address of the exit relay over HTTP that it’s part of the Tor network. That alone will significantly reduce the amount of inbound abuse reports.

Use BSD

We all like diversity, right ;) There is already an abundance of Linux-based relays. Let us get some more BSD relays into the mix. If you can configure a Linux relay, that knowledge can also be put to use for deploying FreeBSD / OpenBSD relays.

Get a new domain for reverse DNS

When you deploy a Tor exit relay, your server will be added to a substantial number of IP blocklists. Eventually, this reputation will spill over to your domain name as well, and Spamhaus will label it as malicious.

Unfortunately, this makes the domain name unusable for anything other than hosting Tor services.

Experiences

I’ll admit that I expected to receive way more complaints and other requests, especially in regard to the exit relays. However, it’s been pretty quiet out there. One explanation could be that law enforcement agencies have become more knowledgeable about the Tor network and thus don’t waste their time on dead ends. Or perhaps the amount of serious crime committed using the Tor network has been vastly over-exaggerated by mainstream media. It would not surprise me if the majority of Tor browser users are simply fed up with surveillance technology.

During the last year, I’ve deployed five relays, including three exit nodes. I have not experienced that hosting Tor relays requires significantly more work than other services I’m running.

A quick rundown of events

Here is a simple rundown of the events related to my five Tor relays during the last year.

See you next year for another report. Happy anonymous browsing!