[tor-relays] DoS attacks on multiple relays

[teor]

> On 6 Dec 2017, at 19:13, Scott Bennett <bennett at sdf.org> wrote:
> 
> null <null at omuravpn.com> wrote:
> 
>> @ x9p:
>> 
>>> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
>>> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
>>> | egrep -v '      1 |      2 |      3 '
>>> 
>>> with this information in hand, double the max of it (mine was 10
>>> connections from 188.214.30.0/24):
>>> 
>>>     10 188.214.30
>>> 
>>> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
>>> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>> 
>> Thank you! This was extremely helpful.
>> 
>> In our case we found a handful of IPs that had *thousands* of
>> concurrent connections on several of our relays. The offending IPs
>> were not in the consensus. After restarting the Tor service, these
>> suspect connections come back rapidly, again across several of our
>> relays. Since our relays are all in the same declared family, it is
>> very difficult to see how this traffic is legitimate. If it's valid
> 
>     But it could be legitimate.  As has been discussed here previously,
> they may be connections from a relay that actually is in the consensus,
> but either a) uses an OutboundBindAddress or b) is on a LAN that has
> multiple connections to the Internet.

Relays try very hard to have at most one connection to each other relay.
(And only two relays are allowed in the consensus per IPv4 address.)
Clients try to make one connection to one or two guards.

So it's far more likely to be a collection of Tor clients in a network with
only a few public IPv4 addresses. (There are entire countries and large
networks that only have a few allocated IPv4 addresses.)

Or, it might be a bug in Tor, a misconfiguration, or a denial of service
attack. We'd like to know more, so we can find out and fix it.

> (Snip)
>     A script similar to the one used to reveal and make available the
> otherwise unidentified source IP addresses of exits could be run by the
> project to gather the hidden addresses of currently running relays, and
> a list of such addresses could be made available on a compromise basis,
> e.g., by having a relay at the project that would serve those lists only
> over tunneled directory connections *from relays*, were it not for obstinacy.
> Such a list could then be included into our packet filters' "free pass"
> lists without putting the list up on the project's web site like the exit
> list is.

Outbound addresses aren't secret, because they are used for connections.

Anyone is free to volunteer to create and maintain a list of outbound
relay addresses. It is technically feasible: it requires a few thousand Tor
connections per day, one via each relay, to a relay that reports the
remote address of each inbound relay connection.

It just needs to be done safely, in a way that doesn't collect client
addresses, and avoids attaching a timestamp or order to relay connections.

> A torrc option to fetch the list whenever updates were available
> could default to not fetching the list, so relays whose operators who do
> not use packet filter defenses would not automatically fetch the hidden
> address list of non-exit relays.

If someone created a list, and showed that it had value to other relay
operators, then it might gain support, and be supported by Tor,
just like other features have:

There is an exit_addresses field for relays in Onionoo and Relay Search
that gives the outbound exit addresses of every exit (when they differ
from the relay address). It gathers addresses using exitmap. (Rather
than relays self-reporting, which is unreliable.)

There is also a torrc option that has the side effect of making every
address on the machine public, even unused addresses, because it
blocks them in the exit policy. (ExitPolicyRejectLocalInterfaces, off by
default.)

Here's how someone could work on this feature:

Create a scanner, publish a list, and show that it has value.
Or start with a proposal, ask for advice, then create the scanner.

Try for something independent of Tor, like exitmap, because it will
be more accurate. (Tor doesn't always know what its outbound address
is.)

And try to have list downloads rely on existing Tor features, like onion
services. They'll be faster to deploy that way.

Here's a description of the proposal process:

https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

>> Tor clients, they are behaving very strangely, and in either case we
>> need to limit their impact. As such we've implemented connlimits by
>> /24 as suggested (with a much higher limit to err on the side of not
>> rejecting valid traffic). We can already see that this has improved
>> our situation.
>> 
>     And it will likely get you roundly denounced by tor project members
> and certain other individuals on this list. :-(

I sketched a proposal like this in another thread just a few days ago.
I'm happy to work with others to include inbound or outbound connection
limits in the draft proposal. (My initial proposal had outbound circuit and
stream limits.)

> You will also see your
> Fast and HSDir flags come and go at random, depending upon how many
> authorities creating testing circuits to reach and test your node(s)
> go through a node that used a hidden outbound address as the source
> address that fails your filter to connect to your node.

If you set the connection limit at or above 512 connections per /24, it will
be impossible for well-behaved consensus relays to go above the limit:

2 relays per IPv4 * 256 IPv4 addresses per /24 = 512 connections

Or you could check how many relays are in the most popular /24, and use
that to work out a limit.

> (Snip)

>> @ Scott Bennett:
>> 
>>> (Snip)
>> 
>> Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule
>> it out. However it appears that option is deprecated (on 0.3.1.9).
>> Enabling it causes this in the log:
>> 
>>  [WARN] Skipping obsolete configuration option 'HidServDirectoryV2'
>> 
>> It's also no longer listed in the Tor manual
>> (https://www.torproject.org/docs/tor-manual.html.en). It looks like we
>> might be able to achieve the same effect with something like this
> 
>     Sigh.  My apologies.  You are indeed correct on this matter.  It had
> slipped my mind that tor no longer is distributed with a man page.

Tor source is distributed with an asciidoc man page.

It might not be on your system because the packager left it out, or left
out asciidoc as a build dependency.

>> (Snip)
>> 
>> Anyone have any info on why HidServDirectoryV2 is consider obsolete?
> 
>     Not entirely sure, but I *think* I remember reading somewhere that
> HS v2 is no longer preferred and has been superseded by HS v3.  I hope
> someone will confirm/correct this recollection.

It was removed in 0.2.7 along with the authority option
VoteOnHidServDirectoriesV2. There's not much information on the ticket:

https://trac.torproject.org/projects/tor/ticket/16543

In general, we try to remove options that very few people use, because it
reduces the cost of testing and maintaining Tor.

> (Snip)

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171206/22c929a4/attachment-0001.html>