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

I thought I'd better report this event, as it occurred shortly after upgrading to 3.2.8-rc. Regarding: BF735F669481EE1CCC348F0731551C933D1E2278 This relay ran 3.2.6-rc through the initial DOS and did not appear to be involved/affected. It was upgraded to 3.2.8-rc yesterday around 0400 UTC,

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

Hi I've implemented following mitigations: * limit memory in queues. For my system that's a safe yet large enough setting (2gb system mem, current usage around 320mb). MaxMemInQueues 768 MB * connlimit: both count & rate. Although, based on observations, only the rate limit is actually being

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

> On Thu, Dec 21, 2017 at 10:11:47PM +0100, Felix wrote: > 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

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

I got also 17 from ovh (under ip-54-36-51.eu) and plenty of leaseweb.com (didn't count) too but no your-server.de The OVH ones were interestingly 2 (nearby) consecutive blocks of 4 and 13 IPs (and are not relays) On 22 December 2017 at 15:23, Tyler Johnson wrote: > Every

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

Every IP I was checking through Atlas which are part of the mentioned hosts were NOT relays, all client connections. On Dec 22, 2017 9:20 AM, "niftybunny" wrote: > Thats “only” “relays” with multiple connections to your relay? > Interesting to see Hetzner there …

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

Thats “only” “relays” with multiple connections to your relay? Interesting to see Hetzner there … Markus > On 22. Dec 2017, at 16:14, Tyler Johnson wrote: > > Out off 133 IPs blocked with my rather aggressive firewall ruleset: > > leaseweb.com -

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

Out off 133 IPs blocked with my rather aggressive firewall ruleset: leaseweb.com - 26 your-server.de - 66 ip-54-36-51.eu - 17 That was in < 24hrs. On Dec 22, 2017 3:38 AM, "niftybunny" wrote: > Short answer: > > https://i.imgur.com/8QLptcz.png > > Around 15000 -

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

Short answer: https://i.imgur.com/8QLptcz.png Around 15000 - 18000 connections I can see with netstat. Even my 300 mbit exit has less and there a a lot of Leaseweb clients connecting to me ... The interesting thing is, it comes and goes in waves. From 6000

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

Am 22-Dec-17 um 08:25 schrieb niftybunny: > Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I > need 2 xeons to push 30 mbit as a guard/middle … Do you want to share some information: Type i) (memory exhaustion by too many circuits) What is the memory(top) per tor and its

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

Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I need 2 xeons to push 30 mbit as a guard/middle … Markus > On 22. Dec 2017, at 00:25, teor wrote: > > > On 22 Dec 2017, at 10:08, Roger Dingledine wrote: > (Connection refused;

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

On 22 Dec 2017, at 10:08, Roger Dingledine wrote: >>> (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

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

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

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

Hi, You can block inbound connections if you like, but it's only a partial mitigation for the attack. > On 22 Dec 2017, at 06:42, mick wrote: > > So: My logs show Tor staying up for around 10 minutes at a time before > rebooting with the following sort of entries: > ... > Dec

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

Hi mick > And I run 0xbaddad - EA8637EA746451C0680559FDFF34ABA54DDAE831 a guard > (though whether it stays a guard depends. It keeps falling over.) Still guard > (As an aside, I'd be very > grateful for any feedback from other relay operators who /have/ added > iptables "connlimit" rules. What

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

On Wed, 20 Dec 2017 17:22:54 +0100 fco...@wardsback.org allegedly wrote: > Hi > > I'm the happy maintainer of wardsback : > B143D439B72D239A419F8DCE07B8A8EB1B486FA7 And I run 0xbaddad - EA8637EA746451C0680559FDFF34ABA54DDAE831 a guard (though whether it stays a guard depends. It keeps falling

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

Le 20/12/2017 à 23:15, teor a écrit : > >> On 21 Dec 2017, at 08:51, teor wrote: >> >>> >>> 1) Why didn't we see this abuse wave coming ? We kept replying to reporters >>> of the dreaded "Failing because we have XXX connections already. Please >>> read doc/TUNING for

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

> On 21 Dec 2017, at 08:51, teor wrote: > >> >> 1) Why didn't we see this abuse wave coming ? We kept replying to reporters >> of the dreaded "Failing because we have XXX connections already. Please read >> doc/TUNING for guidance" about how they could amend their config

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

> On 21 Dec 2017, at 03:22, fco...@wardsback.org wrote: > > Hi > > I'm the happy maintainer of wardsback : > B143D439B72D239A419F8DCE07B8A8EB1B486FA7 > > As many of us have noticed, many guard nodes are beeing abused by extremely > high numbers of connection attempts. > Thanks to some of you

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

Hi I'm the happy maintainer of wardsback : B143D439B72D239A419F8DCE07B8A8EB1B486FA7 As many of us have noticed, many guard nodes are beeing abused by extremely high numbers of connection attempts. Thanks to some of you guys, I manged to put some mitigation in place [0] and I assume many of