- tor-relays - lists.torproject.org

Authority Amplified Attack
by Logforme 26 Oct '26

26 Oct '26

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Like many relays mine has been under attack for a while now. Recently it has however become worse. Because of the DirAuths. After having restarted the relay a few time in order to upgrade the tor program in the vain hope there might be a fix for the attack, the attacker now only have to spend a few hours every few days on my relay. The rest of the time it is flagged as non-stable and gets hardly any traffic. Once the DirAuths figure the relay is stable the flags return, and so does the attack. And the DirAuths promptly removes the flags and we go another round around the loop. If the torproject can't find a programmer to fix the actual issue can the DirAuths at least relax the requirements for the stable flag?

5 5

Testers wanted: replacements for the stopped tor-ddos scripts and its relay lists
by Enova Maker 21 Oct '26

21 Oct '26

Hello, The `Enkidu-6/tor-ddos` project was shut down in May and its relay lists are no longer updated. I have published replacements that keep the same commands: - https://www.google.com/url?q=https://github.com/EnovaMaker/tor-ddos-compat&… — same scripts (`download.sh`, `multi.sh`, `update.sh`, ...), iptables/ipset, same set names. Run the download line from the directory of your old install and it offers to reuse your addresses and ports. - https://www.google.com/url?q=https://github.com/EnovaMaker/tor-relay-lists&… — the lists, rebuilt from the Tor consensus, under the same file names except `dual-or`, `overloaded` and the Snowflake lists, which are not covered yet. If you read them yourself, change `Enkidu-6` to `EnovaMaker` in the URL. - https://www.google.com/url?q=https://github.com/EnovaMaker/nixos-tor-anti-d… — the same idea as a NixOS module, using nftables. One difference on purpose: as its README describes the rule, an address is blocked once it has more than two connections, which a one-connection limit never reaches; here a source is blocked after repeated refused connections. It is not production-tested, and I have not seen a real `ipv4.txt` from the old scripts, so I would like to hear from anyone who migrates: did it pick up your addresses and ports, and did it drop any relay that should not have been dropped? MIT licensed. Independent of the Tor Project and of the author of tor-ddos. EnovaMaker

2 2

Re: How is this attack causing 900 Mbps download and 100 Mbps upload?
by Khan Krum 18 Oct '26

18 Oct '26

Hi forest, and everyone, I would like to share a further update following my earlier reports about abnormal BEGIN_DIR activity on three non-exit Tor relays. We have now completed a reproducible retrospective analysis of another prolonged incident on October 17–18, following the earlier episodes on October 4–5, October 8, and October 12–13. This time we had two independent monitoring systems: - Tor Sentinel, collecting standard Tor MetricsPort measurements, including BEGIN_DIR activity, circuit counts and Tor process metrics. - Linux OS Sentinel, independently collecting host and process resource indicators, including CPU, memory, swap and Linux pressure statistics. The second system was added after the earlier incidents revealed that MetricsPort can become temporarily unresponsive during severe overload. Our main observations are: 1. Two ARM relays, hosted by different providers (Hetzner and Oracle Cloud), again experienced substantial, prolonged BEGIN_DIR-related workload. A third, smaller Oracle AMD relay did not show comparable BEGIN_DIR activity. 2. The two affected relays showed different resource profiles. The Hetzner relay experienced very low available memory and substantial swap occupancy. The Oracle ARM relay showed considerable CPU pressure and more monitoring failures despite retaining a much larger memory reserve. 3. The Tor processes remained running. A bandwidth configuration change and reload reported on the Hetzner relay did not immediately end its prolonged abnormal state. 4. Locally observed HSDir flag transitions did not provide a simple explanation for the onset of the workload. We are distinguishing these observations from independently verified directory consensus changes. 5. The recorded BEGIN_DIR peaks are lower bounds on the maximum successfully observed rates, not necessarily the true maxima, because measurements can be lost during overload. We have preserved and validated the underlying measurements and analysis scripts. However, in accordance with Tor’s relay-operator privacy expectations, I am not publishing high-resolution traffic or host statistics. I would be happy to discuss an appropriate private channel for technical review. A few questions for operators and developers: - Have others observed MetricsPort timeouts or degraded responsiveness during comparable BEGIN_DIR workloads? - Have Tor’s MaxMemInQueues protection or circuit-killing notices appeared during these incidents? - Is there any progress on understanding why the experimental BEGIN_DIR rate-limiting approach discussed earlier did not appear effective? - Can Network Health or the directory-authority community help clarify whether overload-related descriptor or consensus effects might explain some of the observed flag changes? - Would a coordinated comparison of daily incident summaries from independent operators be useful? I do not have evidence identifying the origin or intent of this traffic, and I do not want to imply that all reports necessarily have the same cause. My goal is to contribute reliable observations and help identify what further evidence would be useful. Regards, KhanKrum

