Hello, I've been tearing my hair out a bit lately. I launched a Tor middle relay a few weeks ago, but every so often, I get a dramatic spike in upload traffic, and the relay becomes almost unusable—or even crashes... I thought it might be a DDoS attack, but I'm not sure. Is something going on with the network right now, or is it on my end? I’ve set the relay’s bandwidth rate to 52 MB and 55 MB burst, but sometimes the upload speed hits 100 MB/s… The relay averages around 10 MB, and then suddenly it runs at 60–100 MB/s for several hours at a time. I already have a UFW firewall that only allows the relay ports on my server. It takes a while to get flags, and since my relay crashes because of these network spikes, I lose a good portion of my flags and basically have to start all over again... It's really frustrating. Thanks
Am 31.07.26 um 18:45 schrieb Lavender I Tor Relay via tor-relays:
Hello, I've been tearing my hair out a bit lately. I launched a Tor middle relay a few weeks ago, but every so often, I get a dramatic spike in upload traffic, and the relay becomes almost unusable—or even crashes... I thought it might be a DDoS attack, but I'm not sure.
Most likely. TOR is sometimes DDoSsed.
Is something going on with the network right now, or is it on my end? I’ve set the relay’s bandwidth rate to 52 MB and 55 MB burst, but sometimes the upload speed hits 100 MB/s…
What about RAM/CPU usage in that case? -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
I’m also asking about the Tor network because it seems I’m not the only one experiencing these upload speed spikes recently. It’s comforting to know I’m not alone. Especially since my server is set up very simply, so I don’t really see what could be causing this, but it’s particularly frustrating when you’re trying to help out in your own small way. CPU is at 100%, and I get messages like, “The computer is too slow to handle all these connections.” Overall, the entire relay lags, and it’s crashed only once, but usually it lags heavily for an hour or two, then goes back to normal. RAM usage is at 5% out of 64GB. (3GB in use) During these “attacks”—if I can call them that—there’s also a significant disparity between download and upload speeds. Download speed stays around 10 MB/s, while the upload speed spikes to around 100 MB/s When there aren't any attacks, my CPU usage is around 40–50% at 10–15 MB/s, and RAM usage stabilizes at around 4–5%. Thanks for your help!
Am 31.07.26 um 23:08 schrieb Lavender I Tor Relay via tor-relays:
CPU is at 100%, and I get messages like, “The computer is too slow to handle all these connections.”
And that is the problem. Unless you provide more CPU capacity, you will end up there again when the next attack happens. :-( Happened to my system too, but CPU is an old Intel Atom. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 How many simultaneous connections are involved in one of these directory fetching attacks? If it's only a few, a simple ratelimit in a firewall might be able to help mitigate it. It's a shame the DirPort and ORPort are combined now or we could apply rate-limiting selectively on DirPort. Btw, simply restarting the relay seems to interrupt the attack, probably because the attacker doesn't continuously retry the same relay if the connection gets broken. But that probably kicks them to another relay. I'm guessing the attack works by simultaneously fetching directory data over and over to overload the CPU with compression work? Perhaps a long- term mitigation would be for the Tor process to switch to a lower level of compression (e.g. the equivalent of zstd -1) if it detects that the bottleneck is becoming the CPU rather than the network. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCanE98QAKCRAw+TRLM+X4 xvjEAP96v7/UU+mz/kMdACM31oaVGrIfRpbta0JzAfn7UEgFaAD/YPjrjLiX0syt dh5nIaFQM5/JB9xbBMKikZj2DXhTEwg= =2uOn -----END PGP SIGNATURE-----
participants (3)
-
forest-relay-contact＠cryptolab.net -
Lavender I Tor Relay -
Marco Moock