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

Mailing Lists tor-relays
1

Hello.

I'm experiencing a very strange high-bandwidth attack against my exit
F79C822281CB1001E589296C80ABA6EA5DC7E36A. At first it was a directory
fetch attack, slowing it to a crawl due to upload exceeding 700 Mbps
(while download was never over 50 Mbps). I added "DirCache 0" to torrc
as a stop-gap measure, but after reloading, the attack has changed and
now *download* is excessive, showing 900 Mbps down and 100 Mbps up.

How is this possible? What kind of attack could cause such asymmetric
load in the *download* direction? I confirmed with nyx that it was
downloading at nearly 10x the rate that it was uploading. This relay
rarely exceeds 100 Mbps bidirectionally under normal conditions.

Of the 60 relays I operate, this is the only one that appears affected.
I'm urgently in need of advice for troubleshooting this.

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

2

Same here, but in the opposite direction for a middle relay.
The outgoing traffic was around ten times greater than the incoming traffic.
Update to v0.4.9.12 did not help.
No ddos at TCP layer, conn-limit and rate-limit normal.

60-seconds diff of metrics dump for the devs:
-tor_relay_connections_total{type="OR",direction="initiated",state="created",family="ipv4"} 1145
-tor_relay_connections_total{type="OR",direction="initiated",state="created",family="ipv6"} 425
-tor_relay_connections_total{type="OR",direction="received",state="created",family="ipv4"} 3887
-tor_relay_connections_total{type="OR",direction="received",state="created",family="ipv6"} 2505
+tor_relay_connections_total{type="OR",direction="initiated",state="created",family="ipv4"} 1154
+tor_relay_connections_total{type="OR",direction="initiated",state="created",family="ipv6"} 427
+tor_relay_connections_total{type="OR",direction="received",state="created",family="ipv4"} 3889
+tor_relay_connections_total{type="OR",direction="received",state="created",family="ipv6"} 2519
@@ -118 +118 @@
-tor_relay_connections_total{type="Metrics",direction="received",state="created",family="ipv4"} 15
+tor_relay_connections_total{type="Metrics",direction="received",state="created",family="ipv4"} 16
@@ -131 +131 @@
-tor_relay_circ_proto_violation_total 32204
+tor_relay_circ_proto_violation_total 32887
@@ -134 +134 @@
-tor_relay_est_rend_total{action="success"} 54
+tor_relay_est_rend_total{action="success"} 56
@@ -146 +146 @@
-tor_relay_load_onionskins_total{type="ntor",action="processed"} 3087
+tor_relay_load_onionskins_total{type="ntor",action="processed"} 3147
@@ -148 +148 @@
-tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} 158303
+tor_relay_load_onionskins_total{type="ntor_v3",action="processed"} 161425
@@ -155 +155 @@
-tor_relay_intro1_total{action="unknown_service"} 73
+tor_relay_intro1_total{action="unknown_service"} 74
@@ -161 +161 @@
-tor_relay_destroy_cell_total 125358
+tor_relay_destroy_cell_total 127971
@@ -178 +178 @@
-tor_relay_congestion_control_total{state="cc_limits",action="above_delta"} 164303
+tor_relay_congestion_control_total{state="cc_limits",action="above_delta"} 166843
@@ -181,3 +181,3 @@
-tor_relay_congestion_control_total{state="cc_circuits",action="circs_created"} 155254
-tor_relay_congestion_control_total{state="cc_circuits",action="circs_closed"} 149399
-tor_relay_congestion_control_total{state="cc_circuits",action="circs_exited_ss"} 93987
+tor_relay_congestion_control_total{state="cc_circuits",action="circs_created"} 158334
+tor_relay_congestion_control_total{state="cc_circuits",action="circs_closed"} 152560
+tor_relay_congestion_control_total{state="cc_circuits",action="circs_exited_ss"} 95829
@@ -189,2 +189,2 @@
-tor_relay_traffic_bytes{direction="read"} 8492777654
-tor_relay_traffic_bytes{direction="written"} 153599293076
+tor_relay_traffic_bytes{direction="read"} 8685321262
+tor_relay_traffic_bytes{direction="written"} 157162466254
@@ -193,5 +193,5 @@
-tor_relay_congestion_control{state="slow_start_exit",action="cwnd"} 344
-tor_relay_congestion_control{state="slow_start_exit",action="bdp"} 158
-tor_relay_congestion_control{state="slow_start_exit",action="inc"} 31
-tor_relay_congestion_control{state="on_circ_close",action="cwnd"} 296
-tor_relay_congestion_control{state="on_circ_close",action="ss_cwnd"} 243
+tor_relay_congestion_control{state="slow_start_exit",action="cwnd"} 332
+tor_relay_congestion_control{state="slow_start_exit",action="bdp"} 146
+tor_relay_congestion_control{state="slow_start_exit",action="inc"} 30
+tor_relay_congestion_control{state="on_circ_close",action="cwnd"} 287
+tor_relay_congestion_control{state="on_circ_close",action="ss_cwnd"} 247
@@ -200,10 +200,10 @@
-tor_relay_congestion_control{state="cc_backoff",action="chan_blocked_pct"} 75
-tor_relay_congestion_control{state="cc_backoff",action="gamma_drop"} 18
-tor_relay_congestion_control{state="cc_backoff",action="delta_drop"} 13
-tor_relay_congestion_control{state="cc_backoff",action="ss_chan_blocked_pct"} 10
-tor_relay_congestion_control{state="cc_cwnd_update",action="alpha_pct"} 6
-tor_relay_congestion_control{state="cc_cwnd_update",action="beta_pct"} 51
-tor_relay_congestion_control{state="cc_cwnd_update",action="delta_pct"} 0
-tor_relay_congestion_control{state="cc_estimates",action="ss_queue"} 83
-tor_relay_congestion_control{state="cc_estimates",action="queue"} 181
-tor_relay_congestion_control{state="cc_estimates",action="bdp"} 133
+tor_relay_congestion_control{state="cc_backoff",action="chan_blocked_pct"} 76
+tor_relay_congestion_control{state="cc_backoff",action="gamma_drop"} 19
+tor_relay_congestion_control{state="cc_backoff",action="delta_drop"} 12
+tor_relay_congestion_control{state="cc_backoff",action="ss_chan_blocked_pct"} 13
+tor_relay_congestion_control{state="cc_cwnd_update",action="alpha_pct"} 16
+tor_relay_congestion_control{state="cc_cwnd_update",action="beta_pct"} 37
+tor_relay_congestion_control{state="cc_cwnd_update",action="delta_pct"} 1
+tor_relay_congestion_control{state="cc_estimates",action="ss_queue"} 92
+tor_relay_congestion_control{state="cc_estimates",action="queue"} 179
+tor_relay_congestion_control{state="cc_estimates",action="bdp"} 134
@@ -216 +216 @@
-tor_relay_connections{type="OR",direction="initiated",state="opened",family="ipv4"} 808
+tor_relay_connections{type="OR",direction="initiated",state="opened",family="ipv4"} 810
@@ -218,2 +218,2 @@
-tor_relay_connections{type="OR",direction="received",state="opened",family="ipv4"} 251
-tor_relay_connections{type="OR",direction="received",state="opened",family="ipv6"} 1206
+tor_relay_connections{type="OR",direction="received",state="opened",family="ipv4"} 135
+tor_relay_connections{type="OR",direction="received",state="opened",family="ipv6"} 1207
@@ -297 +297 @@
-tor_relay_circuits_total{state="opened"} 5814
+tor_relay_circuits_total{state="opened"} 5722
@@ -300 +300 @@
-tor_relay_load_socket_total{state="opened"} 6705
+tor_relay_load_socket_total{state="opened"} 6701
@@ -305 +305 @@
-tor_relay_streams_total{type="BEGIN_DIR"} 3071513
+tor_relay_streams_total{type="BEGIN_DIR"} 3141550

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

3

I am experiencing the very same attack on two of my relays. At first my upload is 4-8 times upload. When I add DirCache 0, I then get download 2:1 over upload.

Likely repeated directory fetch requests which are being denied once DirCache 0 is specified, hence the massive upload to download before DirCache 0 and the 2:1 download to upload after.

This is a very serious attack, it is clearly through well planned and carefully coded malicious tor instances and does not require repeated connections and thus bypasses firewall connection rate rules.

One relay currently under this attack is $3370227A57DFC88D3CE68AA6B4FC4E13438F0AC7.

···

On 2026-09-09 00:27, forest via tor-relays wrote:

Hello.

I'm experiencing a very strange high-bandwidth attack against my exit
F79C822281CB1001E589296C80ABA6EA5DC7E36A. At first it was a directory
fetch attack, slowing it to a crawl due to upload exceeding 700 Mbps
(while download was never over 50 Mbps). I added "DirCache 0" to torrc
as a stop-gap measure, but after reloading,

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

4

I am experiencing the very same attack on two of my relays. At first
my upload is 4-8 times upload. When I add DirCache 0, I then get
download 2:1 over upload.

I tried a little troubleshooting while the attack was occurring, but had
to give up eventually because my SSH connection was so slow and because
I would soon exceed my provider's CPU fair-use-policy (CPU was 100%). I
found that setting "BandwidthRate" does _not_ help reduce CPU usage. The
asymmetric traffic is still there yet CPU usage remains 100%.

The fact that limiting traffic does not reduce CPU usage even though it
does reduce traffic is both interesting and very concerning.

This is a very serious attack, it is clearly through well planned and
carefully coded malicious tor instances and does not require repeated
connections and thus bypasses firewall connection rate rules.

When Tor was in the shutting down state and not accepting new circuits,
the attack immediately became ineffective. I suspect it's involving a
large number of new but short-lived connections rather than several
long-lived connections doing fetches over and over. When trying to find
out which IPs were involved, I had to give up because no IP transferred
over 2 MiB over a 10 second period, even during the attack.

I also use a firewall to limit connection rates, based on toralf's but
with some significant modifications. It's stricter in some ways, as it
will block all IPs from a /24 if more than 8 connections/minute or 32
connections/hour are made, and it disallows more than 20 simultaneous
connections from a single /24 regardless of connection rate. But it's
only measuring new connections as "tcp flags & (syn | ack) == syn" (nft
syntax), so if the attacker is keeping connections established or if
they simply use a larger set of malicious IPs, they'll bypass it. I have
not tried adjusting my firewall's limits to see if it would help.

Can someone find a few IPs that are participating in this attack and
send tcpdump output (with timestamps)? I'm curious if there's a timing
pattern that could be exploited for detection.

One relay currently under this attack is
$3370227A57DFC88D3CE68AA6B4FC4E13438F0AC7.

By shutting down Tor and restarting it 15 minutes later, I was able to
get the attack to stop. In another case when I realized it was targeting
another relay of mine, I had to wait over an hour with Tor off before it
stopped. If I restarted Tor any sooner, it would immediately resume. I
don't know if this is because the attack determined that my relay was
down and stopped attempting connections, or if each attack was set to be
run for a predetermined amount of time and that time happened to elapse.

Regards,
forest

···

On 2026-09-09 23:05, Red Oaive wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

5

Can someone find a few IPs that are participating in this attack and
send tcpdump output (with timestamps)? I'm curious if there's a timing
pattern that could be exploited for detection.

I was, unfortunately, more interested in defending than analysis and I no longer have any attacked nodes.

I only have six relays I run or manage, and two of them had been attacked simultaneously. Including one I would consider a point of interest, which is why I am concerned these are not just DoS attacks but aimed at deanonymizing some traffic. I can imagine several effective timing attacks against tor anonymity that would be highly effective for anyone with the ability to inject disproportionate traffic at will.

By shutting down Tor and restarting it 15 minutes later, I was able to
get the attack to stop. In another case when I realized it was targeting
another relay of mine, I had to wait over an hour with Tor off before it
stopped.

I find the attacks stop within an hour of activating DirCache 0. Likely as the attacker realizes their attack is spinning its wheels and no longer achieving asymmetric replies.

There is also a forum discussion on these attacks. I highly recommend developer input into this as automated defenses from outside tor is problematic at best. My recommendations to developers are in the forum post: https://v236xhqtyullodhf26szyjepvkbv6iitrhjgrqj4avaoukebkk6n6syd.onion/t/traffic-disbalance-and-overload/21926/2

The fact that this attack is a) highly effective, b) circumvents most or all of current firewall protections, and c) NOT widespread leads me to believe it is in use in the wild not to destabilize but either as a proof of concept for something that *could* destabilize Tor at (someone's) will, and/or as a current deanonymizing tool in targeted current use.

So I will reiterate what I said in the forum, that I think this is a serious threat to Tor.

···

On 2026-09-10 01:31, forest via tor-relays wrote:
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

6

I was, unfortunately, more interested in defending than analysis and I
no longer have any attacked nodes.

Defending is exactly why I'm trying to analyze it.

What bothers me the most about the attack is the fact that CPU load is
independent of the amount of bandwidth being used. Even when limiting
the bandwidth rate so the relay is only pushing through a trickle, the
CPU load remains pegged at 100%.

I only have six relays I run or manage, and two of them had been
attacked simultaneously. Including one I would consider a point of
interest, which is why I am concerned these are not just DoS attacks
but aimed at deanonymizing some traffic.

I have 61, but still only saw two of them being attacked. One was an
exit and one was not. Both were serving directory requests. Why do you
consider one particular one of yours a point of interest?

I agree that they aren't just DDoS attacks for the sake of harming the
network. There would be easier ways to do that. It's certainly either an
attempt at deanonymizing some client or server (or even just confirming
or disproving use of a certain guard) or it's part of proof-of-concept
research to do just that.

I find the attacks stop within an hour of activating DirCache 0.
Likely as the attacker realizes their attack is spinning its wheels
and no longer achieving asymmetric replies.

It might just be coincidence that it stops, because the relay is still
suffering extreme asymmetric load (now in the opposite direction) and
_something_ causes the CPU load to remain at 100%. It can't just be
denied directory fetches, since a relay refusing a directory request is
not using a lot of CPU to do so (unlike, say, diffing, compressing, and
sending the directory request itself over and over).

There is also a forum discussion on these attacks. I highly recommend
developer input into this as automated defenses from outside tor is
problematic at best.

I agree and I'm a bit surprised that there hasn't been any announcement
about it or even acknowledgement. Even "we're aware of it and and trying
to figure out solutions" would be helpful. Although I also acknowledge
that they are busy and quickly developing an ad-hoc mitigation probably
isn't going to be one of their priorities. Arti is.

Regarding the forum post, I disagree with the suggestion that offending
relays should be blacklisted. I _highly_ doubt the relays themselves are
aware of the attack. Unlike the recent circuit-building attack that came
from Contabo and Hetzner IPs, this one is routed through the Tor network
itself. The only solution is to limit the amount of resources that a
directory fetch can take up. If a relay is overloaded, I think it would
be much better for the network if directory fetches slowed down than if
everything slowed down to a crawl.

Regards,
forest

···

On 2026-09-10 18:55, Red Oaive via tor-relays wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

7

I agree and I'm a bit surprised that there hasn't been any announcement
about it or even acknowledgement. Even "we're aware of it and and trying
to figure out solutions" would be helpful. Although I also acknowledge
that they are busy and quickly developing an ad-hoc mitigation probably
isn't going to be one of their priorities. Arti is.

Arti will likely have the same vulnerability. And something that can de-anonymize connections today and which could be used to literally cripple every guard on the network tomorrow should be a priority. At least to acknowledge.

Regarding the forum post, I disagree with the suggestion that offending
relays should be blacklisted.

I don't mean the relays experiencing the attack. I mean the relays sending the directory requests. These are clearly ones that are running hacked tor instances. Nothing on the outside of a tor instance can cause it to execute a directory request on another relay. So these aren't relays that are themselves being abused. These are intentionally malicious ones.

The bad news is that since the attacks are coming through malicious relays, there is little outside of tor we can do with a firewall. The good news is that every one of them will have to have a relay fingerprint that can be blacklisted.

I now have a repeat customer re-attacking a relay I manage in the same way. I'm going to do what I can to trace it before I turn off the DirCache again.

I'm getting a constant 4MiB/s download and over 40MiB/s continuous upload. I'm not even sure I have 40MiB/s bandwidth to the public internet on this machine, so this may be very targeted by someone in my provider's data center.

···

On 2026-09-12 05:52, forest via tor-relays wrote:
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

8

Ok, the attack seems to be distributed, but it looks to have a relatively small number of participating relays. Here are relays that look like they are participating:

74.106.232.4 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/BCFE548EA3FF8A0B3610779C238350124A8ED6DE
107.173.7.218 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/369CC0E726E53B8566F25EEB7A72E4F88A217B9B
45.137.100.160 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/19D0F028BADD11B79DC5846C1D75497672E85511
136.243.175.182 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/2687B8534A40D4E1E56B8D93B9009349EA6BF19A
172.104.234.114 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/5FFB97B399ED07472056EEDF2236EA6F265858CA
213.95.55.63 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/B51FAC83BD8CEE69933D9ECA07CAC6A8FF990754
82.126.182.66 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/1C5E491735E906F2A06DA1AE2D26EC0C0494A771
192.186.127.123 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/658239B07EE89F25A9E9B15EFC2B83769209C91D
109.255.184.38 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/77748F5FDA2A5221234CB2100FF4EE9A557F412C
78.43.117.254 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/175D59B37F65EFEB2B9B6B33E53D4754680BBCF9
172.233.242.114 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/7A76496C257941C7D07699525D35F96D868E92F1
207.180.192.66 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/0BA30A3D11B73F95D1447CC9B35BE5F0681D5A1C
172.232.111.152 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/E678A23F9D3E4B0E0934714E03D417E8F8B49A16

[2600:3c01:e000:3a0::] ??? Cannot find a relay with this address in the consensus but shows up in my list.

Notes:
1) MOST but not all are reporting they are outdated Tor versions.
2) They all self-report as low bandwidth servers and show data graphs with low data flow. However, my relay is at this moment sending multiple megabytes per second to each one, enough to single handedly far exceed their entire reported data flow.
3) Many of them have very similar data graph shapes
4) The above are not all nodes that are participating, but all the ones that are that I have high confidence. There are less than 40 in total that are participating.

Lastly, there are a few nodes that are participating which are odd:
140.78.100.35 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.html#details/F97CF76D9121AC28727C22902681A9B539ABAE99
140.78.100.28, 37, 38

These self report as being part of a large tor research project for looking into onion services and each identifies a URL for the research project:

The URL looks legitimate but the nodes in question are absolutely showing the exact same characteristic data graph shape, shows a data flow of 80k/s but where they are actually sinking about 1-2MiB/s from my relay as I write this.

···

On 2026-09-13 03:26, Red Oaive wrote:

I now have a repeat customer re-attacking a relay I manage in the same way. I'm going to do what I can to trace it before I turn off the DirCache again.

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

9

The attacks are getting so severe against some of my more bandwidth-
constrained relays that I may begin needing to shut them down if there
is no mitigation soon. I've already started getting FUP-violation
notices from hosting providers.

I'll be trying one last thing, which is to automatically disable the
directory cache if severe asymmetric bandwidth is detected for more than
a few minutes. Unfortunately a number of issues with Tor's sandbox code
appears to prevent me from simply using "SETCONF DirCache=0" without Tor
crashing due to an assert.

Ok, the attack seems to be distributed, but it looks to have a
relatively small number of participating relays. Here are relays that
look like they are participating:

Are you absolutely sure that the relays themselves are participating?
Because the list you provided have relays with little in common. Some
have been around for days while others have been around for more than a
decade. Some run Linux and some run FreeBSD, etc.

2) They all self-report as low bandwidth servers and show data graphs
with low data flow. However, my relay is at this moment sending
multiple megabytes per second to each one, enough to single handedly
far exceed their entire reported data flow.

That's interesting. The data graphs are self-reported I believe and are
generated from Tor's bandwidth history stats in the state file. If it is
impossible for a legitimate version of Tor to self-report low bandwidth
while making these high-bandwidth requests, then that could show without
a doubt that they themselves are involved (either intentionally or they
are merely a set of relays on servers that have been compromised).

If you have solid evidence that certain relays are participating, you
should send the list to bad-relays@lists.torproject.org. You could also
open a ticket on the bug tracker. Attacks are sometimes discussed there.

Regards,
forest

···

On 2026-09-13 05:15, Red Oaive via tor-relays wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

10

Red Oaive via tor-relays:

I now have a repeat customer re-attacking a relay I manage in the same way. I'm going to do what I can to trace it before I turn off the DirCache again.

Ok, the attack seems to be distributed, but it looks to have a relatively small number of participating relays. Here are relays that look like they are participating:

By participating you mean the relays are doing some attack here? How do you know that not some custom Tor clients are using those relays to fetch directory information from your relay?

And you are sure as well that it's directory requests they are sending and your relay responds to instead of non-directory related traffic?

74.106.232.4 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/BCFE548EA3FF8A0B3610779C238350124A8ED6DE
107.173.7.218 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/369CC0E726E53B8566F25EEB7A72E4F88A217B9B
45.137.100.160 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/19D0F028BADD11B79DC5846C1D75497672E85511
136.243.175.182 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/2687B8534A40D4E1E56B8D93B9009349EA6BF19A
172.104.234.114 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/5FFB97B399ED07472056EEDF2236EA6F265858CA
213.95.55.63 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/B51FAC83BD8CEE69933D9ECA07CAC6A8FF990754
82.126.182.66 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/1C5E491735E906F2A06DA1AE2D26EC0C0494A771
192.186.127.123 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/658239B07EE89F25A9E9B15EFC2B83769209C91D
109.255.184.38 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/77748F5FDA2A5221234CB2100FF4EE9A557F412C
78.43.117.254 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/175D59B37F65EFEB2B9B6B33E53D4754680BBCF9
172.233.242.114 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/7A76496C257941C7D07699525D35F96D868E92F1
207.180.192.66 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/0BA30A3D11B73F95D1447CC9B35BE5F0681D5A1C
172.232.111.152 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/E678A23F9D3E4B0E0934714E03D417E8F8B49A16

[2600:3c01:e000:3a0::] ??? Cannot find a relay with this address in the consensus but shows up in my list.

Notes:
1) MOST but not all are reporting they are outdated Tor versions.

Yeah, 0.4.9.12 is pretty new and everything else got marked as unsupported. So, this is not surprising.

2) They all self-report as low bandwidth servers and show data graphs with low data flow. However, my relay is at this moment sending multiple megabytes per second to each one, enough to single handedly far exceed their entire reported data flow.

Where are you looking at to claim they self-report low bandwidth? Note as well that relays have burst rates, too, that might play a role here. How long are the spikes in sending a lot of bytes to those relays you are seeing?

3) Many of them have very similar data graph shapes

Where do you get that from? The history graphs on relay-search?

4) The above are not all nodes that are participating, but all the ones that are that I have high confidence. There are less than 40 in total that are participating.

Lastly, there are a few nodes that are participating which are odd:
140.78.100.35 http:// hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/ rs.html#details/F97CF76D9121AC28727C22902681A9B539ABAE99
140.78.100.28, 37, 38

These self report as being part of a large tor research project for looking into onion services and each identifies a URL for the research project:
Onion Service Statistics – Digidow

The URL looks legitimate but the nodes in question are absolutely showing the exact same characteristic data graph shape, shows a data flow of 80k/s but where they are actually sinking about 1-2MiB/s from my relay as I write this.

Yes, they have the default burst rate set, thus this is not surprising in itself.

Georg _______________________________________________

···

On 2026-09-13 03:26, Red Oaive wrote:
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

11

By participating you mean the relays are doing some attack here? How
do you know that not some custom Tor clients are using those relays to
fetch directory information from your relay?

That's what I suspected as well, given how different the "participating"
relays are. The real issue is that relays are vulnerable to whatever is
occurring. Already one of my VPSes got suspended due to FUP violations.

And you are sure as well that it's directory requests they are sending
and your relay responds to instead of non-directory related traffic?

The behavior of the attack changes when directory caching is disabled,
with the attack suddenly causing an ingress flood rather than an egress
flood, and CPU usage, while high, isn't pegged at 100% anymore.

I plan to deploy a metrics-collecting script across my fleet (with some
privacy safeguards to ensure the VPS never stores more than a couple of
minutes worth of metrics unencrypted). Hopefully that will give me more
information if it's running while an attack is occurring.

Regards,
forest

···

On 2026-09-14 08:58, Georg Koppen via tor-relays wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

12

Does anyone have any advice? This attack seems to be getting worse.

If any developers would benefit from it, I can provide Tor Metrics with
a sampling interval of 15 seconds along with Tor debug logs during the
attack, along with the hour preceding it and the hour following it. If
so, please message me privately and I will send it PGP-encrypted.

In the meantime, the attacks have caused so many problems with my hosts
that I ended up needing to write a script that monitors bandwidth use
over the control socket. If the bandwidth asymmetry ratio exceeds 1:2
over a 2 minute sliding window and bandwidth rate exceeds 50 Mbps, it
stops the Tor process for 15 minutes before restarting it.

It seems to reduce the impact of the attack on my monthly bandwidth
quotas and prevents my providers from complaining to me about sustained
100% CPU use, but I fear it's effectively only making the DDoS more
powerful as it both reduces the attacker's own bandwidth costs and
guarantees my relays will be completely down whenever they attack (as
opposed to struggling but remaining barely up).

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

13

Does anyone have any advice? This attack seems to be getting worse.

This metric may reveal the attack vector.
-tor_relay_streams_total{type="BEGIN_DIR"} 3071513
+tor_relay_streams_total{type="BEGIN_DIR"} 3141550

~70000 "BEGIN_DIR" within one minute on single non-exit guard relay, normal ~300 "BEGIN_DIR".

What about enabling "DoSStreamCreationEnabled" ?
The default setting is 'auto', but it appears that there is no consensus, so it is currently disabled by default.
The disabled state is also confirmed by the heartbeat log line.

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

14

DoSStreamCreation* options are useful only for a exit relay.

On exit's I recommend:
ReevaluateExitPolicy 1 + _surgeprotector_

DoSStreamCreationEnabled 1
DoSStreamCreationDefenseType 3
# 0|1|2|3 (Default: 0 = use consensus params) If not defined in the consensus, the value is 2.
# 1: No defense. 2: Reject the stream or resolve request. 3: Close the circuit creating too many streams.

···

On Wednesday, 16 September 2026 09:00:31 CEST iji--- via tor-relays wrote:

~70000 "BEGIN_DIR" within one minute on single non-exit guard relay, normal

What about enabling "DoSStreamCreationEnabled" ?

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

15

The attack has gotten so bad that even MetricsPort hangs for 10+ seconds
before responding while the attack is ongoing.

DoSStreamCreation* options are useful only for a exit relay.

It appears it is not useful against this attack on exits. I tried it on
an exit of mine that was under attack at the time, even lowering rate to
25 and burst to 50 (down from the default of 100 and 300) but Prometheus
samples still showed zero mitigation events. I continued to get nearly
700 BEGIN_DIR requests per second, but only 2 BEGIN requests per second.

I suppose there is no mitigation which specifically limits BEGIN_DIR? If
that would fix this, it should be a priority to send out a new emergency
update with such a feature.

Regards,
forest

···

On 2026-09-16 15:26, boldsuck via tor-relays wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

16

I've noticed odd attack behavior when setting DirCache 0 in the middle
of an attack. As mentioned previously, doing that causes the attack to
switch from causing massive outbound traffic to massive inbound traffic,
although with less effect on CPU load. But this attack has some unique
patterns: It alternates between a "pulsing" phase that lasts 15+ minutes
and a "steady" phase that lasts about 3 minutes. When pulsing, traffic
comes in bursts every 3-5 seconds at over 1 Gbps peak. When steady, it
seems to be causing the relay to receive 400-600 Mbps.

I wonder if the "steady" phase is trying to measure the effect of the
"pulsing" phase or something.

No idea if this also happens when DirCache 1 however.

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

17

Several minutes ago, another two of my servers were attacked. I need to
know what I should be doing. I only have a few ideas now:

1. No action. Keep my nodes up, at the risk of losing some of them due
to provider suspensions for extreme network and CPU overuse.

2. Temporarily set DirCache 0 when an attack is detected. This reduces
the negative effects on relaying, but network use remains very high.

3. Permanently set DirCache 0. This might cause the attacker to skip my
relays, but that also means I won't be providing any guards.

4. Shut down the relay for a few hours as soon as an attack starts. This
eliminates bandwidth but also means the attacker controls my uptime.

Until discussion begins for implementing a BEGIN_DIR rate-limiter and a
mitigation rolled out, the attacker will continue completely unimpeded
and users will likely be deanonymized, assuming that is their intent.

In the meantime, I have temporarily shut down those relays.

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

18

Hi all,
A small update from my side.

After observing the same phenomenon on more than one of my relays, I wanted a way to capture it continuously instead of trying to collect diagnostics only after the relay was already overloaded.

I have therefore put together a small passive monitoring tool:

Tor BEGIN_DIR Storm Sentinel

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.

In my own observations, the first obvious operator-visible symptom was the same one described earlier in this thread: sudden and extreme traffic asymmetry on a relay whose traffic is normally much more balanced.

The most useful specific indicator I found in the metrics was BEGIN_DIR. During normal operation it stays very low, but during the abnormal periods I observed it rising to hundreds, and in some samples more than a thousand, per second. This is consistent with iji's earlier observation in this thread of about 70,000 BEGIN_DIR streams in one minute compared with about 300 normally.

One of my relays, for example, was recording roughly 688–764 BEGIN_DIR/s while traffic was strongly asymmetric. Without a Tor restart or PID change, the phenomenon then disappeared abruptly: BEGIN_DIR fell to about 1/s and read/write traffic became almost symmetric again. I have included this transition as an example in the repository README.

The Sentinel records BEGIN_DIR/s, read/write traffic and asymmetry ratio, Tor total and main-thread CPU, circuits, sockets, ntor/ntor_v3 processing and drops, Guard/HSDir flags, and the Tor PID. It samples every 30 seconds normally and every 10 seconds when suspicious activity is detected, and saves raw MetricsPort snapshots around interesting transitions.

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.

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. forest reported this in the original September discussion. If one of my relays enters another storm, I intend to capture a stable baseline first and then test DirCache 0 without restarting Tor while the Sentinel records the transition.

If other relay operators experiencing the same phenomenon want to run the monitor as well, comparable captures from several relays might help determine whether we are all seeing the same underlying behaviour.

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

Regards,
Khan Krum

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

1 Like
19

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

···

On 2026-10-09 14:49, khankrum359--- via tor-relays wrote:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

20

Several of my relays are now under attack again, the moment they HSDir
flag. This happened even before Tor Metrics updated to show it, so the
attacker is clearly actively monitoring the consensus and immediately
attacking all or a subset of relays with the HSDir flag.

How do I prevent a relay from obtaining the HSDir flag without also
disabling the DirCache which is necessary to be a guard?

Regards,
forest

···

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org