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

[lists at for-privacy.net]

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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 3864 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20230208/0614dbe4/attachment.sig>