July 2019 - tor-commits - lists.torproject.org

[community/staging] Move technical considerations to a new section
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 9b2aebc2b7e2ca0e48eedc1eb4570f70df693f62 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 11:18:19 2019 -0400 Move technical considerations to a new section --- .../technical-considerations/contents.lr | 93 ++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/content/relay-operations/technical-considerations/contents.lr b/content/relay-operations/technical-considerations/contents.lr new file mode 100644 index 0000000..b9038b9 --- /dev/null +++ b/content/relay-operations/technical-considerations/contents.lr @@ -0,0 +1,93 @@ +_model: page +--- +title: Technical considerations +--- +_template: layout.html +--- +body: + +# 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: [GoodBadISPs](FIXME). + +## Questions to consider when choosing a hoster + +* How much monthly traffic is included? (Is bandwidth "unmetered"?) +* Does the hoster provide IPv6 connectivity? (it is recommended, but not required) +* What virtualization / hypervisor (if any) does the provider use? (anything but OpenVZ should be fine) +* Does the hoster start to throttle bandwidth after a certain amount of traffic? +* How well connected is the autonomous system of the hoster? To answer this question you can use the AS rank of the autonomous systems if you want to compare: http://as-rank.caida.org/ (a lower value is better) + +## If you plan to run Exit Relays + +* Does the hoster allow Tor exit relays? (explicitly ask them before starting an exit relay there) +* Does the hoster allow custom WHOIS records for your IP addresses? This helps reduce the amount of abuse sent to the hoster instead of you. +* Does the hoster allow you to set a custom DNS reverse entry? (DNS PTR record) + + This are probably things you will need to ask the hoster in a Pre-Sales ticket + +# AS/location diversity + +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 hosters: + +* 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](https://metrics.torproject.org/rs.html#aggregate/as) +* [Country Level Overview](https://metrics.torproject.org/rs.html#aggregate/cc) + +# Choosing an Operating System + +We recommend you use the operating system you are most familiar with. + +Please keep in mind that since most relays run on Debian and we want to avoid a monoculture, BSD and other non-Linux based relays are greatly needed. + +The following table shows the current OS distribution on the Tor network to give you an idea of how much more non-Linux relays we should have: + +* https://nusenu.github.io/OrNetStats/#os-distribution-relays + +# OS Level Configuration + +OS configuration is outside the scope of this guide but the following points are crucial for a Tor relay, so we want to mention them here nonetheless. + +## Time Synchronization (NTP) + +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 + +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: + +* [RPM-based distributions](FIXME) (RHEL, CentOS, Fedora, openSUSE) +* [Debian/Ubuntu](FIXME) +* [FreeBSD/HardenedBSD](FIXME) + +--- +html: two-columns-page.html +--- +section: relay operations +--- +section_id: relay-operations +--- +key: 2

1 0

