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.