Tuesday, 30 December 2014


The first step to understanding honeypots is defining what a honeypot is. This can be harder then it sounds. Unlike firewalls or Intrusion Detection Systems, honeypots do not solve a specific problem. Instead, they are a highly flexible tool that comes in many shapes and sizes. They can do everything from detecting encrypted attacks in IPv6 networks to capturing the latest in on-line credit card fraud. Its is this flexibility that gives honeypots their true power. It is also this flexibility that can make them challenging to define and understand. As such, I use the following definition to define what a honeypot is.

A honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource.

A honeypot is valuable as a surveillance and early-warning tool. While it is often a computer, a honeypot can take other forms, such as files or data records, or even unused IP address space. A honeypot that masquerades as an open proxy to monitor and record those using the system is known as a "sugarcane". Honeypots should have no production value, and hence should not see any legitimate traffic or activity. Whatever they capture is therefore malicious or unauthorized. One practical application of this is the spamtrap - a honeypot that thwarts spam by masquerading as a type of system abused by spammers. These honeypots categorize trapped material 100% accurately: it is all illicit.

Honeypots can carry risks to a network, and must be handled with care. If they are not properly walled off, an attacker can use them to break into a system.

Victim hosts are an active network counter-intrusion tool. These computers run special software, designed to appear to an intruder as being important and worth looking into. In reality, these programs are dummies, and their patterns are constructed specifically to foster interest in attackers. The software installed on, and run by, victim hosts is dual purpose. First, these dummy programs keep a network intruder occupied looking for valuable information where none exists, effectively convincing an intruder to isolate themselves in what is truly an unimportant part of the network. This decoy strategy is designed to keep an intruder from getting bored and heading into truly security-critical systems. The second part of the victim host strategy is intelligence gathering. Once an intruder has broken into the victim host, the machine or a network administrator can examine the intrusion methods used by the intruder. This intelligence can be used to build specific countermeasures to intrusion techniques, making truly important systems on the network less vulnerable to intrusion.

Honeypots can be classified based on their deployment and based on their level of involvement. Based on the deployment, honeypots may be classified as

   1. Production Honeypots
   2. Research Honeypots

Production honeypots are easy to use, capture only limited information, and are used primarily by companies or corporations; Production honeypots are placed inside the production network with other production servers by an organization to improve their overall state of security. Normally, production honeypots are low-interaction honeypots, which are easier to deploy. They give less information about the attacks or attackers than research honeypots do. The purpose of a production honeypot is to help mitigate risk in an organization. The honeypot adds value to the security measures of an organization.

Research honeypots are run by a volunteer, non-profit research organization or an educational institution to gather information about the motives and tactics of the Blackhat community targeting different networks. These honeypots do not add direct value to a specific organization. Instead they are used to research the threats organizations face, and to learn how to better protect against those threats. This information is then used to protect against those threats. Research honeypots are complex to deploy and maintain, capture extensive information, and are used primarily by research, military, or government organizations.

Just as honeypots are weapons against spammers, honeypot detection systems are spammer-employed counter-weapons. As detection systems would likely use unique characteristics of specific honeypots to identify them, a great deal of honeypots in use makes the set of unique characteristics larger and more daunting to those seeking to detect and thereby identify them. This is an unusual circumstance in software: a situation in which "versionitis" (a large number of versions of the same software, all differing slightly from each other) can be beneficial. There's also an advantage in having some easy-to-detect honeypots deployed. Fred Cohen, the inventor of the Deception Toolkit, even argues that every system running his honeypot should have a deception port that adversaries can use to detect the honeypot. Cohen believes that this might deter adversaries.

Two or more honeypots on a network form a honeynet. Typically, a honeynet is used for monitoring a larger and/or more diverse network in which one honeypot may not be sufficient. Honeynets and honeypots are usually implemented as parts of larger network intrusion detection systems. A honeyfarm is a centralized collection of honeypots and analysis tools.

The concept of the honeynet first began in 1999 when Lance Spitzner, founder of the Honeynet Project, published the paper "To Build a Honeypot":

    "A honeynet is a network of high interaction honeypots that simulates a production network and configured such that all activity is monitored, recorded and in a degree, discreetly regulated"


Honey Drive : HoneyPot In the Box, HoneyDrive is a virtual hard disk drive (VMDK format) with Ubuntu Server 11.10 32-bit edition installed. It contains various honeypot systems such as Kippo SSH honeypot, Dionaea malware honeypot and Honeyd. Additionally it includes useful scripts and utilities to analyze and visualize the data it captures. Lastly, other helpful tools like tshark (command-line Wireshark), pdftools, etc. are also present.

Announcing HoneyDrive!

UPDATE: This post was about the server version of HoneyDrive which is no longer maintained. I have now released a HoneyDrive Desktop version based on Xubuntu Linux.

HoneyDrive is a virtual hard disk drive (VMDK format) with Ubuntu Server 11.10 32-bit edition installed. It contains various honeypot systems such as Kippo SSH honeypot, Dionaea malware honeypot and Honeyd. Additionally it includes useful scripts and utilities to analyze and visualize the data it captures. Lastly, other helpful tools like tshark (command-line Wireshark), pdftools, etc. are also present.

NOTE: The description is not very accurate for the current state of HoneyDrive. Right now only Kippo SSH honeypot and its related tools are included, but all of the above will be present in future releases.

