Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug in widely used OpenSSH opens servers to password cracking

arstechnica.com

Post reply on HN
Print view View original

31–40 of 62 posts

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

#31

Post by jamestnz »

marcosdumay wrote: post #22
currysausage wrote: post #13

Earlier quoted context omitted.

Note that Fail2ban doesn't support IPv6 at all [1]. I'm currently using sshguard [2] instead. Edit: Thinking about it, I guess that blocking single IPv6 addresses, as sshguard does, doesn't really help at all, as it's easy to obtain huge subnets. (This might even open the door to an iptables DDoS?) Blocking whole subnets, on the other hand, doesn't sound clever either. (Who knows how many users are sharing the same s…

I'm very curious about IPv6 banning best practices. I imagine banning /64 networks is completely harmless, but I'm not really confident on that. I'd be wary of banning anything bigger, but getting a bigger address range is very cheap, so that may be required. I've recently written a banning layer over my email server, in case somebody tries to guess the computer's passwords. It's a certainty that an attack exploiting…

I think /64 would be the correct subnet size to ban in most cases.

My understanding is that /64 has become the de-facto standard subnet size for IPv6 sites. For example, I think that most home and business internet connections would be likely to receive a /64 allocation from their provider.

Moreover, many times the hosts will be generating themselves a new random address (within the /64) from time to time. So blocking a single IPv6 address probably won't block the user for long.

Conceptually, whenever a site (or hosted server, etc) would have been allocated a single address (/32) under IPv4, I think the analogous allocation for IPv6 is a /64, i.e.: 1.8 x 10^19 addresses.

If you look at RFC5375, you can see why /64 would be common:

- "An allocation of a prefix shorter then 64 bits to a node or interface is considered bad practice..."

- "Using subnet prefixes shorter than /64 would rarely be useful..."

- "Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea..."

- "Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery, Secure Neighbor Discovery, privacy extensions, parts of Mobile IPv6, PIM-SM with Embedded-RP, and Site Multihoming by IPv6 Intermediation, among others."

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

#32

Post by nly »

noselasd wrote: post #15
nly wrote: post #9

Earlier quoted context omitted.

Never seen the need for fail2ban when you can do the same thing with a couple of iptables rules.

Mind sharing those ? (Or do you mean you add them manually at each attempt ?)

You can rate limit connections and connection rate with the iptables connlimit module[0]. What exactly does fail2ban gain over this?

[0] http://www.cyberciti.biz/faq/iptables-connection-limits-howt...

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

#33

Post by thaumaturgy »

scintill76 wrote: post #30
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 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...

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

#34

Post by joeyspn »

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.

> 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

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

#35

Post by protomyth »

thaumaturgy wrote: post #33
scintill76 wrote: post #30

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

Just got set to the default on OpenBSD, so it should be shipped in 5.8.

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

#36

Post by segmondy »

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/

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

#37

Post by this_user »

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.

Here is a pretty good guide for configuring SSH in a secure way that also goes into detail regarding the crypto side: https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

You probably also want to set kex, ciphers and MAC preferences in your client config for when you connect to servers with suboptimal settings.

Personally, I have also moved away from RSA keys and prefer using Ed25519 ones instead.

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

#39

Post by user_0001 »

nly wrote: post #9
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...

Never seen the need for fail2ban when you can do the same thing with a couple of iptables rules.

Just as easy to block yourself from the server with iptables as well ;-)

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

#40

Post by kazinator »

Someone1234 wrote: post #4
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...

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

I rolled my own log-monitoring solution. I have it so that there have to be N unsuccessful attempts in M seconds. There are multiple such thresholds (different combinations of N and M) with different banishment periods. The system will react to an acute flood, like when > 30 attempts are made in just a few seconds, say (which you would never do if you're clumsily mis-typing your password). The software also discriminates whether the same account is being tried multiple times, versus different accounts. If the same client IP address is trying different user ID's, it will be banned more easily than a client trying the same account. Someone trying three or more accounts is almost certainly an intruder, since a legit user on my system knows at most two accounts: their personal one and possibly root. Trying root is punished more swiftly than non-root, also. All these inputs contribute to a score, and the score determines the position on the banishment scale which translates to a period.

Oh, and a successful login will clear the record: the software scrubs all records of that IP from its cache, so then if you make new logins from the same IP with mistyped passwords, you're starting with a clean slate.

I've never locked myself out.

Post reply on HN