At Z+0000=2024-10-30Wed13:43:01, Andy Smith via BitFolk Users sent: 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? I often wonder about how to mitigate this problem. 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. 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. Accidental backscatter -- good point. I have seen this on LANs on many occasions. 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. Oh, okay. 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. 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. 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. Oh right. Delroth's article states that their Tor relays are not also exit nodes, though, so I don't think it is this. 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.

Hi Andy, At Z+0000=2024-10-30Wed20:45:22, Andy Smith via BitFolk Users sent: Yep, this all makes sense. Thanks for clarifying. :-) Yep, it can't transmit any TCP payload data. When I first mentioned "payload", I think I was actually thinking about the payload of the IP packet -- in this case the IP payloads are the TCP packets that are all TCP header. In other words, when I was wondering about looking closer at the packets for details that might help differentiate, I was wondering whether there were any other details in these spoofed packets that could be used to distinguish them from legitimate SSH connections, in either the fields that have been listed by Delroth, or in fields or flags that were in Delroth's TCPdump that were not listed, if any. Given that these IP packets are small and all-header, with just a few header fields, if anything could distinguish them, these details are probably already visible in Delroth's article. I have been thinking about this some more, and something that I am wondering about is whether the src and dst /ports/ seem to be back-to-front from the usual way of doing it. This comprises a single bit of information hidden in plain sight which is actually quite helpful in potentially blocking this attack, if I am not mistaken. My understanding, in the 3-stage handshake, SYN, SYN+ACK, ACK, is that that initial SYN packet usually goes from a high port to a low port -- e.g. a low port of 22 for SSH. Now, Delroth's article does open with this quoted abuse alert email listing a number of packets outbound from Delroth's server at 195.201.9.37 with high src ports, and heading towards dst port 22 on various other hosts -- making it look like, at first glance, that these are SSH connection attempts initiating on Delroth's 195.201.9.37. But as Delroth soon discovers that these are backscatters triggered by incoming spoofed SYN packets, it means that these outgoing packets are actually SYN+ACK packets, and thus /out-of-phase/ with the usual sequence. This could be a really key way to detect and block this kind of attack, both for operators of servers and for service providers running honeypots with automated abuse warnings. I also notice that the destination IP addresses listed are all within the range of 202.91.16[1-3].* -- in the quoted email, that is -- the others listed below are different, though. I also wonder whether the TTL of these packets would be 1 less than normal -- however, this can be spoofed as well, and also depends on how far these have travelled across the Internet, so not really very helpful. The SYN versus SYN+ACK phase mismatch seems to me like the most useful thing here. Also, simply blocking outbound SSH, except for a whitelist, seems like a quick easy fix. This would not block me from SSH'ing-in to the server, and if I find that I want to SSH-out to another server, maybe for SCP, SFTP, Rsync, a temporary port forward, or whatever and I find that I have blocked myself -- well I can fix that from that server that I am already SSH'd into! :-) I don't see the harm in blocking outbound SSH until otherwise needed, if it avoids transmitting abuse, seeing as I can always change that later if it becomes a problem. Yep, so, for clarity, I will annotate that with what I think the high/low port numbers are doing in the activity that Delroth has observed:- ATTACKER \ \ -SYN packet with source IP of VICTIM--> TARGET VICTIM <------------------SYN+ACK packet back-- TARGET (e.g. Delroth's VICTIM --RST back because sequence number-----> TARGET 195.201.9.37:xxxxx) (port 22) didn't match any SYN it had sent Btw., it seems to me that both TARGET and VICTIM are victim to different parts of the attack -- VICTIM is victim to a more typical DDoS attack, whereas TARGET is victim to consequences that may be more severe than mere Denial-of-Service. I would label these VICTIM1 and VICTIM2, if not for matching the labels with your own diagram. Yes, hypersensitive security can create new vulnerabilities and instabilities. But if I am not mistaken about the aforementioned phase mismatch, there could be a small adjustment to those detections that avoids incentivising this new kind of attack that seems to be leveraging those abuse alerts as a new form of abuse in itself. Well, nothing new about the concept of a "stitch-up", but it may be fairly new to witness a stitch-up at the TCP/IP level in incomplete connections that don't even complete their TCP handshakes. Btw., "port 22 SYN packets" is ambiguous, in this context. Normally, a port 22 SYN packet would be a SYN packet with a destination port of 22. In this context, Delroth observed packets that were out-of-phase with this usual relationship, implying that in fact the SYN packets in this case actually had a source port of 22 -- as far as I understand. These are 2 very different things, even though informatically, this can be reduced to being different by only a single bit of information. This single bit of information may be key to distinguishing the spoofed packets and blocking them before any backscatter occurs. Yep. I never suggested it was. It is TARGET that represents the Tor relay. And as Delroth and we have established and seconded, the software on TARGET such as Tor is not particularly relevant either, except in being the reason selected as the target of this attack. Agreed, but VICTIM? Have I misinterpreted the orientation of VICTIM and TARGET in your diagram? Are you implying that Delroth's 195.201.9.37:xxxxx is an example of VICTIM in your diagram, rather than TARGET? This would be an alternative explanation for the srcport/dstport phase mismatch that I see, but I don't see how that would match Delroth's logs that he quoted in his article. I may be mistaken but it is worth checking this phase mismatch idea because I think that it could be very helpful if it turns-out to be an easy identifier. Even predates computer networks -- you can generalise it with witch-hunts, for example. (Lol, to be making this comment by-chance on 31st October! :-P No pun was intended.) If "like Tor" means "anonymising network", then I think that this might actually be an impossible problem to solve. To anonymise requires that multiple users (preferably a very large number) use the network and their identities are shuffled. Anyone who uses the network will come into direct contact with nodes on the network, and thus have access to attack them. If the node-directories were somehow made secret, then this would not be an open-access network. The entire network being closed-access, implies a central control, and this central authority would operate more like an individual. E.g., if a government agency operated its own, in-house anonymising network -- whatever goes in or out of it is connected with that government agency, and so it is not really anonymising that agency in any useful way. I gather that Tor itself was born out of a USA governmental/military agency desire to anonymise, and had to make it open-access and gather enough civilian support in order to hide the military activity. So Tor's own foundings kind of imply that an anonymising network has to be open-access and thus will always be very easy to see some or all of the participating nodes. I see. Yep. 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.