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:\cygwin\bin) 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:\activeperl\perl\bin) 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 scripts\ftp.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:\honeyd\scripts>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:\honeyd\pop3.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.