to reduce the risk that your multi-instance tor relay setup triggers
false-positive filter thresholds on other relays, I recommend you make use of the
OutboundBindAddress (or OutboundBindAddressOR)
option and set it to the same IP as in the ORPort line.
This will ensure that the outbound source IP will be the same when connecting to relays.
The man page is not clear what tor's default without that setting is
but I guess that would leave it to the OS to pick the source IP and
that could result in all your tor's using the same source IP.
relayor users are covered by default, no further action required.
Can you please describe what that is? Is it a server with multiple
relays, each with it's own fingerprint? Or is it a relay with one
fingerprint and with multiple tor daemons that are synced by some magic?
···
Am Wed, 8 Feb 2023 00:08:39 +0100 schrieb nusenu <nusenu-lists@riseup.net>:
I’m considering not setting OutboundBindAddress on the dotsrc exit relays (https://metrics.torproject.org/rs.html#search/dotsrc). Wouldn’t it be better if all outgoing connections came from the same IP (i.e do not set OutboundBindAddress), for the sake of making correlation analysis harder? Say you observe an exit connection to example.com:443. If all the dotsrc relays used 185.129.61.1 as src IP, you couldn’t tell which of our relays made the connection.
On a related note, wrt ongoing ddos, here’s something that might be useful to exit relay operators:
What we observed, was tens of thousands open exit connections to a few IP (at one point our server had more than 500.000 open connections to those hosts!). To check if you see the same, here’s a one liner to show you the endpoints with the largest number of connections from your server:
One way to solve this, is to do some firewall foo, but I really don’t like connection tracking (unnecessary CPU cycles). An alternative solution that works great for us, is to lower the net.ipv4.ip_local_port_range from the default of about 30.000 ports. E.g:
This limits the number of connections you can have to a specific dst tuple (IP, Port) to 1.535 connections (and thanks to Tor now setting IP_BIND_ADDRESS_NO_PORT, reaching this limit won’t affect any other connections as the same port can be used as src for many different dst IPs).
I'm considering not setting OutboundBindAddress on the dotsrc exit relays ( Relay Search). Wouldn't it be
better if all outgoing connections came from the same IP (i.e do not set
OutboundBindAddress), for the sake of making correlation analysis harder?
Say you observe an exit connection to example.com:443. If all the dotsrc
relays used 185.129.61.1 as src IP, you couldn't tell which of our relays
made the connection.
There are two settings that can help you with achieving both goals at the same time:
* use the inbound IP for connections to other relays: OutboundBindAddressOR
* use a single source IP for connections exiting the network: OutboundBindAddressExit
there are other points to consider though: if all users exit through the same IP,
will the web become less accessible for tor users because one bad user ruined the
IP reputation for all users?
On a related note, wrt ongoing ddos, here's something that might be useful
to exit relay operators:
What we observed, was tens of thousands open exit connections to a few IP
This is a known issue and there are issues on gitlab.tpo for it and 3rd party tools
for exit operators.
One way to solve this, is to do some firewall foo, but I really don't like
connection tracking (unnecessary CPU cycles). An alternative solution that
works great for us, is to lower the net.ipv4.ip_local_port_range from the
default of about 30.000 ports. E.g:
# sysctl -w net.ipv4.ip_local_port_range="64000 65535"
I don't think that it is a good approach to set such a low hard limit for connections
to any single destination.
Seeing how the git repo mentions MyFamily management, I believe it's just #1 in
this case.
I remember reading someone describe their setup of #2, with a TCP load
balancer in front of multiple Tor instances all using the same fingerprint.
Outright my reaction was that this is fundamentally broken and cannot work,
but apparently it does. Still, IMO that's easy to get wrong and unknowingly
degrade the network quality for Tor users.
···
On Sat, 11 Feb 2023 11:16:33 +0100 Felix <zwiebel@quantentunnel.de> wrote:
Am Wed, 8 Feb 2023 00:08:39 +0100 > schrieb nusenu <nusenu-lists@riseup.net>:
Hi
> multi-instance tor relay
Can you please describe what that is? Is it a server with multiple
relays, each with it's own fingerprint? Or is it a relay with one
fingerprint and with multiple tor daemons that are synced by some magic?