Shodan lists 21 million SSH servers available on the Internet, a number that increases daily. Linux based cloud services continue to grow and often expose SSH by default as soon as a system is deployed. Although built for security, SSH is not infallible and with so many instances around, securing it has never been more urgent.

Last month, a new critical vulnerability was discovered in OpenSSH, a suite of tools based on the SSH protocol and included on almost every Unix/Linux system. Now patched, the vulnerability highlighted the importance of leveraging defense-in-depth strategies to protect even the most secure protocols.

Making it Safe

There are plenty of detailed articles available online for securing individual SSH servers. The guidelines below focus on holistic, enterprise-wide defense-in-depth strategies. Common best practices are summarized at the end.  

Exposure Limits

  • Wherever possible, get rid of legacy SSH-based batch jobs and automated file transfers. These can sometimes linger years after they are no longer in use and the underlying applications have been disabled. Additionally, these jobs tend to rely on keys or passwords that rarely, if ever, get rotated.
  • Replace SSH-based system administration scripts with enterprise management tools, which can typically support a variety of protocols and authentication mechanisms. Segregate management to a dedicated, non-public network, even for systems hosted on public cloud and systems that must otherwise be accessible on a DMZ (e.g., web servers, email servers, etc.)
  • Disable and uninstall the SSH service on workstations and other computers that don't require remote access. For those that do, use an enterprise remote access system instead of exposing SSH directly.

Controlling Access

  • Implement and audit principles of least privilege. Whitelist specific users and default user access to deny.
  • Use the "command" directive in the authorized_keys file to implement command restriction instead of granting shell access (especially for users that only need to transfer files).
  • Use centralized, PKI/certificate-based access credentials instead of passwords or traditional SSH keys. If SSH keys must be used, implement automated systems to manage and rotate keys on a regular basis.
  • Implement and enforce strong multi-factor authentication for interactive logins (the passphrase on an SSH key doesn't really count).
  • Under no circumstances allow the root user to login directly.
  • Use restricted shells and chroot jails (this functionality is now native to OpenSSH).

On the Network

  • Forget the bastion host. Implement a decentralized zero-trust network architecture instead.
  • Even when exposed, it's rarely necessary to keep SSH wide open on the Internet. Use IP based and geoIP restrictions to limit access.
  • Use rate limiting and other tools, such as fail2ban, to limit unauthorized access attempts.
  • Change the default SSH port. Security though obscurity is not effective on its own, but this trick will limit thousands of automated and amateur attacks. Don't use port 2222 either, as this has become a common practice and is now frequently targeted.
  • Implement port knocking.

Don't Forget the Basics

  • Keep servers patched and up to date.
  • Disable the use of encryption algorithms and key lengths which are no longer current and considered safe.
  • Harden systems and SSH configurations using well-known and established guidelines, such as the CIS Benchmarks.
  • Forward SSH log information to SIEM, UEBA and other monitoring systems. Ensure proper alerting is in place and archive logs in case a long-term forensic analysis is ever required.