Standing up a service, getting a handle on controlling key distributions, and configuring things to make life easier are all great, but there may be restrictions on what you can and can not do in your environment. These are sometimes imposed by outside bodies, not just corporate policy.
For example, Payment Card Industry standards (PCI), National Institute of Standards and Technology Internal/Interagency Reports (NISTIR), and the various governance requirements from Sarbanes Oxley (SOX), ISO 27001, and so on all give broad guidelines for server hardening. Some of them get less broad (more specific) such as the up and coming PCI DSS requirement to have multi-factor authentication. Whatever your requirements, you should get intimate with the policies that define what you must, may, and must not do, whether they are internal corporate policies or broader reaching standards body policies such as listed above.
We’re going take a quick look at PCI DSS today, and briefly also mention NIST IR 7966 which deals with SSH Key Management.
Whether it is required in your environment or not, I recommend at least a good once over of the NIST IR 7966 document. Sections 4 and 5 are useful in helping to understand the magnitude of a poorly designed SSH deployment. For example:
Most importantly, SSH key-based trust relationships can enable an attacker who compromises one system to quickly move (or pivot) from one system to another and spread through an organization—individual trust relationships often collectively form webs of trust across an organization’s systems.
Imagine an attacker gains access to a little used server. A lazy systems administrator generated a public private key pair there, and sometimes uses it to bounce to other servers in the same subnet, but isn’t really supposed to do that. Now the attacker gains root, and rummages in home directories looking for anything juicy. SSH keys are definitely juicy. A quick perusal of known_hosts and attempt after attempt come up gold when testing this private key that was discovered. Because the admin didn’t lock down the public key at the end points, the private key would work from anywhere. The attacker makes a copy for himself, and goes about his business.
Attackers tend to think in “graphs.” Defenders tend to deal with lists of assets. Yes, those are best organized as graphs, but most defenders don’t treat them that way. A “graph” is organized by a “source” asset, a vector (direction), and a “target” asset that can be affected by that source. Trust relationships are graphs by nature. “Tom” on “Workstation_A” can log into “Tom” on “Server_B.” But “Tom” on “Server_B” can’t log into “Tom” on “Workstation_A.” The trust is one way. Some trusts will be bidirectional. Mapping these trusts is how attackers are able to plant deep roots into a compromised network.
As for the PCI requirements mentioned before, a new requirement is coming that sets up a policy of required multi-factor authentication. In the Scoping and Segmentation guidance document, we can find an example of using a Jump Box for accessing the sensitive systems where we don’t want to apply multi-factor authentication directly to those systems. That jump box is required to run its own firewall as part of hardening of the system. This is called a “bastion host.” The systems administrators are heavily restricted in how they can manage that host, per the rules laid out. An excellent example of a company that is already doing a Jump Box work flow utilizing SSH Certificate Authorities that get generated via the work flow is brought to us by Facebook.
This article shows how they are using it to meet these PCI (or similar) requirements, but are still able to maintain a high level of efficiency in their daily administrative tasks. Pay close attention, because they also talk about “zones” in their set up. You may or may not want to try something similar if you need to stand one up for your company.
Another requirement from that same PCI document is for ONE of the authentication factors to be “something you have.” It requires some kind of security token. I’ve used several in my career. Some are as simple as “my phone” using a one time pad software app. Other have been as complex as a RADIUS token that kept a one time pad for each VPN login session.
Since I’ve been researching how to best incorporate tokens into an SSH deployment, I settled on making my first purchase for the lab a Yubikey 4. It arrived in the mail over the weekend, and next Monday will cover how to get it working for ssh public key authentication.
I also want to take the time to thank 0ddn1x and TechRights for the recent pingbacks. I meant to include a shout out last week, but I was up late, got frustrated with the recording situation, and frankly, forgot.
The new recording should be available this week. (Probably Tuesday.)