Another critical issue is how you will ensure that the hacker doesnt use your Windows honeypot to attack other production systems. Data control is the issue here, and, as discussed in previous chapters, mature solutions arent widely available in the Windows world.

In order for the honeypot to appear realistic, you will need to develop content to place on the computer. Potentially, you will need to develop a content update plan. How often will the content be updated? Who will update it? Will you need to log in to the machine and create normal-looking user activity so that file-use dates and log files are updated realistically ? The normal process of logging in to Windows updates dozens to hundreds of files. Even a standalone system without any users logging in to it would have frequent file and Registry update activity. The lack of any noticeable signs of activity could be suspicious to the intruder.

Real Operating System or Virtual Machine?

Another choice is whether you want to run a real OS or host it using a virtual or emulated environment, like VMware or Virtual PC. As covered in previous chapters, a stand-alone OS is easier to deploy initially, but a VM environment allows quick redeployment, better data control, and centralized monitoring. However, if a hacker is looking for the specific clues, a VM environment can always be revealed. This chapter will discuss how to deploy both real OSs and VMs.

Which Microsoft Operating System to Choose?

Microsoft offers more than a dozen OSs you can deploy, including the following:

• Windows for Workgroups 3.11

• Windows 95/Windows 95 OSR2

• Windows 98/Windows 98 Second Edition (SE)

• Windows Millennium Edition (Me)

• Windows NT Server 3.51

• Windows NT Workstation 4.0

• Windows NT Server 4.0

• Windows NT Server 4.0 Terminal Server Edition

• Windows NT Server 4.0/4.5 Small Business Server Edition

• Windows 2000 Professional

• Windows 2000 Server

• Windows XP Home Edition

• Windows XP Professional Edition (32- and 64-bit versions available)

• Windows Server 2003 (32- and 64-bit versions available)

• Windows Small Business Server 2003

• Longhorn (32- and 64-bit beta versions available)

This list doesnt include the less popular versions, such as other beta releases, embedded versions, and mobile platform choices like Windows CE or Pocket PC. There are even computers still actively running Microsoft MS-DOS.

Many of the base OS platforms are further divided into different editions. For instance, Windows Server 2003 comes in Web, Standard, Enterprise, and Datacenter editions. The Enterprise Edition is the version that the other editions should be compared against. The Web Edition is essentially meant to serve as a web server and does not support many features of the other editions. The Web Edition supports only a maximum of 2 CPUs and 2GB of RAM. It cannot be a domain controller, but it can participate in Active Directory. It also cannot host Microsoft Certificate Services, Volume Shadow Copying, Terminal Services, or Cluster Services. The Standard Edition of Windows Server 2003 has the same software applications and services as the Enterprise Edition, but has more restricted license limitations. The Datacenter Edition is not sold through normal channels, and it is usually bought as part of high-end database solution purchase. Most Windows Server 2003 honeypots Ive seen are the Enterprise Edition. This is because the price is right, with Microsoft offering a free 180-day evaluation version. The Web Edition is also a popular choice, with its list price starting around $399. For more information about Windows Server 2003 pricing, see http://www.microsoft.com/windowsserver2003/howtobuy/licensing/pricing.mspx.

Remember that a Windows honeypot requires a licensed copy of the OS, plus any necessary client access licenses (CALs). Most of the time, when you purchase the OS, you get at least five CALs with the base product. This should be fine for most honeypots. If you are using the honeypot to attract hackers to IIS, you do not need separate CALs unless the attackers would be authenticating to a back-end SQL Server machine (not likely).

Longhorn is Microsofts next client and server base OS, which is expected to be released in 2006 or 2007. Beta copies are widely available in Microsofts beta and Microsoft Development Network (MSDN) forums. Figure 4-1 shows a screen from a beta version. Longhorn is a significant Windows upgrade with a moderate learning curve, much like the differences introduced between Windows 3.11 and Windows 95. The most talked-about Longhorn features are a SQL Server–based storage engine called Windows Future Storage (WinFS), IPv6, Microsofts Trustworthy Computing architectural changes, a new 3D video-driven user interface, new low-level APIs, and new integrated antivirus and firewall features. A future Windows Server release, code-named Blackcomb, will likely ship two to three years after Longhorn. For more details, visit http://www.winsupersite.com/longhorn. You may want to create a Longhorn research honeypot to see if its increased default security features make it more resistant to attack than its predecessors.

Figure 4-1: A Microsoft Longhorn screen