1 0

Looking to interview Tor relay operators (online or at FOSDEM)
by Jules Dejaeghere 17 Oct '26

17 Oct '26

Hello, I am a researcher at the University of Namur (Belgium), and some of our research focuses on Tor. Recently, we started to investigate how Tor relay operators install and keep their relays up to date. This research was motivated by the (somewhat recent) policy of the Tor Project to exclude outdated relays from the network. As part of this research, we would like to interview relay operators to understand how they install and keep Tor up to date and what they think of the Tor Project policy. If you run, or used to run, Tor relay(s) and are willing to dedicate ~30 minutes of your time, let us know! Your participation will inform our current research about how Tor relay operators manage their relay(s). It will also provide community feedback to the Tor Project about their policy once our results are published. Interviews can be done either online (during the week of 2-6 February 2026, via Framatalk https://framatalk.org/abc/en/) or in person during FOSDEM in Brussels (31 January & 1 February 2026, https://fosdem.org/2026) To participate: - Contact me via email (jules.dejaeghere(a)unamur.be, PGP 0xEB4CC38446E3F82F) or Signal (@julesd.01) - Specify how you want to participate (online via Framatalk, or in person at FOSDEM) and what time slots work for you In practice: - The interview will be audio recorded for analysis by the research team - You can stop the interview at any time, and your answers will be deleted - The interview can be held either in English or in French You'll find attached the full consent form we will ask participants to sign, which describes how the data collected will be processed. If you have any additional questions, you can contact me. Regards, Jules Dejaeghere -- *Jules DEJAEGHERE* PhD Student · Researcher Computer Science Faculty jules.dejaeghere(a)unamur.be https://directory.unamur.be/staff/jdejaegh Université de Namur ASBL Rue de Bruxelles 61 - 5000 Namur Belgium Let’s respect the environment together. *Only print this message if necessary!*

6 14

Re: How is this attack causing 900 Mbps download and 100 Mbps upload?
by Khan Krum 13 Oct '26

13 Oct '26

Hi, I run three hobby relays and I seem to be seeing the same behavior on one of them. I compared two similar ARM, 2-core, non-exit Guard+HSDir relays, both running Tor 0.4.9.13. On the affected relay I measured 41,240 BEGIN_DIR streams in 61 seconds (~676/s). The Tor main thread reaches about 100% CPU, ntor onionskins are being dropped, and traffic is strongly asymmetric — roughly 2.2 MB/s read vs 7.1 MB/s written. On my other Guard+HSDir relay, measured at roughly the same time, I saw only 148 BEGIN_DIR streams in 60 seconds (~2.5/s). That relay carries much more traffic (~15 MB/s in both directions) and appears healthy. So in my case, simply having the HSDir flag does not seem sufficient to trigger the issue. One relay is affected, while another Guard+HSDir relay is not. I’m only a hobby relay operator, so I’m posting these numbers mainly in case they are useful for comparison. Regards, KhanKrum

4 5

How is this attack causing 900 Mbps download and 100 Mbps upload?
by forest 13 Oct '26

13 Oct '26

-----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-----

11 26

1AEO exit relay DNS health checks now classify upstream recursive resolvers
by Tor at 1AEO 13 Oct '26

13 Oct '26

Hello, Exit DNS health checks now include the recursive resolver each exit used. Results are on https://exitdnshealth.1aeo.com (raw) and https://metrics.1aeo.com (aggregated and specific) Methodology Each exit is probed with unique values with tor.exit.validator.1aeo.com to bypass caching and capture the authoritative query's source IP. Upstream resolvers are classified once a threshold of ~25 queries per relay is met: Local: Query originates from the exit's IP or its origin AS (including hoster-internal resolvers). Public: Google Public DNS, Cloudflare, Quad9, OpenDNS, or Freifunk München. Other: Uncategorized third-party resolvers. Current Network Snapshot (12 Oct 2026) Across ~2,600 exits with sufficient query volume: Local: ~67% Public: ~22% (~510 exits: Google ~10%, Cloudflare ~8%, Quad9 ~2%, Freifunk ~1%, OpenDNS <1%) Other: ~12% Endpoints Per-relay status: [https://metrics.1aeo.com/relay/](https://metrics.1aeo.com/relay/)<FINGERPRINT>/ (DNS Health → Upstream Resolver) Aggregated dashboard: [https://metrics.1aeo.com/network-health.html](https://metrics.1aeo.com/netw… Raw JSON: [https://exitdnshealth.1aeo.com/latest.json](https://exitdnshealth.1aeo.com/… (metadata.resolvers, results[].resolver) Prometheus scrape: [https://metrics.1aeo.com/metrics](https://metrics.1aeo.com/metrics) (aeo1_exit_dns_public_resolver_share_ratio, aeo1_exit_dns_resolver_queries_count) As a reminder, community best practices recommend running a local non-forwarding recursive resolver (e.g., Unbound or BIND on 127.0.0.1) rather than pointing to centralized public DNS providers to prevent upstream query correlation and metadata logging.

2 1

Relay suddenly stopped relaying traffic but is still in the consensus
by forest 12 Oct '26

12 Oct '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Yesterday, one of my relays suddenly (within minutes) went from passing about 5 Mbps to passing nothing. The traffic rate dropped off as rapidly as if it went into hibernation. The consensus still says it is up. Nyx does not show any indication of failures and all directory authorities are able to reach its ORPort. There's no network censorship occurring as far as I can tell (my other relays can reach its ORPort). Nothing is out of place in the logs, but Nyx still reports an average rate of 1 KB/sec. Why is this? The relay is 0EF2A357140FCBDAE2F948CC2228909695B81B35. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCasLlCAAKCRAw+TRLM+X4 xkrfAQClP3aXODcrcvS9KOgj7tPCUeB9holpR1kpSrpF99qAFQD9EjjMBr3lKZgF F3RLEbRjTQDULtmqSqMbkJaA/oW4FQg= =6Xg7 -----END PGP SIGNATURE-----

3 3

Family-ID for bridges
by boldsuck 11 Oct '26

11 Oct '26

Hiho, I'm unsure whether I should apply a "Family key" to my bridges. - tor-spec says: we get bridge families "for free" https://spec.torproject.org/proposals/321-happy-families.html#a-note-on-bri… - hiro says Serge & rdsys is not ready yet: https://forum.torproject.org/t/tor-relays-does-c-tor-support-happy-family-o… I don't mind. I would like to change the bridges from ciissversion:2 'proof:dns-rsa' to ciissversion:3 'proof:dns-familyid-ed25519'. Because I don't know how much longer nusenu will continue to support 'proof:dns-rsa' on OrNetStats. - mikeperry suggests against that we have family sets that includes both the bridges and (at least) exit: https://gitlab.torproject.org/tpo/core/tor/-/work_items/40935#note_3351211 Mmmh, should I publish one family key for bridges and another for relays? I assume _Hidden_ Bridges won't get one. ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

3 3

DDoS solution for Tor nodes - nftables variant implemented
by Toralf Förster 10 Oct '26

10 Oct '26

I eventually managed to have it [1] for nftables too and will continue to maintain both variants. The iptables Readme is moved to [2]. Give it a try. Thx -- Toralf [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/torutils/blob/main/README-iptables.md

3 6