NAME

     honeyd - Honeypot Daemon

SYNOPSIS

     honeyd [-dPW] [-l logfile] [-p fingerprints] [-x xprobe] [-a assoc]
            [-f file] [-i interface] [net ...]

DESCRIPTION

     honeyd creates virtual hosts for IP addresses matching the specified net.
     It can simulate any TCP and UDP service.  It replies to ICMP echo
     requests. Currently, all UDP ports are closed by default and honeyd will
     reply with an ICMP unreachable port message if the configured personality
     permits that.

     This enables a single host to claim addresses on a LAN for network simu-
     lation.  The net argument may contain multiple addresses and network
     ranges.

     In order for honeyd to receive network traffic for IP addresses that it
     should simulate, it is necessary to either explicitly route traffic to
     it, use proxy arp or run arpd(8) for unassigned IP addresses on a shared
     network.

     honeyd exits on an interrupt or termination signal.

     The options are as follows:

     -d      Do not daemonize, and enable verbose debugging messages.

     -P      On some operating systems, it is not possible to get event noti-
             fications for pcap via select(3).  In that case, honeyd needs to
             run in polling mode.  This flag enables polling.
             
     -W      Print a list of interfaces. ** WIN32 ONLY **
			
     -l logfile
             Log packets and connections to the logfile specified by logfile.

     -p fingerprints
             Read nmap style fingerprints.  The names defined after the token
             are stored as personalities.  The personalities can be used in
             the configuration file to modify the behaviour of the simulated
             TCP stack.

     -x xprobe
             Read xprobe style fingerprints.  This file determines how honeyd
             reacts to ICMP fingerprinting tools.

     -a assoc
             Read the file that associates nmap style fingerprints with xprobe
             style fingerprints.

     -f file
             Read the configuration in file.  It is possible to create host
             templates with the configuration file that specify which servers
             should run and which scripts should be started to simulate them.

             The syntax is as follows:

             config  = creation | addition | binding | set | annotate | route [config]
             creation= "create" template-name | "create" "default"
             addition= "add" template-name proto "port" port-number action
             binding = "bind" ip-address template-name |
                       "clone" template-name template-name
             set     = "set" template-name "default" proto "action" action |
                       "set" template-name "personality" personality-name |
                       "set" template-name "personality" "random"
                       "set" template-name "subsystem" cmd-string
                       "set" template-name "uptime" seconds
                       "set" template-name "droprate" "in" percent
                       "set" template-name "uid" number ["gid" number]
                       "set" ip-address "uptime" seconds
             annotate= "annotate" personality-name [no] finscan |
                       "annotate" personality-name "fragment" ("drop" | "old" | "new")
             route   = "route" "entry" ipaddr |
                       "route" ipaddr "link" ipnetwork |
                       "route" ipaddr "add" "net" ipnetwork ipaddr ["latency" number"ms"] ["loss" percent]
             proto   = "tcp" | "udp" | "icmp"
             action  = "block" | "open" | "reset" | cmd-string | "proxy" ipaddr":"port

             The cmd-string and the personality-name are arbitrary strings
             enclosed with quotation marks.  Variable expansion on the tokens
             $ipsrc, $ipdst, $sport and $dport is performed when executing the
             command string or when resolving the proxy address.  Addition-
             ally, the environment variables HONEYD_IP_SRC, HONEYD_IP_DST,
             HONEYD_DST_PORT HONEYD_SRC_PORT and HONEYD_PERSONALITY are avail-
             able, too.

             If an IP address is not bound to a template, the actions speci-
             fied in the default template are executed.

             Personalities need to be annotated before they are assigned to a
             template or an IP address.

             The default fragment policy is to accept fragment and resolve
             overlaps in favor of old data.  If the personality returns TCP
             timestamps, the default uptime is a randomly chosen between zero
             and twenty days.

             The special include directive may be used to include other con-
             figuration files, for example to keep all personality annotations
             separate from the main configuration file.

     -i interface
             Listen on interface.

     net     The IP address or network (specified in CIDR notation) or IP
             address ranges to claim (e.g. ``10.0.0.3'', ``10.0.0.0/16'' or
             ``10.0.0.5-10.0.0.15'').  If unspecified, honeyd will attempt to
             claim any IP address it sees traffic for.


ROUTING TOPOLOGY

     honeyd supports the creation of a complete network topology including
     routing.  In order to enable the simulation of a network topology, a
     router entry point has to be configured with

       route entry <IP address>

     Every route add net directive creates the specified gateway as a new
     router.  The virtual machines that can be directly accessed by a router
     are defined as network range in the route link command.


         set template subsystem "/usr/sbin/httpd"

     and are started as a separate process for every bound template.  Applica-
     tions started as a honeyd subsystem need to be dynamically linked in
     order to work under honeyd.


LOGGING

     Honeyd has two different logging modes.  The syslog facility is used to
     log connection establishment and termination including other relevant
     packet events.

     Services started by honeyd can cause the daemon to log data by sending
     information to stderr.

     The second way of logging network activity is by using the -l flag.  This
     causes honeyd to log all received packets in a human readable format.
     For UDP and TCP connections, honeyd logs the start and end of a flow
     including the amount of data transfered.

     For logging any other information, it is suggested to run a separate
     intrusion detection system.


EXAMPLES

     A sample configuration file looks as follows:

     # Example of a simple host template and its binding
     include annotations
     create template
     set template personality "OpenBSD 2.6-2.7"
     add template tcp port 80 "sh scripts/web.sh"
     add template tcp port 22 "sh scripts/test.sh $ipsrc $dport"
     add template udp port 53 proxy yournameserver:53
     set template default tcp action reset
     set template uid 32767 gid 32767

     bind 10.11.69.2 template
     set 10.11.69.2 uptime 1327650

     A simple example of a routing topology:

     route entry 10.0.0.1
     route 10.0.0.1 link 10.2.0.0/24
     route 10.0.0.1 add net 10.2.1.0/24 10.2.0.10 latency 10ms loss 3.4
     route 10.2.0.10 link 10.2.1.0/24


FILES

     /var/run/honeyd.pid                 The PID of the current daemon.

     {prefix}/lib/honeyd/libhoneyd.so    A shared library that can be
                                         preloaded to virtualize applications
                                         within honeyd.
                                         
     {prefix}/share/honeyd/nmap.assoc    An association file to match xprobe2
                                         fingerprints against nmap.

     {prefix}/share/honeyd/nmap.prints   Nmap fingerprints used by honeyd to
                                         impersonate operating system stacks.

     {prefix}/share/honeyd/xprobe2.conf  Xprobe fingerprints used by honeyd to
                                         impersonsate the ICMP section of
                                         operating system stacks.


AUTHORS

     Niels Provos <provos@citi.umich.edu>
     WIN32 Port by Michael A. Davis <mdavis@securityprofiling.com>

Man(1) output converted with man2html