3

I've observed the following:

The Tor client establishes reverse connections to random relays and any further hidden service traffic is tunneled trough these connections.

This means:

  • There are no new connections that could be rate limited by a firewall.
  • It is not easy to monitor the connections for malicious traffic, like an unusual large number of requests from one of the relays.

As security folks will know, layer 7 attacks are anyway difficult to mitigate but how can it be done in this case? How can you detect a flood originating from one of the relays?

The other question is, would it hurt the hidden service functionality or anonymity to ban "misbehaving relays", thus abused circuits temporarily?

And why isn't there any information about this issue on the web? Am I overlooking something?

Improve this question
4
  • 1
    Possible duplicate of Launching a Distributed Denial of Service attack on a hidden service, (which was found by Googling).
    – Richard Horrocks
    Commented Oct 11, 2015 at 19:02
  • 1
    This is a question about mitigation!
    – user9609
    Commented Oct 11, 2015 at 19:35
  • Yep, understood. One of the sub-questions in that thread concerns mitigation :-) The latter half of the accepted answer mentions Nginx (admittedly briefly - it could probably be fleshed out). Also of use might be the following Tor blog entry, though it's not specific to Layer 7: blog.torproject.org/blog/…
    – Richard Horrocks
    Commented Oct 11, 2015 at 19:58
  • Unfortunately neither of these posts are addressing what I'm asking for. My question is about monitoring and filtering hidden service requests and not about software you might want to use because it is "resilient". (that's no mitigation at all) Usually you use a firewall to do so, but (considering the reasons I pointed out earlier) this isn't working for hidden services, so I'm asking for a workaround. I hope it's a bit clearer now. Nevertheless, thanks for caring!
    – user9609
    Commented Oct 12, 2015 at 1:20

1 Answer 1

Reset to default
0

You can use EndGame, which was a system designed to protect Onion Services from DDoS attacks.

In May 2020, Onion Ltd released EndGame on GitHub. It uses nginx frontend proxies ("fronts") to put the users in queues and require them to solve a CAPTCHA (generated with python).

After waiting some seconds, the user is presented with a CAPTCHA from one of the fronts. If the user solves the CAPTCHA correctly, then their session is forwarded to the actual Onion Service backend.

If the CAPTCHA works, then the DDoS will be mitigated against the backend, and the Onion Service administrator only needs to scale-up their fronts. EndGame's README recommends at least 3 fronts.

At the time of writing, EndGame is what's used in many popular Onion Services, such as the Elude Tech Collective and the Dread Forums.

EndGame's README says that it helps mitigate DDoS attacks, but that it "isn't perfect" and suggests that the Tor developers add a POW at the introduction point to make Onion Services more DDoS resilient

EndGame isn't perfect. It can't protect against introduction cell type attacks (the Tor project will need to add POW at the introduction points to fix that). But it does provide good protection and scaling which makes it much harder to take you down overall for whatever people throw at you.

source: https://github.com/onionltd/EndGame/blob/master/README.MD

Further Reading

For more information about protecting Onion Services from DDoS attacks, see the following articles published by the Tor Project:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .