If you’ve ever launched a server in the public cloud like DigitalOcean of Amazon, you have probably seen failed SSH login attempts within minutes of standing it up. Sometimes, these attempts are bots scanning whole subnets, and sometimes these attempts are from an attacker who compromised the system which used to be associated with your brand new IP address. Many people don’t realize that IP’s are ephemeral, meaning when you change servers or cycle nodes and resources, a lot of times your IP’s change too.
Financially motivated attackers are always looking for a quick win.
These quick wins include SSH logins with default or weak credentials.
To help gain some visibility into SSH dictionary and brute-force attacks, I decided to make a simple tool to tweet every time password authentication was attempted against my boxes. This list could then be mined to generate a stronger cracklib library, which prevents a user from using predefined passwords in a system with the cracklib PAM module configured.
You can find Ke$$haBot on Twitter.
The Party Don’t Start ’Til They Log In
To create this tweeting SSH bot, which I’ve dubbed Ke$$ha Bot, I decided to use Golang, which has some really nice SSH crypto libraries readily available. It creates an SSH server, listens for a password authentication login attempt, and boom, sends a tweet. You can get the source of Ke$$ha Bot here on GitHub.
Using Ke$$ha Bot Yourself
If you’re going to run it, I do not suggest you run it on port 22, or as root(which is required for a privileged port) or on a production server.
Instead, use IP tables to forward port 22 to a non-privileged port so if there is a privilege escalation or RCE vulnerability in this faux SSH server, the impact will be dampened.sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 2022
Keeping SSH Safe In the Cloud
Let’s take this chance to turn a fun project into a learning experience. If there is a problem, you can find a solution. Luckily, keeping SSH safe can be done easily with some quick adjustments.
Note: All of the following settings can be changed in your /etc/ssh/sshd_config. You will need to restart the sshd service for them to take effect.
Don’t run SSH on the default port 22
Run it on any other port like 1022, 2022, 27901, etc.
An attacker is going to look for low hanging fruit with regards to network services. This includes top-ports using tools like nmap as it’s a simple way for them to quickly pinpoint viable targets.
You can change the port using the following configuration statement in your sshd_config:Port 122
If you have multiple interfaces on your box, it may also be helpful to limit SSH access to only one of them. This can be done by setting the IP in the following config directive:ListenAddress
Don’t allow root logins for SSH
Disable SSH access for the root account.
Don’t ever login to a box via the root account. Assume that if you can login with root, anyone else can too.
You can prevent root logins with:PermitRootLogin no
Don’t use passwords to login
You should use public/private key authentication, with a password protected private key.
Using a password to login could work depending on where you’re connecting from an to. But for instances in the cloud, you probably want to lock it down as much as possible. This would include preventing Password auth and enabling PublicKey authentication.
You can disable password authentication by setting PasswordAuthentication to no:PasswordAuthentication no
To enable PublicKey authentication:PubkeyAuthentication yes
Conclusion
Everything can’t just be for fun, so hopefully you’ve had a chance to take away some quick wins around hardening SSH.
Member discussion