Botnet targeting Tor relays
Hello, I run several Linux root servers, spread over several providers, some of which serve as Tor relays. For a few weeks now I have been observing massive brute force attempts via SSH from hundreds of sources around the world. However, only the Tor relays are affected, the rest of the servers are not. Are other relay operators also observing something like this? Is there currently a botnet targeting Tor relays? Best, Kai.
anon@kai.sx wrote on 10/17/24 10:40:
Hello,
I run several Linux root servers, spread over several providers, some of which serve as Tor relays. For a few weeks now I have been observing massive brute force attempts via SSH from hundreds of sources around the world. However, only the Tor relays are affected, the rest of the servers are not.
Are other relay operators also observing something like this? Is there currently a botnet targeting Tor relays?
Yes, since the dawn of times. My firewalll blocks any connection to port 22. -- Marco https://nusenu.github.io/OrNetStats/w/relay/A4E74410D83705EEFF24BC265DE2B2FF...
Hi Kai, Any systemd/Linux system connected to the internet with IPv4 is going to be hit with endless bruteforce attempts, not just tor relays (although most tor relays have their IP addresses published online, meaning attackers find out about such systems sooner). The solution is to disable password auth and use pubkeys only (so bruteforcing attacks won't succeed until after the universe burns out), too bad most of the bots are incompetently programmed and keep retrying with a password even if the sshd returns that such auth method is not available. You still get logspam, but you can stop that with sshguard or fail2ban, note that setting thresholds too low will end up with you blocking yourself. -- Kind Regards, DiffieHellman
Hi DiffieHellman,
The solution is to disable password auth and use pubkeys only (so bruteforcing attacks won't succeed until after the universe burns out), too bad most of the bots are incompetently programmed and keep retrying with a password even if the sshd returns that such auth method is not available.
You still get logspam, but you can stop that with sshguard or fail2ban, note that setting thresholds too low will end up with you blocking yourself.
don't worry, such measures have been implemented. Therefore, the attacks will not be successful. I only notice that the other servers (which are also kind of well-known out there) only receive a few attacks per day, while the Tor nodes receive well over a hundred each (would be significantly more w/o fail2ban). So I was wondering whether a botnet is currently targeting Tor nodes in particular. Best, Kai.
I only notice that the other servers (which are also kind of well-known out there) only receive a few attacks per day, while the Tor nodes receive well over a hundred each (would be significantly more w/o fail2ban).
So I was wondering whether a botnet is currently targeting Tor nodes in particular.
Security researchers use lists of known public Tor nodes for legitimate testing purposes all the time. I remember seeing a few people on Tor mailing lists scan the network for open CUPS ports when that vulnerability first came out. If legitimate folk are already scanning relays, it’d make sense that malicious threat-actors would follow suit. Reiterating what others have said before, the best way to avoid this sort of thing is to not expose SSH or non-relay services at all.
On Thursday, 17 October 2024 13:34 DiffieHellman via tor-relays wrote:
The solution is to disable password auth and use pubkeys only
Yes, SSH key auth should be the minimum requirement. 2FA SSH key's the way to go.
You still get logspam, but you can stop that with sshguard or ail2bafn, note that setting thresholds too low will end up with you blocking yourself.
I think fail2ban for SSH is a total code overhead and child's play¹. You let attackers connect and then parse the logs afterwards. This can be solved with few lines of IP/NF-tables directly at the source. As early as possible, preferably in table ingress or prerouting before conntrack is active. ¹I no longer take admins who configure fail2ban abuse seriously. I reject this nonsense. Most servers only need to be accessed by a few IPs or possibly 1-2 providers. I only allow 2 ASNs in nftables. Toralf, Enkidu-6 and I have IP/NF-tables examples on Github. If something is unclear, please ask. Nice pictures and very good answer: https://thermalcircle.de/doku.php?id=blog:linux:nftables_packet_flow_netfilt... https://unix.stackexchange.com/questions/581964/create-dynamic-blacklist-wit... -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!
Hello, I noticed this same behavior, but from my exit relay instead, so I now reject port 22 exits. It would be helpful if there was a way to allow SSH, while being able to control IP-Range scanning and brute-force attacks. For example: If a circuit by a client with malicious intent (IP-Range SSH port scanning / brute-force) had the same source port on the exit IP of my relay, you could easily create an IPTables rule to allow bursts up to maybe 90 connection attempts per minute, per client, and then either drop or TCP-RST for 5 minutes. However, it is not hard to see the downside to this: If source ports from one client on the relay where they exit were NOT random, it could harm anonymity / privacy. I would love to allow SSH through my exit relay, which averages 80 MBit/s, and I currently don't reject any other port except for 25 (unencrypted and / or unauthenticated SMTP). However, I don't think I could write an efficient IPTables ruleset if I were to allow port 22 now. I might accidentally block legit traffic, et cetera. Any advice on this? -GH P.S: Maybe we should tweak consensus parameters for Guard nodes, which already do DoS mitigation.. with the relatively new "concurrent connections" mitigation, we should be able to detect SSH port scanning or range scanning. I need to look at the consensus parameters and the Tor code-base again to see if maybe it could be improved. On Thursday, October 17th, 2024 at 10:40 AM, anon@kai.sx <anon@kai.sx> wrote:
Hello,
I run several Linux root servers, spread over several providers, some of which serve as Tor relays. For a few weeks now I have been observing massive brute force attempts via SSH from hundreds of sources around the world. However, only the Tor relays are affected, the rest of the servers are not.
Are other relay operators also observing something like this? Is there currently a botnet targeting Tor relays?
Best, Kai.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 2024-10-23 05:27, George Hartley via tor-relays wrote:
Any advice on this?
How many concurrent exit connections do you have? And how often do you see bad actors running scanners? It shouldn't be too onerous to rate limit on --dport 22 globally. This is no worse than blocking 22 outright, and any time you don't have a bad actor a relatively low limit on --dport 22 would hardly ever even get noticed. How many ssh connections do your average 100 people open per second? If you constantly, or even often have a bad actor on, then they will tend to take up your allowed connection count. But if its only occasional, it might be a good compromise. I'd also make the rule to reject rather than drop. In my experience a lot of the ssh botnets tend to pout and go away when they get rejections. Drops just keep them coming back. For everone else working on the incoming side, knockd is your friend. I found this was so much of a better solution than fail2ban.
participants (7)
-
anon＠kai.sx -
Benjamin Hays -
boldsuck -
DiffieHellman -
George Hartley -
Marco Predicatori -
Red Oaive