[community/staging] Migrate content from trac.tpo to lektor
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 0289c3bd83a8f7b78934f59381d4c70babcef513 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 18:27:25 2019 -0400 Migrate content from trac.tpo to lektor --- .../community-resources/contents.lr | 54 ++++++++++++++++++++-- 1 file changed, 51 insertions(+), 3 deletions(-) diff --git a/content/relay-operations/community-resources/contents.lr b/content/relay-operations/community-resources/contents.lr index 6727391..145ee9e 100644 --- a/content/relay-operations/community-resources/contents.lr +++ b/content/relay-operations/community-resources/contents.lr @@ -6,14 +6,62 @@ color: primary --- _template: layout.html --- -title: Tor relay community resources +title: Community and legal resources --- subtitle: How to get involved with the Tor relay operator community, advice on responding to abuse complaints, and how to start an organization dedicated to relay operation. --- -key: 4 +key: 5 --- html: two-columns-page.html --- body: -text +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. + +Also see the [TorExitGuidelines Tor Exit Guidelines](FIXME). + +# Responding to abuse complaints + +Operators can put together their own abuse complaint template responses from one of many templates that Tor has created: [TorAbuseTemplates](tor-abuse-templates). + +It is important to respond to abuse complaints in a timely manner (usually within 24 hours). If the hoster gets annoyed by the amount of abuse you can reduce the amount of ports allowed in your exit policy. Please document your experience with new hosters on the following wiki page: [GoodBadISPs](FIXME) + +Other docs we like: + +* a letter Boing Boing used to respond to a US federal subpoena about their exit relay: https://boingboing.net/2015/08/04/what-happened-when-the-fbi-sub.html +* abuse response templates from Coldhak, an organization in Canada that runs multiple relays: https://github.com/coldhakca/abuse-templates/blob/master/dmca.template, https://github.com/coldhakca/abuse-templates/blob/master/generic.template + +# Running a relay with other people + +Running relays is more fun with other people! You can work with your university department, your employer or institution, or an organization like Torservers.net to run a relay. + +## Torservers.net + +Torservers is an independent, global network of organizations that help the Tor network by running high bandwidth Tor relays. Becoming a Torservers partner is a good way to become more involved in the Tor relay community, and can help you connect with dedicated relay operators around the world for solidarity and support. To start a Torservers partner, the most important thing is to have a group of people (3-5 suggested to start) interested in helping with the various activities required for running relays. There should be mutual trust between the people in the group, and members should commit to running relays for the long term. If you do not know anyone in your social network interested in running relays, one place to meet people is your local hackerspace: https://wiki.hackerspaces.org/Hackerspaces. + +Once you have a trusted group of people, depending on your region, it is often advised to create some type of non-profit corporation. This is useful for having a bank account, shared ownership, grant applications, etc. In many countries operating as a corporation instead of as an individual can also get you certain legal protections. + +The next steps are figuring out hardware, transit, and server hosting. Depending on your location and connections within the technical community of the area, the last one may be the hardest step. Small local ISPs often have extra bandwidth, and may be interested in supporting your group with some bandwidth or rackspace. It is extremely important to maintain good relationships with these ISPs. + +## At your university + +Many computer science departments, university libraries, and individual students and faculty run relays from university networks. These universities include the Massachusetts Institute of Technology (MIT CSAIL), Boston University, the University of Waterloo, the University of Washington, Northeastern University, Karlstad University, Universitaet Stuttgart, and Friedrich-Alexander University Erlangen-Nuremberg. To learn more about how to get support for a relay on your university's network, check out EFF's resources: https://www.eff.org/torchallenge/tor-on-campus.html. + +## At your company or organization + +If you work at a Tor-friendly company or organization, that's another ideal place to run a relay. Some companies running relays include 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? + +* 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). + +* There is also more info about running a relay at the [Tor FAQ](https://www.torproject.org/docs/faq.html.en#HowDoIDecide). + +* And, most importantly, make sure to email tshirt(a)torproject.org and [claim your swag](https://www.torproject.org/getinvolved/tshirt.html). It's our way of saying thanks for defending privacy and free speech online. +

1 0

[community/staging] fixed page layout freebsd page
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 1edd37959c50d2915ddc3f6d3e8b71a36fbefae2 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 10:26:04 2019 -0400 fixed page layout freebsd page --- content/relay-operations/technical-setup/freebsd/contents.lr | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/relay-operations/technical-setup/freebsd/contents.lr b/content/relay-operations/technical-setup/freebsd/contents.lr index c03b579..3323fd5 100644 --- a/content/relay-operations/technical-setup/freebsd/contents.lr +++ b/content/relay-operations/technical-setup/freebsd/contents.lr @@ -70,6 +70,6 @@ FreeBSDlatest: { ``` --- -_template: +_template: layout.html --- -color: primary +color:

1 0

[community/staging] add FreeBSD relay instructions
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 8ff05bb00812de2c9deaa52ce71c342d927d33ff Author: gus <gus(a)torproject.org> Date: Thu Jul 4 09:47:46 2019 -0400 add FreeBSD relay instructions --- .../technical-setup/freebsd/contents.lr | 66 +++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/content/relay-operations/technical-setup/freebsd/contents.lr b/content/relay-operations/technical-setup/freebsd/contents.lr index d1afab0..c03b579 100644 --- a/content/relay-operations/technical-setup/freebsd/contents.lr +++ b/content/relay-operations/technical-setup/freebsd/contents.lr @@ -6,6 +6,70 @@ html: two-columns-page.html --- section: relay operations --- -key: 7 +key: 2 --- section_id: relay-operations +--- +body: + +## 1. Install the tor package + +`pkg install tor ca_root_nss` + +or for alpha releases: + +`pkg install tor-devel ca_root_nss` + +## 2. Put the configuration file `/usr/local/etc/tor/torrc` in place + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 9001 +ExitRelay 0 +SocksPort 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +Log notice syslog +``` + +## 3. 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 +``` + +## 4. Start the tor daemon and make sure it starts at boot: + +``` +sysrc tor_enable=YES +service tor start +``` + +### Optional but recommended + +To get package updates faster after they have been build it is best to switch from the "quarterly" with "latest" repository. + +Create the following folder: + +`mkdir -p /usr/local/etc/pkg/repos` + +and create the file `/usr/local/etc/pkg/repos/FreeBSD.conf` with the following content: + +``` +FreeBSD: { enabled: no } + +FreeBSDlatest: { + url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest", + mirror_type: "srv", + signature_type: "fingerprints", + fingerprints: "/usr/share/keys/pkg", + enabled: yes +} +``` + +--- +_template: +--- +color: primary

1 0

[community/staging] add centos relay instructions
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 8efc156a0fa9494da51a7d4969928cbcb9db08cd Author: gus <gus(a)torproject.org> Date: Thu Jul 4 10:20:11 2019 -0400 add centos relay instructions --- .../technical-setup/centosrhel/contents.lr | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/content/relay-operations/technical-setup/centosrhel/contents.lr b/content/relay-operations/technical-setup/centosrhel/contents.lr index af9f706..e8a9a51 100644 --- a/content/relay-operations/technical-setup/centosrhel/contents.lr +++ b/content/relay-operations/technical-setup/centosrhel/contents.lr @@ -11,3 +11,48 @@ key: 5 section_id: relay-operations --- body: + +# 1. Enable the EPEL repository + +To install `tor` package on CentOS/RHEL, you need to install the [EPEL](https://fedoraproject.org/wiki/EPEL) repository first: + +`yum install epel-release` + +# 2. Install the tor package and verify the EPEL signing key + +`yum install tor` + +When you install the first package from the EPEL repository you will be asked about verifying the EPEL GPG signing key. Please ensure the key matches with the one available on the [Fedora Project website](https://getfedora.org/keys/). + +# 3. Put the tor configuration file `/etc/tor/torrc` in place + +``` +#change the nickname "myNiceRelay" to a name that you like +Nickname myNiceRelay +ORPort 9001 +SocksPort 0 +ExitRelay 0 +# Change the email address bellow and be aware that it will be published +ContactInfo tor-operator@your-emailaddress-domain +``` + +# 4. Enable and start your Tor relay + +CentOS 7 / RHEL 7: + +``` +systemctl enable tor +systemctl start tor +``` + +CentOS 6 / RHEL 6: + +``` +service tor enable +service tor start +``` + +--- +_template: layout.html +--- +color: primary

1 0

[community/staging] Migrate content Tor Abuse Templates to lektor
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit e3d4792e9f9ce7e61686c22a58030efe3f8a51f1 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 18:27:51 2019 -0400 Migrate content Tor Abuse Templates to lektor --- .../tor-abuse-templates/contents.lr | 302 +++++++++++++++++++++ 1 file changed, 302 insertions(+) diff --git a/content/relay-operations/community-resources/tor-abuse-templates/contents.lr b/content/relay-operations/community-resources/tor-abuse-templates/contents.lr new file mode 100644 index 0000000..475651b --- /dev/null +++ b/content/relay-operations/community-resources/tor-abuse-templates/contents.lr @@ -0,0 +1,302 @@ +_model: page +--- +title: Tor Abuse Templates +--- +body: + +# Before You Start + +The best way to handle abuse complaints is to set up your exit node so that they are less likely to be sent in the first place. Please see [Tips for Running an Exit Node with Minimal Harassment](https://blog.torproject.org/running-exit-node ) and [Tor Exit Guidelines](https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidel… for more info, before reading this document. + +Below are a collection of letters you can use to respond to your ISP about their complaint in regards to your Tor exit server. + +## Format and Philosophy of Templates + +The general format of these templates is to inform the complaintant about Tor, to help them to find a solution to their particular issue that works in general for the Internet at large (open wifi, open proxies, botnets, etc), and barring all else, how to block Tor. The philosophy of the Tor Project is that abuse should be handled proactively by the site administrators, rather than wasting effort and resources on seeking vengeance and chasing ghosts. + +The difference between the proactive approach and the reactive approach to abuse is the difference between decentralized fault-tolerant Internet freedom, and fragile, corruptible totalitarian control. To further preach to the choir, the identity-based Internet "driver's licenses" of South Korea and China have done nothing to curtail cybercrime and Internet abuse. In fact, all [http://boingboing.net/2011/08/12/south-korea-to-abandon-real-name-internet-… objective evidence] seems to indicate that it has only created new markets for organized crime to preside over. This is the core idea that these abuse complaint templates attempt to instil in the recipient. Feel free to improve them if you feel they fall short of this goal. + +All templates should include the Common Boilerplate below, and append some additional paragraphs depending on the specific Scenario. + +## Common Boilerplate (Tor Intro) + +``` +The IP address in question is a Tor exit node. +https://www.torproject.org/overview.html + +There is little we can do to trace this matter further. As can be seen +from the overview page, the Tor network is designed to make tracing of +users impossible. The Tor network is run by some 5000 volunteers who +use the free software provided by the Tor Project to run Tor routers. +Client connections are routed through multiple relays, and are +multiplexed together on the connections between relays. The system +does not record logs of client connections or previous hops. + +This is because the Tor network is a censorship resistance, privacy, +and anonymity system used by whistle blowers, journalists, Chinese +dissidents skirting the Great Firewall, abuse victims, stalker +targets, the US military, and law enforcement, just to name a few. +See https://www.torproject.org/about/torusers.html.en for more info. + +Unfortunately, some people misuse the network. However, compared to +the rate of legitimate use (the IP range in question processes nearly +a gigabit of traffic per second), abuse complaints are rare. +https://www.torproject.org/docs/faq-abuse.html.en +``` + +## Abuse Scenarios + +The following scenario-specific paragraphs should be appended to the Common Boilerplate paragraphs above. The common boilerplate should be abridged or be omitted if the abuse complaintant is already familiar with Tor. + +## Comment/Forum Spam + +``` +This does not mean that nothing can be done, however. + +The Tor project provides an automated DNSRBL for you to query to flag +posts coming from Tor nodes as requiring special review. You can also +use this DNSRBL to only allow Tor IPs to read but not +post comments. https://www.torproject.org/projects/tordnsel.html.en + +However, be aware that this may be just one jerk amongst many +legitimate Tor users who use your forums. You might have luck getting +rid of this jerk by temporarily limiting account creation to require +Gmail accounts before posting, or by requiring account creation be +done over non-Tor before posting. + +In general, we believe that problems like this are best solved by +improving your service to defend against the attack from the Internet +at large. Brute force login attempts can be reduced/slowed by +captchas, which is the approach taken by Gmail for this same problem. +In fact, Google provides a free captcha service, complete with code +for easy inclusion in a number of systems to help other sites deal +with this issue: https://code.google.com/apis/recaptcha/intro.html + +``` + +## PHP Relay or Exploited Webmail Account Spam + +``` +In addition, our nodes do not allow SMTP traffic to be sent using our IPs. +Upon investigation, it appears that the source of the spam is due to +an abusive or compromised webmail gateway running at: +<web server here>. Did you contact their abuse department? +``` + +## Google Groups Spam + +``` +It appears that your specific abuse complaint was generated by an +authenticated Google Groups user. Inspecting the headers reveals that +the abuse complaint address for Google Groups is +groups-abuse(a)google.com. Contacting this address will give you better +luck at actually having this abuser's Google Groups account canceled +than will chasing down Tor nodes, proxies, and open wireless access +points. + +Additionally, if your news reader supports killfiles, you may be +interested in using the Tor Bulk Exit list script to download a list of +IPs to include in your killfile for posts that match "NNTP-Posting-Host: +<ip>" https://check.torproject.org/cgi-bin/TorBulkExitList.py +``` +## DoS Attacks and Scraping Robots + +``` +We're sorry your site is experiencing this heavy load from Tor. + +However, it is possible that your rate limiting alarms simply +experienced a false positive due to the amount of traffic that flows +through the router. We provide service to almost a gigabit of traffic +per second, 98% of which is web traffic. + +If the attack is real and ongoing, however, the Tor project provides +an automated DNSRBL for you to query to block login attempts coming +from Tor nodes: https://www.torproject.org/projects/tordnsel.html.en + +It is also possible to download a list of all Tor exit IPs that will +connect to your server port: +https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=YOUR_IP&port=80 + +In general however, we believe that problems like this are best solved +by improving the service to defend against the attack from the Internet +at large. + +Scraping and robot activity can be reduced/slowed by captchas, which is +the approach taken by Gmail for this same problem. In fact, Google +provides a free captcha service, complete with code for easy inclusion +in a number of systems to help other sites deal with this issue: +https://code.google.com/apis/recaptcha/intro.html + +Slow DoS attacks aimed to consume the Apache MaxClients limit +(http://www.guerilla-ciso.com/archives/2049) can be alleviated by +reducing the httpd.conf TimeOut and KeepAliveTimeout config values +to 15-30 and raising the ServerLimit and MaxClients values to +something like 3000. + +If this fails, DoS attempts can also be solved with iptables-based rate +limiting solutions, load balancers such as nginx, and also IPS devices, +but be aware that Internet traffic is not always uniform in quantity by +IP, due to large corporate and even national outproxies, NATs, and +services like Tor. +http://kevin.vanzonneveld.net/techblog/article/block_brute_force_attacks_with_iptables/ +http://cd34.com/blog/webserver/ddos-attack-mitigation/ +http://deflate.medialayer.com/ + +``` + +## Brute Force Web Attacks + +``` +We're sorry your account has been brute forced. We can try to prevent +our node from connecting to this site, but since the Tor network +has 800 or so exits, doing so wouldn't really stop the action long +term. The attacker would probably just chain an open proxy after Tor, +or just use open wireless and/or a proxy without Tor. + +The Tor project does provide an automated DNSRBL for you to query to +flag requests from Tor nodes as requiring special treatment: +https://www.torproject.org/projects/tordnsel.html.en + +In general, we believe that problems like this are best solved by +improving the service to defend against the attack from the Internet +at large rather than specifically tailoring behavior for Tor. Brute +force login attempts can be reduced/slowed by captchas, which is the +approach taken by Gmail for this same problem. In fact, Google +provides a free captcha service, complete with code for easy inclusion +in a number of systems to help other sites deal with this issue: +https://code.google.com/apis/recaptcha/intro.html +``` + +## SSH Bruteforce Attempts + +``` +If you are concerned about SSH scans, you might consider running your +SSHD on a port other than the default of 22. Many worms, scanners, and +botnets scan the entire Internet looking for SSH logins. The fact that +a few logins happened to come from Tor is likely a small blip on your +overall login attempt rate. You might also consider a rate limiting +solution: +https://kvz.io/blog/2007/07/28/block-brute-force-attacks-with-iptables/ + +If it is in fact a serious problem specific to Tor, the Tor project +provides an automated DNSRBL for you to query to block login attempts +coming from Tor nodes: https://www.torproject.org/projects/tordnsel.html.en + +It is also possible to download a list of all Tor exit IPs that will +connect to your SSH port: +https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=YOUR_IP&port=22 + +You can use this list to create iptables rules to block the network. +However, we still recommend using the general approach, as the attack +will likely simply reappear from an open proxy or other IP once Tor +is blocked. +``` + +## Hacked Gmail, Web Forum, or Misc Account Access + +``` +With respect to your account, given that the attacker used Tor +and not a large botnet (or your machine's IP itself), it is likely +that your password was either harvested off of your machine from a +keylogger, or it was captured via a kiosk, or from open wireless. + +Our recommendation is to treat this event as though there was a login +from an open wireless access point in your city. Reset your password, +and if you don't have antivirus already, download the free AVG: +http://free.avg.com/us-en/download, Spybot SD: +http://www.safer-networking.org/nl/home/index.html, and/or AdAware: +http://www.lavasoft.com/?domain=lavasoftusa.com. Use these to scan to +check for keyloggers or spyware that someone with access to your +computer may have installed. + +To help protect yourself while using open wireless, consider using this +Firefox plugin: https://www.eff.org/https-everywhere/ and encourage the +site maintainer to support HTTPS logins. +``` + +## Hacking (PHP Webshells, XSS, SQL Injection) + +``` +This also does not mean that there is nothing that can be done. For +serious incidents, traditional police work techniques of running +stings and investigating to determine means, motive, and opportunity +are still very effective. + +Additionally, the Tor project provides an automated DNSRBL for you to +query to flag visitors coming from Tor nodes as requiring special +treatment: https://www.torproject.org/projects/tordnsel.html.en. The same list is +available through the Tor Bulk Exit List: +https://check.torproject.org/cgi-bin/TorBulkExitList.py + +However, rather than banning legitimate Tor users from using your +service in general, we recommend ensuring that such services are updated +and maintained to free of vulnerabilities that can lead to +situations such as this (PHP webshell/XSS compromise/SQL Injection +compromise). +``` + +## E-Commerce Fraud + +``` +This also does not mean that there is nothing that can be done. For +serious incidents, traditional police work techniques of running +stings and investigating to determine means, motive, and opportunity +are still very effective. + +Additionally, the Tor project provides an automated DNSRBL for you to +query to flag orders coming from Tor nodes as requiring special +review: https://www.torproject.org/projects/tordnsel.html.en + +It also provides a Bulk Exit List service for retrieving the entire list: +https://check.torproject.org/cgi-bin/TorBulkExitList.py + +You can use this list to help you take a closer look at Tor orders, or +to hold them temporarily for additional verification, without losing +legitimate customers. + +In fact, in my experience, the fraud processing teams contracted by +many ISPs simply mark all requests from Tor nodes as fraud using that +very list. So it is even possible this is a legitimate order, but was +flagged as fraud solely based on IP, especially if you contract out +fraud detection to a third party. +``` + +## Threats of Violence (Advice for Real-Time Discussion) + +If a serious abuse complaint not covered by this template set arrives, the best answer is to follow a pattern with the complaining party. This is not legal advice. This was not written or reviewed by a lawyer. It was written by someone with experience in working with various ISPs who had issues with a Tor exit node on their network. It has also been reviewed by someone who works in Abuse at a major ISP. + + * Read the [Tor Overview](https://2019.www.torproject.org/about/overview.html.en). Be prepared to summarize and answer basic questions. Assume the person with which you're going to converse knows nothing about Tor. Assume this same person isn't going to trust anything you say. + * In serious cases, such as harassment email or death threats, it is often helpful to draw an analogy to situations in the physical world where an action is perpetrated by an anonymous individual (such as delivering the notice via postal mail). + * Remind them that traditional policework can still be used to determine who had the means, motive, and opportunity to commit the crime. + * Arrange to talk with or directly email the complaintant. + * During the conversation make sure you explain a few points: + * You are not the perpetrator of the issue. + * You are a responsible server operator and concerned about the complaintant's problem. + * You are not insane. You may be insane, but we don't want the complaintant to guess this is true. + * In many cases, your ISP will be involved as a conduit for the 3rd party complaintant. Your ISP wants to know: + * Your server is not compromised. + * Your server is not a spam relay. + * Your server is not a trojan/zombie. + * You are a competent server administrator and can address the issue. Minimally, you can at least discuss and respond to the issue intelligently. + * The ISP is not at fault and not liable for your actions. This is normally the case, but the poor abuse person dealing with the issues just wants to hear it isn't the ISPs problem. They will move on after they are comfortable. + * Discuss options. Options Phobos has been offered: + * The ISP/Complaintant may very well demand to see logfiles. Fortunately, by default, nothing sensitive disclosed. You may want a new ISP if they demand access to log files ad hoc. + * The ISP/Complaintant suggests you convert to middleman. In this case, you may want to counter with a reduced exit policy, such as the one suggested in [https://blog.torproject.org/running-exit-node item #6 of the above blog post]. + * The ISP/Complaintant demands you disable Tor. You may want a new ISP as a result. + * The ISP/Complaintant states they will firewall off the traffic on the default ports. You may want a new ISP as a result. + * Update the config to disallow traffic to a certain IP range from your exit node. You may want to suggest the complaintant use the [Tor DNS RBL](https://www.torproject.org/projects/tordnsel.html.en ) instead. + * After all has been discussed, offer a follow up conversation within a week. Make sure your agreed upon changes are implemented. Neither the ISP nor Complaintant may want to do this, but the fact that you offered is in your credit. This may help them feel "comfortable" with you. + + +## Other Template Sets + + * [DMCA Response template for Tor node maintainer to ISP](FIXME) as written by the [EFF](http://www.eff.org EFF). + * Moritz Bartl, the operator of some of our fastest Tor exit nodes, has begun compiling a [set of abuse response template emails](https://www.torservers.net/wiki/abuse/templates) as well. +--- +html: two-columns-page.html +--- +key: 1 +--- +section_id: community-resources +--- +subtitle: How to handle abuse complaints

1 0

[community/staging] add subtitles to technical considerations page
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 6bd93658bd3f6d9872aa647f95d7ce6fc87db464 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 11:29:38 2019 -0400 add subtitles to technical considerations page --- content/relay-operations/technical-considerations/contents.lr | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/relay-operations/technical-considerations/contents.lr b/content/relay-operations/technical-considerations/contents.lr index b9038b9..9951d45 100644 --- a/content/relay-operations/technical-considerations/contents.lr +++ b/content/relay-operations/technical-considerations/contents.lr @@ -91,3 +91,5 @@ section: relay operations section_id: relay-operations --- key: 2 +--- +subtitle: How to choose a good hosting provider, what's AS and Operating System diversity.

1 0

[community/staging] re-organizing relay operations content in different sections
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 17c52e2530235f7e8de01b5fd9540bbd5a25dba1 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 18:28:34 2019 -0400 re-organizing relay operations content in different sections --- content/relay-operations/contents.lr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/relay-operations/contents.lr b/content/relay-operations/contents.lr index 1e133d1..f55c8ed 100644 --- a/content/relay-operations/contents.lr +++ b/content/relay-operations/contents.lr @@ -29,4 +29,4 @@ 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) -Running a relay requires technical skill and commitment, which is why we've created a wealth of resources to help our relay operators. \ No newline at end of file +Running a relay requires technical skill and commitment, which is why we've created a wealth of resources to help our relay operators.

