Skip to content
This repository was archived by the owner on Aug 24, 2020. It is now read-only.

Latest commit

 

History

History
859 lines (644 loc) · 23.5 KB

ssh.(01)ssh-requirements.adoc

File metadata and controls

859 lines (644 loc) · 23.5 KB

Telekom Security Compliance Framework

Table of Contents

Secure Shell (SSH)

1. Introduction

SSH (Secure Shell) is a client/server application inclusive a network protocol that can be used to access systems on terminal level and to transfer data. As SSH is typically used for management access, this service has a high security demand. This document includes security requirements for SSH server, SFTP server and the SSH protocol. It is recommended to use OpenSSH as this is a well-known solution with a huge developer community.

This documents includes examples for technical implementation and compliance checks for the security requirements of Telekom Security for Secure Shell (SSH) [Doc. 'SecReq 3.04: SSH'].

The examples in this document are tested for the following SSH software:

  • OpenSSH

ℹ️
 Root privileges are needed to perform compliance checks and to implement needed configuration for the security requirements for SSH.

Telekom Security Compliance Automation

Telekom Security provides Ansible roles for an automated implementation of security requirements. This Ansible roles can be found on following page:

1.1 Special Requirements

ℹ️
 SSH daemon must be restarted after the implementation of the configuration!

Use the following command to restart SSH daemon:

# service <ssh-daemon> restart

Values for <ssh-daemon>:
Debian based Linux distributions: 'ssh'
RedHat based Linux distributions: 'sshd'
Suse Linux: 'sshd'

ℹ️
 Before configuring SSH the running version must be verified and validated if current version is used! Check version on openssh.com.

Use the following commands the check installed OpenSSH version:

Debian based Linux (e.g. Ubuntu) distributions:

   # dpkg -l | awk '/openssh-server/ {print $3}'

RedHat based Linux (e.g. CentOS, Amazon Linux) distributions:

   # rpm -qa | awk -F- '/openssh-server/ {print $3}'

Alternative command (all Linux versions):

   # ssh -V

Expected output: version of installed OpenSSH software

2. Security requirements

Req 1: The SSH protocol version 2 must be used.

SSHv1 must permanently be disabled in configuration of the SSH server. With OpenSSH 7.4 support for SSHv1 completely removed and must not longer be configured.

Motivation: SSH protocol version 1 has weaknesses and is obsolete today. With the use of SSHv1 the confidentiality and integrity of transmitted data cannot be guaranteed.

Compliance Check (only for OpenSSH prior 7.4)

Use the following command to check configuration for correct setting:

   # grep "^Protocol" /etc/ssh/sshd_config

Expected output: Protocol 2

Implementation (only for OpenSSH prior 7.4)

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   Protocol 2

Req 2: SSH moduli smaller than 2048 must not be used.

The file "/etc/ssh/moduli" contains pre-generated group parameters – named moduli - for Diffie-Hellman. Here are also moduli available that are not long enough to withstand known attacks. To avoid the use of short values moduli smaller than 2048 must be deleted from file " /etc/ssh/moduli ".

Motivation: If the DH moduli is to short the key exchange is not protected in an adequate way.

Compliance Check

Use the following command to show all moduli not fulfilling the requirement:

   # awk '$5 < 2048' /etc/ssh/moduli

Expected output: if all moduli are correct nothing should be shown

Implementation

Use the following commands to delete wrong moduli from file '/etc/ssh/moduli':

   awk '$5 >= 2048' /etc/ssh/moduli > /etc/ssh/moduli.new ;
   [ -r /etc/ssh/moduli.new -a -s /etc/ssh/moduli.new ] && mv /etc/ssh/moduli.new /etc/ssh/moduli || true

Req 3: Only approved key exchange algorithms must be used.

For key exchange the following algorithms are allowed:

  • curve25519-sha256@libssh.org

  • diffie-hellman-group-exchange-sha256

  • ecdh-sha2-nistp521

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp256

Motivation: An attacker can possibly break the encryption of transported data if weak ciphers and algorithms are used to access sensitive data.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^KexAlgorithms" /etc/ssh/sshd_config

Expected output: KexAlgorithms <key-exchange-algorithms> See requirement for allowed <key-exchange-algorithms>!

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   KexAlgorithms keyex-algo1,keyex-algo2,...,keyex-algoN>

See requirement for allowed key-exchange algorithms!

