SSH hardening for cloud virtual machines

/ October 4, 2013

What’s specific to Cloud Virtual Machines?

SSH is required to access your virtual machines that run in your Cloud infrastructure, so you can not disable it.

Due to new threats that arise with IaaS Cloud Computing (Cloud Security Alliance Top Threats), you must protect your infrastructure against Malicious insiders.
Even if we refer to IaaS leader hardening guide for SSH (http://aws.amazon.com/articles/9001172542712674/), this is clearly lacking of security advise.

An hardenend SSH configuration is the first step to achieve so, but it does not protect against every threat such as DDoS attacks. SSH configuration hardening must be complemented with tools such as Fail2ban or DenyHosts.
You can also use Port Knocking tool such as fwknop which is working with the virtual machine firewall.

In this post, we will try to give best advise for SSH configuration and explain why. Due to malicious insiders threats and Cloud computing features such as auto-scaling, we will skip advise such as changing SSH port to a high-number port (As a matter of fact a malicous insider has no problem retrieving the SSH port because he has some unprivileged access to the infrastructure or a part of it).
We will also suppose that:

  • you have enabled public key authentication (usually enabled by default) 
    PubkeyAuthentication yes
  • you have generated new keys for your SSH server (usually part of the initization of the virtual machine)

Protect against SSH Insertion Attack: Get access to the system

  • Check SSH protocol:
    SSH has two protocol versions 1 and 2. Protocol version 1 has a number of known vulnerabilities, therefore only SSH protocol version 2 connections should be permitted.

    Protocol 2

Protect against SSH Brute Force Attack: Get access to the system

  • Check for root login:
    The root user should never be allowed to login directly over a network, as this both reduces auditable information about who ran privileged commands on the system and allows direct attack attempts on root’s password. By disabling root login if anyone wants to become root via ssh two logins are needed and the root password cannot be brute forced via SSH.

    PermitRootLogin no
  • Check which accounts can use SSH:
    By default all users can access SSH. Allowing or denying SSH access for specific users can significantly improve your security if users with poor security practices don’t need SSH access. It’s recommended to specify which accounts can use SSH if only a few users need to use SSH.

    AllowUsers USER1 USER2
DenyUsers USER1 USER2
AllowGroups GROUP1 GROUP2
DenyGroups GROUP1 GROUP2
  • Check for Password Authentication:
    Because a lot of people with SSH servers use weak passwords, many online attackers will look for an SSH server and then start guessing passwords at random. By disabling password authentication, it will only be possible to connect from computers you have configured a key-pair. This massively improves your security. It is recommended to disable password authentication unless you have a specific reason not to.

    PasswordAuthentication no
  • Check if login to accounts with empty password strings is allowed:
    Empty passwords significantly weakener system security. Furthermore, measures should be taken to disable accounts with empty passwords system-wide.

    PermitEmptyPasswords no
  • Check if Host Based Authentication is allowed:
    SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files. On the other hand, SSH’s cryptographic host-based authentication is slightly more secure than .rhosts authentication, since hosts are cryptographically authenticated. It is not recommended that hosts unilaterally trust one another.

    IgnoreRhosts yes
HostbasedAuthentication no
RhostsRSAAuthentication no
  • Check if Timeout for idle connections has been set:
    SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

    ClientAliveInterval 3600
ClientAliveCountMax 3
  • Check if attack surface is minimized:
    By default ssh will wait up to 2 minutes to allow a user to authenticate and will allow him up to 6 authentication attempts. In order to minimize the attack surface it is recommended to reduce these values. Considering the authentication attempts it is recommended to handle then by strengthening the default firewall rule for the SSH service.
    It is recommended to drop multiple failed authentication attempts by strengthening the default firewall rule for the SSH service

    LoginGraceTime 30
MaxAuthTries 3

Protect against Privileges Elevation: Get admin access to the system

  • Check if users can set environment options:
    It is recommended to prevent users from being able to set environment options through an SSH connection and potentially bypass some access restrictions

    PermitUserEnvironment no
  • Check if Privilege Separation is employed:
    This option separates process privileges splitting the daemon in two parts. With privilege separation a small part of the code runs as root and the rest of the code runs with the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by containing any corruption within the unprivileged processes.

    UsePrivilegeSeparation yes
  • Check if StrickModes option is enabled:
    With this option file permissions and ownerships are checked of user files are checked before accepting a connection. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. If any check fails the user will not be able to login.

    StrictModes yes

Protect against Information Leakage: One can set up a tunnel to access a critical service (such as LDAP)

  • Check if Forwarding is allowed:
    It is possible to tunnel network connections as well as specific graphical applications through an SSH session. These options give more options to an attacker who has already established an ssh connection. However, disabling these options gives you a little security, as an attacker with access to a normal shell can install his own forwarders.

    AllowTcpForwarding no
AllowAgentForwarding no
X11Forwarding no

Conclusion

Nowadays, with IaaS and sharing templates for virtual machines, you must pay attention to backdoors installed (which could be a simple SSH key). You can read more in the following study on Amazon Web Services: A Security Analysis of Amazon’s Elastic Compute Cloud Service, ACM SAC 2012.

Today all these checks on SSH configuration are automatically available with Elastic Detector in Elastic Vulnerability Assessment (on a daily basis) and without having to install software agents.

References:

Related posts

One thought on “SSH hardening for cloud virtual machines”

Leave a reply to Siva Prem Cancel reply