What can you do with
honeyd installed? First of all, it can detect any network activity: if someone makes an attempt to connect to a service via UDP or TCP or sends an ICMP packet,
honeyd will immediately document those attempts into logfiles. It's very important to understand that there is no need to create a dedicated service for that, or to listen on a port--
honeyd does everything. You can easily emulate any network service, for example, a Cisco telnet daemon or a buggy version of Sendmail. Most interestingly, every emulated service is a script written in Perl or the Bourne shell. It is very easy to create service emulators, but there is often no such need because the
honeyd web site contains everything you need for emulating almost any service.
honeyd also emulates any operating system at the network stack level, so if an intruder attempts to detect your operating system with a tool such as
honeyd will deceive him and provide bogus information that you have created. (This requires using the same tables for OS fingerprinting--tables from a set of properties of particular systems--that are used in sophisticated security programs).
With that in mind, I bet you want to configure your honeypot and wait for the first client! Before you can do that, you have to understand how the special networking works. First of all, it's important for
honeyd to have its own address space. If you run
honeyd for a C-class network, say 126.96.36.199, it will work nicely to emulate many computers and services. But you do not have to use the whole network; instead, create one fake computer. You definitely cannot run
honeyd on an already existing IP address and port. The important question is: if a packet is addressed to another computer, then how can
honeyd intercept it? The solution is to use an
arpd daemon or add to ARP table the corresponding record:
# arp -s 192.168.0.50 MAC-address pub
After such mapping, all packets addressed to 192.168.0.50 will go to the network interface identified by a given MAC-address.
honeyd will handle the traffic. If you decide to use
arpd, it is very simple to use:
# arpd 192.168.0.50
# honeyd -p nmap.prints -f honeyd.conf -l logfile.log 192.168.0.50
-p flag points to files with signatures of different operating systems--it appears to be an
nmap fingerprint table. This invocation also uses a honeyd.conf configuration file, logs everything into logfile.log, and emulates a machine with the address 192.168.0.50. Here's honeyd.conf:
create winxp set winxp personality "Microsoft Windows XP Professional SP1" set winxp uptime 319671 add winxp tcp port 80 "perl scripts/iis5.net/main.pl" set winxp default tcp action reset create cisco set router personality "Cisco 1601R router running IOS 12.1(5)" add cisco tcp port 23 "perl scripts/router-telnet.pl" set cisco default tcp action reset set cisco uid 32767 gid 32767 set cisco uptime 1327650
Most of this config file contains descriptions of virtual machines to emulate. These descriptions are patterns or templates. This example creates two new patterns (using the
create command): WinXP and Cisco. The first one emulates a server under Windows XP, allowing connections only to port 80 and sets scripts/iis5.net/main.pl as the main handler of all connections. It will emulate Microsoft IIS 5. The
personality property sets which operating system to emulate, and the whole set of OS properties will come from
For each UDP or TCP port, you can set a behavior model. It can be a local model for particular port, or a global model for all of them. The WinXP example uses the default behavior:
set router default tcp action reset
This means that the honeypot will refuse all connections to ports without any previously set rules by sending a packet with the RST flag. You can also set the
open option (send an ACK for a connection attempt) and
block (ignore any TCP or UDP request).
Port 80 for the WinXP profile has a script handler. After describing some patterns to use, the configuration binds patterns to IP addresses:
bind 192.168.0.50 cisco
If someone now attempts to connect to 192.168.0.50