4.6. Experiments with Honeyd

In the following two sections, we will explore two common scenarios of setting up Honeyd. The first one describes how to run Honeyd locally and does not require a network. The second one shows an easy way to use Honeyd to integrate virtual honeypots into an existing production network. The local setup is well suited for a first exploration of Honeyd, since missteps are not going to lead to a catastrophic meltdown of your network. Almost all of the features but those relating to Ethernet-level emulation are available via the local interface.

4.6.1. Experimenting with Honeyd Locally

Figure 4.9 shows a complete Honeyd configuration for two virtual honeypots on the private IP network 10.1.0.0/24. The configuration specifies two templates that can be reached via the network on IP addresses 10.1.0.1 and 10.1.0.134. Remember that a template in the context of Honeyd is a complete honeypot configuration that can be made available on multiple IP addresses. The process of making a template available at an IP address is called binding in the Honeyd jargon. We have one template for a router that mimicks the network stack of a Cisco 7206 router. It is accessible only via telnet. The other template specifies a honeypot running two services: a simple web server and a forwarder for SSH connections. In this case, the forwarder redirects SSH connections back to the connection initiator. This example is going work in your setup only if your local network is not within the 10/8 address range. If it is, simply replace all occurrences of 10.1 with 192.168 or 127.0 instead.

Figure 4.9. An example configuration for Honeyd. The configuration language is a context-free grammar. This example defines two templates: a router that can be accessed via telnet and a host that is running a web server.

create routerone set routerone personality "Cisco 7206 running IOS 11.1(24)" set routerone default tcp action reset add routerone tcp port 23 "scripts/router-telnet.pl" create netbsd set netbsd personality "NetBSD 1.5.2 running on a Commodore Amiga (68040 processor)" set netbsd default tcp action reset add netbsd tcp port 22 proxy \$ipsrc:22 add netbsd tcp port 80 "scripts/web.sh" bind 10.1.0.1 routerone bind 10.1.0.134 netbsd

Let's start Honeyd on the loopback interface with this configuration example. There are several steps we must take before we can interact with the virtual Honeypots:

route -n add -net 10.0.0.0/8 127.0.0.1

route -n add -net 10.0.0.0/8 gw 127.0.0.1

honeyd -d -i lo -f config.book 10.0.0.0/8

ping -n -c1 10.1.0.1

If you followed all these steps, it should be possible to interact with the virtual honeypots now. For example, try telnet 10.1.0.1. You should see the login screen of a router warning you that unauthorized access is prohibited. The console output from Honeyd then tells you that a connection has been established and also informs you about failed login attempts:

Connection established: tcp (127.0.0.1:4245 - 10.1.0.1:23) <->
   scripts/router-telnet.pl
E(127.0.0.1:4245 - 10.1.0.1:23): Attempted login: root/test

Of course, we are also interested on how well this configuration works to deceive Nmap, the output of nmap -sS -O -F 10.1.0.1, should look like this:

Code View: (The 1216 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 23/tcp open telnet Device type: router Running: Cisco IOS 11.X OS details: Cisco 7206 running IOS 11.1(24), Cisco 7206 router (IOS 11.1(17)

Indeed, this confirms that Honeyd correctly emulated the network stack behavior assigned to the router template. Let's try the same thing with the netbsd template. It is running on the IP address 10.1.0.134. Once again, Nmap should confirm what we specified in the configuration file. It should list the open web and SSH port and also tell us that the operating system is running NetBSD on an Amiga platform.

4.6.2. Integrating Virtual Honeypots into Production Networks

In many situations, it is not easy to get access to an unused network that can be routed to a Honeyd machine. Instead, we would like to use Honeyd to create virtual honeypots in an existing production network. We want real machines and Honeyd's virtual honeypots to coexist in peace, which implies that Honeyd had better not disrupt production network traffic. We can achieve this by creating a default template that does not respond to any network traffic. To avoid the complicated configuration of Proxy ARP, we decide to use Honeyd's built-in Ethernet capabilities. By assigning an Ethernet address to a template, Honeyd will automatically respond to ARP requests for any IP address the template has been bound to. We still need to know which IP addresses have not been allocated so we can pick a free one. However, without administrative control over a network, it may be impractical to assign static IP addresses to Honeyd.

Fortunately, we can use the dhcp command to acquire dynamic IP addresses for us; the syntax is described in Section 4.5.4. When configuring the IP addresses via DHCP, there is no longer any accidentally using an IP address that has been allocated to another machine. An example configuration for a virtual honeypot with dynamic IP address is shown in Figure 4.10.

Figure 4.10. Integrating a virtual honeypot into a production network is simple. We need to make sure that we do not interfere with existing machines and then use DHCP to get an IP address for the honeypot. For DHCP to work, we need to assign an Ethernet address to each template that wants to use DHCP.

create default set default default tcp action block set default default udp action block set default default icmp action block create linux set linux personality "Linux 2.4.20" set linux ethernet "dell" set linux default tcp action reset add linux tcp port 80 "scripts/web.sh" dhcp linux on eth0

Using Honeyd's dhcp capability is probably the easiest way to get a virtual honeypot up and running. The major drawback of this method is that we never know which IP addresses the honeypots are going to be living at. Although a DHCP server normally tries to reassign the same IP address to the same host, this feature requires that the MAC address of the host does not change. Unfortunately, when Honeyd restarts, each virtual honeypot receives a new random MAC address. This can be prevented by using the optional Ethernet argument to assign a static MAC address. The MAC address does not change across restarts of Honeyd, and the DHCP server is more likely to hand out the same IP address again. Many DHCP servers also support assigning a fixed IP address to a host if its MAC address is known.

Figure 4.11. Debug output from Honeyd when acquiring IP addresses via DHCP. When a template receives an IP address from the DHCP server, Honeyd automatically updates the ARP tables so that the honeypot is reachable under the new IP address.

honeyd[12915]: [fxp0] trying DHCP honeyd[12915]: [fxp0] got DHCP offer: 192.168.1.38 honeyd[12915]: Updating ARP binding: 00:10:11:b1:b1:97 -> 192.168.1.38

The dhcp command can be repeated as often as wanted to instantiate multiple honeypots. Although Honeyd has an internal limit of 65,535 DHCP hosts, it seems unlikely that this limit can be reached during normal usage, and most DHCP servers won't be able to handle that many leases. Before doing any extended experiments with this feature, make sure that you leave addresses available for regular users.