On 12/01/2014 03:44 PM, fuckyouhost...@ruggedinbox.com wrote: > On 2014-12-01 07:55, Mirimir wrote: >> On 12/01/2014 12:13 AM, fuckyouhost...@ruggedinbox.com wrote: >>> On 2014-12-01 02:24, Christian Gagneraud wrote: >>>> On 01/12/14 14:46, fuckyouhost...@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. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
