- tor-relays - lists.torproject.org

FamilyID help...again
by wxw＠Safe-mail.net 29 Sep '26

29 Sep '26

Hi, I have run my relays for 15+ years. I am trying to implement FamilyID by following your instructions at https://community.torproject.org/relay/setup/post-install/family-ids/. I generate my secret_family_key. I save the FamilyID. I copy secret_family_key to my key directory "I think". All servers are Debian 12-13. All tor versions are Tor 0.4.9.12 (recommended). Instructions call for sub-directory of DataDir? I don't know where that is. All my Tor key appear at /var/lib/tor/keys so that is where my secret_family_key is. I add FamilyID #$%^&*()POIUYHJKLetc as in the format line generated to the bottom of my torrc file. I restart relay. (Systemctl etc) I also reboot the whole server too. Nyx won't start. Remove the FamilyID from torrc and everything is fine and Nyx starts. I have regenerated secret key several times, tried adding to 3 different relays with exactly the same results. All my servers have Effective & Alleged Family Members listings obviously. I have 2 questions what am I doing &*(*(**( wrong & do I have to add the FamilyID to all my relays first to get things working? Thanks Phil

3 2

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

29 Sep '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-----

9 21

Amplification Attack?
by ProSecureRelays 22 Sep '26

22 Sep '26

Hi there, regarding the current attack on the network, I can only add that my suspicion is some kind of amplification attack. As other operators also noticed, I see normal inbound traffic flows but excessive outbound flows (even exceeding my line rate by far..), when my Guard is under attack. I noticed in my Logs, just before the last OOM Crash of the Tor Process occurred, this warning is spammed excessively: [warn] Service descriptor has an invalid signature length.Expected 86 but got 88 However, the OS did not report any resource exhaustion in that particular moment, and Tor could use ~12GBs out of the 16GB System Memory. That's different from the last crash I had some time ago, where the whole OS triggered resource exhaustion alarms. With the Information others provided (disable Directory Services solves the issue) I would suspect some issue with the services directory, where a malformed request triggers multiple outgoing requests from the relay itself, overloading it in the process. I'm not deep in the functionality of the directory services, but maybe this can be triggered when registering a malformed service or querying the directory with malformed packets. This month my biggest uptime enemy was Microsoft itself, ignoring the GPO's for Update related-restarts and just rebooted twice because of the emergency update that was released. So no more crashes so far. I've attached the Tor Logs when the Relay died, but I don't think it'll help much. Best regards and let's hope for the best! Joker

2 1

overhauled nftables implementation of DDoS prevention solution
by Toralf Förster 20 Sep '26

20 Sep '26

The template [1] works now both for a straight forward Tor instance as well as for machine hosting many Tor instances in parallel. Therere no dedicated firewwall rules per Tor instance. The memory foot print is reduced. And, to avoid wrong abuse complaints from an over-reacting IDS I re-implemented the existing solution [2] in nftables [3]. Will continue to maintain iptables and nftables implementations of the ruleset [4]. As of today metrics show few dozen blocked addresses at a couple of tiny VPS relays, but a high 3-digit number at a bare metal server hosting 5 relays, drop rate is about 40 p/s here. Much higher values were observed in the past. Feedback appreciated. -- Toralf [1] https://github.com/toralf/torutils/blob/main/nftables-ingress.conf [2] https://github.com/toralf/torutils/blob/main/ipv4-rules-egress.sh [3] https://github.com/toralf/torutils/blob/main/nftables-egress.conf [4] https://github.com/toralf/torutils#the-rule-set

1 0

Re: Programmatically determine if a relay is hibernating
by forest 17 Sep '26

17 Sep '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Roger Dingledine wrote: > I just tested by configuring a controlsocket and it seems to survive > hibernation too. If yours doesn't, please file a bug -- but make sure > that it isn't a Stem bug first. This is Tor on Debian, installed using the Tor Project repos, so surely it's not just a bug. It appears Tor isn't even creating /run/tor/control if it starts up and hibernates, although /run/tor/control.authcookie is created. There is nothing at all unusual in my torrc, and the control socket is created using the tor-service-defaults-torrc that is shipped with the Debian package from the Tor Project repo. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqvxwwAKCRAw+TRLM+X4 xtwZAQDojoUBYui8M+3Ll+ilkjphT0mKfoZODCNeBdLN4UgxPgEAtC1cT3GmDBOQ Q8gi0dxQ+Pr038s+vDbmMQCaYm62xAE= =zpjV -----END PGP SIGNATURE-----

1 1

Should I switch my guards to exits?
by boldsuck 16 Sep '26

16 Sep '26

Background: At the time, our AS was generating ~25% of the exit traffic. I then configured one server with 40 exit relays and another with 40 guard relays. We are now only generating ~16%. https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction It’s actually a real shame that the abuse-resistant IPs¹ don't handle exit traffic. In addition, my exit policy is very open. reject *:25 accept *:* ¹f#ck y all > /dev/nulll -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

2 2

Family-ID for bridges
by boldsuck 16 Sep '26

16 Sep '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 2

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

13 Sep '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 5

Complete list of Tor Metrics keys
by forest 12 Sep '26

12 Sep '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. In order to analyze the ongoing DDoS attack, I'm collecting metrics data from my relays. It's a lot of data so I'm compressing it with zstd. I need a "dictionary" containing a typical metrics output in order to get a better compression ratio. The best I have comes from: curl -s 127.0.0.1:9035/metrics | sed 's/ [0-9]*$//' > dict This creates a decent dictionary with sensitive information (the actual sample values themselves) removed. But from what I understand, Tor only outputs metrics that are relevant, so a relay that doesn't also host an onion service will never have a line starting in "tor_hs_", for example. I'm looking for a sample containing all possible metrics strings, as if Tor did not remove entries that are unrelated to its current state. It doesn't seem like the source code contains anything like that in one easily-accessible location. Does anyone know where I can get this? Regarding the privacy issue of storing metrics data, the relay will be automatically encrypting it with a public key so the relay itself never retains more than a few minutes worth of sensitive data in memory. The metrics will only be used to try to learn more about the ongoing DDoS. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaqTkCQAKCRAw+TRLM+X4 xokFAP4snthWGiMg8KXz318kibVVyBZhUIBlOUhVAaC4SuG2NwD/ZQThLAMQFUxP mAm6PbE68Hk91vvxQq9cr6ySYwjlCwc= =ck/7 -----END PGP SIGNATURE-----

1 0

PSA: 0.4.8.x is EOL now, please upgrade!
by Georg Koppen 02 Sep '26

02 Sep '26

Hello! As a reminder for those of you still running any 0.4.8.x Tor version (be it as a relay or a bridge): please upgrade! The 0.4.8.x series is end-of-life since 2 days ago and you should see a respective warning in your Tor log since yesterday. There's currently still 1598 relays on 0.4.8.x, which means roughly 19% of the advertised bandwidth of the network (and 990 bridges). Supported releases in general can be found on the network team wiki.[1] As for the timeline, we plan to reach out to operators still not having upgraded by start of August, and 0.4.8.x is on track to get blocked from the network early September.[2] To follow along the EOL process for 0.4.8.x you can track our work in Gitlab as well.[3] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… [2] We have a ticket for blocking clients by then: https://gitlab.torproject.org/tpo/network-health/team/-/work_items/460 [3] https://gitlab.torproject.org/tpo/network-health/team/-/work_items/453

1 1