Excerpts from Logforme's message of October 19, 2022 8:47 am:
I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
Like most relays mine has been targeted by the DoS attack. Hundreds of VPS IPs creating millions of IP connections. This I mitigated with rules in my firewall. Looking at the firewall counters it looks like that attack has now stopped.
However the relay is still overloaded from lots of circuit creations. Normally my little relay reports around 100K circuits open in the log file but since the overloading started it's closer to 1M circuits open. All these circuit creations put a strain on the CPU, sometime pegging it at 100% (4 core i5-4670K CPU @ 3.40GHz). Worse, it seems to eat memory. Normally the tor process uses about 3GB (out of 8GB) but I have seen it quickly shoot up to using all memory and all swap. I assume this is because of the circuit creation DoS (it's new behavior) and what causes the oom killer to kill the tor process at least once a day or so.
So, how do I mitigate the circuit creation DoS? My immediate thought is to identify if there are a few IPs responsible for the majority and add those to my firewall naughty list.
Is there a way to query the tor process about number of open circuits mapped to IP addresses? _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
this is a good idea, which is why someone's already had it (me, possibly also other people). there are a few problems with this plan:
1. tor doesn't expose this information in log (without SafeLogging 0, highly discouraged and possibly illegal except for testing) or control port, because it could potentially be used to deanonymize clients, made worse because...
2. it might not possible to know in general whether the clients with many connections are "abusive" clients or "abused" onion services. additionally, you definitely need to filter out relays, which will obviously have lots of open circuits. there are a couple of decent ways to do that, but it's non-trivial.
for these reasons, I haven't aggressively pursued this plan. I have some more ideas based on intra-family correlation, but they also have similar problems as well as more implementation problems. in the long term, our best hope is the PoW scheme (note: not cryptocurrency) being somewhat quietly worked on.
cheers, Alex.