Hi Alex,
This attack appears to be malicious to me. It seems to work like this:
- Open many OR connections (hundreds to thousands)
- Leave open until tor runs out of sockets
Tor presently waits for the connections to time out, which takes 3-4.5 minutes. It should instead more aggressively prune these garbage connections. https://trac.torproject.org/projects/tor/ticket/19984 tracks this.
This is exactly what we saw as well. After implementing connection limits (thanks again x9p) the problem mostly went away and our relays have been stable since.
Thank you for opening the trac ticket. We agree it would be great if this problem could be addressed in the Tor software if possible. In the mean time we should probably be advocating for all relay operators to implement connection limits. Put simply, without those limits, relays are vulnerable to DoS.
Evidence for this attack being malicious and intending to disable Tor is:
Agree with all 7 points you listed. We'd also add, there is additional evidence that suggests some of the worst offenders (attacking IPs) are actually orchestrated by a single entity (or perhaps multiple entities working together). There are several commonalities across the infrastructure used for these attacks. We identified and blocked (with iptables DENY) the worst. To be clear, these IPs were not in the consensus, and yes, mostly hosted by LeaseWeb.
The referenced /16 block of guards is *not* part of this attack, and is simply poorly configured relays. you should not block that set,
Completely agree. We haven't blocked anything in the consensus.
Thanks.