Preventing SSH brute force attacks
One of the most common types of attack seen on the internet is a brute force attempt on SSH passwords. Most machines accepting SSH connections from the internet will at some point show numerous failed login attempts in their logs. These attacks typically involve scanning IP address ranges for the default SSH port (22) and attempting to login to any machines that have this port open, using a predetermined list of commonly used usernames and weak passwords.
The impact of these attacks can potentially be very serious, especially if the attacker, having logged in with a weak account, is able to leverage other vulnerabilities to escalate their privileges to root.
The following measures can be used to prevent these attacks. Although just one of these measures might be enough to prevent a successful attack, a 'defence in depth' approach using multiple measures is recommended.
- Disable SSH wherever it is not needed - Many Linux distributions will have sshd enabled by default. If it is not required, simply disable the service.
- Check existing firewall rules and remove rules for machines that do not need SSH open to the internet - This is particularly important when decommissioning machines. Compromises often occur when an IP address is re-used and a firewall rule for SSH still exists for the old machine. If the new machine has an out-of-the-box configuration that includes weak username/password combinations, it is likely to get compromised before long.
- Use a single, secure host for SSH access into your network - Instead of opening multiple firewall holes for every host that someone might need SSH access to, require users to SSH to one particular host, from which they can then SSH to other hosts which are not directly exposed to the internet. The exposed host can have more hardening measures applied, which may not be necessary on the others.
- Run SSH on a non-default port - Since nearly all 'random' attacks are targeted at the default port 22, changing the listening port for sshd is an effective way of avoiding them. In OpenSSH, this can be done by editing the line "Port 22" in /etc/ssh/sshd_config. It is probably wise to avoid obvious alternate ports such as 222 and 2222, as scans for these ports are sometimes seen. Any connecting clients will need to specify the new port.
- Disallow root logins via SSH - This should be the default setting anyway. Older versions that allow root logins by default should be updated. If you require root access via SSH, don't enable root logins, instead you should log in as a user that can 'su' to root.
- Allow only SSH protocol version 2 - Again this should be the default. SSHv1 is insecure and may make brute force attacks easier. The relevant line in /etc/ssh/sshd_config should read "Protocol 2".
- Avoid using easily guessable names for accounts - Unless the attackers can obtain usernames from another source (e.g. a website), they are just guessing them. Avoid usernames such as manager, admin, sysadmin, webmaster, guest, test, temp, as these are seen in brute force attempts. Users' first names are also used, so initial and lastname is a better choice.
- Apply a password policy - Setting length and complexity requirements will greatly decrease the chances of a successful brute force attack.
- Use key-based authentication - It is possible to disable password-based authentication altogether and use key-based authentication. This can have its own security issues. If your machine with the SSH keys is compromised, the attacker can log on to remote systems using your keys. So, if you use SSH keys, you should protect the private key with a passphrase which must be typed when the key is used. However, it might not be possible to force users to set a passphrase for their keys.
- Block brute force attacks - Although sshd itself provides no effective way to limit brute force attacks, it is possible to use methods that use log files and firewall rules to impose a ban on IP addresses that attempt too many connections. An example is Fail2ban.
- Keep the kernel up to date - Local privilege escalation vulnerabilities are regularly found in the Linux kernel, and can allow a user account that is logged in through SSH to escalate privileges to root and take full control of the machine. It is therefore essential that the kernel is regularly updated.