Defining Goals

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

In order to design your honeypot system, you need to define your goals for wanting one in the first place. There are many questions to be answered before you start, including the following:

• What is your primary reason for wanting the honeypot?

• What OS environment do you want to emulate with your honeypot?

• What servers or services do you want to emulate?

• Do you want to monitor internal threats, external threats, or both?

• Do you want to offer unpatched systems as bait, or are you concerned with only successful exploits against fully patched systems?

The answers to these questions essentially define whether you will have a production or research honeypot, and how you will configure it.

Production or Research?

A primary decision is whether you want to have a production honeypot or a research honeypot. Production honeypots exist to protect your network and computers. It is their intent to lure hackers away from legitimate targets, document malicious activity, and mimic production assets. However, many first-time honeypot administrators opt for research honeypots, because they are easier to set up and maintain than production honeypots. They can be placed by themselves on separate network segments, and honeypot administrators don’t need to exert the extra effort involved with emulating their production environment.

Production Honeypots

Production honeypots should imitate existing applications, services, and servers. If your production assets are fully patched, the honeypots should be fully patched as well. The key is to bait malicious hackers into thinking your honeypot system is a legitimate asset. If done correctly and with high interaction, it will be hard for hackers to know they have interacted with a honeypot.

For example, suppose your network’s server farm consists of Windows Server 2003 running IIS 6.0, Windows 2000 Server running Microsoft SQL Server 2000, Windows NT 4.0 Server, and a Windows 2000 Server running IIS 5.0. A production honeynet would attempt to mimic these same servers and services, as illustrated in Figure 2-1.

Figure 2-1: Example of a production honeynet

A properly configured production honeynet should be configured identically to the legitimate assets. The IP address ranges should be identical, and machine names should not deviate substantially between honeypot and production assets.

You can still set up your IP addressing scheme so that you can easily identify honeypots versus legitimate assets. For example, in a Class C /24 (255.255.255.0 subnet mask) network, you can assign honeypots host addresses from .100 to .110 and production servers .1 to .99, or some similar convention.

You should not name your honeypots something obvious like honeypot1 (don’t laugh— I’ve seen it done). It’s better to follow the same naming scheme as your production computers, but give your honeypots an identifier that internal staff will recognize.

Some readers may assume that the honeynet should never be on the same subnet as the production network, but that is not true. If you’re trying to protect working assets, you might want to pepper the production network with your honeypots. We will discuss this further in the “Honeypot System Placement” section later in this chapter.

Research Honeypots

Most research honeypots are set up without all of the patches being installed, to give the casual hacker a hole to break in to. There is no need to constantly upgrade content to match your production environment. Microsoft may release several patches a week, but there is no burning need to keep a research honeypot up-to-date. You want the holes. In fact, I don’t patch my research honeypots unless I’m getting bored with seeing a particular exploit over and over again. This happens often enough these days. For instance, when the Blaster worm came out, my unpatched research Windows honeypots were successfully exploited by the worm about every 20 minutes. Initially, I wanted to keep the honeypots vulnerable to Blaster’s RPC buffer overflow exploit because I wanted to catch the guaranteed-to-come variants. But after new variants slowed down, I patched all my Windows honeypots so they would be impervious to the worm and its cousins.

Whereas a production honeypot might be limited to mimicking your working environment, a research honeypot can be any environment. If you want to learn more about Linux and Linux hacks, you can set up a Linux honeypot. Although I run primarily Windows 2000, Windows XP, and Windows Server 2003 production machines, my honeynet emulates every version of Microsoft Windows from 95 to Server 2003, plus Cisco IOS and Linux. I’ll show you how to do the same in Chapters 5 and 6.

Complexity of Research and Production Honeypots

Some honeypot authorities define research honeypots as complex and production honeypots as capturing only limited information. This is often the case, as production honeypots are mostly interested in protecting legitimate assets from compromise. They want to track and block hackers, not learn every detail.

When a production honeypot is compromised, once the exploit and hacker are learned, the honeypot is closed, and the hacker is prevented from retrying. This limits the hacker’s ability to use the compromised honeypot to damage other computer assets and protects the legitimate computer assets to their fullest.

Research honeypots, on the other hand, might allow the hacker to use the newly compromised honeypot for a long period of time, recording everything the hacker does. For example, tracking a credit card fraud ring requires that several honeypots remain compromised for months.

But I disagree that production honeypots always need to be less complex than research honeypots. If the hacker’s attack is directed toward your organization and its data, you’ll want to do as much tracking and recording as you would with a research honeypot.

Real or Virtual?

One of the biggest decisions you must make is whether your honeypots will be real or virtual. The entire honeynet shown in Figure 2-1 could be represented by one virtual honeypot system, such as VMware or Honeyd.

Real honeypots are great for high interaction, but make data control more difficult and require a lot more work if you’re going to set up a honeynet. Virtual machine honeypots, like VMware, share many of the same attributes as a real honeypot, but offer quick redeployment. Unfortunately, they can be identified by hackers with fingerprinting techniques and, because of their high interaction, can be used to attack other targets.

Emulated honeypots can be easier to set up, especially for entire honeynets, but are limited to low to medium interaction. This means that you might not capture a month-long hacker conversation, but the honeypot won’t allow innocent third-party systems to be attacked.

This chapter will cover the deployment issues surrounding both real and virtual honeypots.

Hardening a Virtual Honeypot Host

If you plan to run a virtual honeypot, you must harden the host system on which it runs. You want hackers to compromise your virtual honeypots; you don’t want them to compromise the supporting computer.

Hardening a Windows computer hosting a virtual honeypot includes the following steps:

• Physically securing the host

• Disabling the ability to boot from removable media to prevent boot viruses and local compromises

• Installing all up-to-date patches, service packs, and hot fixes

• Renaming the administrator and guest accounts, if they exist

• Securing user accounts, by deleting all inactive accounts and instituting complex passwords

• Using the NTFS file system

• Tightening file and Registry account permissions

• Uninstalling unnecessary applications and services

• Auditing startup areas (Registry, startup groups, and so on)

• Removing or securing network shares

• Not installing Internet browsers, e-mail clients, word processors, or other high-risk applications on the host

• Maintaining a known, clean copy of the system, in case it needs to be rebuilt

There are times when real honeypots should be hardened, too, to keep the hacker isolated to just the areas you want them to exploit. We will cover hardening Windows computers for real or virtual honeypots in more detail in Chapter 4. Several online web sites offer Windows hardening lists with specific recommendations:

• Center for Internet Security (http://www.cisecurity.com)

• National Security Agency’s (http://www.nsa.gov) collection of security recommendation guides

• Microsoft Security web site (http://www.microsoft.com/security)

• Windows IT Pro magazine web site (http://www.winnetmag.com)

However, the recommendations in this chapter and Chapter 4 are specifically geared toward honeypot security.

If you are running a virtual honeypot, its supporting host should be among the most hardened OSs in your environment. But be careful not to harden the host to a state where it won’t allow the honeypot to be compromised. This means that you probably don’t want to install firewall or antivirus software on your host computer. This software might block the data headed to the virtual systems as well.

After you have decided what type of honeypot to install—research or production, real or virtual—you need to decide on the network infrastructure necessary to support your honeypot system.