- tor-relays - lists.torproject.org

Should I switch my guards to exits?
by boldsuck 10 Oct '26

10 Oct '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!

3 3

Re: Ebury 1.8.3 on two Quetzalcoatl relay servers: timeline, lessons, open questions
by Marc-Etienne M.Léveillé 08 Oct '26

08 Oct '26

Hi, Marc-Etienne here, I've been looking at Ebury for quite some time (13 years now, yikes!). I'm the author of the latest (2024) report on Ebury and co-author of the original paper from 2014. First, I'd like to thank you for coming forward about the compromise and detailing what you found. **A lot** of servers have been compromised by Ebury in the past but most victims, for good or bad reasons, decided _not_ to disclose they got comprised. I think if we actually work together, we can better remediate threats like Ebury. I'd be happy to assist in any way. Here are some partial answers to your questions: > Where did the attacker get the operator password before Aug 28? That I couldn't say for sure. My best guess is a login from a host already compromised by Ebury. Another possibility is a compromised hosting provider. We identified a couple of them in the past where their management servers were compromised by Ebury and their customers' VPSes, containers, etc., ended up running Ebury as well. > How did Switzerland2's sshd accept a key that was in no authorized_keys I'm really not sure, but maybe Ebury was already present before and was updated on Sept 30? But then if it was Ebury letting them in, that log line wouldn't even be there :-/ > What did guard, failover and snf do on Switzerland2? I couldn't say. snf may stand for "sniff", so maybe some sort of traffic sniffing on the egress of the exit node? > Where do the stolen credentials go? They are kept in memory in a process spawn by Ebury until they are fetched using Ebury's "Xcat" command. There are daily SSH connections from the attacker infrastructure pulling them. After 14 days without Xcat, it will send them via UDP/53 to some exfil server. The "xpost.php" is exclusively for stuff captured from HTTP POST requests made by libcurl (Apache, PHP, etc). This additional module is not activated on non-HTTP servers. > On Switzerland2, sudo logged the entire base64 installer across 64 "(command continued)" Any chance you could share this publicly or privately? > If you find it, take the relays down and mask the tor units, snapshot the disk, and rebuild from scratch rather than cleaning in place. +1 on this. I will also add: Ebury will spider everywhere. Look at your .ssh/known_hosts file to see where this system connected to before. They certainly did, using every username password and key combination possible. Also please try to capture anything that could help us better understand this group's impact and intent. A few notes and advice for any other relay operators in the same situation: - Ebury version 1.8.3 has been around since at least June 2026. Although _not_ a silver bullet, I've updated the detection script I made to include the latest versions I have: https://github.com/marc-etienne/eset-malware-research/blob/ebury_update/ebu…. It wasn't merged in ESET's version yet (I no longer work there), but I will bump the PR I made for my ex-colleagues. - Defusing the userland rootkit currently works with "I=1 bash" too. They replaced H with I after our 2024 publication. Now that I say this, next Ebury version will likely use J :P - From your description it seems it is magling with network settings. The Ebury operators are known to play with them for capturing and redirecting traffic. Consider dumping netfilter tables (iptables-save, iptables-nft-save, nft list ruleset) as well routing tables and rules (ip link show, ip addr show, ip rule show, ip route show table all, ip tunnel show). - If a process is running but the executable file is missing from disk, procfs will happily extract it from memory for you. Find the PID, and use `cp /proc/$PID/exe suspicious.elf` to dump the original file into suspicious.elf. gcore (just `gcore $PID`), part of gdb, can also be used to dump non-filebacked memory (heap, stack, rw mem). This could be helpful to extract configuration from running processes as well as reveil some details about the context of the execution (example: the SSH_CONNECTION envvar). That's what I can think of off the top of my head for now. Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there. I wouldn't be surprised Ebury operators automated the process of installing "special tools" on Tor relay specifically, maybe to capture more SSH credentials from users connecting to SSH servers via Tor. Feel free to reach out to me for any questions or if you find something interesting that may help better understand what Ebury is up to now :) Cheers! M-E

3 2

Updating on Rasberry PI
by Keifer Bly 08 Oct '26

08 Oct '26

Hi, So I am attempting to run a bridge from a Rasberry Pi 5, encountering errors when updating. Upong trying to update tor, it generates the following: updating from such a respiratory cant'e be done securly, and is disabled by default. This is what I have configured in /etc/apt/sources.list.d/tor.list deb [signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] https://deb.torproject.org/torproject.org debian> I am assuming it needs to be signed for Debain Trixie as that is what the newest rasberry PI OS is, so what is the correct line for Trixie? Where can one find the correct lines for each Linux variant? Thank you. --Keifer

2 1

Security incident affecting some relay operators
by hiro 06 Oct '26

06 Oct '26

Hello Tor relay operators, We encourage relay operators running Linux to audit their tor configuration file (torrc) and monitor for unauthorized kernel module loading, tunnelling interfaces or unexplained memory usage. Background: Over the weekend we received reports that relays of some of our operators were intercepting SSH connections. According to the operators their servers were hacked, the tor config had been edited and the relays were intercepting SSH connections. It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack. The Tor Network Health team are investigating the issue and looking into how these machines were compromised. For now, we have been flagging those affected relays and the directory authorities are rejecting them from the network. What you can do: Audit your relay looking for potential sign of compromise. * On Tor Metrics Relay Search: does your relay show the Exit flag or an exit policy you didn't set? * Check torrc and anything in %include paths for ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname changes. * Look for NAT rules redirecting port 22 (nft list ruleset, iptables -t nat -S). * Look for unknown listening processes or outbound connections (ss -tnp). * Verify the tor binary against your distribution package (debsums tor or rpm -V tor). * Look for new users, authorized_keys entries, cron jobs or systemd units. One of the techniques that were reported involved establishing root cron persistence via a fake uppercase CRON daemon. If you suspect a relay got compromised: take the relay offline, preserve disk and logs before wiping, reinstall rather than clean up, generate a new relay identity (the old keys must be treated as stolen), and rotate every credential that was on the host. Reach out: If you have been affected or if you have more information about this incident, please reach out to bad-relays(a)lists.torproject.org. Please stay vigilant and thanks for running relays. -hiro

4 3

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

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

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

Snowflake setup fail
by John Thompson 29 Aug '26

29 Aug '26

Repeated blacklisting while running a tor relay has persuaded me to try a snowflake proxy instead. I want to run a stand-alone proxy on Almalinux-9.8. Following the instructions on https://community.torproject.org/relay/setup/snowflake/standalone/docker/, I have installed docker, but cannot complete the next step, downloading the docker-compose.yml configuration file: $ wget -O docker-compose.yml https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… --2026-08-21 09:17:57-- https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… Resolving gitlab.torproject.org (gitlab.torproject.org) 2620:7:6002:0:266:37ff:feb8:3489, 204.8.99.149 Connecting to gitlab.torproject.org (gitlab.torproject.org)|2620:7:6002:0:266:37ff:feb8:3489|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2026-08-21 09:17:57 ERROR 403: Forbidden. Is there a fix? -- -John Thompson (johndthompson(a)gmail.com) Appleton WI USA

6 16