Running a Tor relay: lessons learned

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, January 30, 2015

Follow me on Twitter as @mattiasgeniar

Mozilla recently announced they’ll be running their own Tor relays to support the Tor project.

As an experiment, I added a Tor relay (not an exit node, I had no interest in dealing with complaints/abuse reports) to my own server a few weeks earlier, to see what kind of traffic it would/could do.

After the initial setup, your relay goes through a “learning period” of a few days, where your relay is evaluated. If it’s stable, it’ll receive more data along the way. After a few days, it was already peaking to > 80Mbps (around 8MB/s). This was faster than I had anticipated, so I killed the relay shortly after and it’s no longer running at this point.

Tor relay bandwidth

In terms of CPU, this was a very low-end server and it peaked to around 30% when it was pushing around 80Mbps.

Tor relay CPU usage

The top 10 relay list in the Tor Globe shows the most active relay is pushing more than 130MB/s in traffic, so a 1Gbps connection being completely saturated.

I considered this an experiment, to see what technical hurdles are involved in setting up a tor relay, how it works from a technical point of view, what happen to your server, … Technically, it’s super easy to set up. Pre-made packages are available, configs are explained and up-to-date setup guides are present.

But as a sysadmin for a hosting provider, I must admit I have mixed feelings about the Tor project. On the one hand, I love the ideal of Tor, of allowing users anonymous access to the public internet. Especially if your government is limiting freedom of speech by filtering the internet. But as a sysadmin, I more often see the negative aspects of traffic relayed through Tor: low-bandwidth denial of service attacks, SQL injection attacks, online abuse, harassment, …

It’s so easy to run everything through Tor as a client that it’s being abused more and more by “attackers”. Site reconnaissance, executing attacks on vulnerable content management systems, … a lot of scriptkiddie tools have Tor support built-in, to make it even easier.

So while I appreciate Tor from a distance, I won’t be running a Tor relay again any time soon.



Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.