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

[Alec Muffett]

Hi All,

I think I see the shape of the DDoS mitigations now, and to test my
understanding I'm going to try to recap/quote some of the thread as I
understand it; plus, I'll voice some of the questions which linger at
the back of my head.

Stuff where I am inferring (possibly wrongly) behaviour from context,
is in <angle> brackets.

Observation: I had a hard time following whether a bare reference to
"client" in any given explanation, referred to a client-ip-address, or
to one of the tor-daemons ("clients behind an ip-address"), or to
something (eg: curl) actually using tor. So I may have misapprehended
/ got some of this wrong...


# The three defences are...

1) Connection-Limiting: if a <given client ip-address> makes too many
connections to <a solitary given relay> then <that solitary relay>
will start to <destroy further circuits that the ip-address creates,
irrespective of which tor-daemon behind that address, created them>

Question: as above, I am really uncertain whether the circuits are
destroyed because they are attributed to a given ip-address (potential
for collateral damage?) or to a specific overzealous tor-daemon/client
*behind* a given ip-address.

Question: I am not sure whether this mitigation is per-relay, or
whether the status that <given client ip-address> is being "unfair"
gets somehow propagated to the rest of the Tor network?


2) Rate-Limiting: if a <given client ip-address> makes connections too
quickly to <a solitary given relay>, when ALSO there are lots of
existing connections <to that relay>, then <that solitary relay> will
start to ignore that <given client ip-address>

Question: <The same two questions as-previous, apply.>


3) DoS Mitigation: if a <non-relay / random ip-address somewhere on
the internet> asks <a relay> to <become> a rendezvous point, it gets
ignored, which thereby kills Tor2web.

Notes: initially this worried me because I misread it as "if a
non-relay CONNECTS to an RP" - which would ban SingleOnions because no
guards - but I am pretty sure of my revised interpretation and I am
fairly certain of why this would be a good idea; but if I can make
this misinterpretation, then others might do, too.


# Re: my situation...

Teor: yep everything is SingleOnion in EOTK by default, not least
because testing onionification of video streams with a bank of
RaspberryPi on a single DSL connection is laggy enough without a
couple of extra hops.

Questions:

The reason I am worried (above) about "notification of bad behaviour
is somehow propagated?" is that I am worried that if I trip a
trigger, am I going to effectively be banned from the entire Tor network
for "a couple of hours", or am I just going to lose <a solitary relay>?

Reading the text further down, Teor writes: "...the defence will
trigger. Then both instances will try another relay..." - so I am
pretty sure that this is not a "banhammer" that would kick me off Tor
entirely; instead it's more of a "choke".


# Re: EOTK...

Any given EOTK "worker" currently gets 2x tor daemons provisioned to
it; this is partly to make better use of the compute bandwidth
available on a multiprocessor box, and partly to mitigate exant
problems of Tor daemons going "stale" - having 2x daemons makes it
less likely to lose the entire worker.

Also: I am looking at #24973 "Tor should be more gentle when launching
dozens of circuits at once" - which resonates with my worker pool: I
am running 6x2 = 12 worker-daemons (and that figure may double, soon)
not to mention all the other tor daemons that I am running (eg: TBB,
OnionBalance)

Also: per #24992, I have seen quite a lot of "exceeded launch limit
with 10 intro points in the last 180 seconds"-type messages, recently;
I am not sure why this has been happening because the tor daemons in
question have all been workers running a single HS in each. Perhaps it
was having problems establishing ANY introduction points at all,
because of the DDoS attack, but the failures still counted?

To summarise: all of this "bad" behaviour on my part, explains why I
am/was worried about getting blocked from Tor entirely.  :-)


# Re: NYT...

I am still working with NYT to confirm their IP setup on AWS; until
now, one of the selling points of enterprise onion networking for me
has been the capability to keep everything in one/more "NAT enclaves"
which - combined with SingleOnion - mitigates inbound-connection
attacks like flooding, whilst permitting "horizontal scaling" which is
important with a rewriter-proxy like EOTK.

I'm a little bummed that that may no longer be viable / that in order
to do Tor at high bandwidth then your worker fleet will need to have
separate and visible IP addresses, because DDoS attribution; however,
this is an evolving environment so I suppose that we'll adapt.

In the case of AWS this likely means buying "Elastic IPs" for each
worker.


# Speculation...

Aaron wrote: "Because the circuit-creation limit is applied at the
guard, wouldn't this affect hidden sevices instead of single onion
services?"

Teor wrote: "It will only trigger if hundreds of guard-using clients
are behind a single IP address."

This exchange makes me think a couple of things:

a) if my EOTK development farm was using NormalOnions not
SingleOnions, then I might actually be in a worse situation because I
would be more heavily regulated... in fact:

b) I am wondering if <bad people> might leverage the DDoS mitigations
to knock non-SingleOnion onionsites off-air? The attack would be to
use a wide diversity of client IPs (eg: botnet) to "just enough"
connections to the onion site that the connections back, through the
guard, to the rendezvous sites, would trip the DDoS code?

Whether I am right would depend in-part on my proper understanding of
defences 1 & 2 at the top of this post, plus also how quickly the
onionsite would "give up" on the guard which is now ignoring it.

It would be a bit like a DNS amplification attack; but I'm presuming
that I'm somehow wrong; Roger's final paragraph speaks directly to
Onions-that-use-guards being apparently safer:

"I expect a popular onion service that doesn't use guards and that
runs many Tor instances on the same IP address will trigger the
defense often: because it doesn't use guards, each new circuit it
builds in response to a rendezvous request will pick an entry point at
random, and if some of the conversations with clients last for a
while, then outgoing connections will accumulate, eventually reaching
the threshold for each relay to decide that that address is being
unfair."

...however it is speaking to the protections of relays as a whole,
rather than the connectivity of a given onion site through a given
guard.

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