Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[nusenu <nusenu-lists@xxxxxxxxxx>]

Hi,

thanks for raising these questions and trying to understand before deploying/changes to filters.

A good understanding of how tor relays and connections work is important when trying
to defend against overload attacks, without breaking functionality
with packet filters that cause false positive blocks, especially when such a
long standing limit like the relays per IPv4 address limit is changed.

> - I have a few Exit relays as permanent residents in my block list, not
> because I want them to be there but because, no matter how many times I
> remove them, day or night, they'll be back in seconds for making too
> many concurrent attempts.

As a relay operator you should allow all other relays
to connect to your relay's ORPort no matter what flags or onionoo
guard/middle/exit probability they might have.
Place known relay IPs on an exception list so your filters don't block them
and update that list at least every hour.

If you have a problem on your relay's ORPort with a source IP that
is also used by an exit relay please try to contact
the operator by looking at their contactinfo, if they don't
have a contactinfo, join the 'require a usable contactinfo' lobby ;)
for this very reason and maybe ask on this list if they can drop you an email.

You can also not be sure whether it is an actual authenticated relay to relay
connection or a client to relay connection just by looking at the source IP.
Some upcoming MetricsPort enhancement might help you there in the future
not per source IP but as a general overview for your relay's ORPort connections.
An exit can share it's source IP with tor clients for example behind NAT,
but I don't think that is common and it is also discouraged. Exits should have dedicated
IPs that is not shared for unrelated things.

Blocking relay to relay communication should not be done
as it breaks a core assumption of the tor network (every relay can talk
to all other relays ORPorts). Upcoming tooling that detects
broken relay to relay links might also detect and flag your relay
if your filters break relay to relay communication.

As an option of last resort - after verifying it is an authenticated
relay to relay connection that is causing you trouble and not some tor client using the same source IP
you might contact the bad-relays list. That is still better than blocking
another relay from reaching your relay's ORPort.

I've seen other problematic filter practices for relay to relay connections and I'll
write up some recommendations in a separate email so it doesn't get lost in this lengthy email.

> I'm assuming this is due to the fact that
> Exits are being used to attack other relays 

In a vanilla current tor version it is not possible to use a tor client
to connect via an exit to another relay's ORPort so this is very unlikely. The background here
is that tor does not allow such connections to prevent an attacker from reentering
the tor network via an exit relay.

You can test that by opening this URL in tor browser, you will get a
"Unable to connect" very fast:

https://185.220.102.242/
because it is this ORPort:
https://metrics.torproject.org/rs.html#details/0A2366980A2842D770EF8E136A7DA14876360447

the answer is very fast and not a slow timeout because a tor client can predict
that is inaccessible before even trying to create a stream
because exits will not allow such connections to relay ORPorts.

> I have 2 Established connections to two Or Ports of an exit relay

I was not able to follow you there. I was unable to find any exit relay that
has more than one ORPort on IPv4 (I identify relays by fingerprint not by IP address).
Maybe you can list the specific exit relay fingerprint and timestamp so I can cross
check for bugs in my tooling/onionoo?

> - Each relay has Established connections to many other relays and if
> they're guard they will also have many connections to regular users and
> their Tor browsers until they have enough traffic to reach their
> MaxAdvertisedBandwidth. Obviously we don't Establish connections to all
> 6300 relays out there.

It is best to actually expect that.

> So if we do not allow each IP more than two
> connections and they need 4, They'll have two from us and they'll move
> on to another relay and get the other two and get the job done and we
> will reach our Max Bandwidth anyway by accepting traffic from other
> relays. Diversity of relays as opposed to concentration of some relays.
> Am I correct in my assumption that this will have little to no effect on
> the health of the Tor network as a whole?

I think there is a misunderstanding there. One important point to take away:
Relays do not chose the next hop in a circuit, tor clients do.
So if my tor clients picks a circuit with these relays:
client -> A -> B -> C -> example.com
and B can not reach C, B can not say "oh I can not reach C I'll pick D instead for you",
a relay has no say in that. I hope that helps to reinforce the importance of
ubiquitous reachability between relays. Relays have to obey a tor client's
orders and a tor client expects that all relays can talk to each other.
A few years ago David Stainton published some actual scan results on tor-dev
that showed that this expectation might not be true in reality but close enough.

I fear that overly aggressive relay to relay filter actually help the adversaries more
than the network and would advise against filtering practices between relays.
The first step should always be on a social level: Try to reach the operator if you feel
they attack your relay and NOT iptables DROP without notice.

kind regards,
nusenu

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays