[CentOS] Fedora change that will probably affect RHEL

[Chris Murphy]

On Tue, Jul 28, 2015 at 5:29 PM, Warren Young <wyml at etr-usa.com> wrote:
> On Jul 28, 2015, at 2:27 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>
>> On Tue, Jul 28, 2015 at 11:27 AM, Warren Young <wyml at etr-usa.com> wrote:
>>
>>> Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines.
>>
>> Your freedom to have sshd enabled by default stops at the point where
>> exercising that freedom creates risk to other people's machines.
>
> You’re offering a false choice.  We do not have to choose between cutting the tree down or leaving the fruit to rot on the twig.  Fedora is rightly choosing to pick this low-hanging fruit.

Disabled by default is in no way cutting the tree down. It happens to
be the default on Fedora Workstation. While Fedora Server currently
leaves it enabled, there has been some discussion of disabling it by
default when Cockpit has a switch for enabling it, and then expect it
to be enabled there - that way it's opt in rather than opt out. And
the problem with opt out is a lot of users don't know this service is
running and exposes them to infiltration unless they have a strong
passphrase or use PKA.


> If you want a Linux distro that doesn’t ship with sshd enabled by default, that is already available.  Given that CentOS does ship with sshd enabled by default, it makes sense that it should not allow itself to be so badly misconfigured that it allows trivial exploits.

Well that's rather difficult for it to know the environment it's in,
which is why there's such a thing as defaults. Many people have no
idea sshd is enabled by default, meanwhile everyone could voluntarily
choose stronger passphrases. Opt out vs opt in, and opt in assures the
person doing the setup is making a conscious decision.



>> I can also use that logic with, password based auth by default, rather
>> than PKA by default.
>
> That’s more low-hanging fruit; we might get there someday.

That requires UI work and coordination seeing as it requires a service
made active on one computer and keys made on each computer that will
access that server, and then a mechanism to securely transfer the pub
key to the server. This is non-trivial.



>
> They turned off "PermitRootLogin yes" and "Protocol 1" in EL6 or EL7, the previous low-hanging fruit.  Do you think those were bad decisions, too?

Disabling Protocol 1 is a good decision because it negatively impacted
essentially no one with sane workflows. The disabling of root I don't
disagree with but I think it's specious.


>
>> A rather strong argument can be made, much more so than a very weak >
>> weak password quality policy, for sshd on a default 7 day disable
>> timer. That is, by default, after 7 days, sshd is stopped and
>> disabled.
>
> The stock PAM on-fail delay is about 2 seconds.  I can’t see that sshd has any rate-limiting built into it, but it does limit the number of unauthenticated connections to 100 by default in EL7.  Together, this means a small botnet could try 50 guesses at a single account’s password per second.
>
> The current non-policy allows abc1 as a password.  According to:
>
>   https://www.grc.com/haystack.htm
>
> …that password can be brute-forced in about half an hour at 1000 guesses per second, or 4 days at 50/sec.  Your 7-day window is too short, if you don’t institute *some* kind of password quality minima.

It was a number I pulled out of my ass, but it's still better than
infinite. The proper value in this case is not one that always assures
are particular passphrase won't be brute forced, but one that's high
enough that the sysadmin leaves the timer feature intact, while low
enough to thwart a non-targeted attack. If you're targeted, you're
probably screwed short of a rather strong passphrase or PKA.

Of course, both iptables and firewalld also have rate limiting
options. Maybe fail2ban is better because it can apply restrictions
per IP so that legitimate attempts get through. I didn't realize PAM
has a fail delay, that actually matters.



>
> Also keep in mind that the GRC calculator is assuming you’re brute-forcing it, and not intelligently trying common passwords first, and sensible variations.
>
> The stock rules currently allow “monkey” as a password, which the GRC calculator considers stronger than “abc1” due to the length, but it’s a top-10 most-used password, so it will be among the first to be tried by any intelligent attacker.

So now the problem with this type of policy enforcement in a GUI is
you have to create instructions for the user to follow in order to
successfully pick a minimally acceptable passphrase without iterating.
Iteration means failure.

And no OS does this right now. Everyone is completely permissive
because no one wants to replicate a UI across completely different
applications: the installer, Gnome Initial Setup, and Gnome Users &
Groups.

I still think informed consent is the way this will probably end up
working - meaning the user is informed their password is common
(dictionary word, derivative, or a top 10,000 most common password)
should not be used but give them a way to use it anyway.


>> And yet the weak password policy is too strong for many
>> legitimate use cases where the use case/environment aren't high risk
>> for such passwords.
>
> Really?  Which of these new rules is onerous?
>
>   http://manpages.ubuntu.com/manpages/trusty/man8/pam_pwquality.8.html

All of them. Those rules are absurd to require by default on a
computer in a low risk environment. I would never accept such a
product that required such login rules.



-- 
Chris Murphy