Change this to a more generic 404 message. Something less telling.

An IPP (Internet Printing Protocol) script for honeyd is needed. From a quick reading of the protocol, there appears to be two different ports that are commonly used: TCP 631 and UDP 631. The TCP port is for data and the actual sending of print documents. There are many features here that would be difficult to support, like authentication and encryption. The UDP port is just used for discovery, and may be significantly easier to implement.

Background
Before commit f8fd589, the scripts were duplicated multiple times with nothing changed but the version strings that the script reported itself as being. In an early attempt to remedy this problem and give the scripts more flexibility, I combined all of the Suse7 and Suse8 scripts by removing the string differences and placing them in "strings" files located in honeyd/scripts/strings.

The idea is that these strings files contain all of the recommended strings that can be chosen from in the format of a KEY followed by a space and the string. For example, in httpd.strings,

HTTPD_SERVER_VERSION Apache/1.3.23 (Unix) (SuSE/Linux) ...
HTTPD_SERVER_VERSION Apache/1.3.12 (Unix) (SuSE/Linux) ...
HTTPD_SERVER_VERSION Apache/2.2.20 (Ubuntu)
HTTPD_SERVER_VERSION SonicWALL
...

One entry for each KEY is chosen (manually right now) and placed into a configuration file for a script. See https://github.com/DataSoft/Honeyd/blob/master/scripts/strings/example.conf. A user could also manually write desired strings into the config file. The strings files just provide an easy mechanism for an untrained user to pick realistic version (and other parameter strings).

Things that are worth looking into

1. First off, is merging strings text files into a single config file a good way to do this? Android uses a similar system where you don't generally hard code strings, but provide them via a strings resource XML file. We already have a scripts.xml file for NOVA, we should expand this to not only store the script paths but also all of the configuration options for each string instead of using the .strings files. I'm not sure about the exact schema yet, but we would want GLOBAL KEYs like a log folder location that all scripts can share as well as LOCAL KEYs that only one script uses, like a specific http response string. KEYs should also have a human readable description so a user doesn't have to dig through the script code to find what they're used for. One KEY should be marked with a DEFAULT tag we can use if the user doesn't specify a string or a randomize option.
2. Write a GUI for creating the configuration files. Right now generating a config file by manually choosing the strings is a rather tedious process. It would be better if we can run the GUI without NOVA, but I imagine some amount of integration with it will be a necessity. A user should be able to specify a Honeyd node with scripts running on certain ports. They should be able to further customize the script configuration file for each node if they desire to not use the defaults or a randomized string value. NOVA would then generate all of the configuration files and the Honeyd configuration file, which will specify different paths to the script configuration files.
3. Make a standard library the scripts can use to figure out their configuration parameters rather than having different people write different file parsing implementations needlessly. This would also be good if we change the file format. The scripts are written in different languages (perl, python, shell, tcl), but we could create an executable or script that they could all call with something like,

STRING = system(getScriptString FILE KEY)

With system being replaced with the language's external execution function of choice.

A number of errors that can occur in Honeyd just get printed to stdout/stderr instead of put into the syslog file, which is the only output visible to Quasar. This makes debugging things without dropping down to the CLI and running honeyd next to impossible. One example is the errors given when something is wrong with the configuration file, such as attempts to create DHCP nodes on invalid interfaces.

/home/david/.config/nova/config/haystack_honeyd.config:47: Interface "eth0" does not exist.
honeyd: parsing configuration file failed

If you try running honeyd on a network, packets going to any of the VMs are lost if they're sent from the host computer. The effect is that the host that is running honeyd is unable to contact any of the VMs created.

Many of our "nmap -O" scans of honeypots do not get 100% correct matches to the operating system being emulated, and in some cases the first match in the fuzzy scan isn't even the one that is being emulated. Compare the fingerprint that nmap spits out for the honeypot with the fingerprint in the nmap-os-db file to see what probes and responses are coming up different than expected. This might be an actual bug where Honeyd is dropping certain probes that it's supposed to reply to, or not populating part of the packet used in the fingerprinting.

Honeyd seems to segfault if you create a node with a static IP address and then spoof udp packets using FAST with the source IP set to the same as the honeydpot IP. Stack trace follows,

#0 0x08052518 in honeyd_ether_cb (req=0x8af8b38, success=0, arg=0x8af7f5c) at honeyd.c:560
#1 0x08073930 in arp_discover (req=0x8af8b38, ha=) at arp.c:218
#2 0x0807407c in arp_request (inter=0x0, src_pa=0xbfffdab0, src_ha=0x8794168, addr=0xbfffda9c, cb=0x8052460 , arg=0x8af7f5c) at arp.c:314
#3 0x0805923c in honeyd_delay_cb (fd=-1, which=1, arg=0xbfffdb54) at honeyd.c:703
#4 0x0805347a in honeyd_delay_packet (tmpl=0x8794060, ip=0x8af7f5c, iplen=68, src=0x0, dst=0x0, ms=0, flags=6, spoof=...) at honeyd.c:835
#5 0x0805505c in honeyd_ip_send (pkt=0x8af7f5c "E", iplen=68, spoof=...) at honeyd.c:912
#6 0x08055565 in icmp_send (tmpl=0x8794060, pkt=0x8af7f5c "E", tos=0 '\000', iplen=68, df=0, ttl=64 '@', proto=1, src=4211345930, dst=4294967295, spoof=...)at honeyd.c:1616
#7 0x08056896 in icmp_error_send (tmpl=0x8794060, addr=0xbfffdfd8, type=3 '\003', code=3 '\003', rip=0xb7b63054, spoof=...) at honeyd.c:1642
#8 0x08056dbe in udp_recv_cb (tmpl=0x8794060, pkt=0xb7b63054 "E\020", pktlen=168) at honeyd.c:2504
#9 0x08058bf3 in honeyd_dispatch (tmpl=0x8794060, ip=0xb7b63054, iplen=168) at honeyd.c:2814
#10 0x08059190 in honeyd_delay_cb (fd=-1, which=1, arg=0xbfffe1d4) at honeyd.c:768
#11 0x0805347a in honeyd_delay_packet (tmpl=0x8794060, ip=0xb7b63054, iplen=168, src=0x0, dst=0x0, ms=0, flags=0, spoof=...) at honeyd.c:835
#12 0x080594e0 in honeyd_input (inter=0x8518a18, ip=0xb7b63054, iplen=) at honeyd.c:3047
#13 0x08059ad8 in honeyd_recv_cb (ag=0x8518a18 "", pkthdr=0xbfffe424, pkt=0xb7b63046 "") at honeyd.c:3202
#14 0xb7f5be64 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#15 0xb7f5e668 in pcap_dispatch () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#16 0x080721e4 in interface_recv (fd=14, type=2, arg=0x8518a18) at interface.c:516
#17 0xb7f98ce9 in event_base_loop () from /usr/lib/libevent-2.0.so.5
#18 0xb7f99a37 in event_loop () from /usr/lib/libevent-2.0.so.5
#19 0xb7f99a5b in event_dispatch () from /usr/lib/libevent-2.0.so.5
#20 0x08051cec in main (argc=0, argv=0xbffff82c) at honeyd.c:3691

Many of our "nmap -O" scans of honeypots do not get 100% correct matches to the operating system being emulated, and in some cases the first match in the fuzzy scan isn't even the one that is being emulated. Compare the fingerprint that nmap spits out for the honeypot with the fingerprint in the nmap-os-db file to see what probes and responses are coming up different than expected. This might be an actual bug where Honeyd is dropping certain probes that it's supposed to reply to, or not populating part of the packet used in the fingerprinting.

