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