Controlling SSH for Security and Compliance

SSH is nearly ubiquitous in today’s enterprises, and is the predominant tool for managing unix and linux servers, and the applications and data that they host. Poor practices around the deployment and management of the SSH infrastructure could easily leave your enterprise vulnerable to a breach. Are you in control?

SSH, Secure Shell protocol, is now nineteen years old and broadly deployed across almost every enterprise server and PC in your organization. It is also widely implemented in home networking broadband modems and routers, digital TV set top boxes, DVD players, tablet computers, smart phones, and (although not an advertised feature) even in-car entertainment and engine management systems, including inside the electric Tesla car.

SSH provides for a secure connection and transport protocol for user and machine-to-machine (M2M) sessions. This means the SSH suite is a must-use toolkit for your system admin and support staff. Often this involves enabling access to higher privileges to perform administrative tasks, or to access specific servers that house sensitive information. The compromise of an account with any privileged access can shut down applications, expose data in that one environment, and become a launching off point to expose other critical systems on your network to attack. The loss of sensitive information that an enterprise is bound by regulation to protect is costly to repair, and will cause enormous damage to both your team’s and company’s reputation.

Like any service that allows a remote host or device to connect to a computer, SSH can be attacked or abused. Compromise of a system via SSH often happens by attacking the authentication required to connect. This can be achieved using a stolen password or pass phrase, and is frequently combined in association with stolen SSH keys.

SSH does allow for some basic controls over how it is used. The SSH service runs on each computer, however it is typically controlled by local configuration text files. Each system that is running SSH has its own edition of configuration files that define:

• how the service is offered
• how connections can be established
• how a connection can be authenticated
• and to a degree, who has access

The configuration of the various SSH services are the rules that are enforced when someone, or something, tries to connect. Unfortunately, systems and application administrators, who are required to have access to your critical infrastructure that hosts your most sensitive data, can easily abuse their privilege and change the rules. If the rules are “on paper,” and not enforced by central management, your staff can ignore the rules. Unmanaged without enterprise-wide controls, SSH is the recipe for a nightmare scenario.

A recent study has declared that administrators and end users are leaving back-doors open for SSH protocols for accounts that provide Linux root or Windows Administrator access to almost every server, virtual machine, and cloud service within the enterprise. The back-door is typically an unapproved and unmanaged account outside of enterprise controls, and in violation of enterprise policy. Additionally, for their own convenience the admin staff is often populating SSH user-keys to allow a singlesign-on ‘feel’ to it. Their simple desire to NOT type a password or pass phrase can leave your enterprise vulnerable to attack.
 

WHAT ARE SSH KEYS 

SSH keys are used all the time, in every connection. Confusingly there are two types of keys: user-keys and host-keys.

Host-keys are used during the connection setup to provide a secure channel for authentication and can be likened to the SSL certificate on an e-commerce web server that is meant to protect the connection. However, unlike website certificates, Host-keys are typically unmanaged. They are created when the server is installed and hardly ever renewed.

Currently it is the responsibility of the end-user to verify that the connection to the host is trusted before authenticating and exposing their login credentials (password) to the server. How would they know? The answer to the question “do you trust this host?” is usually a default and automatic response of “yes.” An unwary user may accept an untrustworthy connection and facilitate a man-in-the-middle attack that steals their password. However, due to the static nature of host keys “living” inside each server operating system, and without central management and automatic key rotation processes, most SSH enterprise configurations tend to avoid using them for user access. User-keys are a different story.

User-keys provide a different type of functionality. These keys can replace the username/password paradigm, and are used to authenticate an account to a system. Most often the legitimate use of these keys in an enterprise is to allow for automated connections from one machine to another (M2M) to perform an automated or scheduled task. These services still require an account to log into, which are often called functionalaccounts or service-accounts, and are created to be used by an application, not by a person. The problem is that once SSH user-keys are allowed, they are hard to control. In the SSH configuration you can choose to allow keys, or not. If user-keys are allowed, then all you have to do is place a user-key on the target system and it can be used to gain access. Again, the use of SSH user-keys for authentication can have a legitimate purpose within an enterprise. Some organizations have scripts semi-automating key distribution to well-known servers. The problems arise when new infrastructure is established and not known to your scripting environment, or manual key movements are made by admin staff.
 

CONTROLLING THE SIMPLE STUFF 

In a typical deployment, SSH relies on local authentication and access controls configured on each system. With only a few servers and a few accounts this may be manageable. As the number of hosts and accounts grow, the administrative burden grows exponentially, to the point of becoming difficult or dangerous.

