Ke$$haBot - Tweeting Malicious SSH Login Attempts

Feb 21, 2016 Security


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:

The Party Don’t Start ‘Til They Log In


You can get the source of Ke$$ha bot here on GitHub,

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 sshd service 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:

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:


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


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