[tor-talk] (D)DOS over Tor network ? Help !
fuckyouhosting at ruggedinbox.com
fuckyouhosting at ruggedinbox.com
Tue Dec 2 19:27:04 UTC 2014
On 2014-12-02 02:51, Mirimir wrote:
> On 12/01/2014 03:44 PM, fuckyouhosting at ruggedinbox.com wrote:
>> On 2014-12-01 07:55, Mirimir wrote:
>>> On 12/01/2014 12:13 AM, fuckyouhosting at ruggedinbox.com wrote:
>>>> On 2014-12-01 02:24, Christian Gagneraud wrote:
>>>>> On 01/12/14 14:46, fuckyouhosting at ruggedinbox.com 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!
More information about the tor-talk
mailing list