Honeypots are gaining momentum as a useful security tool alongside firewalls, Intrusion Detection Systems (IDSs), and antivirus software. Intended for the early detection of unauthorized activity, honeypots are computer assets that you intentionally configure to be vulnerable to compromise. A honeypot can be a computer, router, printer, or practically any networked device that has value to a potential intruder.
A properly configured honeypot doesn't contain any legitimate production software or data; its most distinguishing feature is that you can deem all activity that occurs on it as suspicious. This functionality is wholly unlike that of firewalls and IDSs, which are ruled by false-positive alerts. More than a dozen honeypot solutions are available, but only recently has the most popular open-source honeypot—Honeyd—become available for Windows. (See the Honeypots Solutions Web site at http://www.tracking-hackers.com/solutions for a listing of commercial and open-source solutions.) Let's look at honeypots in general, then discuss the configuration and deployment of Honeyd for Windows.
Why Use a Honeypot?
Production honeypots excel at early detection of attacks against networks. When activity occurs on a honeypot, it's unauthorized by definition. Honeypots can alert you about active attacks and let you collect forensic evidence against an intruder. Some honeypots can identify and locate the intruder—although such activity, which goes beyond the typical passive nature of honeypots, increases the risk of alerting the intruder that you're aware of his or her presence.
You can deploy research honeypots as an educational tool for IT staff. By doing so, you can learn more about cracking methods in general and about the specific types of exploits that your company's defenses face. Some honeypot administrators are surprised to learn that automated cracking tools account for most attacks. Most probes come from Internet worms or scanning tools looking for viable victims. Administrators are even more surprised to see how quickly such automated tools and malicious software (malware) can compromise a machine. One figure, attributed to a large honeynet (i.e., a collection of honeypots simulating a virtual network) research project, says that the shortest recorded time between Internet-enabling a honeypot and the compromise of that honeypot is just 15 minutes.
Understand that a honeypot typically doesn't prevent attacks—other than slowing down intruders as they attack virtual targets instead of production computers. Because you're essentially inviting intruders to hang out in your house, you're putting your organization at increased risk should the intruder compromise the honeypot host. If an intruder uses your honeypot to attack other systems, you also face potential legal liabilities.
Honeypot Software
Before specialized honeypot software came along, you had to manually create honeypot systems. You had to endure the same installation and configuration processes as you did for your production systems, albeit forgoing the application of security patches. After you created the honeypot, you had to install and configure all the related alerting, logging, and forensics mechanisms. And you had to repeat this process each time an intruder compromised the honeypot host. To save time, many honeypot administrators clone the honeypot's hard disk and reimage it when necessary.
You can install honeypot software to simulate one or more virtual honeypot systems on one host computer. To the attacker, each virtual honeypot appears as a separate computer, router, or other networked device. Most honeypot applications come with emulated TCP/IP stacks and services and even contain fake content and data files. Honeypot software typically offers built-in monitoring and logging mechanisms for easy administration. If an intruder compromises the host system, you can simply reinstall all the virtual honeypots from one cloned image to restore the host system.
Honeyd
Niels Provos created the original Honeyd (aka honeypot daemon) in 2002 as an open-source UNIX tool. Michael A. Davis, also responsible for the Windows port of the Snort IDS, released a ported version of Honeyd in March 2003. With the exception of subsystems and a few small syntax changes, the Windows port of Honeyd is identical to its UNIX cousin. Therefore, Honeyd doesn't have a pretty GUI; you configure and execute it at a command prompt. Honeyd for Windows works on Windows 95 and later.
Honeyd is a low-interaction honeypot that mimics only the basics: the OS, IP stack, and simple services. It doesn't include forged content or running applications. Low interaction also means the honeypot is simple to deploy and to recreate in the event of a compromised host. If you need a high-interaction system with a pretty GUI, you can try an alternative product or build your own honeypot. (For information about the do-it-yourself route, see "Building a Honeypot" at http://rootprompt.org/article.php3?article=210.)
Several free and commercial honeypots are available, but Honeyd is one of the premier free honeypot tools for Windows. Other free solutions work only with UNIX or are limited in application. For example, Tom Liston's LaBrea functions as a sticky honeypot or tarpit that's designed to slow down automated worms. NFR Security's BackOfficer Friendly (http://www.nfr.com) is easy to use and set up, but it monitors only seven ports. In contrast, Honeyd can monitor all TCP and UDP ports. With their friendly GUIs, LaBrea and BackOfficer Friendly are excellent honeypots for first-time users and for people who don't want to write configuration files and work from the command prompt.
For step-by-step instructions for obtaining and configuring Honeyd, see the sidebar "Honeyd Configuration Steps." After you download Honeyd, you must define the IP addresses on which the software will listen, one or more virtual OSs, the fingerprinting emulation Honeyd will use, which IP ports the software will mimic, and which logging options to use. You define these options as command-line parameters or in the configuration file. (For a summary of Honeyd's command-line parameters, see the Web-exclusive sidebar "Executing Honeyd" at http://www.secadministrator.com, InstantDoc ID 39427.) The following sections detail each of these items and options.
The Configuration File
When Honeyd starts, it immediately looks for a configuration file in which you've defined virtual host templates, bound IP addresses to those templates, specified an OS personality, and defined ports and services. The configuration file's entire syntax is beyond the scope of this article, but you can refer to honeyd.html (included with Honeyd) for details about the configuration file. Listing 1 shows a sample configuration file moderately commented so that you can see what's happening. Each configuration statement is one line long (which can wrap), and you use a configuration command verb, followed by other keywords and variables, to start it.
Templates
Templates are Honeyd's method for keeping track of one or more virtual OS environments. Each template defines a unique IP address associated with a virtual OS's personality, ports, and services. One instance of Honeyd can support many templates. Every configuration file should contain a template called default, which is the template Honeyd uses when no other template applies. You define a template as follows:
create <templatename>
Template names are always case sensitive, can't begin with a number, can't contain spaces or special characters, and—with the exception of default—shouldn't be identical to reserved commands.
Emulated IP Addresses
You can configure Honeyd to use specific, predefined IP addresses or a range of addresses. Other options are to have Honeyd respond to any request for a currently invalid address or to any packet it sees on the wire. The latter behavior is the default behavior. On the command line, you can define the subnet Honeyd will emulate, for example
honeyd 192.168.169.0/24
honeyd 192.168.169.1-192.168.169.255
Note that Honeyd uses Classless Inter-domain Routing (CIDR) subnet notation or IP address ranges.
To bind a Honeyd template to a specific IP address, you use the configuration file statement
bind <ipaddress> <templatename>
For example, you would enter
bind 192.168.169.202 Win98
Unfortunately, Honeyd doesn't magically draw packets off the wire. You must configure your network to redirect the appropriate traffic to the virtual Honeyd IP address. (Many honeypot administrators configure their Internet firewalls and gateways to redirect unauthorized port requests directly to the honeypot, at which they can monitor and quarantine attacks.) Complicating any such effort is the fact that Honeyd is hosted on a PC that uses one IP address, and Honeyd must have a unique IP address and subnet. The use of static routes or Address Resolution Protocol (ARP) proxies is almost mandatory. For example, suppose you're running Honeyd on a PC that has the IP address 192.168.168.168. To direct traffic to Honeyd's virtual IP subnet as 192.168.169.0, you can create a static route entry to tell the network that to get to any host on 192.168.169.0, it must use interface 192.168.168.168. The appropriate route table entry on a multihomed Windows 2000 or Windows NT system would be
route -p add 192.168.169.201
mask 255.255.255.255
192.168.168.168
(Although this command appears on several lines here, you would enter it all on one line in the configuration file. The same holds true for the other multiline commands in this article.) During testing, you can enter this command (with appropriate addresses) into your remote test probe machine's routing table so that the machine can see the virtual Honeyd session. Depending on your setup, you might also need static routes to redirect honeypot responses back to the remote testers. To ease administration, you should define the static entries into a centralized router or gateway. A sign that your honeypot routing is set up incorrectly is that Honeyd responds to and reports only broadcast traffic.
You can also use an ARP proxy, such as the UNIX utility arpd, in conjunction with Honeyd so that Honeyd can respond to any previously unallocated IP address (aka ARP spoofing). Nobody legitimate should be searching your network for nonexistent IP addresses. A properly configured Honeyd server with an ARP proxy can delay worms and malicious intruders by waylaying them with innumerable bogus services and machines. Be careful, however, because ARP proxies operating in this capacity can interfere with DHCP servers. Davis is working on a Windows port of the arpd utility, which should be available by the time this article is published.