Ron Risley:
On Jan 27, 2016, at 08:24, Flipchan flipchan@riseup.net wrote:
Hi all! Great with a new mailing list anyhow i was wondering IF anyone have any tips on some good ddos defense for .onion sites , take care
Hi!
Many DDoS attacks, particularly those that use reflection and amplification, rely on the attacker knowing your IP address. Such attacks cannot be used against a properly implemented .onion site, as the service's IP address is hidden.
There are also torloris and pyloris, which are not volumetric.
Conversely, defense against DoS attacks often involve blacklisting attacking IP addresses. Since the attacker's IP addresses will also be hidden, such defenses cannot be implemented.
Indeed.
What you're left with is using good fundamental site design. Specifically, putting any resource-intensive operations behind authentication or a CAPTCHA. Of course, any CAPTCHA should probably be locally generated to avoid leaking the hidden service's address, and CAPTCHA generation could, itself, become the target of a DOS attack.
If it's appropriate to the site's mission, I would make only a simple, static authentication page visible to non-authenticated users.
Wouldn't torloris or pyloris work against that too?
Are these attacks still effective against onion sites? If so, what are the best defenses? One can reduce webserver read and write idle times, but that can also block legitimate users on high latency circuits. There is also the flag CloseHSServiceRendCircuitsImmediatelyOnTimeout. Is it useful to set that to "1"?
On 2/9/16, Ann O'Nymous ann.onymous@vfemail.net wrote:
... Wouldn't torloris or pyloris work against that too?
Are these attacks still effective against onion sites? If so, what are the best defenses? One can reduce webserver read and write idle times, but that can also block legitimate users on high latency circuits. There is also the flag CloseHSServiceRendCircuitsImmediatelyOnTimeout. Is it useful to set that to "1"?
manage sessions and lifetimes carefully; don't use apache; tune limits.conf and sysctl; disable conntrack in kernel network filters (if applicable); ... most important - test before you set live!
know that your onion will survive a modest torrent by measuring it under test first.
also, https://trac.torproject.org/projects/tor/attachment/ticket/8902/torhs-pylori... :)
best regards,
On 2/9/16, coderman coderman@gmail.com wrote:
... manage sessions and lifetimes carefully; don't use apache; tune limits.conf and sysctl; disable conntrack in kernel network filters (if applicable); ...
one other benefit: put a proxy in front of onion service if request based like HTTP/HTTPS/WebDAV. this lets Tor hs config hit nginx (for example) to relay request to actual service back-end, which responds, and can release a socket for close or re-use (pipeline) with Nginx to ensure client response in turn delivered to onion peer at far end.
in addition, keep-alive is useful for DDoS mitigation and performance - always enable HTTP pipelined request support if possible. With a rate limit on accept by origin (by AS instead of IP or CIDR?) legitimate clients can usually connect as expected, and remain connected, while the transient burst of flood sybils from botherders and pwnhops gets almost entirely denied. a few connections make it through established, but the typical operation of automation implies it will get restarted / reconfiged as reason for RST is investigated, thus closing those few connections that did make it, and in turn, once a response is received, not uncommon for code to close socket, rather than re-use.
perhaps more ideas if you encounter specific attacks... good luck! :)
best regards,
On 2/9/16, coderman coderman@gmail.com wrote:
... in addition, keep-alive is useful for DDoS mitigation and performance
- always enable HTTP pipelined request support if possible. With a
rate limit on accept by origin (by AS instead of IP or CIDR?)
and in onion only (not dual public and onion service) this is by stream rather than IP:Port, of course.
in my notes reference to useful thread: "[tor-dev] Hidden Service Scaling" - https://lists.torproject.org/pipermail/tor-dev/2013-October/thread.html#5556
and of course the infamous blog post with input provided by peanut gallery :P "Hidden Services are in a peculiar situation. While they see a loyal fan-base, there are no dedicated Tor developers to take car e of them." - https://blog.torproject.org/blog/hidden-services-need-some-love
best regards,
Thank you, coderman. You have provided much to read, ponder and test. I will likely have followup questions. Perhaps others will benefit.
tor-onions@lists.torproject.org
-
Ann O'Nymous -
coderman