Topics
- What is Tor?
- Types of relays
- Technical setup
- More about relays
- Relay diversity
- Getting help
What is Tor?
- Tor is free software and an open network.
- Mitigates against tracking, surveillance and censorship.
- Run by a US non-profit and volunteers from all over the world.
- It's Tor, not TOR.
The Tor network
- An open network that everyone can be a part of.
- The network is composed of different types of servers run by volunteers around the world.
- Your server will relay the Tor traffic to another server on the Internet.
- Before entering the network, your server will automatically go through the relay lifecycle.
Why run a Tor relay?
By running a Tor relay, you can help make the Tor network:
- faster (and therefore more usable)
- more robust against attacks
- more stable in case of outages
- safer for users (spying on more relays is harder than on a few)
Guard/middle (aka non-exit) relay
- A guard is the first relay in the chain of 3 relays building a Tor circuit.
- A middle relay is neither a guard nor an exit, but acts as the second hop between them.
- To become a guard, a middle relay has to be stable and fast (at least 2MByte/s); otherwise, it will remain a middle relay.
Exit relay
- The exit relay is the final relay in a Tor circuit, and sends the traffic to its destination.
- That is why exit relays have the most significant legal exposure and liability of all relays.
- Before running an exit relay, talk with your local digital rights organization.
- You should not run a Tor exit relay from your home.
Bridge
- A bridge is a node in the network that is not listed in the public Tor directory, making it harder for ISPs and governments to block it.
- Bridges are relatively easy, low-risk, and low bandwidth Tor relays to operate.
- And there's another special kind of bridge: Pluggable transports. These hide your Tor traffic by adding a layer of obfuscation.
The lifecycle of a new relay
Non-exit relays go through a lifecycle of four phases (defined in days):
- Days 0-3: the unmeasured phase.
- Days 3-8: network authorities start the remote measurement phase (the ramp-up guard phase).
- Days 8-68: guard phase (where load counter intuitively drops and then rises higher).
The lifecycle of a new relay
Before we start
- Never run a relay without the consent of the network administrator or machine owner.
Read the Terms of Service (ToS) first, so you don’t risk losing money.
- Choose which type of relay you will host. A non-exit relay is an easy way to start helping the network.
- Read the documentation: https://community.torproject.org/relay
Bandwidth requirements
- It’s recommended to have at least 16 Mbit/s (Mbps) upload and download bandwidth available for Tor. More is better.
- The minimum requirements for a relay are 10 Mbit/s (Mbps).
- If you have less than 10 Mbit/s but at least 1 Mbit/s, we recommend running a bridge with obfs4 support.
Monthly outbound traffic
- Relays must use at least 100 GByte of outbound/incoming traffic per month.
- If you have a metered plan, you might want to configure Tor to use only a given amount of bandwidth or monthly traffic.
- More (>2 TB/month) is better and recommended.
Public IPv4 address
- Every relay needs a public IPv4 address - either directly on the host (preferred) or via NAT and port forwarding.
- The IPv4 address is not required to be static, but static IP addresses are preferred.
- Your IPv4 address should remain unchanged for at least 3 hours (network consensus).
- You can only run two Tor relays per public IPv4.
Other requirements
- Memory: A <40 Mbit/s non-exit relay should have at least 512 MB of RAM available.
- Disk storage: Tor does not need much disk storage. A typical Tor relay needs less than 200 MB.
Other requirements
- Any modern CPU should be fine.
- Uptime: Ideally, the relay runs on a server which runs 24/7.
Choosing your relay hosting
Non-exit relay - Debian/Ubuntu
- Enable the Tor Project package repository
- Install the tor package
$ apt update && apt install tor
Non-exit relay - Debian/Ubuntu
Non-exit relay - Debian/Ubuntu
$ systemctl restart tor@default
Non-exit relay - FreeBSD
pkg install tor ca_root_nss
Non-exit relay - FreeBSD
- Edit the configuration file
/usr/local/etc/tor/torrc
Nickname myNiceRelay
ORPort 9001
ExitRelay 0
SocksPort 0
ContactInfo tor-operator@your-emailaddress-domain
Log notice syslog
Non-exit relay - FreeBSD
- Ensure that the random_id sysctl setting is enabled:
echo "net.inet.ip.random_id=1" >> /etc/sysctl.conf
sysctl net.inet.ip.random_id=1
Non-exit relay - FreeBSD
- Start the tor daemon and make sure it starts at boot:
sysrc tor_enable=YES
service tor start
Verify that your relay works
After restarting the service, verify that the log file contains the following entry:
Self-testing indicates your ORPort is
reachable from the outside.
Excellent.
Publishing server descriptor.
About 3 hours after you started your relay, it should appear on Metrics portal in Relay Search.
Technical tips
- Enable automatic software updates.
- Backup your Tor Identity Keys.
- It's possible to limit bandwidth usage (and traffic). Check the parameters, for example, AccountingMax, AccountingRule, AccountingStart.
- If you run more than one Tor relay, you need to set the MyFamily parameter.
Metrics
- Metrics portal: https://metrics.torproject.org
- You can search for how many relays are in the network, how many are exits, etc.
- In 2021 there are ~6,600 public relays and ~1,500 bridges.
- Check: how many relays are in your country? Who runs these relays? How diverse are they?
Monoculture
- A single kernel vulnerability in GNU/Linux impacting all Tor relays could be devastating.
- Diversity of Operating System (OS): ~90% of relays are Linux.
Monoculture
- Diversity of Autonomous Systems (AS).
- Try to avoid the following hosters: OVH SAS (AS16276), Online S.a.s. (AS12876), Hetzner Online GmbH (AS24940), DigitalOcean, LLC (AS14061).
The TorBSD Diversity Project
- The Tor BSD Diversity Project (TDP) is an initiative seeking to extend the use of BSD Unix operating systems in the network.
- Goals: increase the number of Tor relays running BSDs; Engage the BSD community about Tor anonymity; Port Tor related programs to BSD operating systems.
Legal information
- Many countries have regulations that exclude internet service providers from liability.
- It's a good idea to consult with a lawyer or your local digital rights organization.
- Under most circumstances, you will be able to handle legal matters by having an abuse response letter.
Tips for running an exit relay
- Get a separate IP for the relay, and don’t use it for other services.
- Set up a Tor Exit Notice, so if someone checks your exit IP they'll know that it’s a Tor Exit.
- If you receive excessive complaints, consider running a Reduced Exit Policy.
- For more tips: https://blog.torproject.org/tips-running-exit-node
Running relays with others
Running a relay with others
Relays associations
- It's often advised to create some type of non-profit organization. This is useful for having a bank account and shared ownership.
- The most important thing is to have a group of people (3-5 suggested to start) interested in helping.
Running a relay with universities
- Universities are typically home to a reliable, robust, and well-equipped network.
- Many computer science departments and university libraries run relays: Massachusetts Institute of Technology, Universität Stuttgart, the University of Waterloo.
Running a relay with universities
At your company or organization
- If you work at a Tor-friendly company or organization, that's another ideal place to run a relay.
- Companies like Brass Horn Communications, Quintex Alliance Consulting, and many others run relays.
- And organizations like Digital Courage, Access Now, Derechos Digitales, Calyx Institute, and Lebanon Libraries in New Hampshire.
What is a bad relay?
- A bad relay is one that either doesn't work properly or tampers with our users' connections. That can be either through maliciousness or misconfiguration.
What is a bad relay?
- For example: tampering with exit traffic in any way (including dropping accepted connections). Or, running HSDirs that harvest and probe .onion addresses
Reporting a bad relay
- The "Bad relays" private working group at the Tor Project work to detect misconfigured, malicious, or suspicious relays.
- Users can report bad relays by sending an email to bad-relays@lists.torproject.org with the relay’s IP address or fingerprint, what kind of behavior you see, and any additional information needed to reproduce the issue.
What happens to bad relays?
- After a relay is reported and behavior has been verified, the Tor Project will attempt to contact the relay operator.
- The relay will be flagged to prevent it from being used (BadExit, Invalid, Reject).
- The working group actively looks for bad relays using open source tools like exitmap, sysbilhunter.
How do I get help running a Tor relay?