Every time I spin up an instance in the cloud, the first thing I do is harden SSH. I can’t stand all these malicious, or forgotten about scripts out there trying to troll these boxes. 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. That includes SSH logins with default credentials. One of my favorite pass times includes streaming DumpMon and collecting cred dumps for use in keeping others safe.
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 on my boxes.
I am calling this
Ke$$ha. You can find the Twitter feed here: https://twitter.com/kesshabot.
The Party Don’t Start ‘Til They Log In
You can get the source of Ke$$ha bot here on GitHub, https://github.com/mikemackintosh/kesshabot.
This was a fun, but quick project. 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). Instead, use IP tables for forward port
22 to a non-privileged port.
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
sshdservice for them to take effect.
Don’t run SSH on the default port 22
Run it on any other port like 122, 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 weed out viable targets.
You can change the port using the following configuration:
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:
Don’t allow root logins for SSH
Disable SSH access for the
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:
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
To enable PublicKey authentication:
Hopefully you learned something new with SSH security but also had fun running an SSH honeypot and setting up a Twitter bot.
For Shits and Giggles
comments powered by Disqus