
Enterprise Information Security (OpenSSH, IAM, Fundamentals, and More) - halfbrown
https://infosec.mozilla.org/
======
unethical_ban
Under Fundamentals > Principles > Isolation:

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

~~~
dozzie
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?

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

~~~
kangistaken
that is true, though contributions can be made (I mean, PR welcome!) it would
be a great addition there's also some basic scripts here
[https://github.com/mozilla-
iam/federated_access_proxy/tree/m...](https://github.com/mozilla-
iam/federated_access_proxy/tree/master/scripts)

~~~
kevin_nisbet
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](https://github.com/gravitational/teleport)

Disclaimer: I work for Gravitational, the company behind teleport

~~~
jonafato
There are "improve this document" links at the top of each of the pages (a bit
confusing, as that link doesn't really belong with the site navigation links).
e.g. the OpenSSH doc lives at
[https://github.com/mozilla/infosec.mozilla.org/blob/master/d...](https://github.com/mozilla/infosec.mozilla.org/blob/master/docs/guidelines/openssh.md).
It looks like the root project is
[https://github.com/mozilla/infosec.mozilla.org](https://github.com/mozilla/infosec.mozilla.org).

~~~
kevin_nisbet
Thanks... I completely missed it.

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

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

