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:
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 [...]
Same here. Middle relay, automated abuse report forwarded by Hetzner, for alleged scans of TCP port 22 across several related IPv4 class-C networks. I wondered if that was a mistake on the reporting third party's end, but given that I am not the only on, it seems there is more to it.
-Ralph
On Tue, 29 Oct 2024 06:52:13 +0100 Ralph Seichter via tor-relays tor-relays@lists.torproject.org allegedly wrote:
- Pierre Bourdon:
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 [...]
Same here. Middle relay, automated abuse report forwarded by Hetzner, for alleged scans of TCP port 22 across several related IPv4 class-C networks. I wondered if that was a mistake on the reporting third party's end, but given that I am not the only on, it seems there is more to it.
Me too. Middle relay on Hetzner. Alleged SSH scans from my relay. I have not yet had time to investigate, but will do so later today.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------
On Tue, 29 Oct 2024 07:47:53 +0000 mick mbm@rlogin.net allegedly wrote:
Same here. Middle relay, automated abuse report forwarded by Hetzner, for alleged scans of TCP port 22 across several related IPv4 class-C networks. I wondered if that was a mistake on the reporting third party's end, but given that I am not the only on, it seems there is more to it.
Me too. Middle relay on Hetzner. Alleged SSH scans from my relay. I have not yet had time to investigate, but will do so later today.
Mick
I have taken a look at my relay and noted activity like this a short while ago.
105.812429380 202.91.162.47 → 95.216.198.252 TCP 54 22 → 18588 [RST, ACK] Seq=1 Ack=1 Win=5840 Len=0 113.387329574 202.91.163.206 → 95.216.198.252 TCP 54 22 → 41567 [RST, ACK] Seq=1 Ack=1 Win=4128 Len=0
So - resets coming from a host I have not attempted to connect to.
I have informed hetzner and pointed them to the tor-project note at https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85 given by Roger Dingledine.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------
Could this be the real issue? https://delroth.net/posts/spoofed-mass-scan-abuse/ Greetz, Richie
Am 29.10.2024 um 15:12 schrieb mick mbm@rlogin.net:
On Tue, 29 Oct 2024 07:47:53 +0000 mick mbm@rlogin.net allegedly wrote:
Same here. Middle relay, automated abuse report forwarded by Hetzner, for alleged scans of TCP port 22 across several related IPv4 class-C networks. I wondered if that was a mistake on the reporting third party's end, but given that I am not the only on, it seems there is more to it.
Me too. Middle relay on Hetzner. Alleged SSH scans from my relay. I have not yet had time to investigate, but will do so later today.
Mick
I have taken a look at my relay and noted activity like this a short while ago.
105.812429380 202.91.162.47 → 95.216.198.252 TCP 54 22 → 18588 [RST, ACK] Seq=1 Ack=1 Win=5840 Len=0 113.387329574 202.91.163.206 → 95.216.198.252 TCP 54 22 → 41567 [RST, ACK] Seq=1 Ack=1 Win=4128 Len=0
So - resets coming from a host I have not attempted to connect to.
I have informed hetzner and pointed them to the tor-project note at https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85 given by Roger Dingledine.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hey all,
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
d.
[1] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85#note_3...
Στις 29/10/24 15:23, ο/η mick έγραψε:
I have informed hetzner and pointed them to the tor-project note at https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85 given by Roger Dingledine.
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------
Hi,
I got an abuse report on my Guard, Middle, relay hosted at OVH. I replied with the blog post and explanation that it's an attack outside of my server spoofing packets. No reply back from OVH, no account suspension either.
Regards,
mick:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2024-10-31 13:42, tor@nullvoid.me wrote:
I got an abuse report on my Guard, Middle, relay hosted at OVH. I replied with the blog post and explanation that it's an attack outside of my server spoofing packets. No reply back from OVH, no account suspension either.
I got an abuse complaint from Verizon today since I have a middle relay on Fios (actually eight). I hope I don't get more and/or am forced to go bridge-only. I run eight exits on OVH over 2 IPs and have no abuse tho.
I thought maybe it's an issue with my MikroTik router or an infected Windows PC or Rocky server, I didn't realize it was TCP forgery on middle relays. FSB, maybe?
It would be hard to explain to Verizon I run Tor relays since they technically don't allow servers. I hope I'm not forced onto AT&T Internet Air as my particular co-op rental unit won't let met get Spectrum even when other units can, not that I wanted Spectrum, I don't.
-Neel
Regards,
mick:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2024-10-31 23:15, Neel Chauhan wrote:
It would be hard to explain to Verizon I run Tor relays since they technically don't allow servers. I hope I'm not forced onto AT&T Internet Air as my particular co-op rental unit won't let met get Spectrum even when other units can, not that I wanted Spectrum, I don't.
It shouldn't be necessary to go into great detail. Simply tell them there have been attacks going around the internet where people's ip addresses have been spoofed for ssh connections with an eye toward getting them in trouble with their providers. Explain to them that further actions from them on this matter would be like taking action against a person if someone else forged your reply address on outgoing harassing postal mail letters. In other worst, totally inappropriate. You are not responsible for other people forging your IP address, and if required you can tell them you welcome them to put such monitoring in place as will prove you aren't responsible for the outgoing ssh connections.
If pressed, you can even offer that you are involved with online privacy advocacy and that is how your IP address got out.
All of the above is 100% true.
Hopefully just your willingness to accept scrutiny to prove your IP hasn't originated the connection attempts will be enough. If it does attract too much scrutiny and they discover your Tor contribution, at least you are no worse off.
To The Tor Project officials:
So far the Tor Project has left its operators twisting in the wind over this. Marie has had a ten server account locked over this. A well worded blog entry explaining the attack would be a very welcome assistance to refer our providers to. It wouldn't have to mention this discredit attack is targeting relay operators. It can simply say the attack is targeting privacy volunteers for the project and leave the precise details vague.
On 1/11/24 22:42, Red Oaive via tor-relays wrote:
On 2024-10-31 23:15, Neel Chauhan wrote:
It would be hard to explain to Verizon I run Tor relays since they technically don't allow servers. I hope I'm not forced onto AT&T Internet Air as my particular co-op rental unit won't let met get Spectrum even when other units can, not that I wanted Spectrum, I don't.
It shouldn't be necessary to go into great detail. Simply tell them there have been attacks going around the internet where people's ip addresses have been spoofed for ssh connections with an eye toward getting them in trouble with their providers. Explain to them that further actions from them on this matter would be like taking action against a person if someone else forged your reply address on outgoing harassing postal mail letters. In other worst, totally inappropriate. You are not responsible for other people forging your IP address, and if required you can tell them you welcome them to put such monitoring in place as will prove you aren't responsible for the outgoing ssh connections.
If pressed, you can even offer that you are involved with online privacy advocacy and that is how your IP address got out.
All of the above is 100% true.
Hopefully just your willingness to accept scrutiny to prove your IP hasn't originated the connection attempts will be enough. If it does attract too much scrutiny and they discover your Tor contribution, at least you are no worse off.
If you’re dealing with ISPs that aren’t too friendly towards Tor and you’re worried they won’t get the technical stuff about SYN packet spoofing, here’s a simple tip: just tell them your machine might have some malware scanning on port 22 and that you’re looking into it. It’s an explanation they hear all the time, so it should help take the heat off you.
To The Tor Project officials:
So far the Tor Project has left its operators twisting in the wind over this. Marie has had a ten server account locked over this. A well worded blog entry explaining the attack would be a very welcome assistance to refer our providers to. It wouldn't have to mention this discredit attack is targeting relay operators. It can simply say the attack is targeting privacy volunteers for the project and leave the precise details vague. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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)....
replied to hetzner with proposed template and minor changes.
d.
Στις 31/10/24 17:58, ο/η mick έγραψε:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
On Tue, 5 Nov 2024 10:32:40 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org 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 ---------------------------------------------------------------------
Update for my experience with OVH.
Received 4 abuse emails in total (2 per each relay), each was replied within 24h. No followup on any or response. Still have service uninterrupted.
Hopefully the attacker's ISP kicks them off instead. All of the honeypot that send "incorrect" abuse emails get a flood of responses and update their detection scripts. Ideally no one loses any nodes, but it seems to have already happened.
Good luck everyone,
Dimitris T. via tor-relays:
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)....
replied to hetzner with proposed template and minor changes.
d.
Στις 31/10/24 17:58, ο/η mick έγραψε:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hey,
my personal experience with OVH was that they would accept 5-10 abuse reports per day, even if you replied to them, and then replied to the abuse report with the forwarded reply, but they always disable your VM/Server after 21-30 days.
OVH is also on the GoodBadHosters community page.
-GH
On Tuesday, November 5th, 2024 at 5:24 PM, tor@nullvoid.me tor@nullvoid.me wrote:
Update for my experience with OVH.
Received 4 abuse emails in total (2 per each relay), each was replied within 24h. No followup on any or response. Still have service uninterrupted.
Hopefully the attacker's ISP kicks them off instead. All of the honeypot that send "incorrect" abuse emails get a flood of responses and update their detection scripts. Ideally no one loses any nodes, but it seems to have already happened.
Good luck everyone,
Dimitris T. via tor-relays:
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)....
replied to hetzner with proposed template and minor changes.
d.
Στις 31/10/24 17:58, ο/η mick έγραψε:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Just adding a "me too" here: Hetzner node, running a relay (*not* an exit node), received two abuse emails from Hetzner that a company called "watchdogcyberdefense" complained about SSH login attempts to their 202.91/16 network.
Replied to Hetzner with my own text and reinstalled my node and installed egress packet filter rules to block traffic to that network. Weird though.
Thanks for reporting this to the list!
On 5 November 2024 17:24:07 CET, tor@nullvoid.me wrote:
Update for my experience with OVH.
Received 4 abuse emails in total (2 per each relay), each was replied within 24h. No followup on any or response. Still have service uninterrupted.
Hopefully the attacker's ISP kicks them off instead. All of the honeypot that send "incorrect" abuse emails get a flood of responses and update their detection scripts. Ideally no one loses any nodes, but it seems to have already happened.
Good luck everyone,
Dimitris T. via tor-relays:
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)....
replied to hetzner with proposed template and minor changes.
d.
Στις 31/10/24 17:58, ο/η mick έγραψε:
On Thu, 31 Oct 2024 11:25:30 +0200 "Dimitris T. via tor-relays" tor-relays@lists.torproject.org allegedly wrote:
similar situation here with hetzner.. got a first report 2 days ago, and just a while ago got another abuse report, by the same watchdogcyberdefence.... with more alleged activity from our ip...
like everybody else, there's nothing coming out from our relay ip, so we strongly believe "Theory three"[1] .
Agree.
I have just received another "abuse" report. Hetzner have yet to respond to my last reply to them.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Wed, Nov 06, 2024 at 11:04:51AM +0100, CK wrote:
Replied to Hetzner with my own text and reinstalled my node and installed egress packet filter rules to block traffic to that network. Weird though.
Egress rules won't help, because the traffic never hits your server -- the source IP address is spoofed as yours, but the packets are injected into the Internet from another location entirely.
- Matt
but the packets are injected into the Internet from another location entirely.
On that note, most data-centers nowadays have routers do SRC IP checks, and do not allow the traffic through if it doesn't match that interfaces assigned address.. it would probably more useful to somehow find the company which allows this traffic, and make them update their routers.
My guess is some Russian data-center, there used to be 2x4 notorious for hosting illegal, even yucky child porn sites, on the open internet. In the end, their datacenter burned down or so the story goes. Since it was a cheap Russian building, they had no Argon/CO2 fire suppression system or even basic sprinklers.
Nonetheless, right now they seem to be back in business, but with much better ToS.
Also, even if you spoof the IP, shouldn't the MAC address still be the one of the server from which the packets originated (unless it's spoofed too)?
-GH
On Wednesday, November 6th, 2024 at 11:40 PM, Matt Palmer mpalmer@hezmatt.org wrote:
On Wed, Nov 06, 2024 at 11:04:51AM +0100, CK wrote:
Replied to Hetzner with my own text and reinstalled my node and installed egress packet filter rules to block traffic to that network. Weird though.
Egress rules won't help, because the traffic never hits your server -- the source IP address is spoofed as yours, but the packets are injected into the Internet from another location entirely.
- Matt
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On Thu, Nov 07, 2024 at 07:53:04AM +0000, George Hartley wrote:
but the packets are injected into the Internet from another location entirely.
On that note, most data-centers nowadays have routers do SRC IP checks, and do not allow the traffic through if it doesn't match that interfaces assigned address.. it would probably more useful to somehow find the company which allows this traffic, and make them update their routers.
The words "somehow" and "make" are doing an awful lot of work there.
Also, even if you spoof the IP, shouldn't the MAC address still be the one of the server from which the packets originated (unless it's spoofed too)?
MAC addresses are link-local addresses, and as such are never seen outside of the broadcast domain (ie the local LAN) they're used on.
- Matt
On Wed, 06 Nov 2024 22:40:08 +0000 Matt Palmer mpalmer@hezmatt.org allegedly wrote:
Egress rules won't help, because the traffic never hits your server -- the source IP address is spoofed as yours, but the packets are injected into the Internet from another location entirely.
But they will allow you to prove to yourself, and your ISP, that the spoofed packets CANNOT have come from your address.
I now have such egress iptables rules on my node blocking all access to:
202.91.160.0/24 202.91.161.0/24 202.91.162.0/24 202.91.163.0/24
And as further proof (if any were needed) that watchdogcyberdefense.com is run by bozos one of their "abuse" reports to Hetzner reportedly shows a “log entry” which reported attacks from my IP address to the RFC 1918 address 192.168.200.216. That address, like all such 192.168/16 prefix addresses is not even routeable across the internet.
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net ---------------------------------------------------------------------
Hi,
And as further proof (if any were needed) that watchdogcyberdefense.com is run by bozos one of their "abuse" reports to Hetzner reportedly shows a “log entry” which reported attacks from my IP address to the RFC 1918 address 192.168.200.216. That address, like all such 192.168/16 prefix addresses is not even routeable across the internet.
good catch. The abuse reports I received also have such 192.168/16 addresses listed.
Does that mean they attack themselves and then blame others?
Best, Kai.
and how many reports are complete fabrications?
no need to spoof ip's at all when you can simply make a false report.
Adding a "me too": I have a tor middle relay in Vultr, and I've had 4 abuse tickets so far. I replied to them with information about my server, this thread, and the delroth's blog post. Vultr closed all tickets without further actions.
Adding another me too. 2 of 5 different ISPs for middle and entry nodes shared same abuse complaints other received. First time in 10 years to receive abuse complaints from middle/entry nodes. Not fun.
It'd be great for Tor to publish a blog on what is happening / what happened so we can include that as more official appearing response in these abuse complaint replies to our ISPs rather than only linking a long mailing list thread and a wonderful but unknown individual's blog.
Another opportunity for Tor to further educate more people, especially ISPs forwarding abuse complaints that we're all replying to so we don't lose our Tor nodes.
Sent with Proton Mail secure email.
On Thursday, November 7th, 2024 at 12:55 PM, Nicolás Dato nicolas.dato@gmail.com wrote:
Adding a "me too": I have a tor middle relay in Vultr, and I've had 4 abuse tickets so far. I replied to them with information about my server, this thread, and the delroth's blog post. Vultr closed all tickets without further actions. _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
usetor.wtf via tor-relays:
Adding another me too. 2 of 5 different ISPs for middle and entry nodes shared same abuse complaints other received. First time in 10 years to receive abuse complaints from middle/entry nodes. Not fun.
It'd be great for Tor to publish a blog on what is happening / what happened so we can include that as more official appearing response in these abuse complaint replies to our ISPs rather than only linking a long mailing list thread and a wonderful but unknown individual's blog.
Another opportunity for Tor to further educate more people, especially ISPs forwarding abuse complaints that we're all replying to so we don't lose our Tor nodes.
Check this one out, which we published yesterday:
https://blog.torproject.org/defending-tor-mitigating-IP-spoofing/
GEorg
Sent with Proton Mail secure email.
On Thursday, November 7th, 2024 at 12:55 PM, Nicolás Dato nicolas.dato@gmail.com wrote:
Adding a "me too": I have a tor middle relay in Vultr, and I've had 4 abuse tickets so far. I replied to them with information about my server, this thread, and the delroth's blog post. Vultr closed all tickets without further actions. _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hello, add me to the list too.
Started receiving packets 3 days ago and Tor Weather sent me an e-mail regarding it.
Sad that I could not respond further.. I try to maintain an extremely high uptime. So far, the node has only been been offline for 6 hours in 6 months.. now it's been 72 hours :(
I also got a Tor Weather notification, which finally got my attention.. sadly 3 days too late. It also took my friend some time to travel to the data center, I don't live in the United States, he does, but it's like 45 minutes using the nearest bus for him.
The DC staff refused to re-connect our power-cable, since we allegedly "abused" their network "to a great extent" (in quotes text is from DC staff).
I mailed them about this mailing list, and they finally understood, or it seems that way.
My hoster sadly did not notify me, they just took the entire colocated server offline, even if they know that the IP 104.219.232.126 is a bridge IP allocated through QEMU macvtap bridge using the servers physical 10GbE Synology E10G22-T1-Mini network card, and that we own the server including it's main IP address I use for SSH.
They could have just nullrouted 104.219.232.126, but no, they nullrouted both my main IP and the KVM IP, and even "illegally" removed our the power cord, and according to our lawyer, should not have touched our network card card too, since it's specified in the contract that the owner of the server will do all maintenance, but it's unclear if we can do much anything about it. They still own the room, and since it was not clear to them that the packets came from card.. it's a shitty situation.
Will update once everything is restored.
Sorry for the downtime.
I unfortunately could not do iptraf-ng or use mtr to find out the culprit network.
-GH
It appears that the Tor node ExitTheMatrix (fingerprint: 0F8538398C61ECBE83F595E3716F7CE7E4C77B21) has been uncontactable >through the Tor network for at least 48 hours. You may wish to look at it to see why.
You can find more information about the Tor node at:
https://metrics.torproject.orgrs.html#details/0F8538398C61ECBE83F595E3716F7C...
You can unsubscribe from these reports at any time by visiting the following url:
https://www.torweather.org/unsubscribe?hmac=nope&fingerprint=0F8538398C6...
The original Tor Weather was decommissioned by the Tor project and >this replacement is now maintained independently. You can learn more here:
https://github.com/thingless/torweather/blob/master/README.md
-GH
Hi,
the node is back online.
Everything works normally, and I don't get any bogus SSH packets when using iptraf-ng.
Also, we noticed reverse path filtering was off on the VM.. we enabled it. but don't know why it was off.. I configured the ArchLinux VM's /etc/sysctl.d entries on my own, and it is still enabled on boot, or at least should be, but it wasn't.
I checked since I believe arma mentioned it.
All the best, -GH On Sunday, November 10th, 2024 at 6:50 PM, George Hartley hartley_george@proton.me wrote:
Hello, add me to the list too.
Started receiving packets 3 days ago and Tor Weather sent me an e-mail regarding it.
Sad that I could not respond further.. I try to maintain an extremely high uptime. So far, the node has only been been offline for 6 hours in 6 months.. now it's been 72 hours :(
I also got a Tor Weather notification, which finally got my attention.. sadly 3 days too late. It also took my friend some time to travel to the data center, I don't live in the United States, he does, but it's like 45 minutes using the nearest bus for him.
The DC staff refused to re-connect our power-cable, since we allegedly "abused" their network "to a great extent" (in quotes text is from DC staff).
I mailed them about this mailing list, and they finally understood, or it seems that way.
My hoster sadly did not notify me, they just took the entire colocated server offline, even if they know that the IP 104.219.232.126 is a bridge IP allocated through QEMU macvtap bridge using the servers physical 10GbE Synology E10G22-T1-Mini network card, and that we own the server including it's main IP address I use for SSH.
They could have just nullrouted 104.219.232.126, but no, they nullrouted both my main IP and the KVM IP, and even "illegally" removed our the power cord, and according to our lawyer, should not have touched our network card card too, since it's specified in the contract that the owner of the server will do all maintenance, but it's unclear if we can do much anything about it. They still own the room, and since it was not clear to them that the packets came from card.. it's a shitty situation.
Will update once everything is restored.
Sorry for the downtime.
I unfortunately could not do iptraf-ng or use mtr to find out the culprit network.
-GH
It appears that the Tor node ExitTheMatrix (fingerprint: 0F8538398C61ECBE83F595E3716F7CE7E4C77B21) has been uncontactable >through the Tor network for at least 48 hours. You may wish to look at it to see why.
You can find more information about the Tor node at:
https://metrics.torproject.orgrs.html#details/0F8538398C61ECBE83F595E3716F7C...
You can unsubscribe from these reports at any time by visiting the following url:
https://www.torweather.org/unsubscribe?hmac=nope&fingerprint=0F8538398C6...
The original Tor Weather was decommissioned by the Tor project and >this replacement is now maintained independently. You can learn more here:
https://github.com/thingless/torweather/blob/master/README.md
-GH
True, but as Mick wrote in this thread they are more meant as proof to Hetzner that my node doesn't allow contact with the addresses listed.
When I received the abuse emails I was slightly panicking and reinstalled the node from scratch because I couldn't prove that I had *not* been hacked. I found this thread only later and learned that IP spoofing might be in play. Somehow I assumed IP spoofing to be a thing of the past - interesting that this is still possible.
Or "Cyberdogdefense" is just making stuff up, all the did is send a bunch of "log entries" to Hetzner and *claim* these nodes made login attempts to their network.
The worst case would be that there's an actual problem in the Tor code, leaking stuff not to exit nodes but to targets outside of the Tor network.
CK.
On 6 November 2024 23:40:08 CET, Matt Palmer mpalmer@hezmatt.org wrote:
On Wed, Nov 06, 2024 at 11:04:51AM +0100, CK wrote:
Replied to Hetzner with my own text and reinstalled my node and installed egress packet filter rules to block traffic to that network. Weird though.
Egress rules won't help, because the traffic never hits your server -- the source IP address is spoofed as yours, but the packets are injected into the Internet from another location entirely.
- Matt
tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
You likely discovered a way, how criminals (or Intel agencies, since there is no difference) are being allowed access to middle relays.
--x9p
On 10/29/24 04:47, mick wrote:
On Tue, 29 Oct 2024 06:52:13 +0100 Ralph Seichter via tor-relays tor-relays@lists.torproject.org allegedly wrote:
- Pierre Bourdon:
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 [...]
Same here. Middle relay, automated abuse report forwarded by Hetzner, for alleged scans of TCP port 22 across several related IPv4 class-C networks. I wondered if that was a mistake on the reporting third party's end, but given that I am not the only on, it seems there is more to it.
Me too. Middle relay on Hetzner. Alleged SSH scans from my relay. I have not yet had time to investigate, but will do so later today.
Mick
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 blog: baldric.net
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, Oct 29, 2024 at 04:33:33AM +0100, Pierre Bourdon wrote:
Kind of like someone spoofing source IPs to send SYNs everywhere.
Sounds right. See https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/85 where I walked through the analysis, for transparency and to help other folks learn more about how the internet works.
It is a shame that whoever is sending this traffic clearly wants to undermine safety on the internet. :(
--Roger
We've definitely seen an up tick in this type of complain. One of the abuse reports for "port scanning" had a log of exactly 3 SYN packets to port 22, IDK why people bother with soemthing like that given the amount of actual SSH scans I see against our infrastructure constantly.
New one today though, apparently spoofed web exploit probing. That's probably going to trigger a bigger reaction if it becomes more wide spread than a few ssh packets.
-Jon
Jonathan Proulx jon@csail.mit.edu:
IDK why people bother with soemthing like that given the amount of actual SSH scans I see against our infrastructure constantly.
Indeed, but Hetzner is known for noob stuff like that, while they seem to understand the importance of privacy and let people run Tor relays, they also send abuse reports for insignificant stuff such as a port's scan.
Yes, I have 11 IP addresses on Hetzner, 3 of which are running Tor relays. Only those 3 received the abuse notice, which tells me Tor IP addresses are specifically targeted.
I'm assuming It could be intended to get Tor IP addresses added to various popular block lists. Once they're added to several block lists, all kinds of traffic with those source addresses are affected, not just traffic to port 22.
Regards,
Enkidu
On 10/28/2024 11:33 PM, Pierre Bourdon wrote:
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,
On 2024-10-29 06:04, Toralf Förster via tor-relays wrote:
On 10/29/24 04:33, Pierre Bourdon wrote:
Some tcpdumps showing random RSTs coming back to my machines running relays (with no traffic being initiated by said machines beforehand):
You used somethign like this? :
tcpdump -i enp8s0 'tcp[13] & 4 != 0 && port 22'
You want source port of 22.
For RSTs: tcpdump -i enp8s0 'tcp[13] & 4 != 0 and src port 22' For SYN-ACKs: tcpdump -i eth0 'tcp[13] & 18 != 0 and src port 22'
I tend to use nft counters for stuff like this:
If you don't have a good nft accounting chains set up yet: nft create table ip accounting nft create chain ip accounting input { type filter hook input priority filter ; policy accept ; } nft create chain ip accounting output { type filter hook output priority filter ; policy accept ; }
And the the counter rule: nft add rule ip accounting input tcp sport 22 tcp flags == syn|ack counter
You can add them for other source ports too - might be useful to expand our scope to some other commonly abused ports like 25.
To check your counts: nft list table ip accounting
I believe it would be helpful to develop a standard template letter to address these abuse reports. This letter could clarify the ongoing attack, explain the potential for packet spoofing, and outline why responding to a single SYN packet with an abuse letter may not be the most effective use of time.
On 29/10/24 00:33, Pierre Bourdon wrote:
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,
On Tue, Oct 29, 2024, 03:33 Pierre Bourdon delroth@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.
I have also received a notice from my hosting provider regarding this. Have anyone noticed that when you look up the ip that supposedly port scanning 22, there is no reports on abuseipdb?
John - prsv admin
Oct 31, 2024 at 01:30 by delroth@gmail.com:
On Tue, Oct 29, 2024, 03:33 Pierre Bourdon <> delroth@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/%3E 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.
Hey, Ionos (AS8560) locked my account because of SSH scans (i only run middle/guard relays) and told me they couldnt unlock my account, did anyone else had similar experiences with them?
Marie (running all relays with a *.ketamin.trade hostname)
29.10.24 04:33, Pierre Bourdon wrote:
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,
On 2024-10-31 11:44, marie wrote:
Marie (running all relays with a *.ketamin.trade hostname)
Hi Marie. I just wanted to write and point out looking at your relays that none of them have the MyFamily configuration set up. The ownership association between them should be declared.
Hello,
I do operate an exit node which rejects exits on port 22.
You should, by default, change your SSH port to a random 5 digit number:
Random.org Random Number Generator
And apply static IPTables rules to block connection spam even if someone portscans your system (make sure to apply this rule to your random port, I just set the port here to 22):
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name SSH -j DROP $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Also, disable password-based authentication entirely, and go for at least RSA4096 or even better ED25519 login rendezvous.
I promise to later do a tcpdump on my machine, and see if relays on the public lists are more affected then your average "normal" server.
Of course there are always machines, more often infected than not, scanning the IPv4 ranges for open SSH ports, which possible can be exploited.
Please wait for me reply in a few hours friend.
-GH
On Tuesday, October 29th, 2024 at 4:33 AM, Pierre Bourdon delroth@gmail.com wrote:
Hi relay ops, By any chance, any other relay ops seeing the same thing, or am I just going crazy? (it does kind of sound insane...)
Software Engineer @ Zürich, Switzerland https://delroth.net/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hello, here is a 20 minute tcpdump using the PCAP format.
There were only 19 packets inbound on port 22 during said time:
Interestingly, my server was communicating with some other server, making connections TO port 22..
I then looked up said IP in Metrics, and it was just as I assumed another Tor relay:
1 0.000000 104.219.232.126 135.148.149.23 22 TCP 74 37008 → 22 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM TSval=2099663009 TSecr=0 WS=512
The only portscan over a 20 minute timescan was this fellow:
19 466.667800 167.94.146.24 104.219.232.126 22 TCP 74 36027 → 22 [SYN] Seq=0 Win=42340 Len=0 MSS=1460 SACK_PERM TSval=1728927577 TSecr=0 WS=1024
So no, there is no scanning going on on my machine.
I attached the file if you want to take a look in Wireshark or whatever else parser you use.
P.S: Tor-relays moderators, maybe scrub the attachment as it can be used to track down part of a circuit.
All the best, -GH On Saturday, November 2nd, 2024 at 2:47 PM, George Hartley hartley_george@proton.me wrote:
Hello,
I do operate an exit node which rejects exits on port 22.
You should, by default, change your SSH port to a random 5 digit number:
Random.org Random Number Generator
And apply static IPTables rules to block connection spam even if someone portscans your system (make sure to apply this rule to your random port, I just set the port here to 22):
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name SSH -j DROP $IPT -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Also, disable password-based authentication entirely, and go for at least RSA4096 or even better ED25519 login rendezvous.
I promise to later do a tcpdump on my machine, and see if relays on the public lists are more affected then your average "normal" server.
Of course there are always machines, more often infected than not, scanning the IPv4 ranges for open SSH ports, which possible can be exploited.
Please wait for me reply in a few hours friend.
-GH
On Tuesday, October 29th, 2024 at 4:33 AM, Pierre Bourdon delroth@gmail.com wrote:
Hi relay ops, By any chance, any other relay ops seeing the same thing, or am I just going crazy? (it does kind of sound insane...)
Software Engineer @ Zürich, Switzerland https://delroth.net/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
admin＠prsv.ch -
anon＠kai.sx -
Chris Enkidu-6 -
CK -
dewaj -
Dimitris T. -
Georg Koppen -
George Hartley -
Jonathan Proulx -
marie -
Matt Palmer -
mick -
mpalmer＠hezmatt.org
-
Neel Chauhan -
Nicolás Dato -
Pierre Bourdon -
Ralph Seichter -
Red Oaive -
Richie -
Roger Dingledine -
tor-operator＠urdn.com.ua -
tor-relays+tor-relays＠queer.cat -
tor＠nullvoid.me -
tor＠x9p.org -
Toralf Förster -
usetor.wtf