Cut It Out

If compromising an SSH server looks all too easy, you might be wondering what you can do to prevent this kind of attack. The following is a non-exhaustive list of tips for preventing attacks on SSH. It is worth underlining the fact that rarely do any of these individual security controls act as the panacea to fully secure your SSH servers. However, making use of several of these techniques in tandem will give you a fighting chance to stop attackers. Having said all of that, the first item of the list will make a massive difference to how long your SSH server lasts online without being compromised (even if you don't patch the OpenSSH package for a while).

• Limit IP addresses – this is the first thing I do whenever I set up an SSH server. Building an allow list can be difficult without a permanent IP address, if your broadband router uses dynamic public IP addresses or your VPN shifts IP addresses frequently. If this is the case, I'd recommend looking for alternatives (I'll leave you to research them online). Be creative and use options like Port Knocking, which I wrote about in ADMIN [15]. If you do have a permanent IP address, think about using iptables or TCP Wrappers (which I also wrote about in ADMIN [16]) to lock down SSH server access. I cannot emphasize the benefits of doing so strongly enough. It really is important to limit access to a select few IP addresses. You might even consider only letting, say, 256 IP addresses from your broadband router's IP address pool connect.
• Enforce SSH keys – you should use keys and not passwords. If you must use passwords, make them greater than 12 characters long and complex. As for SSH keys, don't leave them on devices that don't use them. Treat them like precious passwords. Finally, you can also configure Pluggable Authentication Modules (PAM), using one of the many online guides [17], to limit the number of failed logins and enforce password complexity. Be sure to test carefully to avoid causing access problems.
• Monitor logins – If you run five or fewer servers and there aren't that many logins every day over SSH, you could employ this trick, which I have used on personal servers before to keep track of when users log in successfully. I add the command in Listing 6 to the foot of the /etc/profile file, and when Bash is spawned for a user login, an email is sent (note that it is encapsulated in brackets on purpose). See the article in Linux Magazine [18]. You will need an outgoing email server to be available; use something like Postfix with a basic configuration for outbound SMTP only.

(who -m |awk -v q="$(date +"%k:%M:%S %Z on %e %B")" \
  '{print "User " $1 " logged in at " q " from IP "$5 }' | \
  mail -s "Logged user on $(uname -n)" chris@binnie.tld &)

• Harden the /etc/ssh/sshd_config file – there are a plethora of online guides to help you tweak the SSH server's configuration file [19]. Without fail, you should disable root user access and ideally add a group of permitted usernames, alter the standard port that the SSH server runs on (e.g., TCP port 2222) to prevent endless automated probes, lower the setting MaxAuthTries to reduce the maximum number of authentication attempts per connection to three from six, and disable X11Forwarding by changing yes to no. The list goes on and you should do more research online if you are unsure.
• Remove the version banner – if you do not use an allow list for IP addresses, try to avoid advertising the version of your SSH server to the whole Internet. You might be surprised at how difficult that is to do in OpenSSH. To switch off the banner, it really does require a bit more effort [20].
• Use Fail2ban [21] – I would be remiss not to mention Fail2ban; it really is one of the most sophisticated open source rate-limiting solutions out there. You may be surprised to read that I once wrote about it on the Linux Magazine website [22]. I cannot recommend it enough; just take care with your initial configuration to avoid locking yourself out. And, don't be daunted by the regular expression configuration style; you'll find lots of online examples to get you started.

Conclusion

It is perfectly possible to launch high-performance brute force attacks against SSH servers using lightweight tools. In this article, I wanted to demonstrate the effectiveness of lesser-known tools, and I think Shreder and sshbrute both passed with flying colors.

If you're wondering what other tools are available, two of the most popular options for this kind of attack are Hydra (also called THC Hydra) [23] and the inimitable Nmap, when used with its ssh-brute scripting engine script [24].

I hope this article has given you some useful insights into how attackers approach SSH servers. Although SSH servers tend to be better protected than other network services due to their critical nature, they are far from impenetrable. If you don't impose rate-limiting to limit brute force attacks, they are clearly vulnerable.

I also covered a number of mitigation techniques. At the risk of repeating myself, you can stop brute force attacks with rate-limiting in place, but ideally, you should use an allow list to define which specific IP addresses will have access.

Whether you are keen to keep your own servers compliant with security standards or you just want to practice some ethical hacking, the tools described in this article will keep you well prepared to hack and defend your SSH servers.