[tor-relays] Re: How is this attack causing 900 Mbps download and 100 Mbps upload?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2026-10-09 14:49, khankrum359--- via tor-relays wrote:
> The tool only reads Tor's local MetricsPort and Linux /proc. It does
> not use the ControlPort and does not change, reload, restart,
> throttle, or otherwise modify Tor.

Does the MetricsPort time out for you often? In my experience, the port
can end up blocking for 10-60 seconds, sometimes longer. Although the
MetricsPort is supposed to be extremely computationally-light, it must
be running synchronously in the event loop or something. I haven't read
the code at all, but the attack makes Tor almost totally unresponsive.

> I am deliberately calling this a "BEGIN_DIR storm" rather than an
> attack. The measurements show a very unusual workload and a strong
> correlation, but they do not establish intent or prove the underlying
> cause.

It is absolutely an attack. At first I thought it was attempting to do
guard discovery on some client or onion service by systematically taking
down guards, but it seems all it's really trying to do is cause relays
to lose the HSDir flag. I don't know why. Maybe they're trying to DoS a
specific onion service by going after the HSDirs that it uses?

> One experiment I have not yet reproduced myself under controlled
> monitoring is the DirCache 0 behaviour described earlier in this
> thread, where the dominant traffic direction appears to reverse.

I captured that, including debug logs, and sent it privately to the Tor
developers. I'm unsure what they've been able to glean from it yet, if
anything. I'm still waiting to see if they have any ideas for some sort
of mitigation. At the very least, limiting the number of directory fetch
streams that a single circuit could have simultaneously open might help.

I suppose the attacker is just opening thousands of streams per circuit
with BEGIN_DIR. Something akin to the existing DoSStreamCreationEnabled
defense, but not limited to exit relays' DNS and exit streams, might be
able to mitigate this attack, or at least reduce the impact it has.

> Feedback from Tor developers or relay operators on the metrics,
> thresholds, or anything else worth recording would be very welcome.

Why not record all metrics? I wrote my own script that simply saves the
Prometheus report from MetricsPort every 30 seconds. The majority of the
script's complexity comes from ensuring that the metrics are encrypted
with public key encryption so that the server never has more than half
an hour of plaintext in memory at any given time. I'd be happy to share
it if you'd like.

Regards,
forest
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasmVYgAKCRAw+TRLM+X4
xsJrAQDqYJzA6IQJFor6YzZNhnUhPzrkCWWQ9FsxS2jcw3PEZAEA6lXNAGlanrm4
xUpqTQKKjXYXMC5Xn3pXtlvbeNnxLQM=
=M5L1
-----END PGP SIGNATURE-----
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx