- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
Honeybrid is a network application built to combine the functionalities and advantages of low and high interaction honeypots by intelligently switching the recipients of known and unknown attacks at the network flow level. The main goal of honeybrid is to increase the scalability and the flexibility of honeypots.
Primary Mentor: Georg Wicherski
Student: Robin Berthier
The architecture of Honeybrid will consist of two engines: a Decision Engine and a Redirection Engine. The Decision Engine will filter network traffic, which means it will select network sessions worthy of analysis from the overall traffic received. The Redirection Engine will handle selected network sessions by transparently switching the destination of selected sessions from low-interaction honeypots to the farm of high-interaction honeypots.
The decision to switch the destination is a critical part of the architecture. It can be based on various criteria defined by honeypot administrators. To increase the flexibility of Honeybrid, these criteria will be implemented as modules that can be enabled or disabled in a configuration file. This configuration file allows security researchers to define and apply custom filtering and redirection policies.
A prototype of Honeybrid has already been implemented. The goal for this summer is to leverage this prototype into a reliable tool for the community. The development status of the different components of the architecture is the following:
Moreover, the following decision modules have been implemented so far:
I plan on implementing few other modules to add more functionalities to the architecture:
Deliverables: the Honeybrid framework as an open source application, working and tested in a Unix environment.
Updated Timeline (2009-07-05):
A detailed Gantt chart of the different tasks involved to reach these three milestones is available on the sourceforge project page of Honeybrid.
Second milestone reached! Honeybrid has now all its functionalities working and it's time for testing. In order to check that everything works efficiently, I deployed a Windows honeypot to receive traffic from five /24 unused subnets during half an hour. Here are the details of this experiment.
Here is a overall diagram of the testing architecture:
The NATing gateway was configured with the following iptables rules:
This week I completed an important step which is to integrate a parser in Honeybrid. There are now two new files in the source code:
TCP was built to allow 2 hosts to exchange a stream of packets reliably. Honeybrid must add a third host to this operation when it decides to investigate further a connection. The keys for this process to work are: 1) a replay process that gets the high interaction honeypot to the same state than the low interaction honeypot; and 2) a forwarding process that translates not only IP addresses but also TCP sequence and acknowledgement numbers. Here is how things work in detail:
The goal of this post is to introduce myself and my project: my name is Robin Berthier and I just got my PhD from the University of Maryland. I'll be working this summer on improving Honeybrid, a hybrid honeypot architecture. I've been working with honeypot technologies for the past 4 years, and Honeybrid represents a central part of my dissertation.