Recently I explained the differences between real
and virtual honeypots
to show how they can effectively protect your
network. In that article, I pointed out a few advantages virtual honeypots had
over their real counterparts—namely, low cost and low overhead. For this
article, I want to focus on setting up a virtual honeypot. For demonstration
purposes, I have chosen to use Security
Profiling’s Honeyd

Ready for Honeyd

After you have downloaded and installed WinPcap, it’s time
to install Honeyd. What you might be surprised to learn is that the entire
installation process consists solely of unzipping the file that you downloaded.
The Honeyd program was originally UNIX based and was then ported to Windows, so
UNIX programs typically do not come with a Windows style Setup.


Honeyd is not a completely standalone product. Before Honeyd
will run, you will have to download and install WinPcap.
This free program is a packet capture module for Windows that Honeyd depends on
for activity detection.

As is characteristic of a UNIX style program, Honeyd is
completely command-line based. To run Honeyd, you must simply open a Command
Prompt window, navigate to the folder containing the HONEYD.EXE file, and then
enter the appropriate command. It is important to remember that like other UNIX
programs, Honeyd is case sensitive. The syntax is as follows:

Honeyd [-dPW] [-L logfile] [-I interface] [-p personalities] 
[-x xprobe] [-a assoc] [-f config] [net…]

Here’s a breakdown of what the various switches do:

  • -d
    tells Honeyd not to daemonize and enables
    verbose debugging messages.
  • -P
    runs in polling mode rather than using pcap for
  • -W
    displays a list of interfaces.
  • -L logfile is the file to which Honeyd logs are written.
  • -I
    interface is the number of the network interface.
  • -p personalities allows Honeyd to read fingerprints.
    Fingerprints are nmap files that are designed to
    define the behavior of the simulated TCP/IP stack. There are two built in nmap files: nmap.assoc and nmap.print.
  • -x xprobe allows you to specify an xprobe-style
    fingerprint file. An xprobe file controls how
    Honeyd responds when someone uses an ICMP fingerprinting tool against it.
  • -a assoc allows you to specify an association file that
    associates nmap-style fingerprints with xprobe-style fingerprints.
  • -f config tells Honeyd to read a configuration from a
    specific file. A configuration file tells Honeyd which scripts to run.
  • net isn’t really a parameter, but rather a placeholder
    for an IP address or an IP address range. The net option allows you to
    specify a string of IP addresses that Honeyd should claim. If you do not
    specify an address or an address range, Honeyd will claim any IP addresses
    for which it detects traffic.

Sample honeypot

To get the ball rolling, open a Command prompt window and
navigate to the directory where you decompressed Honeyd. From there, enter the
Honeyd -W command. When you do, Honeyd will display a list of the machine’s
network adapters. Each adapter will be assigned a number. Pay attention to the
number assigned to the NIC that you want Honeyd to monitor.

Once you have an interface number to work with, it’s time to
actually run Honeyd. If your machine has multiple NICs, you will want to use
the interface number in conjunction with the -i

Note there are a lot of different ways that you can run
Honeyd. Honeyd is designed to emulate an operating system where no computer
exists. For example, on my network, I set up Honeyd to emulate a Windows 2000
Server on IP addresses and Currently no machines
exist at those IP addresses, but Honeyd can make it appear to would-be
intruders as though there are servers at those addresses. You can then monitor
those IP addresses for malicious traffic.

Configuration file creation

Let’s start with a very simple Honeyd configuration. Honeyd
comes with some sample configuration files, but I chose to create my own
instead. Below I have displayed the contents of my configuration file. I named
the file honeyd.conf.

create windows
set windows personality "Windows NT 4.0 Server SP5-SP6" 
set windows default tcp action reset
add windows tcp port 110 open
add windows tcp port 80 honeyd.html
add windows tcp port 25 open
add windows tcp port 21 open
add windows tcp port 22 open
add windows tcp port 0 open
bind windows
bind windows

Running Honeyd

After creating the configuration file, I opened a Command
prompt window and navigated to my Honeyd folder. I then launched Honeyd by
using the following command:

Honeyd -f honeyd.conf

Upon pressing enter, Honeyd appears to lock up the command
prompt as shown in Figure A, but it
is actually running. The program will continue to run until you press [Ctrl]C. You can verify it is running by executing a port scanner
against the bogus IP addresses. Since there are no computers using the IP
addresses, the port scanner shouldn’t detect anything at all. However, as you
can see in Figure B, Honeyd did
respond to the port scanner.

Figure A

When you issue the Honeyd command, the system will appear to lock up
although the program is functional.

Figure B

You can use a port scanner to confirm that Honeyd is working.

Those other switches

So now that you have seen a very simple Honeyd
implementation, you might be wondering about all of those other command line
switches. One common misconception about these switches involves the -l switch.
The whole idea behind most honeypots is that they operate as decoy systems.
Therefore, any time that activity is detected you can assume it’s malicious. It
might therefore make sense for the -l switch to log malicious activity.
However, you should also check out the -d switch, which enables verbose logging
for the daemon. This switch enables logging to a log file that you specify and
can be used for recording errors, not malicious activity.

The -p, -x, and -a switches are used to specify the nmap fingerprint file, the xprobe
fingerprint file, and the fingerprint association file, respectively. Honeyd
comes with sample files that you can use for this purpose. The nmap.prints file is used as the nmap
fingerprint file. The xprobe2.conf file is used to define the xprobe fingerprints. The nmap.assoc
file is an association file that relates the other two files to each other.

Should you choose to use these files, note that the nmap.prints file contains an error.
On my test machine, I could not get the file to work unless I deleted the
following lines of code:

# Contributed by Nick Hone
Fingerprint Windows NT 4 SP3