[tor-relays] Recent wave of abuse on Tor guards

[Roger Dingledine]

On Thu, Dec 21, 2017 at 10:11:47PM +0100, Felix wrote:
> It's currently good to be restrictive. May-be a *per ip* limit of 20
> (slow DoS) and a *per ip* rate of 1 per sec (fast DoS) is good.

I'm getting up to speed on this issue (been absent for some days).

My current thought is that these are actually Tor clients, not intentional
denial-of-service attacks, but there are millions of them so they are
producing surprises and damage. (Also, maybe there is not a human behind
each of the Tor clients, so maybe we shouldn't value them as much as we
would value more Tor Browser users.)

> I am on Freebsd

The Freebsd relays running Tor 0.3.2 will especially benefit from
today's 0.3.2.8-rc release, because bug 24671 only affects non-Linux or
ancient-Linux relays:

  o Minor bugfixes (scheduler, KIST):
    - Use a sane write limit for KISTLite when writing onto a connection
      buffer instead of using INT_MAX and shoving as much as it can.
      Because the OOM handler cleans up circuit queues, we are better
      off at keeping them in that queue instead of the connection's
      buffer. Fixes bug 24671; bugfix on 0.3.2.1-alpha.

> > (Connection refused; CONNECTREFUSED; count 18; recommendation warn;
> > host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443)
> > 
> > So - I get loads of CONNECTREFUSED whilst coming up (presumably because
> > of the attack) and then come fully back online. 

> IMO your tor searches for guards and they are under load, gone or lost
> their guard flag. Finally you found a guard :)

Yes, I agree. (Though if they were gone or lost their guard flag, you
would not have tried them and gotten a CONNECTREFUSED. So I think they
are all suffering from the "under load" case. Gosh.)

--Roger