The Optimum Attack Rate For SSH Bruteforce? Once Every Ten Seconds

badger.foo writes "Remember the glacially slow Hail Mary Cloud SSH bruteforcers? They're doing speedup tweaks and are preparing a comeback, some preliminary data reported by Peter Hansteen appear to indicate. The optimum rate of connections seems to be 1 per ten seconds, smack in the middle of the 'probably human' interval."

Comments

Passwords are for philistines

[halber_mensch]

RSA keypair auth, disable password auth, bruteforcers irrelevant.

Re:Passwords are for philistines

[TheLink]

Yeah to me that's the best approach - use a different port. Simple and effective enough. You could resort to port knocking or similar (use some other method[1] to selectively allow access to the ssh server). But just running the ssh server on a different port allows you to avoid nearly all automated attempts, so when you actually see brute forcing on your ssh server, it's more likely to be a serious targeted attack (hence you can set up an automated response/alert without getting too many false positives).

[1] For example, if you already have to expose https to the world you could have a web app that triggers the opening of ssh access for the web client's current IP.

Re:Passwords are for philistines

[drosboro]

Good point. My standard setup is to move SSHD to a non-standard port, and to turn off PasswordAuthentication completely in favour of RSA key-pairs.

Just checking my SSHD logs, it looks like I've had exactly one rejected attempt on a busy public-facing web server (which may in fact have been me, connecting from a machine that I hadn't set up a key for) in the past month... so in my experience, no, they're not trying too hard off of port 22.

Re:Passwords are for philistines

[JWSmythe]

      I double that up. sshd to a nonstandard port, and firewall rules to only allow access in from very specific IPs and networks.

    You really shouldn't be able to ssh in from just anywhere. Even if that means throwing a copy of OpenVPN up at a static location, to ssh to the second.

    I can get to most of my stuff directly from home. At a hotel, airport, or coffee shop, I am on a hostile network, and shouldn't even be able to see that the port is open.

    But, most people scanning for machines with SSH on them to hit are blindly scanning port 22. It's people interested in your specific network will scan every port on every machine. Someone determined to hit your machine specifically will try every trick they can, and having SSH on port 2222, 9222, or 64222 won't help, if you have a weak password or an exploitable version.

Or never...

[damn_registrars]

Most of the bruteforce attacks I see on my home server are trying to get in as root. I don't allow remote root logins anyways (and even say so on the ssh greeting) so they'll never get in, even if they do manage to guess the password.

Hence their most optimal rate for my system would be never, because they won't get in that way. Not that my system is impenetrable - I'm sure an intelligent hacker could compromise it - but they will never get in trying to ssh in as root.

If they're doing white pages username + dictionary password - or white pages username + blank password (I've seen both, from botnet attacks), they still won't get in on my system as none of the common user names are used there.

But it still would not work.

[khasim]

They'll use a dictionary attack that is spread over some number (dozens or more) of distinct botnet systems, making it very inconvenient for you the admin to try to block all those addresses.

Who cares about blocking them? They're not getting in anyway. Blocking is just additional work that may cause problems.

That said from my experience the botnets usually seem to do a white pages type list of common usernames and then try either blank or extremely common user names to try to get in by.

That's the reason that they're not going to get in. They're using usernames that don't exist (unless the sysadmin is an idiot in which case you have the regular idiot problems and it's probably been cracked already through one of those).

So you may also want to ensure that if you have users who use very common (English) first names as their login names, they are using strong passwords.

If you're using JUST first names or last names as usernames then you have a bigger problem.

Instead use something like one of the following:
FIrstnameLastname
Firstname.Lastname
FirstnameMiddleinitialLastname

You should be able to easily distinguish the potential threats from the random script-kiddies. That being a REAL username on your system with hundreds of login attempts.

And then you deal with that issue by changing the username. Then investigate how that username leaked.

Re:Details?

[ledow]

knockd on Linux. Apt-get should find it for you. It will execute a specified shell script when it receives a specified knock (default one is specified). That shell script can be passed the IP that knocked (so you can include it in an iptables opening within the script).

There are also implementations for Windows, should you need that.

Denyhosts

[Gaygirlie]

I personally use Denyhosts on my Linux server; it is a simple application that keeps an eye on SSH log and blocks access to SSH and any other services you have configured when the limit threshold is reached. You can also configure whether to keep those IP-addresses blocked forever, or for a specified time. Plenty useful. And the attack described here wouldn't work with Denyhosts.

Since I don't use my server for any actual business-use I have just configured Denyhosts to flat-out block access to any and all services altogether when the limit threshold is reached, and I've configured it to retain the block lists forever. These days I've got several thousand IP-addresses there and I rarely see anything malicious in my logs anymore.

Of course, denying root login altogether and using either SSH-keys or proper, long passwords is still essential.

Re:WTF, Editors?

[Samantha Wright]

It's the name of a botnet. Assume any unfamiliar word in any Slashdot summary is the name of a botnet; it makes them eminently more readable. You can try out the technique on this one.

Re:OpenSSH should block these

[subreality]

Why roll your own firewalling script? fail2ban works great.

In my experience fail2ban alone gets the attack rate down so low that they'll never succeed. They can scale the attack with more IPs, but large botnets aren't free and the price is apparently high enough for them to never bother any of my exposed machines.