Honeypots are increasingly used to provide early warning of potential intruders, identify flaws in security strategies, and improve an organization's overall security awareness. Honeypots can simulate a variety of internal and external devices, including Web servers, mail servers, database servers, application servers, and even firewalls. As a software development manager, I regularly use honeypots to gain insight into vulnerabilities in both the software my team writes and the OSs upon which we depend.
Setting up and operating a honeypot involves legal considerations as well as some expertise with networking tools and computer forensics. As I describe how to set up and operate a honeypot below, I'll assume some level of familiarity with honeypot legal and ethical issues and some experience with networking and computer forensics. I often use Microsoft Virtual PC 2004 for my honeypots. Although some people might argue that VMware has a better feature set than Virtual PC, I've found that Virtual PC offers a reasonably equivalent feature set at a better price ($129 for Virtual PC versus $199 for VMware).
Choosing Your Hardware and OS
The primary driver for the hardware requirements for a virtual honeypot will be the number of simultaneous virtual sessions you plan to run. Typically, a standalone honeypot, which requires only one session, is sufficient for testing perimeter defenses or gathering early warning information about potential attacks. However, if your goals are more sophisticated?for example, if you want to test the security of a full-blown internal network?you'll almost certainly need a honeynet, which requires multiple simultaneous virtual sessions, as Figure 1 shows.
The number of simultaneous virtual sessions you can run on one computer is limited by that system's processing power and memory. Virtual PC runs on a Windows XP Professional or Windows 2000 Professional system with a 1GHz or faster processor and a CD-ROM drive. In general, each virtual session adds 32MB to 256MB of memory and 50MB to 4GB of disk space to your system requirements, so you can expect a 3GHz or faster Pentium 4 Processor (P4) with 1GB memory and a 40GB hard drive to run four or five simultaneous virtual sessions.
You'll likely need two network cards. Since your virtual sessions won't have physical network cards, they'll need to share the primary physical network card with the host. To support the sharing, Virtual PC provides a device driver for a virtual network adaptor. A honeypot setup also requires you to install on the host additional software (e.g., a desktop firewall, a network monitor) that implements network-level device drivers, which like the Virtual PC driver, may deny or alter incoming and outgoing packets. As a result, to get a true packet trace of the traffic going to and from the honeypot, it's best to capture the traffic from a second network card. You can plug the two network cards into a hub, as Figure 2 shows, and configure the primary interface with a public address on your demilitarized zone (DMZ) network and the secondary interface with a private address not on your DMZ network (ideally, the address shouldn't even be routable). You can then set the second network adaptor to promiscuous mode to listen in on traffic from the first adaptor.
I?d also recommend a DVD-RW drive for archiving forensic data to read-only media. Before setting up a virtual honeypot, I spent hours waiting for image copies of the hard disk in order to preserve evidence for later forensic analysis. These steps are simplified in a virtual world because the hard disk and the contents of memory are nothing more than files on the physical drive of the host computer. If you choose to create a dynamic virtual disk, the file containing the virtual disk will average 3GB to 4GB for most Windows OSs. So if you plan to archive this data to a read-only media, you will want a DVD-RW drive.
And finally, you need to choose an OS for your host system. Virtual PC 2004 supports only Windows XP Professional and Windows 2000, but it does actually run on Windows Server 2003 (although you?ll receive a warning on install). The primary consideration in choosing an OS is your comfort level in securing it. Because the honeypot host will be connected to a public network, hardening it as a bastion host is essential. Although all three OSs can be sufficiently hardened, I'd recommend XP or Windows 2003 over Win2K as your host platform because they offer additional security features.
Setting Up the Host
You need to secure any honeypot?even one screened from the Internet by a firewall or a router, as Figure 1 shows?as a bastion host. To have confidence in the data you collect, you must ensure that you've secured your honeypot from both internal and external intrusions. At a minimum, you should apply all available security patches, install a stateful firewall, configure security policies, enable auditing, restrict account privileges, and disable all nonessential network services. If you aren't familiar with hardening a system, I?d recommend that you read the National Security Agency's (NSA's) security configuration guides. (See the Learning Path box for information about where to find these guides.) One final tip: No hardening process is complete without penetration testing. Use security tools such as Nmap and two or more vulnerability scanners, and be sure to remediate any issues they find before you connect your system to a public network. For information about where to find Nmap and other tools mentioned in this article, see Table 1.
If you plan to use evidence gathered from a honeypot for the purpose of prosecution, keep this in mind while planning your host security. You'll need to carefully consider and document every security measure to ensure it can withstand a challenge in court. In particular, pay close attention to the potential for the host and virtual sessions to contaminate each other.
After hardening the host, you'll want to install the additional applications and utilities necessary for the operation and later forensic analysis of your honeypot. At a minimum, you'll need an Intrusion Detection System (IDS), a network monitor, penetration-testing tools, and forensic tools.
An IDS provides advanced warning of potential intrusions into your virtual sessions. You can choose from a variety of IDS types; in general, any host-based IDS such as Snort is acceptable. Although you can typically run your IDS with a default set of rules or signatures, you'll likely want to customize the rules to reduce false alarms and better reflect the deployment and usage of your honeypot. To ensure that your IDS captures all the traffic to and from your virtual sessions, set it up to use the second dormant network card to listen in on traffic from the first.
You'll also need a network monitor to identify potential attacks and reconstruct known attacks. I always capture all inbound and outbound traffic for the host and virtual sessions from when the honeypot goes live to when I take it offline. Because you'll likely spend hours reviewing packet traces, install a monitor with which you're comfortable. Although many versions of Windows come with an optional network monitoring tool, it's limited and too hard to use for analyzing sessions within the traffic. If you aren't already familiar with a specific network monitor, you might consider trying Ethereal.
For penetration-testing tools, I typically install a selection of utilities from the Windows Server 2003 Resource Kit Tools, the Microsoft Windows Security Resource Kit CD-ROM, and Sysinternals. I also install at least one vulnerability scanner and Nmap. For forensic tools, I rely on a hex editor and selected utilities from the two resource kits. I've also written a collection of utilities specifically for gathering and analyzing evidence from my honeypot.
Creating Virtual Sessions
Installing Virtual PC takes only a few minutes. The application has few options, so you'll spend most of your setup time configuring and installing the virtual sessions. A simple wizard lets you configure the memory, up to three hard drives, up to four network cards, and support for COM ports, parallel ports, and a sound card. Figure 3 shows the settings panel for a virtual session.
Virtual PC supports four types of virtual hard disks: dynamic, fixed-size, differencing, and linked-to-physical. Each of the four result in one file being created on a physical disk. Dynamic drives expand as needed by the host OS. Fixed-size disks use a predefined amount of space, which you can alter after creation. Differencing disks let you separate the changes from an original baseline image for a disk. Linking to a physical disk lets you install your virtual disk on an unmounted physical disk.
Each option has advantages and disadvantages in a honeypot setup. Linking to a physical disk increases the potential for cross-contamination from the host but is ideal if you plan to use removable drives for securing your evidence. A differencing drive lets you mix and match different changes on top of a baseline drive image but makes binary-level forensic analysis somewhat more complex. A dynamic drive provides the convenience of minimizing the disk space usage on the host and will dynamically expand based on the needs of the virtual session but doesn't let you control the apparent size of the disk. A fixed-size disk requires that you pre-allocate space on the physical disk of the host and can arouse suspicion if you allocate too little space to the disk or waste space if you allocate too much space but lets you control the visible size of the disk. All the disk options support undo disks, which provide transactional control over changes made to the disks (changes are saved in a separate file and you can commit or roll back the changes at the conclusion of a session). If you aren't sure which type of disk to choose, use dynamic drives and stay away from undo disks because they add complexity to forensic analysis.
Regardless of your disk choice, take time to wipe the virtual disk before using it to ensure that information from the host?s physical disk doesn't leak to the virtual disk. To erase the disk, first create a bootable floppy disk or CD-ROM that contains a disk-wiping utility. Alternatively, create images of the bootable floppy or CD-ROM, then load the images into the virtual session. After booting to an OS, you can run the disk-wiping utility. The freeware Active@ KillDisk utility includes a bootable International Organization for Standardization (ISO) image that you can use to boot a virtual session.
Although Virtual PC supports three types of network connectivity?shared networking through Network Address Translation (NAT), sharing a physical network adaptor, and using loopback adaptors as virtual network cards?only sharing a physical network adaptor is valid for a honeypot because your virtual sessions need to be addressable external to the host. By design, the Virtual PC network adaptor is designed to function as if it were plugged into a hub with a switched uplink. If you use two network cards as mentioned previously, you should select only the primary network card to share with your virtual sessions.
By default, a virtual session shares the host's CD-ROM and floppy drives. Thus, if you insert a CD-ROM or floppy disk into the host's drive, you'll see it in the virtual sessions. To ensure that the physical CD-ROM is never visible within a virtual session, I typically leave an ISO image loaded in the virtual CD-ROM drive.
Creating Your Honeypot
Creating a honeypot requires the following steps: installing the base OS for each virtual system, configuring each virtual system's profile, performing tests to validate the profile, and backing up your virtual sessions. You should perform all these steps on an isolated private network to eliminate any possibility of external contamination. In addition, I highly recommend taking careful and copious notes while setting up each virtual session. This practice will ensure that you have an accurate record of your honeypots and aid you in the later forensic analysis of compromised virtual systems.
A virtual system's profile is the specific configuration, including the setup of the OS and third-party software and the exposure of certain services. For example, to test vulnerabilities in a Web server farm, you might set up a profile that mirrors your servers by running a Microsoft IIS 5.0 Web server on Win2K Server, secures IIS with the IIS Lockdown tool, and uses a packet filter that blocks all ports except TCP 80 and 443. You can save this virtual session as a base profile, then create variations of this profile to add or remove known vulnerabilities to further refine your honeypot tests.
Installing the base OS is simple but time-consuming in Virtual PC. After you've configured a virtual session, you can insert a bootable CD-ROM or ISO image with the desired OS and perform a standard install. Unfortunately, installing OSs in Virtual PC is surprisingly slow. It took me about 20 minutes to install Windows 2003 as the host OS but more than 4 hours to install it in a virtual machine. I tried changing the default option for how Virtual PC shares the CPU between the host and virtual sessions, but no change seemed to result in any perceptible difference in the install time. The silver lining, though, is that once installed, guest OSs perform quite well.
Next, you will want to configure each virtual session with the desired profile. This step includes configuring the OS, installing desired components, configuring system security, applying desired service packs and patches, and installing any third-party software you plan to run. If you plan to expose publicly available services, such as a Web server, you should ensure that the services are configured to mask the fact that they're a honeypot. For example, a Web server whose content is inconsistent with the organization operating it or whose content is out of date might arouse the suspicion of potential attackers or discourage their interest.
When masking your systems, be aware of the meaning and implication of enticement, which is legal but raises some ethical questions, and entrapment, which is illegal. Running an anonymous honeypot Web server on your perimeter is enticing an internal attacker to come. But sending an email message to potential attackers of the Web server's existence and potential contents could be entrapment. Even though legal experts are unconvinced that a case charging entrapment with honeypots could be won, you should educate yourself about this topic. (For some places to start, see the Learning Path box.) Most experts recommend that internal honeypots should show a banner warning that users should be authorized and might be monitored.
As part of configuring each virtual session, ensure that it's set up to provide the necessary evidence. Although you can collect some evidence (e.g., network traffic) from outside a virtual session, some of the best forensic evidence will come from a compromised virtual session. I always turn on logging for all login/logout, process, account management, and policy events and increase the size of the event logs.
Next, you should test the external and internal profiles of each virtual system to ensure that they're working as intended. For example, if you want to expose a system running a Web server with a desktop firewall that allows only inbound TCP traffic to port 80, you should use your penetration-testing tools to validate that you?ve set up the profile correctly. The virtual aspect of a virtual session's external profile will be nearly undetectable. Unfortunately, the same can't be said of a virtual session's internal profile. Because Virtual PC emulates the hardware, virtual sessions are installed with generic drivers, so an attacker can identify the sessions as virtual fairly quickly. You'd have pretty much the same problem with VMware sessions, with one exception: In Virtual PC, the hard disk has the description Virtual HD, and you can't hide this description. The good news is that the rapid adoption of virtualization over the past two years is making virtual sessions less common and therefore less suspicious to a would-be attacker.
The last step in setting up your virtual sessions is to make a backup of each session. You should do so for three reasons: First, installing and configuring your sessions requires a significant effort, and a clean backup will ensure that you don't lose your hard work. Second, when a system is compromised, you'll be able to return to the system before it was compromised for comparison and analysis. And finally, you'll often want to make minor changes to the configuration of a specific virtual session to collect additional evidence, and the backup lets you quickly return to a base configuration to make specific changes.
Going Live
You're almost ready to take your honeypot live, but before you do, you should review the session configurations one last time, take an evidence snapshot of sessions, and start the evidence collectors on the host. I usually work from a checklist at this stage to ensure consistency and integrity in my final setup.
To review your configuration, start your virtual sessions and do a manual walk-through of each to ensure that it's properly set up. If you're running a honeynet, verify network configurations. For each session, validate the internal and external profiles of each device and do a spot check to ensure that you've properly set up each virtual session to collect and retain the evidence you'll need.
I always save a snapshot of the configuration from each virtual session before going live. The objective is to develop a baseline that I can use to identify changes after a system is compromised. Although there are some good utilities for taking snapshots of system configurations for UNIX, few such utilities exist for Windows. If you don't have tools for taking a configuration snapshot, I?d recommend you start with a manual process. In particular, take checksums of files and snapshots of processes (including currently loaded modules), services, device drivers, registry entries, open ports, event logs, and any other evidence specific to applications you run. You can find utilities to checksum files and take snapshots of OS settings at shareware Web sites, at Sysinternals, or on the Microsoft Windows Security Resource Kit CD-ROM. Over time, you can automate this process with custom scripts. I've written a command-line utility called Snapshot that not only archives a vast array of information about a running system but can also identify the differences between two snapshots (e.g., one before a system is compromised and one after)?more about Snapshot in a moment.
The last step before going live is to start evidence collection on the host. At a minimum, you should start a network monitor and IDS. I always clear the monitor packet trace and IDS logs before going live to make reviewing (and filing) evidence specific to a honeypot run easier. Now, it?s time to plug your host into your DMZ and take your honeypot live.
Identifying Attacks
Once the honeypot is live, your objective is to let it run long enough to collect the evidence of an attack but not long enough to risk it being used in other attacks. The length of time it takes a honeypot to be compromised depends upon its location, its perceived value, and the security level of its virtual sessions. For perimeter honeypots, I've found that automated probes (e.g., worms) often start within minutes of the system going live and intelligent probes begin within a few days.
While the honeypot is live, I keep a close eye on both the virtual sessions and the host. I typically work from a checklist, walking through it every day or two to ensure integrity and consistency. I start by working through the list of IDS alerts on the host to identify those that represent possible attacks. An IDS will do a fair job of providing early warning, but you shouldn't rely on it as the sole mechanism for identifying an attack because IDSs are known for their high volume of false positives. But in general, an IDS will catch most common exploits and provide a good starting point for investigating specific attacks.
Next, I review packet traces taken from the network monitor running on the host for potential attacks. I typically start by filtering the packets to show only the outbound traffic from specific virtual sessions. I then use these packets as a springboard for reviewing each suspicious session that resulted in outbound traffic.
My next step is to move from the host to the honeypot itself. In switching to the virtual machine, you must be careful not to contaminate evidence. I typically review the event logs (in particular the security logs), active ports, and logs of other applications that the honeypot is running. I try to minimize my time on the honeypot itself but find that the brief review gives me one last safety net in identifying an exploited system.
Collecting Evidence
If your honeypot has been compromised, it's time to start the forensic analysis of the system. Don't shut down the host system right away. You need to ensure that your collection procedures don't compromise evidence or put any other system at risk. If you plan to use evidence collected from your honeypot in court, you should be well-versed in the legal issues related to your response and collection procedures. (Unfortunately, a discussion of these legal issues is beyond the scope of this article.)
The forensic process on a honeypot has three basic steps: collect volatile evidence, back up the system, and analyze and collect the remaining, nonvolatile, evidence. Throughout these steps, document all your actions and their results. These documents will let you quickly return to specific runs of your honeypot in the future and will help you improve your operating and collection procedures over time.
Volatile evidence?evidence that you collect while the honeypot is still running because it will likely be altered if the system is turned off?can include everything from a memory dump to network connections to remote hosts. You must weigh the need to collect volatile evidence against the reality that any collection of evidence might damage evidence. Unlike traditional honeypots on physical systems, virtual honeypots give you the option of turning off the session, saving its state, and returning to it in the future. As a result, I rarely collect evidence from a virtual session immediately after a system has been compromised because almost all the evidence I require can be recovered from a backed up session (although on occasion, I've attached a debugger to a running process to understand more about its execution).
The next step is to back up the virtual system to preserve evidence. To do so, close the virtual session by selecting Close in the Action menu, then choosing Save State. Saving state shuts down the session and updates two files: one that contains the current contents of the hard disk and another that contains the current state of the system (including the memory contents of the virtual session). The size of the state file varies based on the amount of memory in use by the virtual system but in general ranges from 50MB to 80MB. After the session is shut down, make a copy of the files for the session, ideally on read-only media. You'll also want to stop and archive evidence from all evidence collectors running on the host (e.g., the IDS, the network monitor).
Now begins the real challenge: finding evidence of how the system was exploited and, if you're lucky, who exploited it. To do this, you need to start the session again. Because the honeypot is on a virtual system, starting the session will return you to the exact running state of the system before you shut it down. At this point, you must carefully scrutinize every detail of the system for evidence. This process can be very time-consuming and labor-intensive, so over time, you'll almost certainly need to automate it with scripts and utilities. My Snapshot utility comes in particularly handy here. I take a snapshot of the compromised system, move it from the virtual session to the host, and compare it to the snapshot taken before the system was brought online for the first time. The utility identifies precise changes in files, registry entries, and even modules loaded by a specific process. Using Snapshot, I sleuth my way through the crime scene, collecting evidence along the way, until I've collected a comprehensive picture of the attack.
The options for getting evidence from a compromised virtual session are the same as from a regular system, with one addition?you can install Virtual PC Additions in a virtual session to provide tighter integration between the virtual sessions and host. The software's features include folder sharing, clipboard sharing, time synchronization, and drag and drop support between the host and guest. The downside of Virtual PC Additions is that its presence reveals that a system is virtual, but this disadvantage is less of a concern if you install the software after a system has been compromised.
Beyond the Technical
If you plan to set up and operate a honeypot, make sure you're well versed in the legal, ethical, and technical issues associated with this topic. Because honeypots are a hot topic in the security community, you can find quite a bit of information about them. But before committing to operating a honeypot, you should have a clear and well-defined purpose and be willing to invest the required time to understand all the aspects of working with honeypots.
Virtual PC, although clearly not designed for use as a honeypot, offers a flexible set of features at a good price. I'd highly recommend it for operating your first honeypot.
| Project Snapshot: How to |
|
PROBLEM: Setting up a honeypot running Virtual PC 2004 to test the security of your perimeter devices (e.g., Web servers, mail servers), gather early warnings of potential attacks, or learn about techniques used by attackers. WHAT YOU NEED: Computer with at least a 1 GHz Pentium 3 Processor (P3), 512MB of memory, a 50GB hard disk, a CD-ROM drive, and 2 NICs; a valid license or trial version of Virtual PC; valid licenses for the host and guest OSs, and assorted security tools (firewall, IDS, network monitor, and other utilities such as a hex editor and a port monitor). DIFFICULTY: 4 out of 5 PROJECT STEPS:
|
