Delivery-Date: Tue, 02 Dec 2014 16:46:04 -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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	PLING_QUERY,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,URIBL_BLOCKED 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 674B91E0E9F;
	Tue,  2 Dec 2014 16:46:02 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id C203E26436;
	Tue,  2 Dec 2014 21:45:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id CB51423B5E
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 21:45:54 +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 BxG0MsMrsBMh for <tor-talk@lists.torproject.org>;
 Tue,  2 Dec 2014 21:45:54 +0000 (UTC)
Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 9292A22ED4
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 21:45:54 +0000 (UTC)
Received: from smtp2.hushmail.com (localhost [127.0.0.1])
 by smtp2.hushmail.com (Postfix) with SMTP id 77E0BA012A
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 21:45:51 +0000 (UTC)
Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29])
 by smtp2.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Tue,  2 Dec 2014 21:45:51 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id 61AD0A00FC; Tue,  2 Dec 2014 21:45:51 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 02 Dec 2014 16:45:51 -0500
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <5c39d8f9ecd9ac52a55979d6ed0109dc@ruggedinbox.com>
References: <d44c9fb94badc9743f9491dc11db52c0@ruggedinbox.com>
 <547BD14E.3060902@gna.org> <ae0862eb6ac3ff7fa2798255b2676645@ruggedinbox.com>
 <547C1EE3.7010604@riseup.net>
 <ce591bffa5f5cd607106259789f652b1@ruggedinbox.com>
 <547D2935.9040808@riseup.net>
 <5c39d8f9ecd9ac52a55979d6ed0109dc@ruggedinbox.com> 
Message-Id: <20141202214551.61AD0A00FC@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
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>

> Perhaps the new implementation of the hidden services will be better
? 
> How is it going ?

I don't see anything in the improvements suggested for hidden services
that would help this situation. Though I would be grateful for being
corrected.

First, I just want to say I only meant sheep(s) to emphasize that you
don't know how many black sheep you have participating. I mentioned
the part about this potentially being an attack external to Tor out of
concern for your participation in a de-anonymizing attack on your
hosted HS. I see your HS's are offline while you troubleshoot this so
that's good. Next, I'm confused by what you describe. Sorry I deleted
your previous email so I may repeat some things you already said.

- no evidence of any HS being flooded from logs. No evidence of a load
on any particular HS.
and
- next to no bandwidth consumption. Does this include no processor
use? I don't recall if that was mentioned before.

- no evidence is apparent from checking REND_QUERY=HS. So no request
to rendezvous. Might make sense given little/no traffic.

- your guards go offline. This is contradictory. If the attack is
within Tor via a HS it implies the HS traffic *reliably* makes it to
at least your guard before you experience the symptomatic overload and
timeout. Meaning there must be traffic you can detect. Otherwise the
attacker would likely lose their connection to the rendezvous point
(at least sometimes) by committing to the attack. What I mean is in
order for this to be an attack via malicious HS it would need to
succeed in not timing out until the traffic reaches your guard and
server. That's two circuits that must work before failing at your
guard. Not to mention you already tried changing the guards. It just
seems implausible to occur reliably enough to take your server down.
This assumes little/no traffic and no heavy cpu usage.

-- Now I don't know how you setup your logging but I assume you would
know if there was a load on any particular site or flood. I can
suggest beefing up this part of the auditing trail. You could use
proxy (on the same server) in your server blocks (Nginx?) for each HS
(or in batches). Then you can use SPI to analyses the traffic of each
proxy for a build up of use that might be causing your timeouts.
Though I don't see the use if your logging is as good as you
mentioned.

If there's no traffic, no cpu usage, no evidence of HS load except
your guards are timing out--I'm back to the implausible. Two circuits
that reliably take down your guards. There *has* to be traffic on your
side you can measure or some load indicator. Either that or the attack
is external to Tor. On the other hand you could reply and say 'yeh
lots of cpu use'. In which case sorry for wasting your time. If there
is alot of cpu use the VM-partitioning solution is the best solution
as it would guarantee at least some guards available to your other
HS's. It also provides you more granular control over hardware
allocation. Either way you have to assume at some point you will be
targeted externally (from Tor) to de-anonymize your HS's. Shared
hosting.. many HS's.. you're an eavesdropping goldmine.

-- leeroy bearr
-- 
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

