The section on openssh misses some things like ssh certificates:
SSH certificates are a CA type model for openssh, where you can trust one key, and anything it signs will be trusted, great for stuff like cloud/server deployments and reimaging, way way too many people either blindly trust new ssh keys, or just disable server fingerprint checking entirely, opening yourself up to trivial MITM attacks.
you can also restrict user keys themselves to a subset of ssh functionality, rather than trying to lock down individual users via ssh config etc.
You should be careful specifying an explicit list of ciphers/kex/key/etc acceptable algos, because the openssh defaults and included algos have changed with time, and by setting an explicit list, you will not get any new ones as they are added (for instance they have recently added experimental post quantum crypto support), nor will weak ones be removed. If you need to add options to connect to older servers that do not support newer, stronger crypto its recommended you prefix them with + so they are added in addition to the reasonably secure defaults, not replacing them.
The mozilla recommendations list also fails to mention that stuff like sftp can be chrooted, and other ssh functionality disabled so it functions more like a secure alternative to ftp, and less like a tool to run remote commands.
I don't see a link to the repository if we wanted to submit a PR.
Also might be worth mentioning that there is some alternative tooling to deliver multi-factor / single sign on and short lived certificates to SSH like teleport: https://github.com/gravitational/teleport
Disclaimer: I work for Gravitational, the company behind teleport
> [Do Not] Allow tools remotely executing code on systems from a centralized location (single Puppet Master, Ansible Tower, Nagios, etc. instance) across multiple services.
I wil stress a point made to IT Ops a few years back: Configuration Drift can be more of an organizational risk than a well audited single repo for configuration. A separate Puppet for each environment, or each datacenter, can be asking for trouble when you're asking admins to manually keep data in sync.
And if you automate the synchronization, what's the point of splitting it?
This part seems to be written by somebody who's never had under their care more
than a dozen of servers at a time. What's the alternative for managing
configuration across a modest hundred of servers if you de facto can't use
CFEngine/Puppet/Chef or deployment tools like Ansible?
They might want to add a page about not publishing their security guidelines for potential attackers to read and learn about potential gaps.
It's security through obscurity, sure. But if someone reads this and thinks there is indication of low-hanging fruit, they become a more tempting target.
On the other hand, by posting this, the organization will learn from the collective wisdom of anyone reading and providing comment (and perhaps any resulting other activity), so at least this has potential to provide improvement.
Awesome resource. Kubernetes sure is the hot thing right now, I just wish I had any excuse to use it.
Can anyone recommend a more general resource? Possibly something that covers a wider range of topics like intranets, VPNs, self-hosted servers, etc? I know someone who thinks he's all that but seriously needs to read more of this stuff.
He values private networks over SSL (as in public websites don't even have SSL), salts salts and decrypts stuff by looping through timestamps within a range close to the transmission, and more.
9 comments
[ 2.9 ms ] story [ 22.7 ms ] threadSSH certificates are a CA type model for openssh, where you can trust one key, and anything it signs will be trusted, great for stuff like cloud/server deployments and reimaging, way way too many people either blindly trust new ssh keys, or just disable server fingerprint checking entirely, opening yourself up to trivial MITM attacks.
you can also restrict user keys themselves to a subset of ssh functionality, rather than trying to lock down individual users via ssh config etc.
You should be careful specifying an explicit list of ciphers/kex/key/etc acceptable algos, because the openssh defaults and included algos have changed with time, and by setting an explicit list, you will not get any new ones as they are added (for instance they have recently added experimental post quantum crypto support), nor will weak ones be removed. If you need to add options to connect to older servers that do not support newer, stronger crypto its recommended you prefix them with + so they are added in addition to the reasonably secure defaults, not replacing them.
The mozilla recommendations list also fails to mention that stuff like sftp can be chrooted, and other ssh functionality disabled so it functions more like a secure alternative to ftp, and less like a tool to run remote commands.
Also might be worth mentioning that there is some alternative tooling to deliver multi-factor / single sign on and short lived certificates to SSH like teleport: https://github.com/gravitational/teleport
Disclaimer: I work for Gravitational, the company behind teleport
> [Do Not] Allow tools remotely executing code on systems from a centralized location (single Puppet Master, Ansible Tower, Nagios, etc. instance) across multiple services.
I wil stress a point made to IT Ops a few years back: Configuration Drift can be more of an organizational risk than a well audited single repo for configuration. A separate Puppet for each environment, or each datacenter, can be asking for trouble when you're asking admins to manually keep data in sync.
And if you automate the synchronization, what's the point of splitting it?
It's security through obscurity, sure. But if someone reads this and thinks there is indication of low-hanging fruit, they become a more tempting target.
On the other hand, by posting this, the organization will learn from the collective wisdom of anyone reading and providing comment (and perhaps any resulting other activity), so at least this has potential to provide improvement.
Can anyone recommend a more general resource? Possibly something that covers a wider range of topics like intranets, VPNs, self-hosted servers, etc? I know someone who thinks he's all that but seriously needs to read more of this stuff.
He values private networks over SSL (as in public websites don't even have SSL), salts salts and decrypts stuff by looping through timestamps within a range close to the transmission, and more.