Securing SSH: What To Do and What Not To Do
An Uptick in Activity
Over the last week we've seen the compromise of a number of supercomputers through their SSH service. Given the increase in Work From Home (WFH), the security of remote, administrative based services is more important than ever. If we look at Shodan (Figure 1), we can see ~22 million SSH services. Given the sheer volume of SSH services on the Internet, it's hardly surprising that attacks are on the rise and that they are successful.
Figure 1: SSH Services by as identified by Shodan
It's also a popular service for the SpiderLabs penetration test team when looking to gain entry into a host or environment. Given our long history compromising the service we wanted to give you some advice on how to properly secure the service from threat actors.
Recommendations for securing the SSH Service
The configuration file for SSH, sshd_config, has a large number of configurable options. We would always recommend that options are considered for their security and context within an environment. We'll list what we believe are the most important recommendations for securing the SSH service.
- Ensure that the SSH service is running the latest, stable release. Looking at OpenSSH, which is the most popular version of SSH, we can see from Figure 2 (below), that the number of associated CVEs is small, but that vulnerabilities still occur, therefore, ensuring that the latest version is running is important, especially if this is an Internet-facing service.
Figure 2: OpensSSH Vulnerabilities by Year (src: https://www.cvedetails.com/product/585/Openbsd-Openssh.html?vendor_id=97)
- Do not allow the root user (UID 0) to authenticate remotely. This can be achieved by setting PermitRootLogin to no from within the sshd_config file. Access to the privileged root user should be via sudo.
- Set PermitEmptyPasswords to no. I would hope that this doesn't require too much explanation.
- Disable password authentication (PasswordAuthentication), this will remove the ability for remote attackers to brute-force credentials using a username and password combination. Disabling password-based authentication leaves key-based authentication, which is significantly harder to brute-force.
- Configure the AllowUsers option, this will permit a pre-defined set of users to authenticate to the SSH service and disable the ability for all other users to authenticate.
- Ensure the AddressFamily is correctly configured. This option allows you to determine which address family can be used, inet (use IPv4 only), inet6 (use IPv6 only) or any (both). We've previously blogged around the importance of IPv6 security.
- While outside the scope of this blog post, we would recommend filtering the source IP address i.e. only allow trusted IP addresses to connect to the service, this can be implemented via IPTABLES or TCP Wrappers.
Security through obscurity
As a dedicated penetration testing team, we see many different types of SSH configurations. Some of these configurations we believe add little or no value to the overall security posture of the service.
- Changing the port number. SSH, by default, listens on 22/tcp, moving this to a non-standard port will not hide the service. If there are any underlying issues with the SSH service they will be found regardless of the port that SSH listens on.
- Removing the SSH banner. When performing port scanning, it is common for SSH to display its banner, which will often display its version and/or related information. Removing the SSH banner does not impact the underlying security of the service.
Final Thoughts
The SSH administrative service is a key component when looking to gain access to an environment, even more so with the WFH movement. Ensuring its security is paramount when looking to create a robust and secure environment.