tor-relays December 2022

tor-relays@lists.torproject.org

20 participants
18 discussions

recommended way to run 0.4.7 on armhf?
by ilf 25 Nov '23

25 Nov '23

What's the recommended way to run 0.4.7 on armhf? > The package repository [deb.torproject.org] does not offer 32-bit ARM > architecture (armhf) images (yet). https://support.torproject.org/apt/tor-deb-repo/ Debian has 0.4.7 in bullseye-backports. But Raspbian doesn't have bullseye-backports: http://raspbian.raspberrypi.org/raspbian/dists/ -- ilf If you upload your address book to "the cloud", I don't want to be in it.

3 6

inet_csk_bind_conflict
by Christopher Sheats 21 Mar '23

21 Mar '23

Hello tor-relays, We are using Ubuntu server currently for our exit relays. Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps and the only observable data point that we have is a significant increase in inet_csk_bind_conflict, as seen via 'perf top', where it will hit 85% [kernel] utilization. A while back we thought we solved with with two /etc/sysctl.conf settings: net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 However we are still experiencing this problem. Both of our (currently, two) relay servers suffer from the same problem, at the same time. They are AMD Epyc 7402P bare-metal servers each with 96GB RAM, each has 20 exit relays on them. This issue persists after upgrading to 0.4.7.11. Screenshots of perf top are shared here: https://digitalcourage.social/@EmeraldOnion/109440197076214023 Does anyone have experience troubleshooting and/or fixing this problem? Cheers, -- Christopher Sheats (yawnbox) Executive Director Emerald Onion Signal: +1 206.739.3390 Website: https://emeraldonion.org/ Mastodon: https://digitalcourage.social/@EmeraldOnion/

6 20

security update for obfs4proxy
by meskio 10 Jan '23

10 Jan '23

Hello, The latest version of obfs4proxy (0.0.14) comes with an important security fix. If you are running a obfs4 Tor bridge please upgrade as soon as possible. If you use debian you can find the Debian package in stable-backports: https://packages.debian.org/stable-backports/obfs4proxy If you use docker you'll find the latest version in docker hub: https://hub.docker.com/r/thetorproject/obfs4-bridge/ Or you can find the source code in the upstream repository: https://gitlab.com/yawning/obfs4 If you need help upgrading your relay, please use this mailing list or the Tor Forum: https://forum.torproject.net/c/support/relay-operator/17 We appreciate a lot your effort and time! Thank you -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

4 12

Short heads up (was: Re: Another attempt against Tor DDoS)
by Frank Steinborn 09 Jan '23

09 Jan '23

Hi friends, I made some smaller tweaks over the last few hours which should especially help relays on nearly OOM or thrashing situations (making use of Zswap + MGLRU if available). The rules themselves are just the same, so no changes there. Merry christmas, Frank ------- Original Message ------- On Sunday, December 4th, 2022 at 11:25 PM, Frank Steinborn <steinex(a)nognu.de> wrote: > > > Hi, > > I want to show you my anti DDoS solution for my relays (aswell ;-). It works without ipset, but with a mix of the recent and hashlimit iptables modules. > > What is does: > * If one IP address tries to make 7 SYN connection attempts per second, they are locked out for 300 seconds. If they try another connection in that timeframe, the timer is reset and they are locked out for another 300 seconds. > * Threre are no more SYNs allowed if 4 connections are already in use to the ORPort. > > It works very well for me. Other solutons are far more aggressive but I feel my solution works perfectly against the attacks, even if they are not that aggresive. > > On top of that, I feel its more easy to implement into ones existing firewall solution. > > You can find the repo here: https://github.com/steinex/tor-ddos > > Feel free to give it a shot and feedback would be much appreciated! > > Greetings, > steinex

3 2

cannot keep my bridge up
by Anonforpeace 02 Jan '23

02 Jan '23

