Загрузка
Protecting the Linux Infrastructure
Linux administrator accounts are a prime target for attackers. Compromising such accounts gives attackers access to the most critical infrastructure components, such as virtualization and backup systems, databases, core banking and payment processing, etc.
Common threats and issues that require attention when organizing SSH access in a Linux infrastructure
Login and password are easily intercepted by a keylogger
A private key stored as a file is easy to steal when the administrator's device is compromised. At the server level there is no way to verify whether the administrator protected the key with a passphrase, and an attacker can easily steal the passphrase as it is typed using a keylogger
When a private key is compromised, a new private key must be generated and the corresponding public key distributed to all parts of the infrastructure as quickly as possible.
When user public keys are stored in an external system, such as LDAP, there is a risk of losing the ability to authenticate when the external storage is unavailable. In addition, the external storage must be protected against an attacker adding their own public key.
PAM solutions sit inline between the SSH client and the server, which means ensuring their resilience, including 24x7 support, becomes a top priority. It should also be noted that some browser-based PAM solutions incorrectly forward specific keyboard shortcuts and break formatting when pasting multi-line text from the clipboard, which can affect administrator productivity. The session-recording capabilities provided by PAM solutions can be achieved with alternative, cheaper tools installed on jump hosts. All of these questions must be assessed when deciding to adopt a PAM solution for protecting SSH access.
Approach to protecting SSH keys
The risk of authentication data theft over SSH access can be significantly reduced by storing private keys in a non-extractable form on hardware tokens or virtual smart cards using TPM. With this approach, the private key is generated inside the protected area of the token or TPM, which performs all the required cryptographic operations itself, returning the result to the SSH client when a connection is established, while the private key never leaves the device. Tokens expose an interface to the operating system that makes them work like smart cards, which are natively forwarded over RDP connections, making them easy to use from dedicated jump hosts.
SCAT is an SSH-PKI certificate authority that issues SSH certificates after a set of checks that guarantee the private key is stored in a non-extractable form. SSH certificates are the standard way to authenticate in Linux, requiring no additional software or drivers on the server infrastructure. To enable authentication with SSH certificates, servers must receive the certificate authority's public key (the TrustedUserCAKeys parameter in sshd_config) and the revocation list (the RevokedKeys parameter in sshd_config). The required synchronization scripts and API are already part of SCAT.
Supported hardware carriers for SSH keys
Workflow when using YubiKey
With a YubiKey, the user creates an attestation certificate generated by the token. The YubiKey attestation certificate is the public key corresponding to the private key, signed by the intermediate certificate authority (the F9 slot) embedded by the manufacturer at production time, with an additional set of attributes such as the required PIN policy and the requirement to touch the device during use. SCAT verifies the attestation certificate's validity along with the PIN and Touch policies, and if the checks pass, it generates an SSH certificate, extracting the public key from the attestation certificate.
Smart cards
When using other smart cards, including virtual ones, an external X.509 certificate authority must be used — one that issues X.509 certificates only if the private key is stored on a smart card. SCAT verifies the validity of the X.509 certificate and a number of its attributes, such as the issuer, template and EKU, and if the checks pass, it generates an SSH certificate, extracting the public key from the user's X.509 certificate.
Private key generation
Linux configuration
Using SSH certificates
Key SCAT capabilities
- Two-factor user authentication at login, or integration with an external OIDC provider
- Protection of the certificate authority's private key with a passphrase stored encrypted in memory only
- Ability to create multiple certificate authorities, for example to separate production and test environments
- Role model based on LDAP groups or local user lists
- Certificate issuance modes: automatic, or only after approval
- Defining the allowed SSH key algorithms
- Defining constraints for issued SSH certificates: maximum validity, allowed IP addresses and networks, permitted commands, various forwarding options (agent, X11, port), etc.
- Defining mandatory and optional principals included in the certificate
- Defining attestation policies for YubiKey keys and smart card X.509 certificates
- Setting the certificate's key ID to a value containing the author and the request ID, which simplifies investigations when non-personalized accounts are used
- Logging of user actions, forwarding events to SIEM in CEF format