The 64-bit versions of Windows require 64-bit CPUs, like Intels Itanium or AMDs Opteron and Athlon processors. Although 64-bit versions of Windows have not been widely deployed, 64-bit malware is already in existence. The Rugrat virus (http://securityresponse. symantec .com/avcenter/venc/data/w64.rugrat.3344.html) was released in May 2004 as a working demonstration of a 64-bit virus. It is a direct-action infector virus, meaning that it infects other 64-bit executables only when executed. It does not stay resident in memory. It avoids infecting Windows system files protected by Windows File Protection (WFP).

Starting with Windows Server 2000, Terminal Server is available as an included installable application, and it no longer requires a separate version of the OS, as it did in Windows NT Server 4.0. Small Business Server editions contain Windows NT Server 4.0, 2000, or 2003, along with a set of common applications, including Exchange Server, Proxy Server (or Internet Security and Acceleration Server), SQL Server, IIS, Routing and Remote Access Server (RRAS), Shared Fax Services, and Microsoft Outlook.

Client or Server?

Do you want to run a honeypot using a client or server OS? The vast majority of honeypots run server software, but there is an exciting learning path for administrators wishing to explore client holes.

You can deploy a research honeypot using a client OS and wait to be attacked , or go on the offensive. Most malware attacks are against client OSs, but require action on the part of the end user. Usually, the end user executes a malicious file, opens a rogue e-mail, or surfs to a hacker web site. At any point in time, there are usually more than a dozen documented but unpatched holes in Internet Explorer and Outlook Express. You can create a client honeypot system whereby you surf to known malicious sites, open rogue e-mail messages, and execute untrusted files. By monitoring the client honeypot system, you can capture the malware attack and track the exploits.

Patched or Unpatched?

Should the OS you place on the honeypot be patched or left in an unpatched state? As stated in previous chapters, it depends on your goals. If the primary goal is to protect a production network, the honeypot should be patched to the level of the surrounding systems. If you are interested in a particular exploit, patch the system with all security updates, except the related patch. If you want to attract the most hacking opportunities, leave the system in an unpatched state. See the Installing Necessary Patches section later in this chapter for more information about Microsoft patches.

What Support Tools Are Available?

Another factor that will impact which OS you will install on your honeypot is the availability of software support tools. Most of the better patch–management tools are available only for the newer OSs. Most monitoring, logging, and management tools (covered in Chapter 10) are being built for Windows 2000 and above. Fortunately, there are plenty of tools that work with Windows 9 x , but you wont find those versions being updated and their bugs fixed.

When choosing an OS, make sure the support tools you want to use are available. For example, the Windows Software Update Services (SUS) patching service works with only Windows 2000 and later Microsoft computer systems.

Which Services and Applications to Install?

Production OSs never exist without running applications and updated content. Which applications and network services do you want to install?

A popular choice for honeypots is IIS. Hackers and automated malware love to attack Microsofts web server application. Other possibilities include Exchange Server, DNS, DHCP, Microsoft Office, Windows Media Services, WINS, .NET Framework, accessibility software (recently used in an announced exploit), FrontPage Server Extensions (a frequent hacker target on IIS servers), FTP, SQL Server, Certificate Services (and web enrollment), SharePoint, IAS, RRAS, Terminal Services, wireless services (802.11x networking), and so on. Of course, there is all that non-Microsoft software to consider. You need to install enough software to make the honeypot realistic.

If you are going to set up a complex application like IIS, SQL Server, or Exchange Server, do you have the expertise to install, configure, and analyze it? If you dont, youll end up doing more research, finding someone who does have the expertise, taking educational classes, or choosing not to run the application until you understand it better.

And heres another good question: How do you plan to keep the content updated? Automated malware doesnt care about updated content, but real hackers will. Unless you plan to pose your honeypot as a forgotten system, neglected by its operators, you will need some method of updating its content. I dont know of any automated tools or scripts for doing so, so updating the content will probably be a manual process.

SAM or Active Directory?

In Windows NT and later, user security principal accounts ( group and service accounts) are stored either in the local SAM database or in Active Directory. When you create a Windows honeypot, you need to decide where to create and store the user accounts.

It is probably easiest , and most secure, to create the user accounts in the local SAM. Most hackers attack the local administrator account, even if Active Directory is installed. Installing Active Directory means either making the honeypot system a domain controller or creating a secondary honeypot as the domain controller. Still, using Active Directory on a honeypot adds realism . And if you install Active Directory, you can use Group Policy Objects to install and manage user accounts and security settings. Without Active Directory, only the Local Security Policy is available (on Windows 2000 and later). As compared to Active Directorys Group Policy Objects, the Local Security Policy is significantly limited. See the Automating Security section later in this chapter for more details.

Hackers Choice?

So, which OS and applications do hackers prefer? How can you make the most attractive honeypot? First, remember that 99.9% of the attacks against most honeypots come from automated malicious programs. This means that most attacks will randomly assault your honeypot whether or not the honeypot contains a particular piece of software. To create an exploitable honeypot, it needs to contain vulnerable weaknesses and be contactable over the Internet. With that said, many honeypot administrators find high levels of exploitation using the following honeypot scenarios:

• Windows NT Server 4.0, Service Pack 2 or earlier

• Any version of Windows with weak or blank administrative passwords

• Any unpatched version of IIS

• IIS servers with Front Page Extensions installed

• Any version of Windows with open, unprotected (without passwords) network shares, although Windows 9 x systems are attacked more often because of their lack of NTFS security permissions

• Any version of Windows with port 135 (RPC) open to the Internet

• Any Windows Server version with FTP actively running

• SQL Server machines with blank SA passwords running on ports 1433 and 1434

• Exchange Server machines with open relaying allowed or with anonymous authentication allowed

In order to attract malicious exploits and hackers, create a honeypot with unpatched software or applications, attach it to the Internet, and allow its ports to be probed. Most honeypot systems following these guidelines report malicious scans within hours, or even minutes.

What Hardware Is Required?

What hardware should you use to support a honeypot running one of the Windows OSs? Table 4-1 lists the minimum and recommended CPU, RAM, and hard drive (HD) requirements for the most common OSs. Hard drive size refers to free space available.

The values shown in Table 4-1 are the minimum and recommended requirements according to Microsoft. I use a more general rule of thumb. For honeypots, I recommend a computer with a relatively new CPU and the RAM and hard drive sizes listed in Table 4-2.

If you are planning to run your honeypot as a VM session, you will need enough RAM on the host computer to run the VM software, plus enough RAM and CPU power for each concurrently running virtual session. In my experience, you need at least 128MB to 256MB of RAM set aside for the VM host itself ( assuming it is running on Windows 2000 or XP), and any of the latest CPUs are capable of adequately supporting multiple VM sessions. For example, I run three Windows Server 2003 honeypot VM sessions on a computer with 1GB of RAM. I give the host machine and each of the virtual sessions 256MB of RAM (256MB 4=1GB).