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.
Read the rest of this entry »
