Although you can deploy a honeypot without much forethought, your life will be easier if you do it the right way the first time. This section outlines the installation steps and offers some tips to make your honeypot installation go smoothly.
When installing a Windows honeypot, here are the general steps you can take to deploy and operate your honeypot:
Decide on its physical placement (as discussed in Chapter 2).
Install your chosen Windows OS on the host computer.
Harden Windows installation (see the “Hardening Microsoft Windows” section later in this chapter).
Install applications, services, and so on (including honeypot and VM software, if needed).
Create content and develop a content update plan.
Install monitoring tools (see Chapters 9 and 10).
Test your honeypot.
Make changes based on your test results, if needed.
Document configuration settings (see Chapters 10 and 11).
Clear any local log files and make a backup copy or image of your honeypot system.
Take baseline measurements (see Chapter 10).
Deploy your honeypot system in a live environment.
Monitor your honeypot and begin operational procedures.
If you use an existing hard drive in your honeypot that was previously used in a production system, consider formatting and/or running a data-wiping utility to remove previous data remnants.
Several of these steps require some explanation. The following sections provide more details about testing your honeypot (step 7), documenting configuration settings (step 9), and taking baseline measurements (step 11).
Testing your honeypot (step 7) is an important step. You want to “attack” your honeypot as if you were an intruder. If you left a particular vulnerability open, attempt to exploit it. Test your alerting mechanisms to make sure they alert you in the event of a compromise. Test your monitoring tools. If you hardened any particular area of the honeypot to prevent a particular compromise, try to compromise it. Use vulnerability assessment tools against your honeypot and employ trusted friends or coworkers to test the honeypot. If you find something not working, fix it, and then test again. The key is that you don’t want the first test of the honeypot to be a real hacker’s compromise against your system on a live environment. Testing will be covered in more detail in Chapter 12.
Documenting configuration settings (step 9) is important because you need to know what changes have been made by the hacker or malicious exploit, as compared to your honeypot’s uncompromised state. And if you need to rebuild the honeypot or improve it, you have a handy document detailing what was done to build the original honeypot.
Taking baseline measurements (step 11) is the process of measuring what the honeypot looks like prior to compromise. Although covered in detail in Chapter 10, here are some of the methods for getting baseline measurements:
If you have any tools that take “snapshots” of the honeypot in its uncompromised state, take them now and document the findings.
Measure normal network bandwidth traffic across the honeynet and to and from the honeypot. Record which programs are listed in the auto-run areas (see Listing 4-1).
Listing 4.1: Windows Auto-Run Areas
Files CONFIG.SYS (or CONFIG.NT) AUTOEXEC.BAT (or AUTOEXEC.BAT) SYSTEM.INI (look for SHELL= statement) WIN.INI (look for LOAD= and RUN= statements) Registry keys HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx HKLM\Software\Microsoft\Windows\CurrentVersion\Run HKCU\Software\Microsoft\Windows\CurrentVersion\Run HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ Explorer\Browser Helper Objects HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Windows\AppInit_Dlls
Run Microsoft’s Sysedit.exe, Msconfig.exe (not available on Windows NT or Windows 2000, unfortunately), Tasklist.exe, or Dr. Watson (Drwatson.exe or Drwtsn32.exe) utilities to document which programs, processes, and services are running on the uncompromised system.
Run Microsoft’s netstat.exe -an to list listening network TCP or UDP ports. Run the NET VIEW and nbtstat commands to document shares and NetBIOS properties.
If you use Sysinternal’s Filemon or Regmon utilities (http://www.sysinternals.com) for monitoring changes, run them on the system in its uncompromised state.
If you haven’t run these types of utilities before, you’ll be surprised that a lot of activity is occurring, even on a system that appears to be idle. And if you don’t know what the uncompromised state looks like, how can you be sure what the compromised state looks like? Chapter 10 will cover many of these tools in detail.
Listing 4-1 shows an example of listing which programs are in the auto-run areas.
When installing your honeypot, you should follow Microsoft’s typical installation procedures, but there are some special considerations.
Here are some tips that apply to all types of honeypot systems:
Consider installing the system/boot and data partitions on different disk volumes. This might offer additional protection and alternatives when planning honeypot strategies.
Don’t give away your honeypot’s identity by giving it a computer name suggesting that it is a honeypot (for example, Honeypot_Server).
Make sure the administrative password is not the same password as used for your production machines.
Create long (40 characters or longer), complex passwords for any user or service accounts needing elevated security to protect against password-cracking attacks.
Don’t install your honeypot in the same domain or directory tree as your production network.
When creating content, create items that would be known only by someone who had compromised the honeypot. This way, if you come across outside communications referencing the fake content on the honeypot, you will know it could have come only from a honeypot compromise. This is called a honeytoken. See http://www.securityfocus.com/infocus/1713 for more information.
If you are using VM software to run your honeypot, use these guidelines as well:
Don’t install the VM tools that are normally installed to assist in the VM’s emulation and with installing compatible drivers. These are too easy for the hacker to spot in Add/Remove Programs and other areas.
Make sure each honeypot virtual session is installed to its own virtual disk. Don’t share virtual disk images. Doing so will complicate forensic analysis if multiple honeypots are used.
Create honeypot virtual sessions so that changes to the virtual disks can be removed or saved. In VMware, these are known as undoable disks. In Microsoft’s Virtual PC, they are called undo disks. This way, you can save the compromised image for later analysis or undo the changes and restore the honeypot to its original state.
Modify the VM network interface card’s MAC address so that the first three octets do not immediately reveal that the MAC address belongs to a honeypot. (The octets of a MAC address must be hexadecimal values between 00h and FFh.) Virtual PC MAC addresses always begin with 00-03-FF, and VMware MAC addresses always begin with 00-50-56. This fact can be used by hackers to identify a VM session presence. In Virtual PC, you can modify the virtual session’s *.vmc file to change its MAC address. The VMC file is an XML file. Just look for the characters between <ethernet_card_address> and </ethernet_card_address> tags, and change the first three octets to some other random MAC address octets. See your VM documentation for more details.
VMware may not support the use of arbitrary MAC addresses (see http://www.vmware.com/support/ws4/doc/network_macaddr_ws.html).