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

[Mirimir <mirimir@xxxxxxxxxx>]

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.
-- 
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