|
|
A conceptual overview of how Honeyd processes network packets is shown in Figure 4.4. A central machine intercepts network traffic sent to the IP addresses of configured honeypots and simulates their responses. Before we describe Honeyd's inner workings, we need to configure our network so that packets for the virtual honeypots reach the Honeyd host. For anyone who needs a quick refresher on networking, Chapter 1 explains and describes the most important network protocols.
Honeyd replies to network packets whose destination IP address belongs to one of the simulated honeypots. However, lacking the proper network configuration, Honeyd is never going to see any packets to reply to. It is our responsibility to configure the network in such a fashion that Honeyd receives packets for the IP addresses it simulates. There are several ways to do this. For example, we can create special routes for the virtual IP addresses that point to the Honeyd host, we can use Proxy ARP [7], or we can use network tunnels.
Let's say that our router has the IP address 10.1.0.1 and the address of the Honeyd host is 10.1.0.2. In this simple case, the IP addresses of virtual honeypots lie within our local network. If we assume that 10.1.0/24 is our local network, then the virtual honeypots would have addresses like 10.1.0.x, where x is a number between 3 and 254 — for example, 10.1.0.134; see Figure 4.4.
When the attacker sends a packet from the Internet to honeypot 10.1.0.x, our router receives the packet and attempts to forward it. The router queries its routing table to find the forwarding address for 10.1.0.x. Because the honeypot lies in the local network range, the router can reach it directly. In more complicated scenarios, there are other outcomes: The router could drop the packet because there is no route to the honeypot, or the router could forward the packet to another router.
However, when our router tries to forward a packet to the honeypot, it needs to translate the honeypot's IP address into a link layer or MAC address. The address resolution protocol (ARP) is responsible for this translation. For an unallocated IP address, ARP requests remain unanswered, and the router eventually drops the packet because the destination host seems to be dead. To get the router to forward the packet to the Honeyd machine, we forge the reply and return the MAC address for 10.1.0.2. There are several ways to create such a redirection. An easy method is to use the arp command. Let's say the MAC address for 10.1.0.2 was 1A:1A:60:F0:19:07. The following command would redirect packets destined for 10.1.0.34 to the Honeyd host:
/usr/sbin/arp -s 10.1.0.134 1A:1A:60:F0:19:07
If we have administrative control over router 10.1.0.1, we can insert a static route for the virtual honeypots that points to the Honeyd host 10.1.0.1 instead of using proxy ARP . For example, if the router was running NetBSD, the following command achieves this redirection:
route -n add -net 10.1.0.132/30 10.1.0.2
When the router receives a packet for any IP address in the range of 10.1.0.132 to 10.1.0.135, it forwards the complete packet to the Honeyd host and no ARP redirection is necessary. In more complex environments, it is possible to tunnel network address space to a Honeyd host. Honeyd supports the generic routing encapsulation (GRE) [34,35] tunneling protocol described in detail in Section 5.6.
|
|