tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays