Honeypot System Network Devices

		Chapter 2 - A Honeypot Deployment Plan Honeypots for Windows by Roger A. Grimes Apress 2005

Before we get into the discussion of honeypot placement, it’s important to understand the operational differences between the different types of network devices used in creating a honeynet system. Honeynets are made up host computer(s) and an operational selection from the following network devices: hub, bridge, switch, router, firewall, or honeywall. Your device choices are partially determined by the goals of the honeynet and how you want your honeypot(s) isolated from the production network and monitoring workstations. This section will cover the major classes of network devices as they relate to honeypot systems, in order of increasing complexity.

Hub

A hub is a simple network device that repeats all network traffic on each of its network ports to all other ports on the hub. For this reason, a hub is often called a repeater.

All computers on a hub share a single physical network segment and collision domain. Every computer plugged into a port on a hub will be able to monitor all traffic headed to and from the other ports. All network traffic is shared between all computers, including unicast, multicast, and broadcast packets. Unicast packets are network packets sent from a source computer device to a single destination computer. Multicast packets originate from a single host and are sent to one or more computers using predefined multicast routing tables. Broadcast packets are network packets sent from a source device to all network devices on the local network.

Hubs are often used to create honeynets, as illustrated in Figure 2-2.

Figure 2-2: Honeynet created using a hub

Hub-connected networks are great for network monitoring, but they’re bad for privacy. This is a dual-edged sword for the honeypot administrator. While a hub will allow the honeypot administrator to monitor the hacker’s activities at the honeypot, so, too, can the hacker monitor the other devices connected to the hub (such as the monitoring workstation) if no additional protection exists. A honeypot system should be set up so that the hacker is isolated to one or more honeypots and the monitoring devices are hidden from easy discovery.

Honeypot administrators with a hub configuration can use both software and hardware methods to hide monitoring devices from prying hackers.

Software Solutions for Hiding Monitoring Devices

One software method, which doesn’t always work very well, is configuring the monitoring computer with a promiscuous mode network driver, but without an IP address or with an IP address that does not match the honeynet’s subnet range. The idea is that many hackers will be looking for only TCP/IP devices within the same subnetwork range, as is usually the case on production networks.

Microsoft Windows OSs don’t allow you to activate the Microsoft TCP/IP protocol without assigning an IP address, either manually or using the Dynamic Host Configuration Protocol (DHCP). So, while you can put in a TCP/IP address that doesn’t match the honeypot’s subnet addressing scheme, you cannot leave the IP address blank (as you can on other platforms). You also cannot assign 0.0.0.0 or 255.255.255.255 as a computer’s IP address, which is a trick used by some other OSs when trying to remain hidden. If you tell Windows to use a DHCP server to obtain the IP address and no DHCP server is found, Windows will assign an Automatic Private IP Address (APIPA). APIPA IP addresses are randomly generated from 169.254.0.0 to 169.254.255.255. In Windows XP and Windows Server 2003, you can configure the APIPA to be any allowable IP address you manually predefine using the Alternative Configuration tab of the TCP/IP protocol configuration dialog box. Again, Windows will not allow you to assign 0.0.0.0 or 255.255.255.255 as a viable IP address.

