Introduction to HoneyPy & HoneyDB

Published in

Signal Sciences Labs

5 min readSep 1, 2016

Last week, I discussed HoneyPy and HoneyDB at Blackhat and Defcon. This week I wanted to dive a bit deeper into the projects.

Honeypots 101

If you’re not familiar with the concept of honeypots don’t worry, I’ll provide a brief explanation in this section. It makes sense to understand some basic honeypot concepts before reading about HoneyPy & HoneyDB. If you are familiar with honeypots, then feel free to skip to the next section.

At the highest conceptual level a honeypot is simply a computer that is configured to look and behave like any other computer you might find on any given network. A honeypot can be configured to offer various network services like HTTP, SSH, file sharing, etc. However, the honeypot serves no legitimate business purpose, so in theory no one should really ever attempt to establish a network connection with it. But if it ever does receive a connection, it will log all activity and possibly send alerts to the honeypot operators. Since connection activity should be rare, the logs and alerts are essentially high value signals to both security and operation teams. These are high value to security teams since its possible this could be an indicator of compromise. It is also high value to operations teams as it could mean another system on the network is misconfigured and is generating noise on the network.

Honeypot Types

Now that you have the concept down, there are a few honeypot types and tiers of interaction you should know about. First the types:

Research honeypot — Typically this would be a honeypot that is on the Internet with the purpose of identifying and observing attack activity. Basically, let’s put it out there and see what happens to it! One goal of research honeypot may be to discover new exploits or identify other compromised computers on the Internet.
Production honeypot — This would be a honeypot that is on an enterprise network (or some production environment). Its purpose is to identify and expose malicious actors that may have already compromised the network.

Next are the tiers of interaction, which is about how much interaction does the honeypot enable or allow.

Low interaction — A honeypot that just opens service ports and logs any IP address that connects to it. It may also serve service banners or offer fake login prompts (e.g. telnet), but not actually allow an actor to log in and interact with the system. Low interaction honeypots are also considered less risky to operate.
Medium interaction — A honeypot that offers a bit more than just service ports and banners. For example, it may emulate a fake telnet service with limited command capability. Someone connecting to it may think they have a real telnet session with the system but they don’t. Medium interaction honeypots can gather more information about what a malicious actor may be trying to do, and because they allow more interaction they can be considered more risky to operate.
High interaction — A honeypot that offers full service or system access, however it will be instrumented to log all activity and possibly implement other controls to contain a malicious actor’s activity to just that honeypot or a segment of a network. High interaction honeypots should be considered very risky to operate.

HoneyPy

HoneyPy is a low to medium interaction honeypot, written in Python. It is intended to be a honeypot that is easy to configure, deploy, and extend. You can find the project on Github here https://github.com/foospidy/HoneyPy.

HoneyPy was built to be extensible so you can easily add new service emulations (plugins) for both TCP or UDP based protocols. However, it does come with a small set of basic plugins, listed here, that you can run or use as a starting point to write your own. In addition, configuring what plugins you want to enable is as simple as editing the services.cfg file.

Another great feature is its event log handler integrations with other tools like Twitter, HoneyDB, Slack, Logstash, and Elasticsearch. These event log handlers are intended to make consuming log events more convenient. Rather than writing scripts to parse a log file and generate alerts, the HoneyPy log handlers do that for you. It is relatively trivial to create new new event log handlers so the list of tools will continue to grow.

HoneyPy is easy to deploy, and I’ll cover this and more in a subsequent blog post. However, if you are a fan of Docker containers and would like to quickly spin up an instances, I provide Docker build scripts here https://github.com/foospidy/HoneyPy-Docker. Or you can pull an image from https://hub.docker.com/r/foospidy/honeypy/. I invite you to give it a try.

HoneyDB

HoneyDB is a database and web site created to capture and display event data from HoneyPy sensors that are running on the Internet. I’ve been running HoneyPy sensors and collecting data for a few years now. You can find HoneyDB here https://riskdiscovery.com/honeydb/. There are several features on HoneyDB I could dive into, but I’ll save that for a follow up post.

At a high level you’ll notice various charts showing top traffic statistics. You can click on the pie charts to drill down into specific activity generated from an IP address. One main feature to highlight is the API. The API enables users to leverage the data HoneyDB is collecting as a threat information feed. See more details here https://riskdiscovery.com/honeydb/#threats. In addition, if you want to run your own HoneyPy sensor it can be configured to contribute its event data to HoneyDB! The more sensors contributing the better HoneyDB becomes as a threat information resource.

For anyone that’s every been curious about running their own honeypot, you should go for it as you will definitely learn something new. HoneyPy and HoneyDB are great tools for getting started so please give them a try! Also, any feedback or questions are welcome. Keep an eye out for the follow-up posts, thanks for reading!

If you enjoy our publication, please let us know by clicking that little heart below.

At Signal Sciences we are building a modern Application Security defense product that works for microservices, APIs, Web Applications and anything else that speaks HTTP/HTTPS. Signal Sciences’ NextGen Web App Firewall works seamlessly across cloud, physical, and containerized infrastructure, providing security without breaking production traffic.