honeynet Project
http://www.honeynet.org
Last Modified: 31 May, 2006
One of the primary tools used by the Honeynet Project and Research Alliance to capture information is
the honeynet. The purpose of this paper is to discuss what a honeynet is, its value,
an overview of how it works, and the risks/issues involved. This paper is not a technical
blueprint on how a honeynet works. Instead, this paper is a initial introduction to the
concepts and issues. This paper is the first in a series of three documents. If after
reading this paper you want to learn more about honeynets, and specifically honeywalls and
how they work, we recommend you read the
second paper in the series,
KYE: Honeywall CDROM. Finally, if you are interested
in actually deploying such a technoloty, after you have read these first two papers, the final
and third document you will want to read is the Online User
Manual. Whatever your technical knowledge or skill level, it is highly recommended
you read this paper first. It is critical you understand the concepts, risks and issues
of a honeynet before deploying such a technology.
Honeynet Overview
A honeynet is a type of honeypot.
Specifically, it is a high-interaction honeypot designed to capture extensive information
on threats. High-interaction means a honeynet provides real systems, applications, and
services for attackers to interact with, as opposed to low-interaction honeypots such as
Honeyd or Nepenthes
which provide emulated services and operating systems. It is through this extensive interaction
we gain information on threats, both external and internal to an organization. What makes
a honeynet different from most honeypots is that it is a network of real computers
for attackers to interact with.
These victim systems (honeypots within the honeynet) can be any type of system, service,
or information you want to provide. If you want to create Oracle databases on Solaris
servers, not a problem. If you want to create a e-commerce site using IIS webserver on
Windows 2003, not a problem. You can run everything from VAX systems to Cisco routers.
Its is this flexibility that gives honeynets their true power.
Conceptually honeynets are very simple, they are a network
that contains one or more honeypots. Since honeypots are not production
systems, the honeynet itself has no production activity, no
authorized services. As a result, any interaction with a honeynet implies
malicious or unauthorized activity. Any connections intiated inbound to your honeynet are
most likely a probe, scan, or attack. Any unauthorized outbound connections
from your honeynet imply someone has compromised a system and has initiated outbound activity.
This makes analyzing activity within your honeynet very simple. With traditional
security technologies, such as firewall logs or IDS sensors, you have to sift
through gigabytes of data, or thousands of alerts. A great deal of time and
effort is spent looking through this information, attempting to eliminate false
positives while identifying attacks or unauthorized activty. In many ways, its the classic
needle in the haystack
problem, as you attempt to find the critical incident amongst volumes of information.
Since a honeynet is nothing more than a network of honeypots, all captured activity is assumed
to be unauthorized or malicious. All you are doing is capturing needles. Its up
to you to prioritize which of those needles has the greatest value to you, then
analyze them in great detail.
Honeynets are an architecture. This
architecture creates a highly controlled network, one that you can control and
monitor all activity that happens within it. You then place your target systems,
your honeypots, within that architecture. In many ways a honeynet is like a fishbowl. You
create an environment where you can watch everything happening inside it. However,
instead of putting rocks, coral, and sea weed in your fish bowl, you put Linux
DNS servers, HP printers, and Juniper routers in your honeynet architecture. Just
as a fish interacts with the elements in your fishbowl, intruders interact with
your honeypots.
Honeynet Architecture
Traditionally, information security has been primarily defensive. Firewalls, Intrusion
Detection Systems, encryption; all of these mechanisms are used defensively to protect
one's resources. The strategy is to defend one's organization as best as possible, detect
any failures in the defense, and then react to those failures. The problem with this approach
is it purely defensive, the enemy has the initiative. Honeynets attempt to change that.
The primary purpose of a honeynet is to gather information on threats. This information
has different value to different organizations. For example, academic research institutions
may use honeynets to gather data for research, such as worm activity.
Security organizations may use honeynets to capture and analyze malware for anti-virus,
IDS signatures or learn new ways to counter changing threats. Government organizations
may use honeynets to learn more about who is targeting them or why. ISP's may use honeynets
to capture, analyze, and terminate botnets that are on their networks. Security responders
can use honeynets for incident response, collecting information on a compromised systems.
The primary value of honeynets is information, that information will have different value to
you depending on who you are and your needs. Examples of the information collected
include the papers KYE: Tracking Botnets,
KYE: Phishing. and KYE: Motives.
As we stated earlier, honeynets are nothing more than an architecture. To succesfully deploy
a honeynet, you must correctly deploy the honeynet architecture. The key to the honeynet
architecture is what we call a honeywall. This is a gateway device that seperates your honeypots
from the rest of the world. Any traffic going to or from the honeypots must go through the
honeywall. This gateway is traditionally a layer 2 bridging device, meaning the device
should be invisible to anyone interacting with the honeypots. Below we see a diagram of this
architecture. Our honeywall has 3 interfaces. The first 2 interfaces (eth0 and eth1) are what
seperate our honeypots from everything else, these are bridged interfaces that have no IP stack.
The 3rd interface (eth2, which is optional) has an IP stack allowing for remote administration.
There are several key requirements that a honeywall must implement; Data Control, Data Capture, Data Analysis, Data Collection. Data Control defines how activity is contained with the honeynet without an attacker knowing it. Its purpose is to minimize risk. Data Capture is capturing all of the attacker's activity without the attacker knowing it. Data Analysis is the ability to analyze this data. Data Collection is the ability to collect data from multiple honeynets to a single source. Of all these requirements, Data Control is the more important. Data Control always takes priority as its role is to mitigate risk. We describe each in more detail below.
Risks and Issues
Honeynets can be a powerful tool. They allow you to collect extensive
information on a variety of threats. To obtain this information, you
have to allow attackers and malicious code access -- potentially privileged access -- to your
honeypots. As a result, the price you pay for this capability is risk.
Any technology developed by man (or woman) can also be defeated by man (or woman.)
Risk means different things to different organizations. You will have to identify
what risks are important to you. Also, organizations have different thresholds for risk.
We cannot determine what is right and wrong for you. Your organization will have to make
those policy decisions for itself. All we can do is help make you aware of the risks. Also,
we will not address legal issues of honeypots, or specifically honeynets. That is beyond the scope of this
paper, and is specific to your country and organization. If you are interested in
legal issues of honeypots, a good place to start is the legal chapter (which is
freely available to the public) from our book Know
Your Enemy: 2nd Edition.
We also recommend you seek your organization's legal counsel for more information,
especially in reference to privacy or liability issues. In reference to risk,
there are four general areas we will cover; harm, detection, disabling, and violation.
There are several measures you can take to mitigate these risks, beyond what we have discussed so far. Two measures are human monitoring and customization. By human monitoring, we mean you have a trained professional monitoring and analyzing your honeynet in real time. This gives you the ability to detect a failure in your system, a failure that automated mechanisms may fail to detect or react to. By having a human analyzing honeynet activity, instead of just depending on automated techniques, you help protect yourself against new or unknown attacks or honeynet countermeasures. A second measure is customization. This paper and all honeynet technologies, including the Honeywall CDROM are OpenSource and publicly available. This means that anyone has access to this information, including the blackhat community, which we can assume are actively reading this and developing countermeasures. To help reduce risk you want to modify your honeynet from any default settings or normal behavior. The more your honeynet differes from standard or default configurations, the more difficult it will be others for detect or attack it. However, its critical that you understand that no matter what measures you take, risk is not eliminated, only mitigated.
Conclusion
Honeynets are a form of a high-interaction honeypot. Their primary advantage is their ability
to gather extensive information. A honeynet is an architecture, similar
to a fishbowl. Within this architecture you can deploy any type of system or application
you desire. The critical requirements for this architecture are Data Control, Data Capture,
Data Analysis and Data Collection, with Data Control taking the priority. While very powerful, honeynets present
unique risks. Mechanisms can be put in place to mitigate these risks, but there is no way
to eliminate all risk, it is crtical you understand this. If you are still interested in deploying
a honeynet, the next step is to learn more about the Honeywall CDROM in our paper
KYE: Honeywall CDROM.