... | ... | @@ -4,7 +4,7 @@ |
|
|
# The content on this page is no longer maintained.
|
|
|
|
|
|
|
|
|
== Using this guide ==
|
|
|
== Using this guide ==
|
|
|
This guide includes the best practices that are essential for healthy Tor relays. We've included technical steps, legal considerations, and information about running relays with others. It's organized into three parts:
|
|
|
|
|
|
* [[TorRelayGuide#Partone:decidingtorunarelay|Part one: Deciding to run a relay]]
|
... | ... | @@ -17,7 +17,7 @@ If you wish to skip directly to setting up a relay, read part two only. |
|
|
|
|
|
We use "tor" (lower case) whenever we talk specifically about the program tor (the daemon), in all other cases we use "Tor".
|
|
|
|
|
|
== Part one: deciding to run a relay ==
|
|
|
== Part one: deciding to run a relay ==
|
|
|
### Why run a Tor relay?
|
|
|
|
|
|
By running a Tor relay you can help make the Tor network:
|
... | ... | @@ -26,38 +26,38 @@ By running a Tor relay you can help make the Tor network: |
|
|
* more stable in case of outages
|
|
|
* safer for its users (spying on more relays is harder than on a few)
|
|
|
|
|
|
=== Types of nodes in the Tor network ===
|
|
|
=== Types of nodes in the Tor network ===
|
|
|
|
|
|
All nodes are important, but they have different technical requirements and legal implications. Understanding the different kinds of nodes is the first step to learning which one is right for you.
|
|
|
|
|
|
==== 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 the two. To become a guard, a relay has to be stable and fast (at least 2MByte/s) otherwise it will remain a middle 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 the two. To become a guard, a relay has to be stable and fast (at least 2MByte/s) otherwise it will remain a middle relay.
|
|
|
|
|
|
Guard and middle relays usually do not receive abuse complaints. All relays will be listed in the public list of Tor relays, so may be blocked by certain services that don't understand how Tor works or deliberately want to censor Tor users. If you are running a relay from home and have one static IP, you may want to consider running a bridge instead so that your non-Tor traffic doesn't get blocked as though it's coming from Tor. If you have a dynamic IP address or multiple static IPs, this isn't as much of an issue.
|
|
|
Guard and middle relays usually do not receive abuse complaints. All relays will be listed in the public list of Tor relays, so may be blocked by certain services that don't understand how Tor works or deliberately want to censor Tor users. If you are running a relay from home and have one static IP, you may want to consider running a bridge instead so that your non-Tor traffic doesn't get blocked as though it's coming from Tor. If you have a dynamic IP address or multiple static IPs, this isn't as much of an issue.
|
|
|
|
|
|
A non-exit Tor relay requires minimal maintenance efforts and bandwidth usage can be highly customized in the tor configuration (will be covered in more detail later in this guide). The so called "exit policy" of the relay decides if it is a relay allowing clients to exit or not. A non-exit relay does not allow exiting in its exit policy.
|
|
|
|
|
|
#### Exit relay
|
|
|
|
|
|
The exit relay is the final relay in a Tor circuit, the one that sends traffic out its destination. The services Tor clients are connecting to (website, chat service, email provider, etc) will see the IP address of the exit relay instead of their real IP address of the Tor user.
|
|
|
The exit relay is the final relay in a Tor circuit, the one that sends traffic out its destination. The services Tor clients are connecting to (website, chat service, email provider, etc) will see the IP address of the exit relay instead of their real IP address of the Tor user.
|
|
|
|
|
|
Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you the operator may receive a [DMCA notice](https://www.dmca.com/Solutions/view.aspx?ID=712f28a5-93f2-467b-ba92-3d58c8345a32&?ref=sol08a2). Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss more in legal considerations section.
|
|
|
Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you the operator may receive a [DMCA notice](https://www.dmca.com/Solutions/view.aspx?ID=712f28a5-93f2-467b-ba92-3d58c8345a32&?ref=sol08a2). Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss more in legal considerations section.
|
|
|
|
|
|
Because of the legal exposure that comes with running an exit relay, **you should not run a Tor exit relay from your home**. Ideal exit relay operators are affiliated with some institution, like a university, a library, a hackerspace or a privacy related organization. An institution can not only provide greater bandwidth for the exit, but is better positioned to handle abuse complaints or the rare law enforcement inquiry.
|
|
|
|
|
|
If you are considering running an exit relay, please read [[TorRelayGuide#Legalconsiderationsforexitrelayoperators|the section on legal considerations]] for exit relay operators.
|
|
|
|
|
|
#### Bridge
|
|
|
The design of the Tor network means that the IP address of Tor relays is public. However, one of the ways Tor can be blocked by governments or ISPs is by blacklisting the IP addresses of these public Tor nodes. Tor bridges are nodes in the network that are not listed in the public Tor directory, which make it harder for ISPs and governments to block them.
|
|
|
The design of the Tor network means that the IP address of Tor relays is public. However, one of the ways Tor can be blocked by governments or ISPs is by blacklisting the IP addresses of these public Tor nodes. Tor bridges are nodes in the network that are not listed in the public Tor directory, which make it harder for ISPs and governments to block them.
|
|
|
|
|
|
Bridges are useful for Tor users under oppressive regimes or for people who want an extra layer of security because they're worried somebody will recognize that they are contacting a public Tor relay IP address. Several countries, including China and Iran, have found ways to detect and block connections to Tor bridges. Pluggable transports (https://www.torproject.org/docs/pluggable-transports.html.en), a special kind of bridge, address this by adding an additional layer of obfuscation.
|
|
|
|
|
|
Bridges are relatively easy, low-risk and low bandwidth Tor nodes to operate, but they have a big impact on users. A bridge isn't likely to receive any abuse complaints, and since bridges are not listed in the public consensus, they are unlikely to be blocked by popular services. Bridges are a great option if you can only run a Tor node from your home network, have only one static IP, and don't have a huge amount of bandwidth to donate -- we recommend giving your bridge at least 1 Mbit/sec.
|
|
|
Bridges are relatively easy, low-risk and low bandwidth Tor nodes to operate, but they have a big impact on users. A bridge isn't likely to receive any abuse complaints, and since bridges are not listed in the public consensus, they are unlikely to be blocked by popular services. Bridges are a great option if you can only run a Tor node from your home network, have only one static IP, and don't have a huge amount of bandwidth to donate -- we recommend giving your bridge at least 1 Mbit/sec.
|
|
|
|
|
|
### Relay Requirements
|
|
|
Requirements for Tor relays depend on the type of relay and the bandwidth they provide.
|
|
|
|
|
|
|
|
|
==== Bandwidth and Connections
|
|
|
* A non-exit relay should be able to handle at least 7000 concurrent connections. This can overwhelm consumer-level routers. If you run the Tor relay from a server (virtual or dedicated) in a data center you will be fine. If you run it behind a consumer-level router at home you will have to try and see if your home router can handle it or if it starts failing. Fast exit relays (>=100 Mbit/s) usually have to handle a lot more concurrent connections (>100k).
|
|
|
|
... | ... | @@ -73,7 +73,7 @@ Every relay needs a public IPv4 address - either directly on the host (preferred |
|
|
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 (if it regularly changes more often than that, it does not make much sense to run a relay or bridge there since it takes time to distribute the new list of relay IPs to clients - which happens only once every hour).
|
|
|
|
|
|
Additional IPv6 connectivity is great and recommended/encouraged but not a requirement.
|
|
|
There should be no problem at all with this requirement (all commercially available servers come with at least one IPv4 address).
|
|
|
There should be no problem at all with this requirement (all commercially available servers come with at least one IPv4 address).
|
|
|
|
|
|
Note: You can only run two Tor relays per public IPv4 address. If you want to run more than two relays you will need more IPv4 addresses.
|
|
|
|
... | ... | @@ -90,7 +90,7 @@ Tor does not need much disk storage. A typical Tor relay needs less than 200 MB |
|
|
|
|
|
==== CPU
|
|
|
|
|
|
* Any modern CPU should be fine.
|
|
|
* Any modern CPU should be fine.
|
|
|
* It is recommended to use CPUs with AESNI support (that will improve performance and allow for up to about ~400-450 Mbps in each direction on a single tor instance on modern CPUs). If the file `/proc/cpuinfo` contains the word `aes` your CPU has support for AES-NI.
|
|
|
|
|
|
==== Uptime
|
... | ... | @@ -101,13 +101,13 @@ Tor does not need much disk storage. A typical Tor relay needs less than 200 MB |
|
|
|
|
|
For security reasons, Tor relays should not downgrade their tor version from a [[org/teams/NetworkTeam/CoreTorReleases#Listofreleases|supported]] to an unsupported version of tor. Some unsupported versions are insecure. Relays that attempt to downgrade to an insecure version will be rejected from the network automatically.
|
|
|
|
|
|
== Part two: technical setup
|
|
|
== Part two: technical setup
|
|
|
|
|
|
=== Considerations when choosing a hosting provider
|
|
|
|
|
|
If you have access to a high speed internet connection (>=100 Mbit/s in both directions) and a physical piece of computer hardware, this is the best way to run a relay. Having full control over the hardware and connection gives you a more controllable and (if done correctly) secure environment. You can host your own physical hardware at home (do NOT run a Tor exit relay from your home) or in a data center. Sometimes this is referred to as installing the relay on "bare metal".
|
|
|
|
|
|
If you do not own physical hardware, you could run a relay on a rented dedicated server or virtual private server (VPS). This can cost anywhere between $3.00/month and thousands per month, depending on your provider, hardware configuration, and bandwidth usage. Many VPS providers will not allow you to run exit relays. You must follow the VPS provider's terms of service, or risk having your account disabled. For more information on hosting providers and their policies on allowing Tor relays, please see this list maintained by the Tor community: [/wiki/doc/GoodBadISPs GoodBadISPs].
|
|
|
If you do not own physical hardware, you could run a relay on a rented dedicated server or virtual private server (VPS). This can cost anywhere between $3.00/month and thousands per month, depending on your provider, hardware configuration, and bandwidth usage. Many VPS providers will not allow you to run exit relays. You must follow the VPS provider's terms of service, or risk having your account disabled. For more information on hosting providers and their policies on allowing Tor relays, please see this list maintained by the Tor community: [/wiki/doc/GoodBadISPs GoodBadISPs].
|
|
|
|
|
|
==== Questions to consider when choosing a hoster
|
|
|
* How much monthly traffic is included? (Is bandwidth "unmetered"?)
|
... | ... | @@ -127,16 +127,16 @@ If you do not own physical hardware, you could run a relay on a rented dedicated |
|
|
|
|
|
When selecting your hosting provider, consider network diversity on an autonomous system (AS) and country level. A more diverse network is more resilient to attacks and outages. Sometimes it is not clear which AS you are buying from in case of resellers. To be sure it is best to ask the hoster about the AS number before ordering a server.
|
|
|
|
|
|
It is best to avoid hosters where many Tor relays are already hosted, but it is still better to add one there than to run no relay at all. Try to avoid the following hoster:
|
|
|
It is best to avoid hosters where many Tor relays are already hosted, but it is still better to add one there than to run no relay at all. Try to avoid the following hoster:
|
|
|
|
|
|
* OVH SAS (AS16276)
|
|
|
* OVH SAS (AS16276)
|
|
|
* Online S.a.s. (AS12876)
|
|
|
* Hetzner Online GmbH (AS24940)
|
|
|
* DigitalOcean, LLC (AS14061)
|
|
|
|
|
|
To find out which hoster and countries are already used by many other operators (that should be avoided) you can use Relay Search:
|
|
|
|
|
|
* Autonomous System Level Overview
|
|
|
* Autonomous System Level Overview
|
|
|
* https://metrics.torproject.org/rs.html#aggregate/as
|
|
|
* Country Level Overview
|
|
|
* https://metrics.torproject.org/rs.html#aggregate/cc
|
... | ... | @@ -156,7 +156,7 @@ OS configuration is outside the scope of this guide but the following points are |
|
|
|
|
|
Correct time settings are essential for Tor relays. It is recommended that you use the network time protocol (NTP) for time synchronization and ensure your timezone is set correctly.
|
|
|
|
|
|
==== Automatic Software Updates
|
|
|
==== Automatic Software Updates
|
|
|
|
|
|
One of the most imported things to keeps your relay secure is to install security updates timely and ideally automatically so you can not forget about it.
|
|
|
We collected the steps to enable automatic software updates for different operating systems:
|
... | ... | @@ -181,7 +181,7 @@ Questions you should clarify before configuring Tor: |
|
|
* What external TCP port do you want to use for incoming Tor connections? ("ORPort" configuration, we recommend port 443 if that is not used by another daemon on your server already. ORPort 443 is recommended because it is often one of the few open ports on public WIFI networks. Port 9001 is another commonly used ORPort.)
|
|
|
* What email address will you use in the ContactInfo field of your relay(s)? Note: This information will be made public.
|
|
|
* How much bandwidth/monthly traffic do you want to allow for Tor traffic?
|
|
|
* Does the server have an IPv6 address?
|
|
|
* Does the server have an IPv6 address?
|
|
|
|
|
|
The installation commands are shown in code blocks and must be executed with **root** privileges.
|
|
|
|
... | ... | @@ -201,7 +201,7 @@ The following Ansible Role has specifically been build for Tor relay operators a |
|
|
* http://github.com/nusenu/ansible-relayor
|
|
|
|
|
|
The following bash script for Debian and Ubuntu is not a configuration management but can also help you automate the steps to setup a new single Tor relay. It is meant to be run on a server that is only used for Tor.
|
|
|
* https://github.com/coldhakca/tor-relay-bootstrap
|
|
|
* https://github.com/coldhakca/tor-relay-bootstrap
|
|
|
|
|
|
==== Platform specific Instructions
|
|
|
|
... | ... | @@ -214,7 +214,7 @@ Please choose your platform: |
|
|
* [[TorRelayGuide/openSUSE|openSUSE]]
|
|
|
|
|
|
|
|
|
=== Verify that your relay works
|
|
|
=== Verify that your relay works
|
|
|
If your logfile (syslog) contains the following entry after starting your tor daemon your relay should be up and running as expected:
|
|
|
```
|
|
|
Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
|
... | ... | @@ -228,7 +228,7 @@ If you run into problems while setting up your relay you can ask your questions |
|
|
This is a great resource for asking (and answering) questions, and generally getting to know other relay operators. Make sure to check out the archives!
|
|
|
|
|
|
=== Limiting bandwidth usage (and traffic)
|
|
|
Tor will not limit its bandwidth usage by default, but supports multiple ways to restrict the used bandwidth
|
|
|
Tor will not limit its bandwidth usage by default, but supports multiple ways to restrict the used bandwidth
|
|
|
and the amount of traffic. This can be handy if you want to ensure that your Tor relay does not exceed a certain amount of bandwidth or total traffic per day/week/month. The following torrc configuration options can be used to restrict bandwidth and traffic:
|
|
|
|
|
|
* [AccountingMax](https://www.torproject.org/docs/tor-manual.html.en#AccountingMax)
|
... | ... | @@ -289,7 +289,7 @@ MyFamily AAAAAAAAAA,BBBBBBBB |
|
|
```
|
|
|
to both relays. To find your relays fingerprint you can look into the log files when tor starts up or find the file named "fingerprint" in your tor DataDirectory.
|
|
|
|
|
|
Instead of doing so manually for big operators we recommend to automate the MyFamily setting via a
|
|
|
Instead of doing so manually for big operators we recommend to automate the MyFamily setting via a
|
|
|
[[TorRelayGuide#ConfigurationManagement|configuration management solution]]. Manually managing MyFamily for big relaygroups is error prone and can put Tor clients at risk.
|
|
|
|
|
|
=== Exit Relay Configuration
|
... | ... | @@ -298,7 +298,7 @@ It is recommended that you setup exit relays on servers dedicated to this purpos |
|
|
|
|
|
==== Reverse DNS and WHOIS record
|
|
|
|
|
|
Before switching your relay to become an exit relay, ensure that you have set a clear DNS reverse (PTR) record to make it clear for everyone that this is a tor exit relay.
|
|
|
Before switching your relay to become an exit relay, ensure that you have set a clear DNS reverse (PTR) record to make it clear for everyone that this is a tor exit relay.
|
|
|
Something like "tor-exit" it its name is a good start.
|
|
|
|
|
|
If your provider offers it, make sure your WHOIS record contains clear indications that this is a Tor exit relay.
|
... | ... | @@ -315,7 +315,7 @@ DirPortFrontPage /path/to/html/file |
|
|
We offer a sample Tor exit notice HTML file, but you might want to adjust it to your needs:
|
|
|
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
|
|
|
|
|
|
Here are some more tips for running a reliable exit relay: https://blog.torproject.org/tips-running-exit-node
|
|
|
Here are some more tips for running a reliable exit relay: https://blog.torproject.org/tips-running-exit-node
|
|
|
|
|
|
==== DNS on Exit Relays
|
|
|
|
... | ... | @@ -329,7 +329,7 @@ Unlike other types of relays, exit relays also do DNS resolution for Tor clients |
|
|
* try to avoid adding too many resolvers to your /etc/resolv.conf file to limit exposure on an AS-level (try to not use more than two entries)
|
|
|
|
|
|
There are multiple options for DNS server software, unbound has become a popular one but feel free to use any other you are comfortable with. When choosing your DNS resolver software try to ensure it supports DNSSEC validation and QNAME minimisation ([RFC7816](https://tools.ietf.org/html/rfc7816)).
|
|
|
In every case the software should be installed using the OS package manager to ensure it is updated with the rest of the system.
|
|
|
In every case the software should be installed using the OS package manager to ensure it is updated with the rest of the system.
|
|
|
|
|
|
By using your own DNS resolver you are less vulnerable to DNS-based censorship that your upstream resolver might impose.
|
|
|
|
... | ... | @@ -391,7 +391,7 @@ chattr +i /etc/resolv.conf |
|
|
|
|
|
===== FreeBSD
|
|
|
|
|
|
FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely so we install the unbound package:
|
|
|
FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely so we install the unbound package:
|
|
|
```
|
|
|
pkg install unbound
|
|
|
```
|
... | ... | @@ -421,7 +421,7 @@ chflags schg /etc/resolv.conf |
|
|
|
|
|
==== Exit Policy
|
|
|
|
|
|
Define your [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy). The exit policy defines which destination ports you are willing to forward. This has an impact on the amount of abuse emails you will get (less ports means less abuse emails, but an exit relay allowing only few ports is also less useful). If you want to be a useful exit relay you must **at least allow destination ports 80 and 443.**
|
|
|
Define your [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy). The exit policy defines which destination ports you are willing to forward. This has an impact on the amount of abuse emails you will get (less ports means less abuse emails, but an exit relay allowing only few ports is also less useful). If you want to be a useful exit relay you must **at least allow destination ports 80 and 443.**
|
|
|
|
|
|
As a new exit relay - especially if you are new to your hoster - it is good to start with a reduced exit policy (to reduce the amount of abuse emails) and further open it up as you become more experienced. The reduced exit policy can be found on the following page:
|
|
|
[/wiki/doc/ReducedExitPolicy ReducedExitPolicy]
|
... | ... | @@ -434,7 +434,7 @@ ExitRelay 1 |
|
|
```
|
|
|
|
|
|
|
|
|
=== Tor relay lifecycle
|
|
|
=== Tor relay lifecycle
|
|
|
|
|
|
It takes some time for relay traffic to ramp up, this is especially true for guard relays but to a lesser extend also for exit relays. To understand this process, read about the lifecycle of a new relay: https://blog.torproject.org/lifecycle-new-relay.
|
|
|
|
... | ... | @@ -481,7 +481,7 @@ Some practical advice: |
|
|
* Smaller periods are worse.
|
|
|
* Numbers are worse than graphs.
|
|
|
* Real-time data is worse than historical data.
|
|
|
* Data in categories (IP version, in/out, etc.) is worse than total data.
|
|
|
* Data in categories (IP version, in/out, etc.) is worse than total data.
|
|
|
|
|
|
==== Tools
|
|
|
This section listsm a few tools that you might find handy as a Tor relay operator.
|
... | ... | @@ -498,11 +498,11 @@ vnstat documentation and demo output: |
|
|
== Part three: legal info, social info, and more resources
|
|
|
=== Legal considerations (for exit relay operators)
|
|
|
|
|
|
Exit relay operators should understand the potential risks associated with running an exit relay. For the majority of operators in most countries, bridges and guard/middle relays are very low risk. Exits are the ones that present some legal concerns, but operators under most circumstances will be able to handle legal matters by having an abuse response letter, running the exit from a location that isn't their home, and reading through some of the legal resources that Tor-supportive lawyers have put together.
|
|
|
Exit relay operators should understand the potential risks associated with running an exit relay. For the majority of operators in most countries, bridges and guard/middle relays are very low risk. Exits are the ones that present some legal concerns, but operators under most circumstances will be able to handle legal matters by having an abuse response letter, running the exit from a location that isn't their home, and reading through some of the legal resources that Tor-supportive lawyers have put together.
|
|
|
|
|
|
==== Legal resources
|
|
|
|
|
|
The EFF Tor Legal FAQ (https://www.torproject.org/eff/tor-legal-faq.html.en) answers many common questions about relay operation and the law. We also like Noisebridge's wiki for additional legal resources: https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI. In general it's a good idea to consult with a lawyer before deciding to operate an exit relay, especially if you live in a place where exit relay operators have been harassed, or if you're the only exit relay operator in your region. Get in touch with your local digital rights organization to see if they have recommendations about legal assistance, and if you're not sure what organizations are working in your region, write to EFF and see if they can help connect you: https://www.eff.org/about/contact.
|
|
|
The EFF Tor Legal FAQ (https://www.torproject.org/eff/tor-legal-faq.html.en) answers many common questions about relay operation and the law. We also like Noisebridge's wiki for additional legal resources: https://www.noisebridge.net/wiki/Noisebridge_Tor/FBI. In general it's a good idea to consult with a lawyer before deciding to operate an exit relay, especially if you live in a place where exit relay operators have been harassed, or if you're the only exit relay operator in your region. Get in touch with your local digital rights organization to see if they have recommendations about legal assistance, and if you're not sure what organizations are working in your region, write to EFF and see if they can help connect you: https://www.eff.org/about/contact.
|
|
|
|
|
|
Also see the [/wiki/doc/TorExitGuidelines Tor Exit Guidelines].
|
|
|
|
... | ... | @@ -538,7 +538,7 @@ Many computer science departments, university libraries, and individual students |
|
|
If you work at a Tor-friendly company or organization, that's another ideal place to run a relay. Some companies running relays inlcude Brass Horn Communications, Quintex Alliance Consulting, and OmuraVPN. Some organizations running Tor relays include Digital Courage, Access Now, Derechos Digitales, and Lebanon Libraries in New Hampshire.
|
|
|
|
|
|
### More resources
|
|
|
Congratulations, you're officially a Tor relay operator! What now?
|
|
|
Congratulations, you're officially a Tor relay operator! What now?
|
|
|
|
|
|
* You can check out traffic and other statistics for your relay at our Relay Search: https://metrics.torproject.org/rs.html (your relay will appear on "Relay Search" about 3 hours after you started it).
|
|
|
|
... | ... | |