tor-relays September 2020

tor-relays@lists.torproject.org

33 participants
22 discussions

Dropped off consensus (0.4.4.5)
by Felix 23 Oct '21

23 Oct '21

Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix

5 8

SSH
by Андрей Гвоздев 29 Dec '20

29 Dec '20

Hello I'm running a TOR relay, every time I SSH to my server I see a message that there were thousands of failed login attempts Do you see this message too?

10 12

Call for Testing - New Feature: Relay IPv6 Address Discovery
by David Goulet 28 Nov '20

28 Nov '20

Greetings everyone! We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment. This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature. The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order): 1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query. If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory). The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now. Thus this is now valid: Address 1.2.3.4 Address [4242::4242] ORPort 9001 Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort. Now, if you happen to have this configuration which I believe might be common at the moment: ORPort 9001 ORPort [4242::4242]:9001 The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this. Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family: ORPort <IPv4>:9001 ORPort <IPv6>:9001 And of course, if you want your relay to _not_ listen on IPv6: ORPort 9001 IPv4Only In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from. Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it. Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated. Thanks!! David [1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en -- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

8 12

Collaborative Bad-Abuse-Sender Blocklist
by Matt Corallo 19 Oct '20

19 Oct '20

Hi all, I run a few relatively-small exit nodes, and still get a decent flow of the usual Fail2Ban, blocklist.de, and such garbage to abuse PoCs. I tend to proactively find appropriate abuse/noc contacts to provide a response informing them of how they can appropriately block all Tor exits from their SSH ports if they wish, but often get either no or indignant responses about how sending a stream of garbage abuse reports is a useful service to the internet (nevermind that most large providers don't bother handling abuse reports anymore because of exactly this behavior). After a reply or two I usually add senders to a blocklist and bounce them at the mailserver with a notice about spam not being useful. Is there any interest in building up a shared blocklist of senders who feel its their right to send Fail2Ban emails in non-machine-parsable formats and not bother handling replies to their emails they expect others to handle, or does anyone already have such a list? Matt

4 6

Malicious Tor relays - post-analysis after two months
by Corl3ss 07 Oct '20

07 Oct '20

Hello, This summer Nusenu shared his posts about malicious relays [1][2] and it was followed by many answers. A very important is Roger's one [3] explaining that the malicious relays have been kicked out of the network and that any new one should be reported. I was wondering if, with some distance with this summer situation / discussion : * new malicious relays have been reported in any way ? * vigilance / watchfulness is still needed ? if yes : * is there specific cases to share (e.g. nodes that block HTTPS on a site or redirect to HTTP ?) * any concern to have on other protocols that use SSL (imaps, smtps, ssh) ? * is there / will there be things implemented as a conclusion of the "call for support for proposal to limit large scale attacks" ? * has it been possible to prepare / set up precautions to avoid this king of situation or it is a too long shot for such a problem ? These questions come with a lot of respect for the project, its teams and the work done. No critics, it is just made to update the knowloedge on the subject as these questions came back with other friends and relay operators. And perhaps a last one, perhaps specific for Nusenu : how do you define a malicious relay ? Sorry but I did not get that precisely, moreover in big group analysis. All answers will be read with care and gratitude ! --- Corl3ss 2042 5D39 E7C1 E657 025E A28F 937D 8A90 FCB0 E24A [1] https://lists.torproject.org/pipermail/tor-relays/2020-July/018643.html [2] https://lists.torproject.org/pipermail/tor-relays/2020-August/018817.html [3] https://lists.torproject.org/pipermail/tor-relays/2020-August/018845.html

6 7

Reconfiguring a middle relay as a bridge
by torix＠protonmail.com 30 Sep '20

30 Sep '20

Is there a security problem with turning a middle relay, whose ip address is known, into a bridge? TIA, --Torix Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 3

Heartbeat: It seems like we are not in the cached consensus.
by Fran 27 Sep '20

27 Sep '20

Hello, I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus. As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD). Excerpts from the log: Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done. Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB. Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33% Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 5 v4 connections; initiated 48 and received 124 v5 connections. Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections. Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB. Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47% Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor. Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 10 v4 connections; initiated 57 and received 246 v5 connections. Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB. Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51% Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor. Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 18 v4 connections; initiated 64 and received 370 v5 connections. Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA… Accessing the status page on port 80 works. No FW on the machine. Any ideas? Thanks and regards Fran

4 7

Exit not utilizing full bandwidth
by 4punk7＠mailbox.org 26 Sep '20

26 Sep '20

Hi, i am running a tor exit node for over 2 years now and it's just using around 1.7 MiB/s of a 100 MBit/s connection. My other relays (not exits) from the same hoster (same bandwidth) are using around 10 MiB/s (which is the rate I expect). I have tried to limit the bandwithrate, set no limits, adding IPv6 and also excluding relays from overseas (i'm located in Germany). Nothing happened. CPU is around 10%... Any idea how to speed up the exit ? Thanks, apunkt Tor Version is 0.4.2.7, here is my current torrc: /var/log/tor/notices.log RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 ORPort 1234 ORPort [2a0a:51c0::103]:9001 Nickname 4punk7e1 RelayBandwidthRate 100 MBytes # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 100 MBytes # But allow bursts up to 200KB (1600Kb) MyFamily $CEFBCB5FCE5FB37784AD489BCDEC46F1D59C06CB,$ABA31795BAD2AB8097F3AD0FE1A9 20E518D3D3F3 ExitRelay 1 IPv6Exit 1 ExitPolicy reject6 *:22 ExitPolicy reject6 *:587 #ExitPolicy reject6 *:* ExitPolicy accept *:20-21 # FTP #ExitPolicy accept *:22 # SSH ExitPolicy accept *:23 # Telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79 # finger ExitPolicy accept *:80-81 # HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:465 # URD for SSM (more often: an alternative SUBMISSION port, see 587) ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL #ExitPolicy accept *:587 # SUBMISSION (authenticated clients [MUA's like Thunderbird] send mail over STARTTLS SMTP here) ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:853 # DNS over TLS ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-990 # FTP over SSL ExitPolicy accept *:991 # Netnews Administration System ExitPolicy accept *:992 # TELNETS ExitPolicy accept *:993 # IMAP over SSL ExitPolicy accept *:994 # IRCS ExitPolicy accept *:995 # POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8232-8233 # Zcash ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* ExcludeNodes {US},{CA}

