I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?
The defaults assume your appetite for security risk is much greater than your appetite for interop failure.
Imagine two products that could easily exist, almost the same features:
A by default works just fine, but there's a risk an adversary spends $10M to attack you. You can tweak the config and replace all the OmniCorp CheapDevices in your estate to get rid of that attack which is best practice.
B by default requires that you replace all the OmniCorp CheapDevices in your estate or it won't work. You can tweak the config and risk that an adversary spends $10M to attack you so that the OmniCorp CheapDevices still work.
Which one do you buy? You buy A of course. Nobody is going to sign off on the budget to replace all the OmniCorp CheapDevices. What's this nonsense about a $10M attack anyway?
At some point the risk is judged to be too high, and people flip the defaults for those risks. For example OpenSSH decided the risk for SHA1 authentication is now too high, like the Web PKI had years before, but despite SSH being a much less plausible target than the Web PKI for various reasons.
Which ones aren't secure by default? When you install new OS like Debian those defaults will be correctly set (and depending on your organization, you may change some settings around to fit your needs).
However, if you customized your config e.g. in debian 6 and updated to 11, you may wanna revisit those settings and change them
Not really SSH, but Kerberos on many distros allows extremely weak ciphers by default. And when I say weak, I mean these should have been disabled a decade ago. On Ubuntu 20.04 with the default setup, keytabs using DES are allowed...
Not sure about that, but from my understanding that's because with kerberos the encryption level doesn't matter as much because cracking DES from such a small amount of bytes still shouldn't be feasiable
I don't think the defaults are bad. I think the defaults are generic. And I don't have a generic machine. Nobody has. Old SSH clients don't need access to my server. So I think it is a good idea to remove old cyphers.
The defaults support the largest number of client SSH implementations. If you're doing a de novo SSH implementation, you can almost certainly just support the newest clients, and thus get a better config.
I'm pretty sure some of those are on by default (PermitEmptyPasswords). Some others don't have a sane general setting (AllowUsers) or depend completely on your local environment (KerberosAuthentication). Some are compatibility issues (PasswordAuthentication, cypher selection). And finally, some are ... more controversial than defaults should be (Port, PermitRootLogin).
The software authors can’t change the default settings, since many users have config files where a setting isn’t specified, and these users would, when they upgrade, get an unasked-for change, which might break their workflow. The software authors can change the defaults in major version releases, but even that is frowned upon by those who would be affected by the change. Therefore, this usually does not happen until a real security issue is caused by the old state of things.
The downstream package maintainers for various operating systems or distributions have some more leeway in changing the defaults, but here, also, they have to bow to the impact which a change might have on real-world users. Indeed, since these package maintainers are closer to the actual affected end users, it has been known to happen that upstream authors have changed a default value to be more secure, but the real-world impact has been so large that the package maintainers have reverted this change in the packaged versions of the software, essentially making the software more insecure in the name of compatibility. So, package maintainers are more flexible, but are also more beholden to the wishes of users who might be adversely affected by any changes.
the problem is a lot of the "disable asap" steps require a step before that so the machine is still accessible afterwards (such as adding a non-root user before disabling root login, adding an authorized key before disabling password login, etc)
Comments
I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?
The defaults assume your appetite for security risk is much greater than your appetite for interop failure.
Imagine two products that could easily exist, almost the same features:
A by default works just fine, but there's a risk an adversary spends $10M to attack you. You can tweak the config and replace all the OmniCorp CheapDevices in your estate to get rid of that attack which is best practice.
B by default requires that you replace all the OmniCorp CheapDevices in your estate or it won't work. You can tweak the config and risk that an adversary spends $10M to attack you so that the OmniCorp CheapDevices still work.
Which one do you buy? You buy A of course. Nobody is going to sign off on the budget to replace all the OmniCorp CheapDevices. What's this nonsense about a $10M attack anyway?
At some point the risk is judged to be too high, and people flip the defaults for those risks. For example OpenSSH decided the risk for SHA1 authentication is now too high, like the Web PKI had years before, but despite SSH being a much less plausible target than the Web PKI for various reasons.
Which ones aren't secure by default? When you install new OS like Debian those defaults will be correctly set (and depending on your organization, you may change some settings around to fit your needs). However, if you customized your config e.g. in debian 6 and updated to 11, you may wanna revisit those settings and change them
Not really SSH, but Kerberos on many distros allows extremely weak ciphers by default. And when I say weak, I mean these should have been disabled a decade ago. On Ubuntu 20.04 with the default setup, keytabs using DES are allowed...
Not sure about that, but from my understanding that's because with kerberos the encryption level doesn't matter as much because cracking DES from such a small amount of bytes still shouldn't be feasiable
I don't think the defaults are bad. I think the defaults are generic. And I don't have a generic machine. Nobody has. Old SSH clients don't need access to my server. So I think it is a good idea to remove old cyphers.
Staying ahead of the pack.
The defaults support the largest number of client SSH implementations. If you're doing a de novo SSH implementation, you can almost certainly just support the newest clients, and thus get a better config.
I'm pretty sure some of those are on by default (PermitEmptyPasswords). Some others don't have a sane general setting (AllowUsers) or depend completely on your local environment (KerberosAuthentication). Some are compatibility issues (PasswordAuthentication, cypher selection). And finally, some are ... more controversial than defaults should be (Port, PermitRootLogin).
The software authors can’t change the default settings, since many users have config files where a setting isn’t specified, and these users would, when they upgrade, get an unasked-for change, which might break their workflow. The software authors can change the defaults in major version releases, but even that is frowned upon by those who would be affected by the change. Therefore, this usually does not happen until a real security issue is caused by the old state of things.
The downstream package maintainers for various operating systems or distributions have some more leeway in changing the defaults, but here, also, they have to bow to the impact which a change might have on real-world users. Indeed, since these package maintainers are closer to the actual affected end users, it has been known to happen that upstream authors have changed a default value to be more secure, but the real-world impact has been so large that the package maintainers have reverted this change in the packaged versions of the software, essentially making the software more insecure in the name of compatibility. So, package maintainers are more flexible, but are also more beholden to the wishes of users who might be adversely affected by any changes.
the problem is a lot of the "disable asap" steps require a step before that so the machine is still accessible afterwards (such as adding a non-root user before disabling root login, adding an authorized key before disabling password login, etc)