Case Study includes the different types of honeypots. With
evaluation and different types of honeypots including the
low interaction and high interaction.
This Case Study presents an evaluation of honeypots used for gathering
information about the methods used by attackers to compromise a host. Honeypots
are an important utility to learn more about attackers. There are several types of
honeypots which can be used for gathering information about the tools and
methods used by attackers to compromise a server. This paper will evaluate these
The focus will be on the virtual honeypots, because they are a rather new concept.
We will compare them to the other types of honeypots to find out if the
information gathered from the virtual honeypots is just as useful as from the other
honeypots. We will see that there are even more possibilities with virtual
honeypots than with low interaction and high interaction honeypots.
Countermeasure to detect or prevent attacks
Know attack strategies
Gather information which is then used to better identify,
understand and protect against threats.
Divert hackers from productive systems
A Honeypot is a security resource whose value is in being probed, attacked or
A honeypot is a resource which pretends to be a real target. A honeypot is
expected to be attacked or compromised. The main goals are the distraction of an
attacker and the gain of information about an attacker, his methods and tools.
In this section we will discuss the criteria which will be used to evaluate different
types of honeypots. We will come to these criteria by distilling the information from
the literature we found on the topic of honeypots.
A big difference between honeypots is the degree on how much control an attacker
can get once he compromised a honeypot. The more control an attacker can have, the
more you can learn about his motives and techniques. This criterion will be used in
the evaluation of different types of honeypots.
Two categories of Honeypots methodology
Low Interaction - Low interaction honeypots are limited in their extent of
interaction. They are actually emulators of services and operating systems,
whereby attacker activity is limited to the level of emulation by the
honeypot. This keeps the host operating system uncompromised. Logs of
the attacker are kept on the host’s file system, relatively save from
manipulation. The deployment and maintenance of these systems are
simple and do not involve much risk. Unfortunately low interaction
systems log only limited information and are designed to capture known
activity. An attacker can detect a low interaction honeypot by executing a
command that the emulation does not support.
Eg. Specter, Honeyd and KFSensor.
Specter, low interaction honeypot software
Next we will look into the deployment of a low interaction honeypot. McGrew et al deployed the low interaction
honeypot Specter ([GV06]). With this honeypot they tried to gather information on the network of the Mississippi State
University about the type and source of attacks as well as the amount of time that a machine can expect to be online
before being attacked. They deployed the honeypot on the network behind the university’s firewall and on an IP
address outside of the university’s firewall.
The results of the research done by are about two situations, the honeypot behind the firewall and the honeypot directly
connected to the internet. The results from the tests with the honeypot behind the firewall were not interesting. In the
two-week period no activity was logged by the low interaction honeypots behind the firewall.
More interesting were the results of the honeypots directly connected to the internet. The first week of the Solaris
honeypot, the first anomalous connection was observed after 2 hours and 40 minutes after connecting to the internet.
The second week the honeypot emulated a Windows XP host. After 14 minutes the first anomalous connection was
observed. The Solaris honeypot logged an average of one attack every 1 hour and 26 minutes, during a period of 7
days. The Windows XP honeypot also logged for a period of 7 days and had an average of one attack every 48 minutes.
The most attacks on the Windows XP honeypot were on the Microsoft IIS web server service.
Honeyd, low interaction honeypot framework
Another research on low interaction honeypots has been done by Provos [PROV04]. Provos used the
Honeyd framework for their research. They limited attackers to interacting with their honeypots only at the
network level. They did not emulate every aspect of an operating system. Instead they choose to simulate
only the network stack of a certain operating system. The main reason for this approach is that an attacker
never gains complete access to the system even if he compromises a simulated service.
With this approach they are still able to capture connection and compromise attempts.
High Interaction - . High interaction honeypots utilize actual operating systems rather than emulations
like the low interaction honeypots. Because actual operating systems are utilized, the attacker gets a more
realistic experience and we can gather more information about intended attacks. This makes high interaction
honeypots very useful in situations where one wishes to capture details of vulnerabilities or exploits that are
not yet known to the public. These vulnerabilities or exploits are being used only by a small number of
attackers who discovered the vulnerability and wrote an exploit for it.It is very important to find and
publicize these vulnerabilities quickly, so that system administrators can filter or work around these
problems. Also vendors can develop and release software patches to fix these vulnerabilities.
High interaction honeypots provide information on the motives, tools, and techniques of the attackers. This is
another advantage of these types of honeypots. Other systems like firewall logs, IDS alerts, and low
interaction honeypots can log a large number of attacks. A large percentage of these attacks will effectively
be not interesting.
A generation II high interaction honeypot
The most difficult issue of these honeypots is the provisions that must be made for data control and
data capture. Because these systems are complete operating systems, if an attacker takes control over
this system, appropriate measures must have been taken to limit the attacker’s ability to launch attacks
from this honeypot system. If attacks targeting other production machines, whether within the
organization or outside the organization, the honeypot becomes a major liability. That is why some put
a firewall in front of the high interaction honeypots, which blocks all outbound connections. These
limitations can hinder the progress of the attacker, resulting in less informative data being captured
and potentially alerting attackers to the possibility that they are being watched.
McGrew et al used “Generation II” techniques for data control ([HOG05]). This involves a machine
separate from the honeypot acting as a layer 2 bridging firewall, called a “Honeywall”. Out-bound
connections from the honeypot are restricted by this Honeywall. The Honeywall utilizes a special in-
line version of the Snort IDS to detect known attacks and either block or “mangle” them by modifying
key elements of the attack to prevent them from being successful. The Honeywall prevents the
honeypot from being used as a significant contribution to denial -of-service attacks by limiting the
bandwidth and the number of established connections of the honeypot.
File system changes on high interaction honeypots
This gives some great opportunities for evidence reconstruction. For example to obtain all the files
created by an attacker, once he compromised the system. Or a report can be generated of all the files
altered by the attacker, with the content of the alteration. Another possibility is to create a timeline,
containing the complete evolution of a set of files or even the entire file system. However, for making
a complete evolution timeline of the entire file system, a local copy of the honeypots original file
system is needed, for the evidence reconstruction.
In the previous section we talked about high interaction honeypots. When you want to deploy a
complete honeynet with high interaction honeypots running different operating systems, this can
become quite expensive. Because you will need a physical machine for every honeypot. Today,
server virtualization is emerging as one of the most popular options for reducing costs ([ITB06]).
Virtualizations offers also some other useful possibilities for honeypots. This is why virtual
machines are becoming more common as honeypots. Software used for the virtualization include
VMWare ([VM06]), User Mode Linux ([UML06]), and Microsoft’s Virtual PC ([MSV06]).
One of the advantages of using virtual servers is
that they are easy to fix and isolate, and that you
can emulate several systems on a single
machine. Numbers like two or three virtual
systems per physical machine are very common.
This makes it possible to create a complete
honeynet on one physical machine, a virtual
The Honeynet Project defines two types of virtual honeynets, self-contained and hybrid ([HOV03]). A self-
contained virtual honeynet is an entire honeynet network onto a single machine, see figure 1. This means that
both the Honeywall and the honeypots are on the same machine. This also brings a risk. If an attacker somehow
discovered the host machine andcompromised it, your complete honeynet will be useless. So you have a Single
Point of Failure. If something goes wrong with the hardware for example, your whole honeynet will be down.
Figure 1. A self-contained virtual honeynet setup
There is the hybrid virtual honeynet. With hybrid virtual honeynet, the Honeywall is a separate machine,
illustrated in figure 2. All the honeypots are on running on the same machine using virtualization. This solution
is more secure, because the attacker could only access the other honeypots on the virtual machine. The
Honeywall will be save on a separate machine. But this makes this solution also less portable then a self-
contained virtual honeynet.
Figure 2. A hybrid virtual honeynet setup
Examples of honeypots
Examples of freeware honeypots include:
1. Deception Toolkit6: DTK was the first Open Source honeypot released in 1997. It is a collection of Perl
scripts and C source code that emulates a variety of listening services. Its primary purpose is to deceive
2. LaBrea7: This is designed to slow down or stop attacks by acting as a sticky honeypot to detect and trap
worms and other malicious codes. It can run on Windows or Unix.
3. Honeywall CDROM8: The Honeywall CDROM is a bootable CD with a collection of open source
software. It makes honeynet deployments simple and effective by automating the process of deploying a
honeynet gateway known as a Honeywall. It can capture, control and analyse all inbound and outbound
4. Honeyd9: This is a powerful, low-interaction Open Source honeypot, and can be run on both UNIX-like
and Windows platforms. It can monitor unused IPs, simulate operating systems at the TCP/IP stack level,
simulate thousands of virtual hosts at the same time, and monitor all UDP and TCP based ports.
Examples of honeypots.
5. Honeytrap10 : This is a low-interactive honeypot developed to observe attacks against network
services. It helps administrators to collect information regarding known or unknown network-based
Examples of honeypots cont.
6. HoneyC11: This is an example of a client honeypot that initiates connections to a server, aiming to
find malicious servers on a network. It aims to identify malicious web servers by using emulated
clients that are able to solicit the type of response from a server that is necessary for analysis of
7. HoneyMole12: This is a tool for the deployment of honeypot farms, or distributed honeypots, and
transport network traffic to a central honeypot point where data collection and analysis can be
A Valuable Resource
To be Compromised
Gains Info. About Attackers and their Strategies
Need for Tight Supervision
Honeypot is primarily a research tool, but also has a real commercial applications. The
honey pot set in the company's Web or mail server IP address on the adjacent, you can
understand that it suffered the attack.
reduce the data to be analyzed. For the usual website or mail server, attack traffic is
usually overwhelmed by legitimate traffic. Thus, browsing data to identify the actual
behavior of the attacker also much easier.
[DVK+06] P. Defibaugh-Chavez, R. Veeraghattam, M.Kannappa, S. Mukkamala, A. H. Sung,
“NetworkBased Detection of Virtual Environments and low Interaction Honeypots”, In 2006 IEEE
InformationAssurance Workshop, pages 283-289, IEEE, 2006.
[GV06] R. McGrew, R.B. Vaughn, Experiences With HoneypotSystems: Development, Deployment, and
Analysis,System Sciences, 2006. Proceedings of the 39th Annual Hawaii International Conference, pages
220a-220a, IEEE, 2006.
[HOG05] The Honeynet Project, Know Your Enemy: GenIIHoneynets,
http://www.honeynet.nl/papers/gen2/index.html (07-12-2006), The Honeynet Project 2005.
[Hon06] Honeynet Project, “Know your Enemy: Honeynets”,
http://www.honeynet.nl/papers/honeynet/index.html, (3-10-2006), Honeynet Project, 2006.