> 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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
