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 logging.
- -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.
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 parameter.
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 22.214.171.124 and 126.96.36.199. 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.
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 188.8.131.52 windows
bind 184.108.40.206 windows
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 220.127.116.11-18.104.22.168
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.
|When you issue the Honeyd command, the system will appear to lock up although the program is functional.|
|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 firstname.lastname@example.org
Fingerprint Windows NT 4 SP3