The second method for forwarding traffic is more complex. The goal of the second method is for Honeyd to reside on a network that has both valid and nonexistent systems. In this case, we cannot simply have all of the network traffic sent to the honeypot, since most of the traffic is valid and needs to go to its intended destination. As we stated earlier, Honeyd does not have the capability to identify nonexistent systems but relies on
nonexistent IP addresses to come to the honeypot. Instead, for dynamically identifying nonexistent systems, Honeyd depends on another program: the utility Arpd.[1] Arpd, developed by Dug Song, identifies nonexistent systems and then forwards any connections to them to the Honeyd honeypot, using a method called ARP spoofing. For the case of Honeyd, ARP spoofing is when the IP address of a nonexistent system is bound to the MAC address of the Honeyd honeypot. The end result is that regardless of the IP address of the nonexistent system, the actual packet goes to the Honeyd honeypot. Just as in the previous method, once Honeyd receives the packet, it assumes the IP address of the intended victim and interacts with the attacker.
To understand how Arpd and ARP spoofing work, we have to understand the layers of the TCP/IP protocol suite. These layers define how systems communicate with each other using TCP/IP. There are several different layer models to work with. We will use the four-layer protocol model based on Stevens [5] (see Figure 8-2).
Figure 8-2. The four layers of the TCP/IP protocol suite. (This model is based on Stevens [5].)
We will start at the bottom and work our way up Stevens' model. At the bottom, the link layer handles all the hardware issues of physically interfacing the cable (or whatever media you choose) and network interface card. A common example of this layer is Ethernet. The second layer, the network layer, handles the movement of packets around different networks. An example of this is the IP protocol. The transport layer provides a flow of data between two hosts for the application layer above. A common example of this is TCP. Finally, the
application layer handles the details of the particular application. A common example of this is HTTP. The layers we are concerned with are layers 1 (link) and layer 2 (network). These are the layers involved in getting packets from one system to another and are used by ARP spoofing.
The network layer is IP addressing—the unique IP addresses assigned to each system so it can communicate over large networks such as the Internet. IP addresses ensure that systems on two different networks can
communicate. However, if two systems are on the same local network, or once a packet from two different networks reaches the network of its intended destination, then communication is based on the lower protocol, the link layer protocol. For many organizations, the link layer is the Ethernet protocol.
Ethernet, like IP addressing, uses a unique identification number, called MAC (Media Access Control) identifier. This unique identifier is assigned to each network interface card created by the manufacturer. Each number is unique, like IP addresses, ensuring systems can communicate with each other. IP addresses use a 32-bit, four- octet numbering system, whereas MAC addresses use a 48-bit, six-octet numbering system. The first three octets designate the manufacture of the card. The last three octets are a unique identifier assigned by the manufacturer, ensuring that no two network interface cards have the same MAC identifier, regardless of the manufacturer. For example, my Honeyd honeypot interface has this MAC address:
00:10:4B:70:14:E7
The first three octets, 00:10:4B, identify the manufacturer of my network interface card as 3Com Corporation. (There is a listing of the manufacturer identification numbers on the CD-ROM.) The last three octets, 70:14:E7, are the unique identifier assigned to the card by the manufacturer. When two systems on different IP networks communicate, they use IP to route packets from one network to another, based on the destination IP address. However, once the intended packet reaches the network of the destination system, then the link layer is used. In the case of Ethernet, the MAC address is used.
For a packet to reach its destination system, we have to know the MAC address of the system. We already know the IP address because the packet has reached the local network. However, we now need to know the MAC address that is associated with the destination IP address. Every system, including routers, keeps a table— called an ARP table—of every system on the local network and its associated IP and MAC address.
For example, in Figure 8-3, we see the ARP table of one of my computers on my homelab, specifically the system called apu. The network it resides on is 192.168.1.0 /24. When I look at the ARP table on my system, it has the IP address to MAC mapping of all the local systems on my home network. My system was able to build this ARP table by communicating with other systems on the local network. Whenever it communicates with a system on the local network, it remembers the MAC address of the local system and stores it in the ARP table. The second opportunity for obtaining this information is when a new system becomes live on the network. Whenever a new system is brought up, it broadcasts its IP address and MAC identifier to the local network, so everyone can update their ARP tables about the new system (kind of like introducing yourself to the class in grade school).
Figure 8-3 The ARP table of the system apu showing the MAC identifiers and IP addresses mapped together
apu $arp -a
router (192.168.1.254) at 00:E0:1E:60.70:40 [ether] on eth0 otto (192.168.1.9) at 00:50:04:67:6A:6C [ether] on eth0 itchy (192.168.1.100) at 00:50:DA:D8:7B:1C [ether] on eth0 scratchy (192.168.1.20) at 00:40:96:48:A9:54 [ether] on eth0 honeyd (192.168.1.8) at 00:10:4B:70:14:E7 [ether] on eth0
When a packet finally reaches the network of the destination system, the ARP table is checked for the MAC address of the intended destination system, and then the packet is sent to that MAC address, using the Link layer. When the destination system receives the packet at the Link layer, it takes it up one layer on the TCP/IP protocol set and confirms the IP address. If both the MAC and IP match, the packet is then passed up the protocol layers. When an IP packet reaches the local network or is sent by a local system, and if the MAC address of the intended system is unknown, then it must be asked. For example, in Figure 8-3 apu knows the MAC addresses of four systems on the local network: router, otto, itchy, and scratchy. To reach any of these four systems, apu will send packets with both the IP address and the MAC address. The destination system receives the packet at the link layer, using the MAC address, and then checks the IP address to see if it applies. However, if apu did not have the MAC address of one of the local systems and wanted to communicate with it, apu would have to first ask for the MAC address. For example, if apu wanted to communicate with itchy but did not have its address, it would have to find the MAC address of itchy: IP address 192.168.1.100. To do this, it asks the network for the MAC
address of IP address 192.168.1.100, using the ARP protocol or Address Resolution Protocol. In Figure 8-4, we see apu (IP address 192.168.1.50) using ARP to ask the local network for the MAC address of IP address 192.168.1.100. ARP requests are broadcast to all systems on the network, so every system is sure to see the request. Even within switched networks, all systems see the ARP request. Since 192.168.1.100 is active and on the local network, it sees the ARP request and responds with its MAC address—in this case, 0:50:DA:D8:7B:1C.
Figure 8-4 System 192.168.1.50 asking the local network for the MAC address of 192.168.1.100. 192.168.1.100 replies, supplying its MAC address.
apu #snort -v arp host 192.168.1.100
-*> Snort! <*-
Version 1.8.1-beta8 (Build 69)
By Martin Roesch ([email protected], www.snort.org)
04/14-10:41:39.190696 ARP who-has 192.168.1.100 tell 192.168.1.50 04/14-10:41:39.190766 ARP reply 192.168.1.100 is-at 0:50:DA:D8:7B:1C
Now if the system 192.168.1.100 did not exist or was not active, apu would send out several ARP requests over time until it times out. Once it times out, it determines the system does not exist and will add an incomplete entry into the arp table, with the packet never reaching its intended destination.
Now that you have an understanding of how ARP works, we can understand how the utility Arpd can be used to forward the packets of a nonexistent system to the Honeyd honeypot. Arpd runs on the same system as the Honeyd honeypot. Arpd watches all the ARP traffic on the local network. It knows what systems on the local network are active by consulting the honeypot's ARP table, just as we did in Figure 8-3. Now when an attacker attempts to connect to a system that does not exist on the local network, Arpd will be able to identify this, since the packet is intended for an IP that is not in the honeypot's ARP table. Arpd will then attempt to ARP the victims' IP. It is necessary for Arpd to send the request because unlike ARP requests, ARP replies are not broadcast and only go to their intended destination. If Arpd does get an ARP response from the victim, it will assume the system does exist, add that entry to the honeypot's ARP table, and ignore the connection attempt because it is most likely valid traffic.
However, if Arpd does not get a response from the intended victim, it will assume that the system does not exist. Once Aprd confirms that the intended victim does not exist, it executes its ARP spoofing attack. It replies to the ARP requests from the attacker (or the router) that the honeypot's own MAC address belongs to the IP of the victim. The person who requested the MAC believes the Arpd's ARP response and associates the IP address of the intended victim with the MAC address of the Honeyd honeypot. The packet now goes to Honeyd. Honeyd takes the packet, pretends it is now the IP address of the intended victim, and takes over the communication with the attacker. Since this spoofing happens at layer 2, it works in switched environments just as well as in a hubbed environments.
You have just witnessed the fatal flaw of ARP: It has no authentication mechanism. When someone requests the MAC address of a certain IP, as we see in Figure 8-4, anyone can reply with the MAC address, and the response is considered valid because there is no authentication. That is why Arpd can spoof connections: It makes people believe that whatever IP the packet is intended for, the MAC address is the MAC address of the honeypot. Once the packet is sent to the honeypot at the link layer, Honeyd takes over the connection. Let's look at an example, based on the system apu and its arp table in Figure 8-3.
Say apu is an attacker scanning the local network for victims vulnerable to an FTP exploit. Honeyd honeypot, IP address 192.168.1.8, is also on this local network, running the Arpd utility for ARP spoofing. When apu attempts to scan a system that does not exist on the local network, it will not have the MAC address because there is no system. In this case, let's say he is attempting to probe the IP address 192.168.1.200, which does not exist. The first thing apu's system will do before scanning its victim is attempt to get the MAC address of
192.168.1.200 by sending out an ARP request. Arpd on the Honeyd honeypot will see this ARP request because it is broadcast throughout the network. Arpd will then refer to the ARP table of the Honeyd honeypot. In this case, it identifies that there is no MAC address for the IP address 192.168.1.200. Arpd then sends out its own ARP request to the intended victim. If there is no response from the IP, Arpd will assume the system does not exist, and this is potentially an attack.
Arpd will then send an ARP reply to apu, saying that the MAC address of Honeyd (00:10:4B:70:14:E7) belongs to the IP address of the nonexistent target 192.168.1.200. Our attacker, apu, believes the response and sends its attack against 192.168.1.200, using the MAC address of the Honeyd honeypot. The Honeyd honeypot receives the packet at the link layer, assumes the identity of IP address 192.168.1.200, and then communicates with the attacker apu as the IP address of 192.168.1.200.
Arpd just successfully executed an ARP spoofing attack. Since apu was attempting to communicate with FTP, Honeyd will start an emulated FTP service as IP address 192.168.1.200. Our attacker apu will never realize that she was probing a nonexistent system and is now interacting with a honeypot.
ARP Proxy
ARP proxy is an alternative to ARP spoofing. Like ARP spoofing, the end goal of ARP proxy is to associate the IP address of nonexistent systems with the MAC address of the Honeyd honeypot. Arpd accomplished this dynaimcally for us in real time. However, with ARP proxy, we can statically bind nonexistent IP addresses to Honeyd's MAC address. Most versions of Unix allow a system to statically assign and broadcast such ARP assignments.
For example, let's say that within our 192.168.1.0 /24 network, we know of five systems that will never have an IP address assigned to them, specifically 192.168.1.201-205. Instead of using Arpd to monitor the network, we can manually configure these five IP addresses to be bound to the MAC of our honeypot. We use the arp-s
command on our honeypot to accomplish this. The -s parameter statically assigns the MAC address to an IP. The command would look like in Figure 8-5. If an attacker attempts to connect to any of these five nonexistent systems, the Honeyd honeypot will automatically resond with its own MAC addresses, without the help of Arpd.
Figure 8-5 Using the arp-s command to statically assign the IP addresses of known, nonexistent systems to the MAC address of the Honeyd honeypot
arp -s 192.168.1.201 00:10:4B:70:14:E7 permanent pub arp -s 192.168.1.202 00:10:4B:70:14:E7 permanent pub arp -s 192.168.1.203 00:10:4B:70:14:E7 permanent pub arp -s 192.168.1.204 00:10:4B:70:14:E7 permanent pub arp -s 192.168.1.205 00:10:4B:70:14:E7 permanent pub
The concepts of ARP spoofing and ARP proxy give Honeyd tremendous advantages. The honeypots discussed in the two previous chapters could only monitor one IP address per honeypot. Honeyd can monitor thousands, if not millions of IP addresses and detect and interact with attackers.