A honeypot is a decoy IT infrastructure component that is designed and deployed to be attacked. While the development of commercial honeypots seems to have lost steam, there is a plethora of innovative and freely available honeypot tools. Let's take a look at the pros and cons of using honeypots as part of a modern IT infrastructure.

The Value of Honeypots

As I discussed in my Stopping Malware on its Tracks article, they can strengthen the defensive posture of a mature enterprise in several ways:

• Slow down an intruder's progress by having him waste time breaking into a system that offers no value to the attacker. For instance, the free LaBrea tool stalls port scans and worm propagation activities by creatively responding to an attacker's network connections.
• Decrease the rate of false positives, which often plague network IDS. Since a honeypot, by definition, should not participate in production activities, almost any connection to it is an indication of malice. Free tools Honeyd and InetSim can emulate servers, devices, and even networks to increase the span of such monitoring without requiring multiple physical systems.
• Capture malware samples for analysis. Since malware is a part of most modern intrusions, capturing it before it finds its way to a production system assists in incident response. Free tools that can assist in this task include Nepenthes and Dionaea.
• Understand the intruder's intentions by observing his interactions with the compromised environment. This can be accomplished by deploying a series of honeypots to fool the intruder, whether a human or a program, about the authenticity of the targeted system. The bootable Honeywall disk, distributed for free by the Honeynet Project, can help enable this.

Note that in most cases, these examples refer to honeypots that are deployed on the internal network, rather than being directly accessible from the Internet.

For more honeypot tools, see my post Specialized Honeypots for SSH, Web and Malware Attacks.

The Challenges of Using Honeypots

Perhaps the biggest challenge of using honeypots is the risk that they might get compromised. In that case, they might be used to attack the organization that deployed them or to attack other organizations. This is, in part, why many organizations aren't using honeypots. However, a low-interaction honeypot that sits on an controlled network segment and is monitored by the security staff might present a sufficiently low risk, allowing the organization to begin experimenting with honeypots.

For an overview of honeypot technologies and deployment options, take a look at Anand Sastry's article Honeypots for network security: How to track attackers' activity. Anand advised that a high-interaction honeypot be deployed on a "separate network for the host OS for management purposes." In contrast, low-interaction honeypots are less likely to "be fully compromised by an attacker, thus making them easier to protect."

I recall attending an incident response talk by Richard Bejtlich, where he mentioned the usefulness of honeypots for intrusion detection. He recommended that only organizations that have mature security practices deploy honeypots. The implication is that there are other elements of the overall security incident cycle that should be considered beforehand.