[tor-onions] DDoS, Single Onion Services and IP Addresses

[teor]

Hi,

I didn't give much detail here:

>> On 2 Feb 2018, at 11:08, Alec Muffett <alec.muffett at gmail.com> wrote:
>> 
>> The current limit is 2 connections per IP address.
>> This affects single onion services, because they don't use guards.
>> 
>> Can you please make sure that you only have one or two Single Onion
>> Services on each outbound IP address?


So I'm going to quote from my email to tor-relays earlier today:

> Here are the mitigations again:
> 
>> o Major features:
>>   - Give relays some defenses against the recent network overload. We
>>     start with three defenses (default parameters in parentheses).
>>     First: if a single client address makes too many connections
>>     (>100), hang up on further connections. Second: if a single client
>>     address makes circuits too quickly (more than 3 per second, with
>>     an allowed burst of 90) while also having too many connections open
>>     (3), refuse new create cells for the next while (1-2 hours).
> 
> We could patch clients so they never exceed this number of circuits
> by default. But that would penalise large clients that have a dedicated IP
> address.

For Alec's home development use case, limiting client bursts may be helpful.

>>     Third: (DoS mitigation)
>>     if a client asks to establish a rendezvous point to you directly,
>>     ignore the request. These defenses can be manually controlled
>>     by new torrc options, but relays will also take guidance from
>>     consensus parameters, so there's no need to configure anything
>>     manually. Implements ticket 24902.

This shuts down Tor2web, which is a major source of the current load.

>> On 2 Feb 2018, at 03:04, David Goulet <dgoulet at torproject.org> wrote:
>> 
>>>>> On 01 Feb (04:01:10), grarpamp wrote:
>>>> Applications that use a lot of resources will have to rate-limit themselves.
>>>> Otherwise, relays will rate-limit them.
>>> 
>>> It's possible if relays figure that stuff by #2 might not be
>>> an attack per se, but could be user activities... that relays
>>> might push back on that one by...
>>> - Seeking significantly higher default values committed
>>> - Seeking default action committed as off
>>> - Setting similar on their own relays if commits don't
>>> work. And by not being default off, it should be prominently
>>> documented if #2 affects users activities [1].
>> 
>> That I agree. We've set up default values for now and they will probably be
>> adapted over time so for now this is experimental to see how much we make
>> people unhappy (well except for the people doing the DoS ;).
>> 
>> But I do agree that we should document some "real life" use cases that could
>> trigger defenses at the relay in some very public way (blog post or wiki)
>> before this goes wide in the network. Large amount of tor clienst behind NAT
>> is one I have in mind, IPv6 as well...
> 
> We did some analysis when we were choosing these figures.
> 
> It takes a few hundred clients behind an IP address, to have a 50% probability
> of 3 clients choosing the same large guard. That's unusual. And if clients see their
> guard timeout, they will move to another guard.
> 
> Here are some other scenarios:
> 
> Peer-to-peer clients like Ricochet, when the user has >90 contacts, but only
> when there are hundreds of other clients on the same IP address.
> 
> Any Tor client that doesn't use guards. For example:
> 
> Bridges with multiple users, but only when there are >=3 bridges per outbound
> IP address. (This is unlikely, because bridges need their own IPv4 address.
> If you have multiple bridges using the default route, and multiple IP addresses,
> set OutboundBindAddress on each bridge.) We will need to consider this issue
> when we allow IPv6 bridges without a public IPv4 address. Perhaps an appropriate solution is to make bridge clients use vanguards.
> 
> Multiple (>=3) Tor2web or single onion services using separate tor instances,
> behind a single IP address, making large numbers of circuits. This is a likely
> source of our current issues.

Alec wrote:

> I think the NYT is okay (separate IPs?)

I hear Facebook is ok as well.

> but if I understand this right, this is going to hamper EOTK development, since I have ~ 12 worker onions spread over 6 quad-core machines, and then publish up to 10 additional "service" addresses via OnionBalance ... all behind my single DSL NAT firewall that protects them from inbound traffic.


For IP addresses with 3 or more connections to a single guard, the guard imposes
a limit of 1 circuit every 3 seconds, with a 90 circuit burst allowance.

Are these single onion services or do they use guards?

If they are single onion services, then the probability that 3 of your 13? instances
will choose the same relays for their directory, HSDir, intro or rend points is small
(< 10%). If it happens, and if they build more than 90 circuits to the same relay,
the defence will trigger. Then both instances will try another relay.
You should probably limit your circuit construction rate if this happens a lot.

If they use guards, then the probability that 3 of your 13? instances will choose
the same guard is negligible (1 in 1 million). The defence will not trigger.

Aaron wrote:

> Because the circuit-creation limit is applied at the guard, wouldn’t this affect hidden sevices instead of single onion services?

It will only trigger if hundreds of guard-using clients are behind a single IP address.
See above.

Alec wrote:

> I am not going to pretend that I fully understand the DDoS mitigations yet, but experience at two jobs has taught me that at least three entire countries essentially present themselves from behind small numbers of heavily NATed addresses, so I hope that the mitigations are NAT-friendly.
> 
> ISTR that UAE and Singapore are two such, I forget the third?


They are as NAT-friendly as possible under the circumstances.
We may have issues if thousands of users are behind a single IP.

In this case, we could recommend bridges, or increase the DDoS mitigation limits.

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20180202/03be52d6/attachment-0001.html>