Although we just saw that running Honeyd can be quite simple, it is an enormously complex tool. You can tweak it to do almost any network-related task that you can imagine. Although most of the complexity lies in the configuration described in Section 4.5, Honeyd has several command line parameters that influence its behavior.
If you have Honeyd installed correctly on your system, you can get an overview and description of the command-line parameters by executing
man honeyd
When reading the man page, the first paragraph shown in Figure 4.5 may seem rather cryptic. It is an overview of all the command line flags and their corresponding parameters. The name of the parameter gives an indication of what type of argument Honeyd expects.
honeyd [-dP] [-l logfile] [-s servicelog] [-p fingerprints] [-0 p0f-file] [-x xprobe] [-a assoc] [-f file] [-i interface] [-u uid] [-g gid] [-c host:port:username:password] [--webserver-port port] [--webserver-root path] [--rrdtool-path path] [--disable-webserver] [--disable-update] [--fix-webserver-permissions] [-V|--version] [-h|--help] [--include-dir] [net ...] |
In the following, we will explain all these parameters in detail. We are going to discuss them in slightly different order to address the more important ones first and leave the ones you are going to use less often for the end.
-f configfile: Probably, the most important flag. It tells Honeyd where to find its configuration file. The configuration file contains information about all your virtual honeypots and what services they should present to the network; see Section 4.5 for more information.
-i interface: By default, Honeyd uses the first network interface to listen to incoming traffic. However, if your Honeyd machine has multiple interfaces, you need to specify the interfaces that receive traffic for your virtual honeypots manually on the command line. For example, let's assume that your host has three interfaces: eth0 in 192.168.1.0/24, eth1 in 10.1.0.0/24, and eth2 in 10.2.0.0/24. If you want to create virtual honeypots on the latter two networks, you need to specify -i eth1 -i eth2 on the command line.
-d: This flag causes Honeyd to run in debug mode. All status messages are printed on the current terminal. This is useful to test configuration files and learn how Honeyd works. Once everything seems to be functioning correctly, this flag should be omitted so that Honeyd can run in the background as a daemon process. Even without -d, log messages will still be provided via syslog and can usually be read in /var/log/messages.
-l logfile: Enabling this flag causes Honeyd to write packet-level logs to the specified logfile. It is important that this file and the underlying directory can be written to by Honeyd. Honeyd usually runs with the user id nobody, so make sure that the directory is either user or group writeable by that user; see Section 4.8 for more information. This flag is turned off by default.
-s servicelog: Similar to the packet-level logs, enabling this flag causes Honeyd to log information provided by emulated services. This is all the data that a service script writes to stderr; see Section 4.8 for more information. This flag is turned off by default
-p fingerprints: The pathname to the Nmap fingerprints data file. If you used the default install directory of Honeyd, this file is going to live at /usr/local/share/honeyd/nmap.print. In that case, you do not need to use this flag. On the other hand, if you just installed a new version of Nmap, you might want to use the latest version of this file and can use the -p flag to tell Honeyd about its location.
-0 p0f-file: The pathname of the passive fingerprinting database. This database allows Honeyd to identify the operating system of the remote host, which can be quite useful for later analysis. If Honeyd has been installed correctly, you do not need to specify this flag.
-x xprob: The pathname to the Xprobe fingerprint database. It allows Honeyd to return correct ICMP replies to ICMP fingerprinting tools.
-a assoc: The pathname to the database that associates Xprobe fingerprints with Nmap fingerprints. This file is required to combine the benefit of both fingerprint databases. For a given virtual honeypot, the association file enabled Honeyd to return both correct TCP and ICMP replies to fingerprinting tools.