[tor-talk] Help setting up tor dos defense

David Goulet dgoulet at torproject.org
Mon Jan 6 14:17:30 UTC 2020


On 19 Dec (12:38:35), brokenback at danwin1210.me wrote:
> Hello I run a forum hidden service and a former user is constantly
> attacking it.
> 
> I now have 0.4.2.5 installed and this is my torrc file the attacks still
> persist do I need to add anything else or change these numbers I thought
> this version of tor fixed these attacks was I mistaken?
> 
> HiddenServiceDir /var/lib/tor/forum/
> HiddenServiceEnableIntroDoSDefense 1
> HiddenServiceEnableIntroDoSRatePerSec 25
> HiddenServiceEnableIntroDoSBurstPerSec 200
> HiddenServicePort 80 10.152.152.11:80
> HiddenServiceVersion 3

The above looks fine. I will expand on these defenses since it has been a
recurrent theme lately:

There is unfortunately a catch with these HS DoS defenses and it has to do
because of a safety issue namely the "partition problem".

Tor relays supporting the HS DoS defense (intro points) at this point in time
are not in majority. Basically >= 0.4.2.1-alpha relays do support it which
currently represents ~36% in bandwidth weight so roughly 1/3 of the network.

If a service enables the defenses (like you did above), it will NOT
specifically pick intro points supporting the defenses but will normally pick
intro points as it did before and _if_ they happen to support the HS defenses
(via protocol version "HSIntro=5"), then they are used. Yes, I agree, not
ideal but there is a valid reason.

This is in part to prevent partitionning onion services using the HS defenses
to a specific set of relays (those who support it). Bottom line is: if the set
of relays that can only be used by an onion service is reduced, attack surface
gets bigger.

As the relay in the network upgrades to latest stables, the network naturally
move towards supporting these defenses in majority. This is another
_extremely_ important reason why relay operators should stay up to date with
their tor application so the network can be more agile in deploying defenses
and improvements.

Now onto "what this defense really does for your onion service?" question:

Lets assume the attack here is a client DDoS meaning there are a gazillion
clients trying to reach your service. Unfortuantely, this can bring down a
service as it will be unable to cope with the amount of requests due to a
number of factors that I will not cover with this email. More importantly, his
has an immense toll on the network itself that is affecting everyone.

What this defense does it to limit the number of client request that can
*reach* the service by imposing a rate limitation at the intro point layer.

In other words, this is primarly a defense to protect the _network_ which
soaks in the extraneous client requests at the "edges" of the network (in this
case more at the "edges of the onion service").

The main benefit for the service is that it will not be under heavy load and
thus will still be usable/reachable for some definitions of "reachable".
Because bad vs good client requests are basically indistinguishable at the
intro point, legitimate clients get caught in this rate limitation resulting
in them having a hard time to reach the service that is under attack.

But, if your service happens to be under attack on a single .onion address but
is configured with many more .onion, then these defenses makes it that through
the other .onion addresses, it will be reachable without any problem which
wasn't the case before.

All in all, the network pressure is massively reduced due to this defense
which overall is critical to the anonymity and stability properties of the
network.

Onion service reachability under DDoS is a hard problem and being researched:

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

Hope this help!

David

-- 
j4GkCCMWq4EUJFogagt0wniDJJQgnGlBM/lXudVEJec=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20200106/b76461a0/attachment.sig>


More information about the tor-talk mailing list