Bug in widely used OpenSSH opens servers to password cracking • Hacker News Board

Re: Bug in widely used OpenSSH opens servers to password cracking

#51

Post by anonova » Wed, Jul 22, 2015, 3:58 AM UTC

scintill76 wrote: post #50

anonova wrote: post #41

Earlier quoted context omitted.

I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`. * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes * openSUSE 13.2 (openssh 6.6p1-5.1.3):…

Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I lo…

Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros.

So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`."

Thanks for the correction!

Re: Bug in widely used OpenSSH opens servers to password cracking

#52

Post by scintill76 » Wed, Jul 22, 2015, 4:42 AM UTC

anonova wrote: post #51

scintill76 wrote: post #50

Earlier quoted context omitted.

Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I lo…

Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros. So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`." Thanks for the correction!

Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point.

I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default.

[1] https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26

Re: Bug in widely used OpenSSH opens servers to password cracking

#53

Post by noinsight » Wed, Jul 22, 2015, 6:04 AM UTC

tedunangst wrote: post #28

noinsight wrote: post #25

Shouldn't effective brute forcing be prevented by the fact that this should be completely choking the server? I'm not completely sure what algorithms are currently used for password hashes in UNIX-likes but in any case, shouldn't this choke the server when it has to generate hashes for all those attempts at once (or consequently)? If you monitor loads at all this is very detectable. It's a good avenue for DDOS in tha…

Heh. I noticed a blistering two guess per second hacking attempt against my laptop because the fan went full jet engine.

So on OpenBSD the hashes are bcrypt and rounds are based on system performance as per man crypt_checkpass?

So it's like 15 bcrypt rounds on average hardware for ~500ms per hash?

Linux seems to use a pathetic 5000 rounds of SHA-512: http://www.akkadia.org/drepper/SHA-crypt.txt

Re: Bug in widely used OpenSSH opens servers to password cracking

#54

Post by rlpb » Wed, Jul 22, 2015, 8:35 AM UTC

zacharydanger wrote: post #6

Someone1234 wrote: post #4

Earlier quoted context omitted.

It is all fun and games until you ban yourself for a couple of million seconds... Far too many people ban themselves with fail2ban.

Sharp tools are sharp.

Why are you using a circular saw to cut your fingernails?

Re: Bug in widely used OpenSSH opens servers to password cracking

#55

Post by thraxil » Wed, Jul 22, 2015, 8:59 AM UTC

ryanlol wrote: post #42

DrTung wrote: post #3

Earlier quoted context omitted.

Have you tried fail2ban? It really helps to keep the hacking attempts down on your ssh-server(s), especially if you increase the bantime from the default 600 seconds to a couple of million...

What's the point of fail2ban (for ssh)? It definitely won't stop you from getting hacked, nor will it provide any useful data. Especially since any sane bruteforcers iterate over IP addresses instead of passwords to avoid just this.

It's useful as part of a layered strategy. Your passwords still need to be secure enough that they can't be guessed easily. If they're easily brute-forced, fail2ban might slow things down, but it won't stop it.

Once you have that though, fail2ban does do a nice job of making the perpetual brute force attacks significantly less obnoxious. I've seen machines effectively DDoSed by brute-force ssh attempts, either with the network overloaded or filling up disk with ssh's logs of the failed attempts. Not as bad as getting hacked, but still annoying. A serious botnet attack will be able to spread it over thousands of IP addresses, but IME, those are relatively rare. Most attacks are still coming from a handful of hosts at a time and fail2ban basically stops them dead in their tracks.

The other useful thing to do with fail2ban is to use it along with a whitelisted range of networks. Even if you aren't on a private network, not every server needs ssh open to the entire world. You can often get away with whitelisting the local network and maybe a few ISPs' ranges where admins are likely to access it from. I run fail2ban even on machines on private networks. If one of the other machines gets hacked, one of the first things they'll usually do is start trying to brute-force other machines on the network. Since it will probably only be a couple compromised machines, fail2ban is useful here.

I find that it does also give me useful data as well. Eg, I have simple graphite metrics based on the number of bans/minute. If it gets unusually high, I can get an alert and perhaps notice that other hosts have been compromised, or do a quick firewall rule or two to drop packets from an entire network for a while.

Re: Bug in widely used OpenSSH opens servers to password cracking

#56

Post by mbubb » Wed, Jul 22, 2015, 9:56 AM UTC

stephen-mw wrote: post #23

Some quick tips for securing SSH: 1. Disable password authentication altogether 2. Create and use keypairs 3. Add an "AllowUsers foo" line to /etc/ssh/sshd_config so that only your user is allowed to SSH 4. Install sshguard or fail2ban and set the ban limit to a week There are other things you can do, but I find this to be the lowest hanging fruit for the best security.

I am curious as to why DenyHosts is not mentioned in this context (beside fail2ban and sshguard. Is its use deprecated?

I ask because I administer about 300 servers with DenyHost grandfathered on the servers. I've googled a bit to see the relative merits and DH is just for ssh whereas fail2ban is more general.

I somehow didn't know about sshguard - it looks interesting (and also seems to do more than just ssh brute force blocking).

So... do I need to take DH off the herd and replace?

Re: Bug in widely used OpenSSH opens servers to password cracking

#57

Post by rc4algorithm » Wed, Jul 22, 2015, 2:43 PM UTC

kazinator wrote: post #44

praseodym wrote: post #12

Earlier quoted context omitted.

Recent Google Cloud Engine images have Sshguard enabled by default. Now I do wonder: does this 'exploit' still cause a log line immediately after each attempt? And also, do iptables firewall rules also apply to open connections, or just to new ones? In the latter case, Sshguard and fail2ban are circumvented for a rather high number of attempts.

iptables rules can (trivially) apply to all traffic, or they can be sensitive to connection state. In the case of cracking, you'd just want to apply a blanket blan: completely black-hole any packet whatsoever coming from that IP to your box. That will freeze all existing connections. To ban new connections, you'd have a rule that applies to TCP connections in the NEW state, leaving the ESTABLISHED ones alone.

In many cases, this is a bad idea. For example, this is eventually equivalent to blocking Tor. I've been dealing with this issue lately.

Re: Bug in widely used OpenSSH opens servers to password cracking

#58

Post by e40 » Wed, Jul 22, 2015, 4:05 PM UTC

stcredzero wrote: post #19

e40 wrote: post #10

Earlier quoted context omitted.

But what does deter them is port knocking. We went from many attempts per hour to not a single one since adding port knocking to our firewall. Port knocking has been mentioned before on HN and it generally gets a luke warm to negative response. It completely baffles me, this response.

It's just caution. Using port knocking by itself would be a recipe for security disaster. As an addition to an already secure system, it's okay if you just want to reduce junk in your logs, perhaps. Many would ask, in that case, why use port knocking at all?

The is the usual thing I hear. It is so incredible naive, though.

Any service, no matter how locked down and properly configured, still presents an attack surface. SSHD is a program like any other, and it can have bugs.

When you use port knocking with a properly configured SSHD, you are much more secure because that attack surface has been removed.

Re: Bug in widely used OpenSSH opens servers to password cracking

#59

Post by sliken » Thu, Jul 23, 2015, 3:46 AM UTC

segmondy wrote: post #36

rascul wrote: post #20

Disable password auth and ensure you have another way in if necessary. Fail2ban, changing ports and port knocking doesn't really add anything more unless you're concerned about log sizes, and just increases the hassle for you. Mozilla's wiki has some information on strengthening the security of your OpenSSH setup. https://wiki.mozilla.org/Security/Guidelines/OpenSSH

what do you mean by port knocking doesn't really add anything? It sure does. Use a good port knocker. ie. http://www.thoughtcrime.org/software/knockknock/

It adds no security. Assuming you use keypairs the attacker either has your private key or he doesn't. If they compromise your client to the point of having your private key they are likely to have access to whatever port knocker magic you have in place.

Re: Bug in widely used OpenSSH opens servers to password cracking

#60

Post by sliken » Thu, Jul 23, 2015, 3:48 AM UTC

e40 wrote: post #10

orf wrote: post #2

It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.

But what does deter them is port knocking. We went from many attempts per hour to not a single one since adding port knocking to our firewall. Port knocking has been mentioned before on HN and it generally gets a luke warm to negative response. It completely baffles me, this response.

Seems like quite a bit of work to avoid a few connections an hour. Are you paying $0.01 per byte for syslog entries or something?

Who cares about a few connections per hour if the sun will die before they brute force your private key?