30 Oct
2024
30 Oct
'24
5:32 p.m.
At Z+0000=2024-10-30Wed13:43:01, Andy Smith via BitFolk Users sent:
I was thinking more via some side-channel, like a timing side-channel. But I also was
not seeing the independence of the spoofed and incomplete SSH connections from the Tor
connections, until it was revealed later in the article that this is not specific to Tor.
So on 2nd-thought, I agree with you that the replies to the backscatters have no impact on
the Tor relays that is detectable from a Tor client.
On Wed, Oct 30, 2024 at 12:12:12PM +0000, James R.
Haigh (+BitFolk subaddress) via BitFolk Users wrote:
[...]
In general where we don't think actual abuse is taking place, we expect the customer
to reply to abuse reports involving them. [...]
How does the customer reply to abuse reports from BitFolk's ISP to BitFolk? Does
BitFolk automatically forward such abuse reports to the customer? Or does BitFolk
generate its own abuse reports?
SSH dictionary attacks are so common that when someone
sees a number of TCP SYN packets to their port 22 they just think it is one of those and
report it as such, and the hosting company at the other end would often be inclined to
believe it, as initially seen in that article.
I often wonder about how to mitigate this problem.
The honeypots do an important job of detecting this
sort of activity but it does seem necessary for them to gather more information than some
TCP SYN packets before taking any action.
I was wondering about the payload of the packets. Delroth did not go into that
detail, but his article also states at the bottom that it was written hastily before a
plane flight. He may not have had time to look at the payloads in more detail, like in
WireShark.
I wouldn't necessarily call it benign as it does
imply some forging is going on for some reason.
Sorry, I meant "ineffective". I.e., there is malicious intent there, but
not one that can harm us because the TCP connections never complete their handshake.
It could indicate a misconfiguration such as two or
more devices with the same IP address.
Accidental backscatter -- good point. I have seen this on LANs on many occasions.
[...]
Tor is a proxy. What comes out of it is just normal Internet traffic,
If we are talking about the relay nodes (Delroth specifically states that these are
not also exit nodes), then no normal Internet traffic is coming out of it at this point.
The traffic is inside an encrypted tunnel, being "onion routed" through 3 relay
nodes, iirc..
According to the WireShark wiki, Tor's TLS connection is the usual port 443, and
it also uses ports 9001 and 9030:-
http://frogfind.com/read.php?a=https://wiki.wireshark.org/Tor
My understanding is that the servers running Tor are being sent -- completely
unrelatedly on port 22, and from /outside/ of the Tor tunnels -- TCP packets with a
spoofed source IP address, backscattering to other machines that of course fail to
establish the full handshake, meaning that these connections are instantly dropped -- but
sometimes can trigger anti-abuse honeypots, even though the abuse did not originate on the
server that received the spoofed TCP packets.
So what has it got to do with Tor? Delroth says not much, beside maybe a motive to
cause disruption to the Tor network -- by means of attempting to trigger anti-abuse
measures against operators of Tor services such as relays. These servers may only be
being targetted as such because they are being listed as available relay nodes in the Tor
network.
Machines not running Tor are apparently just as susceptible to this vulnerability, but
simply are not being targetted yet.
[...] When a TCP SYN packet comes in, all you have is
the source address as there is no payload yet.
Oh, okay.
The only way to tell that it is a legitimate
connection attempt from a non-spoofed source is to complete the TCP three way handshake.
Spoofed sources can't complete that.
I think what I might do if I was in this situation is to run my SSH on some other much
higher port, and just drop all packets for port 22, because it has nothing to do with Tor.
Or I would capture them and maybe honeypot them somehow to further protect my real SSH
port.
What if
actually it is more specific to Tor than Delroth first realised? What if it is possible
to detect the replies to the backscatter from within the Tor network?
Tor, being a proxy, runs as a user process on some server. User processes should never
see these partially set up TCP connections as all that happens is the kernel receives a
SYN+ACK packet from the SSH host with a sequence number that does not match any SYN it has
sent itself. It knows something strange has happened and sends back a TCP RST packet to
destroy the connection before it was ever established.
You can't even see this happening unless you run a process with elevated privileges
in order to trace it like tcpdump.
So no, it should not get as far as the Tor process. Anyway, multiple companies are scanning all 65k ports
of the entire IPv4 address space multiple times a day to look for every service there is
and they sell the database of that, so there is no need for anyone to do it through Tor if
the goal were purely to identify SSH servers.
Heh, how is that not against computer misuse? I'm sure if I did that sort of
thing I'd be in big trouble for it, but they are allowed to do it for profit, hey?
Hmm.
Point taken, though.
It may also be worth noting that most Tor exit nodes
are configured to not permit TCP port 22 connections out since they just get used for SSH
dictionary attacks otherwise.
Oh right. Delroth's article states that their Tor relays are not also exit nodes,
though, so I don't think it is this.
Similarly they don't allow port 25 as they just
get used to relay spam.
SMTP. Okay.
Well, I through a few other ideas into the mix trying to question whether there is a
deeper motive besides triggering these honeypots against the wrong people (a TCP/IP
version of "stitching someone up"), but I don't think they came to much
beyond Delroth's understanding that the intent of these spoofed TCP packets is none
other than to turn the honeypots and automatic abuse blockers onto innocent
users/operators.
It still seems odd to me as to why port 22? Why not any port if it is just a spoof
packet to cause a nuisance? Is it because this is the port that is most likely to trigger
various honeypots?
Kind regards,
James.
--
Wealth doesn't bring happiness, but poverty brings sadness.
Sent from Debian with Claws Mail, using email subaddressing as an alternative to
error-prone heuristical spam filtering.