Republished with permission from
WatchGuard Technologies, Inc.
Honeypots: Sweet Idea, Sticky Business
By Dave Piscitello, President, Core Competence
Suppose you know you’ve been hacked. Frequently. You haven’t been able to identify the attacker, but you suspect the attacker is well-motivated, perhaps because of repeated visits, or because of the service or information he’s trying to access. In such cases, you may want to consider installing a honeypot.
What Is a Honeypot?
A honeypot is a program that takes on the appearance of a service, a set of services, an entire operating system or even an entire network, but is in reality a tightly sealed compartment built to lure and contain an attacker. Like a surveillance camera in a bank, a honeypot captures every action an attacker takes: it logs access attempts, captures keystrokes, identifies files accessed and modified, and indicates programs executed. If an attacker remains unaware that he’s entered a honeypot, he may eventually reveal his ultimate intentions. He may leave sufficient evidence to assist you in tracking him down. He may even leave sufficient evidence to allow you to pursue legal action. A honeypot complements Intrusion Detection Systems (IDS) by providing you with a way to contain the attacker while you gather evidence and attempt to identify him.
The authoritative explanation of a honeypot can be found in Firewalls & Internet Security: Repelling the Wily Hacker, by Bill Cheswick and Steve Bellovin (look in Chapter 10, "An Evening with Berford"). In a more recent paper, “To Build a Honeypot”, Lance Spitzner describes how he built, implemented, and monitored a honeypot so that he could learn the motives and behavior of black-hat hackers. Either resource provides excellent background on honeypots.
What honeypot should you buy? I can recommend three: the Deception ToolKit, ManTrap, and CyberCop Sting.
The Deception ToolKit (DTK) is a popular and inexpensive honeypot. Written in Perl, DTK uses TCP wrappers to process incoming service requests on ports you would normally block. You use subroutines to log an attacker’s activity and to build appropriate responses to input. You can customize responses to lure the attacker into thinking he has come across a poorly secured and readily exploitable service. As the attacker probes your host, you’ll learn more about what he’s after.
Recourse Technologies' ManTrap extends the honeypot into a full-blown deception host. The entire operating system—every service, file, and process—is presented to an attacker as a decoy environment. ManTrap automates many of the tasks necessary to perpetuate deception in its decoy environment. It populates the deception host with unique data, and can even update the data, to convince the attacker he’s found a production host. ManTrap also attempts to identify the objectives of the intruder: is he trying to gain root, deface a web site, steal passwords, install Trojans, or what?) ManTrap's analysis tools expedite audits of user/attacker activity.
CyberCop Sting goes even further than ManTrap and simulates an entire network segment of routers and hosts on a single deception system. As part of the deception, CyberCop Sting even knows what to do if the attacker tries OS-fingerprinting. "Fingerprinting" involves sending various packets to a machine, then assessing the response to determine what OS the machine is running. Sting can fake out attackers by emulating system images of Windows NT, Solaris, and Cisco IOS. Like the other deception hosts, Sting monitors and logs suspicious activity, and responds appropriately to attacker requests for specified services. Sting doesn’t expose any production systems or protected information, but offers up multiple hosts to an attacker while actually running on one machine.
Deceive or Intimidate: Either One Works for
The most critical aspect of honeypot deployment is deception. If the attacker suspects that he’s entered a trap, he’ll back out fast. A honeypot must provide “sensible” responses that look exactly like the service or resource under attack. A password file, service banner, even file permissions must look correct (just improperly configured against attacks). If the attacker has visited a machine in your network before, he may have a good sense of the “look and feel” of your production environment, so when you implement a honeypot, pay attention to details. It may be worthwhile to periodically add and remove innocuous files—for example, change the contents of a user’s mailbox, or add pages to a web site. These efforts help keep the deception going.
A clever use of DTK is to operate at least one unauthorized port—a deception port—as a means of warding off would-be attackers. Running DTK on its default port 365 with a default banner “Deception ToolKit Running” is like displaying a sign in your front yard that claims your house has a security alarm; most burglars and attackers will move on to an easier target. In the FAQ, DTK author Fred Cohen suggests running many deception ports to increase the hacker’s uncertainty and fear of discovery.
Where and When to Deploy Honeypots
There are several ways to deploy honeypots. You can put honeypots on “sacrificial lamb” systems—systems that don’t host any valuable data and offer no entry point to hosts that do. You can install honeypots on unauthorized ports of production hosts to ward off attackers, as I just described. You can install honeypots on production hosts at service ports with responders (programs that look and feel exactly like the service they replace, for example FTP) to contain an attacker who’s gained access to your host while you gather evidence. . Conventional wisdom says you should run honeypots on well-known servers (Web, SMTP/POP, DNS, FTP) because these are the commonly attacked services. Recourse Technologies recommends that you deploy decoys in proximity to production hosts; for example, you might put several deception hosts on the same logical subnet as your extranet servers. Each deployment scenario has its inherent risks, overhead, and benefits, so think before you act.
Honeypot Pros and Cons
Opinions differ widely about the use of honeypots. Those who are "pro-honeypot" argue that a honeypot can be a low-overhead and effective deterrent if used in the manner DTK author Fred Cohen describes. Others suggest that a well-conceived (and possibly more labor- or resource intensive) honeypot may placate an attacker. For example, if the attacker’s intent was to install a Trojan horse program, you’ve given him what he’s wanted by allowing him to install the Trojan in your honeypot. In this scenario, blocking outbound traffic from the deception host at your Firebox or SOHO is a necessary part of your “containment” strategy: you don’t want your deception host playing a role in another (e.g., DDoS) attack.
One of the more attractive reasons to operate a honeypot may be to identify compromised accounts—you’ll have an audit trail identifying which accounts the intruder has attempted to use as well as which he’s succeeded in breaking into. And of course, being able to analyze an intruder's techniques and intentions provides valuable insight into his motivations. This may help you deduce where he might strike next and what his targets might be. You may also learn about a vulnerability before it’s exploited. [As an aside, if you are interested in reading more about attacker motives, read the Know Your Enemy series of papers by Lance Spitzner, et. al.]
Nay-sayers suggest you’re better off investing your time and talent in securing your production systems than burning cycles maintaining the deception environment. These folks also worry that an improperly configured or deployed deception host might expose a backdoor to a production host. These are legitimate concerns, and you should weigh them carefully before you play cat-and-mouse with attackers. At the least, add honeypots to your mental list of tools and tricks, because at some point it may be just the bait you need to rid your network of a persistent pest.
Copyright © 1996 - 2001
WatchGuard Technologies, Inc. All rights reserved.