Req 4: Only approved ciphers algorithms must be used.

Outdated and insecure ciphers and algorithms must not be used. Use the following ciphers for SSH:

  • chacha20-poly1305@openssh.com

  • aes256-gcm@openssh.com

  • aes128-gcm@openssh.com

  • aes256-ctr

  • aes192-ctr

  • aes128-ctr

Motivation: An attacker can possibly break the encryption of transported data if weak ciphers and algorithms are used to access sensitive data.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^Cipher" /etc/ssh/sshd_config

Expected output: Ciphers <chiphers> See requirement for allowed <chipers>!

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   Ciphers cipher1,cipher2,...,cipherN>

See requirement for allowed ciphers!

Req 5: Only approved MAC algorithms must be used.

It is important to avoid the use of insecure MAC algorithms for SSH. Examples of such outdated algorithms are MD5 and SHA1. The following MAC algorithms are allowed and must be configured for SSH daemon:

  • hmac-sha2-512-etm@openssh.com

  • hmac-sha2-256-etm@openssh.com

  • hmac-sha2-512

  • hmac-sha2-256

Motivation: An attacker can possibly break the encryption of transported data if weak ciphers and algorithms are used to access sensitive data.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^MACs" /etc/ssh/sshd_config

Expected output: MACs <macs> See requirement for allowed <macs>!

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   MACs mac1,mac2,...,macN>

See requirement for allowed MACs!

Req 6: SSH logging must be enabled.

Logging for SSH must be enabled. It is recommended to use level INFO to get important information but not to get a lot of useless events. If needed higher levels like VERBOSE can also be used.

Motivation: Logging security-relevant events is a basic requirement for detecting ongoing attacks as well as at-tacks that have already occurred. This is the only way in which suitable measures can be taken to maintain or restore system security. Logging data could be used as evidence to take legal steps against attackers.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^LogLevel" /etc/ssh/sshd_config

Expected output: LogLevel INFO Beside INFO higher log levels like VERBOSE are also possible!

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   LogLevel INFO

Beside INFO higher log levels like VERBOSE are also possible!

Req 7: SSH LoginGraceTime must be set to one minute or less.

The LoginGraceTime parameter restricts the time window for a successful authentication. The longer this period is the more open unauthenticated connections can be established. To avoid this a max time must be specified. Recommended is 60 seconds.

Motivation: An adequate time for LoginGraceTime parameter protects the system against unauthenticated SSH connections which waste system resources.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^LoginGraceTime" /etc/ssh/sshd_config

Expected output: LoginGraceTime 60

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   LoginGraceTime 60

Req 8: SSH MaxAuthTries must be set to 5 or less.

The MaxAuthTries parameter specifies the maximum number of authentication attempts permitted per connection. This value must be limited to 5 or less attempts.

Motivation: This parameter will minimize the risk of successful brute force attacks to the SSH server.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^MaxAuthTries" /etc/ssh/sshd_config

Expected output: MaxAuthTries 5

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

    MaxAuthTries 5

Req 9: SSH root login must be disabled.

All users must have unique and personal user accounts. Constantly working as root is not permitted. To avoid remote login with user root the login over SSH must be disabled.

ℹ️
 It is also possible to achieve an adequate security level if only functional user accounts are used on a system. It must be guaranteed to share SSH keys over a central ac-count management system (e.g. ZAM) for the root user and to enroll them with a configuration management system. Additionally, access must be done over a jump server with personalized accounts. The use of SSH keys for authentication is still mandatory (login with password over SSH is not allowed).

Motivation: It is a high risk to use user root on a Linux system and to allow remote login. If an attacker is able to compromise this account, the system is complete under control of the attacker.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PermitRootLogin" /etc/ssh/sshd_config

Expected output: PermitRootLogin no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PermitRootLogin no

Req 10: SSH strict mode must be enabled.

SSH StrictModes must be enabled. This enables checks to ensure that SSH files and directories have the proper permissions and ownerships of the login user before allowing an SSH session to open.

Motivation: This feature blocks unwanted access to files and directories.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^StrictModes" /etc/ssh/sshd_config

Expected output: StrictModes yes

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   StrictModes yes

Req 11: SSH user authentication must be done with public keys.

Authentication with public/private key must be used for SSH login.

ℹ️
 The private key of human beings must be protected with a passphrase.

