Long thought of as toys for security administrators who have too much time on their hands, honeypots are gaining an increased presence on corporate networks. Honeypots are nonproduction computer assets set up for the express purpose of being a potential target for unauthorized activities. Although honeypots can mimic any computer resource (e.g., router, print server), they most often mimic legitimate production servers and workstations.
Early on, security professionals mainly used honeypots to learn about malicious attackers (hereafter called intruders) and their tactics. Honeypots have proven their value in this area. For example, using honeypots, the Honeynet Project (http://www.honeynet.org) learned that the majority of attacks are automated by malicious mobile code (i.e., viruses, worms, and Trojan horses) and scripts. Although manual attacks aren't as common, patient intruders will find exploitable holes. Using honeypots, the project members uncovered complex intruder undergrounds involved in widespread commercial fraud and learned and publicized new intruder tricks before they could become pervasive zero-day exploits (i.e., vulnerabilities that attackers discover and exploit before they become widely known to the general public and security professionals).
Although setting up a honeypot to learn about intruders and their tactics is worthwhile, most organizations will find greater value in using honeypots to distract intruders from legitimate resources and to serve as an early warning system. Unlike firewalls and Intrusion Detection Systems (IDSs), honeypots don't produce numerous false positives. By definition, a honeypot is a nonproduction asset, and any activity that takes place on it is considered malicious until proven otherwise.
For a honeypot to attract intruders, it has to appear as a legitimate production asset. Thus, in a pure Windows environment, administrators might create honeypots that mimic common Windows ports and services. However, honeypots didn't originate in the Windows world but rather the UNIX/Linux universe. Although a few Windows honeypot solutions exist, they don't have the sophistication, feature set, or support that their UNIX/Linux counterparts offer. This situation might be somewhat surprising given that most of the world's networks are Windows networks. Vendors are just starting to address this gap, and some Windows solutions are beginning to rival their UNIX/Linux counterparts. And in true Windows fashion, the Windows solutions are becoming easier to configure and deploy than the UNIX/Linux ones. This review will look at virtual honeypots designed for the Windows world and includes both commercial and open-source solutions.
Real vs. Virtual Honeypots
Honeypots can be real or virtual. A real honeypot runs production software (e.g., Windows Server 2003, Microsoft Exchange Server, Microsoft IIS) on dedicated hardware. A real honeypot is one of the best targets you can offer to an intruder. It looks and responds like a real production asset—and as long as the data it contains is updated, the honeypot has little chance of being identified as such.
The problem with real honeypots is that they're generally difficult and time-consuming to set up and control. Setting up a real honeypot might take as many hours as setting up a legitimate production asset. More important, because the software is real, after the intruder gains access to it, preventing the intruder from using the newly compromised asset to attack other, legitimate assets can be difficult. Although many real UNIX/Linux honeypots have mechanisms to prevent the compromise of legitimate assets (called data-control mechanisms in honeypot lingo), few Windows honeypots have them.
Virtual honeypots offer an emulated environment in which the software limits what the intruder can do. In most cases, potential damage to legitimate assets is significantly curtailed, if not impossible. Most virtual honeypots offer weakly emulated TCP and UDP ports and services. Virtual honeypots can simulate open ports, closed ports, or ports that contain a responding service.
Virtual honeypots that only open a port and record an intruder's initial probe are called simple port listeners. Slightly more advanced port listeners can reply with basic open or closed response packets, which might appear more realistic and intrigue the intruder more. These honeypots record the information that the intruder sends, then they respond with the appropriate network protocol reply (e.g., a SYN packet). The honeypots don't send any other data, and the intruder's connection is never successful. For a network administrator, this interaction might be enough because it indicates unauthorized activity within the perimeter and minimizes subsequent risk.
Previous
Register
Hell March 31, 2004