commit 82c05c5ebf85e170e485a62a9744f3c55ad821a4 Author: gus gus@torproject.org Date: Thu Jul 4 18:31:48 2019 -0400
Tor relay post-install and good practices --- .../contents.lr | 175 +++++++++++++++++++++ 1 file changed, 175 insertions(+)
diff --git a/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr b/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr new file mode 100644 index 0000000..8373219 --- /dev/null +++ b/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr @@ -0,0 +1,175 @@ +_model: page +--- +title: Relay Post-install and good practices +--- +body: + +#1. Make sure relay ports can be reached + +If you are using a firewall, open a hole in your firewall so incoming connections can reach the ports you will use for your relay (ORPort, plus DirPort if you enabled it). + +Also, make sure you allow all outgoing connections too, so your relay can reach the other Tor relays, clients and destinations. + +You can find the specific ORPort TCP port number in the torrc configuration samples bellow (in the OS specific sections). + +# 2. 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. +``` + +About 3 hours after you started your relay it should appear on [Relay Search](https://metrics.torproject.org/rs.html). +You can search for your relay using your nickname or IP address. + +# 3. Read about 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). + + +#4. Optional: Limiting bandwidth usage (and traffic) + +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 +* AccountingRule +* AccountingStart +* BandwidthRate +* BandwidthBurst +* RelayBandwidthRate + +Having a fast relay for some time of the month is preferred over a slow relay for the entire month. + +Also see the bandwidth entry in the FAQ: https://www.torproject.org/docs/faq.html.en#BandwidthShaping + +# 5. Check IPv6 availability + +We encourage everyone to enable IPv6 on their relays. This is especially valuable on exit and guard relays. + +Before enabling your tor daemon to use IPv6 in addition to IPv4 you should do some basic IPv6 connectivity tests. + +The following command line will ping the IPv6 addresses of Tor directory authorities from your server: + +``` +ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && ping6 -c2 2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && ping6 -c2 2607:8500:154::3 && ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK. +``` + +At the end of the output you should see "OK." if that is not the case do not enable IPv6 in your torrc configuration file before IPv6 is indeed working. +If you enable IPv6 without working IPv6 connectivity your entire relay will not be used, regardless if IPv4 is working. + +If it worked fine, make your Tor relay reachable via IPv6 by adding an additional ORPort line to your configuration (example for ORPort 9001): + +``` +ORPort [IPv6-address]:9001 +``` + +The location of that line in the configuration file does not matter you can simply add it next to the first ORPort lins in your torrc file. + +Note: You have to explicitly specify your IPv6 address in square brackets, you can not tell tor to bind to any IPv6 (like you do for IPv4). +If you have a global IPv6 address you should be able to find it in the output of the following command: + +``` +ip addr|grep inet6|grep global +``` + +If you are an exit relay with IPv6 connectivity, tell your tor daemon to allow exiting via IPv6 so clients can reach IPv6 destinations: + +``` +IPv6Exit 1 +``` + +Note: Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only. + +# 6. Important: if you run more than one Tor instance + +To avoid putting Tor clients at risk when operating multiple relays you must set a proper [MyFamily](https://2019.www.torproject.org/docs/tor-manual.html.en#MyFamily) value and have a valid [ContactInfo](https://2019.www.torproject.org/docs/tor-manual.html.en#ContactInfo) in your torrc configuration. +The MyFamily setting is simply telling Tor clients what Tor relays are controlled by a single entity/operator/organization, so they are not used in multiple positions in a single circuit. + +If you run two relays and they have fingerprints AAAAAAAAAA and BBBBBBBB, you would add the following configuration to set MyFamily: + +``` +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 configuration management solution. +Manually managing MyFamily for big relaygroups is error prone and can put Tor clients at risk. + + +# 7. Maintaining a relay + +## Backup Tor Identity Keys + +After your initial installation and start of the tor daemon it is a good idea to make a backup of your relay's long term identity keys. +They are located in the "keys" subfolder of your DataDirectory (simply make a copy of the entire folder and store it in a secure location). +Since relays have a ramp-up time it makes sense to backup the identity key to be able to restore your relay's reputation after a disk failure - otherwise you would have to go through the ramp-up phase again. + +Default locations of the keys folder: + +* Debian/Ubuntu: `/var/lib/tor/keys` +* FreeBSD: `/var/db/tor/keys` + +## Subscribe to the tor-announce mailing list + +This is a very low traffic mailing list and you will get information about new stable tor releases and important security update information. + +* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce + +## Setting up outage notifications + +Once you setup your relay it will likely run without much work from your side. +If something goes wrong it is good to get notified automatically. +We recommend you use one of the free services that allow you to check your relay's ORPorts for reachability and send you an email should they become unreachable for what ever reason. + +[UptimeRobot](https://uptimerobot.com/) is one of these services that allow you to monitor TCP listeners on arbitrary ports. +This service can check your configured ports once every 5 minutes and send you an email should your tor process die or become unreachable. +This checks only for the listener but does not speak the Tor protocol. + +A good way to monitor a relay for its health state is to have a look at its bandwidth graphs. + +## System Health Monitoring + +To ensure your relay is healthy and not overwhelmed it makes sense to have some basic system monitoring in place to keep an eye on the following metrics: + +* Bandwidth +* Established TCP Connections +* Memory +* Swap +* CPU + +There are many tools for monitoring this kind of data, [munin](http://munin-monitoring.org/) is one of them and is relatively easy to setup. + +Note: **Do not make your private monitoring data graphs public since this could help attackers with deanonymizing Tor users.** + +Some practical advice: + +* If you want to publish traffic statistics, you should aggregate all your relays' traffic over at least a week, then round that to the nearest 10 TiB (terabytes). +* Reporting individual relays is worse than reporting totals for groups of relays. In future, tor will securely aggregate bandwidth statistics, so any individual relay bandwidth reporting will be less secure than tor's statistics. +* 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. + +## Tools + + This section lists a few tools that you might find handy as a Tor relay operator. + +* [Nyx](https://nyx.torproject.org/): is a Tor Project tool (formerly arm) that allows you to see real time data of your relay. + +* vnstat: vnstat is a command-line tool that shows the amount of data going through your network connection. +You can also use it to generate PNG pictures showing traffic graphs. [vnstat documentation](https://humdi.net/vnstat/) and [demo output](https://humdi.net/vnstat/cgidemo/). +--- +html: two-columns-page.html +--- +key: 4 +--- +section: Relay operations +--- +section_id: relay-operations +--- +subtitle: