[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] (D)DOS over Tor network ? Help !



On 2014-12-02 02:51, Mirimir wrote:
On 12/01/2014 03:44 PM, fuckyouhosting@xxxxxxxxxxxxxxx wrote:
On 2014-12-01 07:55, Mirimir wrote:
On 12/01/2014 12:13 AM, fuckyouhosting@xxxxxxxxxxxxxxx wrote:
On 2014-12-01 02:24, Christian Gagneraud wrote:
On 01/12/14 14:46, fuckyouhosting@xxxxxxxxxxxxxxx wrote:
Hi List! We (try to) maintain a free hosting platform for hidden
service
websites, here: http://fuckyouhotwkd3xh.onion
but recently all the hosted hidden services became unreachable.
[...]
So .. question: is there a way to understand which hidden service is
causing all this ?

Suggestions are welcome!

This might help:
https://lists.torproject.org/pipermail/tor-talk/2014-November/035787.html


Chris


Thank you.

Hi again, ok we followed the advise and captured a number of sessions,
while starting Tor and while reloading it, several times to be sure.

We splitted and sorted the results with this command:
grep "PURPOSE=HS" dbg3.txt|awk '{ print $9 }'| sort |less
(which print just the hidden service name, for example
REND_QUERY=fuckyouhotwkd3xh)
but are unable to find an address repeated more than around 30 times,
example:

REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh
REND_QUERY=fuckyouhotwkd3xh

in short, the addresses are balanced among all the files, still unable
to find the 'black sheep'.

In your torrc, create a new test hidden service, and comment out all of the rest. The new hidden service should be accessible. If it's not, you have other problems. If the new hidden service is accessible, add back the old ones, one at a time, and check accessibility of the test hidden
service after each addition. That should reveal the black sheep.

Hi, thanks for the suggestion but we were looking for a more
'programmatic' way: a straight indication about the offending HS, which
eventually can be used by fail2ban or a custom script
to automatically switch off the black sheeps.

Moreover, consider that we are talking about hundreds of hidden services ..

Upon reflection, I get that I was misguided. Commenting out a hidden
service wouldn't stop a DoS attack through your tor process. The fastest
way would be to configure all of the hidden services through a second
tor process, and wait for the directories to update. Then move them
back, one by one. The process could be scripted, but it would still take
a long time to do properly, given how long it takes the tor network to
respond to changes.

Maybe it would be better to run many tor instances, and put fewer hidden
services on each instance. That way, one black sheep wouldn't take down
everything. Also, segregating the tor processes and hidden services in
multiple VMs would be more secure, albeit heavier.


Hi, thanks for the suggestion, we thought about the same solutions, but they are very cumbersome / unsure / expensive.

Our opinion is that if you provide a feature (Tor hidden services)
and having many hidden services on a single Tor instance is supported,
you _must_ provide the tools to debug / monitor / audit.

Perhaps the new implementation of the hidden services will be better ? How is it going ?

Or perhaps we can contact a Tor developer ? Anyone listening and willing to dig into this ?

We have the feeling that the commands 'usefeature extended_events + usefeature verbose_names + setevents circ' on the Tor control port was a step in the right direction
and maybe something else must be enabled
or we have to look for different log events.

Thanks for your help!
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk