-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqCn9gAKCRAw+TRLM+X4 xuy7AQCmmd6TvF4MSr8c04pbHVl3Emw0SufRO0Vxg4XFnz7jtQEAnE7u4Y653gn6 vdzmiDOP9VJT9fDDSP4LXqu64XHh9gE= =9jHQ -----END PGP SIGNATURE-----
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
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,
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-09-09 23:05, Red Oaive wrote:
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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqIIhwAKCRAw+TRLM+X4 xq+QAQCJh3IO5eYWGx4+MFx6YmL05hUP3bqZiPmxiTv09IZTWgD+L0Ad55qWZTVX BklFuz+6PUZkdTMiu77n/uoPTly6bAw= =x9Y+ -----END PGP SIGNATURE-----
On 2026-09-10 01:31, forest via tor-relays wrote:
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/tra... 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-09-10 18:55, Red Oaive via tor-relays wrote:
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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqTomAAKCRAw+TRLM+X4 xpYkAPkBf4BSgNx0K4D17seG3KUm0s6bpfUyJQEpEfXrgx3CfwD+IHHz3n36mGfH NvuXPrv0noX3BeXDCDcWQ7QgajsMCQE= =ArQp -----END PGP SIGNATURE-----
On 2026-09-12 05:52, forest via tor-relays wrote:
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-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.
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.htm... 107.173.7.218 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 45.137.100.160 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 136.243.175.182 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 172.104.234.114 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 213.95.55.63 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 82.126.182.66 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 192.186.127.123 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 109.255.184.38 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 78.43.117.254 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 172.233.242.114 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 207.180.192.66 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... 172.232.111.152 http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.htm... [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.htm... 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: https://www.digidow.eu/experiments/onion-stats/ 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. On 2026-09-13 05:15, Red Oaive via tor-relays wrote:
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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqepkQAKCRAw+TRLM+X4 xgn9AQCiibaPBI94i1djxzpV9H6zKDK5mPhLEFPj8M3ds6wacwD/dOFSukQM86Qn GBdhhQJZ2iuEizZ13bWtJ19NW5Ze5gU= =JjXU -----END PGP SIGNATURE-----
Red Oaive via tor-relays:
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.
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: https://www.digidow.eu/experiments/onion-stats/
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 _______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2026-09-14 08:58, Georg Koppen via tor-relays wrote:
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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqe/DwAKCRAw+TRLM+X4 xg9kAQD8jkRnH6rp9dbQo+SKnUyuPA7rXsJ7lQnnv3MO10FgLAD/bidKC4uTpuAx icGPffC0jroRMlSo+t6e8Yh4pPALpQ0= =zEEv -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqn5YAAKCRAw+TRLM+X4 xrffAP9B4L7sQNHi7WbNAWz+XXnbPOuFfpQ0k8CZWNYaqJIOPQEAvv6pLqXpXGes sp+DxFlyHb2CNN8Lo1ips8Z+ONGmHQo= =B7sJ -----END PGP SIGNATURE-----
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.
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" ?
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. -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The attack has gotten so bad that even MetricsPort hangs for 10+ seconds before responding while the attack is ongoing. On 2026-09-16 15:26, boldsuck via tor-relays wrote:
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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCarHSOAAKCRAw+TRLM+X4 xij5AP90xJuVVK3bu4Uo4e5lh7rejZXh73BOsdmDYnpFhIsZoAD9FtL9iPHXh5iA sUUe08dKH9AH63zRpwPcdTD2zdIeMAw= =ZCFT -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCarMTOAAKCRAw+TRLM+X4 xgk1AP9TJLaJfeG745mpSmr8/6ru0/Paks1gp2DNrEFEjVh26gEArcE7G3EIESmv b4Ia9CUpXZMAn9ZRQSx3LRFrA57Wogk= =EI4H -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCarnJrgAKCRAw+TRLM+X4 xjGVAP9GTmust6eS0wf8ZR8RIV02198zRC8aE7jRxx/bikxtIAEAkCamVOmt31cK jR4rsrxIk70pFzzgC8HDvVeiQDlWCAY= =3zSF -----END PGP SIGNATURE-----
I observed what appears to be a very similar traffic pattern today on a FreeBSD 15.1 Tor relay in Finland. The relay normally has fairly symmetric RX/TX traffic, but suddenly became extremely asymmetric and bursty. During one ~6 minute sample, RX averaged 13.9 Mbps while TX averaged 101.4 Mbps, with TX peaking at 348.8 Mbps. At times RX dropped close to zero while TX remained very high. During the event, Tor CPU usage increased significantly and SSH repeatedly became unresponsive. The FreeBSD kernel started reporting: kern.ipc.nmbjumbop limit reached kern.ipc.nmbclusters limit reached After Tor eventually stopped running, the VPS itself was still up (no reboot). netstat -m showed: 1522690/0/0 requests for jumbo clusters denied (4k/9k/16k) I restarted Tor after the system recovered, and the abnormal traffic pattern immediately returned. I have now stopped Tor temporarily. The relay is a non-exit relay and only recently received the Guard flag. I cannot confirm that this is the same attack discussed in this thread, but the asymmetric traffic and resulting resource exhaustion seem very similar. Sent with Proton Mail secure email. On Wednesday, September 23rd, 2026 at 5:51 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
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
So much fun. Sent with Proton Mail secure email. On Sunday, September 27th, 2026 at 8:35 PM, kullikovana <kullikovana@proton.me> wrote:
I observed what appears to be a very similar traffic pattern today on a FreeBSD 15.1 Tor relay in Finland. The relay normally has fairly symmetric RX/TX traffic, but suddenly became extremely asymmetric and bursty. During one ~6 minute sample, RX averaged 13.9 Mbps while TX averaged 101.4 Mbps, with TX peaking at 348.8 Mbps. At times RX dropped close to zero while TX remained very high. During the event, Tor CPU usage increased significantly and SSH repeatedly became unresponsive. The FreeBSD kernel started reporting: kern.ipc.nmbjumbop limit reached kern.ipc.nmbclusters limit reached After Tor eventually stopped running, the VPS itself was still up (no reboot). netstat -m showed: 1522690/0/0 requests for jumbo clusters denied (4k/9k/16k) I restarted Tor after the system recovered, and the abnormal traffic pattern immediately returned. I have now stopped Tor temporarily. The relay is a non-exit relay and only recently received the Guard flag. I cannot confirm that this is the same attack discussed in this thread, but the asymmetric traffic and resulting resource exhaustion seem very similar.
Sent with Proton Mail secure email.
On Wednesday, September 23rd, 2026 at 5:51 AM, forest via tor-relays <tor-relays@lists.torproject.org> wrote:
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
My "almost" brand new relay ( three weekss old ) was attacked two times. While 2nd attack I reduced BandwidthRate and BandwidthBurst drastically to 1 and 2 Mbyte and reloaded ( not restared ) tor service ( knowing the possible lost of the "fast" flag ). Some time later it lost the HSDir flag and the attack was over due this... What I had on my mind was not to loose "stable" flag. HSDir flag is now back after 4 days. Since I'm a newbie I had no better ideas. Regards On Mon, 28 Sep 2026, forest via tor-relays wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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 -----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCarnJrgAKCRAw+TRLM+X4 xjGVAP9GTmust6eS0wf8ZR8RIV02198zRC8aE7jRxx/bikxtIAEAkCamVOmt31cK jR4rsrxIk70pFzzgC8HDvVeiQDlWCAY= =3zSF -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
participants (7)
-
3hn92a＠cock.li -
boldsuck -
forest -
Georg Koppen -
iji＠gmx.net -
kullikovana -
Red Oaive