Sidebar 2: Design Tips for Your Honey Pot

There are several lessons to be learned from Stoll and Cheswick and Bellovin's experiences that you can apply in designing your own honey pot system. First, it can be very dangerous to allow open access to a trap system within your organization's network, especially if this puts the cracker closer to the “good stuff” (i.e., database server, financial information, proprietary research, etc.). If you are unable or unwilling (Stoll's devotion put a large strain on his social life) to physically monitor the cracker constantly, be sure you know what the cracker does while he is unsupervised. It can also be costly if the cracker starts using your honey pot to attack other computer systems on the Internet, causing your company to be liable since you knowingly granted him access. Be aware of the time commitment you are making to analyzing and monitoring log files when you deploy a honey pot system.

In addition to the collected stories and literature of past system administrators like Stoll and Cheswick, here are some basic tips to follow when creating your honey pot trap:

• Purpose of the honey pot -- Remember that the goal of a honey pot is to divert the intruder from critical resources to phony ones within your network. In doing so, you hope to figure out an intruder's motives and possibly trick him into giving away his identity. Eventually you may be able to use the hacking attempts you monitor to improve the security of your valuable assets.

• Avoid entrapment -- A legal warning: if one of your traps or baits encourages someone to commit a crime, this is considered entrapment. Entrapment may prevent successful legal prosecution in many instances, practically making your system counterproductive. It is a very fine legal line when creating a honey pot. You want to make the system as tempting to probe as possible, but you also don't want to hang a neon sign on it that says “open 24 hours.” To avoid creating an entrapping situation, I recommend the next tip in addition to talking to legal counsel.

• Warning banners and advisory notices -- Your honey pot should have a clearly spelled out warning notice with strong language to the effect of intrusions are not invited or welcome, use of the system assumes consent to be monitored, those who use or abuse the system without authorization will be breaking the law, and a phone number to call for clarification.

• Keep the psychology of the cracker in mind -- Think about what sort of information would be valuable to your company or organization, and use this to your advantage. For instance, the administrator of a computer chip Web site might install a honey pot and include bogus chip design information that looks like it could be of a secret or restricted nature. This leads into the next tip of choosing your information trail of honey.

• Use good bait -- Remember that the goal is to legally expose anyone who breaks into your system. This may seem harder than it sounds, but here are some suggestions for creating phony information to expose the cracker. The key thing to remember in avoiding entrapment is that this bait should only be accessible once someone has committed an illegal act.

1. Files with a list of phone numbers and accompanying passwords -- This could represent something like remote access into the company, etc. Then the phone lines could be configured with Caller ID, and the traced numbers given to law enforcement officials to start an investigation.

2. Phony system password files obtained through ftp or uucp sessions with an account password that is easily crackable similar to Berferd -- This account could then be booby trapped similar to Cheswick and Bellovin's jail to better ascertain the cracker's activities and motives. Note that this can be like playing with fire, especially if the cracker circumvents the jail and discovers your monitoring devices. Later, I will suggest methods of fortification and creation of a limited jailed account.

3. Files with private Web site URLs that are not published in search engines, and promise useful information -- The cracker then visits the URL and possibly his host machine's IP address shows up in the logs. Edward Amoroso, in his must-read book Intrusion Detection, An Introduction to Internet Surveillance, Correlation, Traps, Trace Back, and Response, describes a man-in-the-middle attack you can perform on the cracker's browser if you feel adventurous with JavaScript and have OK'd it with the legal gurus. Basically, you can redirect the links using your Web site as the requestor. If the normal link was http://www.cert.org, you instead rewrite the link in the form of: http://www.yourtrapsite.com/http://www.cert.org for example. All subsequent sites that the cracker visits will be logged on your Web server as long as he doesn't press “Back” on the browser. The JavaScript would have to be written to hide the URL location in the lower left part of the browser window when the mouse is brought over the link.

4. Files that list mailing addresses to which to send self-addressed stamped envelopes for further information about a certain “project” or for “free stuff” -- Cliff Stoll baited a file on his server as part of his bogus project information with the promise of information on his concocted military project. He was shocked to receive a self-addressed envelope several weeks later!

5. Fake and rigged emails with some or all of the above suggestions incorporated in them -- Also useful is placing correspondence belonging to the systems administrator describing system problems that may conceal and explain certain irregularities with a jailed account. Strange system behavior described in /etc/motd offers a nice haze for many account booby traps.

6. Rigged ports where crackers commonly scan for vulnerable services -- For instance, use public domain tools like Doug Hugh's klaxon to detect port scans and reveal the intruder's IP address and sometimes even their username (if identd RFC931 is supported).

7. Use your imagination, be original, and try not to reproduce bait that has been highly publicized or is too obvious. I hate to sound like a broken record, but make sure your mechanisms are legally supported.

8. Record everything -- Make sure that you have a way to log all the actions of any potential intruders. It's better not to store the logs on your honey pot itself, in case your system is actually exposed and infiltrated. The problem with sending logs across the network is that a cracker could detect this if he decided to run a sniffer on the wire. Methods to remedy this problem are discussed later.

9. Above all, stealth -- When devising your own trap mechanisms, remember a good trap is hidden so that the prey does not detect it and thereby alter his actions to avoid getting caught.