tl;dr: run this:
conntrack -L -p tcp --dport 9001 | awk '{print $5}' | sort | uniq -c | sort -n
ignore numbers less than 10. the remaining output should consist of the following:
1. your IP 2. LeaseWeb and Online.net IPs (use rDNS and whois) 3. mobile networks
block IPs in set 2 from accessing Tor using your firewall software. don't block 1 or you will have problems. don't block 3 or other people may have problems (hopefully more if the Android project gains momentum). also don't block the /16 of guards mentioned. they are causing no measurable harm. my list of set 2 is available upon request to longstanding members (basically if you've done anything on Trac or any tor mailing lists).
more information:
This attack appears to be malicious to me. It seems to work like this:
1. Open many OR connections (hundreds to thousands) 2. 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.
In the interim, this attack is causing real problems, so this approach seems reasonable for now. If you want to be slightly more conservative, instead of blocking them outright, simply limit these IP subnets to a small number of connections. Modern Tor only requires one, but you could do two or three per address, or four or five per /28 or so. Since these are not NATed IPs, a high limit is not justified. I recommend against the blanket approach suggested previously of limiting whole sets of /24s, since that may inadvertently block mobile clients and is not effective against the current attack. As mentioned in the previous paragraph, you should not set DisableOOSCheck 0, as that may wind up killing good sockets instead.
again, this is not a good solution, but until that ticket is resolved, it is probably the best that can be done.
Evidence for this attack being malicious and intending to disable Tor is:
1. these connections are coming very fast: as shown by others too, dozens of connections per second per IP, and tens of thousands of connections held open. the standard tor software multiplexes circuits over a single TCP connection, so even very high-volume links should only have a single Tor connection, or possibly two if they are very old and must make a separate connection to the DirPort.
2. the connections do not taper off if they are rejected. I banned these addresses from accessing Tor, and they continue to make dozens of connection attempts every second from each IP address. this means that this is probably not a good faith "test" or a misconfigured set of real Tor clients, but is instead malicious and using a modified or custom client.
3. they are spread out over many IPs, *but* only from *two* *hosting* service providers. this means that: 3a. it is likely a single individual or organization, otherwise it would be multiple providers 3b. they are trying to cause as much problems as possible, otherwise they would use one server 3c. it is almost certainly not real clients using NAT; as far as I know, LeaseWeb does not use NAT, and Online.net only uses one-to-one NAT.
4. rDNS is generic. this means they do not care enough to explain their origin.
5. as pointed out, they have not registered themselves in the relay consensus. this means it is probably not a set of high-volume relays that is somehow malfunctioning, or someone conducting a DoS attack through Tor itself.
6. as far as I can tell, these connections do not do anything. they simply remain open, consuming resources until tor times them out.
7. they keep far more connections open than they make. what I mean by this is that they hold open thousands of connections at once but only send less than a hundred connections per second. this supports my theory that it is not a large number of regular tor clients, but is instead some custom client specifically for disruption.
additionally:
The referenced /16 block of guards is *not* part of this attack, and is simply poorly configured relays. you should not block that set, but instead block the set described above.