Hello: I hope you can help me. I'm having trouble keeping my bridge up. Ports are forwarded. Running latest version of Tor. I had it running for at least roughly 7 to 10 days and then it went down and keeping it up is trouble. I even setup dynamic dns on my router using no-ip.com to see if that would help and still no. I've pasted logs from this morning here. Any help is appreciated. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF tor[17727]: Dec 20 08:55:16.929 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:34445 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: We compiled with OpenSSL 30000020: OpenSSL 3.0.2 15 Mar 2022 and we are running with OpenSSL 30000020: 3.0.2. These two versions should be binary compatible. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Tor 0.4.7.12 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.35 as libc. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Read configuration file "/etc/tor/torrc". Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Based on detected system memory, MaxMemInQueues is set to 2849 MB. You can override this by setting MaxMemInQueues by hand. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Socks listener on 127.0.0.1:9050 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Socks listener connection (ready) on 127.0.0.1:9050 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening OR listener on 0.0.0.0:443 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened OR listener connection (ready) on 0.0.0.0:443 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Extended OR listener on 127.0.0.1:0 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Extended OR listener listening on port 34445. Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Extended OR listener connection (ready) on 127.0.0.1:34445 Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF kernel: [137278.310446] audit: type=1400 audit(1671544516.974:36): apparmor="DENIED" operation="open" profile="system_tor" name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=17728 comm="obfs4proxy" requested_mask="r" denied_mask="r" fsuid=128 ouid=0 Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Parsing GEOIP IPv4 file /usr/share/tor/geoip. Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Dec 20 08:55:17 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor server's identity key fingerprint is 'h4ck3rspace 93695FBD832C2A29A2DE719CC82B29F06C0B4E09' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor bridge's hashed identity key fingerprint is 'h4ck3rspace 709E7C37DFE418F6A28B3F0352787606B51A66C6' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your Tor server's identity key ed25519 fingerprint is 'h4ck3rspace WpmTmQmwNU2PXhaGrwguLXwxiPL3g/4hHuXZRZxZli0' Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: You can check the status of your bridge relay at https://bridges.torproject.org/status?id=709E7C37DFE418F6A28B3F0352787606B5… Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 0% (starting): Starting Dec 20 08:55:18 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Starting with guard context "default" Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Signaled readiness to systemd Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF systemd[1]: Started Anonymizing overlay network for TCP. Dec 20 08:55:26 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Registered server transport 'obfs4' at '[::]:52812' Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 5% (conn): Connecting to a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Socks listener on /run/tor/socks Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Socks listener connection (ready) on /run/tor/socks Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opening Control listener on /run/tor/control Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Opened Control listener connection (ready) on /run/tor/control Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address. Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 10% (conn_done): Connected to a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 14% (handshake): Handshaking with a relay Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 15% (handshake_done): Handshake with a relay done Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Dec 20 08:55:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: External address seen and suggested by a directory authority: 100.38.62.232 Dec 20 08:55:28 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Bootstrapped 100% (done): Done Dec 20 08:56:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Now checking whether IPv4 ORPort 100.38.62.232:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF CRON[17784]: (root) CMD (timeshift --check --scripted) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF crontab[17820]: (root) LIST (root) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF crontab[17821]: (root) LIST (root) Dec 20 09:00:01 mxh-HP-Compaq-Pro-6300-SFF systemd[1]: run-timeshift-17784-backup.mount: Deactivated successfully. Dec 20 09:15:27 mxh-HP-Compaq-Pro-6300-SFF Tor[17727]: Your server has not managed to confirm reachability for its ORPort(s) at 100.38.62.232:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Dec 20 09:17:01 mxh-HP-Compaq-Pro-6300-SFF CRON[18262]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Sent with [Proton Mail](https://proton.me/) secure email.

4 5

Tor process sporadically gets hung on cloud server
by Keifer Bly 19 Dec '22

19 Dec '22

Hi, So I have been being careful to keep tor as well as Debian up to date, however, both my middle relay "udeserveprivacy" and my bridge "gbridge", running on two different cloud services (OVH and Google Cloud respectively), the tor process gets hung and the relay become unreachable. Upon checking the tor log file I cannot find anything suspicious, so this is a possible bug in tor I am reporting. I am wondering why this would happen and not be recorded in the tor log file? Thanks all. -Keifer

1 0

Setting a relay as an HSDirectory?
by code9n＠pm.me 19 Dec '22

19 Dec '22

Hi all, Thanks for the last answers, it's all running nicely now. Now I want to set the relay to act as a Hidden Services Directory as well and reading the torrc file I'm not sure how to do it. Do I just uncomment the lines 10 and 11 of the extract below? Or just line 10? Or lines 10, 11, 13,14 and 15? Or just some combination of them? 1 ############### This section is just for location-hidden services ### 2 3 ## Once you have configured a hidden service, you can look at the 4 ## contents of the file ".../hidden_service/hostname" for the address 5 ## to tell people. 6 ## 7 ## HiddenServicePort x y:z says to redirect requests on port x to the 8 ## address y:z. 9 10 #HiddenServiceDir /var/lib/tor/hidden_service/ 11 #HiddenServicePort 80 127.0.0.1:80 12 13 #HiddenServiceDir /var/lib/tor/other_hidden_service/ 14 #HiddenServicePort 80 127.0.0.1:8015 #HiddenServicePort 22 127.0.0.1:22 I have uncommented line 10 as, looking at other relays in relay search, relays that have the HSDir flag (mostly) do not seem to have any DirPorts open but so far my relay does not have the HSDir flag itself. Although the torrc file hasn't been reset for very long, yet. Thanks for any advice, Pete

2 1

How to reduce tor CPU load on a single bridge?
by David Fifield 19 Dec '22

19 Dec '22

The main Snowflake bridge (https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6…) is starting to become overloaded, because of a recent substantial increase in users. I think the host has sufficient CPU and memory headroom, and pluggable transport process (that receies WebSocket connections and forwards them to tor) is scaling across multiple cores. But the tor process is constantly using 100% of one CPU core, and I suspect that the tor process has become a bottleneck. Here are issues about a recent CPU upgrade on the bridge, and observations about the proportion of CPU used by different processes: https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… I have the impression that tor cannot use more than one CPU core—is that correct? If so, what can be done to permit a bridge to scale beyond 1×100% CPU? We can fairly easily scale the Snowflake-specific components around the tor process, but ultimately, a tor client process expects to connect to a bridge having a certain fingerprint, and that is the part I don't know how to easily scale. * Surely it's not possible to run multiple instances of tor with the same fingerprint? Or is it? Does the answer change if all instances are on the same IP address? If the OR ports are never used? * OnionBalance does not help with this, correct? * Are there configuration options we could set to increase parallelism? * Is migrating to a host with better single-core performance the only immediate option for scaling the tor process? Separate from the topic of scaling a single bridge, here is a past issue with thoughts on scaling beyond one bridge. it looks as though there are not ways to do it that do not require changes to the way tor handles its Bridge lines. https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… * Using multiple snowflake Bridge lines does not work well, despite that we could arrange to have the Snowflake proxy connect the user to the expected bridge, because tor will try to connect to all of them, not choose one at random. * Removing the fingerprint from the snowflake Bridge line in Tor Browser would permit the Snowflake proxies to round-robin clients over several bridges, but then the first hop would be unauthenticated (at the Tor layer). It would be nice if it were possible to specify a small set of permitted bridge fingerprints.

7 57

Status of Bug #7349 - Obfsbridges should be able to "disable" their ORPort?
by Gary C. New 17 Dec '22

17 Dec '22

All: What is the status of Bug #7349 - Obfsbridges should be able to "disable" their ORPort? https://bugs.torproject.org/tpo/core/tor/7349 I recently setup a loadbalanced OBFS4 bridge and would prefer not to expose the ORPort to the World. I've noticed that some of the tasks to make this possible have been implemented, but it isn't clear whether everything needed is in place as I receive a bridge/relay down status on metrics.torproject.org when the ORPort isn't exposed to the World. Thank you for your assistance. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

2 2

New relay questions
by code9n＠pm.me 15 Dec '22

15 Dec '22

Hi Relay Operators, I am trying to run a non exit relay for the first time and have some questions: FYI, I have 2 virtual CPU s and 1.256 GB RAM with ‘unlimited’ bandwidth on a rented VPS running Debian 11. The logs report success and the Relay Search shows my relay (Nickname: code9nRelay) running but the advertised bandwidth is 0 B/s. It’s been running for 13 hours or so and I see a new relay that has been running for 1 hour has an advertised bandwidth of 12MiB/s. I did set the bandwidth to 100KB/s, then 200KB/s but now it’s just set to run the defaults. Ie Nothing is set. I had my email address as my first contact then my GPG fingerprint as a second contact but the fingerprint is displayed not the email. Now I have it all on one line with the email address first. Which brings me to my main question; when I run systemctl restart tor@default shouldn’t the new settings in the torrc file be used from that point on? Because they don’t seem to be. I have run it after making the changes above and the old settings are still shown on the Relay Search page. Ie 0KB/s and my GPG fingerprint showing as my email address. If this restart doesn’t reset the torrc then what does? Or is it just a matter of waiting for the new info to be taken up? Any one have any thoughts or advice, please? Pete Here are the recent logs: Dec 14 20:05:31.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 10 circuits open. I've sent 188.82 MB and received 168.28 MB. I've received 14629 connections on IPv4 and 1847 on IPv6. I've made 171 connections with IPv4 and 8 with IPv6. Dec 14 20:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 3951317 (server descriptor fetch); 944 (server descriptor upload); 358850 (consensus network-status fetch); 49621 (microdescriptor fetch) Dec 14 20:05:31.000 [notice] Average packaged cell fullness: 95.570%. TLS write overhead: 16% Dec 14 20:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37259/37259 NTor. Dec 14 20:05:31.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 0 v4 connections; initiated 60 and received 16368 v5 connections. Dec 14 20:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:05:31.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 3 circuits open. I've sent 375.23 MB and received 326.98 MB. I've received 32711 connections on IPv4 and 3289 on IPv6. I've made 306 connections with IPv4 and 14 with IPv6. Dec 15 02:05:31.000 [notice] While not bootstrapping, fetched this many bytes: 8221506 (server descriptor fetch); 944 (server descriptor upload); 766467 (consensus network-status fetch); 80676 (microdescriptor fetch) Dec 15 02:05:31.000 [notice] Average packaged cell fullness: 94.792%. TLS write overhead: 18% Dec 15 02:05:31.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 37813/37813 NTor. Dec 15 02:05:31.000 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 0 v4 connections; initiated 88 and received 35765 v5 connections. Dec 15 02:05:31.000 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Dec 15 02:31:35.000 [notice] Performing bandwidth self-test...done. ……………………………………...

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays December 2022