Why would you have and production system exposing SSH to the public?
If you must, at least do these steps:
- Disable password SSH login
- Install root kit scanner, like rkhunter and check if your networked systems are infected. s/he might gained access to other instances in your infra.
- Use port scanning on all your instances and check if there is any suspecious rpc port is open that you are not familiar wtih.
- Enable unattended security upgrades.
- Check for the vulnerabilities listings for your internet facing services, like nginx, apache, HAproxy, etc..
- forward all your syslog logs to remote system so the attacker can't cleanup her/her traces after establishing the attack.
- enable automatic blockers like fail2ban.
There's nothing inherently wrong with exposing SSH on your production servers to the Internet. It is one of the most secure services that can run on any given host. Surely it's more secure than your web server or application daemon(s) which handle the other publicly-facing functions of your production host.
If you have the infrastructure and capability to put it on a different network by all means make it inaccessible but for most businesses there's really no other option anyway.
Simpler (better, IMHO) advice would be to make key-based authentication mandatory for your production servers. That way a brute force attack is unlikely to ever succeed. It also rules out stealing passwords since the attacker would need to obtain the entire SSH key before they could login.
Having said that, we don't know how the attacker got in. They could have created an account for themselves or changed the root password/system configuration via a vulnerability. If that's the case they could modify sshd_config so that it listens on the public IP which would make "don't expose it to the public" moot (firewalls notwithstanding).
There's nothing in the OPs post suggesting SSH was exposed to the public, or that the breach happened over SSH. So it's important to secure that, but it's also important to think holistically about the attack surface.
If you must, at least do these steps:
- Disable password SSH login - Install root kit scanner, like rkhunter and check if your networked systems are infected. s/he might gained access to other instances in your infra. - Use port scanning on all your instances and check if there is any suspecious rpc port is open that you are not familiar wtih. - Enable unattended security upgrades. - Check for the vulnerabilities listings for your internet facing services, like nginx, apache, HAproxy, etc.. - forward all your syslog logs to remote system so the attacker can't cleanup her/her traces after establishing the attack. - enable automatic blockers like fail2ban.