Dear all,
In the past, I set up a middle relay node, and today I am looking to experiment with configuring a Bridge node to support the Tor project and its community. Since this is a very sensitive task, I decided to reach out to you to ensure that the setup is correct and that the configuration does not pose any risks to users who connect.
First, I will summarize the `torrc` configuration file (I have removed the ports as they differ from the standard ones):
``` BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:* ```
I have set two limits on the connections: ``` BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4Only ```
As for the information settings, I have used the usual `ContactInfo` and `Nickname`.
While reading the `torrc` documentation, I discovered the Sandbox feature, which is still in development. In this regard, I would like to ask whether using experimental features like this on Bridge nodes is advisable or not. Personally, I would find a feature like this very useful.
Should an anti DDoS system be configured?
I wanted to ask how I can further contribute to the Tor Project's research, as I have read that there are "Statistics" features that allow the collection of useful information for the developer community. I have two main questions about this:
1. Is it advisable to use experimental features or those that collect information on a Bridge node (assuming there is a difference between a Bridge, a Guard/Middle relay, and an Exit Node)? 2. If the answer to the first question is yes, what are all the features that I can include in the `torrc` file to passively support research within the Tor Project?
Finally, I would like to ask what information should be kept confidential when managing a Bridge. For example, I know for sure that it is important to keep the IP address confidential to avoid the risk of being blacklisted, but are there any other pieces of information that need to be protected?
To ensure that a Bridge node can be restarted on a different machine, which files need to be preserved? Are they the same as those for a standard relay (i.e., the private key), or are there additional files that need to be securely stored?
Thank you for your support and guidance.
Best regards, Aleff
---
Browse my WebSite: aleff-gitlab.gitlab.io Use my PGP Public Key: pgp.mit.edu/pks/lookup?op=get&search=0x7CFCE404A2168C85 Join to support: - Free Software Foundation! (my.fsf.org/join?referrer=6202114) - Electronic Frontier Foundation! (eff.org) - Tor-Project (torproject.org) - Signal (signal.org)
On Sun, Aug 25, 2024 at 12:40:02PM +0000, Alessandro Greco via tor-relays wrote:
In the past, I set up a middle relay node, and today I am looking to experiment with configuring a Bridge node to support the Tor project and its community.
Great!
Be sure to run your bridge on a different IP address than you run your public relay(s): there are censors out there that pull the list of public relays and block them by IP address, so if you have a bridge on one of these known addresses it could end up blocked this way.
First, I will summarize the `torrc` configuration file (I have removed the ports as they differ from the standard ones):
BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:*
Looks good. You don't need the ExitPolicy line (you're just setting it to the default), but it doesn't hurt to have it there.
And if this is on Debian and your Tor deb applies apparmor, you might need to do the 'systemctl edit' steps listed on https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ in order to let Tor launch obfs4proxy.
I have set two limits on the connections:
BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4Only
That's a huge bandwidthrate, so I expect your bridge will never get anywhere close to reaching it. This is fine too. Also be sure to learn about 'BandwidthBurst' in case its behavior is surprising to you.
The IPv4Only entry isn't a valid torrc line, so maybe you mean something else there like writing that on your ORPort?
As for the information settings, I have used the usual `ContactInfo` and `Nickname`.
Sounds good.
While reading the `torrc` documentation, I discovered the Sandbox feature, which is still in development. In this regard, I would like to ask whether using experimental features like this on Bridge nodes is advisable or not. Personally, I would find a feature like this very useful.
Sure, feel free to turn on "Sandbox 1". If it works for you, great. If it breaks for you in a way that you think is a bug, consider filing a gitlab ticket.
Should an anti DDoS system be configured?
I would say you don't need to mess with those options, especially for a bridge, unless some sort of overload starts happening to you.
And for bridges you probably won't see any sort of overload -- most of the time they get very little use, because either they remain mostly unknown (so the load doesn't grow that high), or they become too known and then the censors block them (so the load doesn't stay high).
If you are excited to use more bandwidth than your obfs4 bridge turns out to use, consider running a headless snowflake proxy: https://snowflake.torproject.org/#extension and scroll down to "Run a standalone proxy" which leads to https://community.torproject.org/relay/setup/snowflake/standalone/
I wanted to ask how I can further contribute to the Tor Project's research, as I have read that there are "Statistics" features that allow the collection of useful information for the developer community. I have two main questions about this:
- Is it advisable to use experimental features or those that collect information on a Bridge node (assuming there is a difference between a Bridge, a Guard/Middle relay, and an Exit Node)?
- If the answer to the first question is yes, what are all the features that I can include in the `torrc` file to passively support research within the Tor Project?
Feel free to mess with your torrc options if you find it fun. Remember that you shouldn't need to mess with them for normal operation though.
Search for the 'STATISTICS OPTIONS' section in 'man tor' to see the options. Your Tor will write out its daily aggregated summaries in stats/ in your DataDirectory.
That said, looking at the code it seems we auto-disable some of these statistics options when you are not a public relay:
/* Only collect other relay-only statistics on relays. */ if (!public_server_mode(options)) { options->CellStatistics = 0; options->EntryStatistics = 0; options->ConnDirectionStatistics = 0; options->ExitPortStatistics = 0; }
so don't be surprised if some of them have no effect.
Finally, I would like to ask what information should be kept confidential when managing a Bridge. For example, I know for sure that it is important to keep the IP address confidential to avoid the risk of being blacklisted, but are there any other pieces of information that need to be protected?
There are two categories of data you want to keep safe:
(1) IP address and relay identity fingerprint. The fingerprint is the hash of the public key, and people can use the fingerprint to look up sensitive details of the bridge like its address. (The hashed fingerprint, aka hash of hash of public key, is safe to share and it's how atlas.torproject.org refers to bridges.)
(2) Any external data that can reveal user traffic or users. For more details see https://community.torproject.org/policies/relays/expectations-for-relay-oper...
To ensure that a Bridge node can be restarted on a different machine, which files need to be preserved? Are they the same as those for a standard relay (i.e., the private key), or are there additional files that need to be securely stored?
For a "vanilla" (non-obfs4) bridge, yes the info to preserve for moving the bridge is the same as for a public relay. But for an obfs4 bridge, you will want to bring the pt_state/ directory along too.
--Roger
On Dienstag, 27. August 2024 00:44:02 CEST Roger Dingledine wrote:
BridgeRelay 1 ORPort <port> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:<port> ExtORPort auto ExitPolicy reject *:*
Looks good. You don't need the ExitPolicy line (you're just setting it to the default), but it doesn't hurt to have it there.
Yes, ExitPolicy reject *:* is default on non Exit relays but Socks port 9050 is open by default, I close it when not needed.
SocksPort 0 SocksPolicy reject *
the same applies to ControlPort:
ControlPort 0
Once your bridge has been running stable for a few weeks, an advanced but experimental feature is to hide OrPort.
ORPort 127.0.0.1:<port> ORPort [::1]:<port> AssumeReachable 1
I have set two limits on the connections:
BandwidthRate 300 MBytes # I want to determine how much bandwidth I can allocate without impacting my network usage. IPv4OnlyThat's a huge bandwidthrate, so I expect your bridge will never get anywhere close to reaching it. This is fine too. Also be sure to learn about 'BandwidthBurst' in case its behavior is surprising to you.
If a bridge reaches 20-30 MBytes, that's already a lot. There are only very few (guard|exit) relays on Tor-Metrics that reach 100 MBytes.
Should an anti DDoS system be configured?
You don't need that with a bridge, nor sysctl foo with a 1G nic and 1 - 2 relays. Apart from disabling ipv6 autoconf & dad, I leave the Debian defaults.
Once your bridge has been running stable for a few weeks, an advanced but experimental feature is to hide OrPort.
So is it possible to remove the ports from the torrc file while keeping them unchanged? But what if for some reasons (For istance necessary updates) you have to restart tor? The torrc file is reworked, right? What would need to be done in that case?
the same applies to ControlPort:
ControlPort 0
The control port allows me to quickly check that Tor is working properly via nyx but obviously if it is preferable to close it I will do so but for that reason I would like to better understand why you recommend closing it (Assuming by “0” you mean closing it and not something else that I don't know).
-- Aleff
On Mittwoch, 28. August 2024 07:53:21 CEST Alessandro Greco via tor-relays wrote:
Once your bridge has been running stable for a few weeks, an advanced but experimental feature is to hide OrPort.
So is it possible to remove the ports from the torrc file while keeping them unchanged?
You hide the OrPort or place it on the local port. More Info: https://forum.torproject.org/t/orport-127-0-0-1-auto/8470/2 https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
The reason I called it an experimental feature is because Tor Metrics sometimes shows your bridge as offline even though it is running. This might make you feel insecure in the first few days.
This has been fixed for a few weeks, 'running' flag is rarely gone: https://gitlab.torproject.org/tpo/network-health/team/-/issues/318
But you can see in the history that they are running or check it here: https://bridges.torproject.org/scan/
Coincidentally, my bridges are all 'red' right now ;-) https://metrics.torproject.org/rs.html#search/ForPrivacyNETbr
But what if for some reasons (For istance necessary updates) you have to restart tor? The torrc file is reworked, right? What would need to be done in that case?
Upgrades overwrite, among others, /usr/share/tor/tor-service-defaults-torrc but not /etc/tor/torrc or the entire folder /etc/tor/*
the same applies to ControlPort:
ControlPort 0
The control port allows me to quickly check that Tor is working properly via nyx but obviously if it is preferable to close it I will do so but for that reason I would like to better understand why you recommend closing it (Assuming by “0” you mean closing it and not something else that I don't know).
My note was about if you don't use it. But if you use Nyx or other tools that need it then use it. ;-) Authentication method 'CookieAuthentication' is enabled per default. NOTE: In order to use the ControlPort, the (Nyx) <user> must belong to the tor group. sudo usermod -aG debian-tor <user>
Okay Marco, it would appear that Bridge[1] is now working properly.
I noticed that you have a lot of Bridges active and in this regard I wanted to ask you if under the same network I can activate multiple Bridges and if the answer is yes: - Is it possible and advisable to start multiple bridges on the same machine (perhaps virtualizing the environments) - It is only possible to do this through multiple computers
[1] https://metrics.torproject.org/rs.html#details/8B09E3F8562ED8379448022510605...
-- Aleff
On Freitag, 30. August 2024 14:35:26 CEST Alessandro Greco via tor-relays wrote:
I noticed that you have a lot of Bridges active and in this regard I wanted
I have different subnets on the servers and each bridge has a different IP+IPv6.
Until 3 years ago you could get 1 IP for less than 1,- €/month. I had one for SSH and bridge and others for relays on each server. Nowadays IP + setup fee is so expensive, it is better to take KVM offers for 1-3$/month.
to ask you if under the same network I can activate multiple Bridges and if the answer is yes: - Is it possible and advisable to start multiple bridges on the same machine (perhaps virtualizing the environments) - It is only possible to do this through multiple computers
On Debian systems you can easily do this with tor-instance-create: https://lists.torproject.org/pipermail/tor-relays/2024-July/021715.html
In general, it is not a good idea to have multiple bridges under one IP with different bridge distribution mechanisms.¹ The probability that one will be discovered is higher and then all will be blocked.
But you can, for example, have several Tor instances on one IP. A public bridge, a hidden bridge for you and friends and some hidden services.
¹Meskio has committed a fix so that bridges with the same IP get the same bridge distribution mechanisms. At the last Relay Meetup, this merge was not yet activated. But it should be now. I can't find the Gitlab issue at the moment.
tor-relays@lists.torproject.org
-
Alessandro Greco -
boldsuck -
Roger Dingledine