[tor-relays] Re: Shutting down my ~40 guards

[tor--- via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

Would setting a bandwidth limit and hibernating your nodes instead of shutting them down be also a stopgap measure?

https://support.torproject.org/relays/performance/bandwidth-limits/

On October 15, 2026 9:52:27 PM UTC, forest via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:
>On 2026-10-15 16:45, Tor at 1AEO via tor-relays wrote:
>> Two main defenses we've found successful across ~800 guard relays the
>> last 5 months of the various attacks:
>> 
>> 1) Over provision CPU and RAM
>> Few cores available per relay and enough RAM to let a few relays spike
>> from 16-30GB (max we've seen is 90GB for one relay).
>> 
>> 2) Use mimallc to return the freed RAM faster than glibc, avoiding OOM
>> more often
>> Swap can help temporarily until mimallc frees the RAM
>
>I'm sure that works for large dedicated servers, but there's not much
>that can be done when you have 62 VPSes and a Raspberry Pi with 1-2 GB
>each spread across the globe. All my servers are resource constrained,
>although I do use jemalloc2 (but not mimalloc) to reduce memory use.
>
>In my situation, memory use isn't even the limiting factor. My relays
>rarely OOM before the provider suspends them for bandwidth overuse.
>
>The full solution is to expand on these:
>
>https://gitlab.torproject.org/tpo/core/tor/-/work_items/40589
>https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/756
>
>It's a security issue related to TROVE-2022-003, which had a fix that
>was incomplete and did not mitigate a related vulnerability. A proper
>fix _should_ stop the attacker dead in their tracks or at last vastly
>increase their resource requirements.
>
>> Few blogs with more details from the beginning of the June and July
>> attacks, which are still ongoing: https://1aeo.com/blog
>
>The circuit-building attack is under control on my relays, since I'm
>protecting from it on the firewall-level using a ruleset inspired by
>toralf's iptables generator. Unfortunately, the BEGIN_DIR flood cannot
>be mitigated using that method since each connection contains multiple
>multiplexed circuits, each of which can multiplex multiple streams.
>
>Thank you very much for your work on documenting present and past DoS
>attacks against the Tor network, btw! Your insight is invaluable.
>
>Regards,
>forest
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx