Brute-Force SSH Server Attacks Surge – Security – InformationWeek: “The number of brute-force SSH attacks is rising, the SANS Internet Storm Center warned on Monday. ‘[T]here has been a significant amount of brute force scanning reported by some of our readers and on other mailing lists,’ said Internet Storm Center handler Scott Fendley in a blog post. ‘… From the most recent reports I have seen, the attackers have been using either ’low and slow’ style attacks to avoid locking out accounts and/or being detected by IDS/IPS systems. Some attackers seem to be using botnets to do a distributed style attack which also is not likely to exceed thresholds common on the network.’”
(Via Information Week.)
No kidding. I’ve been seeing a huge spike on my server and was tipped off that the volume had gone up when I saw a CPU spiking with an sshd process. Killing off the process resulted in a new connection attempt a couple of minutes later. Adding the IP address to my blacklist resulted in a new connection attempt from another address shortly afterwards.
This would imply a certain amount of coordination amongst botnet members. They are discreet enough to only try one connection at a time, but blocking each address results in a new connection attempt from elsewhere. However, a few things worth noting regarding the current attacks that I’m seeing:
-
they’re consistently targeting the root account
-
they don’t appear to be smart enough to disconnect after too many failed attempts
As a result, if you’re running a standard OS X Server installation, you’re relatively safe since even if you activate the root account, you can’t open an ssh connection directly to the root account. You need to connect as someone in the administrators group and then sudo or su to start doing things as root. The other aspect is that after 3 failed attempts, OS X Server automatically blocks further attemps for 15 minutes, so brute force attack has little chance of getting through since they get three tries every 15 minutes instead of hammering their way through their local dictionary in one pass.
However, the problem with the attack tool is that once they’ve been refused the connection goes into a wait state and spikes a CPU at 100%. Since each sshd connection only runs on a single thread, you see one core spiked. Since they’re been polite (for the moment) you shouldn’t be seeing it eat up all of your processors, but it’s still a significant load on the server.
On my server, the solution has been relatively simple - I no longer accept ssh connections from anywhere. I’ve put in a small whitelist on the firewall so that it only accepts connections from home and the office. That could be a problem later on if I really need to get in from a client site, but I’ll just have to live with that.
Now I’m watching new attempts arrive every 2-3 minutes in the firewall log. I’ve started trying to backtrack IP addresses to advise people that their machines might be compromised.