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

[l.m]

> 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