And may even be malicious.
I have been receiving “malicious activity” reports from my hosting ISP about my Tor node at “tor1.rlogin.net” since about the end of October. So far I have received five such reports. Each report takes the following form:
We have received an abuse report from abuse@watchdogcyberdefense.com for your IP address 95.216.198.252.
We are automatically forwarding this report on to you, for your information. You do not need to respond, but we do expect you to check it and to resolve any potential issues.
Please note that this is a notification only, you do not need to respond.
Kind regards
Abuse Team
Each report attaches a report from the idiots at abuse@watchdogcyberdefense.com which says the following:
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 involvedTo assist you in understanding the situation, we have provided the relevant log data below, with timestamps adjusted to our GMT +8 timezone:
DateTime Action SourceIP Srcport Protocol DestinationIP DestPort
28-Oct-2024 19:35:08 DENIED 95.216.198.252 3902 TCP 202.91.162.249 22
28-Oct-2024 19:40:38 BLOCKED 95.216.198.252 0 202.91.162.24 22
28-Oct-2024 19:41:57 BLOCKED 95.216.198.252 0 202.91.162.47 22
28-Oct-2024 19:43:59 BLOCKED 95.216.198.252 0 202.91.162.24 22
28-Oct-2024 19:45:23 DENIED 95.216.198.252 22296 TCP 202.91.161.98 22
28-Oct-2024 19:53:26 BLOCKED 95.216.198.252 0 202.91.163.206 22
28-Oct-2024 20:00:28 BLOCKED 95.216.198.252 0 202.91.163.206 22
and so on for several lines of “log files”.
Now initially, I considered this to be a real problem. From the reporting it would seem that my Tor node had been attempting to connect to TCP port 22 on a range of machines across the ‘net. Port 22 is commonly assigned to SSH (unless the sysadmin has disabled SSH or moved it to a different listening port). Attempts to connect to port 22 are part of the normal “background noise” of the ‘net as ‘bots routinely scan for open SSH ports before attempting brute force authentication attacks. Most sensible people wishing to remotely access their servers routinely move the port to a less well known one, disable password authentication in favour of certificated public key auth, and usually limit access to one (non-root) user id as well. (I do all of that but in addition my iptables F/W rules deny all connections to my SSH port from any address except my own fixed IP addresses).
My Tor node “Tor1” is a middle relay, i.e. it does not, and should not make outbound connections to any other hosts except a Tor exit node. Since the addresses given are not Tor nodes, any real activity from my server to those addresses would indicate that my server had been compromised and was being used for malicious activity. Worrying. My ISP would be perfectly entitled to shut me down and lock my account. Fortunately for me they chose simply to pass on the information and ask that I investigate – which I did. Others were reportedly less lucky.
At this point I learned from the “tor-relays” list (an email listserver dedicated to discussions between relay operators) that I was not alone in receiving this alleged “abuse” report. Several contributors reported seeing almost identical reports to the one I received and all came from the same reporter “watchdogcyberdefense.com” to their ISPs. As I reported to the list that I had also seen this, several others popped up to say “me too”.
My initial investigations on my relay showed nothing untoward – certainly there were no outbound connections from my node to destination port 22 other than for one or two Tor nodes which were (for reasons of their own) actually running Tor on port 22. So I left tshark running listening for inbound connections to my server coming from port 22 outside.
While this was running I learned from the tor-relay list that Roger Dingledine of the Tor project team had posted a report about “Dir auths getting abuse complaints about port 22 scanning”. In that report (which has since been updated and modified), Dingledine postulated three theories about what was going on. He concluded in “theory three” that:
these reported port 22 hosts don’t actually appear to be listening, so there was no three-way handshake, so if the observers only saw syn packets, those could have been forged from anywhere.
That is, in this theory, some jerk is spoofing syn packets and sending them to these abuse honeypots in order to make people mad.
Dingledine’s theory looked plausible to many people on the list who were seeing similar activity.
Source IP address spoofing means that the packets received by a host do not actually come from the real IP address recorded in the log, they come from a completely different address which is pretending to be the spoofed server. Since the real server involved in this “attack” did not initiate the original connection it has no record of the outgoing connection in its internal state tables, all it will see is the return connection from the server “answering” a connection request it did not initiate. In most cases, where the second party server is not running anything on port 22 the first packet the innocent (spoofed) party will see is a RST packet tearing down a connection it did not initiate. In other cases, where the second party server is actually running something on port 22, the spoofed server will see a SYN/ACK packet acknowledging a SYN connection it did not make.
This is an extract of what tshark showed on my server:
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 back from servers I had not initiated any connections to. This confirms the theory that someone is spoofing Tor node source addresses.
The reasons for this are not hard to fathom. Tor is disliked by a range of “bad actors” because Tor facilitates free anonymous connection to the ‘net. Authoritarian regimes in particular do not like this so attempt to get Tor nodes shut down. One easy way to do this is to get their addresses listed in one or more “bad reputation” lists (akin to spamhaus for email relays). Unfortunately there are way too many lazy, inexperienced, or just stupid sysadmins around who will sign up to such automated “bad reputation” lists and incorporate those addresses into their firewall rules without thinking. This leads to Tor relays being unable to connect to such “protected” machines. But worse than this, quite often the “bad reputation” lists will not just list the single IP address they have seen supposedly hostile activity from, rather they will list the entire /24 block containing that address. The result is that, even if the “bad address” is genuinely a hostile server (or has been compromised, thus making it hostile) then 250 odd perfectly innocent parties on servers who share that /24 address space will find themselves mysteriously unable to connect to a range of servers on the ‘net. This is bad practice and should not be allowed, but it is difficult to police except through education
At around the time I was checking my own server, Pierre Bourdon (aka “delroth”) posted a good exposition of what he was seeing after being contacted by his ISP with a request similar to the ones other relay operators were seeing. He ran tcpdump on his server and concluded from what he was seeing that:
Something was in fact going on. But not at all what I was expecting. Turns out: no connections were coming out of my server and going to the port 22 of random machines. But some random internet machines were in fact sending me TCP reset packets.
Delroth goes on to give a good description of what source address spoofing is, and what it means. He concludes:
To recap what’s (probably) going on:
A malicious attacker has access to a network without BCP38 filtering.
They send TCP connection requests to port 22 on many random internet machines – possibly deliberately selecting known honeypots or networks known to send automated abuse complaints.
Those TCP connection requests use a spoofed source IP address, making the destination machines think the spoofed source sent that connection. They become the target of the automated abuse complaints.
With a large enough volume, the spoofed IP quickly becomes widely blacklisted from many internet entities following blocklists, and the hosting provider might take action due to many abuse reports and shut down the server for being compromised / malicious.
I agree, and I have pointed my ISP to both Roger Dingledine’s note and to delroth’s blog post. I just hope that I don’t get shut down, but I’m not at all hopeful that the Tor nodes which have been spoofed will successfully stay out of black lists. I have also emailed the idiots at watchdogcyberdefense.com asking that they apply a little more intelligence to their (presumably automated) abuse reporting system so that it does not cause the havoc it could. Of course they have not replied.
Addendum.
I have now received another “abuse” report initiated by the bozos at watchdogcyberdefense.com which implies that I am scanning, or initiating connections to port 21 – FTP. Who the hell uses FTP these days? Why would anyone attempt to connect to an FTP server across the ‘net?
Oh and one more thing which leads me to conclude that watchdogcyberdefense.com is operated by idiots, one of their abuse reports 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. So my server could not possibly have initiated a connection to it.