I went and sorted all the services on ports beneath 1024 (or the "well-defined" ports) from the nmap-services file in /usr/local/share/nmap by frequency; this, I think, will give us a good list as to what services should have scripts made, if possible (I have a feeling that it's going to be more of a community task for some of the proprietary protocols), and a way to prioritize what should be created first:

Service_Type: http_tcp
Port Number/Frequency: 80/48.4143

Service_Type: ipp_udp
Port Number/Frequency: 631/45.0281

Service_Type: snmp_udp
Port Number/Frequency: 161/43.3467

Service_Type: netbios-ns_udp
Port Number/Frequency: 137/36.5163

Service_Type: ntp_udp
Port Number/Frequency: 123/33.0879

Service_Type: netbios-dgm_udp
Port Number/Frequency: 138/29.783

Service_Type: microsoft-ds_udp
Port Number/Frequency: 445/25.3118

Service_Type: msrpc_udp
Port Number/Frequency: 135/24.4452

Service_Type: dhcps_udp
Port Number/Frequency: 67/22.801

Service_Type: telnet_tcp
Port Number/Frequency: 23/22.1265

Service_Type: domain_udp
Port Number/Frequency: 53/21.3496

Service_Type: https_tcp
Port Number/Frequency: 443/20.8669

Service_Type: ftp_tcp
Port Number/Frequency: 21/19.7667

Service_Type: netbios-ssn_udp
Port Number/Frequency: 139/19.3726

Service_Type: ssh_tcp
Port Number/Frequency: 22/18.2286

Service_Type: isakmp_udp
Port Number/Frequency: 500/16.3742

Service_Type: dhcpc_udp
Port Number/Frequency: 68/14.0118

Service_Type: route_udp
Port Number/Frequency: 520/13.9376

Service_Type: smtp_tcp
Port Number/Frequency: 25/13.1314

Service_Type: syslog_udp
Port Number/Frequency: 514/11.9804

Service_Type: snmptrap_udp
Port Number/Frequency: 162/10.3346

Service_Type: tftp_udp
Port Number/Frequency: 69/10.2835

These are all services that appear 10% or more of the time on hosts, according to the nmap-services file. Now, obviously some of these are already done, but I will leave the list in its entirety for review and for comments on the actual utility of the existing scripts.

Completed scripts: httpd (Linux and Windows), snmp (Unix(?)), telnet (only Linux, though there's a Windows entry in scripts.xml that uses the Linux script...), smtp (Linux), ssh (Windows and Linux), ftp (Windows and Linux)

Honeyd can easily be detected at the moment with ARP fingerprinting. The arp-scan package in Ubuntu contains a tool called arp-fingerprint, which is a Perl script that uses arp-scan to generate illegal ARP requests.

I'm not sure if it's worth trying to tie ARP fingerprinting into the templates, because most of the fingerprint fields rely on incorrect implementations and bugs, so it's terribly inaccurate on normal Linux and Windows machines (they just get lumped into a fingerprint like "Linux 2.2, 2.4, 2.6, Vista, 2008, Windows7" fingerprint). I think just fixing the invalid replies that make it stand out in the fingerprint would be sufficient.

Things to fix to make it match the "normal" fingerprint mentioned above,

• Should not respond to requests that have sender IP address in the ARP field of 127.0.0.0
• Should not respond to requests that have sender IP address in the ARP field of 255.255.255.255
• Should not respond to ARP packets that have a Hardware Type field of 255 (invalid)
• Should not respond to ARP packets that have a Protocol Type of 0xffff (invalid)
• Should not respond to ARP packets with incorrect Hardware Addr Length (should be 6 on Ethernet)
• Should not respond to ARP packets with incorrect Protocol Addr Length (should be 4 on ipv4)

If Honeyd has say 100 honeypots, it will make 100 DHCP requests immediately when it starts. The DHCP server will start responding to them a few (possibly one) at a time, and most of them will just end up timing out by the time the DHCP server gets around to making offers on all of them.

One solution would be rather than sending all of the requests when we start, to only send N > 0 DHCP request at a time, and don't send more requests until those N honeypots have gotten IP addresses.

Honeyd demotes itself from root to the user "nobody:nogroup", but the make files/installer don't give file permissions to "nobody:nogroup" on /usr/share/nova/Logs.

We need to either change the user honeyd runs as (nova group?), change the file permissions on the Logs folder, or change where honeyd stuff logs to.

It looks like this is an extern variable that was declared in update.c

To reproduce,

./configure --with-python
make

pyextend.o: In function `pyextend_security_info':
/home/david/Code/honeyd/pyextend.c:535: undefined reference to `security_update'
collect2: ld returned 1 exit status
make[2]: *** [honeyd] Error 1

Profile names currently use spaces to delimit input. We should change this to something less common, such as quotes. That was any character except quotes can be valid for profile names.

While running a standard Nmap quick scan against a honeyd honeypot, a segfault can occur due to xp_print being NULL in the following code,

honeyd.c / icmp_recv_cb
/* YM: Add ICMP Timestamp reply capability /
case ICMP_TSTAMP:
/ Happens only if xp_print != NULL /
if (xp_print->flags.icmp_timestamp_reply) {
icmp_tstamp = (struct icmp_msg_timestamp *)
((u_char)pkt + (ip->ip_hl << 2));

As of the latest commit, this has been temporarily fixed by returning if xp_print is NULL. However, this causes the OS service scan to not match 100% if we go down this branch.

This has only happened if the machine Nmap scanning the Honeypot is behind a NAT router.

The current method that honeyd uses to get a list of what hardware manufacturers belong to what MAC ranges, it just hardcodes the list into the source as a huge array. (in ethernet.c)

We should instead make honeyd read the nmap-mac-prefixes file just like Nova does.

To reproduce:

Make a configuration with many nodes. 500, say. When you try to run honeyd, it will become unresponsive to probes for the first few minutes. (approximately 5 minutes for 500 nodes). After waiting for this duration, then honeyd will respond to probes.

During this time, honeyd is not using any significant amount cpu cycles doing any tasks. So it's likely that whatever is being done here could be removed / done better.

Backtrace from a segfault on normal operation with DHCP nodes that hadn't yet seemed to acquire an IP address.

Program received signal SIGSEGV, Segmentation fault.
0x080568ee in icmp_error_send (tmpl=0x8798ae0, addr=0xbfffdef8, type=3 '\003', code=3 '\003', rip=0xb7b1d6a4, spoof=...) at honeyd.c:1642
1642        if(type == ICMP_UNREACH && code == ICMP_UNREACH_PORT && tmpl->person->udptest.un)
(gdb) backtrace
#0  0x080568ee in icmp_error_send (tmpl=0x8798ae0, addr=0xbfffdef8, type=3 '\003', code=3 '\003', rip=0xb7b1d6a4, spoof=...) at honeyd.c:1642
#1  0x08056e2e in udp_recv_cb (tmpl=0x8798ae0, pkt=0xb7b1d6a4 "E", pktlen=78) at honeyd.c:2510
#2  0x08058c63 in honeyd_dispatch (tmpl=0x8798ae0, ip=0xb7b1d6a4, iplen=78) at honeyd.c:2820
#3  0x08059200 in honeyd_delay_cb (fd=-1, which=1, arg=0xbfffe0f4) at honeyd.c:768
#4  0x0805347a in honeyd_delay_packet (tmpl=0x8798ae0, ip=0xb7b1d6a4, iplen=78, src=0x0, dst=0x0, ms=0, flags=0, spoof=...) at honeyd.c:835
#5  0x08059550 in honeyd_input (inter=0x8518a80, ip=0xb7b1d6a4, iplen=<optimized out>) at honeyd.c:3053
#6  0x08059b48 in honeyd_recv_cb (ag=0x8518a80 "\020\256Q\b\250\335\020\b\\", pkthdr=0xbfffe344, pkt=0xb7b1d696 "\377\377\377\377\377\377") at honeyd.c:3208
#7  0xb7f4fe64 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#8  0xb7f52668 in pcap_dispatch () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#9  0x08072204 in interface_recv (fd=14, type=2, arg=0x8518a80) at interface.c:516
#10 0xb7f8cce9 in event_base_loop () from /usr/lib/libevent-2.0.so.5
#11 0xb7f8da37 in event_loop () from /usr/lib/libevent-2.0.so.5
#12 0xb7f8da5b in event_dispatch () from /usr/lib/libevent-2.0.so.5
#13 0x08051cec in main (argc=0, argv=0xbffff76c) at honeyd.c:3697

personality.c:251:2: warning: enumeration value ‘ID_NONE’ not handled in switch [-Wswitch]

I wandered across the regression tests for honeyd in /regression and was hoping I could use them to make sure I didn't break stuff if I started making changes to honeyd, but it appears they all fail at the moment for various reasons. This ticket is mainly just a place to note that they currently fail and some information I discovered when working on them. It may or may not be worth going an further, they may be too depricated to worry about fixing.

Few notes in case someone takes this up again,

You need to build the code in the honeyd subfolders "dpkt" and "pypcap". You also need to track down and build the code for libdnet (and python modules, usually "python setup.py install").

Libdnet will fail with newer versions of Python (2.5+). I made a ticket on the project page at https://code.google.com/p/libdnet/issues/detail?id=25 but it looks like a dead project. For now just follow the instructions I put there as a work around. I also updated the pyrexc output for pypcap in the honeyd repo to fix the same problem.

To run the tests, "make debug" in the /regression folder will provide verbose output. "make test" will just have summary output. It gathers information from a pcap capture (using pypcap) and parses it into some simple files (with dpkt). It then does a diff on the output files it created and the old ones in the /regression folder.

Following was work to get them runnable on modern versions of Python/pcap again,

b2f14d6 REGRESS: Fix packets not being parsed correctly (something is borked in dpkt.loopback)
3766ca9 PYPCAP: Rebuild the pyx file with new version of pyrexc so it works with Python 2.5+
392e10c REGRESS: Update old personalities, use full path to config file
d571ad5 PYPCAP: Couple of minor fixes to work with newer versions of python and libpcap

They still all fail though. Some of the tests fail because of minor issues that could probably just be solved by updating the output files it diffs with, such as a suffix of "L" on some of the sequence numbers,

-%s ['DATA=TCP(seq=10000L, sum=1078, flags=6, dport=80, sport=555)']
+%s ['DATA=TCP(seq=10000, sum=1078, flags=6, dport=80, sport=555)']

Others have more concerning problems, like entire packets missing from the expected responses or inability to parse the nmap fingerprints file due to some of our changes. It's possible that they haven't been updated in a long time.

You can easily regenerate the output files by running the regression scripts with a "-g" flag, but there are still a lot of failures. The general networking script fails due to mismatched ID fields (did we randomize these at some point?),

Differ on line 9
-%s ['ID=63462']
+%s ['ID=35828']

Sequence numbers never match up either,

-%s ['DATA=TCP(seq=2704042670L, ack=10001, win=0, sum=62797, flags=18, dport=555, sport=80)']
+%s ['DATA=TCP(seq=3395479033L, ack=10001, win=0, sum=20682, flags=20, dport=555, sport=80)']

The "detect.py" script fails with various other problems. One of interest is the TTLs,

Differ on line 10
-%s ['TTL=63']
+%s ['TTL=64']

There might be some sort of off by one bug with honeyd and ping TTLs.

This is going to be a problem going forward, it makes all of the haystack nodes easily distinguishable from real nodes after a scan. I don't know exactly how this gets done, but the hostname is hardcoded in the _pack_request() method in dhcpclient.c.
It's hard to do something like this automagically, unless there's a user supplied list of acceptable hostnames or something that
can get put into an array and randomly grabbed; then there's concerns of # of hostnames available vs. # of nodes to be created, etc. It'll be a mess but it'll need to get done eventually.

Hi I tried your fork today but stumbled across multiple errors when running "make"

1. encode_int function is already declared in libevent2
   see: https://bugs.gentoo.org/show_bug.cgi?id=333099
   renaming encode_int to encode__int helped (as stated in the bugreport)
2. in ui.c the compiling errors with "dereferencing pointer to incomplete type":
   make all-recursive
   make[1]: Entering directory /home/makefu/r/Honeyd/honeyd' Making all in . make[2]: Entering directory/home/makefu/r/Honeyd/honeyd'
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c honeyd.c
   In file included from stats.h:36:0,
   from honeyd.c:98:
   ./compat/sha1.h:23:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:23:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:26:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:28:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:30:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:32:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:35:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   ./compat/sha1.h:35:3: warning: ‘bounded’ attribute directive ignored [-Wattributes]
   honeyd.c: In function ‘tcp_send’:
   honeyd.c:1432:3: warning: implicit declaration of function ‘tcp_personality_test’ [-Wimplicit-function-declaration]
   honeyd.c:1432:12: warning: assignment makes pointer from integer without a cast [enabled by default]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c command.c
   command.c: In function ‘cmd_trigger_read’:
   command.c:87:3: warning: implicit declaration of function ‘asprintf’ [-Wimplicit-function-declaration]
   test -f parse.c || /bin/sh ./ylwrap parse.y y.tab.c parse.c y.tab.h parse.h y.output parse.output -- bison -y -d
   updating parse.h
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c parse.c
   parse.y: In function ‘hydparse’:
   parse.y:1071:3: warning: implicit declaration of function ‘strptime’ [-Wimplicit-function-declaration]
   parse.y:1071:43: warning: comparison between pointer and integer [enabled by default]
   parse.y:1073:50: warning: comparison between pointer and integer [enabled by default]
   parse.y: In function ‘hyderror’:
   parse.y:1168:3: warning: implicit declaration of function ‘vasprintf’ [-Wimplicit-function-declaration]
   test -f lex.c || /bin/sh ./ylwrap lex.l lex.hyd.c lex.c -- flex -Phyd
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c lex.c
   lex.c:1814:17: warning: ‘yyunput’ defined but not used [-Wunused-function]
   lex.c:1855:16: warning: ‘input’ defined but not used [-Wunused-function]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c config.c
   config.c: In function ‘template_print’:
   config.c:914:2: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint32_t’ [-Wformat]
   config.c: In function ‘template_test_parse_error’:
   config.c:1003:12: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c personality.c
   personality.c: In function ‘tcp_personality_seq’:
   personality.c:658:6: warning: variable ‘slowhz’ set but not used [-Wunused-but-set-variable]
   personality.c: In function ‘tcp_personality_options’:
   personality.c:843:21: warning: unused variable ‘tv’ [-Wunused-variable]
   personality.c: At top level:
   personality.c:2608:1: warning: ‘print_xprobe_struct’ defined but not used [-Wunused-function]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c util.c
   util.c: In function ‘fdshare_close’:
   util.c:564:2: warning: implicit declaration of function ‘asprintf’ [-Wimplicit-function-declaration]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c ipfrag.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c router.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c tcp.c
   tcp.c: In function ‘cmd_tcp_eread’:
   tcp.c:144:2: warning: implicit declaration of function ‘asprintf’ [-Wimplicit-function-declaration]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c udp.c
   udp.c: In function ‘cmd_udp_eread’:
   udp.c:78:2: warning: implicit declaration of function ‘asprintf’ [-Wimplicit-function-declaration]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c xprobe_assoc.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c log.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c fdpass.c
   fdpass.c: In function ‘send_fd’:
   fdpass.c:66:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   fdpass.c: In function ‘receive_fd’:
   fdpass.c:148:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c atomicio.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c subsystem.c
   subsystem.c: In function ‘subsystem_listen’:
   subsystem.c:312:2: warning: implicit declaration of function ‘asprintf’ [-Wimplicit-function-declaration]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c hooks.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c plugins.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c plugins_config.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c pool.c
   296 addr_unmarshal(struct addr* addr, struct evbuffer evbuf)
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c interface.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c arp.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c gre.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c network.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c pfctl_osfp.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c pf_osfp.c
   pf_osfp.c: In function ‘pf_osfp_fingerprint_hdr’:
   pf_osfp.c:88:7: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c condition.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c osfp.c
   gcc -DHAVE_CONFIG_H -I. -I./ -I./compat -I/usr/include/pcap -I/usr/include -O2 -Wall -g -DPATH_HONEYDINCLUDE=""/usr/local/include/honeyd"" -DPATH_HONEYDDATA=""/usr/local/share/honeyd"" -DPATH_HONEYDLIB=""/usr/local/lib/honeyd"" -DHONEYD_PLUGINS_DECLARE="" -DHONEYD_PLUGINS="" -DPATH_RRDTOOL="""" -c ui.c
   ui.c: In function ‘ui_write_prompt’:
   ui.c:132:16: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
   ui.c:134:2: warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness [-Wpointer-sign]
   /usr/include/string.h:399:15: note: expected ‘const char *’ but argument is of type ‘u_char *’
   ui.c: In function ‘ui_buffer_prompt’:
   ui.c:143:16: warning: pointer targets in initialization differ in signedness [-Wpointer-sign]
   ui.c:145:2: warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness [-Wpointer-sign]
   /usr/include/string.h:399:15: note: expected ‘const char *’ but argument is of type ‘u_char *’
   ui.c: In function ‘ui_writer’:
   ui.c:249:22: error: dereferencing pointer to incomplete type
   ui.c:249:38: error: dereferencing pointer to incomplete type
   ui.c:263:12: error: dereferencing pointer to incomplete type
   ui.c: In function ‘ui_handler’:
   ui.c:280:11: error: dereferencing pointer to incomplete type
   ui.c:281:11: error: dereferencing pointer to incomplete type
   ui.c:292:43: error: dereferencing pointer to incomplete type
   ui.c:295:13: error: dereferencing pointer to incomplete type
   ui.c:296:13: error: dereferencing pointer to incomplete type
   make[2]: ** [ui.o] Error 1
   make[2]: Leaving directory /home/makefu/r/Honeyd/honeyd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/makefu/r/Honeyd/honeyd'
   make: *** [all] Error 2

Thanks for the support.

I would love to see DataSoft continuing the really great honeyd project as an open-source, community supported project

Basic implementation,

• Change configuration parsing lex magic to allow IPv6 addresses in templates
• Spoof NDP (ipv6's ARP replacement) responses for honeypots
• Change the pcap filters to allow for ipv6
• Handle interface aliases (multiple IPs per interface, one ipv4 and several ipv6)
• Handle parsing out the IP header of packets and passing payload down the stack
• Remove excess passing around of the ip header (eg, tcp_recv_cb doesn't need to know what ip version was used)
• Write an implementation of DHCPv6? Probably easier to find a library, current DHCP support is fairly primitive anyway (ticket #12)

With the default TCP configuration on the default profile set to reset, it's possible that Honeyd will start sending RST to packets that aren't destined to honeypots, which makes the machine running Honeyd to not be contactable by other machines on the LAN. This was reported by Hyperjacker while using a virtual machine with Ubuntu workstation in bridged mode with an Ethernet adapter set to bridged mode.

There are bits of Honeyd code that mention explicitly ignoring packets from the host machine. It's possible that packets were somehow bypassing this code and causing problems? This might be difficult to debug, but even if we can't reproduce it exactly, we should look into how honeyd decides if a packet is to a honeypot and if it should respond or just ignore it.

There are many, most of them look trivial. So let's eliminate them.

Honeyd should be able to be run stand alone (without Nova), but the MAC Prefix file is currently installed from the Nova project.

• Copy the MAC Prefix file to the honeyd repository
• Add it to honeyddata_DATA in Makefile.am and rerun automake so it'll be installed to /usr/share/
  • Be careful gitignore doesn't mask the updates to the automake output files
• Make a command line option for overriding the file path (look at how -p fingerprints is parsed and used with the config struct in honeyd.h/honeyd.c)
• Update the man page (honeyd.8) and usage options (honeyd.c) to show the new option

The haystack honeyd instance in the lab seems to segfault about every 2 days.

Call stack,
Thread [1] 29757 [core: 1](Suspended : Signal : SIGSEGV:Segmentation fault)
addr_cmp() at 0x1860c1
ha_compare() at arp.c:122 0x80721a5
haarptree_SPLAY() at arp.c:126 0x80721a5
haarptree_SPLAY_FIND() at arp.c:125 0x8072795
arp_find() at arp.c:230 0x8072795
honeyd_recv_cb() at honeyd.c:3,122 0x805987b
0x152d44
pcap_dispatch() at 0x155548
interface_recv() at interface.c:516 0x8070cc4
event_base_loop() at 0x136114
event_loop() at 0x136267
event_dispatch() at 0x13628b
main() at honeyd.c:3,629 0x8051b9c

Unsure how to reproduce or what the cause is. Needs more investigation, but it's some sort of error in the ARP.c code.

The new format for nmap-os-db starts out with a dummy "Match Points" personality which looks like this:

MatchPoints
SEQ(SP=25%GCD=75%ISR=25%TI=100%CI=50%II=100%SS=80%TS=100)
OPS(O1=20%O2=20%O3=20%O4=20%O5=20%O6=20)
WIN(W1=15%W2=15%W3=15%W4=15%W5=15%W6=15)
ECN(R=100%DF=20%T=15%TG=15%W=15%O=15%CC=100%Q=20)
T1(R=100%DF=20%T=15%TG=15%S=20%A=20%F=30%RD=20%Q=20)
T2(R=80%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
T3(R=80%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
T4(R=100%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
T5(R=100%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
T6(R=100%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
T7(R=80%DF=20%T=15%TG=15%W=25%S=20%A=20%F=30%O=10%RD=20%Q=20)
U1(R=50%DF=20%T=15%TG=15%IPL=100%UN=100%RIPL=100%RID=100%RIPCK=100%RUCK=100%RUD=100)
IE(R=50%DFI=40%T=15%TG=15%CD=100)

This section tells the rest of nmap how many points each hit are worth, in the event that no exact match is found. However, it's not useful in honeyd.

The current (as of the fix for ticket #23) solution is to manually comment out this section. But we should do better. Read in this section and then ignore it programmatically.

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x08056552 in icmp_recv_cb (tmpl=0x87f3be0, pkt=0xb7bef6a4 "E", pktlen=148)
    at honeyd.c:2615
2615                if(nmap_print->response)
(gdb) backtrace 
#0  0x08056552 in icmp_recv_cb (tmpl=0x87f3be0, pkt=0xb7bef6a4 "E", pktlen=148)
    at honeyd.c:2615
#1  0x08058c17 in honeyd_dispatch (tmpl=0x87f3be0, ip=0xb7bef6a4, iplen=148)
    at honeyd.c:2794
#2  0x080591d0 in honeyd_delay_cb (fd=-1, which=1, arg=0xbfffe0a4)
    at honeyd.c:768
#3  0x080534aa in honeyd_delay_packet (tmpl=0x87f3be0, ip=0xb7bef6a4, 
    iplen=148, src=0x0, dst=0x0, ms=0, flags=0, spoof=...) at honeyd.c:835
#4  0x08059520 in honeyd_input (inter=0x8507448, ip=0xb7bef6a4, 
    iplen=<optimized out>) at honeyd.c:3015
#5  0x08059b18 in honeyd_recv_cb (ag=0x8507448 "ؗP\bh\335\020\b\\", 
    pkthdr=0xbfffe2f4, pkt=0xb7bef696 "") at honeyd.c:3170
#6  0xb7f4ce64 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#7  0xb7f4f668 in pcap_dispatch () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#8  0x08071ac4 in interface_recv (fd=14, type=2, arg=0x8507448)
    at interface.c:516
#9  0xb7f89ce9 in event_base_loop () from /usr/lib/libevent-2.0.so.5
#10 0xb7f8aa37 in event_loop () from /usr/lib/libevent-2.0.so.5
#11 0xb7f8aa5b in event_dispatch () from /usr/lib/libevent-2.0.so.5
#12 0x08051d15 in main (argc=0, argv=0xbffff71c) at honeyd.c:3660

Appears that the variable nmap_print is NULL. Add a check for this and handle the error appropriately.

Networked applications like honeyd should not run as root. Since any vulnerability found then becomes a full system comprimise. So instead we have to allow a normal user to run it.

Pcap as non root is accomplished using setcap();

When attempting to run honeyd as a normal user with setcap privledges honeyd will crash with the error "honeyd: bind: Address Already in Use"

Honeyd is already in almost every repository out there. We may want to up the version to 2.0 and call it honeyd2 in our packages to avoid confusion and make dependency checking easier?

Worse case we should at least up the version number to 1.6.

This was caught while running ostest:

Program received signal SIGSEGV, Segmentation fault.
tcp_send (con=0x811fd80, flags=4 '\004', payload=0x0, len=0) at honeyd.c:1451
1451        if(tmpl->person != NULL)
(gdb) backtrace 
#0  tcp_send (con=0x811fd80, flags=4 '\004', payload=0x0, len=0)
    at honeyd.c:1451
#1  0x08057ab1 in tcp_recv_cb (tmpl=0x0, pkt=0xb7b72054 "E\020", pktlen=52)
    at honeyd.c:2332
#2  0x08058c6b in honeyd_dispatch (tmpl=0x0, ip=0xb7b72054, iplen=52)
    at honeyd.c:2786
#3  0x080591f0 in honeyd_delay_cb (fd=-1, which=1, arg=0xbfffe124)
    at honeyd.c:768
#4  0x080534aa in honeyd_delay_packet (tmpl=0x0, ip=0xb7b72054, iplen=52, 
    src=0x0, dst=0x0, ms=0, flags=0, spoof=...) at honeyd.c:835
#5  0x08059540 in honeyd_input (inter=0x83d4978, ip=0xb7b72054, 
    iplen=<optimized out>) at honeyd.c:3015
#6  0x08059b38 in honeyd_recv_cb (ag=0x83d4978 "", pkthdr=0xbfffe374, 
    pkt=0xb7b72046 "") at honeyd.c:3170
#7  0xb7f48e64 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#8  0xb7f4b668 in pcap_dispatch () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
#9  0x08071ae4 in interface_recv (fd=14, type=2, arg=0x83d4978)
    at interface.c:516
#10 0xb7f85ce9 in event_base_loop () from /usr/lib/libevent-2.0.so.5
#11 0xb7f86a37 in event_loop () from /usr/lib/libevent-2.0.so.5
#12 0xb7f86a5b in event_dispatch () from /usr/lib/libevent-2.0.so.5
#13 0x08051d15 in main (argc=0, argv=0xbffff77c) at honeyd.c:3660

Backtrace:

Program received signal SIGSEGV, Segmentation fault. 10:15:19 AM
0xb7d98b8e in vfprintf () from /lib/i386-linux-gnu/libc.so.6 10:15:20 AM
(gdb) backtrace 10:15:20 AM
#0  0xb7d98b8e in vfprintf () from /lib/i386-linux-gnu/libc.so.6 10:15:20 AM
#1  0xb7d98e6b in ?? () from /lib/i386-linux-gnu/libc.so.6 10:15:20 AM
#2  0xb7d93b85 in vfprintf () from /lib/i386-linux-gnu/libc.so.6 10:15:20 AM
#3  0xb7e3b1ae in vwarnx () from /lib/i386-linux-gnu/libc.so.6 10:15:22 AM
#4  0xb7e3b3e7 in verrx () from /lib/i386-linux-gnu/libc.so.6 10:15:22 AM
#5  0xb7e3b43f in errx () from /lib/i386-linux-gnu/libc.so.6 10:15:24 AM
#6  0x0806369c in template_clone (newname=0x8784218 "CustomNodeProfile-1", tmpl=0x8783db8, inter=0x0, start=0) at config.c:635 10:15:24 AM
#7  0x0805f7b6 in hydparse () at parse.y:361 10:15:26 AM
#8  0x080601f8 in parse_configuration (input=0x877ed58, name=0xbffff8fa "/usr/share/nova/nova/Config/haystack_honeyd.config") at parse.y:1227 10:15:26 AM
#9  0x08061dc1 in config_read (config=0xbffff8fa "/usr/share/nova/nova/Config/haystack_honeyd.config") at config.c:133 10:15:28 AM
#10 0x08051a88 in main (argc=0, argv=0xbffff7c4) at honeyd.c:3549

Background

Honeyd scripts that don't send anything to stdout before waiting for something on stdin will lag for about 2.5 seconds before input sent to the socket gets forwarded to the script's stdin. A script like telnet that sends information first will respond to input right away. However, a script like apache.sh which waits for input after the connection is established, such as "GET / /HTTP/1.1", will hang for several seconds before the "GET / /HTTP/1.1" is actually sent to the script's stdin and processed.

Reproduction

Set up the apache.sh or apache.tcl script on a port and bind that profile to an IP address.
View it in a web browser and you will notice the delay.

To reproduce using just telnet,

telnet ip 80
Enter any text and press return
Press return again to send a blank line
You'll notice a delay before the webserver script responds.

Debugging so far

Relevant functions that were identified,

command.c/cmd_fork executes the script
command.c/cmd_trigger_write seems to trigger the function to write to the script's stdin

Call trace to cmd_trigger_write,

Thread [1] 18424 (Suspended : Breakpoint)
cmd_trigger_write() at command.c:92 0x8059740
tcp_add_readbuf() at tcp.c:130 0x806cb7e
tcp_recv_cb() at honeyd.c:2,181 0x80576ae
honeyd_dispatch() at honeyd.c:2,779 0x80586eb
honeyd_delay_cb() at honeyd.c:766 0x8058c93
honeyd_delay_packet() at honeyd.c:833 0x80533fe
honeyd_input()at honeyd.c:3,008 0x8058fbf
honeyd_recv_cb() at honeyd.c:3,163 0x8059558 0x152d44
pcap_dispatch() at 0x155548
interface_recv() at interface.c:516 0x807106b
event_base_loop()at 0x136114
event_loop() at 0x136267
event_dispatch() at 0x13628b
main() at honeyd.c:3,622 0x8051c6c

I found through manually going through the call trace that the delay seems to happen somewhere inside honeyd_recv_cb. If you put a breakpoint in honeyd_input, there is already a few second delay before that breakpoint gets hit. honeyd_recv_cb seems to be getting hit as soon as the packet is received though.

Viewing the exchange in wireshark makes it seem like it doesn't respond until a TCP KEEPALIVE packet is sent. Looking into this more could provide some clues on the problem.

Honeyd failed to work with DHCP on some (all?) networks (Datasoft 10 network). It was seen functioning before, but we're unsure how it worked given what we found in the code. Creating this ticket for future reference: if we end up having new DHCP issues come up it might be caused by the changes here.

Within dhcpclient.c / dhcp_recv_cb,
/* Check if we manage a virtual machine with this ethernet address */
addr_pack(&eth_dha, ADDR_TYPE_ETH, ETH_ADDR_BITS,
&eth->eth_dst, ETH_ADDR_LEN);

if ((arp = arp_find(&eth_dha)) == NULL || !(arp->flags & ARP_INTERNAL))

This code seems to check if the Ethernet MAC address of the DHCP request is one of the ethernet addresses of the honeypots that we manage. However, rather than checking the ethernet address of the DHCP client, it was checking the address of the DHCP header (the router), which would always cause this if to fail and DHCP connections to never take place.

We added in a copy of the address from the DHCP payload to the ethernet struct that this function used.

• if ((arp = arp_find(&eth_dha)) == NULL || !(arp->flags & ARP_INTERNAL))

• udp = (struct udp_hdr *)((u_char *)ip + (ip->ip_hl << 2));
• msg = (struct dhcp_msg *)((u_char *)udp + UDP_HDR_LEN);
• msglen = ntohs(udp->uh_ulen) - UDP_HDR_LEN;

• memcpy(&eth_dha.__addr_u.__data8[0], (&msg->dh_chaddr[0]), 16);

• arp = arp_find(&eth_dha);
• if ( (arp == NULL) || !(arp->flags & ARP_INTERNAL))

This resolved the problem of DHCP not working, but should be observed for other side effects.

See commit 0ab46a0

Honeyd seems to have a bunch of code in it that duplicates what is in libevent. Such as tagging.c/h. Delete this code within the honeyd repo and make it use the actual libevent calls.

You get:

honeyd: interface_new: bad interface configuration: eth0 is not IP

And then honeyd quits.

This is a recoverable error so long as there are other valid interfaces given. You could just easily ignore this input, produce a warning, and move on. Might need to disable any nodes configured to use the interface though.

Got lucky trying to get honeyd to work on my home machine; I had snort on here from a while ago, and getting libdnet was part of the deal. There are lines in the configure file that make it seems that honeyd supported libdnet once, but I kept getting 'undefined references' to libdumbnet1 functions because the configure process will pick libdnet over libdumbnet every time if it's available. Which was weird, because I know that libdnet contains some of the functions that were getting undefined reference errors, yet it seemed to be looking for libdumbnet analogs.

In short, it appears that if libdnet and libdumbnet are both on the machine, undefined references result from the ./configure step. It may have been a local circumstance, but should be tested anyways.

I noticed several differences in the ARP behavior between honeyd and real Linux machines when observing them in Wireshark. They all come down to traits of the ARP cache in Linux actually being a lot more complicated than a simple table with a max size and timeout values.

The simplest example to observe is to take two machines that have had no communication with each other yet and one of them running Honeyd.

Contacting a closed port on Honeyd will result in,

x.x.x.x         ->     Honeyot                : TCP SYN
Honeypot   ->     MAC broadcast  : Who has x.x.x.x?
x.x.x.x          ->     Honeyot               : x.x.x.x is at x.x.x.x.x.x
Honepot     ->     x.x.x.x                    : TCP ACK/RST

However, contacting a closed port on the Linux machine will result in,

LinuxIP       ->     Honeyot                : TCP SYN
Honeypot    ->    LinuxIP                  : TCP ACK/RST
(few seconds of delay)
Honeypot   ->     LinuxMAC           :  Who has x.x.x.x?
LinuxIP       ->     Honeyot               :  LinuxIP is at x.x.x.x.x.x

The behavior seemed odd at first, Linux will let you send an IP packet even if it hasn't done an ARP request on the IP address that it's destined to; when it sees packets from a new source IP, it will add the IP/MAC pair into the ARP Table in a "DELAY / not confirmed" state. At some point it will do an ARP request to ensure the MAC address actually belongs to the IP that it saw use it, but this delay can take several seconds, and in the meantime anyone who attempts to send to that IP address with an IP socket will actually use the MAC address that was seen in the source field of packets seen so far. Another related thing is that ARP requests can be send to the broadcast MAC address or a unicast MAC address. The Linux kernel will attempt to avoid using the broadcast MAC address whenever possible to reduce network clutter, and will instead send ARP requests directly to MAC addresses that are expiring in the table or the MAC address that was seen in the source field for an IP packet.

There are a few more anomalies that are easy to spot in Wireshark. In the Linux kernel, it will set ARP entries to "STALE" after as little as 60 seconds, resulting in a new ARP request when you contact the closed port. Honeyd will just cache the ARP value for 10 minutes (hard coded in a preprocessor macro).

Another interesting feature of the kernel ARP table is that it can change timeout values of ARP entries based on positive feedback from higher protocols. There is a "base_reachable_time_ms" value you can set, but the actual time the ARP entry stays in a "REACHABLE" state can be almost indefinite if the kernel sees TCP connections being maintained or having successful 3 way handshakes.

List of things that might be able to be used,

• Initial ARP before sending packets versus sending packets to seen source MAC and delayed ARP
• When does it send ARP requests to the MAC broadcast address versus cached unicast address?
• Does the ARP table store broadcasts that it didn't query for?
• Does the ARP table store broadcasts that it didn't query for BUT it saw the query?
• Does higher level protocol usage extend ARP entry timeouts?
• What's the default timeout for an ARP entry?
• How many ARP requests are sent if they fail?
• How long between retries? Linear, exponential, or fixed delay?
• Can you determine the size of the ARP table by flooding a bunch of spoofed IPs and MACs and seeing when old entries are gone?

Code snippet:

verbose = 0;
TimeoutVal = 2;

while ((ch = getopt(argc, argv, "t:v")) != -1) {
    switch (ch) {
    case 't':
        TimeoutVal = (unsigned)atoi(optarg);
        break;

    case 'v':
        verbose = REC_VERBOSE;
        break;

The "verbose" variable is not used.

Honeyd's DHCP currently ignores the lease time (and a bunch of other DHCP params...), which means after the lease expires it'll keep hanging on to the IP even though it'll likely be assigned to someone else as well.

Things to do

Parse lease time and any other useful stuff out of DHCP ack packets
Attempt to renew address if the lease time is coming up soon (1/2 lease time is standard for a renew attempt)
Try and release/lease if the renew fails

Basically, implement all the lease parts of the protocol that are currently being ignored.

Can't get a real stack trace since it's a memory corruption error and not a segfault. Got this though,

Honeyd V1.6a Copyright (c) 2002-2007 Niels Provos
honeyd[25140]: started with -i eth0 --disable-webserver -i lo -f /home/david/.config/nova/config/haystack_honeyd.config -p /usr/share/nova/sharedFiles/nmap-os-db -s /var/log/honeyd/honeydHaystackservice.log -t /var/log/honeyd/ipList -d
honeyd[25140]: listening promiscuously on eth0: (arp or ip proto 47 or (udp and src port 67 and dst port 68) or (ip )) and not ether src 00:1e:4f:ea:45:df
honeyd[25140]: listening on lo: ip 
*** glibc detected *** honeyd: free(): invalid next size (fast): 0x099513e0 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6ff22)[0x537f22]
/lib/i386-linux-gnu/libc.so.6(+0x70bc2)[0x538bc2]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0x53bcad]
honeyd(hydparse+0xdee)[0x80621a7]
honeyd(parse_configuration+0x39)[0x8064d71]
honeyd(config_read+0x50)[0x806754a]
honeyd(main+0x9d8)[0x805d6dd]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x4e1113]
honeyd[0x8054411]

It seems to hate the profile name "pfileShared-Profile-Settings". It doesn't seem length related since I can make longer profiles than this and it doesn't crash, but maybe it's undefined behavior at that point and is still having problems even though no crash.

Configuration file,

create default
set default default tcp action block
set default default udp action block
set default default icmp action block
set default ethernet "Dell"
set default droprate in 0

create pfileShared-Profile-Settings
set pfileShared-Profile-Settings default tcp action reset
set pfileShared-Profile-Settings default udp action reset
set pfileShared-Profile-Settings default icmp action open
set pfileShared-Profile-Settings ethernet "Dell"
set pfileShared-Profile-Settings droprate in 0

clone pfileLinuxServer pfileShared-Profile-Settings
set pfileLinuxServer default tcp action reset
set pfileLinuxServer default udp action reset
set pfileLinuxServer default icmp action open
set pfileLinuxServer personality "Linux 3.0 - 3.1"
set pfileLinuxServer ethernet "Dell"
set pfileLinuxServer droprate in 0

clone pfileWinServer pfileShared-Profile-Settings
set pfileWinServer default tcp action reset
set pfileWinServer default udp action reset
set pfileWinServer default icmp action open
set pfileWinServer personality "Microsoft Windows Server 2003 SP1 or SP2"
set pfileWinServer ethernet "Dell"
set pfileWinServer droprate in 0

clone pfileDoppelganger pfileShared-Profile-Settings
set pfileDoppelganger default tcp action reset
set pfileDoppelganger default udp action reset
set pfileDoppelganger default icmp action open
set pfileDoppelganger personality "Microsoft Windows 7"
set pfileDoppelganger ethernet "Intel"
set pfileDoppelganger droprate in 0

clone pfileBSDServer pfileShared-Profile-Settings
set pfileBSDServer default tcp action reset
set pfileBSDServer default udp action reset
set pfileBSDServer default icmp action open
set pfileBSDServer personality "FreeBSD 8.2-STABLE"
set pfileBSDServer ethernet "Dell"
set pfileBSDServer droprate in 0

clone CustomNodeProfile-1 pfileWinServer
add CustomNodeProfile-1  tcp port 20 open
add CustomNodeProfile-1  tcp port 21 "sh /usr/share/honeyd/scripts/win32/win2k/msftp.sh"
add CustomNodeProfile-1  tcp port 23 "bash scripts/linux/telnetd.sh $ipsrc $sport $ipdst $dport scripts/strings/example.conf"
add CustomNodeProfile-1  tcp port 80 "bash /usr/share/honeyd/scripts/win32/web.sh"
add CustomNodeProfile-1  udp port 135 open
add CustomNodeProfile-1  tcp port 137 open
add CustomNodeProfile-1  udp port 137 open
add CustomNodeProfile-1  tcp port 139 open
dhcp CustomNodeProfile-1 on eth0 ethernet "00:16:f0:4d:19:06"

create DoppelgangerReservedTemplate
set DoppelgangerReservedTemplate default tcp action reset
set DoppelgangerReservedTemplate default udp action reset
set DoppelgangerReservedTemplate default icmp action open
set DoppelgangerReservedTemplate personality "Microsoft Windows 7"
set DoppelgangerReservedTemplate droprate in 0
add DoppelgangerReservedTemplate udp port 135 open
add DoppelgangerReservedTemplate tcp port 137 open
add DoppelgangerReservedTemplate udp port 137 open
add DoppelgangerReservedTemplate tcp port 139 open

bind 10.0.0.1 DoppelgangerReservedTemplate

clone CustomNodeProfile-3 pfileLinuxServer
add CustomNodeProfile-3  tcp port 22 "bash scripts/linux/ssh.sh $ipsrc $sport $ipdst $dport scripts/strings/example.conf"
add CustomNodeProfile-3  tcp port 80 "tclsh scripts/linux/httpd/httpd.tcl $ipsrc $sport $ipdst $dport scripts/strings/example.conf"
dhcp CustomNodeProfile-3 on eth0 ethernet "00:12:3f:c6:7c:ec"
clone CustomNodeProfile-4 pfileBSDServer
add CustomNodeProfile-4  tcp port 22 "bash scripts/linux/ssh.sh $ipsrc $sport $ipdst $dport scripts/strings/example.conf"
add CustomNodeProfile-4  tcp port 23 "perl /usr/share/honeyd/scripts/embedded/router-telnet.pl"
dhcp CustomNodeProfile-4 on eth0 ethernet "00:15:c5:99:cd:da"

From the nmap manual,

 Even though an eight-bit field like TTL can never hold values greater than 0xFF,  
 this test occasionally results in values of 0x100 or higher. This occurs when
 a system (could be the source, a target, or a system in between) corrupts or
 otherwise fails to correctly decrement the TTL. It can also occur due to asymmetric routes.

The fingerprint file contains TTL values that can exceed 8 bits. Honeyd was just stuffing them in an 8 bit field of the TCP header and causing underflows resulting in incorrect personality matches. This was somewhat fixed in f0cd3eb.

However, some personalities (about 56) have hard coded values for a TTL that are greater than 0xFF. This is used internally in nmap to represent certain conditions, and they aren't real TTL fields. In order to make these 56 or so personalities match correctly, we need to dig through the nmap code and find out what each of these values actually means, and how to mimic the things that cause them with honeyd packets.

A random example of this type of personality for later testing,

  331 # Huawei S3928P-EI switch VRP software, Version 3.10
  332 # 3Com Switch 4210 26-Port Software Version 3Com OS V3.01.01s56, Bootrom Version is 4.01
  333 # Quidway S5624F, VRP software, Version 3.10, Release 1510P02
  334 Fingerprint 3Com 4210, or Huawei Quidway S3928P-EI or S5624F switch (VRP 3.10)
  335 Class 3Com | embedded || switch
  336 Class Huawei | VRP | 3.X | switch
  337 CPE cpe:/o:huawei:vrp:3 auto
  338 SEQ(SP=FF-109%GCD=1-6%ISR=105-111%TI=I%II=I%SS=S%TS=U)
  339 OPS(O1=M200%O2=M200%O3=M200%O4=M200%O5=M200%O6=M200)
  340 WIN(W1=2000%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000)
  341 ECN(R=Y%DF=N%T=100%TG=FF%W=2000%O=M200%CC=N%Q=)
  342 T1(R=Y%DF=N%T=100%TG=FF%S=O%A=S+%F=AS%RD=0%Q=)
  343 T2(R=N)
  344 T3(R=Y%DF=N%T=100%TG=FF%W=1FC4%S=O%A=O%F=A%O=%RD=0%Q=)
  345 T4(R=Y%DF=N%T=100%TG=FF%W=2000%S=A%A=Z%F=R%O=%RD=0%Q=)
  346 T5(R=Y%DF=N%T=100%TG=FF%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
  347 T6(R=Y%DF=N%T=100%TG=FF%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
  348 T7(R=Y%DF=N%T=100%TG=FF%W=0%S=Z%A=S%F=AR%O=%RD=0%Q=)
  349 U1(DF=N%T=100%TG=FF%IPL=38%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=0%RUD=G)
  350 IE(DFI=S%T=100%TG=FF%CD=S)

When I made the repo, I accidentally made it so that it looks like "honeyd/honeyd/SOURCE". It needs to be changed so that it's just "honeyd/SOURCE"

We need to find the underlying cause of the interface variable being null. Checking for NULL everywhere is just going to cover it up. This is probably the same underlying issue as #33.

Thread [1] 4793 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation fault) 
honeyd_ether_cb() at honeyd.c:560 0x80522c9 
arp_discover() at arp.c:218 0x80784d7   
arp_request() at arp.c:314 0x80788e9    
honeyd_deliver_ethernet() at honeyd.c:587 0x80523b7 
honeyd_delay_cb() at honeyd.c:703 0x80527de 
honeyd_delay_packet() at honeyd.c:835 0x8052de1 
honeyd_ip_send() at honeyd.c:912 0x8053149  
icmp_send() at honeyd.c:1,616 0x8054d18 
icmp_error_send() at honeyd.c:1,651 0x8054f01   
udp_recv_cb() at honeyd.c:2,513 0x8057661   
honeyd_dispatch() at honeyd.c:2,823 0x805848e   
honeyd_delay_cb() at honeyd.c:768 0x8052a6e 
honeyd_delay_packet() at honeyd.c:835 0x8052de1 
honeyd_input() at honeyd.c:3,056 0x8059059  
honeyd_recv_cb() at honeyd.c:3,211 0x80596b4    
0x17fe64    
pcap_dispatch() at 0x182668 
interface_recv() at interface.c:516 0x8077234   
event_base_loop() at 0x13fce9   
event_loop() at 0x140a37    
<...more frames...> 

Thread [1] 25846 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation fault)    
    eth_send() at 0xb7f75f6c    
    _bcast() at dhcpclient.c:598 0x80826f0  
    _dhcp_getconf() at dhcpclient.c:223 0x808189a   
    dhcp_send_discover() at dhcpclient.c:189 0x8081763  
    main() at honeyd.c:3,607 0x8053c72  

Configuration file,

create default
set default default tcp action filtered
set default default udp action filtered
set default default icmp action filtered
set default personality "Linux 3.0"
set default ethernet "Dell"
set default droprate in 0

clone CustomNodeProfile-0 default
set CustomNodeProfile-0 default tcp action closed
set CustomNodeProfile-0 default udp action closed
set CustomNodeProfile-0 default icmp action open
add CustomNodeProfile-0 tcp port 21 open
add CustomNodeProfile-0 tcp port 79 open
add CustomNodeProfile-0 tcp port 80 open
add CustomNodeProfile-0 tcp port 515 open
add CustomNodeProfile-0 tcp port 631 open
add CustomNodeProfile-0 tcp port 5001 open
add CustomNodeProfile-0 tcp port 9000 open
add CustomNodeProfile-0 tcp port 9100 open
add CustomNodeProfile-0 tcp port 9200 open
add CustomNodeProfile-0 tcp port 9500 open
add CustomNodeProfile-0 tcp port 10000 open
set CustomNodeProfile-0 personality "Lexmark T522 or E332n printer"
set CustomNodeProfile-0 ethernet "Lexmark International"
dhcp CustomNodeProfile-0 on eth3 ethernet "00:04:00:44:83:ed"

Example scan with verbose fingerprint matching on personality with problem,

 35297 Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-28 18:46 MST
 35298 PRINTING 3Com SuperStack 3 Switch 3300
 35299 U1.UN: "0" NOMATCH "5493" (100 points)
 35300 DONE PRINTING 3Com SuperStack 3 Switch 3300

From nmap on the failed test,

Unused port unreachable field nonzero (UN)

 An ICMP port unreachable message header is eight bytes long,
 but only the first four are used. RFC 792 states that the last four
 bytes must be zero. A few implementations (mostly ethernet 
switches and some specialized embedded devices) set it anyway. 
The value of those last four bytes is recorded in this field.

This appears to be parsed out of the nmap fingerprint file fine, but there's some ugly code modifying offsets from the IP header in icmp_error_personality. I believe this is the wrong place for it though and it's not actually doing anything. This should probably be populating somewhere in icmp_echo_reply instead.

if(test->un != 0)
{
    //Sets the unused 4 byte field to the expected value in nmap fingerprint
    //This is the 5th through 8th bytes of the icmp header
    memcpy((ip+(ip->ip_hl << 2)+4),&test->un, 4);
    iphdr_changed = 1;
}

The Fingerprint file stores a CRC32 checksum of data it receives from certain parts of the packet. From nmap,

TCP RST data checksum (RD)

 Some operating systems return ASCII data such as error messages 
 in reset packets. This is explicitly allowed by section 4.2.2.12 of RFC 1122. 
 When Nmap encounters such data, it performs a CRC32 checksum and reports the 
 results. When there is no data, RD is set to zero. Some of the few 
 operating systems that may return data in their
 reset packets are HP-UX and versions of Mac OS prior to Mac OS X.

Honeyd parses this out of the Fingerprint but does not use it. In order to reply properly, we need to be able to generate a chunk of data which matches a given CRC32 hash. CRC32 isn't meant to be secure, and this is actually a fairly easy thing to do. Take a look at some pages on Reversing CRC32 and write a function which can generate data that matches a given CRC32 hash, and then make use of it in Honeyd's responses for this type of OS personality.

One large challenge of using honeyd service scripts is that each one takes input from different sources and in different formats. What is needed is a single unified parameter format / interface such that any program can interact with the scripts.

For instance, the Nova Web UI will want to provide input to many options in scripts. But without a unified way of providing this input, it would have to be hardcoded for each script.

Currently honeyd only processes packets going directly to a honeypot's IP address. In order to fully support things like NetBIOS, we need to be able to figure out the broadcast address for an interface and forward all broadcast packets to each Honeypot instance that should be affected by them. This also means that the scripts may need to do more checking to see if they should reply or not (think of FTP, it shouldn't reply to connection attempts from broadcast packets). Should we have some manner of registering broadcast scripts versus normal scripts? Or additional arguments to the scripts for letting them determine if it was a broadcast packet that triggered them so they can determine if they should reply or not.