On Mittwoch, 8. Februar 2023 00:07:22 CET nusenu wrote: > I don't think relays should silently drop > other relays packets without first trying: > - to confirm that accepting that IP would render the relay (mostly) unusable > (by first running in a mode that accepts relay IPs) - to understand the > actual root cause > - to contact the relay operator at the other > - to report relays they consider malicious > > Not investigating such cases is a missed opportunity > to find potential bugs or a new detection mechanism for malicious relays. > It is also a missed opportunity to help protect the tor network at a higher > level, because it is unlikely that everyone is using (the same) filters. > > Filters that result in blocks for a large fraction of the tor network > are more likely a sign of an unsuitable filters than an indicator that most > of the tor network is engaging in attack against other relays, > especially when they include well known and long term trusted operators. > > This a good topic to be added to the Expectations for Relay Operators > document. > https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-R > elay-Operators > > At the very least relays blocking/dropping some packets of other relays > should be very transparent about it. On exits, i don't block|rate limit via nftables I block via exit policy. Alex from Artikel10 created a nice python script: https://github.com/artikel10/surgeprotector I'm running the script with 10000 TCP connections as the LIMIT. Once issue ¹#40676 is resolved, the relays will no longer need to be restarted. A reload would close already established outbound connections. ¹https://gitlab.torproject.org/tpo/core/tor/-/issues/40676 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays