Over the past several years there has been a growing interest in honeypots and honeypot-related technologies. Honeypots are not a new technology, they were first explained in a couple of very good papers by several icons in computer security: Cliff Stoll's book "The Cuckoo's Egg", and Steve Bellovin and Bill Cheswick's "An Evening with Berferd." This two-part series will attempt to take these works further and discuss what honeypots are, how they can add value to an organization, and several honeypot solutions. There are a variety of misconceptions on what a honeypot is, how it works, and how it adds value. It is hoped that this series will help clear up these issues.
Before we jump into the paper, we should first agree on several definitions. Far too often I've seen people arguing about honeypots on mailing lists. What is so amusing is that they are clearly talking about two entirely different concepts. If they had taken a moment to agree on what they were arguing about first, life would have been much simpler for everyone (including my mailbox.) To make sure we are all on the same page, I would like to first set forth some definitions, particularly the definition of a honeypot, the two different types of honeypots, and the different categories of security.
For the purposes of this paper, we will define a honeypot as "a resource whose value is being in attacked or compromised". This means that whatever we designate as a honeypot, it is our expectation and goal to have the system probed, attacked, and potentially exploited. Keep in mind, honeypots are not a solution, they do not 'fix' anything. Instead, honeypots are a tool, how you use that tool is up to you and depends on what you are attempting to achieve. Honeypots may be a system that merely emulates other systems or applications, creates a jailed environment, or may be standard built systems. Regardless of how you build and use the honeypot, it's value lies in the fact that it is attacked.
We will break honeypots into two broad categories, as defined by Snort creator Marty Roesch. Marty pointed out to me that the two types of honeypots are "production" and "research", a breakdown I found to be very useful. 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. The second category, research, includes honeypots that are designed to gain information on the blackhat community. These honeypots do not add direct value to a specific organization; instead, they are used to gather intelligence on the general threats organizations may face, allowing the organization to better protect against those threats.
Before discussing how honeypots add value to security, let's first define what we mean by security. Simpy put, security is the reduction of risk. One can never eliminate risk, but security helps reduce risk to an organization and its information-related resources. When discussing security, I like to break it down into three areas, as defined by the infamous Bruce Schneier in his book Secrets and Lies:
- Prevention: we want to stop the bad guys. If you were to secure your house, prevention would be similar to placing dead bolt locks on your doors, locking your window, and perhaps a chain link fence around your yard. You are doing everything possible to keep the threat out.
- Detection: we want to detect the bad guys if and when they get through our security measures. Sooner or later, prevention will fail: you want to be sure you detect when failure happens. Once again using the house analogy, this would be similar to putting a burglar alarm and motion sensors in the house. These alarms go off when someone breaks in. If prevention fails, you want to be alerted to that as soon as possible.
- Reaction: we want to react to the bad guys once we detect them. Detecting the failure has little value if you do not have the ability to respond. What good does it to be alerted to a burglar if nothing is done? If someone breaks into your house and sounds the burglar alarm, one hopes that the local police force can quickly respond. The same principle applies to information security, once you have detected a failure, you must have an effective incident response.
Now that we have a better idea of what security is, let's see how honeypots add value to each of these three categories.
Value of Honeypots
A honeypot's greatest value lies in its simplicity, it's a device that is intended to be compromised. This means that there is little or no production traffic going to or from the device. Any time a connection is sent to the honeypot, it is most likely to be a probe, scan, or even attack. Any time a connection is initiated from the honeypot, this most likely means the honeypot was compromised. As there is little production traffic going to or from the honeypot, all honeypot traffic is, by definition, suspicious. Now, this is not always the case. Mistakes do happen, such as an incorrect DNS entry or someone from accounting inputting the wrong IP address. But in general, most honeypot traffic is represents unauthorized activity.
Because of this simplistic model, honeypots have certain inherent advantages and disadvantages. We will discuss a few of them.
Advantage #1 - Data Collection
Honeypots collect very little data, and what they do collect is normally of high value. This cuts the noise down, make it much easier to collect and archive data. One of the greatest problems in security is wading through gigabytes of meaningless data to find something meaningful. Honeypots can give users the exact information they need in a quick and easy to understand format. For example, the Honeynet Project, a group researching honeypots, collects on average only 1-5 MB of data per day. This information is normally of high value, as it shows not only network activity, but also the attacker's activities once he or she gets on the system. We will explore this advantage in greater depth in when we discuss how honeypots add value to detection.
Advantage #2 - Resources
Many security tools can be overwhelmed by bandwidth or activity. Network Intrusion Detection Devices may not be able to keep up with network activity, dropping packets, and potentially attacks. Centralized log servers may not be able to collect all the system logs, potentially dropping logs. Honeypots do not have this problem, they only capture that which comes to them.
Disadvantage #1 - Single Point
Honeypots all have one common problem: they are worthless if no one attacks them. Yes, they can accomplish wonderful things; but if the attacker does not send any packets to the honeypot, it will be blissfully unaware of any unauthorized activity.
Disadvantage #2 - Risk
Honeypots can introduce risk into the user's environment. As we discuss later in this series, different honeypots have different levels of risk. Some introduce very little risk, while others give the attacker entire platforms to launch new attacks. Risk is variable, depending on how one builds and deploys the honeypot.
It is because of these disadvantages that honeypots do not replace any security mechanisms. They can only add value by working with existing security mechanisms. Now that we have reviewed the overall value of honeypots, lets apply them to security.
As we discussed earlier, there are two types of honeypots, production and research. We will first discuss what a production honeypots and their value. Then we will discuss research honeypots and their value. A production honeypot is one used within an organization's environment to help mitigate risk, it has value to the security of production resources. Let's take a look at how production honeypots apply to the three areas of security: prevention, detection, and reaction.
I personally feel honeypots add little value to prevention: honeypots will not help keep the bad guys out. What will keep the bad guys out is good security practices, such as disabling unnecessary or insecure services, patching services that are needed, and using strong authentication mechanisms. A honeypot, a system to be compromised, will not help keep the bad guys out. In fact, if incorrectly implemented, a honeypot may make it easier for an attacker to get in.
Some individuals have discussed the value of deception as a method to deter attackers. The idea underlying this concept is to have attackers spend time and resource attacking honeypots instead of attacking production systems. The attacker is deceived into attacking the honeypot, thus drawing away resources that may have been used for attacking production resources. While this may prevent attacks on production systems, I feel that most organizations are much better off spending their limited time and resources securing their systems, as opposed to deceiving would-be attackers.
Perhaps more importantly, deception will fail against the most common of attacks: automated toolkits and worms. These days, more and more attacks are automated. These automated threats will probe, attack, and exploit anything they can find vulnerable. Yes, these threats will attack a honeypot, but they will also just as quickly attack every other system in your organization. If you have a coffee pot with an IP stack, it will be attacked. Deception will not prevent these attacks, as there is no individual to deceive. As such, I feel that honeypots add little value to prevention, organizations are better off focusing their resources on good security practices.
While honeypots add little value to prevention, I feel they add extensive value to detection. For many organizations, it is extremely difficult to detect attacks. Organizations can be so overwhelmed with production activity, such as gigabytes of system logging, that they may have difficulty detecting when a system has been attacked or exploited.
Intrusion Detection Systems are designed to detect attacks. However, IDS administrators can be overwhelmed with false positives, alerts that are mistakenly generated when a sensor perceives and alerts on an attack that is actually valid traffic. False positives are dangerous because system administrators receive so many alerts that they become inured to the alerts, as they are falsely alerted day after day, similar to "the boy who cried wolf". if false positives are not effectively reduced, system administrators may simply start ignoring alerts issued by IDS sensors. This does not mean that honeypots will never have false positives, only that they will be dramatically lower than in most IDS implementations.
Another risk posed by Intrusion Detection Systems is false negatives, which occur when IDS systems fail to detect a valid attack. Honeypots eliminate false negatives, as they are not easily evaded or defeated by new exploits. In fact, one of their primary values is that they can detect new or unknown attacks. Administrators do not have to worry about updating signature database or patching anamoly detection engines. Honeypots happily capture any attacks that come their way. As discussed earlier though, this only works if the honeypot itself is attacked.
Honeypots can simplify the detection process. Since honeypots have no production activity, all connections to and from the honeypot are suspect by nature. By definition, anytime a connection is made to your honeypot, it is most likely an unauthorized probe, scan, or attack. Anytime the honeypot initiates a connection, this most likely means the system was successfully compromised. This helps reduce both false positives and false negatives, greatly simplifying the detection process. By no means should honeypots replace your IDS systems or be the sole method of detection; however, they can be a powerful tool to complement intrusion detection capabilities.
Though not commonly considered, honeypots also add value to reaction. Often when an organization is compromised, so much production activity has occurred after the fact, that the data has become polluted. The Incident Response Team cannot determine what happened if users and systems have polluted the collected data. For example, I have often come onto sites to assist in incident response, only to discover that hundreds of users had continued to use the compromised system. Evidence is far more difficult to gather in such an environment. The second challenge many organizations face after an incident is that compromised systems cannot be taken off-line. The production services they offer cannot be eliminated. As such, incident response teams cannot conduct a proper or a full forensic analysis.
Honeypots can add value by reducing both of these problems. They offer a system with reduced data pollution and an expendable system that can be taken off-line. For example, let's say an organization has three Web servers, all of which were compromised by an attacker. However, management has only allowed Incident Response personnel to go in and clean up specific holes: they can never learn in detail what failed, what damage was done, whether an attacker still had internal access, and if they were truly successful in cleanup. However, if one of those three systems was a honeypot, the Incident Response people would have a system they could take off-line in order to conduct a full forensic analysis. Based on that analysis, they could learn not only how the bad guy got in, but also what he did once he was in there. These lessons could then be applied to the remaining Web servers, allowing them to better identify and recover to the attack.
As discussed at the beginning, there are two categories of honeypots: production and research. We have already discussed how production honeypots can add value to an organization. We will now discuss how research honeypots add value.
One of the greatest challenges the security community faces is lack of information on the enemy, information such as: who is the threat, why do they attack, how do they attack, and when? It is questions like these that the security community often cannot answer. Organizations such as the military, NSA or the FBI spend billions of dollars on intelligence gathering capabilities because intelligence is such a critical asset. To defeat a threat, you have to first know about it. However, in the information security world we have little such information.
Honeypots can add value in research by giving us a platform to study the threat. What better way to learn about the bad guys then to watch them in action, to record step-by-step as the attack and compromise a system. Of even more value is watching what they do after they compromise a system, such as communicating with other blackhats or uploading a new tool kit. This intelligence gathering is one of the most unique and exciting characteristics of honeypots. Also, research honeypots are excellent tools for capturing automated attacks, such as auto-rooters or Worms. Since these attacks target entire network blocks, research honeypots can quickly capture these attacks for analysis.
The lessons learned from a research honeypot can be applied to improve attack prevention, detection or reaction. However, research honeypots contribute little to the direct security of an organization. If an organization is looking to improve the security of their production environment, they may want to consider production honeypots, as they are easy to implement and maintain. That said, if an organization, such as a universities, governments, or large corporationss are interested in learning more about threats research, honeypots would be a useful research tool. The Honeynet Project is one such example of an organization using research honeypots to gain intelligence on the blackhat community.
That wraps up our brief overview of honeypots, as well as the discussion of some their inherent strengths and weaknesses. In the next article in this series, we will take a look at some examples of different types of honeypots. We will also briefly discuss some important legal isues associated with honeypots and their use.
To read The Value of Honeypots, Part Two, click here.
Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at email@example.com .