The secure shell protocol (SSH) is one of the cornerstones for sysadmins. Creating an encrypted communication channel over an unsecured network is crucial in keeping your organization’s internal systems safe.
The SSH protocol was introduced way back in 1995 but went through some significant changes since then. Some versions proved more vulnerable to attack than others. Still, the continued evolution of the protocol and some commonly used tools (like OpenSSH) continue to provide a very reliable means of performing remote tasks.
Reposify’s external attack surface platform discovered more than 20 million exposed SSH services last month, posing a very attractive target to attackers seeking access to an organization. Finding and exploiting any single version can result in access to countless targets.
While updating a version might not be as straightforward as it sounds, as it affects other systems or 3rd parties using it, there are still security measures to help us mitigate the risks to SSH services.
We’ve compiled a shortlist of essential steps to harden any SSH service. These steps are highly recommended, regardless of version. Some are part of the best practices recommended, and others are just good sense.
4 Steps For hardening Any SSH Service
The “config” file referred to below is “/etc/ssh/sshd_config”
- Changes to the config file will be applied only after restarting the SSH service using “service sshd restart”
1. Prevent Root Access
This one goes without saying, and it’s a top priority. If an attacker managed to get your password, or even worse, managed to break into your system and steal your credentials, you must pull up the big guns and make sure that no matter what, the attacker won’t get the root access privileges.
How to prevent hackers from gaining root access?
In the config file, change “PermitRootLogin yes” to “PermitRootLogin no”
A subset of this critical step is to restrict SSH access to specific users, instead of any system users (that isn’t root).
In the config file, uncomment “AllowUsers” and add the permitted users after (e.g. “AllowUsers user1 user2 user3″)
2. Limit Retries / Password Attempts
Limiting how many times a user can attempt to guess a password will automatically drop the connection after a set number of failed attempts to log in.
In the config file, uncomment “MaxAuthTries” and add a numeric value after it, indicating the number of permitted attempts (ex: “MaxAuthTries 4”)
This step will only drop the connection, a new one can still be established to continue making login attempts. To address this, we highly recommend using the brilliant tool, fail2ban.
3. Disable Empty Passwords
This is a simple one, but can also help enforce the use of passwords in the organization. In the config file, set the “PermitEmptyPasswords” to “no”.
4. Disconnect Idle Timeouts
When a session is idle for a set period of time, it is prudent to let it drop. The risk of leaving an open session can lead to a compromised system and leverage an attack.
In the config, uncomment “ClientAliveInterval” and set a time value (e.g.:ClientAliveInterval 600). This will determine the idle time (in seconds) before a connection is dropped.
Another part of this feature is its ability to test to see if the connection is idle for a set number of times, and only then drop the connection.
In the config, uncomment and set “ClientAliveCountMax” with a number (e.g.: ClientAliveCountMax 2). This indicates the number of times the server will probe the client before dropping the connection. For example, a 10-minute interval x 2 probe attempts = 20 min before the connection is dropped.
Note: ClientAliveCountMax 0 will result in no probe attempts before dropping the connection. (The default value is 0. but some guides do recommend using this one as well to reduce idle time.)
Top Common Critical & High SSH Vulnerabilities
Early Detection Can Prevent Network Damage
By continuously monitoring your IT network, Reposify’s external attack surface management platform (EASM) can alert you to newly exposed open ports that might be backdoors left by attackers or misconfigurations that expose those services and others unknowingly; early detection can prevent attackers from damaging your entire network or serve as an indication to an ongoing attack. This continuous monitoring enables your security team to stay on top of every risk or unknown exposure with an always up-to-date asset overview. No assets should be left unmanaged!