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

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

Hi everyone,

The attack started targeting my relay yesterday at 12:00 UTC, 15 hours after the relay achieved the HSDir flag. This time I had implemented a rate cap (on version 0.4.9.14) for BEGIN_DIR which allowed me to try out a few different things.
The rate limiter has a configurable rate/burst limit and two configurable defense types:
Either
- Refuse the stream by sending END_STREAM_REASON_NOTDIRECTORY back to the offender
Or
- Close the offending circuit by sending -END_CIRC_REASON_RESOURCELIMIT back to the offender

At the beginning of the attack I was limiting BEGIN_DIR requests to 200/s and refusing anything beyond that. The attacker was spawning 300 circuits per second on average and hitting me with ~55,000 BEGIN_DIR requests per second on average. After 8 hours of being attacked the relay logged "1647224804 BEGIN_DIR rejected". During these first 8 hours, the relay remained responsive, with memory usage staying flat at or under 1000MB, main thread CPU usage 20-80% and traffic 200-850 Mbps with a bandwidth ratio of around 2:1 down:up. CPU usage was highly correlated with the amount of traffic being moved. There were also occasional latency spikes while the bandwidth was close to the Gbit line rate.

At 8 hours into the attack I reloaded Tor with the other defense type (close BEGIN_DIR circuits) and lowering the limit to 100 requests per second. Bandwidth usage immediately dropped to 80-100 Mbps in both directions and CPU usage plummeted to <10%. The attack now changed its strategy and started creating circuits at an increasing rate, topping out at 1500 circuits per second, still no match for 12 Ryzen cores though. At the time of writing the attacker is still spawning around 1000 circuits per second and the main thread is at 10% of one core with the circuit work being spread out over the rest of the cores.

This shows the attacker has the capability to send closer to 100,000 requests per second and change its strategy on the fly.

21 hours into the attack the relay is completely stable, bandwidth usage in control and all flags retained. The only downside is that legitimate directory requests get denied while the attack lasts, a minor issue compared to losing the HSDir flag for days at a time. The legitimate requests just retry another directory.

I'll keep you updated.



On Wednesday, October 21st, 2026 at 12:49 PM, TinCan via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Marco,
> 
> Multiple things can cause that warning, an attack is one of them. Hard to tell from the warning message alone, though.
> 
> C-Tor is mostly single-threaded. Some circuit work does get delegated to helper threads, but most of the work happens on the main thread which is the bottleneck.
> 
> 
> On Tuesday, October 20th, 2026 at 6:38 PM, Marco Moock via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > Am 13.10.26 um 08:17 schrieb Marco Moock via tor-relays:
> > > Am 13.10.26 um 00:53 schrieb forest via tor-relays:
> > >> That was only possible in the v2 days, but v3 onion services are blinded
> > >> which means it's not possible to find out the .onion address even if you
> > >> are their HSDir. There's very little an attacker can do in the position
> > >> of HSDir besides selective censorship (if they already know the .onion,
> > >> they can match it to the descriptor and censor it).
> > >>
> > >> CCing Tobias Höller who I know is working on HSDir research and might
> > >> have some insight into this whole situation.
> > >
> > > Are relays known which have HSDir and do such censorship attacks?
> > >
> > > Is there a good way to detect such attacks?
> >
> > Now I got:
> > [warn] Your computer is too slow to handle this many circuit creation
> > requests! Please consider using the MaxAdvertisedBandwidth config option
> > or choosing a more restricted exit policy
> >
> > Is that maybe part of an attack?
> >
> > The machine is an Intel Atom, but normally it was able to handle all the
> > traffic. I also saw that Tor creates load on one core, not on 2.
> >
> > Is Tor able to spawn 2 processes to handle the traffic?
> >
> > --
> > Gruß
> > Marco
> > Muell und Spam bitte an abfalleimer2002@xxxxxxxxxxxxxxxxxxxxxx
> > _______________________________________________
> > tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
> >
> _______________________________________________
> tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
> 
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx