Commit c4d75334 authored by Hiro's avatar Hiro 🏄
Browse files

Remove duplicate content for real

parent 09753a20
section: outreach
---
section_id: outreach
---
color: primary
---
_template: layout.html
---
title: Speakers
---
subtitle: Speakers
---
key: 2
---
html: two-columns-page.html
---
body:
## Speakers
_model: page
---
title: CentOS / RHEL / OpenSUSE
---
body:
# 1. Install tor and dependencies
* Redhat / RHEL:
```
yum install epel-release
yum install git golang tor
```
* OpenSUSE:
```
zypper install tor go git
```
# 2. Build obfs4proxy and move it into place.
Heavily outdated versions of git can make `go get` fail, so try upgrading to a more recent git version if you're running into this problem.
* CentOS / RHEL:
```
export GOPATH=`mktemp -d`
go get gitlab.com/yawning/obfs4.git/obfs4proxy
sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin/
chcon --reference=/usr/bin/tor /usr/local/bin/obfs4proxy
```
* OpenSUSE:
```
export GOPATH=`mktemp -d`
go get gitlab.com/yawning/obfs4.git/obfs4proxy
sudo cp $GOPATH/bin/obfs4proxy /usr/local/bin/
```
# 3. Edit your Tor config file, usually located at `/etc/tor/torrc` and add the following lines:
```
#Bridge config
RunAsDaemon 1
ORPort auto
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
# For a fixed obfs4 port (e.g. 34176), uncomment the following line.
#ServerTransportListenAddr obfs4 0.0.0.0:34176
# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means
# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto
# Contact information that allows us to get in touch with you in case of
# critical updates or problems with your bridge. This is optional, so you
# don't have to provide an email address if you don't want to.
ContactInfo <address@email.com>
# Pick a nickname that you like for your bridge.
Nickname PickANickname
```
Don't forget to change the ContactInfo and Nickname options.
* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports.
# 4. Restart tor
`systemctl restart tor`
# 5. Monitor your logs (usually in your syslog)
To confirm your bridge is running with no issues, you should see something like this:
```
[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>'
[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>'
[notice] Registered server transport 'obfs4' at '[::]:46396'
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
```
Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.en#ServerTransportListenAddr) option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet.
---
html: two-columns-page.html
---
key:
2
---
color: primary
---
subtitle: How to deploy obfs4proxy Bridge on CentOS / RHEL / OpenSUSE
---
_template: layout.html
_model: page
---
title:
Bridge
---
body:
This guide will help you run an obfs4 bridge to help censored users connect to the Tor network. The requirements are 1) 24/7 Internet connectivity and 2) the ability to expose TCP ports to the Internet (make sure that NAT doesn't get in the way).
Note: If you're running platforms that are not listed on this page, you should probably [compile obfs4 from source](https://gitlab.com/yawning/obfs4#installation).
---
html: two-columns-page.html
---
key: 2
---
section: Bridge operations
---
section_id: bridge-operations
---
subtitle: Run an obfs4 bridge to help censored users connect to the Tor network
---
_slug: {{bridge}}
_model: page
---
title: Debian / Ubuntu
---
body:
# 1. Install Tor
Get the latest version of Tor. If you're on Debian stable, `sudo apt-get install tor` should give you the latest stable version of Tor.
* Note:''' Ubuntu users need to get it from Tor repository. Please see [Download instructions for Ubuntu](https://www.torproject.org/docs/debian.html.en#ubuntu).
# 2. Install obfs4proxy
On [Debian](https://packages.debian.org/search?keywords=obfs4proxy), the `obfs4proxy` package is available in sid, buster, and stretch. On [https://packages.ubuntu.com/search?keywords=obfs4proxy Ubuntu], bionic, cosmic, disco, and eoan have the package. If you're running any of them, `sudo apt-get install obfs4proxy` should work.
If not, you can [build it from source](https://gitlab.com/yawning/obfs4#installation).
# 3. Edit your Tor config file, usually located at `/etc/tor/torrc` and add the following lines:
```
#Bridge config
RunAsDaemon 1
ORPort auto
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
# For a fixed obfs4 port (e.g. 34176), uncomment the following line.
#ServerTransportListenAddr obfs4 0.0.0.0:34176
# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means
# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto
# Contact information that allows us to get in touch with you in case of
# critical updates or problems with your bridge. This is optional, so you
# don't have to provide an email address if you don't want to.
ContactInfo <address@email.com>
# Pick a nickname that you like for your bridge.
Nickname PickANickname
```
Don't forget to change the ContactInfo and Nickname options.
* If you decide to use a fixed obfs4 port smaller than 1024 (for example 80 or 443), you will need to give obfs4 `CAP_NET_BIND_SERVICE` capabilities to bind the port with a non-root user:
```
sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
```
* Under Debian, you will also need to set `NoNewPrivileges=no` in `/lib/systemd/system/tor@default.service` and `/lib/systemd/system/tor@.service` and then run `systemctl daemon-reload`. [bug #18356](https://trac.torproject.org/projects/tor/ticket/18356)
* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports.
# 4. Restart tor
`systemctl restart tor`
# 5. Monitor your logs
To confirm your bridge is running with no issues, you should see something like this (usually in `/var/log/tor/log` or `/var/log/syslog`):
```
[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>'
[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>'
[notice] Registered server transport 'obfs4' at '[::]:46396'
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
```
Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.en#ServerTransportListenAddr) option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet.
---
key: 1
---
html: two-columns-page.html
---
subtitle: How to deploy an obfs4proxy Bridge on Debian / Ubuntu
_model: page
---
title: FreeBSD
---
html: two-columns-page.html
---
key: 3
---
body:
# 1. Install packages
```
pkg install obfs4proxy-tor tor ca_root_nss
```
# 2. Edit your Tor config file, usually located at `/usr/local/etc/tor` and add the following lines
```
#Bridge config
RunAsDaemon 1
ORPort auto
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
# For a fixed obfs4 port (e.g. 34176), uncomment the following line.
#ServerTransportListenAddr obfs4 0.0.0.0:34176
# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means
# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto
# Contact information that allows us to get in touch with you in case of
# critical updates or problems with your bridge. This is optional, so you
# don't have to provide an email address if you don't want to.
ContactInfo <address@email.com>
# Pick a nickname that you like for your bridge.
Nickname PickANickname
Log notice file /var/log/tor/notices.log
```
Don't forget to change the ContactInfo and Nickname options.
* Note that both Tor's OR port **and** its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports.
# 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
```
# 5. Monitor your logs
To confirm your bridge is running with no issues, you should see something like this in `/var/log/tor/notices.log`:
```
[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>'
[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>'
[notice] Registered server transport 'obfs4' at '[::]:46396'
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
```
Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.en#ServerTransportListenAddr) option in your torrc. You can use[our reachability test] (https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet.
# 6. To get the fastest package updates, switch from the "quarterly" package repo to the "latest" repo.
Create the following folder:
```
mkdir -p /usr/local/etc/pkg/repos
```
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
}
```
---
subtitle: How to deploy obfs4proxy Bridge on FreeBSD
_model: page
---
title: OpenBSD
---
html: two-columns-page.html
---
key: 4
---
body:
# 1. Install packages
```
pkg_add tor obfs4proxy
```
# 2. Edit your Tor config file
Usually located at `/etc/tor/torrc`, add the following lines:
```
#Bridge config
RunAsDaemon 1
ORPort auto
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
# For a fixed obfs4 port (e.g. 34176), uncomment the following line.
#ServerTransportListenAddr obfs4 0.0.0.0:34176
# Local communication port between Tor and obfs4. Always set this to "auto". "Ext" means
# "extended", not "external". Don't try to set a specific port number, nor listen on 0.0.0.0.
ExtORPort auto
# Contact information that allows us to get in touch with you in case of
# critical updates or problems with your bridge. This is optional, so you
# don't have to provide an email address if you don't want to.
ContactInfo <address@email.com>
# Pick a nickname that you like for your bridge.
Nickname PickANickname
Log notice file /var/log/tor/notices.log
User _tor
```
Don't forget to change the ContactInfo and Nickname options.
Note that both Tor's OR port and its obfs4 port must be reachable. If your bridge is behind a firewall or NAT, make sure to open both ports.
# 3. Start the tor daemon and make sure it starts at boot:
```
rcctl enable tor
rcctl start tor
```
# 4. Monitor your logs
To confirm your bridge is running with no issues, you should see something like this (`/var/log/tor/notices.log`):
```
[notice] Your Tor server's identity key fingerprint is '<NICKNAME> <FINGERPRINT>'
[notice] Your Tor bridge's hashed identity key fingerprint is '<NICKNAME> <HASHED FINGERPRINT>'
[notice] Registered server transport 'obfs4' at '[::]:46396'
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Bootstrapped 100%: Done
[notice] Now checking whether ORPort <redacted>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
```
Remember to open the random port associated with your bridge. You can find it in your tor log; in the above example it is 46396. To use a fixed port, uncomment the [ServerTransportListenAddr](https://www.torproject.org/docs/tor-manual.html.en#ServerTransportListenAddr) option in your torrc. You can use [our reachability test](https://bridges.torproject.org/scan/) to see if your obfs4 port is reachable from the Internet.
---
subtitle: How to deploy obfs4proxy Bridge on OpenBSD
---
section: Bridge
---
section_id: bridge
_model: page
---
title: Post-install
---
body:
Congrats! If you get to this point, it means that your obfs4 bridge is running and is being distributed by BridgeDB to censored users. If you want to connect to your bridge manually, you will need to know the bridge's obfs4 certificate. See the file `/var/lib/tor/pt_state/obfs4_bridgeline.txt` and paste the entire bridge line into Tor Browser:
```
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0
```
You'll need to replace `<IP ADDRESS>`, `<PORT>`, and `<FINGERPRINT>` with the actual values, which you can find in the tor log. Make sure to use `<FINGERPRINT>`, not `<HASHED FINGERPRINT>`; and that `<PORT>` is the one from the log line `Registered server transport 'obfs4'`, not the one from the line `Now checking whether ORPort ... is reachable`.
Finally, you can monitor your obfs4 bridge's usage on [Relay Search](https://metrics.torproject.org/rs.html#search). Just enter your bridge's `<HASHED FINGERPRINT>` in the form and click "Search". After having set up the bridge, it takes approximately three hours for the bridge to show up in Relay Search.
---
html: two-columns-page.html
---
key: 5
---
subtitle: How to find your Bridge in Relay Search and connect manually
_model: page
---
title: CentOS
---
html: two-columns-page.html
---
section: relay operations
---
section_id: relay-operations
---
key: 3
---
body:
---
subtitle: CentOS
---
_slug: {{centos}}
_model: page
---
title: CentOS
---
html: two-columns-page.html
---
section: relay operations
---
section_id: relay-operations
---
key: 3
---
body:
---
subtitle: CentOS
---
_slug: {{centos}}
_model: page
---
title: Exit
---
html: two-columns-page.html
---
section: relay operations
---
section_id: relay-operations
---
key: 3
---
body:
We assume you read through the [relay guide](..) already. This subpage is for operators that want to turn on exiting on their relay.
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 turning your non-exit relay into an exit relay, ensure that you have set a reverse DNS record (PTR) to make it more obvious 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
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/ReducedExitPolicy) 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
```