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

[fuckyouhosting at ruggedinbox.com]

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