On Sat, 08 Nov 2014 22:10:23 +0000 Fears No One <[email protected]> wrote:
> BEGIN TINFOIL > > Upon scrolling through the .xz files (I personally use xzless), you'll > find a bunch of stuff like: > > 1 > /%5C%22http://www.hackforums.net/code/fail/code/code/code/code/code/ > ... > > All of the requests were around (If I recall correctly) 3KB in size. > Oddly enough, it caused tor to hiccup pretty badly, although the web > server itself was just fine and I didn't have any network bandwidth > problems (i.e. No obscene traffic spikes). It's also worth pointing out > that the tcp buffers weren't even close to maxed. The same box has > handled a similar volume of legitimate requests before (Namely back in > March, after The Hidden Wiki debacle; see > https://twitter.com/loldoxbin/status/530765088366821377). The solution > to getting tor availability back was to set ConstrainedSockets to 1 and > play with ConstrainedSockSize (Originally set to 8192, then 4096). This > made doxbin regularly available again, whereas before it was hit or > miss. Once the requests stopped, I waited a couple of days before > commenting those two config lines out and reloaded tor. > > A month later, the same kinds of requests started coming in again. After > the first few hours, I started 301 redirecting all requests containing > /%5C%22 to the new Hidden Wiki's Hard Candy page. I also added a grep -v > to my log report script in order to filter out the noise (Possibly a > mistake, but we both tailed logs and watched for something like a > different attack style that the ddos was being used to cover and never > noticed anything). That was good enough to maintain availability, so I > rolled with it and the requests eventually stopped. I have no hard data > on that last point, just the fact that I tailed the access log and the > requests went from 5 per second to 1 every 3-6 seconds before dying off > completely. Do you have more detailed logs? I'm specifically interested in the timing data of these requests (like the logs web servers keep for "analytics"). The HS may have been subject to a traffic confirmation attack (aka cross-correlation attack) and the timing data could disprove this. Mansour _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
