How Stratum thinks about Internet-exposed SSH

Recently one of our customers engaged Stratum to perform a pentest of their external perimeter. We found a few instances of SSH exposed to the internet and write it up as a low severity finding. The SSH instances didn't show to be vulnerable (at the time of the test) to known exploits, but we still wrote it up as a finding as it represents a risk.

Note: In the time since I provided the guidance below, CVE-2024-6387 dropped and yeah, proved my point.

In this case, the customer asked us for our recommendation on how to manage the risk and, more broadly, how we think about internet-exposed SSH servers. In this case, one of the SSH services was associated with an instance of Concourse CI.

Here is our reply to the customer:

Great question. As an outsider, I’ll do my best to give you some thoughts on this without making too many assumptions. While I’m not familiar with Concourse’s SSH implementation, there are two areas of concern for all SSH servers that are exposed to the Internet:

1. SSH service vulnerabilities: SSH servers (e.g., OpenSSH, Crush, Dropbear, etc.) have had exploitable vulnerabilities like any software. Common SSH exploits include buffer overflows and attacks against the service itself. I think it is reasonable to speculate that SSH servers will be exploited in the future. As such, we recommend ensuring that all internet-exposed services receive top priority when it comes to updates, patching, etc. If the client machines connecting to the service originate from predictable/known IP space, you could adjust your security groups (possibly via automation) to only allow connections from known IPs. You would have to evaluate if this is scalable in your environment. If the client IPs are random or are not known before the connection attempt, it will be difficult to restrict connections to known IPs. Other mitigations include host-level security hardening (e.g., SSH jails, etc.) but are beyond the scope of an email.
2. Authentication attacks: Any SSH server exposed to the internet is under nearly constant password-guessing attacks for default credentials. As such, configuring the SSH server to only allow public key-based authentication mitigates password-guessing attacks. Ensure that changes made to the SSH server are considered carefully so that the server does not allow password-based authentication. If password-based auth is required, ensure that passwords are sufficiently long (e.g., 32 characters) to thwart password-guessing attacks. Consider frequent password rotation. Also, investigate if you can install fail2ban to shun abusive IPs. 

Ideally, SSH would only be exposed to known IP ranges as it addresses most of the risks above. The security controls you should deploy are dependent on how your environment operates, your business, and your operational requirements. Other things to consider:

• Use cloud-managed services when possible (e.g., SFTP with AWS Transfer Family)
• Ensure the SSH authentication logs are captured and sent to a remote log collection platform or SIEM to detect malicious activity, odd authentication activity
• Ensure EDR software (e.g., Defender, Crowdstrike, etc.) is installed on the device to detect malicious activity if an attacker successfully exploits a vulnerability. 
• Ensure Internet-exposed devices’ configs are tracked, and changes logged. For example, in source control, etc.
• If SSH needs to be exposed, take time to evaluate the use of OS/service hardening such as SELinux, chroot jails, etc.

I hope this guidance is helpful. Happy to discuss more.

Thank you,

Trevor