What Are Honey Pots?

According to the general definition, a honey pot's goal is to emulate production servers while alerting and logging intruder activity. How it should achieve that goal, however, is open to interpretation. Examining six products that vendors are peddling as honey pots, I compiled the lowest common denominator of features among them.

All the honey-pot packages aim to provide a working facade capable of enticing would-be intruders into using the service, and then coaxing them into displaying malicious intent. The extent of emulation offered by the packages varies (see "Honey Pots for Sale" for more details). You can sweeten a honey pot's lure by presenting real Web material (if the honey pot runs as a Web server), and using a sampling of legitimate accounts (but not passwords!) to populate the user database of the honey-pot system.

Of course, no intrusion-detection system would be complete without plentiful alerting and logging mechanisms. These could be as simple as e-mail alerts when an intruder accesses a service, or as complex as logging every packet received by the honey-pot system. As with a network- or host-based intrusion-detection system, the reporting and alerting mechanisms are as important, if not more so, than the detection.

Integrating Honey Pots

How well a honey pot helps you detect intrusions depends on how you integrate it into your network. You should position the honey pot close to your production servers, to warrant a look from intruders targeting production systems.

One method is to emulate nonproduction services on production systems. By using port redirection on an upstream router or firewall, you can make it appear as if the honey-pot services are on the production system. This tactic, recommended by Recourse Technologies (maker of ManTrap), is illustrated in "Avoiding the Sting: Redirecting to a Honey Pot," above.

For example, if I run a production Web server (Port 80), I could then redirect telnet (Port 23) and SMTP (Port 25) to a honey pot. Because these services should not be accessed on the production system, the honey pot should immediately send an alert and/or log the activity. This would require an upstream router or firewall capable of performing port/service redirection. Axent Technologies' Raptor Firewall has its own Redirect Services, and Cisco Systems' IOS 12.0 lets you set up access lists in conjunction with NAT (Network Address Translation) to redirect particular services to a honey-pot system. In this situation, the honey pot would be located on a separate network segment, though it might be possible to have the honey pot on the same segment, depending on the redirection capabilities of the upstream device. The upstream device is responsible for transparently handling the address translation of the honey pot, thereby helping to conceal its real destination IP address.

A setup such as this lets you detect probing and tampering within a production system, but only on nonproduction services. In the indicated setup, you wouldn't be alerted to tampering on the production Web server because that service isn't redirected to the honey pot. Therefore, it is still important that you monitor production-system logs and perhaps also employ a network- or host-based intrusion-detection system. The setup requires the use of an upstream router/firewall capable of port redirection. In addition, all accesses to the production services must traverse through the router/ firewall performing the port redirection, which means servers may need to be internally segmented.

Another way to deploy a honey pot is to place it logically between production systems, as shown in "Sweet Rewards: Networkwide Scan Detection," below. In this decoy placement, your production systems are addressed as .2, .3 and .5, while your honey pot is located at .4. This is achieved by straight network addressing of the honey pot. You can even make the honey pot appear as multiple hosts by using IP aliasing (assigning multiple IP addresses to the same host). Because this method uses standard network addressing, you don't need any special configurations on your upstream router or firewall.

The goal in this setup is to catch intruders who will "sweep" (scan) an entire network range, looking for vulnerable services. If your production servers are running the DNS service, so should your honey pot; an intruder scanning for the latest DNS service vulnerability will hone right in. However, if the intruder focuses only on your production systems, he or she will avoid the honey pot, rendering it useless.

Honey pots work on the principle of a single truth: All traffic to a honey pot should be deemed suspicious. An intrusion-detection system can help facilitate this process by detecting known or statistical/trend-based attacks; however, the glory of a honey pot is that it lets you catch unknown attacks as well. If a honey pot's service emulation fools an intruder, that intruder may try to exploit a new vulnerability; therefore, logging all packets to the honey pot will provide a perfect replay of how the intruder leveraged the new vulnerability.

However, it's important to understand the limitations of service emulation. Like virus scanners and (signature-based) intrusion-detection systems, the software must know about the vulnerability prior to exploitation for it to emulate properly. If the emulation convinces the intruder, he or she may run the exploit--but if the vulnerability is new or unknown, odds are the emulation will then fail and reveal itself. At this point, the intruder may recognize the facade and hightail it out of there, or worse, become more aggressive in attempts to breech your servers and erase evidence. Unfortunately, most emulations are limited to presentation of text banners and very low service interaction.

Even so, an intruder accessing a honey pot gives you a point of reference to correlate access on production machines. The production Web server of a high-traffic site may produce large amounts of Web service logs; reviewing them may become an arduous process, even if automated. With a honey pot, you have the opportunity to learn about intruders, and use that information to search and isolate how they accessed production systems.

Worth the Trouble?

After all is said and done, should you bother with a honey pot? To answer that, consider the following:

• Do you have enough resources to dedicate system(s) as honey-pot hosts?
• Do you monitor system and intrustion-detection system logs?
• Do you intend to prosecute or track intruders?
• Do you have proper incident response, or any incident response at all?

Legal Aspects of Honey Pots

Unfortunately, little legal precedence has been established in regard to honey pots. Some people may view them as unfair entrapment tools while others may deem them perfectly respectable. If you choose to use honey pots, you should consider the possible repercussions. If you intentionally lure intruders to a honey pot, you may be seen as giving permission for an intruder to access the system; therefore the honey-pot system should at minimum carry the same posted restrictions as your production and/or private systems.

There may be liability if an intruder compromises your honey pot and uses that system as a stepping-stone to compromise other systems. You may be found to be lacking in due diligence if you knew an attacker had compromised your system (honey pot) and you had not handled the situation properly. It could even be considered gross negligence, because by setting up a "vulnerable" honey pot, you indirectly allowed and promoted the attacker's actions.

Many people feel they need to provide false data in order to lure the intruder. But how is an attacker to know a system contains data (false or otherwise) before he or she has compromised the system? Clearly, providing data to encourage attackers to break in is backward logic. You also must consider the nature of the false data you provide. The intruder may make the false data publicly available, which could affect public perception of your company. Imagine if you decided to place information that indicated your company was having a weak fourth quarter. What would the stockholders think if this false information somehow popped up on the Internet?

With regard to the issue of honey pots being viewed as unfair entrapment tools, it can only present a problem if your organization is a law-enforcing agency. From a legal standpoint, you should keep in mind that honey pots are still defensive detection tools, not an offensive approach to luring intruders.

Jeff Forristal is a senior security consultant for Neohapsis in Chicago. Send your comments on this article to him at jeff@neohapsis.com.