Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Unknown Lamer posted more than 2 years ago | from the and-that's-why-you-use-denyhosts dept.

Security 167

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."

Sorry! There are no comments related to the filter you selected.

WTF, Editors? (0, Insightful)

Anonymous Coward | more than 2 years ago | (#39600011)

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?

Re:WTF, Editors? (0)

Anonymous Coward | more than 2 years ago | (#39600223)

WTF is a "Hail Mary Cloud"?

From the link: "cloud of distributed, password-guessing hosts"
I thought of it as a possibility when I first started using fail2ban, but I first saw it happen with Mac OS X machines (for some reason, the botnet would target only OSX hosts).

Re:WTF, Editors? (4, Informative)

Samantha Wright (1324923) | more than 2 years ago | (#39601465)

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 [slashdot.org] .

Passwords are for philistines (5, Informative)

halber_mensch (851834) | more than 2 years ago | (#39600015)

RSA keypair auth, disable password auth, bruteforcers irrelevant.

Re:Passwords are for philistines (3, Insightful)

aztracker1 (702135) | more than 2 years ago | (#39600083)

RSA key/pair is something you have... you still need something you are, and something you know... Once someone has your key, it's no more secure than your password. A trojan can read local files, just as easily, if not more so than snoop for a password.

Re:Passwords are for philistines (4, Insightful)

0racle (667029) | more than 2 years ago | (#39600193)

If you have a trojan keylogger, you probably don't have to worry about SSH bruteforcing.

Re:Passwords are for philistines (0)

Anonymous Coward | more than 2 years ago | (#39600195)

Sloppy and careless thinking about security is worse than no security. The questions "What do I have?", "What am I?" and "What do I know?" all live in the provinces of theology and philosophy. Computers should try to pass the Turing test first.

Re:Passwords are for philistines (2)

allo (1728082) | more than 2 years ago | (#39600363)

soon computers will pass the tests better than humans.

there are two types of tests:
- ones with a rather small set of human-made puzzles, computers can just learn them one time
- ones which are generated by computers. Those can be solved by computers, too.
The most ridiculous ones are simple math problems in the html-text.

the average case is some distorted text, which will soon be no problem for computers anymore, as OCR software is getting better.

Re:Passwords are for philistines (2)

JWSmythe (446288) | more than 2 years ago | (#39600609)

    I've been passing as human for years, you insensitive clod!

Re:Passwords are for philistines (2)

hairyfeet (841228) | more than 2 years ago | (#39602877)

Am I the only one that HATES those stupid "R U a Human?" tests? I swear some of them have gotten so damned ridiculous on the word twisting i just write a nasty note to the contact with a JPG of some of their "tests" saying "You tell ME WTF this is supposed to be? is it a 7 or a T? O or 0? Your tests suck" and I've actually gotten a few responses along the lines of "Geez i hadn't tried it since we started using those and didn't know they were THAT bad".

Look I appreciate you want to keep the bots and crap off your sites, i really do, but this stuff is just getting nuts. There has GOT to be a better way than all these hoop jumps because frankly the spammers will just pay some schmuck in Asia a few cents a hundred to spend all damned day cracking your crap while your actual users get fed up and move on.

Re:Passwords are for philistines (4, Insightful)

nine-times (778537) | more than 2 years ago | (#39600521)

Once someone has your key, it's no more secure than your password.

Whether the token is something you know, something you are, or something you have, it *all* becomes useless once someone else has it. That's not really the issue here. The issue is brute-force attacks on SSH, and using a key makes them significantly more difficult than passwords.

Stealing someone's key/password is not a brute-force attack.

Re:Passwords are for philistines (4, Funny)

Brucelet (1857158) | more than 2 years ago | (#39601319)

It is if I break into your house and brute-force you to hand it over

Re:Passwords are for philistines (1)

nine-times (778537) | more than 2 years ago | (#39601687)

I'm not sure if you're kidding, but that's not what people mean by "brute force attack".

Re:Passwords are for philistines (0)

Anonymous Coward | more than 2 years ago | (#39601783)

Well, what if he breaks into every house on the block brandishing a LART and demanding "Gimme nine-times's ssh private key, and nobody gets hurt!", until he runs into nine-times himself and gets it?

I mean, in addition to seriously baffling the local PD, that would be a brute-force attack, no?

Re:Passwords are for philistines (1)

loufoque (1400831) | more than 2 years ago | (#39601425)

Someone cannot have something you are without you being aware of it.

Re:Passwords are for philistines (4, Insightful)

nine-times (778537) | more than 2 years ago | (#39601803)

That's nice in theory and all, but it depends on what that "something you are" is. Essentially we're talking about biometrics, so what are we measuring? Is it a thumbprint scan? Those have been defeated in the past by taking a thumbprint and replicating it by some means. Is it a DNA scan? Then they might just need to get ahold of your DNA.

Really, the "something you are" is still "something you have", but you "have" it attached to your body. That doesn't necessarily mean it can't be stolen or replicated somehow. Similarly, the "something you know" can also be considered to be "something you have", but you "have" it in your mind. In some circumstances, it can still be figured out or retrieved, or you might be tricked into providing it.

Real security isn't quite as simple as you make it sound.

Re:Passwords are for philistines (2)

mlts (1038732) | more than 2 years ago | (#39600541)

If the computer with the key is compromised, the game is over. The password can be slurped, the key snarfed, and even the session hijacked.

It is all about limiting exposure. Going to public keys closes a potential common method of access, brute force guessing.

No security method is 100%, but in a lot of cases, something is better than nothing, and having at least root locked out from password guessing is a must for Internet facing systems.

Re:Passwords are for philistines (1)

artg (24127) | more than 2 years ago | (#39601113)

You're assuming the loss is via a compromised computer. For me, the most likely loss of the key is laptop theft. So I want to ensure that isn't going to give an automatic login to the home machine. i'd prefer to have both key pair and password, but failing that I think password is preferable to key pair.

Re:Passwords are for philistines (1)

artg (24127) | more than 2 years ago | (#39601223)

Oh, wait, passphrase. duh.

Re:Passwords are for philistines (3, Interesting)

sexconker (1179573) | more than 2 years ago | (#39600691)

RSA key/pair is something you have... you still need something you are, and something you know... Once someone has your key, it's no more secure than your password. A trojan can read local files, just as easily, if not more so than snoop for a password.

When you send bits out, everything in those bits is "something you know".

You don't need to have the keyfob, you just need to know what it will output at any given time, or what a prior output was (as long as you use it within the time window for which it is valid - typically 30 seconds to 2 minutes). Yes, it's mathematically hard to get the key by brute forcing, but it's not impossible. When you log in with one of those, you're not proving that you have the thing, you're proving that you know what it output at a given time.

Imagine if PS4 games had built in RSA shits right onto game discs. (Or the Vita game cards if you can't imagine a thing battery, cpu, and display on a disc.)
Touch an area on the surface of the game disc (or card) and get a password on a little display. You have to put that password in within X time to access the game. This isn't secure because even if Bob holds onto the disc physically, Alica can call him up and ask him to read the code.

Sony wants the disc to be in Bob's physical possession (and no one else's) at any given time, but they cannot rely on this type of security to ensure that. For all they know Bob is visiting Alice and brought his new game over.

Re:Passwords are for philistines (1)

RichardJenkins (1362463) | more than 2 years ago | (#39600965)

Are you thinking of RSA SecurID? That is something quite different.

If you want to log in to my SSH server, then in practice you need a private counterpart to a public key which you have added to your authorized_keys file.

Re:Passwords are for philistines (1)

DamnStupidElf (649844) | more than 2 years ago | (#39602889)

Encrypt your private key with a passphrase that you know, which is a property of something you are (your brain). Nothing will protect you from local malware that can intercept your keystrokes. Even if you use a secure keyfob for your private key the trojan could just take over your session and execute commands on your behalf once you're securely connected.

Re:Passwords are for philistines (4, Interesting)

the eric conspiracy (20178) | more than 2 years ago | (#39600105)

Anyone see these guys on a port other than 22?

Re:Passwords are for philistines (3, Informative)

TheLink (130905) | more than 2 years ago | (#39600435)

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 (4, Interesting)

multimediavt (965608) | more than 2 years ago | (#39601253)

I made it just a different port on my router at home; still points to port 22 on the internal address forward. That way I can just turn sshd on (after configuring max tries to '3') and not worry about port fiddling on the machine. Works. Haven't seen many attempts at it since I did that years ago.

Re:Passwords are for philistines (4, Informative)

drosboro (1046516) | more than 2 years ago | (#39600441)

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 (2)

jandrese (485) | more than 2 years ago | (#39600677)

Wouldn't it be easier to just choose good passwords? The downside of port knocking is when you are using ssh because all of the other ports are blocked (including 80, thanks to your ISP).

This is probably not a solution if you have a bunch of users, but for a home machine it's not that hard to create a password that will never be guessed by some bot trying one dictionary word every 10 seconds.

Re:Passwords are for philistines (4, Informative)

JWSmythe (446288) | more than 2 years ago | (#39600787)

      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.

Re:Passwords are for philistines (2)

stackdump (553408) | more than 2 years ago | (#39600619)

Agreed! - this seems like the simplest tweak to bypass brute-force attacks -- After all why attack a server that isn't listening on port 22 when so many are?

Re:Passwords are for philistines (0)

Anonymous Coward | more than 2 years ago | (#39601455)

23 (sadly)

Re:Passwords are for philistines (2)

alanmeyer (174278) | more than 2 years ago | (#39601625)

Anyone see these guys on a port other than 22?

+1. Moving to a different service port dropped my failed login attempt logs down to nothing (at least, for now). Prior to that, my logs still weren't too big because I block IPs after #MAX_ATTEMPTS within a 24 hour window. However, the attempts were coming in at a rate of 10 minutes apart. Still, they got blocked. It's just that the hacking community seems to be well aware of trying to keep the number of attempts / unit time down to avoid detection.

Re:Passwords are for philistines (2)

v1 (525388) | more than 2 years ago | (#39602235)

RSA keypair auth, disable password auth, bruteforcers irrelevant.

I'd also recommend changing the ssh listener port to something else, to keep the secure.log a little cleaner and easier to spot possible issues in.

443 is a fun one, few if any of the ssh bots even consider that one.

Re:Passwords are for philistines (2)

nabsltd (1313397) | more than 2 years ago | (#39602467)

443 is a fun one, few if any of the ssh bots even consider that one.

The other advantage to 443 is that pretty much no ISP/WiFi provider/whatever will block access to that port, and since they expect to see encrypted traffic, they probably won't mess with the connection at all.

Seems Easy To Detect (0)

Anonymous Coward | more than 2 years ago | (#39600021)

Just look for large numbers of incorrect logins over a long-ish time span.

Re:Seems Easy To Detect (1)

aztracker1 (702135) | more than 2 years ago | (#39600099)

Never forgotten your password on a site have you... I'll usually try 5-6 times before I finally get it, or give up and hit the forgot password link.

Re:Seems Easy To Detect (0)

Anonymous Coward | more than 2 years ago | (#39600191)

Maybe so but there is a difference between 5-6 times in a half hour and a couple of hundred times.

Re:Seems Easy To Detect (4, Insightful)

TheRaven64 (641858) | more than 2 years ago | (#39601581)

The problem is that botnets have a lot of IP addresses. They can do one try from one machine then another from the next. If you disable the account entirely after a certain number of failed logins, you've just created a simple DoS attack. If you disable it just from that IP, it doesn't matter because it will just try from another. There are some realtime block lists that you can use to reject things, but these add another attack route that can let someone who can spoof DNS prevent you from logging in to your own machine...

set ban interval to 11 seconds. (2)

fincan (989293) | more than 2 years ago | (#39600041)

So, set your fail2ban or denyhosts configuration to 11 seconds intervals, and problem solved?

Re:set ban interval to 11 seconds. (1)

aix tom (902140) | more than 2 years ago | (#39600221)

Until they set the try interval to 12 seconds.

Re:set ban interval to 11 seconds. (2)

Tehrasha (624164) | more than 2 years ago | (#39600339)

5 fails in a row...ever.

Re:set ban interval to 11 seconds. (2)

Tehrasha (624164) | more than 2 years ago | (#39600379)

Additionally... automatically block any single attempt to login as root, admin, www, ftp, etc..

Re:set ban interval to 11 seconds. (1)

mlts (1038732) | more than 2 years ago | (#39600601)

What would be interesting is that if someone tries to log in as root with a password (as opposed to using a public key), rather than outright deny access, just make sure all access is denied from that IP or IP range, even if a future attempt at logging on would have normally been successful. This keeps the attacker busy thinking they can gain something.

Or, if someone is really clever, spawn a fake shell which drops to a prompt, then 1-2 seconds later, have it look like it got logged out.

Something like that widely distributed would be an effective poison, until the attack scripts started checking to see if the shell prompt is real or fake.

Re:set ban interval to 11 seconds. (2)

Tehrasha (624164) | more than 2 years ago | (#39600757)

just make sure all access is denied from that IP or IP range

Which is exactly what denyhosts and fail2ban do.
On failure, echo $IP:ALL >> /etc/hosts.deny

Re:set ban interval to 11 seconds. (0)

Anonymous Coward | more than 2 years ago | (#39600999)

I think what he meant was to allow them to keep attempting to log in but give the wrong username/password response regardless of whether it would work at all, rather than stop responding at all. My understanding is that fail2ban and denyhosts means that the server stops responding at all due to blocking at the firewall.

Re:set ban interval to 11 seconds. (1)

Samantha Wright (1324923) | more than 2 years ago | (#39601525)

Think more honeypottish. The defender's best tactic against an attacker is to deny the attacker knowledge of whether or not their break-in was actually successful: the more complex and bewildering you can make the fake prompt, the better. No one will try to brute-force a machine they think they already have access to.

Re:set ban interval to 11 seconds. (1)

mlts (1038732) | more than 2 years ago | (#39601657)

Exactly. If an attacker is running their stuff on some botnet clients, and gets reports that machines on a network all are accessible, it will waste their time and resources in having to vet each and every machine that reported a successful login.

It isn't a true honeypot because the machines are not giving much of an environment for an intruder to play around in, but more of a way to fool the brute forcing scripts in giving them a bunch of false positives.

Isn't that useless? (2)

khasim (1285) | more than 2 years ago | (#39600055)

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?

Re:Isn't that useless? (1)

PRMan (959735) | more than 2 years ago | (#39600177)

Also, you use logarithmically-increasing delays to both the username and the IP address (and to a lesser extent, range) that tries this. They won't be trying much for long. And no, I don't want people on zombie botnets coming to my site.

Re:Isn't that useless? (3, Funny)

girlintraining (1395911) | more than 2 years ago | (#39600207)

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?

You're thinking... this makes you a bad reference model for the average user.

Re:Isn't that useless? (1, Interesting)

damn_registrars (1103043) | more than 2 years ago | (#39600219)

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?

Yes, it would be obvious in the logs. However, most of the common hacks are now scripted and distributed. 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.

Although of course as you point out, it should fail if they are going for root or equivalent. 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. 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.

Thankfully, ssh generally returns the same password prompt for a valid username as it does for a nonexistent one, and the same wrong password response regardless of whether or not the username exists, so at least your system won't be giving them useful information on which usernames are worth trying again with other passwords.

But it still would not work. (3, Informative)

khasim (1285) | more than 2 years ago | (#39600571)

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:But it still would not work. (2)

colinrichardday (768814) | more than 2 years ago | (#39601145)

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).

Do you have your system set up so that email names are not user names?

Let me try to illustrate that. (Long post) (3, Interesting)

khasim (1285) | more than 2 years ago | (#39601879)

Do you have your system set up so that email names are not user names?

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.

Re:Let me try to illustrate that. (Long post) (1)

colinrichardday (768814) | more than 2 years ago | (#39602361)

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.

But you are being reactive. Wouldn't it be better to have the ssh user name different from the email name, and really different, so that it is difficult to deduce one from the other?

Re:Let me try to illustrate that. (Long post) (1)

khasim (1285) | more than 2 years ago | (#39602795)

But you are being reactive. Wouldn't it be better to have the ssh user name different from the email name, and really different, so that it is difficult to deduce one from the other?

Being completely non-related to your login ID is okay. I won't hurt anything by having it like that.

But it also won't add any additional security if you follow the other steps I've outlined.

It all comes down to the cracker being able to match (pretty much in order):
1. your SSH server
AND
2. legit username on that server
AND
3. matching password
AND
4. complete the crack before the sysadmin takes action to break the attack.

Note, 2 & 3 can be any authentication method used on that server. Including keys.

That is why, if your server gets cracked via Internet-based brute force SSH attack (not a 0-day exploit or compromised credentials or such) then it is the sysadmin's fault.

Re:Isn't that useless? (2)

Culture20 (968837) | more than 2 years ago | (#39600283)

That's 6 attempts per minute.

per zombie in the botnet. Each zombie IP gets banned individually, and the slow attack attempts prevents a DDoS.

Re:Isn't that useless? (1)

lambent (234167) | more than 2 years ago | (#39600447)

it's remarkably dumb, yes. but they don't need to attack specific targets, they're going after the lowest hanging fruit. they just need ANY attack to work, not EVERY.

very easy to mitigate against as you point out. but there are people out there who never get around to those steps, on account of being lazy.

Key AND Password (4, Interesting)

XanC (644172) | more than 2 years ago | (#39600125)

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?

Re:Key AND Password (1)

datapharmer (1099455) | more than 2 years ago | (#39600313)

If you are worried about that setup VPN with only access to ssh. Use a password for one and a key for the other. Otherwise, just keep your keys password protected and in a safe place. You can also restrict ssh/vpn to your IP address or a known range to limit the attack surface to locations you might actually be using to login. Add in fail2ban and a honeypot... wait why I am I telling you all this? If you are that worried just unplug it from the internet, don't use removable media and you will be fine!

Re:Key AND Password (1)

allo (1728082) | more than 2 years ago | (#39600395)

maybe with pam.

at least you can for example use password AND one-time-password with pam, which applies for ssh, too.
with OTP its more often used as password replacement (login from places where you do not trust the computer), but you can configure it as two-factor auth as well.

Re:Key AND Password (2)

heypete (60671) | more than 2 years ago | (#39600511)

Indeed.

Google Authenticator (which is an implementation of TOTP, and doesn't send anything back to Google itself) can tie in with SSH/PAM [google.com] quite easily.

Re:Key AND Password (3, Interesting)

allo (1728082) | more than 2 years ago | (#39600707)

yeah, or i once had a sshd with https://en.wikipedia.org/wiki/OPIE_Authentication_System [wikipedia.org] running. Nice thing, you generate a bunch of passwords and print it. Then you can login from everywhere without looking out for keyloggers.

Re:Key AND Password (2)

mlts (1038732) | more than 2 years ago | (#39600743)

Maybe even going back to the age-old S/KEY or OPIE protocol that has been part of BSD for 20+ years? This has fallen into disuse because it was mainly designed to foil packet sniffers, but might be a good way of doing things. Maybe modify the algorithm a little bit so it uses a modern hash, and perhaps add a random 4-5 digit number somewhere in addition to dictionary chosen words. That way, trying to brute force a pass phrase that will easily be more than 20+ characters will be almost impossible, especially with tarpitting, IP blacklisting, and locking an account out for 5-20 minutes if too many guesses are done wrong.

Re:Key AND Password (1)

Dr. Sp0ng (24354) | more than 2 years ago | (#39600773)

I use Google Authenticator on my home server (and on Google itself). It's a great solution to this problem and works very well. Some ssh clients (notably on iOS) can't handle the two-factor authentication, but I just set those up with private key authentication.

Re:Key AND Password (2)

What'sInAName (115383) | more than 2 years ago | (#39601157)

I use Mobile OTP (http://motp.sourceforge.net/) for two-factor auth at work. Once I figured out the PAM side of things, it was quite straight-forward. I installed it on my server at home as well, but I'm a little more relaxed about it -- I allow ssh from a few "trusted" boxes via ssh-keys, otherwise it requires password+OTP token authentication. Now, I just have to worry about keeping those "trusted" boxes safe. (I do have a password on the ssh keys, but wonder if I have a long-running login session with the keys installed into ssh-agent, I might be boned anyway if someone were to break in.)

Re:Key AND Password (1)

Qzukk (229616) | more than 2 years ago | (#39600515)

Non-Open-SSH has been able to require multiple authentication stages for some time now. Every now and then someone updates a patch for OpenSSH to do the same [mindrot.org] .

Re:Key AND Password (0)

Anonymous Coward | more than 2 years ago | (#39600543)

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?

Nope. Submit a patch, or use a token mechanism (RSA, OTP, Yubikey) hooked in PAM for two-factor auth.

Re:Key AND Password (0)

Anonymous Coward | more than 2 years ago | (#39600817)

You could put stunnel in front of your SSH port.

Re:Key AND Password (1)

marcosdumay (620877) | more than 2 years ago | (#39601311)

Why would you want that? If you fear somebody else getting hold of your key, put a password on it; if you fear your key is too short, make it longer.

Re:Key AND Password (3, Interesting)

XanC (644172) | more than 2 years ago | (#39601359)

There's no way for a server admin to require a passworded key for login.

Re:Key AND Password (0)

Anonymous Coward | more than 2 years ago | (#39602027)

I thought this was possible. The SSH protocol standard definitely supports it; after the first authentication it would issue a conditional fail (a fail message with the bool set to true indicating process was made) and after the second method, it should issue a succeed. Funny, now that I go to configure my SSH box like that, I don't see how to do it.

Or never... (4, Informative)

damn_registrars (1103043) | more than 2 years ago | (#39600135)

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.

I have a portknocking setup (5, Interesting)

ledow (319597) | more than 2 years ago | (#39600279)

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".

Re:I have a portknocking setup (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39600335)

Why go through all that just to leave your SSH server on port 22?

Details? (1)

gQuigs (913879) | more than 2 years ago | (#39600577)

Is there a package that includes this functionality or is it all custom done?

Re:Details? (4, Informative)

ledow (319597) | more than 2 years ago | (#39600639)

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.

Re:Details? (0)

Anonymous Coward | more than 2 years ago | (#39600721)

for ubuntu. http://linux.die.net/man/1/knockd

Re:I have a portknocking setup (1)

Gazzonyx (982402) | more than 2 years ago | (#39600597)

This is interesting. It's the first time I've heard of such a setup. How exactly do you have this setup in iptables? Is it just a chain that you jump to on the first port and return from on the last knocked port?

Re:I have a portknocking setup (1)

tocsy (2489832) | more than 2 years ago | (#39600669)

I don't know anything about networking, but that all sounded REALLY sexual.

Re:I have a portknocking setup (1)

mrnobo1024 (464702) | more than 2 years ago | (#39600673)

TCP port numbers are unencrypted so a serious attacker will be able to find out your sequence anyway. All you're doing is wasting your own time by making legitimate connections take longer.

Re:I have a portknocking setup (0)

Anonymous Coward | more than 2 years ago | (#39601043)

You can make it cryptographically strong and use one-time combinations. That means that the combination changes after every successful attempt and the algorithm that generates the sequence picks the ports essentially at random.

Re:I have a portknocking setup (2)

ledow (319597) | more than 2 years ago | (#39601249)

There are cryptographically secure versions. But you've missed the point.

This stops random port-spam, random brute-force attacks, and casual access. If you want something secure, you should SECURE it (e.g. by restricting access to the bare minimum necessary and provide only public-key authentication ONLY). You can do that AND add port-knocking, if you want.

But the spam on port 22 on an unsecured machine will flood your logs the second you put it on the net. Port-knocking stops that without having to touch a SINGLE configuration for all your services. And, if you want it to, it can be cryptographically secure in itself too, no matter what application sits behind it.

It's quite literally another level and a DIFFERENT level of security, above and beyond what you might usually deploy.

Re:I have a portknocking setup (1)

rastoboy29 (807168) | more than 2 years ago | (#39600879)

I had not heard of this--super interesting.

Question though: how is it fundamentally different from simply having a slightly strongly stronger public-key-only authentication?  Just the fact that that sshd doesn't get involved?

Re:I have a portknocking setup (2)

moderatorrater (1095745) | more than 2 years ago | (#39601065)

All your packets bounce when you touch my port 22 until you have touched a "magic sequence" of port numbers first

Using the old "ex-wife" model of security, eh?

Re:I have a portknocking setup (0)

Anonymous Coward | more than 2 years ago | (#39601259)

Uhh-huhuhuh...shut up, port-knocker. Huhuhuh-huh-huh.

Re:I have a portknocking setup (0)

Anonymous Coward | more than 2 years ago | (#39601423)

You were already 100% secure with your "Public-key-only authentication and no root logins allowed."
Portknocking is not actual security; it's just just e-peen.

Funny, I was tweakin' my firewall this morning (2)

grasshoppa (657393) | more than 2 years ago | (#39600285)

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 )

Re:Funny, I was tweakin' my firewall this morning (4, Insightful)

Culture20 (968837) | more than 2 years ago | (#39600803)

That's only useful if there's one attacker IP. TFA is talking about a botnet doing the attacking. Hundreds, if not thousands of IPs per minute. The only way to "protect" against that with iptables is to have iptables block all incoming on port 22 from any address. But then you're left with a DDoS where your ssh port is down nearly all the time. Same deal with locking accounts; if hundreds of attempts occur per minute, a lot of accounts can be locked out as a DDoS, intentionally or not.

So how much time to break a strong password? (2)

roman_mir (125474) | more than 2 years ago | (#39600397)

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.

Re:So how much time to break a strong password? (1)

allo (1728082) | more than 2 years ago | (#39600411)

rainbow-tables are not relevant for remote attacks.

Re:So how much time to break a strong password? (1)

roman_mir (125474) | more than 2 years ago | (#39600483)

I mean a dictionary attack.

Denyhosts (4, Informative)

Gaygirlie (1657131) | more than 2 years ago | (#39600645)

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:Denyhosts (1)

Anonymous Coward | more than 2 years ago | (#39601829)

+1 on denyhosts. If you use pubkey auth and denyhosts set to permanently lock out the IP of ANYONE attempting to login using passwords (you NEVER use passwords anyway) you don't have to worry about this stuff any more.

OpenSSH should block these (2)

psydeshow (154300) | more than 2 years ago | (#39600893)

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.

Re:OpenSSH should block these (0)

Anonymous Coward | more than 2 years ago | (#39601505)

How long does a port scan of all 65,536 ports take in nmap? Now, how many times can you try to brute force root on port 22 on somebody else's computer in the time that port scan took? Using a port like 65056 for sshd isn't *security*, in any real sense, in that it won't protect you from an APT, but it will shoo away the nuisance attacks.

Re:OpenSSH should block these (3, Informative)

subreality (157447) | more than 2 years ago | (#39602823)

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.

Tarpity them (1)

Tuipveus (815858) | more than 2 years ago | (#39601131)

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...

RFC6593 (1)

Anonymous Coward | more than 2 years ago | (#39601481)

It might solve the problem
http://tools.ietf.org/html/rfc6593 :-)

Using PAM pam_access to block hail mary (1)

Forever Wondering (2506940) | more than 2 years ago | (#39602631)

An alternate method is to add the PAM pam_access module to /etc/pam.d/sshd. You set up /etc/security/access.conf to allow logins from console, secure tty, and local LAN and deny all others. Each user's ~/.ssh/authorized_keys file has his/her public key from the systems they want to login from (e.g. each user sets up a separate key pair for each system they have and adds the public key from each key pair to authorized_keys)

---

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?