Delivery-Date: Mon, 01 Dec 2014 21:51:53 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	PLING_QUERY,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,
	UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id AAA0A1E0E9F;
	Mon,  1 Dec 2014 21:51:51 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 7C9F33068E;
	Tue,  2 Dec 2014 02:51:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id CD2D125ACB
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 02:51:40 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wZjyOv-V00ll for <tor-talk@lists.torproject.org>;
 Tue,  2 Dec 2014 02:51:40 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 98C1023EDD
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 02:51:40 +0000 (UTC)
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id C9C45413A3;
 Tue,  2 Dec 2014 02:51:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1417488697; bh=WqtUNgcpcjsdrB5cRs8aVinrR22+bMLavgsPD+kAYow=;
 h=Date:From:To:Subject:References:In-Reply-To:From;
 b=K68HiESAw9b4S0iioKQdZiJBqeAU/7NRk/7Truy11TrK4Myw+WFv09HuvlhcMEFgY
 Gn328uUmeeYQiknTzCwu02N/ns2s3Twg3PAnmdnDO/QE0d2ljKksDJ/L8CqpIJ6hG6
 zuT75NQyycXk9xEwcwHx8dsLmGL90f3jqATF+dr0=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: mirimir) with ESMTPSA id AB26222CA6
Message-ID: <547D2935.9040808@riseup.net>
Date: Mon, 01 Dec 2014 19:51:33 -0700
From: Mirimir <mirimir@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: fuckyouhosting@ruggedinbox.com, tor-talk@lists.torproject.org
References: <d44c9fb94badc9743f9491dc11db52c0@ruggedinbox.com>
 <547BD14E.3060902@gna.org> <ae0862eb6ac3ff7fa2798255b2676645@ruggedinbox.com>
 <547C1EE3.7010604@riseup.net>
 <ce591bffa5f5cd607106259789f652b1@ruggedinbox.com>
In-Reply-To: <ce591bffa5f5cd607106259789f652b1@ruggedinbox.com>
X-Virus-Scanned: clamav-milter 0.98.4 at mx1
X-Virus-Status: Clean
Subject: Re: [tor-talk] (D)DOS over Tor network ? Help !
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 12/01/2014 03:44 PM, fuckyouhosting@ruggedinbox.com wrote:
> On 2014-12-01 07:55, Mirimir wrote:
>> On 12/01/2014 12:13 AM, fuckyouhosting@ruggedinbox.com wrote:
>>> On 2014-12-01 02:24, Christian Gagneraud wrote:
>>>> On 01/12/14 14:46, fuckyouhosting@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

