[tor-relays] DoS attacks are real (probably)

[Alex Xu]

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.