- tor-relays - lists.torproject.org

Running a middle relay on home network
by Keifer Bly 11 Nov '24

11 Nov '24

Hi, So wondering for running a middle relay on a raspberry pi esque micro computer, what are the recommed maximum bandwidth for running a middle relay on a hole network (by a stock isp router, etc?)? Thanks. --Keifer

3 2

Tor relays source IPs spoofed to mass-scan port 22?
by Pierre Bourdon 10 Nov '24

10 Nov '24

Hi relay ops, A few hours ago I received a forwarded abuse report from Hetzner for one of my machines running a Tor relay (not exit). Some random ISP was claiming I was sending SSH connections to them, and at first I couldn't find any corroborating evidence in my own network logs and I was ready to dismiss it. But then I noticed that there is in fact something weird: all 4 of my machines running Tor relays are seeing *return* TCP traffic (RSTs or SYN-ACKs) from port 22 from various machines all over the world, at a very low rate. Kind of like someone spoofing source IPs to send SYNs everywhere. I can't figure out at all whether that's actually what's happening and what the intent would be though. Some tcpdumps showing random RSTs coming back to my machines running relays (with no traffic being initiated by said machines beforehand): 04:19:14.705034 IP 198.30.233.69.22 > 172.105.199.155.39998: Flags [R.], seq 0, ack 171173954, win 0, length 0 04:20:15.135733 IP 124.198.33.196.22 > 172.105.199.155.23506: Flags [R.], seq 0, ack 1985822135, win 0, length 0 04:21:30.222739 IP 223.29.149.158.22 > 172.105.199.155.27507: Flags [R.], seq 0, ack 3614869158, win 0, length 0 04:14:25.286063 IP 45.187.212.68.22 > 195.201.9.37.59639: Flags [R.], seq 0, ack 41396686, win 0, length 0 04:14:25.291455 IP 107.152.7.33.22 > 195.201.9.37.39793: Flags [R.], seq 0, ack 1391844539, win 0, length 0 04:14:25.322255 IP 107.91.78.158.22 > 195.201.9.37.48900: Flags [R.], seq 0, ack 1434896088, win 65535, length 0 04:12:39.470366 IP 121.150.242.252.22 > 77.109.152.87.57627: Flags [R.], seq 0, ack 2452733863, win 0, length 0 04:13:05.549920 IP 46.188.201.102.22 > 77.109.152.87.9999: Flags [R.], seq 0, ack 3253922544, win 0, length 0 04:14:33.027326 IP 1.1.195.62.22 > 77.109.152.87.52448: Flags [R.], seq 0, ack 351972505, win 0, length 0 By any chance, any other relay ops seeing the same thing, or am I just going crazy? (it does kind of sound insane...) Any speculation as to the reason for this? Best, -- Pierre Bourdon <delroth(a)gmail.com> Software Engineer @ Zürich, Switzerland https://delroth.net/

26 43

Metrics issue with my relay?
by Carlo P. 10 Nov '24

10 Nov '24

Dear experts, my relay https://metrics.torproject.org/rs.html#details/0FBABB8C7B22CEDDFC849331E8E9… is shown as "down since more than three days" in Metrics. The logs on the server however seem to show normal activity: Nov 10 06:45:35 odin Tor[87753]: Heartbeat: It seems like we are not in the cached consensus. Nov 10 06:45:35 odin Tor[87753]: Heartbeat: Tor's uptime is 12:00 hours, with 59518 circuits open. I've sent 69.19 GB and received 71.95 GB. I've received 24885 connections on IPv4 and 524 on IPv6. I've made 326621 connections with IPv4 and 106790 with IPv6. Nov 10 06:45:35 odin Tor[87753]: While not bootstrapping, fetched this many bytes: 10227682 (server descriptor fetch); 6336 (server descriptor upload); 595320 (consensus network-status fetch); 307663 (microdescriptor fetch) Nov 10 06:45:35 odin Tor[87753]: Average packaged cell fullness: 12.651%. TLS write overhead: 2% Nov 10 06:45:35 odin Tor[87753]: Circuit handshake stats since last time: 0/0 TAP, 36156/36641 NTor. Nov 10 06:45:35 odin Tor[87753]: 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 61280 and received 25404 v5 connections. What caught my attention is the "seems like we are not in the cached consensus" log statement and also the Platform "Tor 0.4.8.13 on FreeBSD (version is 0.4.8.12 in consensus)" on Metrics While being shown as "down" in Metrics, the stats continue to be updated and config changes like 'MaxAdvertisedBandwidth' are properly reflected in Metrics Is there some issue with Metrics in conjunction with FreeBSD ? On the OS, the only changes were automated OS updates. Thanks for your feedback Regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service vps-3e661acc.vps.ovh.net
by Keifer Bly 09 Nov '24

09 Nov '24