Motivation: Passwords are usually attackable via Phishing, Keylogger and Brute Force attacks. An attacker who occupies a password can misuse the corresponding user account.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PubkeyAuthentication" /etc/ssh/sshd_config

Expected output: PubkeyAuthentication yes

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PubkeyAuthentication yes
ℹ️
 Before activating this feature at least one user account must be present on the system that are allowed to login over SSH and with a public key configured (see Annex for help)!

Req 12: SSH password authentication must be disabled.

The login must be done with public/key authentication. Login with password only must be disabled for SSH.

Motivation: Passwords are usually attackable via Phishing, Keylogger and Brute Force attacks. Additionally, pass-words can be easily shared and a non-repudiation therefore is reasonable hard.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PasswordAuthentication" /etc/ssh/sshd_config

Expected output: PasswordAuthentication no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PasswordAuthentication no
ℹ️
 Before activating this feature at least one user account must be present on the system that are allowed to login over SSH and with a public key configured (see Annex for help)!

Req 13: SSH IgnoreRhosts must be enabled.

Motivation: If a trust relationship is configured with another system an attacker has direct access to all other trusted systems in case of an intrusion.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^IgnoreRhosts" /etc/ssh/sshd_config

Expected output: IgnoreRhosts yes

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   IgnoreRhosts yes

Req 14: SSH HostbasedAuthentication must be disabled.

Motivation: If a trust relationship is configured with another system an attacker has direct access to all other trusted systems in case of an intrusion.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^HostbasedAuthentication" /etc/ssh/sshd_config

Expected output: HostbasedAuthentication no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   HostbasedAuthentication no

Req 15: The usage of the SSH service must be restricted to dedicated groups or users.

For easier and more secure system administration it is necessary to use dedicated users or groups (recommended) for SSH.

Motivation: The usage of dedicated users or groups makes user management for SSH more secure.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^AllowGroups" /etc/ssh/sshd_config
   # grep "^AllowUsers" /etc/ssh/sshd_config
   # grep "^DenyGroups" /etc/ssh/sshd_config
   # grep "^DenyUsers" /etc/ssh/sshd_config

Expected output: user and groups

ℹ️
 It is recommended to configure and use a dedicated group for SSH. All users that are allowed to access the system via SSH are added to this group. This means also that parameters 'AllowUser', 'DenyGroups' and 'DenyUser' are not used and must be empty.

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   AllowGroups <ssh-group>

If possible use the following existing default groups for SSH:
* Ubuntu: ssh * RedHat: sshd * Suse: sshd

Additionally add the needed user to the ssh group with the following command:

   # usermod -a -G <ssh-group> <user>
ℹ️
 If you miss to add the needed users to the group used for SSH, you can not login afterwards!

Req 16: The SSH Idle Timeout Interval must be configured to an adequate time.

To specify the time how long inactive SSH session hold open the following two parameters must be configured:

  • ClientAliveInterval: timeout interval in seconds (recommended 300) after session is terminated if no data is received.

  • ClientAliveCountMax: number of client alive messages (recommendation 0) which may be sent without sshd receiving any messages back from the client.

Example: if the ClientAliveInterval is 20 seconds and the ClientAliveCountMax is 3, the client SSH session will be terminated after 60 seconds of idle time.

Motivation: Open or unused sessions give the possibility to an unauthorized user for session high-jacking. This session can then be used to get access to the effected system and its data.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^ClientAliveInterval" /etc/ssh/sshd_config
   # grep "^ClientAliveCountMax" /etc/ssh/sshd_config

Expected output:
* ClientAliveInterval 300 * ClientAliveCountMax 0

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   ClientAliveInterval 300
   ClientAliveCountMax 0

Req 17: SSH tunnel devices must be disabled.

SSH can be used to tunnel services. For management service of Linux servers this is typically not used and can be disabled.

Motivation: SSH tunnel feature can be used by an attacker to tunnel traffic to own destinations.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PermitTunnel" /etc/ssh/sshd_config

Expected output: PermitTunnel no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PermitTunnel no

Req 18: SSH TCP port forwarding must be disabled.

TCP forwarding can be used to forward TCP connections through SSH. For management service of Linux servers this is typically not used and can be disabled.

❗
 This requirement is not valid for Jump Servers!

Motivation: If this feature is not used in a controlled manner, it could be a security risk for servers.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^AllowTcpForwarding" /etc/ssh/sshd_config