Here are some broad guidelines:

1. Your company’s user accounts need to be managed in one place. When access for an account needs to be disabled, it can be done centrally. Imagine having to disable an account and its SSH keys on ten, a hundred or thousands of servers if an administrator were to leave an organization. Missing even one server has the potential of allowing entry, and exposing the entire infrastructure to attack.
2. With most centralized access management systems you can also manage which server, or group(s) of servers an account is allowed to access. Not every user account should require access to every system. Limiting access is a fundamental security tool.
3. Create a management group for a role, add user accounts to the group going forward, and allow role-based-accesscontrol (RBAC). Creating access and authentication rules for defined teams of people are a lot more efficient than making adjustments individually.
4. Another benefit of centralizing authentication to many systems in an account is password management. Having to remember only one password is much better than having to remember many. It is a best practice to require passwords to be changed periodically, and this is much easier to implement and enforce when accounts are managed in one place.
5. The from-user and to-user SSH keys need to be known at both ends of a session to secure the channel. Choose a solution that can automatically make them available when the user attempts to connect. Pre-populating keys to servers on a “might be needed” basis is both inefficient, and prone to later non-removal as the user leaves your company or changes role.
6. Your administration and support staff have been using SSH for a long time. One quirk of behavior you should recognize is that they are used to self-creating their own SSH user-keys, even in an enterprise organization. Use a solution that allows these user generated keys to be transferred into a managed framework, and take control centrally.

THE NEXT STEP: CENTRALIZING SSH SESSION ACCESS CONTROL 

Once you have decided which keys to authenticate with, you need to contend with the default behavior of SSH. This is what we like to call the “all access key.”

The SSH suite of tools allows you to access servers and devices in multiple ways:

• log into a shell on a remote server/device
• executing a single command on a remote server/device
• secure file transfer
• back up, copy, and mirror files efficiently and securely
• forwarding or tunneling a network port
• full-fledged encrypted VPN
• forwarding X-Windows from a remote host
• browsing the web through an encrypted proxy connection
• securely mounting a directory on a remote server as a file system on a local computer
• automated remote monitoring and management of servers through one or more of the mechanisms discussed above

If you have a valid host or user-key by default, you are then allowed to use any SSH “door” to gain entry to a server. If a key has been stolen or copied, a hacker can use any “door” to access the power of all of the above mechanisms.

To ensure SSH is being used correctly, centralized SSH control also needs to include the following:

1. Separate access control “locks” on each of the SSH “doors,” enabling you to strictly control which parts of SSH functionality you want to make available as part of a user’s normal role, and where in your server estate each door can be used.
2. Ensure the SSH solution you purchase ACTUALLY HAS “locks” available for every SSH “door.” Some products may only have simple locks for the first three mentioned on the list above. That still leaves seven other ways to compromise the security and data on your servers.

Core Privileged Access Manager (BoKS) 

Core Privilged Access Manager (BoKS) is utilized by both multi-national enterprises that must comply with stringent compliance regimes, and small start-up companies that have commercial and customer confidential data. Core Privileged Access Manager (BoKS)'s automated credentials management and enforcement approach gets organizations out of the “SSH key management business,” enabling them to increase the granularity of access enforcement, and easily meet strict compliance regulations, all while taking full advantage of the benefits of SSH without the operational cost impact.

Not all software is created equal. Core Privileged Access Manager (BoKS) protects you from the shortcomings of standard SSH software by:

1. Centralizing user management in one place. If a staff member leaves, any accounts, passwords, keys, and roles can be switched off immediately.
2. Allowing you to create meaningful business and technical roles, which provide sensible connection points to attach SSH access policies, rather than with individual users.
3. Enabling you to define which keys are used where for SSH sessions, and how keys are automatically made available and used for user sessions, without assigning staff to handle SSH key distribution as an ongoing administration burden.
4. Enforcing which of ALL the SSH protocol “doors” can be used, and where.
5. Centrally logging all sessions to ensure you will pass your technical audits.
6. Stopping you from needing external scanning tools to “discover” historical SSH keys widely distributed across your infrastructure. If your organization has been in place for a while, expunging that stuff manually can be expensive. If the key is not registered with Core Privileged Access Manager (BoKS), and associated with the correct user and “door,” it cannot be used - period.
7. Protecting you against using policies defined by mal-configured local SSH configuration files, or files that have been purposely tampered with by your staff or technical support partners.
8. Protecting you with “locks” on all the “doors,” and keys only being used in the right places at the right times, and providing you with centralized control of SSH.