- tor-relays - lists.torproject.org

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 28 Oct '24

28 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