[bitfolk] Re: Backscatter attacks on TCP connections (not limited to Tor) triggering abuse honeypots of service providers

At Z+0000=2024-10-29Tue14:15:32, Andy Smith via BitFolk Users sent: Having read that article, it looks like this issue is of most relevance to the service providers of those 3 customers -- so more relevant to BitFolk, right Andy?, or BitFolk's ISP. The article finds that the only threat that seems to be present in this backscatter attack on TCP connections, ordinarily benign, is that it is triggering abuse warnings of some ISPs or hosts, which may have further consequences if not responded to. The article implies that if it were not for these abuse honeypots, backscatter attacks on TCP would be ineffective, unless part of an ordinary DDoS attack on some other target. The article also draws the realisation that this nefarious activity is not specific to Tor, even though the Tor network is currently observing this backscatter activity from multiple countries and continents, but the concept of the attack could just as easily target any TCP-based service into triggering the automatic abuse honeypots -- whatever those consequences may be from minor nuisance to termination of service contract. The article implies that this attack is an exploitation of a vulnerability that was created by the abuse prevention measures themselves, and is only as severe as those consequences are. If backscatter on TCP connections is ordinarily benign, then maybe it is the responsibility of service providers to adjust their abuse policy to act differently on TCP packets, such as to undermine the motive of this kind of attack -- which could be worse than the DDoS attacks that the abuse prevention measures are trying to address, depending on the severity of the consequences triggered. If the abuse prevention can trigger actions as hostile as termination of contract, then the service providers will have "jumped out of the frying pan and into the fire", replacing DDoS vulnerability with a vulnerability that is far more hostile. Then again, the DDoS vulnerability never really goes away, so actually they have just added more attack surface area with little gain, it seems. The article does not suggest any technical remedy on the part of the service user, and merely suggests replying to the automatic abuse messages asserting that "you are in fact a victim and not a perpetrator", but seeing as this attack seems to be targetting port 22 -- the port for SSH -- surely there is some set of filtering rules that could differentiate the spoofed packets from the rest of the Tor traffic, without blocking SSH as well. I still don't get how we jump from whatever port Tor uses to port 22 for SSH. I'm wondering whether this is perhaps an abuse of the Tor network to somehow conduct a distributed SSH port-knocking-style attack, somehow finding machines listening for SSH connections. But as the article already points-out, the attacker does not get to see the replies from this backscatter, so we believe. 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? You run some data through the Tor network, you can see what relay you are connected to, you send a TCP RST packet to that relay that backscatters to some server you want to knock for SSH, if the server replies, you somehow detect this in your Tor connection -- maybe the reply disrupts the TCP connections in some obvious and detectable way, such as a connection tear-down. That then gives feedback as to whether that server has SSH running on port 22. Just an idea. It is way beyond me to prove or disprove this. I don't even run Tor. Nice! :-D Jq is a very useful tool. I discovered it a few years ago. Thanks for this share, Andy, it has certainly been an interesting and thought-provoking read! :-) 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.