Sometimes, there is a valid business reason to directly expose a SSH server on the Internet and make it a target for an attack. We would like to know how these attacks are being performed. Are they scripted or performed by hand? How often is a server attacked? From which IP address do the attacks originate?

To find out the answers to these questions, a SSH honeypot can be deployed. Given the availability of low-cost hardware such as the Raspberry Pi, this seems to be an inexpensive solution.

SSH Honeypot Experiment

Given the challenge that we want to not only detect attacks, but also possibly learn from the attackers’ behavior, we need some kind of tool. In general, an application that creates a sandbox-like environment to trap attackers is called a “honeypot.” Several tools are available to mimic a SSH server.

For this experiment, I have chosen a SSH honeypot software called Kippo. This open-source tool is available in the base implementation and in a fork with added functionality. To analyze the logs of the Kippo application, a Kippo-Graph is used.

The Kippo application runs on Port 2222 by default and mimics a SSH server. The handshake reaction of the application is like a real SSH server. The version it will report as running can actually be set as a configuration option. Once an attacker successfully penetrates the sandbox and lands in the virtual shell, a file system will be presented. The file system can be configured and even “cloned” from an existing file system of a real server. This means most simple file system commands will actually return a directory structure and even some files. All of this is geared toward preventing the person logged in from discovering that this is not a real server.

In a business setting, the logging of the SSH honeypot could be fed into a security information and event management (SIEM) solution. This would then act as a sensor either on the internal network or the externally exposed IP addresses to discover attack activity.

One important aspect to note regarding this experiment is that the software is free and the hardware to deploy it is inexpensive. However, the labor needed to deploy the software on a Raspberry Pi is not negligible. Of course, once one has been applied, some kind of imaging mechanism could be used to deploy more. The return on investment of this deployment is questionable, as well. It is very difficult to gather new intelligence from these SSH honeypot sensors that is not already available from other sources. From a security operations viewpoint, this sensor does not deliver enough to warrant the investment.

Experiment Takeaways

So what do we learn from a SSH honeypot sensor on the Internet in a consumer Internet setting?

After installing the software and all prerequisite software, the Raspberry Pi’s Port 2222 was exposed as Port 22 on the Internet. Within a couple hours, thousands of login attempts were documented. So attackers (or, more correctly, attack scripts) had no problem finding the honeypot. After the first 24 hours of the honeypot being operational, it became clear that the attacks were clearly scripted and that no attack was successful since the password was too strong.

Initially, no attacker successfully penetrated the system because the root password was not in the list of tried passwords. Since Kippo-Graph also shows the most-used username and password combinations, it was possible to set a password that would lead to successful login attempts.

The top five most-attempted combinations by the attack scripts were the following:

1. root/admin
2. root/passw0rd
3. admin/passw0rd
4. root/PassWord
5. root/admin123

I selected the second-most-tried combination to enable “easy” access for the attack scripts, and successful attempts started showing up.

What Was Learned?

We’re ready to start learning from all those attackers gaining access and trying to steal stuff, right? Wrong! As it turns out, the scripted attackers find the correct passwords to a username (in our case, “root/passw0rd”) and then try to connect using a Secure File Transfer Protocol (SFTP) connection. As the Kippo software does not expose a SFTP protocol, this fails and the script disconnects. Afterward, there is no further connection from the originating IP address until the next script sweep. So the first thing we’ve learned is that there is some intelligence built into the attack script. It uses the same SFTP as a first-stage “Kippo detector.”

Next, I deployed a fork of the Kippo code that provides a SSH honeypot that also exposes the SFTP protocol on the same port as the SSH protocol. Examining the logs, the first stage of the detection in the attack script fails. The next stage is mimicking a WinSCP connection. The current Kippo code fails to respond quickly enough, and again, the attack script disconnects until the next sweep.

Up to this point, I have put quite a bit of labor into this, and the information I have gained is that the attack script is built to detect a SSH honeypot (at least one using Kippo). The other information, such as attackers’ originating IP address and the most-used username/password combinations are also available from other sources.

In conclusion, as a way to learn from attackers’ behavior, this experiment is a failure. There might be more to be learned by other SSH honeypot applications that are able to better fool the attack scripts; or SSH honeypots deployed in the internal network might lead to more information. The Raspberry Pi hardware is a hardware platform that is inexpensive to deploy as a sensor in volume once an imaging solution is in place to deploy code. Future experiments are possible by using other applications to build security sensors.

Finally, given that attack scripts are built to recognize a Kippo SSH honeypot, could we disguise a real SSH server that we need to expose on the Internet as honeypots, thus possibly increasing the time it takes to breach a system? It seems that an easy way to achieve this is to disable SFTP if it is not needed.