Just got this note, I run a middle relay on ovh. Why would this suddenly happen? Thanks. Relay is usdeserveprivacy --Keifer ---------- Forwarded message --------- From: <ticket+KMLTFQPGVQ.ca83(a)abuse.ovh.net> Date: Sat, Nov 2, 2024, 9:07 PM Subject: [Abuse #KMLTFQPGVQ] Abusive use of your service vps-3e661acc.vps.ovh.net To: <keifer.bly(a)gmail.com> Hello, An abusive behaviour (Intrusion) originating from your VPS vps-3e661acc[.]vps[.]ovh[.]net has been reported to or noticed by our Abuse Team. Technical details showing the aforementioned problem follow : -- start of the technical details -- <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head> <body><pre> Greetings Fellow Sys Ad/s I hope this message finds you well. I'm reaching out to you today regarding a matter of potential concern involving one or more IP addresses associated with your system Our network security logs have recently detected unusual activity originating from these IP addresses. While we understand that such incidents can sometimes occur innocently, it's crucial to investigate and address them promptly to ensure the security of all networks involved To assist you in understanding the situation, we have provided the relevant log data below, with timestamps adjusted to our GMT &#43;8 timezone: DateTime Action AttackClass SourceIP Srcport Protocol DestinationIP DestPort 0 01-Nov-2024 05:07:55 DENIED 51[.]68[.]197[.]220 44959 TCP 202[.]91[.]161[.]97 22 1 01-Nov-2024 05:24:37 DENIED 51[.]68[.]197[.]220 58734 TCP 202[.]91[.]161[.]98 22 2 01-Nov-2024 08:48:23 BLOCKED 51[.]68[.]197[.]220 8551 TCP 202[.]91[.]161[.]132 22 3 01-Nov-2024 08:53:27 BLOCKED 51[.]68[.]197[.]220 2419 TCP 202[.]91[.]161[.]169 22 4 01-Nov-2024 08:58:05 BLOCKED 51[.]68[.]197[.]220 5917 TCP 192[.]168[.]200[.]216 22 5 01-Nov-2024 08:59:24 BLOCKED 51[.]68[.]197[.]220 56858 TCP 202[.]91[.]161[.]132 22 6 01-Nov-2024 09:04:23 BLOCKED 51[.]68[.]197[.]220 32161 TCP 202[.]91[.]161[.]169 22 7 01-Nov-2024 09:17:30 BLOCKED 51[.]68[.]197[.]220 33472 TCP 202[.]91[.]161[.]132 22 8 01-Nov-2024 09:18:02 BLOCKED 51[.]68[.]197[.]220 11282 TCP 202[.]91[.]161[.]132 22 9 01-Nov-2024 09:19:00 BLOCKED 51[.]68[.]197[.]220 3727 TCP 202[.]91[.]161[.]132 22 10 01-Nov-2024 09:20:31 BLOCKED 51[.]68[.]197[.]220 4388 TCP 202[.]91[.]161[.]169 22 11 01-Nov-2024 09:25:57 BLOCKED 51[.]68[.]197[.]220 6898 TCP 202[.]91[.]161[.]165 22 12 01-Nov-2024 09:32:06 BLOCKED 51[.]68[.]197[.]220 18202 TCP 202[.]91[.]161[.]132 22 13 01-Nov-2024 09:39:40 BLOCKED 51[.]68[.]197[.]220 51142 TCP 202[.]91[.]161[.]132 22 14 01-Nov-2024 09:45:32 BLOCKED 51[.]68[.]197[.]220 46914 TCP 192[.]168[.]200[.]216 22 15 01-Nov-2024 10:40:48 BLOCKED 51[.]68[.]197[.]220 60991 TCP 192[.]168[.]200[.]216 22 16 01-Nov-2024 10:42:58 BLOCKED 51[.]68[.]197[.]220 42833 TCP 202[.]91[.]161[.]132 22 17 01-Nov-2024 10:47:13 BLOCKED 51[.]68[.]197[.]220 38382 TCP 202[.]91[.]161[.]132 22 18 01-Nov-2024 10:47:23 BLOCKED 51[.]68[.]197[.]220 30596 TCP 192[.]168[.]200[.]216 22 19 01-Nov-2024 10:47:46 BLOCKED 51[.]68[.]197[.]220 56767 TCP 202[.]91[.]161[.]185 22 20 01-Nov-2024 10:52:10 BLOCKED 51[.]68[.]197[.]220 8983 TCP 202[.]91[.]161[.]132 22 21 01-Nov-2024 10:55:04 BLOCKED 51[.]68[.]197[.]220 55684 TCP 192[.]168[.]200[.]216 22 22 01-Nov-2024 10:57:43 BLOCKED 51[.]68[.]197[.]220 37003 TCP 202[.]91[.]161[.]185 22 23 01-Nov-2024 10:58:43 BLOCKED 51[.]68[.]197[.]220 10524 TCP 192[.]168[.]200[.]216 22 24 01-Nov-2024 11:01:06 BLOCKED 51[.]68[.]197[.]220 6384 TCP 202[.]91[.]161[.]132 22 25 01-Nov-2024 11:03:46 BLOCKED 51[.]68[.]197[.]220 6779 TCP 202[.]91[.]161[.]185 22 26 01-Nov-2024 11:06:05 BLOCKED 51[.]68[.]197[.]220 23062 TCP 192[.]168[.]200[.]216 22 27 01-Nov-2024 11:58:01 BLOCKED 51[.]68[.]197[.]220 33174 TCP 202[.]91[.]161[.]132 22 28 01-Nov-2024 11:58:05 BLOCKED 51[.]68[.]197[.]220 29422 TCP 202[.]91[.]161[.]132 22 29 01-Nov-2024 11:58:26 BLOCKED 51[.]68[.]197[.]220 53504 TCP 202[.]91[.]161[.]185 22 30 01-Nov-2024 12:00:03 BLOCKED 51[.]68[.]197[.]220 5898 TCP 192[.]168[.]200[.]216 22 31 01-Nov-2024 12:00:20 BLOCKED 51[.]68[.]197[.]220 38324 TCP 202[.]91[.]161[.]185 22 32 01-Nov-2024 12:00:30 BLOCKED 51[.]68[.]197[.]220 6362 TCP 202[.]91[.]161[.]132 22 33 01-Nov-2024 12:03:11 BLOCKED 51[.]68[.]197[.]220 38581 TCP 202[.]91[.]161[.]132 22 34 01-Nov-2024 12:05:37 BLOCKED 51[.]68[.]197[.]220 43932 TCP 202[.]91[.]161[.]132 22 35 01-Nov-2024 12:07:27 BLOCKED 51[.]68[.]197[.]220 5141 TCP 202[.]91[.]161[.]185 22 36 01-Nov-2024 12:08:42 BLOCKED 51[.]68[.]197[.]220 56161 TCP 202[.]91[.]161[.]132 22 37 01-Nov-2024 12:12:26 BLOCKED 51[.]68[.]197[.]220 6269 TCP 202[.]91[.]161[.]132 22 38 01-Nov-2024 12:14:33 BLOCKED 51[.]68[.]197[.]220 164 TCP 192[.]168[.]200[.]216 22 39 01-Nov-2024 12:15:48 BLOCKED 51[.]68[.]197[.]220 25787 TCP 202[.]91[.]161[.]185 22 40 01-Nov-2024 12:16:39 BLOCKED 51[.]68[.]197[.]220 9188 TCP 202[.]91[.]161[.]185 22 41 01-Nov-2024 12:16:58 BLOCKED 51[.]68[.]197[.]220 32317 TCP 202[.]91[.]161[.]132 22 42 01-Nov-2024 12:22:28 BLOCKED 51[.]68[.]197[.]220 21955 TCP 202[.]91[.]161[.]185 22 43 01-Nov-2024 12:29:50 BLOCKED 51[.]68[.]197[.]220 33563 TCP 202[.]91[.]161[.]185 22 44 01-Nov-2024 12:32:18 BLOCKED 51[.]68[.]197[.]220 48519 TCP 202[.]91[.]161[.]132 22 45 01-Nov-2024 12:33:24 BLOCKED 51[.]68[.]197[.]220 42914 TCP 202[.]91[.]161[.]132 22 46 01-Nov-2024 12:34:07 BLOCKED 51[.]68[.]197[.]220 11296 TCP 202[.]91[.]161[.]185 22 47 01-Nov-2024 12:36:43 BLOCKED 51[.]68[.]197[.]220 6522 TCP 202[.]91[.]161[.]132 22 48 01-Nov-2024 12:37:55 BLOCKED 51[.]68[.]197[.]220 57962 TCP 202[.]91[.]161[.]185 22 49 01-Nov-2024 12:37:56 BLOCKED 51[.]68[.]197[.]220 53189 TCP 202[.]91[.]161[.]132 22 50 01-Nov-2024 12:39:29 BLOCKED 51[.]68[.]197[.]220 7411 TCP 192[.]168[.]200[.]216 22 51 01-Nov-2024 12:41:51 BLOCKED 51[.]68[.]197[.]220 27413 TCP 192[.]168[.]200[.]216 22 52 01-Nov-2024 12:44:00 BLOCKED 51[.]68[.]197[.]220 355 TCP 202[.]91[.]161[.]181 22 53 01-Nov-2024 12:50:35 BLOCKED 51[.]68[.]197[.]220 28953 TCP 202[.]91[.]161[.]185 22 54 01-Nov-2024 12:50:53 BLOCKED 51[.]68[.]197[.]220 46927 TCP 192[.]168[.]200[.]216 22 55 01-Nov-2024 12:52:00 BLOCKED 51[.]68[.]197[.]220 45122 TCP 202[.]91[.]161[.]185 22 56 01-Nov-2024 12:55:04 BLOCKED 51[.]68[.]197[.]220 4184 TCP 202[.]91[.]161[.]181 22 57 01-Nov-2024 12:55:15 BLOCKED 51[.]68[.]197[.]220 33245 TCP 202[.]91[.]161[.]185 22 58 01-Nov-2024 12:57:38 BLOCKED 51[.]68[.]197[.]220 50897 TCP 192[.]168[.]200[.]216 22 59 01-Nov-2024 12:58:58 BLOCKED 51[.]68[.]197[.]220 35903 TCP 202[.]91[.]161[.]132 22 60 01-Nov-2024 12:59:35 BLOCKED 51[.]68[.]197[.]220 16158 TCP 192[.]168[.]200[.]216 22 61 01-Nov-2024 13:01:40 BLOCKED 51[.]68[.]197[.]220 18404 TCP 202[.]91[.]161[.]181 22 62 01-Nov-2024 13:04:12 BLOCKED 51[.]68[.]197[.]220 32885 TCP 202[.]91[.]161[.]181 22 63 01-Nov-2024 13:05:50 BLOCKED 51[.]68[.]197[.]220 6316 TCP 202[.]91[.]161[.]132 22 We believe that by working together to resolve this matter swiftly, we can help safeguard the integrity of our networks and prevent any further issues. If you require any additional information or support from our end to facilitate your investigation, please don't hesitate to reach out. Your prompt attention to this matter would be greatly appreciated. We value your expertise and cooperation in resolving this situation effectively. Thank you for your time and consideration. For any corrections/updates, kindly email email-removed@provider [.]com</pre></body></html> -- end of the technical details -- Your should investigate and fix this problem, as it constitutes a violation to our terms of service. Please answer to this e-mail indicating which measures you've taken to stop the abusive behaviour. Cordially, The OVHcloud Trust & Safety team.

5 6

Re: Update: Tor relays source IPs spoofed to mass-scan port 22
by Carlo P. 08 Nov '24

08 Nov '24

Hello all, those watchdogcyberdefense "specialists" have meanwhile publicly admitted their mistake (of course, hidden in a political wording to create a different impression): https://watchdogcyberdefense.com/2024/11/is-this-attackers-ip-spoofed/ Quote: "This experience got us thinking about the need for a swift way to identify spoofed IPs involved in attacks that create substantial backscatter traffic" On November 8, 2024 at 4:44 PM, <tor-operator(a)urdn.com.ua> wrote: gus : > I'm writing to share that the origin of the spoofed packets has been > identified and successfully shut down today, thanks to the assistance > from Andrew Morris at GreyNoise and anonymous contributors. Are you sure that it has been effectively shut down? We're still receiving spoofed packets with IP addresses of Tor relays set as source after this message has been posted. We've also received more "reports" from the same newbies after this message was posted. Our traps even see packets with the IP addresses of Tor relays that are in the same subnet. So far we've been able to trace this to a certain peer, we'll be monitoring. _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email

1 0

Re: tor-relays Digest, Vol 166, Issue 7
by Account Etheron 07 Nov '24

07 Nov '24

Furthermore, an identical email was received on a server operated by me, Running I2PD. The email originated from watchdogcyberdefense.com, which is hosted on a server located in the Philippines. Additionally, the company has published an article on this matter, which can be accessed via the following link: https://watchdogcyberdefense.com/2024/11/is-this-attackers-ip-spoofed/. On Thu, Nov 7, 2024 at 4:02 PM <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service > vps-3e661acc.vps.ovh.net (Ren? Ladan) > 2. Re: Raspberry Pi 4 (Michael W?chter) > 3. Re: Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your service > vps-3e661acc.vps.ovh.net (George Hartley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Nov 2024 18:33:25 +0100 > From: Ren? Ladan <rene0(a)freedom.nl> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Fwd: [Abuse #KMLTFQPGVQ] Abusive use of your > service vps-3e661acc.vps.ovh.net > Message-ID: <a0332b84-ada5-435a-8f02-3eaae04b236e(a)freedom.nl> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 11/3/24 05:10, Keifer Bly wrote: > > Just got this note, I run a middle relay on ovh. Why would this suddenly > > happen? Thanks. Relay is usdeserveprivacy > > > Interestingly (for some definition), I got an abuse mail forwarded by my > ISP today with exactly the same destination addresses and from the same > last Friday as in the your report. > > > > > > --Keifer > > > > Regards, > Ren? > > > ---------- Forwarded message --------- > > From: <ticket+KMLTFQPGVQ.ca83(a)abuse.ovh.net > > <mailto:ticket%2BKMLTFQPGVQ.ca83@abuse.ovh.net>> > > Date: Sat, Nov 2, 2024, 9:07?PM > > Subject: [Abuse #KMLTFQPGVQ] Abusive use of your service > > vps-3e661acc.vps.ovh.net <http://vps-3e661acc.vps.ovh.net> > > To: <keifer.bly(a)gmail.com <mailto:keifer.bly@gmail.com>> > > > > > > Hello, > > > > An abusive behaviour (Intrusion) originating from your VPS > > vps-3e661acc[.]vps[.]ovh[.]net has been reported to or noticed by our > > Abuse Team. > > > > Technical details showing the aforementioned problem follow : > > > > -- start of the technical details -- > > > > <html> > > <head> > > <meta http-equiv="Content-Type" content="text/html; > > charset=us-ascii"></head> > > <body><pre> > > Greetings Fellow Sys Ad/s > > > > I hope this message finds you well. I'm reaching out to you today > > regarding a matter of potential concern involving one or more IP > > addresses associated with your system > > Our network security logs have recently detected unusual activity > > originating from these IP addresses. While we understand that such > > incidents can sometimes occur innocently, it's crucial to > > investigate and address them promptly to ensure the security of all > > networks involved > > > > > > To assist you in understanding the situation, we have provided the > > relevant log data below, with timestamps adjusted to our GMT &#43;8 > > timezone: > > > > > > ? ? ? ? ? ? ? ? DateTime? ?Action AttackClass? ? ? ?SourceIP Srcport > > Protocol? ? DestinationIP DestPort > > 0? ?01-Nov-2024 05:07:55? ?DENIED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?44959? ? ? TCP? ? 202[.]91[.]161[.]97? ? ? ?22 > > 1? ?01-Nov-2024 05:24:37? ?DENIED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?58734? ? ? TCP? ? 202[.]91[.]161[.]98? ? ? ?22 > > 2? ?01-Nov-2024 08:48:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 8551? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 3? ?01-Nov-2024 08:53:27? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 2419? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 4? ?01-Nov-2024 08:58:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5917? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 5? ?01-Nov-2024 08:59:24? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56858? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 6? ?01-Nov-2024 09:04:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32161? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 7? ?01-Nov-2024 09:17:30? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33472? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 8? ?01-Nov-2024 09:18:02? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?11282? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 9? ?01-Nov-2024 09:19:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 3727? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 10? 01-Nov-2024 09:20:31? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 4388? ? ? TCP? ?202[.]91[.]161[.]169? ? ? ?22 > > 11? 01-Nov-2024 09:25:57? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6898? ? ? TCP? ?202[.]91[.]161[.]165? ? ? ?22 > > 12? 01-Nov-2024 09:32:06? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?18202? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 13? 01-Nov-2024 09:39:40? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?51142? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 14? 01-Nov-2024 09:45:32? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?46914? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 15? 01-Nov-2024 10:40:48? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?60991? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 16? 01-Nov-2024 10:42:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?42833? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 17? 01-Nov-2024 10:47:13? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38382? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 18? 01-Nov-2024 10:47:23? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?30596? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 19? 01-Nov-2024 10:47:46? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56767? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 20? 01-Nov-2024 10:52:10? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 8983? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 21? 01-Nov-2024 10:55:04? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?55684? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 22? 01-Nov-2024 10:57:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?37003? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 23? 01-Nov-2024 10:58:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?10524? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 24? 01-Nov-2024 11:01:06? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6384? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 25? 01-Nov-2024 11:03:46? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6779? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 26? 01-Nov-2024 11:06:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?23062? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 27? 01-Nov-2024 11:58:01? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33174? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 28? 01-Nov-2024 11:58:05? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?29422? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 29? 01-Nov-2024 11:58:26? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?53504? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 30? 01-Nov-2024 12:00:03? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5898? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 31? 01-Nov-2024 12:00:20? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38324? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 32? 01-Nov-2024 12:00:30? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6362? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 33? 01-Nov-2024 12:03:11? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?38581? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 34? 01-Nov-2024 12:05:37? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?43932? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 35? 01-Nov-2024 12:07:27? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 5141? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 36? 01-Nov-2024 12:08:42? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?56161? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 37? 01-Nov-2024 12:12:26? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6269? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 38? 01-Nov-2024 12:14:33? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?164? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 39? 01-Nov-2024 12:15:48? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?25787? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 40? 01-Nov-2024 12:16:39? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 9188? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 41? 01-Nov-2024 12:16:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32317? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 42? 01-Nov-2024 12:22:28? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?21955? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 43? 01-Nov-2024 12:29:50? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33563? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 44? 01-Nov-2024 12:32:18? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?48519? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 45? 01-Nov-2024 12:33:24? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?42914? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 46? 01-Nov-2024 12:34:07? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?11296? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 47? 01-Nov-2024 12:36:43? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6522? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 48? 01-Nov-2024 12:37:55? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?57962? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 49? 01-Nov-2024 12:37:56? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?53189? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 50? 01-Nov-2024 12:39:29? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 7411? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 51? 01-Nov-2024 12:41:51? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?27413? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 52? 01-Nov-2024 12:44:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?355? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 53? 01-Nov-2024 12:50:35? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?28953? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 54? 01-Nov-2024 12:50:53? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?46927? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 55? 01-Nov-2024 12:52:00? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?45122? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 56? 01-Nov-2024 12:55:04? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 4184? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 57? 01-Nov-2024 12:55:15? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?33245? ? ? TCP? ?202[.]91[.]161[.]185? ? ? ?22 > > 58? 01-Nov-2024 12:57:38? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?50897? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 59? 01-Nov-2024 12:58:58? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?35903? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > 60? 01-Nov-2024 12:59:35? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?16158? ? ? TCP? 192[.]168[.]200[.]216? ? ? ?22 > > 61? 01-Nov-2024 13:01:40? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?18404? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 62? 01-Nov-2024 13:04:12? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > ?32885? ? ? TCP? ?202[.]91[.]161[.]181? ? ? ?22 > > 63? 01-Nov-2024 13:05:50? BLOCKED? ? ? ? ? ? ? 51[.]68[.]197[.]220 > > 6316? ? ? TCP? ?202[.]91[.]161[.]132? ? ? ?22 > > > > We believe that by working together to resolve this matter swiftly, we > > can help safeguard the integrity of our networks and prevent any further > > issues. If you require any additional information or support from our > > end to facilitate your investigation, please don't hesitate to reach > > out. > > Your prompt attention to this matter would be greatly appreciated. We > > value your expertise and cooperation in resolving this situation > > effectively. Thank you for your time and consideration. > > For any corrections/updates, kindly email email- > > removed(a)provider[.]com</pre></body></html> > > > > -- end of the technical details -- > > > > Your should investigate and fix this problem, as it constitutes a > > violation to our terms of service. > > > > Please answer to this e-mail indicating which measures you've taken to > > stop the abusive behaviour. > > > > Cordially, > > > > The OVHcloud Trust & Safety team. > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > ------------------------------ > > Message: 2 > Date: Mon, 4 Nov 2024 14:30:59 +0100 > From: Michael W?chter <mwaechter(a)mac.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Raspberry Pi 4 > Message-ID: <A709A06F-E27D-40CE-8A9F-43D028277066(a)mac.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > I?m running a relay on a Pi 4 now for almost 2 years, almost no issues at > all. Average CPU load 40 %, average bandwidth 5 MB. > Updating to a newer version of tor is a bit tricky. > > Rads > > Michael > > > > Am 04.11.2024 um 12:40 schrieb jl2238--- via tor-relays < > tor-relays(a)lists.torproject.org>: > > > > It works. My relay is running on a Raspberry Pi 4B with 4 GB RAM. > Bandwith for the relay is 2 Mbit/s, CPU Load of the relay is about 20 % > > > > > > Am 02.11.24 um 02:15 schrieb Keifer Bly: > >> Hi, > >> > >> So I am wondering, is a Raspberry Pi 4 a recommended device to run a > tor relay on? In terms of traffic load, etc? Thanks. > >> --Keifer > >> > >> > >> _______________________________________________ > >> tor-relays mailing list > >> tor-relays(a)lists.torproject.org <mailto:tor-relays@lists.torproject.org > > > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Inquiry about a possible DDoS case
by Jose A 07 Nov '24

07 Nov '24

Hello everyone. I have received a communication from my ISP regarding the IP where I have a Middle Relay and a Bridge, informing me that this IP is being used for a DDoS attack. I have checked the servers and everything is correct; there are no strange processes running. I have run various tools and everything seems to be in order. Therefore, has anyone encountered a similar case? Or even better, could someone be using Tor to carry out DDoS attacks? I am a bit puzzled by this situation. Thanks for your time King regards JAC -- Sent with https://mailfence.com Secure and private email

2 2

Re: Tor relays source IPs spoofed to mass-scan port 22?
by Carlo P. 06 Nov '24

06 Nov '24

Meanwhile 3* OVH abuse report (twice the same, once for 2nd IP), Virtarix, ServaRICA - all from the same watchdogcyberdefence folks. I have replied to all above ISPs, no suspensions so far. Just received a suspension note without ANY explanation from AvenaCloud - opened a support ticket with them... On November 5, 2024 at 5:51 PM, mick <mbm(a)rlogin.net> wrote: On Tue, 5 Nov 2024 10:32:40 +0200 "Dimitris T. via tor-relays" allegedly wrote: > another abuse report from hetzner (by the same watchdogcyberdefence) > a few hours ago. no reply from hetzner yet to previous ticket. > > this time, alleged attacked /20 subnet from watchdogcyberdefence was > firewalled since 30/10/2024, just to confirm new false abuse > reports..., and they confirmed (=their report, shows traffic from our > ip on 3/11/2024).... And I have received a new "abuse" report from Hetzner raised by the same bozos at watchdogcyberdefence, but this time purportedly aimed at FTP port 21. I've told Hetzner they are welcome to monitor traffic coming out of my node to reassure themselves that this is nonsense. Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net --------------------------------------------------------------------- _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email

1 0

Raspberry Pi 4
by Keifer Bly 05 Nov '24

05 Nov '24

Hi, So I am wondering, is a Raspberry Pi 4 a recommended device to run a tor relay on? In terms of traffic load, etc? Thanks. --Keifer

6 7

Please check if your relay has fallen out of the consensus
by Roger Dingledine 02 Nov '24

02 Nov '24

Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https://atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, --Roger

5 7

"When you pay peanuts, you get monkeys"
by mick 01 Nov '24

01 Nov '24

Hi there. I found the title of the above blog post highly ironic. I run a Tor relay (middle and guard node). You appear to be sending automated "abuse" reports to other ISPS as a result of what is obviously (well obvious to anyone who studies the network traffic properly) spoofed source address connections to SSH port 22 on random servers around the net. These "abuse" reports cause the ISP hosting the /real/ address of the spoofed server to do one of two things. Either they just pass the report on to the server admin for investigation, or they simply shut down the srevr in question and lock the account of the operator. In either case the perfectly innocent Tor server admin is highly inconvenienced and the bad actor(s) doing the spoofing scans get the Tor relay addresses blacklisted. This is detrimental to the health of the Tor network. Please look carefully at your automated abuse reporting system and add some intelligence to it - preferably by getting a properly skilled network administrator to look at the traffic /before/ firing off a spurious report. (Oh and BTW, SSH scanning at scale is so much part of the background noise on the 'net that I am astounded that you should pay much attention to it at all. I don't.) Best Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------

2 2

Re: [tor-relays] Tor relays source IPs spoofed to mass-scan port 22?
by Carlo P. 31 Oct '24

31 Oct '24

Just received today two abuse tickets... On October 31, 2024 at 9:29 AM, Pierre Bourdon <delroth(a)gmail.com> wrote: On Tue, Oct 29, 2024, 03:33 Pierre Bourdon <delroth(a)gmail.com> wrote: By any chance, any other relay ops seeing the same thing, or am I just going crazy? (it does kind of sound insane...) Any speculation as to the reason for this? My own write-up and explanation (and speculation) is available at https://delroth.net/posts/spoofed-mass-scan-abuse/ as a reference. I've had a few people email me saying they had the same scare moment after getting an abuse report and they ended up finding my article, so I'd like to think it's already helped a bit! I also received an email today from Hetzner's legal team saying that they have read my article (props on them, I didn't send it to them myself!). They are monitoring the situation on their side and emphasized that they do not usually take action on this kind of reports they have recently been forwarding to Tor relay operators. So at least for others hosting relays at Hetzner I don't think it's worth worrying too much. For other hosting providers, your mileage may vary. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sent with https://mailfence.com Secure and private email

1 0

[tor-project] Reminder: mailman 3 upgrade imminent (TPA-RFC-71)
by Antoine Beaupré 29 Oct '24

29 Oct '24

Hi, As mentioned in early October, we're in the process of upgrading our main mail server, which includes upgrading to the shiny new Mailman 3 platform. We have, right now, a prototype mailman 3 server available at: https://lists-01.torproject.org/ It's hidden behind the usual "trivial" authentication (ask us on IRC if you don't remember what it is), but should otherwise work normally. I'm going to start by migrating the TPA mailing list and we'll be testing this for a couple of days, but, next week, I'll start migrating the other mailing lists (including this one!). If people want to jump in front of that train early and be part of the beta testers, then by all means I'm happy to have your mailing list be part of the early adopters. Be warned that Mailman 3 is a significant upgrade from Mailman 2. There are some great things (like unified authentication), and some less great things (like a more complex design and "shinier" web interface that might not be everyone's taste). As a reminder, we're doing this upgrade a little rushed because the main mail server is now unsupported for security upgrades. See the details of the proposal here: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-71-emerge… ... with the milestone tracking actual work issues in: https://gitlab.torproject.org/groups/tpo/tpa/-/milestones/16 (Sorry for cross-posting this, but this seems like it warrants wider distribution. As a rule of thumb, I selected mailing lists with public archives that had posts in October 2024, removing duplicates like anti-censorship-team and -alerts. I also suspect many of those mailing lists will refuse my message because I'm not subscribed, but I will have tried. :)) Phew! a. -- Antoine Beaupré torproject.org system administration _______________________________________________ tor-project mailing list tor-project(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Re: [tor-relays] Please check if your relay has fallen out of the consensus
by denny.obreham＠a-n-o-n-y-m-e.net 29 Oct '24

29 Oct '24

As an update, once I showed the link from OONI to my ISP, they offered to move my server to another location at no charge. So the Tor server was moved from India to the UK. (Actually, I built a new one from scratch.) So I will mention here this ISP - Contabo.com - for their great customer service and understanding of what Tor represents. They have automatically and temporarily blocked my IP address - and informed me that they did - 2 or 3 times in the past because they felt it was under a DDoS attack, and I'm OK with that. At one point, communicating with their support team, one person even wrote this to me: We are glad to support your efforts in maintaining these relays, as they play a crucial role in fighting censorship and promoting internet freedom. Thank you for your ongoing trust and partnership. I initially chose them because they have few exit relays (only 12 as of today, 4 of them being mine, but there are about 100 other non-exit relays). With that kind of service, I'm wondering why they are not more popular for exit relays. Denny On 2024-10-22 15:41, tor-relays(a)queer.cat wrote: > > > On 22/10/24 12:08, denny.obreham(a)a-n-o-n-y-m-e.net wrote: >> I still haven't found a solution to my problem I stated earlier in my email with the subject "Exit relay not in consensus" https:// lists.torproject.org/pipermail/tor-relays/2024-October/021899.html <https://lists.torproject.org/pipermail/tor-relays/2024-October/021899. html> >> >> >> The most helpful answers were from Sebastian <https:// lists.torproject.org/pipermail/tor-relays/2024-October/021909.html> and George <https://lists.torproject.org/pipermail/tor-relays/2024- October/021918.html>. I contacted the ASN but never received a response. My ISP was useless as they jus t repeated "We don't block traffic." > > > Iâve gone through the original thread you shared and found an OONI result that supports the notion that your ASN (141995) is blocking Tor directory authorities. You can view the result here: > > https://explorer.ooni.org/m/20241001034902.297107_US_tor_d6973b06186ed4 3a > >> >> >> As of today, the server is still active and running. You can't find it in the metrics but it is still in the consensus <https://consensus- health.torproject.org/consensus-health.html? #7BDDE0E7607A5F49578768F44CD721793FA2D7AE>. >> >> >> I did not have much time lately and have no clue what I can do from this point forward. >> >> >> Denny >> >> >> On 2024-10-22 04:48, Roger Dingledine wrote: >> >> Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https:// atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, -- Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi- bin/mailman/listinfo/tor-relays >> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

2 1

Next Tor Relay Operator meetup - October 26th, 2024 at 1900 UTC
by gus 27 Oct '24

27 Oct '24

Dear operators, Save the date: the next Tor Relay Operator will happen Saturday, October 26th, 2024 at 19.00 UTC[1]! We're still working on the agenda for this meetup, however feel free to add your topics directly to the gitlab issue below or use the tor-relays mailing list: https://gitlab.torproject.org/tpo/community/relays/-/issues/100. ## Agenda 1. Announcements 2. Network Health updates - New proposal: Framework for running Tor Network Health investigations https://gitlab.torproject.org/tpo/community/policies/-/issues/25 3. OTF relay operator survey summary/presentation 4. Osservatorio Nessuno presentation - https://osservatorionessuno.org/ 5. Questions & Answers ## How to join us Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - When: Saturday, October 26th, 2024 - 19.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room-linkabove. We will open the room 10 minutes before. cheers, Gus [1] If you're confused about UTC and your timezone, @anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime -- The Tor Project Community Team Lead

3 4

DDOS mitigation with nftables
by Top 25 Oct '24

25 Oct '24

Hi all, My tor relays[1] traffic decreased a lot and I think this *might* be connected to some kind of DDOS attack. So I wanted to use this situation to set up some DDOS protection. For that I stumbled upon Enkidus tor DDOS mitigation script. [2] However, this script is made for `iptables`, not `nftables`. I use `firewalld` with `nftables` on my system, since this seems to be the new default. [3] I don't really know that much about firewalls, so this situation overwhelms me a bit. In the README of Enkidus rules it says: > Practically all linux systems come with iptables or more recently with nftables which basically does the same and more. So you won't need to install iptables. Just type iptables -V . If you see a version, you have it. The same with ipset . An ipset -v will do the job. In some rare cases you may not have ipset installed and installing it is as simple as apt-get ipset or yum install ipset or... This seems to imply that the script should work fine with `nftables` as well. This is also what Enkidu seems to state in a relevant gitlab issue: [4] > nftables interprets all the iptables rules just fine so the provided scripts will work regardless of which one you have. But it's not true! The script failed on my server, complaining that the `iptables` command couldn't be found (and no rules had been applied). So how can I apply proper DDOS protection firewall rules whilst using `nftables`? Is there some easy way to modify the script to make it work? Kind regards Top [1]: https://metrics.torproject.org/rs.html#search/toptor [2]: https://github.com/Enkidu-6/tor-ddos [3]: https://wiki.debian.org/nftables [4]: https://gitlab.torproject.org/tpo/community/support/-/issues/40093

6 8

Botnet targeting Tor relays
by anon＠kai.sx 24 Oct '24

24 Oct '24

Hello, I run several Linux root servers, spread over several providers, some of which serve as Tor relays. For a few weeks now I have been observing massive brute force attempts via SSH from hundreds of sources around the world. However, only the Tor relays are affected, the rest of the servers are not. Are other relay operators also observing something like this? Is there currently a botnet targeting Tor relays? Best, Kai.

7 7

Re: [tor-relays] Please check if your relay has fallen out of the consensus
by denny.obreham＠a-n-o-n-y-m-e.net 22 Oct '24

22 Oct '24

I still haven't found a solution to my problem I stated earlier in my email with the subject "Exit relay not in consensus" [1]https://lists.torproject.org/pipermail/tor-relays/2024-October/02189 9.html The most helpful answers were from [2]Sebastian and [3]George. I contacted the ASN but never received a response. My ISP was useless as they just repeated "We don't block traffic." As of today, the server is still active and running. You can't find it in the metrics but it is still in the [4]consensus. I did not have much time lately and have no clue what I can do from this point forward. Denny On 2024-10-22 04:48, Roger Dingledine wrote: Hi folks! We're hunting down a mystery where two of our big university relays are having troubles reaching the Tor directory authorities: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/86 Can you check to see if your relay is in a similar situation? In particular, the situation to look for is "Tor process is still running fine from your perspective, but, relay-search (https://atlas.torproject.org/) says you are no longer running." If your relay is in this situation, the next step is to check your Tor logs, try to rule out other issues like firewall rules on your side, and then (if you're able) to start exploring traceroutes to the directory authority IP addresses vs other addresses. If you need more direct help, we can help you debug or answer other questions on #tor-relays on IRC. Thanks, --Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Tor-Podcast about Tor-Messaging
by lists＠for-privacy.net 19 Oct '24

19 Oct '24

On Saturday, 19 October 2024 20:17 David Adam wrote: People are crying in the Tor forum that you have to register with an (anonymous) email. Expressions are used like: Tor Project is dictatorship. And then redshit links? OPSEC please, use frontents: https://github.com/libreddit/libreddit-instances/blob/master/instances.md Onion or clearnet + > /r/Spot_On_Encryption/comments1g7ejidtormessaging_introducing_reflectors_exitrelay/ For all the other centralized cloudflared nonsense: https://github.com/mendel5/alternative-front-ends -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

Tor Relay Operator Community Health - Final report (June 2024)
by gus 17 Oct '24

17 Oct '24

Hello, I wanted to share the "Tor Relay Operator Community Health - Final Project report" (June 2024) made by Ana and Victoria. You can access the report via these links: - Main report: https://www.sr2.uk/reports/2024-TorRelayOperatorCommunityHealth.pdf - Mirror: https://gitlab.torproject.org/-/project/60/uploads/846d7d1816aee92fd2ee283b… best, Gus -- The Tor Project Community Team Lead

3 2

[proposal] Framework for running Tor Network Health investigations
by gus 16 Oct '24

16 Oct '24

Dear Tor relay operators, Inspired by the Berkeley Protocol on Digital Open Source Investigations, Network Health Team and Community Team has developed a framework for conducting Network Health investigations. This proposal provides clear guidelines for conducting ethically sensitive investigations transparently, responsibly, and in a way that upholds the trust of the Tor user base and wider internet freedom community. You can read and comment on this proposal here: https://gitlab.torproject.org/tpo/community/policies/-/issues/25 Alternatively, you can read the full text below. Gus ``` * Filename: 101-running-network-health-investigations.md * Title: Framework for running Tor Network Health investigations * Author: Gus - gus at torproject.org, GeKo - gk at torproject.org * Created: 2024-10-15 * Status: Draft ``` ## Overview This proposal outlines a framework for conducting open source investigations of Tor Network Health related events and actors that potentially harm Tor users or the Tor network, such as denial-of-service attacks or malicious relay operators. Investigations of other types of network incidents, like censorship events, are out of scope of this proposal, even though they might want to follow the framework outlined here as well. Inspired by the Berkeley Protocol on Digital Open Source Investigations [1] (hereafter: Berkeley Protocol), but adapted to the needs of the Tor Community, this proposal provides clear guidelines for conducting ethically sensitive investigations transparently, responsibly, and in a way that upholds the trust of the Tor user base and wider internet freedom community. ## Motivation It is easy to contribute to the Tor network by setting up and running relays. While this low threshold is good for growing the network it, unfortunately, makes it easy as well for malicious actors trying to harm Tor users or the network. Using publicly accessible data and open-source resources empowers the Network Health team and open-source investigators to actively protect the Tor network against such malicious actors. However, thus far there are no guidelines on how to do such investigations in an ethical, reliable and reproducible manner which might prevent volunteers from looking closer at the Tor network out of fear they might do something wrong or harm users or the Tor Project. This proposal is meant to resolve that issue, encouraging interested volunteers to stay vigilant and help protecting the Tor network and its users. At the same time, it aims at providing transparency into how we at the Tor Project use publicly available data during network health investigations ourselves, as we follow the framework developed below as well. ## Framework The framework outlined in this proposal is following the open source investigation cycle as developed in Chapter 6 of the Berkeley Protocol, concluding with a section about guidelines for reporting the findings safely to the Tor Project, so we can take action if needed. The individual stages of the investigation process will be adapted to the Tor context while following the methodological, professional, and ethical principles collected in Chapter 2 of the Berkeley Protocol. Those principles are in particular important as advancing human rights is at the core of Tor's mission. The framework below does not address any security or legal concerns that could arise from doing open source investigations into network incidents or actors. In particular, if the planned investigation might result in danger or harm (be it physical, legal, or otherwise) to yourself or a third party, we urge you to additionally consult the legal and security sections of the Berkeley Protocol first for advice and proper planning of the investigation before it starts. Finally, keep in mind that investigators must adhere to the Tor Project's [Community Policies](https://community.torproject.org/policies). For instance, investigators must respect relay operators' human rights and privacy rights conventions as described in the [evalution criteria for solution to combat malicious relays](https://community.torproject.org/policies/relays/evaluation-criteri…. ## Table of Contents 1. Searching and Monitoring 2. Preliminary assessment 3. Collection 4. Preservation 5. Verification 6. Analysis 7. Reporting ### 1. Searching and Monitoring 1.1. When searching for information and monitoring sources, investigators need to be aware of biases, both their own and those inherent in information online, which might taint the results. Developing and deploying several working hypotheses, which are guiding the search and monitoring efforts, is helping with biases but is not a panacea. Ultimately, it's crucial to be aware of potential biases involved in investigative work and countering them e.g. by broadening and diversifying search and monitoring efforts. 1.2. Besides useful external tools, like regular search engines or specialized ones (e.g., https://shodan.io/) investigators can deploy a collection of tools developed and maintained by the Tor Project to look into network anomalies and bad relay behavior. These tools can be found on the [Network Health GitLab repository](https://gitlab.torproject.org/tpo/network-health/). It is recommended to avoid rewriting tools that already exist, for example, a Tor exit scanner to spot machine-in-the-middle (MITM) attacks. Instead please contribute to the code that's actively developed. In case you're working on innovative open-source methods to detect malicious actors and publishing them could tip attackers, please contact bad-relays(a)lists.torproject.org so we can think about ways to use those methods while not giving attackers an even larger advantage in the bad relay arms race.[2] 1.3. Running scanners is important to keep the network healthy, but be mindful that this is putting strain on the network and the data you are looking for might already be available by other means. 1.4. As a public network, the Tor network already provides relay information such as relays IP addresses, ISPs, operating systems, fingerprints, Tor versions, and more. Investigators can query or consult this data as long as it does not disrupt relay operations or compromise the privacy of Tor users. Such publicly accessible network information is available via Tor Metrics and Onionoo. To learn more, refer to the Onionoo[3] and Tor Metrics sources[4] documentation. Moreover, there are tools available as well, like OrNetStats[5], that build upon those sources providing further insight into the network and its relays. 1.5. Moreover, as a transparent and open source project we provide public analyses and investigations of a lot of previous and current incidents in our [bug tracker](https://gitlab.torproject.org/tpo). Please consult that issue tracker as well to avoid duplicated work or false positives. For instance, sometimes there are some DNS resolution issues at exit nodes preventing users from reaching a website. We are aware of that as we are continuously scanning for that problem and dealing with affected exit nodes on a regular basis. 1.6. It must be acknowledged that legit investigations into malicious activities and bad relays may extend beyond using open-source data. Other methodologies and strategies for gathering information, like whistleblowing or using a relay's MetricsPort[6], are out of scope of this framework. 1.7. Finally, it is important to highlight that running modified Tor software or deploying offensive hacking techniques against relays or the Tor network which could harm users, relay operators and the Tor network itself won't be considered part of an open-source investigation under this framework. Rather, those actions will be considered a malicious activity. ### 2. Preliminary assessment 2.1. As searching and monitoring efforts lead to more and more results it is important to make a preliminary assessment of them early on to avoid over-collection. Over-collection is not just problematic because it will make the analysis process slower and more difficult: there are more results to analyze, more storage used and needed, etc. The risks of leaking information or infringing on rights to privacy of individuals are rising as well. 2.2. Similarly to the search and monitoring efforts, assessing the results through the lens of hypotheses is important as they help to focus on the evidence and avoid speculation. 2.3. During the assessment of results make sure they are relevant, reliable and safe to collect. If there is no risk of results being removed from the internet then their collection is not needed either. ### 3. Collection 3.1. Data collected close to the event under investigation may produce better results. For example, tracking IP addresses involved in a DDoS attacks might not be useful after a long period of time as the attackers' infrastructure might have been reassigned to a new customer. 3.2. As the investigation progresses and new evidence shows up, older, previously collected data might not be needed anymore. Please consider deleting it for the same reasons as stated in section 2.1. above. 3.3. Apart from collecting relevant content itself, it is important to save associated metadata as well in order for other investigators to more easily reproduce the investigation's findings and double-check used source material: URLs of the content, the time when it was accessed, source of a website in question, and anything else that helps to explain the context of the capture/collection should be stored, too. 3.4. In cases where malicious content, such as injected JavaScript, is identified during the scanning of exit nodes, it is crucial to capture and archive the website’s source code for both analysis and as evidence of a bad exit relay. ### 4. Preservation 4.1. Preserving the collected content is essential in network health investigations because the information can change, disappear, or be altered over time, making it unreliable and unusable for the investigation. To ensure the integrity of the data, network health investigators must follow preservation principles, based on archivist standards, as outlined in the Berkeley Protocol (section 6D). These principles include authenticity, availability, identity (keeping track of the origin and nature of the evidence), persistence, renderability, and understandability. 4.2. The decentralized and dynamic nature of the Tor network makes collecting and preserving public relay information a significant challenge. The network changes as relays join or leave, making historical data collection and preservation essential for investigations. For example, relay information is only available on the Tor Metrics website for one week before it is archived and removed from the relay search portal. To ensure access to historical relay information, investigators need to download relay descriptors from [CollecTor](https://metrics.torproject.org/collector.html). 4.3. Tools like archive.today and the Internet Archive (web.archive.org) are useful for capturing and publicly preserving snapshots of digital content, such as relay information, websites, social media content, and other online information that needs to be collected during an investigation. For a private archive collection, see the [ArchiveBox project](https://github.com/ArchiveBox/ArchiveBox). 4.4. When using open source tools to monitor the network, it is important to preserve the results. This includes maintaining logs with metadata such as timestamps, relay fingerprints, targeted URLs and other information like errors. Trusted services like archive.today or the Internet Archive should be used to preserve the original version of the website. 4.5. Investigators must maintain both evidentiary and working copies of collected digital content. An evidentiary copy is a preserved, unaltered version of the original evidence, used to maintain the authenticity of the original content. Working copies can be created for analysis, allowing changes in format or structure without compromising the integrity of the original data. 4.6. Investigators should regularly back up both evidentiary and working copies to secure storage systems, ensuring that data is not lost or corrupted during the investigation process. Please note that while relay descriptors are important for verification and analysis, they can be re-downloaded from the Tor Metrics website, so backing up this data is not needed. ### 5. Verification 5.1. Verification is a process to ensure the accuracy and validity of information collected during network health investigations. Verification can be done using closed and confidential sources or based exclusively on open sources. Without using a verification method, the information collected may be invalid or unreliable for detecting and removing bad relays. (Verification can be split into three key methods: source analysis, technical and investigative analysis.) 5.2. Investigators must evaluate the credibility and impartiality of the source from which the evidence originates. This includes verifying whether the output from open source tools, social media or websites are reliable. 5.3. Information should be cross-verified by consulting other sources to avoid relying on non validated, manipulated, biased or outdated data. Please be aware that some relay information displayed on the Tor Metrics website are not validated, for example, operator's contact information. 5.4. When verifying collected information, network health investigators should begin by looking for unique or distinguishing features. Such features might include groups of relays joining or leaving the network from a particular Autonomous System (AS), new relay operating in an obscure or popular AS, similarities and other patterns. These identification methods rely on searching and monitoring the Tor network activity. 5.5. While geolocation can be a useful tool in network health investigations and analysis, it is important to remember that the geolocation of Tor relays is often inaccurate. This data must be cross-verified with other IP geolocation databases to ensure reliability. 5.6. Investigators should evaluate the information collected for internal consistency during the verification process. This helps determine whether the information is consistent and coherent, and aligns with itself, ensuring its credibility on its own terms. ### 6. Analysis 6.1. Be mindful that a network health analysis might find false-positives. There are a number of possible reasons for that. Among other things: - the data from Tor Metrics isn't always reliable, and what could initially appear as an action of a malicious actor could actually be the result of a glitch in the Metrics database or other network events, like a denial-of-service attack or a major Tor version upgrade. Please double check if Tor Metrics services (Metrics website, relay-search, Onionoo, etc) status are/were healthy and accurate at the time of the incident. - properly analyzing scanning results can be tricky. During an anomaly investigation, you may discover new and intriguing censorship facts, where exit nodes seem to mess with user traffic resulting in blocked websites. Yet, the underlying problem is that they are just using [the DNS resolvers of their ISP](https://gitlab.torproject.org/tpo/network-health/team/-/issues/92) or the blocking of websites is done even further upstream. - Tor has location-biases that might impact the analysis. For instance, when investigating bandwidth related anomalies in the network or outright attacks it might just look like some relays are involved based on bandwidth scanner data. However, that might in fact be related to the still existing location-dependency of our bandwidth scanning efforts instead. 6.2. When starting the analysis keep in mind that it might be useful to translate, aggregate or reformat collected material so that it's easier to process with tools planned to be deployed. For instance, it is not uncommon to change the format of collected information to make it more easily searchable. 6.3. If any of your collected data is at risk of getting altered, lost or destroyed during an analysis it is advisable to use a working copy instead. That way it is possible to re-do the analysis with the same data later on, for instance with a different set of tools that might produce better results. See items 4.5. and 4.6. 6.4. There are many open source tools and services available to assist with your data analysis. As the Network Health Team needs to verify findings without the need to buy or purchase any product, it is important to prioritize platforms and/or products that do not require the purchase of a license to access the results. 6.5. Shifting the focus from 'who' to 'how' an anomaly or attack is happening may yield more valuable insights. In general, attackers have a _modus operandi_. Making a profile of a potential attacker, including their resources and techniques, can significantly help and support your analysis. 6.6. During the analysis investigators may be able to identify attacks such as Sybil, MITM, (distributed) denial-of-service, impersonation of relay operators, DNS poisoning, and social engineering (for example, Tor relay MyFamily evasion) attacks. A list of harmful behaviors can be found in [Criteria for rejecting bad relays](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Crite… and also on [Network Health blog posts](https://blog.torproject.org/malicious-relays-health-tor-network/). ### 7. Reporting 7.1. As said in 6.6, the canonical definition and criteria for bad relays in the Tor network are established and followed by the [Criteria for rejecting bad relays](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Crite… document. However, if you've observed a behavior that you may consider malicious and can cause harm to Tor users or to the network, but is not covered by the criteria, please file a ticket on [GitLab](https://gitlab.torproject.org/tpo/network-health/team). Make sure the ticket is confidential[7] if there is a risk of tipping off an attacker (see 7.7.). 7.2. If investigators detect relays with one of the described issues or behaviors from the Criteria for rejecting bad relays, please report them with a detailed description to our bad relays mailing list (bad-relays(a)lists.torproject.org) including: - The relay's IP address or fingerprint. The fingerprint is a forty-character hex string such as 203933ED4E55EF8A3C3518427D1A1ED6A4CC285E. - What kind of behavior did you see and when? - Any additional information we'll need to reproduce the issue. 7.3. It is better to report attacks earlier than later, as attackers might turn them on and off to avoid the risk of detection. Waiting too long before getting back to us might make it therefore harder or outright impossible to replicate your findings. 7.4. Without replicable findings, the Network Health Team is unable to reject relays. However, we'd like to hear your results nevertheless, as we might have additional information or did our own investigation already that could help reproducing them. 7.5. When reporting to us, investigators don't need to identify themselves by their legal names. Pseudonyms and anonymous tips are welcome. 7.6. Writing a blog post or a research paper about your findings is very much welcomed. However, please coordinate the disclosure part with us first, so that the risk and potential harm to our users is minimized. 7.7. Don't tip off the attacker. While much of the data on suspicious relay activity is public, putting together all the pieces of an investigation should be done discretely. Revealing publicly an investigation result could inadvertently inform the attacker, helping them to evade future detection. 7.8. Additionally in the case of bridges, investigators must be careful on not publicly revealing the bridges' IP addresses. Revealing publicly the IP addresses of bridges without consulting the Network Health Team might be considered as malicious intent. ## References [1] Berkeley Protocol on Digital Open Source Investigations (2022) - https://www.ohchr.org/en/publications/policy-and-methodological-publication… [2] [tor-talk] Why make bad-relays a closed mailing list? (2014) - https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html [3] Onionoo documentation - https://metrics.torproject.org/onionoo.html [4] Metrics sources documentation - https://metrics.torproject.org/sources.html [5] OrNetStats - https://nusenu.github.io/OrNetStats/ [6] MetricsPort - https://support.torproject.org/glossary/metrics-port/ [7] Confidential issues in GitLab - https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html -- The Tor Project Community Team Lead

1 0

Decommissioning a FallbackDir node (punki)
by Osservatorio Nessuno 09 Oct '24

09 Oct '24

Hi there, sadly after almost 6 years of good and honest service, our exit node punki[1] will be turned off. The provider is powering off the infrastructure where it is hosted, and has offered no viable alternative. We are writing this email in advance, since the node is in the FallbackDir list and embedded in Tor. The cluster will be powered off on 25th November. punki E43244684E0C924EC082B8ECC735FAF2F8CF1C45 Cheers Giulio [1] - https://metrics.torproject.org/rs.html#details/E43244684E0C924EC082B8ECC735…

3 6

Re: [tor-relays] Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 05 Oct '24

05 Oct '24

I tried changing the exit and OR ports, I tried setting CircuitBuildTimeout to 300, and my ISP keep assuring me they don't block any port, ever. Some DirAuth still cannot connect with me. I have about 20 exit relays spread across 11 ISPs, including 4 with this ISP (each in a different country). They are all built with the same setup. This particular Tor instance has been working fine for months now. I don't understand what more I can do. Everything is OK on my side, except for an "It seems like we are not in the cached consensus." line appearing in the log once in a while. It's the DirAuth that somehow cannot reach me, apparently blocked by some proxy server in the middle. What more can I do? Do I just abandon this server and IP address because it is somehow blacklisted by I don't know who? Denny On 2024-10-03 13:06, boldsuck via tor-relays wrote: On Wednesday, 2 October 2024 21:24 Sebastian Hahn wrote: On 2. Oct 2024, at 09:05, George Hartley via tor-relays <tor-relays(a)lists.torproject.org> wrote: It could be that your provider has throttled you temporarily. I don't think so, I get that message on a dedicated 10 GbE link with little to no use except for the exit relay on it. Also, if his relay publishes it's descriptor, then why Metrics won't reflect that? It should show it as online, as you don't need IPv6 to be reachable to get the online flag. it looks like your upstream is maliciously messing with your traffic. I am noticing a distinct difference between two traces, one directly from my diraut's IPv4, another from a different host on the same network: A few years ago, Roger emailed me that he could not reach a service @ mit.edu (ASN3) via my exit. I had 2 exits at the same provider with same torrc, network config, IPtables, etc. One had "mystery null routes between Tor relays." https://gitlab.torproject.org/tpo/core/tor/-/issues/40357 I then switched to a different exit port and the problem was solved. -- â°_â¯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom! _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 03 Oct '24

03 Oct '24

Before my last restart 6 hours ago you get a series of messages like these: ``` Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 81 v3 connections; initiated 0 and received 341 v4 connections; initiated 38535 and received 87986 v5 connections. 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. Heartbeat: It seems like we are not in the cached consensus. Heartbeat: Tor's uptime is 2 days 18:00 hours, with 185 circuits open. I've sent 41.52 GB and received 55.06 GB. I've received 105529 connections on IPv4 and 0 on IPv6. I've made 46384 connections with IPv4 and 0 with IPv6. While not bootstrapping, fetched this many bytes: 53988798 (server descriptor fetch); 11748 (server descriptor upload); 3201890 (consensus network-status fetch); 548826 (microdescriptor fetch) Circuit handshake stats since last time: 0/0 TAP, 2/2 NTor. ``` After my last restart I have: ``` Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Read configuration file "/etc/tor/torrc". Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand. Opening Control listener on 127.0.0.1:9051 Opened Control listener connection (ready) on 127.0.0.1:9051 Opening OR listener on 156.67.111.146:443 Opened OR listener connection (ready) on 156.67.111.146:443 [...] Bootstrapped 5% (conn): Connecting to a relay Opening Control listener on /run/tor/control Opened Control listener connection (ready) on /run/tor/control Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor. Bootstrapped 10% (conn_done): Connected to a relay Bootstrapped 14% (handshake): Handshaking with a relay Bootstrapped 15% (handshake_done): Handshake with a relay done Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Bootstrapped 95% (circuit_create): Establishing a Tor circuit Bootstrapped 100% (done): Done Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes. Performing bandwidth self-test...done. ``` I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth. Denny On 2024-10-01 08:06, George Hartley via tor-relays wrote: Hi, looks like the DirAuth's think that your relay is unreachable, and so your descriptor isn't published, so your flags are not updated, this would explain the lack of change in flags. Port 443 on 156.67.111.146 is open for me, can't test IPv6 as I have disabled it through my modem and kernel command line. Can you attach your tor log file? You can also adjust the log verbosity of certain "domains" within Tor like so: [1]https://2019.www.torproject.org/docs/tor-manual.html.en#Log Please let us know what you find. Thanks, George On Tuesday, October 1st, 2024 at 1:40 PM, denny.obreham(a)a-n-o-n-y-m-e.net <denny.obreham(a)a-n-o-n-y-m-e.net> wrote: My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE 0E7607A5F49578768F44CD721793FA2D7AE After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then. What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. h ttps://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768 F44CD721793FA2D7AE Any help would be appreciated. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 4

turning off BridgeDB and the future of moat bridges
by meskio 03 Oct '24

03 Oct '24

Hello, tl;rd: moat bridges are not distributed anymore. Don't shut them down as they are still used but don't create new bridges with "BridgeDistribution moat". BridgeDB has being our bridge distribution system since 2007. For years we have being developed a replacement of BridgeDB[0] called rdsys[1]. And finally yesterday we replaced the last distributors missing in rdsys (email, https and moat) and turned off BridgeDB. The only visible difference is that captchas has disappeared from https://bridges.torproject.org and requesting bridges in Tor Browser gives you a static captcha and doesn't even verify if the answer is correct (until we have the time to update TB to don't request the captcha[2]. The mayor difference for bridge operators is that we don't distribute "moat" bridges anymore. We have merged circumvention settings and moat and now is one distributor handing over "settings" bridges. For now we are going to keep the existing "moat" bridges assigned to "moat" and don't distribute them, so users that have one of those bridges can keep using them without risk of censors finding it. New bridges will not be assigned automatically the moat distributor, only existing bridges or bridges with "BridgeDistribution moat" will stay in this distributor. We plan to watch the usage of moat bridges and evaluate moving them to another distributor depending on the usage[3]. Thank you for running bridges. [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [3] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

3 6