Live data from Hacker News

Bug in widely used OpenSSH opens servers to password cracking

arstechnica.com

41–50 of 62 posts

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

#41

Earlier quoted context omitted.

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

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): #PermitRootLogin yes
  * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password
  * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password

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

#42
post #3
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.

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.

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

#43
post #34

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.

> There are other things you can do, but I find this to be the lowest hanging fruit for the best security. During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s

What actual benefits does changing the port offer?

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

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

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.

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

#45
post #43
post #34

Earlier quoted context omitted.

> There are other things you can do, but I find this to be the lowest hanging fruit for the best security. During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s

What actual benefits does changing the port offer?

Usually automated bulk (non-targeted) hacking tools don't like to spend time looking for services on non-standard ports. I get zero ssh hack attempts on my machines ever since I changed to a non-standard port vs 100s of attempts everyday previously on standard ssh port.

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

#46
post #43
post #34

Earlier quoted context omitted.

> There are other things you can do, but I find this to be the lowest hanging fruit for the best security. During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s

What actual benefits does changing the port offer?

It stops your log from filling up with half-assed attempts to break in.

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

#47
post #41

Earlier quoted context omitted.

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

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):…

[deleted]

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

#48
post #41

Earlier quoted context omitted.

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

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):…

[deleted]

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

#49
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/

Use the stuff from that Mozilla wiki page and OpenSSH will be secure enough already. Unless more vulnerabilities are found that apply to such a configuration, or keys are compromised, port knocking in this case isn't going to stop anyone that OpenSSH wouldn't already stop on its own. It's effectively just a pointless layer of security that only adds more hassle to connect.

I'm not saying that port knocking doesn't have uses, just that it doesn't in this case. Unless you're trying to hide the service I guess, but I don't see why that would be necessary.

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

#50
post #41

Earlier quoted context omitted.

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

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 looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing.

[1] http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6...

Post reply on HN