This is a guest post by BruteForce Lab’s long time supporter and honeypot enthusiast “Black September”. It is also posted on his site here.
Honeypots are nothing new, their use pre-dates computers and malware. Their main goal is to passively sit and wait for someone to engage them. The handler (administrator) of the honeypot will monitor and record everything that happens on the honeypot.
Law enforcement have used honeypots (in human terms) in sting operations, intelligence agencies for catching double agents and “recruiting” new assets. In the realm of IT security honeypots, the ones we are talking about here, have traditionally been used for research and education.
Honeypots will yield a lot of data that can be used for research such as frequency and type of attacks, what type of malware and exploits the attackers use, how they utilize the honeypot once its compromised and the level of knowledge the attackers possess. The malware can be analysed and the AV industry can add another signature to their databases.
Another use of honeypots is for testing. I guess we all have read a “best practices” manual at some point, but very few of us have been able to test these best practices. Building a virtual replica of your production network as a honeynet is one way to get it tested. This will put it to the ultimate test and show you where the weak points are, what type of attacks you can expect and it can even be used in incident response training.
There are three categories of honeypots. High, Medium and Low interaction. Low interaction honeypots are nothing more than a emulated service and give the attacker a very limited level of interaction. High interaction honeypots are fully fledged operating systems and yield a lot more data.
Honeypots have been hard to deploy. Many techniques required you to install software on the honeypots themselves that send information about what is happening on the system back to a collector/sensor. This strategy has worked most of the times, but the reporting software have in some cases rendered the honeypots unusable and the attackers have sometimes been able to detect it.
Late summer of 2013, I came across a Python project that - while far from being a “silver bullet” - had great potential and worked amazingly well. It was easy to deploy and configure and solved a lot of issues with the de facto way we deploy honeypots. The project is called HonSSH.
As described on its project page (https://code.google.com/p/honssh/):
HonSSH will sit between an attacker and a honeypot, creating two separate SSH connections between them, capturing all connection attempts to a text file. When an attacker sends a password guess, HonSSH can either automatically replace their attempt with the correct password and allowing them to login, but confuses them when trying to use sudo with the same [wrong password]. Or with password spoofing disabled, handle the connections as any other NAT device and, once the correct password is detected, capture all the interaction in a TTY log. Sessions can be viewed or hijacked in real time, using the management telnet interface, or be played back later from the saved TTY logs.
In theory, this allows us to deploy HonSSH on a NAT device that sits between the Internet and an internal network. Once HonSSH is installed we can deploy any operating system with a SSH server on it to be used as a high interaction honeypot, without having to install reporting software.
Until now I have not seen any easy way to deploy Linux based high interaction honeypots, but this project sounded extremely promising. During the last couple of weeks I have been playing around with it. It has worked well above my expectations and has showed the potential for becoming a real contender to some of the old ways we have been doing it.
My setup
I have one machine running Ubuntu 12.04 server. This machine is acting as a virtual host machine (KVM: https://help.ubuntu.com/community/KVM) on which I created one NAT device using iptables, one virtual network and several virtual machines of different flavors.
The network topology is pretty standard:
The honeypot is connected to the same virtual network as the internal NIC of HonSSH.
The iptables on the machine running HonSSH will forward any outbound connections from the virtual network and allow incoming connections on tcp/22, but it’s NOT configured to forward this connection to the honeypot as this will be handled by HonSSH itself.
The second NIC on the HonSSH machine is connected to the same network as the gateway. The gateway will handle any incoming requests to tcp/22 as it normally would do and forward them to tcp/22 on the HonSSH machine.
When the attacker finds the correct username/password combination and is able to access the honeypot, HonSSH takes over the show.
HonSSH is configured to intercept incoming connections on tcp/22 (or the port of your choosing), and once the connection is intercepted it will establish a new connection of its own from the NAT device to the honeypot and preform a sort Man-In-The-Middle attack if you like. This will be completely transparent to the attacker.
The attacker will not find any suspicious processes or installed software on the machine he just connected that will tip him off about this being a honeypot. All passwords the attacker enters are logged to the HonSSH logs, and if the attacker uses the honeypot as a pivot device and connects to another machine using SSH that too, including all passwords, will be logged.
If we built an entire network infrastructure as one giant honeypot we would only need to use HonSSH to monitor the first device the attacker connected to, as all other connections from that device would be captured as well.
Conclusions
HonSSH is a great tool which is built upon the Medium interaction honeypot called Kippo. But it still has a few things that could be sorted out. For example, Kippo automatically downloads and saves a copy of the malware (downloaded files by attacker), while HonSSH does not do this automatically. I wrote a single Python script myself that does this, but I’m hoping this will be included in the future.
In order for HonSSH to accept incoming connections on tcp/22 it has to be run as root, and this makes it impossible for you to read the log files or view the TTY sessions without executing sudo. It would be really nice to have HonSSH generate files and directories with read permissions (0755 and 0644). I guess we can just hack the code ourselves, but still I would have liked to not have to do this.
These are just two of the things I would like to point out, but don’t get me wrong, I do not call HonSSH flawed in any way - it’s not. I’m mighty impressed by HonSSH and I truly hope this project is kept alive in the future. This is absolutely something I would recommend to people that use honeypots - it’s simply awesome.
Here’s a video of one of the attackers that came to visit my honeypot: