Honeypots: Handle with care
By Robert L. Scheier
If you've been around the security field for a while (or if you've read Winnie the Pooh lately) you're familiar with the concept of a honeypot.
In the case of Pooh, the greedy bear got stuck trying to steal honey out of a jar. In the case of a hacker, a honeypot looks like a real system that traps the invader, alerts you to his presence and lets you study his tactics. The idea goes back at least to the late 80s and early 90s but is getting more attention these days as one possible component of an overall security system.
The original honeypots were designed to learn how hackers worked and to distract them so they wouldn't go after the real critical systems, says Joe Judge, a Boston-based independent security consultant. That was fine when relatively few people were linked to the Internet and security managers had more time to monitor the honeypots.
But it's a much riskier proposition today: Your Web servers are critical business tools, and you've got too many other responsibilities to spend much time monitoring a honeypot. Most of the half-dozen or so security managers to whom I spoke would rather spend their time monitoring their systems against attack instead of luring attacks, however educational that might be. Many security administrators are also justifiably afraid of being sued if crackers use their honeypots to launch denial-of-service attacks against other companies.
With all those risks and the that fact a security manager has plenty on his plate already, why even think about creating a honeypot?
For starters, says Judge, today's honeypots are less sticky than many original honeypots. They are designed not as a trap for an intruder, but as a tripwire to alert you to his presence. One example, he says, is to seed your e-mail address book with 50 false names, which all point to a single inbox that you carefully monitor. If that inbox gets mail, you'll know someone (or a virus program) is indiscriminately reading your address book and sending mail to the addresses in it, which is something no legitimate visitor should be doing. Some companies are already programming such watched, but bogus inboxes to page the security administrator as soon as they get mail.
Something more akin to a traditional honeypot can be created on the server level by putting up a server with fake, but realistic-looking information, as well as common services such as file transfer protocol (FTP) or e-mail, along with simple log programs that scream bloody murder if they see suspicious behavior. "If someone logs into FTP, downloads a file and leaves, that's not scary," says Judge. But it is scary if the visitor starts sending long commands trying to do a buffer overflow. Unlike in the early days of honeypots, existing log systems can be tweaked to automatically look for such suspicious behavior, says Judge.
The next step in the honeypot strategy is the "honeynet," which pretends to be an entire network of machines, sending fake responses to the hacker. Network Associates Inc.'s CyberCop Sting creates "a virtual network of decoy routers and servers on a 'sacrificial' host," the company says and logs information on the attacks without putting production systems at risk. A volunteer group called The Honeynet Project is working to develop and share expertise about honeynets.
Having said all that, it's pretty hard to find anyone who's actually using a honeynet to protect production systems, for the reasons mentioned above. The biggest danger, though, is that the honeypot might stick you, the security manager, with a lot of risky decisions that could cost you your job if you mess up. What if you don't do a good enough job sanitizing the data on the server? What if you don't properly configure the firewalls, allowing crackers to generate traffic from your servers to bring down a popular Web site? What if you don't properly isolate your honeynet from your production network and wind up inviting costly damage to your site?
The bottom line: Honeypots can be a useful part of a carefully planned security architecture, but only if used right. That takes time, which is probably your scarcest resource. And the stickier you want to make them, the more careful you'd better be with that honey jar.
For more information:
The Honeynet Project
About the author:
Robert L. Scheier is a contributing editor specializing in information technology issues. He can be reached at firstname.lastname@example.org
This was first published in April 2001