Playbook for Failed SSH login

Brute-force and dictionary attacks against remote services such as SSH, are one of the Top-20 most common forms of attack on the Internet that compromise servers. In particular, Unix-based and Mac OS X servers that run an SSH service to allow administrators secure remote connections are at risk.

Playbook

Mitigation

1. Disable root access – It is a good security practice to disable logins via SSH for the root account. Log in from your non-privileged user account and escalate privilege when and if necessary. SUDO and SU are examples of tools/commands that allow privilege escalation. These provide the added benefit of accountability (i.e. logging) in environments where root access must be shared.
2. Disable unused services – Disable SSH if it is not in use.
3. Filter traffic to your SSH server – Whenever possible, filter traffic to your SSH server (with a network or host based firewall) restricting access to only known IP addresses. Restricting access to the campus VPN subnet or a range of IP addresses is a good start for filtering traffic.
4. Run the SSH server on a non-standard, high port – This will mitigate automated attacks scanning for SSH servers on the default port.
5. Consider to Install and maintain anti-brute-force tools – There are a number of filters and tools that administrators can use to block and protect against brute-force/dictionary attacks. A few are:
   • Pam_abl (first test on a sandbox environment) – Provides a blacklisting of hosts and users responsible for repeated failed authentication attempts. Pam_abl download
   • SSHBan (first test on a sandbox environment) – Receives data directly from the loggers instead of scanning system logs. SSHBan download
6. Enforce strong passwords – Using a strong password will enhance your defense against SSH brute-force/dictionary password attacks. Please refer to Computing Services Password Requirements and Guidelines for Password Management for more information on how to select and manage a strong password.
7. Limit connection rates – For example, limit the number of SYN packets – This practice will not affect the legitimate user, but will limit incoming attacks from rapid, repeated connection attempts.

References

https://www.cmu.edu/iso/aware/be-aware/brute-force_ssh_attack.html

https://www.forbes.com/sites/daveywinder/2020/05/05/godaddy-confirms-data-breach-what-19-million-customers-need-to-know/#5e23caa71daa

Real Use cases

Here is what GoDaddy did as part of their containment

We immediately reset these usernames and passwords, removed an authorized SSH file from our platform, and have no indication the individual used our customers’ credentials or modified any customer hosting accounts. The individual did not have access to customers’ main GoDaddy accounts.”

GoDaddy Breach