At 18:25 12/30/2017 -0500, Roger Dingledine wrote: Thank you Roger for your detailed reply.
I have some observations: 1) An additional contingent of dubious clients exists aside from the newly arrived big-name-hoster instances each generating _hundreds_of_thousands_ of connection requests _per_guard_per_day_: hundreds of scattered client IPs behave in a distinctive bot-like manner, and seem a likely source of excess circuit-extend activity. These IPs have been active since late August this year. 2) Intervals of extreme circuit-extend activity come and go in patterns that resemble attacks to my eyes. In one my guard relay was so overloaded before crashing that no normal user circuits could be created whatsoever. Has never come close to happening before. 3) I run an exit on a much more powerful machine. Normally the exit does not complain "assign_to_cpuworker failed," but recently the exit was attacked two different ways in rapid succession: first it was hit with a DDOS packet-saturation blast calibrated to overload the network interface but not so strong as to trigger the ISP's anti-DDOS system (which works well); the first attack had little effect. Then within two hours the exit was hit with a singular and massive circuit-extend attack that pegged the crypto-worker thread, generating thousands of "assign_to_cpuworker failed" messages. Both attacks degraded traffic flow noticeably but did not severely impact the exit. The attacker gave up (or accomplished their goal), presumably moving on to other targets. 4) Aside from "assign_to_cpuworker failed" overloading, the recent aggravation commenced with a "sniper attack" against my guard relay that resulted in Linux OOM kill of the daemon. Brought it back up with a more appropriate MaxMemInQueues setting and they tried again exactly two times, then ceased. I am certain it was a sniper attack due to the subsequent attempts, and it appears the perpetrator was actively and consciously engaged in attacking a selected target. https://trac.torproject.org/projects/tor/ticket/24737 Here are my two cents: The current stress activity is either or both of 1) a long-running guerilla campaign to harass Tor relay operators and the Tor network, calibrated to avoid attracting an all-hands mitigation and associated bad press, 2) an effort to deanonymize hidden services with various guard-discovery guard-substitution techniques. In light of the above I suggest adding support for circuit-extend rate-limiting of some kind or another. I run Tor relays to help regular flesh-and-blood users, not to facilitate volume traffic/abuse initiated by dubious actors. I wish to favor the former and have no qualms hobbling and blocking the latter. _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