In an effort to fool hackers on a honeypot, you can assign the monitoring computers a completely different IP address range. This might fool a large percentage of the hackers, as they might look around for machines only by pinging or some other higher-level method dependent on correct IP addressing. Of course, if the hackers install a passive fingerprinting tool, like P0f (http://lcamtuf.coredump.cx/p0f.shtml), they still might catch the presence of the monitoring computer, even if it is on a separate IP address network range.

If you remove or disable the TCP/IP stack from Windows altogether, you won’t be able to capture TCP/IP data going by it on the wire, unless you install another IP stack. Some packet-capturing programs, like Network General’s Sniffer (http://www.sniffer.com), install their own IP stack to allow them to capture TCP/IP traffic without having an IP address. I’ve also successfully used WinPcap (http://winpcap.polito.it), a third-party packet capture driver, and the free Ethereal network protocol analyzer (http://www.ethereal.com) to capture IP traffic headed to and from the honeypot, without having an IP address.

Unfortunately, there are ways to find hosts even if they don’t have IP addresses. These methods include ARP query tools, passive monitoring tools, broadcast queries, and master browser elections (if you have NetBEUI enabled). A hacker could conceivably send out a master browser election broadcast, fooling the monitoring station into returning a response, and thus reveal its presence. The same can be said for any service or application running on the monitoring workstation, if the hacker tries enough tricks. Also, if your monitoring workstation does not have an IP address, it can make it difficult or impossible to receive log files (Syslog, Sebek, and so on) from the honeypot or to prevent remote management. Workstations without IP addresses usually need to be managed on-site. I do know one honeypot administrator who used Novell’s IPX protocol to establish connections between his management workstation and the honeypot. So far, his trick has not been detected, but it’s probably only a matter of time before a hacker notices the IPX protocol installed and begins investigating.

HOW THE ADDRESS RESOLUTION PROTOCOL WORKS

When network traffic is delivered to a remote host, it is ultimately accomplished using the remote host’s network interface card’s hardware address (also known as the media access control, or MAC, address). Address Resolution Protocol (ARP) requests and queries are used to convert logical IP addresses to hardware-layer MAC addresses. When a sending computer is looking for a receiving computer on the local network to transmit information to, it needs the receiver’s MAC address in order to transmit the network packet. If the sender does not have the receiver’s MAC address in memory (its ARP cache), it sends out an ARP broadcast. The broadcast asks all machines on the local network subnet, “Who has the specified IP address?” The receiver, or other local gateway devices, will respond with the receiver’s MAC address. The sender then uses the receiver’s MAC address to send the packet.

ARP is used only on the local segment. If the remote computer is not on the local network, the sender will transmit an ARP query for the MAC address of the gateway router device so it can send the packet to the router and on to the intended destination network. Once the packet has made it to the destination network, the destination gateway will send an ARP query for the receiver’s MAC address and complete the journey. This fact will become important in Chapters 5 and 6, when we begin to set up a virtual honeypot.

Hardware Solutions for Hiding Monitoring Devices

Because manipulating software-based IP addresses isn’t considered foolproof, honeypot administrators often turn to hardware-based solutions. A crude method for honeypot administrators comfortable with network wiring is to construct a receive-only Ethernet cable. This cable is placed between the hub and the monitoring device. A receive-only cable can be created by changing the straight-through wiring that comes with a regular twisted-pair Ethernet cable (unshielded twisted pair, or UTP). If you are skilled in network wiring or with a soldering iron, this may be the method for you.

There are two common receive-only wiring methods. One method, which works only for single-speed hubs (it does not work on dual-speed hubs or switches), involves the following steps:

1. Remove both RJ-45 connector ends of a regular UTP Ethernet cable.

2. On the monitoring workstation side of the cable, disconnect wires 1 and 2.

3. Take a short piece of wire (to be used as a jumper) and place one end into slot 1 and the other end into slot 2 on the new RJ-45 connector.

4. Place wires 3 through 8 back into their original positions, and crimp the new RJ-45 connector.

5. On the hub side of the cable, take the wire originally in slot 1 on the RJ-45 connector and place it in slot 3 along with wire 3.

6. Take the wire from slot 2 and place it in slot 6 along with wire 6. The other wires can be kept in their original positions, and the RJ-45 connector crimped. If you created the cable correctly, link lights should be lit on the hub (and on the network card, if it has a link status light).

Figure 2-3 shows the wiring schematic for a receive-only Ethernet cable.

Figure 2-3: Wiring schematic for receive-only Ethernet cable

Another wiring method, in which a capacitor is placed on wire 1 on the monitoring side, has proven effective on hubs, switches, and Fast Ethernet devices (see http://www.geocities.com/samngms/sniffing_cable/index.htm for instructions). The capacitor induces so much noise into the transmit line that the network device does not transmit data.

The safer, proven, method is to use an Ethernet tap (also called a sensor). Taps are small-form network devices especially made to spy on one or more network links. They usually don’t have keyboards or mice, and they must be configured by proprietary administrative software. One port plugs into the middle of a connection on the network segment to be monitored, and the other port plugs into a cable leading to the monitoring workstation. The tap copies network traffic off the wire and passes it to the monitoring PC. Taps usually don’t have an IP or MAC address, so they are more likely to remain invisible to intruders. Intrusion Inc. (http://www.intrusion.com) and Comcraft (http://www.comcraftfr.com/ethertap100tx.htm) are popular tap makers.

Note 

You can also find devices called UTP Y-adapters or UTP port doublers that essentially split one Ethernet wire into two connections. The two devices coming off the bi-end of the Y-adapter can supposedly receive information, but not transmit to each other. I have not tried this solution.

Hubs are simple devices and often come in handy when creating a honeynet, but you should not rely on them alone for data control or to protect remote monitoring computers. A common scenario for using a hub is to create a honeynet collection of honeypots, but then use a more intelligent device to separate the honeynet from the devices you don’t want the hacker to discover. Receive-only cables and Ethernet taps are good choices for administrators using only hub network equipment and needing transparent and secure remote monitoring.

Bridge

A bridge is a layer 2 device that directs traffic using MAC addresses, without regard for the higher-layer network protocol. Bridges are usually used to connect two separate physical subnets into one larger network. The bridge listens to all traffic occurring on each bridged segment. Each segment includes the bridge in its communications, as if it were connected to a hub.

An intelligent bridge will create a matrix table in memory, recording the MAC addresses of the computers on each segment, essentially learning which segment each computer is on. The bridge inspects all packets from all segments. If it detects that a packet has a destination MAC address not on the local segment, it will send the packet to all segments or only to the segment with the destination MAC address. Because bridges don’t automatically send all packets between two different segments, they offer a little more protection than hubs, but not much. Most of what was said about hubs applies to bridges.

Switch

Ethernet switches are the most common type of network device for connecting computers in a modern network and are frequently components of honeynets. Switches are essentially layer 2 bridge devices, directing traffic using MAC addresses, but with more specificity. Switches provide virtual connections from the source computer to the destination. No other node on a switch can listen to the traffic intended for another node, with the notable exception of broadcasts. Owing to its bridge origins, a switch will pass all broadcast packets to all nodes on the switch.

Switches, by default, keep each port’s traffic separate. This is good when you’re trying to stop the hacker from discovering computers and monitoring tools outside the honeynet, but it does add complexities for the honeypot administrator. Fortunately, there are several ways around this:

• Use taps and Y-adapters, much as you can in the hub and bridge scenarios.

• Plug a hub into the communication’s pathway between the hacker, the switch, and the honeypot. Still, the same precautions that were needed in the hub scenario need to be taken in order to avoid unwanted detection.

• Use ARP flooding to overwhelm the switch. I don’t recommend this method, except in emergency situations. In ARP flooding (also called ARP poisoning), a computer sends thousands to millions of spoofed ARP registration packets. The spoofed traffic can overwhelm older and less intelligent switches and make them revert to a hub-only mode, where all traffic is shared by all ports. Hackers sometimes use this strategy when trying to detect monitoring devices on a switch. It doesn’t work on newer switches (which are fail-safe), and it often causes older switches to lock up instead of defaulting to a hub mode.

• The best method is to use port mirroring (as was briefly discussed in Chapter 1), as illustrated in Figure 2-4. Most managed switches (those with management features and remote administration) allow traffic headed to or from one or more ports to be copied to another port. This essentially allows the management port to capture everything headed to and from the honeypot, while at the same time remaining hidden. If the port getting the mirrored data is a true management port versus a normal switched port, it should not respond to hacker broadcasts, and it will not be susceptible to some of the tricks used against hub configurations. A managed switch with port mirroring enabled is an excellent way to configure a GenI honeypot.

  
  Figure 2-4: Example of port mirroring

Router

A router is a layer 3 network device that makes traffic decisions based on IP addresses (or other layer 3 and higher packet information). The defining characteristic of a router is that it connects two or more different networks together, but each routed segment is considered a separate subnet and collision domain. Each routed segment has a different IP address range, and a router will not pass broadcasts (unlike the previously discussed devices).

It is very difficult to deploy an Internet-accessible honeypot today without one or more routers being involved. A router is usually the device that connects a local network to the Internet.

Network Address Translation

Routers often perform Network Address Translation (NAT) between devices on the local network and the Internet. NAT devices take private IP address ranges (10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255, which are not routable across the Internet) assigned to computers on the local network and convert them to public IP addresses for communications across the Internet.

NAT was created when public IP addresses started becoming scarce. NAT allows one or more internal network devices to share one or more public IP addresses when communicating across the Internet. NAT also provides a limited additional form of security because remote computers (and remote hackers) cannot directly connect to a computer with a private IP address. For these reasons, NAT is used in most production networks connecting to the Internet; directly connected public IP addressed computers are in the minority.

When creating a honeynet, you can use public IP addresses or use NAT. For example, a honeypot computer may have the private IP address of 192.168.168.200. When it communicates with other computers on the Internet, the source address of its packets will be replaced with the public IP address of the NAT router, as illustrated in Figure 2-5. When the majority of network equipment and host computers start using the IPv6 addressing scheme, it will eliminate the practical need for NAT, but private IP addressing may still be used for security purposes.

Figure 2-5: Example of NAT routing

Router Capabilities

GenI honeypots rely on routers for obscuration and data control. Adding a router between the honeynet and the firewall puts another hop between the honeypot and the production network. Routers provide several capabilities:

• They can be used to control data coming into and out of the network and honeypot.

• They can be used to direct different kinds of traffic, as defined by the source or destination address or port number, to the production network or honeynet.

• They can be configured to drop outgoing connections from the honeypot after a certain amount of attempts, or be instructed to deny all outgoing connection attempts from the start. For example, the Honeynet Project Alliance used to configure their honeynet routers to allow five to ten outgoing connections a day before shutting down the connection.

Routers can be stand-alone devices, specialized software, or a computer with two network interface cards installed. A different IP subnet can be defined on each network interface card, and most OSs will build an internal routing table to direct traffic to the appropriate network. Windows PCs are often used as gateways between local networks and the Internet. This is done by designating one network interface card as belonging to the local network and the other with an Internet address. Microsoft has automated this process using the Internet Connection Sharing Wizard, available since Windows 98 Second Edition.

With virtual honeypots, it might become necessary to define a network interface card with more than one IP address and more than one network address range. A virtual honeypot, by its very nature, resides on one computer, but may be configured to respond as more than one IP address. This is done by configuring the honeypot software with the desired IP addresses and updating the host OS’s routing tables.

Routing Tables

Routing tables tell the router where to route packets, depending on the destination IP address. In Windows, the local routing table can be displayed by typing route print at the command prompt. Listing 2-1 shows the route print output of a Windows 2000 Professional computer.

Listing 2.1: Example Route Print Output

 ================================================  Interface List  0x1 ........................... MS TCP Loopback interface  0x2 ...00 60 08 26 85 0d ...... 3Com 3C90x Ethernet Adapter  ================================================  Active Routes:  Network Destination   Netmask          Gateway           Interface           Metric  0.0.0.0               0.0.0.0          192.168.168.160  192.168.168.200     1  127.0.0.0             255.0.0.0        127.0.0.1        127.0.0.1           1  192.168.168.0         255.255.255.0    192.168.168.200  192.168.168.200     1  192.168.168.200       255.255.255.255  127.0.0.1        127.0.0.1           1  192.168.168.255       255.255.255.255  192.168.168.200  192.168.168.200     1  224.0.0.0             224.0.0.0        192.168.168.200  192.168.168.200     1  255.255.255.255       255.255.255.255  192.168.168.200  192.168.168.200     1  Default Gateway:   192.168.168.160  ================================================  Persistent Routes:    None 

In Listing 2-1, the host computer’s IP address is 192.168.168.200, the subnet mask is 255.255.255.0, and the gateway address is 192.168.168.160. The Windows routing table essentially reads like this: If a network packet is headed to a particular host computer or network (the Network Destination field) with this corresponding subnet mask (the Netmask field), send it to this IP address (the Gateway field) using this network interface card (the Interface field). The Metric field displays the cost of a particular route. If two interfaces exist for the same network destination, the interface route with the lowest cost will be chosen first, unless it is unavailable.

The information at the top of the routing table is the listing of two network interfaces. The first, 0x1, is the default loopback adapter address, which is automatically given the IP address of 127.0.0.1 on any computer. It can be used to test IP stack functionality on the computer without involving a physical network interface card. Most computers have the loopback adapter defined by default. The second network interface, 0x2, is a 3Com network card and its MAC address.

Note 

In Listing 2-1, the interfaces are number 1 and 2, respectively. The interface numbering system can change depending on the software querying and displaying the interfaces. In Chapter 3, you will see an example of this.

The next portion of the output is the routing table listings. In Listing 2-1, the entries are as follows:

• The first entry, 0.0.0.0, is essentially setting the PC’s default gateway (some routers call this the gateway of last resort). The network interface card has the address 192.168.168.200, and the Internet router has the address 192.168.168.160. So, this entry instructs the computer that if it cannot find a more specific route listed in the table, to send network packets to the 192.168.168.160 router gateway, which can be reached through interface 192.168.168.200.

• The second entry, 127.0.0.0, defines the local loopback adapter.

• The third entry, 192.168.168.0, says if the computer wants to reach any computers on the local network, to send the packets to the local network interface card. Notice that the packets are not to be sent to the local gateway, because that is needed only when the computer sends packets off the local network.

• The fourth entry, 192.168.168.200, tells the computer to route any packets headed for that IP address (itself) to the local loopback adapter. There is no need for packets destined for the local network interface card to head out to the network and then travel back in.

• The fifth entry, 192.168.168.255, is the local network’s broadcast address. The routing table is telling the computer to send broadcasts to 192.168.168.255 through the local interface card if it wants to broadcast packets to the local network.

• The sixth entry, 224.0.0.0, is the default multicast address. Network interface cards can be defined with one or more multicast IP addresses. When a packet is sent as a multicast, it will be accepted by all PCs with addresses on the multicast network.

• The last entry, 255.255.255.255, tells the computer that if it wants to broadcast a packet, it can also send it to the default broadcast address of 255.255.255.255.

• The default gateway is listed as 192.168.168.200, not 192.168.168.160, because Windows knows that broadcasts should not be passed by routers.

Although reading a routing table may seem complex initially, understanding the logic and structure of the local routing table is essential if you will be working with virtual honeypots. Incorrectly configuring local routing tables is the cause of many common virtual honeypot problems. We will be adding routes to the local routing tables and discussing them again in Chapter 6.

Firewall

Whereas routers excel at directing traffic based on the source or destination IP address, firewalls are especially interested in transport layer port numbers. A standard firewall will allow, deny, or redirect traffic based on what it sees in the network packet. A properly configured firewall should deny all traffic to all ports and IP addresses that are not specifically designated as allowed by a particular firewall rule. For instance, a firewall may allow ports 21, 22, 23, 25, 80, 110, and 443 to head out through the firewall, but automatically deny network traffic to other ports. This is called the default deny policy, and it prevents hackers from using the other 131,065 ports (65,536 TCP ports plus 65,536 UDP ports, minus the 7 ports listed in the previous sentence) in exploit opportunities.

Although firewalls usually drop unwanted packets, they can be told to redirect any requests for a particular port to specific internal IP addresses. For instance, any external queries for RPC port 135 can be automatically redirected to the honeypot. There isn’t a legitimate reason that any external Internet computer should be requesting access to port 135 on the local network. A firewall can detect these requests and automatically forward them to a honeypot, where the probe can be documented or allowed further honeypot access.

Many firewalls come with three internally routed segments: external (often the Internet), internal (the local network), and DMZ. The DMZ is most often used for public-facing servers, such as mail and web servers. DMZ zones allow greater public access but prevent communications with internal segments, except over a few limited ports. Many web sites place their web server in the DMZ and connect it to their back-end database server located in the internal zone. Using the firewall, they allow only one port and IP address coming from the DMZ to the internal segment. Accordingly, DMZs are the frequent location for a honeypot.

Note 

More and more firewalls offer the ability to have more than three segments defined. This is so the traditional zones of external (Internet), DMZ, and internal can be supplemented with additional customized security zones. Each security zone can be defined to include different computers inside and outside the traditional zone definitions. For example, external business partner web sites could be included in the internal zone, or different internal departments could be segregated from each other.

Most of today’s firewalls offer IDS-like abilities. They go far beyond merely logging that an unauthorized connection to a particular port was blocked. An older firewall might report blocked requests to port 1234. Today’s firewalls can read the packet’s data contents and detect a SubSeven trojan attack probe. An older firewall might note attempts to serially access ports 21, 22, 23, 25, 80, and 110. A modern firewall would correctly note it as a port scan. Some of today’s firewalls are capable of capturing packet data and function as rudimentary protocol analyzers.

Honeywall

As discussed in Chapter 1, GenII honeynets are embracing the idea of a honeywall (also known as a honeynet gateway). Although a GenII honeynet still has an initial Internet router (such as a cable modem, T-1 line, or DSL modem), the honeywall is a bridging firewall that replaces the rest of the devices normally used in a GenI honeynet.

Honeywalls offer several benefits:

• You are dealing with fewer devices. This means fewer IP addresses and subnets, less planning, and less to go wrong.

• Because the honeywall replaces the firewall, which is usually by default also a router, honeypots could easily be on the same network as other production servers. This will make hackers less suspicious if they’ve been able to determine the IP addresses of your other legitimate computers.

• A large portion of the data capturing can be done on the honeywall. Instead of trying to coordinate IDSs, packet traffic analyzers, routers, and firewall logs, all logging can be centrally located. At the very least, it means logging will be time-synchronized.

• The honeywall, when used with Snort-inline (http://snort-inline.sourceforge.net) or Hogwash (http://hogwash.sourceforge.net), allows data control to happen without relying on rudimentary traffic limits. Snort-inline or Hogwash can replace outgoing malicious traffic with harmless content.

Unfortunately, GenII honeypots and the concept of the honeywall are not taking off in the Windows world at the moment. However, honeywall tools are being developed in the Unix world; for example, Figure 2-6 shows the Honeynet Project’s Honeywall Administration menu. If events play out at the same speed as they have over the past few years, the Windows world won’t be seeing similar tools for about a year.

Figure 2-6: Honeynet Project’s Honeywall Administration menu

Honeypot Network Devices Summary

What is the best network device for a Windows honeynet? It depends on your objectives and your available equipment. Switches with port mirroring are an excellent way to monitor honeynet traffic without being detected by the hacker. Hubs are natural for a honeynet setup with multiple honeypots. Routers are usually used at the network perimeter, and they may be used within the honeynet to strengthen data control. Firewalls are essential in protecting your network perimeter and in setting up DMZs.

In general, use network devices set up like a packet funnel, starting with your dumbest (but fastest) devices blocking the largest amount of invalid traffic first. This means placing a router as your first network defense tool to the Internet. It can block large amounts of traffic quickly based on IP addresses, without needing to cycle through dozens of rules. Next, use a firewall to further tighten the funnel by restricting traffic based on port addresses. In a high-performance environment, consider configuring your router to block by port numbers as a way to improve overall throughput.

Configuring these devices and their related IP address schemes can be confusing, unless you really have a firm understanding of the different devices and how they treat IP network address ranges. Here are some hints:

• Computers connected to a hub, bridge, or switch, will share the same IP network address range.

• Computers on either side of a router must use a different IP network address range, as shown in Figure 2-7.

  
  Figure 2-7: Example of a simple router segment IP address scheme

• Routers and switches usually have their own management IP addresses; hubs and bridges usually don’t.

The practical effect of using a router and one or more other network devices can create moderately complex IP address schemes. In setting up a typical honeynet, it can be challenging to get all the addresses, interfaces, and subnets planned correctly. If you don’t have your IP addresses worked out correctly, your honeypot will not get any traffic.

Figure 2-8 shows a common honeynet setup and the related sample IP addresses. In this example, the honeynet has a public IP address range and all addresses have a /24 subnet mask (255.255.255.0). Using public IP addresses on the DMZ and honeynet makes the honeynet a bit more attractive to the hacker than one that uses a NAT private address.

Figure 2-8: Example of a complex honeynet IP address scheme

Note 

In Figure 2-8, assume a 255.255.255.0 subnet mask on all IP addresses.

It’s important to remember that, no matter which network device you use, all are important data-capturing sources. You can set up each of these devices to log varying levels of traffic detail to and from your honeypot. When you are analyzing an attack, as we will do in Chapter 11, coordinating events from multiple logs will prove beneficial.

Now that we have covered the most popular network devices used in a honeynet, we can discuss where to place a honeypot system.