Think of honeypots as intelligence collection systems. Many hackers engage in routine scans of the Internet's address space, looking for poorly defended computers. A honeypot is a deliberately vulnerable target that invites penetration while fully instrumented. So after a hacker penetrates it, you can learn how it was done, keeping you current with the latest attacks and exploits against your company's servers. You can also collect the types of hacker tools they use and, by eavesdropping on their communications, map out their social networks.

Setting up a honeypot isn't hard; all you need is a computer running an unpatched copy of Microsoft Windows or Red Hat Linux on your external Internet. Since hackers are likely to booby-trap the computer's logging and auditing capabilities, you'll want to station a network-monitoring system between the box and your Internet connection so that all the traffic in or out of the box is silently recorded. Then just sit back and wait for the inevitable attack.

Running a honeypot is not without its risks, however. That's because the overwhelming number of compromised systems are used for attacking other systems. If you ignore a vulnerable system, you may be liable if hackers use your system to break into others. It's called downstream liability, and it brings us to the topic of honeynets.

A honeynet is a honeypot with added technology that properly records the hacker's actions while simultaneously minimizing or eliminating the risks to others on the Internet. An example is a honeypot that's set up behind a backward firewall; instead of preventing incoming connections, the firewall prevents the honeypot from initiating outbound connections. Still, while that approach makes the honeypot incapable of damaging other systems, it also makes it pretty easy for bad guys to spot. Realizing they've broken into a presumably booby-trapped system, the typical hacker is likely to wipe the disk clean and never return (which is not tremendously informative for the honeypot watchers).

For the past four years, Lance Spitzer and the others at the Honeynet Project have been working to create, deploy, manage and analyze the results of honeynets. Their technology is clever, but their results incredibly disturbing. To solve the problem of downstream liability, Spitzer and his team developed a range of data control techniques—for example, an adaptive firewall rule that allows five or 10 outgoing connections every hour: That's high enough to prevent an attacker from getting suspicious, but low enough to prevent serious damage to third-party systems. These rules can be implemented on commercial firewall systems like those from Check Point Software Technologies or on firewalls built from Linux and OpenBSD systems. Of course, no data control technique is perfect. "The more you allow a blackhat to do outbound, the more you can learn, but the greater the risk," according to the project's website.

Data capture is another technical challenge in running a honeypot. By recording every packet in and out of the system, the honeypot watchers can get a good idea of what the bad guys are doing. The log files on the honeypot itself are also a good data source. The log files are easily deleted by the attacker, so it's common to have the honeypot send a copy of its log to a remote syslog server that's on the same network but is better defended. (Be sure to watch the log server as well. If it is penetrated by your attacker using a novel attack, then your honeypot will certainly have shown its worth.)

The task of data capture has been considerably complicated in recent years by the increased use of encryption in the blackhat community. Back in the 1990s, most bad guys logged in to their compromised systems using clear text-protocols such as telnet and rsh. Today they've followed the advice of numerous computer security professionals and have turned to cryptographic protocols like ssh to make their communications immune to network monitoring. Honeynet's response to encryption is to modify the target computer's operating system so that all keystrokes, transferred files and other information are logged to yet another monitoring system. Because the attacker might discover such logs, the project uses steganographic techniques—hiding keystrokes inside NetBIOS broadcast packets, for example. It's a clever idea. (Unfortunately, it's only a matter of time before the bad guys adapt those techniques to their own nefarious ends.)

One of the nice things about honeypot systems is that they do a great job at data reduction. With a typical website or mail server, attacks are usually drowned out by the legitimate traffic. Adding an intrusion detection system rarely helps because of the tendency of these systems to generate false alarms. Honeypots, on the other hand, have little or no legitimate traffic. Most of the data in or out is, by definition, an attack. As a result, it is much easier to look at the data and find out what the attacker actually did.

Since its formation in 1999, the Honeynet Project has gathered a tremendous amount of information that you can find at www.honeynet.org or in Spitzer's 2002 book, Honeypots: Tracking Hackers. Some of the findings: The incidence of attack has doubled in the past year; attackers are increasingly using automated point-and-shoot tools with pluggable exploits (making tools easy to update as new vulnerabilities are discovered); and, despite their bravado, few hackers use novel attacks.

Honeypots are primarily a research tool, but they have genuine business applications as well. Put a honeypot on an IP address adjacent to your company's Web or mail server, and you'll get an idea of the attacks to which it is subject. But don't give the adjacent machine a name with your domain name server—after all, most attacks are done by IP address. You'll get even better intelligence if the honeypot uses the same operating system, patch level and application suite as the machine you're trying to protect. In fact, make it an exact copy and then monitor all the traffic in and out of this honeypot machine. If it gets compromised, you'll know what to look for on your production machine.

With a honeypot, you constantly match your wits against the bad guys'. You get to choose the battlefield, but your opponent gets to choose the time of the battle.

To be sure, honeypots and honeynets are not "fire and forget" security appliances, a point that Spitzer repeatedly stresses. According to the Honeynet Project, it typically takes between 30 hours and 40 hours of analysis to really understand the damage that an attacker can do in just 30 minutes. The systems also require diligent maintenance and testing. With a honeypot, you constantly match your wits against the bad guys'. You get to choose the battlefield, but your opponent gets to choose the time of the battle. As a result, you must stay alert.

One of the most exciting things happening in the world of honeypots is the development of virtual honeynets—whole networks of virtual computers running on a single machine using a "virtualized computer" system like VMware or User-Mode Linux. A virtualized system lets you run a few (typically four to 10) virtual computers on a single host system. Virtual honeynets dramatically cut costs, machine room space and honeypot management complexities. And since the virtual computer's "disks" are actually files on the host system, it's easy to detect any changes the attacker may have performed and, when necessary, wipe them out. What's more, virtual systems typically support "suspend" and "resume" functionalities, allowing you to freeze a compromised computer, examine the attacker's processes, and open TCP/IP connections and anything else that's on the system.

For the CSO of a large organization, one of the best reasons to run a honeynet is to detect hostile insiders. Any company with more than a few hundred employees is bound to have one or two bad apples behind your firewall and probing for internal weaknesses. What better way to find them than with inside honeynets? Cut off from the outside world and set next to systems used by accounting and payroll, they'll tell you if someone is exploring where he shouldn't. A well-monitored system might even point you back to the perpetrator.

Ironically, monitoring your honeypot has its own legal complications—for instance, potential violations of wiretapping laws. Although there is currently no case law, most people familiar with this area of the law believe that consent banners are the way to go. That is, give every honeypot a banner that says "Anyone using this system consents to having their activity monitored and disclosed to others, including law enforcement."

Then, to keep your honeypots from sticking out like a sore thumb, every other computer in your organization should have a similar banner. But you've done that already, right?


Simson Garfinkel, CISSP, is a technology writer based in the Boston area. He is also CTO of Sandstorm Enterprises, an information warfare software company. He can be reached at machineshop@cxo.com.