Traditionally, the area of information security has been purely defensive. Classic examples of the defensive mechanisms used to protect communication networks include firewalls, encryption and intrusion detection systems. The strategy follows the classical security paradigm of “Protect, Detect and React.” In other words, try to protect the network as best as possible, detect any failures in that defense, and then react to those failures.
The problem with this approach is that the attacker has the initiative, always being one step ahead. For example, traditional, signature-based anti-virus solutions have a hard time keeping up with the flood of new malware appearing each day (since the attackers can test new malware samples before releasing them into the wild). In the last few years, it has become more and more clear that these traditional, network-based defense techniques have severe limitations.
Thus, we need new techniques to improve network defenses. One promising approach is the use of honeypots, a closely monitored computing resource that we want to have probed, attacked or compromised. More precisely, a honeypot is “an information system resource whose value lies in monitoring unauthorized or illicit use of that resource”-this definition coming from the honeypot mailing list at SecurityFocus at http://www.securityfocus.com/archive/119/321957/30/0/threaded.
The Value of a Honeypot
The value of a honeypot is weighed by the information that can be obtained from it. Monitoring the data that enters and leaves a honeypot lets us gather information that is not available to an IDS. For example, we can log the keystrokes of an interactive session even if encryption is used to protect the network traffic. To detect malicious behavior, IDS requires signatures of known attacks and often fails to detect compromises that were unknown at the time it was deployed.
On the other hand, honeypots can detect vulnerabilities that are not yet understood, so-called “zero-day attacks.” For example, we can detect compromises by observing network traffic leaving the honeypot, even if the means of the exploit has never been seen before.
Honeypots can run any operating system and any number of services. The configured services determine the vectors available to an adversary for compromising or probing the system. A so-called “high-interaction honeypot” provides a real system with which the attacker can interact. In contrast, a “low-interaction honeypot” simulates only some parts; for example, the low-interaction honeypot “Honeyd” simulates the network stack of arbitrary systems.
High-Interaction vs. Low-Interaction Honeypots
High-interaction honeypots can be compromised completely, allowing an adversary to gain full access to the system and use it to launch further network attacks. With the help of these honeypots, you can, for example, learn more about targeted attacks against your systems-or even about insider attacks.
In contrast, low-interaction honeypots simulate only services that cannot be exploited to get complete access to the honeypot. Low-interaction honeypots are more limited, but they are useful for gathering information at a higher level; for example, to learn about network probes or worm activity within your network. Low-interaction honeypots can also be used to analyze spammers or for active countermeasures against worms. Please note, though, that neither approach is superior to the other. Each has unique advantages and disadvantages that we examine in our book “Virtual Honeypots: From Botnet Tracking to Intrusion Detection.”
After all, a honeypot is a concept and not a tool that you can simply deploy. You need to know in advance what you want to learn, and then you can customize a honeypot to your needs. In our book, we present several case studies on how to use different kinds of honeypots to protect a given network.
Physical vs. Virtual Honeypots
We also differentiate between physical and virtual honeypots. A physical honeypot is a real machine on the network with its own IP address. Physical often implies high interaction, thus allowing the system to be compromised completely. They are typically expensive to install and maintain. For large address spaces, it is impractical or impossible to deploy a physical honeypot for each IP address. In that case, we need to deploy virtual honeypots.
A virtual honeypot is simulated by another machine that responds to network traffic sent to the virtual honeypot. When gathering information about network attacks or probes, the number of deployed honeypots influences the amount and accuracy of the collected data. A good example is measuring the activity of HTTP-based worms: We can identify these worms only after they complete a TCP handshake and send their payload. However, most of their connection requests will go unanswered because they contact randomly chosen IP addresses. A honeypot can capture the worm payload by configuring it to function as a Web server or by simulating vulnerable network services. The more honeypots we deploy, the more likely one of them is contacted by a worm.
With the help of virtual honeypots, you can easily deploy a large number of honeypots. Furthermore, this kind of honeypot offers two additional advantages: scalability and ease of maintenance. We can have thousands of honeypots on just one machine. They are inexpensive to deploy and accessible to almost everyone. In our book, we discuss further about how to implement, configure, use and maintain virtual honeypots in your own environment-even if you have never deployed a honeypot before.
ABOUT THE AUTHORS:
Niels Provos and Thorsten Holz are co-authors of “Virtual Honeypots: From Botnet Tracking to Intrusion Detection” (Addison Wesley Professional, 2007).
Provos received a Ph.D. from the University of Michigan in 2003, where he studied experimental and theoretical aspects of computer and network security. He is one of the OpenSSH creators and known for his security work on OpenBSD. He developed Honeyd, a popular open-source honeypot platform; SpyBye, a client honeypot that helps Web masters detect malware on their Web page; as well as many other tools such as Systrace and Stegdetect. He is a member of the Honeynet Project and an active contributor to open-source projects. Provos is currently employed as senior staff engineer at Google. He can be reached at provos@gmail.com.
Holz is a Ph.D. student at the Laboratory for Dependable Distributed Systems at the University of Mannheim, Germany. He is one of the founders of the German Honeynet Project and a member of the Steering Committee of the Honeynet Research Alliance. His research interests include the practical aspects of secure systems, but he is also interested in more theoretical considerations of dependable systems. Currently, his work concentrates on bots/botnets, client honeypots and malware in general. He regularly blogs at http://honeyblog.org. He can be reached at thorsten.holz@gmail.com.