The Distributed Honeypot Project

Methods of Allowing Access to Your Honeynet
Michael Anuzis, February 2003


So you want to run a honeynet, but you're not sure where to start. One of the first things you have to decide before you can really do anything is what method of access will you be allowing hackers to use to reach your honeypot. This may seem like nothing important but in fact it plays a huge role in dictating what types of hackers will take the bait and what types of things they will be able to do after they've broken in. One of the difficulties of running a honeynet is you can't dictate ahead of time exactly who will hack you, what their skill level will be, and what they will do once they get in (after all, the fun part is not knowing these things and then figuring them out as they happen). However, by choosing the correct method of honeypot access you want to provide (which is covered in this paper), you will be able to have some influence over who hacks you and what they will be able to do. Think of it as using the right bait for the right fish.

The 5 basic ways of allowing access to your honeypot:

The following methods of allowing access are only a small few of several hundred options that could theoretically be used. These 5 were picked because they seem the most commonly used, and the most versatile allowing you to tweak them for greater control.

All five examples have been written with the thought that the monitoring station that watches over your honeypot will be a seperate machine. These concepts have been written with the OpenBSD operating system in mind as your monitoring station, however they should work just fine with almost any UNIX based OS (as long as you can keep it from getting hacked itself!).

The key in choosing the right method is keeping in mind that a hacker (generally) won't want to hack something they know is a honeypot. Depending on the skill level of the hacker, the following models each offer pros and cons that may tip off more advanced hackers while leaving more neophyte hackers completely oblivious to the fact that the host they're going after is a honeypot. For example, if this is your first honeynet and you want to start a little safer you may choose a model that will be a more likely turn off to advanced/veteran hackers, but will still be realistic enough to catch the novices like bees on honey.

1. Setting the honeypot as a DMZ (Demilitarized Zone) behind your gateway

Pros: High functionality for the hacker/honeypot since all ports are exposed; I call high functionality a pro because it means the hacker will be able to do things like setting up back doors and other various servers for themselves on ports of their choosing, and allowing them to access these services since the required port will also be forwarded. It's important to note however, that giving the hacker this increased sense of functionality can also be taken as a negative thing simply by the fact that it gives the hacker more control over your honeypot.


2. Bridging the connection to your honeypot via invisible firewall

(see link for more details: Memoirs of an Invisible Firewall)
Pros: Pro/Con: This man(monitoring station)-in-the-middle method offers one of the highest potentials available for capturing the more sophisticated hackers as it's the only one that doesn't involve NAT and appears from the internet to be a pure connection.

Cons: Like the DMZ method, since your monitoring station has no IP, you must be at its console to check your honeypot's status/logs

3. Forwarding a few specific ports

Pros: There's a long list of pros for this method, but to name a few: Cons: This method was the first I ever used for a honeynet because I knew ahead of time it would allow me to have near complete control over what my hackers would and wouldn't be allowed to do. For more details on exactly how to set it up the whitepaper is available here:
Incident Analysis of Compromised OpenBSD 3.0 Honeypot

4. Forwarding ALL port ranges to your honeypot, excluding
the ones you really use on the gateway. Possibly my favorite
model; there are many pros and very few cons.

Pros: Cons: It's an extremely odd way to have a system set up realistically. If the hacker is good enough to figure out what's going on it will look rather suspicious!

Note: OpenBSD's PF has NAT rules that allow for simple forwarding of all your un-used port
ranges. You don't have to type in an individual rule for each port! See the pf.conf man page
for more details. I'm fairly sure Linux's ipmasq can provide similar functionality as well if
that's what you prefer.

5. Exposing your honeypot directly to the internet
with its own IP address and having your monitoring station
connected to the same hub with a different IP address

(note: a hub, not a switch; to allow for listening in to take place).
This is what I like to call the Man-on-the-side method, as apposed to the first four which are all man-in-the-middle (having the monitoring station sitting beside the honeypot listening as apposed to having the monitoring station in between the hacker and the honeypot)

Pros: Your honeypot's internet connection is 100% pure/realistic as far as the hacker is concerned. There's nothing in the middle watching over things that they may find to be suspicious.

Pro/Con: Due to the raw/exposed connection your hacker will have via this access method there's nothing about the access-method itself that would tip off a potential hacker as it's possibility of being a honeypot, thus increasing it's potential to snag a more sophisticated hacker.



While there are several different possible methods out there for providing access to your honeypot, the ones you have just read about are the most common and effective methods to date. It's clear not all possible pros/cons were mentioned for each method, but this was done intentionally to point out the fact that all the pros/cons are by nature subjective anyway. The way you set up your bait may not be the way your hacker perceives it, which in the end is the determining factor of who will hack your honeypot and who will be turned away by it.