CentOS - Jul 2015 - Fedora change that will probably affect RHEL

On Tue, Jul 28, 2015 at 11:27 AM, Warren Young <wyml at etr-usa.com>
wrote:
> Much of the evil on the Internet today ? DDoS armies, spam spewers,
phishing botnets ? is done on pnwed hardware, much of which was compromised by
previous botnets banging on weak SSH passwords.
>
> 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.

I can also use that logic with, password based auth by default, rather
than PKA by default.

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. In the autopsies of pwned computers is the quickly
provisioned server with a standard simple in-house password for such
things, with the idea that after configuration the password will get
changed or more likely sshd is disabled or it'll be added to firewall
filtering. The reality is all the bad practices happen because this
quickly provisioned machine is forgotten about for one reason or
another, and then it gets owned.

Well, disabling sshd after 7 days would stop all of that and yet
doesn't prevent initial configuration.

More likely, I think we'll see either sshd disabled by default or PKA
required by default, both being provisioned via Cockpit. And that's
because the minimum password quality under discussion is still rather
weak when it comes to being able to put a system directly on the
Internet or facing it with port forwarding while taking no other
precautions. 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.



-- 
Chris Murphy

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.

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

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

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.
> I think we'll see either sshd disabled by default
That wouldn?t break my heart, either.
> or PKA required by default
The main problem with that is that you need some way to install the client
computer?s public key into the authorized_keys file during initial setup.  You
don?t need password auth to be enabled to do that, but it would make things
considerably more difficult.

Meanwhile, *this* thread is about using 9+ character passwords that aren?t
laughably easy to break, which is not difficult.
> 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

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

On 07/28/2015 04:29 PM, Warren Young wrote:
> 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?
As far as I know, PermitRootLogin has not been set to "no" by default.
At least, I've never seen that on a system I've installed.  Am I missing
something?

On Tue, 2015-07-28 at 14:27 -0600, Chris Murphy wrote:
> The reality is all the bad practices happen because this
> quickly provisioned machine is forgotten about for one reason or
> another, and then it gets owned.
Linux users take a lot more care, and pride, in maintaining their
systems well and reading the daily logs too. Most increase security on
their machines. They have no wish to lose their work, their time and
effort investment and their increased Linux-enabled productivity.

If you want to offer advice and save the world from spam, viruses,
Trojans and other crap, please join a Windoze forum and make your
positive contribution there ;-)

Thanks,

-- 
Regards,

Paul.
England, EU.      England's place is in the European Union.

On 07/30/15 19:56, Always Learning wrote:
>
> On Tue, 2015-07-28 at 14:27 -0600, Chris Murphy wrote:
>
>> The reality is all the bad practices happen because this
>> quickly provisioned machine is forgotten about for one reason or
>> another, and then it gets owned.
>
> Linux users take a lot more care, and pride, in maintaining their
> systems well and reading the daily logs too. Most increase security on
> their machines. They have no wish to lose their work, their time and
> effort investment and their increased Linux-enabled productivity.
Not always. I bet you are. But I support a big group of scientists, and 
when choosing Linux for laptop they usually pick Ubintu. Guess why? 
Because all just works, no need to invest (waste actually) their 
precious time into fiddling with the system. They can just do their 
science. I don't intend to blame anybody for what or how they do. I just 
would like everybody to realize the reality.

Valeri
>
> If you want to offer advice and save the world from spam, viruses,
> Trojans and other crap, please join a Windoze forum and make your
> positive contribution there ;-)
>
> Thanks,
>
-- 
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++