Honeyd for Windows

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 

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/24honeyd 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  

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.

Personalities
At the core of Honeyd is the concept of OS personalities. A personality is the OS IP stack that Honeyd is impersonating. Each major OS responds somewhat differently to various TCP/IP requests. Every packet that Honeyd outputs passes through the personality engine for inspection to make sure it matches the configured personality.

Honeyd can have a different personality for each template. You can configure Honeyd to impersonate more than 130 systems, including different versions of Windows, Mac OS, Linux, Digital UNIX, Sun Microsystems' Sun Solaris, FreeBSD, NetBSD, OpenBSD, SCO Group's SCO OpenServer, and many network infrastructure devices. For example, you can have Honeyd spoof the personality of a Cisco Systems router or several popular firewalls. You can also create custom personalities to extend Honeyd's functionality.

Personalities use the fingerprinting database of the open-source Network Mapper (Insecure.org's Nmap) tool and another fingerprinting utility called Xprobe2, written by Fyodor Yarochkin and Ofir Arkin. Nmap performs TCP/UDP fingerprinting, whereas Xprobe2 uses Internet Control Message Protocol (ICMP) packets. Both utilities send different types of TCP/IP packets, record the results, and use the combination of results to identify a particular host OS. The utilities are often sufficiently accurate to identify OS version and service pack level. You can obtain nmapNT—a Windows version of Nmap—at http://download.insecure.org/nmap/dist/nmap-3.27-win32.zip.

OS fingerprinting isn't a perfect science. Nmap often detects Windows XP systems as Win2K or replies with a broad identifier that indicates the tested machine is either XP, Win2K, or NT. If you want to use nmapNT to manually test the fingerprinting process, use the command

nmapnt -vv -O ipaddress

where ipaddress is the IP address of the host to be fingerprinted. The -vv parameter tells nmapNT to be verbose about its actions, and the -O parameter tells nmapNT to fingerprint the destination host's OS.

Malicious users often use Nmap or Xprobe2 to identify remote machines, so Honeyd takes advantage of this reliance to spoof results back to the originating requestor. Thus, you can fool a remote attacker into believing he or she has broken into an NT Server 4.0 Service Pack 4 (SP4), Windows for Workgroup (WFW), or SCO Open Server system—even though these are just emulated environments originating from one instance of Honeyd running on a Win2K box.

For a list of all available personalities and their related Nmap signatures, see Honeyd's nmap.prints and nmap.assoc files. Nmap.prints contains the IP stack responses for each personality (if you want to delve into the inner workings of OS fingerprinting), and nmap.assoc matches Xprobe2 fingerprints against Nmap to keep fingerprinting responses consistent, should an intruder use both tools. Honeyd uses the xprobe2.conf file to impersonate the ICMP section of OS stacks. You can tell Honeyd which OS fingerprinting database to use when you start it; most administrators choose both Nmap and Xprobe to cover both types of OS fingerprinting.

The personalities that will concern most Windows administrators are XP Professional Edition, XP Home Edition, Win2K, NT, Windows Me, Win9x, and Windows 3.11. The actual personality names are much longer, such as Windows NT 4.0 Server SP5-SP6, and you can find them in the nmap.prints file. (You must type personality names exactly as they appear in the nmap.prints file.) You use a command such as the following to set a personality in Honeyd's configuration file:

set  personality ""

For example, you would enter

set default personality "Windows NT 4.0 Server SP5-SP6"

Personalities affect only the way Honeyd responds to IP stack­related requests. They don't affect how applications and services respond and whether the right service is associated with the correct OS. For example, just because you tell a personality to mimic a Win2K Server machine doesn't mean that Win2K Server Terminal Services emulation will magically appear. Later in the article, I show you how to set up the appropriate emulated services so that your Win2K personality knows to serve up Microsoft Internet Information Services (IIS) 5.0 instead of Apache when the intruder probes port 80.

You must also annotate personalities before you can assign them to templates or IP addresses. The syntax is

annotate ""

At a minimum, for each Honeyd template, you need to annotate the personality, define a name, tie the personality to the template, and bind everything to an IP address. Here's sample code for setting up a default template:

annotate "Windows NT 4.0 Server SP5-SP6"create defaultset default personality "Windows NT 4.0 Server SP5-SP6"bind 192.168.169.201 default

At this point, you've defined the IP stack for the template to emulate. Now you need to declare ports and services. You can define ports and services for every template defined in the configuration file.

IP Ports
Honeyd supports an unlimited number of ports and treats them in a stateful way. In the configuration file, you can configure Honeyd's default behavior for all undefined port probes, as well as the values for specific ports tied to specific templates. Values include block, open, reset, cmd-string, and proxy. Reset is the default option because it's the answer that most IP stacks return when a requested port isn't available. The cmd-string parameter primarily emulates different services and kicks off alerts. Syntax for setting up ports in the Honeyd configuration file might look like

set default default tcp action openset default default udp action resetadd default tcp port 21 openadd default tcp port 137 openadd default tcp port 139 block

The first two lines tell Honeyd how to treat TCP or UDP probes if the configuration file doesn't specifically define a behavior of a specific port. If you want the honeypot to interest intruders, it must do more than respond to IP stack fingerprinting and port probes.

Emulated Services
As a low-interaction honeypot, Honeyd doesn't offer full OS or application emulation, but you can use proxies and scripts to provide emulated services. Proxies are external host machines configured to accept redirects from Honeyd for predefined services. For example, you can redirect DNS requests to a real DNS server in the demilitarized zone (DMZ) so that your captive intruder doesn't grow suspicious because of a poorly emulated or limited DNS service. In the configuration file, a proxy command would look like

add default udp port 53   proxy 68.10.16.30:53

This command tells Honeyd to pass DNS traffic that arrives on UDP port 53 to an external DNS service that resides on a machine with the IP address of 68.10.16.30. An intruder might get suspicious if the compromised box won't let him or her do anything or get to any services. The more your honeypot resembles a real host, the longer the intruder will stay and the more useful forensics evidence you can collect.

In Honeyd, you can write and use script files to emulate services that sit on different ports. After you learn how to write emulated service scripts to interact with Honeyd, you can use a script engine that your host OS supports—or even compiled C or C++—to write custom emulation scripts. Most of the scripts available for Honeyd are written for the UNIX version in Perl and shell scripting. (You can find these common scripts on the Web.) Because most existing scripts for Honeyd are written in scripting languages that Windows doesn't install by default, you need to install a Perl or shell scripting engine. I should warn you that getting scripts to work and setting up emulated services on Honeyd is perhaps the most difficult step for a first-time user. But don't get frustrated—the journey is worth the payoff.

To use predefined scripts, you need to install one or two Windows-based UNIX utilities. For shell scripting support (sh.exe) and Perl (perl.exe), you can install Cygwin, a UNIX-environment emulator for Windows, and put the resulting directory that holds the binary files (e.g., C:cygwinbin) in your system's PATH variable. Although shell scripting comes as part of the default Cygwin installation, you need to select Perl as an optional package. Alternatively, you can download ActiveState's ActivePerl and put its binary directory (e.g., C:activeperlperlbin) in your system PATH variable. Both Cygwin and ActivePerl are moderately sized downloads that contain hundreds of files.

Honeyd for Windows comes with three scripts: router-telnet.pl, test.sh, and web.sh. Router-telnet.pl emulates a basic Telnet logon, complete with authorization warning message and password routine; test.sh mimics a Secure Shell (SSH) session; and web.sh mimics an IIS 5.0 server with standard directory names.

At Provos's Web site (http://niels.xtdnet.nl/honeyd/contrib.html), you can find a few advanced scripts that various contributors have programmed. Current script contributions include two POP3 services, a moderately functional IIS 5.0 server, and an emulated sendmail server. Unfortunately, to extract some of the scripts, you need a Windows utility that can uncompress gzipped tarballs (.gtz or .tar.gz), which are the UNIX equivalent of a Windows .zip file—I use GlobalSCAPE's CuteZIP. To add scripts to Honeyd, you use the Add command in the Honeyd configuration file, with a statement such as

add default udp port 21   "sh scriptsftp.sh"

To save troubleshooting time, test the script engines and scripts at a command prompt before expecting them to run inside Honeyd. For example, type

C:honeydscripts>sh ftp.sh

to make sure shell scripting is correctly installed. Also, if you're using scripts originally written for UNIX, you need to edit the scripts to change UNIX-style parameters to the appropriate Windows syntax. For example, the POP3 script is set up to write its log to /tmp/honeyd/pop3-$1.log. You would need to change that destination to something like C:honeydpop3.log, or the script would error out during execution.

Logging
Any activity (minus harmless network broadcasts) that occurs on the honeypot is suspicious. By default, Honeyd writes activity to an ASCII file on the host or sends events to a syslog server. Using the ­l command parameter lets you specify a filename to which to save entries. Most honeypot administrators try to save their log files to protected remote servers so that if the honeypot host is compromised, the intruder will still have a difficult time erasing the logs.

The first column of a given Honeyd log lists the time and date of the recorded event. The next column lists the protocol type (e.g., UDP, TCP, ICMP). The Honeyd log also provides the source and destination IP address and port number, as well as the number of data bytes in the packet. Many of the emulated service scripts also contain log files. If the main Honeyd log reveals activity on one of the emulated services, be sure to investigate the emulated service log for more details.

Ideally, you'll use a packet sniffer or an IDS acting in packet-sniffing mode, along with your firewall event logs, to capture all activity to and from the honeypot. By itself, Honeyd records only a minimum amount of information. Honeyd's data is great for a quick look to see what IP addresses and ports are being probed, but to fully understand what's going on, you'll need a full packet decode. With a packet decode, you can see which files and directories are being manipulated, observe what's being typed, and record buffer-overflow information. Consider importing your Honeyd log into a database for easier analysis. Open-source Honeyd log-file analyzers are just starting to appear for the UNIX environment. (For example, check out the HoneyView analyzer at http://www.kh-soft.de/honeyview.) As Honeyd gains acceptance in the Windows environment, expect some contributors to develop log-file tools for the Windows version of Honeyd.

Honeyd Weaknesses
Although Honeyd is a fine solution, you'll quickly develop a list of features you wish it offered. First, Honeyd's most glaring weakness is that you can't configure it from a Windows GUI. On the honeypot mailing list (http://www.securityfocus.com), I've seen discussions about providing a GUI from which to generate Honeyd scripts, but I haven't seen anyone mention writing a Windows GUI (as has been done for Snort) for the program. Second, because Honeyd is a UNIX application ported to Windows, it predictably doesn't contain a way to emulate a NetBIOS name. This crucial missing component might set off a warning flag to intruders. Third, further complicating setup, Honeyd for Windows requires that you have a UNIX emulator or scripting engines to get existing scripts to work.

Honeyd doesn't offer sophisticated alerting, logging, and monitoring features. You can use an external alerting program, but Honeyd desperately needs an internal alerting system. Getting remote logging set up on a Honeyd server is a moderately difficult chore. Most honeypot administrators use Snort IDS or a packet sniffer to back up Honeyd's text-based log. However, you should have the ability to choose between basic and full packet decodes (as you can with Snort) from within the product.

Finally, because Honeyd is an open-source honeypot, its support consists of mailing lists, email messages to Davis and Provos, FAQs, and other information on the Internet. When I pose questions to the honeypot mailing list or the author, I typically receive a response the same day. Many users, however, prefer to have commercial support before they deploy it in their environment.

In spite of its weaknesses, Honeyd is a viable low-interaction honeypot for any business—large or small. Provos, the original Honeyd author, appears committed to increasing the functionality and user-friendliness of Honeyd in subsequent releases. Davis seems to be just as committed to updating the Windows port as new features become available. The growing user base is a banner open-source community, frequently providing new add-ons and features.

Early Warning System
Honeyd is a capable but not always friendly low-interaction honeypot for Windows, ported from the UNIX world. Appropriately configured, Honeyd can be an excellent early-warning defensive tool. If the command-line prompt or configuration file appears overwhelming, consider researching an easier Windows honeypot. For an excellent collection of honeypot articles, Web sites, and product links, see http://www.honeypots.net.