You can get the latest version (0.1) of HoneyDrive which contains Kippo SSH honeypot and related scripts (kippo-graph, kippo-stats, kippo-sessions, etc). Everything is pre-configured to work. Due to its size the file is hosted at SourceForge: http://sourceforge.net/projects/honeydrive/

Please also take a look at the README.txt file at SourceForge (also included inside the disk) to learn the specific features and where everything is located.

After downloading the file, you must uncompress it and then you simply have to create a new virtual machine (suggested software: Oracle VM VirtualBox) and select the VMDK drive as its hard disk.
As always, feedback is always welcomed, using the related page: http://bruteforce.gr/honeydrive


Value of Honeypots:

Now that we have understanding of two general categories of honepyots, we can focus on their value. Specifically, how we can use honeypots. Once again, we have two general categories, honeypots can be used for production purposes or research. When used for production purposes, honeypots are protecting an organization. This would include preventing, detecting, or helping organizations respond to an attack. When used for research purposes, honeypots are being used to collect information. This information has different value to different organizations. Some may want to be studying trends in attacker activity, while others are interested in early warning and prediction, or law enforcement. In general, low-interaction honeypots are often used for production purposes, while high-interaction honeypots are used for research purposes. However, either type of honeypot can be used for either purpose. When used for production purposes, honeypots can protect organizations in one of three ways; prevention, detection, and response. We will take a more in-depth look at how a honeypot can work in all three.

Honeypots can help prevent attacks in several ways. The first is against automated attacks, such as worms or auto-rooters. These attacks are based on tools that randomly scan entire networks looking for vulnerable systems. If vulnerable systems are found, these automated tools will then attack and take over the system (with worms self-replicating, copying themselves to the victim). One way that honeypots can help defend against such attacks is slowing their scanning down, potentially even stopping them. Called sticky honeypots, these solutions monitor unused IP space. When probed by such scanning activity, these honeypots interact with and slow the attacker down. They do this using a variety of TCP tricks, such as a Windows size of zero, putting the attacker into a holding pattern. This is excellent for slowing down or preventing the spread of a worm that has penetrated your internal organization. One such example of a sticky honeypot is LaBrea Tarpit. Sticky honeypots are most often low-interaction solutions (you can almost call them 'no-interaction solutions', as they slow the attacker down to a crawl :). Honeypots can also be protect your organization from human attackers. The concept is deception or deterrence. The idea is to confuse an attacker, to make him waste his time and resources interacting with honeypots. Meanwhile, your organization has detected the attacker's activity and have the time to respond and stop the attacker. This can be even taken one step farther. If an attacker knows your organization is using honeypots, but does not know which systems are honeypots and which systems are legitimate computers, they may be concerned about being caught by honeypots and decided not to attack your organizations. Thus the honeypot deters the attacker. An example of a honeypot designed to do this is Deception Toolkit, a low-interaction honeypot.

The second way honeypots can help protect an organization is through detection. Detection is critical, its purpose is to identify a failure or breakdown in prevention. Regardless of how secure an organization is, there will always be failures, if for no other reasons then humans are involved in the process. By detecting an attacker, you can quickly react to them, stopping or mitigating the damage they do. Tradtionally, detection has proven extremely difficult to do. Technologies such as IDS sensors and systems logs haven proven ineffective for several reasons. They generate far too much data, large percentage of false positives, inability to detect new attacks, and the inability to work in encrypted or IPv6 environments. Honeypots excel at detection, addressing many of these problems of traditional detection. Honeypots reduce false positives by capturing small data sets of high value, capture unknown attacks such as new exploits or polymorphic shellcode, and work in encrypted and IPv6 environments. You can learn more about this in the paper Honeypots: Simple, Cost Effective Detection. In general, low-interaction honeypots make the best solutions for detection. They are easier to deploy and maintain then high-interaction honeypots and have reduced risk.

The third and final way a honeypot can help protect an organization is in reponse. Once an organization has detected a failure, how do they respond? This can often be one of the greatest challenges an organization faces. There is often little information on who the attacker is, how they got in, or how much damage they have done. In these situations detailed information on the attacker's activity are critical. There are two problems compounding incidence response. First, often the very systems compromised cannot be taken offline to analyze. Production systems, such as an organization's mail server, are so critical that even though its been hacked, security professionals may not be able to take the system down and do a proper forensic analysis. Instead, they are limited to analyze the live system while still providing production services. This cripiles the ability to analyze what happend, how much damage the attacker has done, and even if the attacker has broken into other systems. The other problem is even if the system is pulled offline, there is so much data pollution it can be very difficult to determine what the bad guy did. By data pollution, I mean there has been so much activity (user's logging in, mail accounts read, files written to databases, etc) it can be difficult to determine what is normal day-to-day activity, and what is the attacker. Honeypots can help address both problems. Honeypots make an excellent incident resonse tool, as they can quickly and easily be taken offline for a full forensic analysis, without impacting day-to-day business operations. Also, the only activity a honeypot captures is unauthorized or malicious activity. This makes hacked honeypots much easier to analyze then hacked production systems, as any data you retrieve from a honeypot is most likely related to the attacker. The value honeypots provide here is quickly giving organizations the in-depth information they need to rapidly and effectively respond to an incident. In general, high-interaction honeypots make the best solution for response. To respond to an intruder, you need in-depth knowledge on what they did, how they broke in, and the tools they used. For that type of data you most likely need the capabilities of a high-interaction honeypot.