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:

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?

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