Slashdot Mirror
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."
WTF is a "Hail Mary Cloud"?
I clicked the link in the summary, which talks about something I'm supposed to "remember", but must have missed the first time it was discussed. That goes to another summary that also doesn't explain what it is, but also mentions that it's been discussed before. Then I click the link on that summary and I get a big long page of information.
Does anyone review submissions at all before they go live?
RSA keypair auth, disable password auth, bruteforcers irrelevant.
perl -e "eval pack(q{H*},join q{},qw{70 72696e74207061636b28717b482a7d2c717b343 637323635363534323533343430617d293b})"
Just look for large numbers of incorrect logins over a long-ish time span.
So, set your fail2ban or denyhosts configuration to 11 seconds intervals, and problem solved?
I'm going to guess it was a dictionary attack because otherwise it is even dumber.
That's 6 attempts per minute.
360 per hour
8640 per day
60,480 per week
3,144,960 per year.
So unless you're allowing usernames such as "root" or "admin" or "administrator" AND using dictionary passwords wouldn't this fail? And be obvious in the logs?
So what I've never understood is why it's not possible (as far as I know) for a server to require BOTH a key AND a password. Sure, I can put a password on my key, but that isn't the same at all. Is this possible yet?
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
I have a portknocking setup. All your packets bounce when you touch my port 22 until you have touched a "magic sequence" of port numbers first. That sequence can be cryptographically strong, time-dependent, etc. but even a simple one-port knock is enough to stop all this random SSH spam and has been for years.
And if you do "get lucky" and find the right ports and then detect that port 22 is open and then start a brute-force on that? Public-key-only authentication and no root logins allowed.
Impact on me? Another line in a shell script that I use to connect (and hell, even Android has free port-knocking apps, not to mention them being standard-enough to be in Ubuntu/Debian). Impact on server? Greatly reduced number of fake connections bouncing off iptables and a tiny little daemon that does nothing but listen on the ports I need (and can ONLY open the SSH port even if compromised). Impact on brute-forcers? They might as well give up and go home.
Even those remote companies that we do allow to port-forward direct to their device on my work network (e.g. telecoms providers, etc.) understand it and "knock" before they come in (which tells us exactly when they are about to log in), while everyone else in the world sees closed ports.
Why everyone doesn't use it, I have no idea. Even our VPN users have an automated script that just knocks to open the VPN ports (and only the VPN ports) before they connect. Transparent to them, invisible to everyone else, no different if "compromised".
iptables with the recent module...ssh brute force attacks a thing of the past. Actually, same with RDP and just about any other service you can identify via iptables.
Rate limit those suckers to something useful ( for ssh, I configured 2 attempts in 5 minutes, everything else is dropped ), call it done.
iptables -I INPUT -i eth0 -p tcp --dport 22 -m state --state ESTABLISHED -j ACCEPT
iptables -I INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --set
iptables -I INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --update --seconds 300 --hitcount 3 -j DROP
iptables -I INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT
( Disclaimer: the above is from memory. I am positive there are better ways and more things you can do with it )
Mod me down with all of your hatred and your journey towards the dark side will be complete!
1 attempt per 10 seconds, so 360 attempts per hour, 8640 per 24 hours, 3,153,600 per year or 31 million passwords per 10 years.
Well, if your password is not in some rainbow table and it's at least moderately strong, then you should be fine.
You can't handle the truth.
Who cares about blocking them? They're not getting in anyway. Blocking is just additional work that may cause problems.
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).
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.
Is there a package that includes this functionality or is it all custom done?
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.
I've been blocking these "attacks" using a script+firewall for many years now. And I still think that, really, OpenSSH should have a configuration switch to block them internally. But BSD folks don't see it as a real threat, and they don't want to risk having actual users to get locked out of their servers. Fair enough, I guess.
So we're left with mitigation strategies. At 6 connections per minute, it's more a a nuisance than an attack, but I've seen rates as high as 200 connections per minute in the past, and there is no reason it couldn't go higher on an out-of-the-box OpenSSH configuration.
Some solutions, as others have pointed out:
- Have ssh listen on a port other than 22
- Turn on OpenSSH's internal rate limiting (MaxStartups config)
- Use key-based authentication
- Roll your own script to grep the log for failed connections, and firewall any IP addresses with 10 or more failures
A real brute-force attack would do a portscan first so putting ssh on a high port isn't much of a solution. Key-based auth is a nearly perfect solution, except that there are situations in which it is undesirable/awkward to use keys. The others just slow down the attack, which prevents the force part of brute-force.
I'll just TARPIT those tries automatically after 6 unsuccessfull tries with fail2ban + iptables + TARPIT -module. This will make their connection last forever... at least almost :)
Too bad, just that I have not found working tarpit for the newest kernels yet...
It might solve the problem :-)
http://tools.ietf.org/html/rfc6593
At home? Yes.
I think I seen where you're going with that and I don't think you understand. Collecting email login names is easy.
But being able to login to an outward-facing server (email or ftp or ssh or whatever) should be limited to a certain amount of failed logins (no matter from which IP address) per time period.
The crackers would have to go through an ADDITIONAL step to try to match email login names with ssh login names and an ADDITIONAL ADDITIONAL step to match that name to a different type of server (such as ssh).
Let me see if I can illustrate this.
1. Attacking ssh on server A.B.C.D with username aaron - if there's any chance that the cracker can do it then the sysadmin failed. Even more so with "root" or "admin" or such.
2. Collecting username aaron.aaronson via email spammer and then trying to attack ssh on server mail.example.com - more work for the cracker than scenario #1 but still the same as #1. If there is any chance that the cracker can succeed then the sysadmin has failed. SSH should only be allowed on the mail server from the inside interface.
3. Collecting username aaron.aaronson via email spammer and then trying to attack ssh on servers in the block A.B.C.D through A.B.C.Z (and one of those is your SSH server). And the cracker is using multiple machines to make multiple attempts (one per machine) within time period X. - Again, if it works then the sysadmin has failed. Too many attempts in time period X should lock out the account for a set number of minutes. No matter how many IP addresses are involved.
-continued-
And that depends upon aaron.aaronson being a LEGITIMATE USERNAME ON THAT SYSTEM. Once the sysadmin sees that attack in the logs then the logins to that should be changed (ssh.aaron.aaronson or such) to break that attack if they were not already such. Or change them AGAIN (aaron.aaronson.ssh) and be aware that something leaked somewhere.
4. See #3 except the logins are from multiple machines but only 1 login attempt in time period X so it never triggers the account lockout. Again, change the login names (ssh.aaron.aaronson) to break that attack (and did they leak?).
In summary, getting your system cracked via SSH means that your sysadmin failed so many times.
---
When an attempt is made to login, sshd first checks authorized_keys and if the public key proffered matches an entry, access is granted (with no password challenge). This is standard PKI authentication for sshd.
If no such match, sshd proceeds with PAM authentication and a password challenge will be issued. But, since the /etc/pam.d/sshd file has the pam_access module active, pam_access will deny the login after giving the password challenge. Even if the password given is correct, the authentication will fail.
Thus, a system so configured to the remote world will look like it's ordinary and wide open but will be completely immune to the hail mary attack.
Even if you don't (or can't) configure your systems in this manner, since sshd login by root is disabled by default in most /etc/ssh_config/sshd_config files, the hail mary is only effective with a valid [non-root] user/pw combo. If you use a different username/pw on each system, this reduces the odds on a successful attempt dramatically.
The reason I say this is that I added an additional wrinkle to my PAM stack. After securing it as described above, I created an additional PAM authentication module that logs all incorrect attempts. I also enabled root ssh login, and modified sshd so that it would pass the actual password along.
The normal sshd action is if either root is attempting to login (with root access configured off) or an invalid userid is given, sshd will replace the password with a fixed string of INCORRECT. This is supposed to prevent timing measurements that might give a clue as to whether a given userid is valid. I compensate for this by adding my own random delay that overshadows any response time measurement.
With the mods, I now have a log of time/IP/user/pw attempts. For my home system, I have a dynamic IP with no DNS entry, so it's low profile. Still, after four months in operation, my log has netted some 6000 entries. The attempts fall into several categories:
(1) user/id where they are the same (e.g. userid is mary and password is mary).
(2) several different userids (e.g. a list of 10) and several different passwords (e.g. a list of 9) that are all tried against each other for a total of 90.
(3) very specific userid/pw combos that come from a database of already cracked user/pw combos. These are repeated from far flung IP addresses from time to time indicating that somebody is passing around the database. Some are such specific one shot combos (e.g. root with the same password 439812uioewruiey19283793487123 [an actual password from my log]) that they actually form a signature for the crackers themselves.
Like a good neighbor, fsck is there
But I was always too chicken to set it up to try every failed username/password combination against the host attempting to log in and executing a 'sudo shutdown -h now' if it succeeded. I can't imagine the botnet operators change the vulnerable passwords; that might alert the owner that something was up.
adaptive sec packages help. fail2ban or the like. jail duration of -1, denyrootlogin via ssh, done.
anyone that tries and fails 6 times gets a perm -DROP iptable rule added
Gun one place, bolt and ammo somewhere else. You know where but somebody who breaks in at night doesn't.
Biometrics or whatever don't matter, the important thing is to make sure an attacker can't get everything they need to get in from one place. A key on a USB stick or the local machines disk and the passphrase/password in your head is not one place. If an attacker aims to trick you into providing access then they have have to trick you twice, or steal and trick you.
Perhaps that program could be "login" or something similar. Also, that give you the ability to use different command and different behaviors on a key-by-key basis for the account.
Just install fail2ban: http://www.fail2ban.org/wiki/index.php/Main_Page And set it to something like 6 hours locktime. Really cleans up the logfiles and takes the load of the server, espicially with SMTP. Regards Brian Simonsen
Good luck paying customer service to handle requests to reset these blocks once your customers forget their passwords, forget caps lock is turned on (common for laptops that don't have a dedicated caps lock LED), etc., or once an attacker gets hold of a particular customer's username and intentionally fails to block the legitimate user.
unless the attacker is at the same IP as the legit user
Which is entirely possible under the carrier-grade NAT commonly used in mobile environments and less-developed countries. And if not, if these blocking measures treat each IP address separately, watch a team of over 9000 compromised PCs run through the over 9000 most common passwords.
And protect that key in a number of ways