1 0

"Your server (xxxx:443) has not managed to confirm that its ORPort is reachable."
by Pham Minh Duc 23 Sep '20

23 Sep '20

I see this in syslog: Your server (xxxx:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. torrc: Nickname Contake ORPort 443 ExitRelay 0 SocksPort 0 ControlSocket 0 ContactInfo contakechuyennghicmt(a)gmail.com What happened and how to fix this?

3 7

Who am I?
by Kencf0618＠riseup.net 22 Sep '20

22 Sep '20

Whatever the torrc, with "Tor" I get Sep 18 08:02:12.538 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:02:12.538 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:02:12.538 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:02:12.542 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:02:12.542 [notice] Scheduler type KIST has been enabled. Sep 18 08:02:12.542 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:02:12.542 [warn] Could not bind to 0.0.0.0:443: Permission denied Sep 18 08:02:12.542 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Sep 18 08:02:12.542 [err] Reading config failed--see warnings above. whereas with "sudo Tor" (yeah, yeah, I know, I know -"bad form") I get ep 18 08:04:12.236 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:04:12.236 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:04:12.237 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:04:12.240 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:04:12.240 [notice] Scheduler type KIST has been enabled. Sep 18 08:04:12.240 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:04:12.241 [warn] /home/kenneth/.tor is not owned by this user (root, 0) but by kenneth (1000). Perhaps you are running Tor as the wrong user? Sep 18 08:04:12.241 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/home/kenneth/.tor" Sep 18 08:04:12.241 [err] Reading config failed--see warnings above. What is happening?

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays September 2020