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