1 0

[community/staging] Reorganize Relay Operations sections
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit cc258e468f192b730e24446d77ebe3e7f38cc734 Author: gus <gus(a)torproject.org> Date: Thu Jul 4 18:35:29 2019 -0400 Reorganize Relay Operations sections --- .../relay-operations/technical-setup/contents.lr | 444 +-------------------- 1 file changed, 9 insertions(+), 435 deletions(-) diff --git a/content/relay-operations/technical-setup/contents.lr b/content/relay-operations/technical-setup/contents.lr index 65d44fc..07925c7 100644 --- a/content/relay-operations/technical-setup/contents.lr +++ b/content/relay-operations/technical-setup/contents.lr @@ -4,106 +4,28 @@ section_id: relay-operations --- color: primary --- -key: 3 +key: 4 --- _template: layout.html --- title: Technical setup --- -subtitle: Installing and configuring your Tor relay. +subtitle: Installing and configuring your Tor relay: Bridge, Guard / Middle node, Exit. --- html: two-columns-page.html --- body: -# 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: [GoodBadISPs](FIXME). - -## Questions to consider when choosing a hoster - -* How much monthly traffic is included? (Is bandwidth "unmetered"?) -* Does the hoster provide IPv6 connectivity? (it is recommended, but not required) -* What virtualization / hypervisor (if any) does the provider use? (anything but OpenVZ should be fine) -* Does the hoster start to throttle bandwidth after a certain amount of traffic? -* How well connected is the autonomous system of the hoster? To answer this question you can use the AS rank of the autonomous systems if you want to -compare: http://as-rank.caida.org/ (a lower value is better) - -## If you plan to run Exit Relays - -* Does the hoster allow Tor exit relays? (explicitly ask them before starting an exit relay there) -* Does the hoster allow custom WHOIS records for your IP addresses? This helps reduce the amount of abuse sent to the hoster instead of you. -* Does the hoster allow you to set a custom DNS reverse entry? (DNS PTR record) - This are probably things you will need to ask the hoster in a Pre-Sales ticket - -# AS/location diversity - -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 hosters: - -* 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](https://metrics.torproject.org/rs.html#aggregate/as) -* [Country Level Overview](https://metrics.torproject.org/rs.html#aggregate/cc) - -# Choosing an Operating System - -We recommend you use the operating system you are most familiar with. -Please keep in mind that since most relays run on Debian and we want to avoid a monoculture, BSD and other non-Linux based relays are greatly needed. - -The following table shows the current OS distribution on the Tor network to give you an idea of how much more non-Linux relays we should have: - -* https://nusenu.github.io/OrNetStats/#os-distribution-relays - -# OS Level Configuration - -OS configuration is outside the scope of this guide but the following points are crucial for a Tor relay, so we want to mention them here nonetheless. - -## Time Synchronization (NTP) - -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 - -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: - -* [RPM-based distributions](FIXME) (RHEL, CentOS, Fedora, openSUSE) -* [Debian/Ubuntu](FIXME) -* [FreeBSD/HardenedBSD](FIXME) - -# Tor Relay Setup: Installation and Configuration - This section covers the installation and configuration of the program required to run a Tor relay for various operating systems. + These steps are intended for the latest stable version of the given OS, on Ubuntu for the latest LTS release. Note: For some operating systems, there are alpha version packages available (tor versions with new features not deemed to be stable yet). + These are only recommended for people eager to test and report bugs in bleeding edge releases/features. If you are looking to run a relay with minimal effort we recommend you stick to stable releases. -In this guide we describe how to setup a new non-exit relay. -By reading further you can easily switch to become an exit relay. - -**Questions you should clarify before configuring Tor:** +# Questions you should clarify before configuring Tor * Do you want to run a Tor exit or non-exit (guard/middle) relay? * If you want to run an exit relay: Which ports do you want to allow in your exit policy? (more ports usually means potentially more abuse complains) @@ -116,362 +38,14 @@ By reading further you can easily switch to become an exit relay. The installation commands are shown in code blocks and must be executed with root privileges. -## 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). - ## Configuration Management -Tor does not scale well on multi-core machines. -If you run a Tor relay on a server with a fast Internet uplink (>200 Mbit/s) you might want to consider running multiple Tor instances on a single server with multiple cores. -Note: You can only run two tor instances per public IPv4 address. - If you plan to run more than a single relay, or you want to run a high capacity relay (multiple Tor instances per server) or want to use strong security features like [Offline Master Keys](https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/Of… without performing additional steps manually, you may want to use a configuration management for better maintainability. There are multiple configuration management solutions for Unix based operating systems (Ansible, Puppet, Salt, ...). -The following Ansible Role has specifically been build for Tor relay operators and supports multiple operating systems: - -http://github.com/nusenu/ansible-relayor - -## Platform specific Instructions - -Please choose your platform: - -* Debian/Ubuntu -* CentOS/RHEL -* Fedora -* FreeBSD -* openSUSE - -## 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. - -# Getting Help - -If you run into problems while setting up your relay you can ask your questions on the public tor-relays mailing list: - -* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays - -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 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 - -# IPv6 - -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. - -# 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#Contac… 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. - -# Exit Relay Configuration - -It is recommended that you setup exit relays on servers dedicated to this purpose. It is not recommended to install Tor exit relays on servers that you need for other services as well. -Do not mix your own traffic with your exit relay traffic. - -## 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. -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. - -## Exit Notice HTML page +The following Ansible Role has specifically been build for Tor relay operators and supports multiple operating systems: [Ansible Relayor](http://github.com/nusenu/ansible-relayor). -To make it even more obvious that this is a Tor exit relay you should serve a Tor exit notice HTML page. -Tor can do that for you if your DirPort is on TCP port 80, you can make use of tor's DirPortFrontPage feature to display a HTML file on that port. -This file will be shown to anyone directing his browser to your Tor exit relay IP address. - -``` -DirPort 80 -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 - -## Exit Policy - -Defining the [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy) is one of the most important parts of an exit relay configuration. -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 [ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/Reduce… wiki page. - -To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration file and restart the tor daemon. - -``` -ExitRelay 1 -``` - -## DNS on Exit Relays - -Unlike other types of relays, exit relays also do DNS resolution for Tor clients. -DNS resolution on exit relays is crucial for Tor clients, it should be reliable and fast by using caching. - -* DNS resolution can have a significant impact on the performance and reliability your exit relay provides. Poor DNS performance will result in less traffic going through your exit relay. -* Don't use any of the big DNS resolvers as your primary or fallback DNS resolver to avoid centralization (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6) -* We recommend running a local caching and DNSSEC-validating resolver without using any forwarders (specific instructions follow bellow for each operating systems) -* if you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, try to choose a resolver within your autonomous system and make sure it is not your first entry in that file (the first entry should be your local resolver) -* if a local resolver like unbound is not an option for you try to use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up, using for example https://bgp.he.net) -* 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). -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. - -Here follow specific instructions on how to install and configure unbound on your exit - a DNSSEC-validating and caching resolver. unbound has many configuration and tuning nobs but we try to keep these instructions as simple and short as possible and the basic setup will do just fine for most operators. - -After switching to unbound verify it works as expected by resolving a valid hostname, if it does not work, you can restore the old resolv.conf file. - -### Debian/Ubuntu - -The following 3 commands install unbound, backup your DNS configuration and tell the system to use the local unbound: - -``` -apt install unbound -cp /etc/resolv.conf /etc/resolv.conf.backup -echo nameserver 127.0.0.1 > /etc/resolv.conf -``` - -To avoid that the configuration gets changed (for example by the DHCP client): - -``` -chattr +i /etc/resolv.conf -``` - -The Debian configuration ships with QNAME minimisation (RFC7816) enabled by default so you don't need to enable it explicitly. -The unbound resolver you just installed does also DNSSEC validation. - -### CentOS/RHEL - -Install the unbound package: - -``` -yum install unbound -``` - -in /etc/unbound/unbound.conf replace the line - -``` -# qname-minimisation: no -``` - -with: - -``` -qname-minimisation: yes -``` - -enable and start unbound: - -``` -systemctl enable unbound -systemctl start unbound -``` - -Tell the system to use the local unbound server: - -``` -cp /etc/resolv.conf /etc/resolv.conf.backup -echo nameserver 127.0.0.1 > /etc/resolv.conf -``` - -To avoid that the configuration gets changed (for example by the DHCP client): - -``` -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: - -``` -pkg install unbound -``` - -Replace the content in /usr/local/etc/unbound/unbound.conf with the following lines: - -``` -server: - verbosity: 1 - qname-minimisation: yes -``` - -enable and start the unbound service: - -``` -sysrc unbound_enable=YES -service unbound start -``` - -Tell the system to use the local unbound server: - -``` -cp /etc/resolv.conf /etc/resolv.conf.backup -echo nameserver 127.0.0.1 > /etc/resolv.conf -``` - -To avoid that the configuration gets changed (for example by the DHCP client): - -``` -chflags schg /etc/resolv.conf -``` - -# 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 - -# 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 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. - -* https://uptimerobot.com/ - -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 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 listsm a few tools that you might find handy as a Tor relay operator. - -Nyx: [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 and demo output: - -* https://humdi.net/vnstat/ -* https://humdi.net/vnstat/cgidemo/ +Click below in which type of relay do you want to host. +--- +_slug: {{setup}}

1 0

[community/staging] Tor relay post-install and good practices
by hiro＠torproject.org 05 Jul '19

05 Jul '19

commit 82c05c5ebf85e170e485a62a9744f3c55ad821a4 Author: gus <gus(a)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#Contac… 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:

1 0