Expected output: AllowTcpForwarding no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   AllowTcpForwarding no

Req 19: SSH agent forwarding must be disabled.

SSH agent forwarding can be used to forward authentication requests to other systems over SSH. For management service of Linux servers this is typically not used and can be disabled.

❗
 This requirement is not valid for Jump Servers!

Motivation: The server-side deactivation blocks the creation of a server-side agent forwarding socket, this socket consequently cannot be misused.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^AllowAgentForwarding" /etc/ssh/sshd_config

Expected output: AllowAgentForwarding no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   AllowAgentForwarding no

Req 20: SSH gateway ports must be disabled.

SSH Gateway ports specifies whether remote hosts can connect to ports forwarded for the client. For management service of Linux servers this is typically not used and can be disabled.

Motivation: If this feature is not used in a controlled manner, it could be a security risk for servers.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^GatewayPorts" /etc/ssh/sshd_config

Expected output: GatewayPorts no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   GatewayPorts no

Req 21: SSH X11 forwarding must be disabled.

X11 is not used on Linux servers. The forwarding of X11 over SSH must be disabled.

Motivation: If this feature is not used in a controlled manner, it could be a security risk for servers.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^X11Forwarding" /etc/ssh/sshd_config

Expected output: X11Forwarding no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   X11Forwarding no

Req 22: SSH PermitUserEnvironment must be disabled.

The SSH PermitUserEnviroment parameter specifies if user defined environment variables are processed by sshd. This variable must be set to "no" to disable it.

Motivation: Enabling the processing environment variable may enable users to bypass SSH access restrictions.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PermitUserEnvironment" /etc/ssh/sshd_config

Expected output: PermitUserEnvironment no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PermitUserEnvironment no

Req 23: SSH PermitEmptyPasswords must be disabled.

With the 'PermitEmptyPasswords' parameter can be configured the SSH server allows login to an account with an empty password. This must not be allowed.

Motivation: If login without a password remotely over SSH is possible unauthorized users can get access to the server.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^PermitEmptyPasswords" /etc/ssh/sshd_config

Expected output: PermitEmptyPasswords no

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   PermitEmptyPasswords no

Req 24: If SFTP is activated, internal server of OpenSSH must be used.

OpenSSH has its own SFTP daemon. If SFTP should be used this function must be enabled and configured in a secure way.

Motivation: It is necessary to use the OpenSSH SFTP daemon to align the security configuration for all SSH based services and not to have different security levels.

Compliance Check

Use the following command to check configuration for correct setting:

   # grep "^Subsystem sftp" /etc/ssh/sshd_config

Expected output: Subsystem sftp internal-sftp

Implementation

Add the following parameter and value to configuration file '/etc/ssh/sshd_conf':

   Subsystem sftp internal-sftp -l INFO

Parameter '-l' activates logging for SFTP.

It is recommended to use a chroot environment for SFTP. This can be implemented by adding the following configuration at the end of the file '/etc/ssh/sshd_conf':

   Match Group <sftp-group>
      ForceCommand internal-sftp -l INFO
      ChrootDirectory /home/%u
      AllowTcpForwarding no
      AllowAgentForwarding no
      PasswordAuthentication no
      PermitRootLogin no
      X11Forwarding no

It is necessary to generate a group (add group name instead of <sftp-group>) for SFTP and to add the users that are allowed to use SFTP to this group.

Annex

How to generate a public/private SSH key

It is recommended RSA keys only. The alternative DSA (Digital Signature Algorithm) is not longer recommended as the possible key length is restricted to 1024 bit in DSA.

Use the following command to create keypair:

   $ ssh-keygen -t rsa -b 4096

The private key (id_rsa.) file should never be given to somebody else. As the name says: it is private and intended to used only by you!

ℹ️
 It is important to set a passphrase during the key generation. Otherwise anybody who gets hand on the private key can misuse it to access your SSH servers!

Add a user with public key authentication

1 Generate a user account

   # useradd -m <user-name>

2 Add user to SSH group

   # usermod -a -G <ssh-group> <user-name>

3 Copy public key to users home directory

The file public key (id_rsa.pub) must be copied in the following directory: /home/<user-name>/.ssh/

From remote client via SSH:

   # ssh-copy-id -i ~/.ssh/id_rsa.pub <user>@<server-address>