For recent information visit: www.honeyd.org
Honeyd is a small daemon that creates virtual hosts on a network. The hosts can be configured to run arbitrary services, and their personality can be adapted so that they appear to be running certain operating systems. Honeyd enables a single host to claim multiple addresses - I have tested up to 65536 - on a LAN for network simulation. Honeyd improves cyber security by providing mechanisms for threat detection and assessment. It also deters adversaries by hiding real systems in the middle of virtual systems.
It is possible to ping the virtual machines, or to traceroute them. Any type of service on the virtual machine can be simulated according to a simple configuration file. Instead of simulating a service, it is also possible to proxy it to another machine.
annotate "AIX 4.0 - 4.2" fragment old # Example of a simple host template and its binding create template set template personality "AIX 4.0 - 4.2" add template tcp port 80 "sh scripts/web.sh" add template tcp port 22 "sh scripts/test.sh $ipsrc $dport" add template tcp port 23 proxy 10.23.1.2:23 set template default tcp action reset bind 10.21.19.102 template
The different TCP personalities are learned from reading a nmap fingerprint file. The configured personality is the operating system that nmap or xprobe will return. Personalities can be annotated to determine if they allow FIN-scans for open ports or to select the preference in which they reassemble fragmented IP packets.
Honeyd can be used to create a virtual honey net or for general network monitoring. It supports the creation of a virtual network topology including dedicated routes and routers. The routes can be attributed with latency and packet loss to make the topology seem more realistic.
Because Honeyd interacts with potentially malicious adversaries, you should sandbox it with Systrace. Systrace prevents an adversary from exploiting bugs in your Honeyd scripts.
Subsystems are virtualized by intercepting their network requests and redirecting them to Honeyd. Every configuration template may contain subsystems that are started as separated processes when the template is bound to a virtual IP address. An additional benefit of this approach is the ability of honeypots to create sporadic background traffic like requesting web pages and reading email, etc.
route entry 10.0.0.1 network 10.0.0.0/8 route 10.0.0.1 link 10.0.0.0/24 route 10.0.0.1 add net 10.4.0.0/14 tunnel "thishost" "honeyd-b" route 10.0.0.1 add net 10.1.0.0/16 10.1.0.1 latency 55ms loss 0.1 route 10.0.0.1 add net 10.2.0.0/16 10.2.0.1 latency 20ms loss 0.1 route 10.0.0.1 add net 10.3.0.0/16 10.2.0.1 latency 20ms loss 0.1 route 10.1.0.1 link 10.1.0.0/24 route 10.2.0.1 link 10.2.0.0/24 [...] route 10.2.0.1 add net 10.3.0.0/16 10.3.0.1 latency 10ms loss 0.1 route 10.3.0.1 link 10.3.0.0/24 route 10.3.0.1 add net 10.3.1.1/24 10.3.1.1 latency 10ms route 10.3.0.1 add net 10.3.240.0/20 10.3.240.1 latency 5ms route 10.3.1.1 link 10.3.1.1/24 route 10.3.240.1 link 10.3.240.0/20 route 10.3.240.1 add net 0.0.0.0/0 10.3.0.1 latency 40ms loss 0.5 [...] bind 10.2.0.243 to fxp0 bind 10.3.1.15 to fxp0
Using GRE tunneling allows the creation of distributed setups that allow Honeyd to scale to larger networks. It also allows virtual machines to be spread across separate address spaces as GRE tunnel selection can be based on the source addresses.
Honeyd should compile and run on *BSD systems, GNU/Linux and Solaris.
Please check the FAQ before sending questions via email.
Without Dug Song's libdnet this work would have been much much harder. I would also like to thank Bill Cheswick, Derek Cotton, Marius Eriksen, Christopher Kolina, Christian Kreibich, Yuqing Mai, Jamie Van Randwyk, Dug Song, Lance Spitzner and Eric Thomas for helpful suggestions, ideas and code contribution, George Akimov, Peter Balland and Christian Kreibich for finding bugs.