Depending on what you want to manage and capture, a honeypot can participate or mimic any layer of the OSI model. If the honeypot is a real operating system, it easily fulfills the physical and data-link level requirements. Depending on the goals of the honeypot, it can respond to requests at other layers. Honeypots can mimic the following:
Operating systems (OSs)
Network routing topologies
Application data content
When designing a honeypot solution, it’s important, to consider which items and layers you want to emulate, capture, and analyze. Each layer has its own subtleties and complexities. Different hackers hack at different layers. Some hackers work only with buffer overflows and data malformations at the application layer. Others spend their energies on the network layer, malforming IP packets and putting together invalid combinations of TCP packet flags (covered in Chapter 9). Rarely do hackers attack at more than one layer of the OSI model—most specialize. Unfortunately, you’ll never know ahead of time what type of hacker is attacking, and there is so much hacking going on that every layer of your network will be probed for weaknesses. The more layers you are able to mimic, the juicier the honeypot.
Although you might initially think that all hackers want to get to valuable data, some are satisfied by simply causing operational problems. Hence, an attack directed at the lowest levels of the OSI model (MAC, protocol stack, or network protocol) can cause a DoS attack. Denying a vendor the ability to service legitimate customers, and hence incurring revenue losses, will make most malicious hackers just as happy as stealing an internal document.
The lower layers tend to be static and predefined. The way Windows Server 2003 will respond to an IP stack probe will be the same, regardless of its purpose or placement. For example, if an attacker sends a ping (ICMP echo) to a Windows Server 2003 computer, its ping response will be the same, whether it is functioning as a file server or a web server. The lower layers of a honeypot, although they can be technically difficult to understand, are usually well covered by honeypots and relatively easy to maintain.
Upper layers, such as applications and services, can be a little tougher to mimic. For example, if your honeypot emulates an FTP server, how well does it emulate a real FTP server? If the FTP server is only an emulated script, how will it respond to a hacker’s invalid password attempts? Is the text that it displays to hackers when they do something right and wrong accurate? Sometimes you can resolve a lot of these issues by offering a fully functional FTP service. Of course, this means the hacker might be able to manipulate it in some way that you were not expecting and compromise the honeypot or attack other systems. And with a real FTP server, if you’re going to allow the hacker to “break in,” you’ll need to provide some sort of content to make the site look realistic.
Another good example is a honeypot mimicking a production mail server. Your honeypot can simply emulate port 25 as an open SMTP port for the hacker to probe. It might be configured to respond with the typical SMTP responses, or even accept incoming e-mail. The latter method is used with some antispam honeypots. Some honeypot administrators have gone so far as to build fully functional mail servers including fake messages. You can create different e-mail threat topics to see what the hackers are interested in. The type of hackers you are facing when the hackers choose the Top Security Clearance: Weapons Guidance Communication Systems topic is probably different from the threat when they choose the New Doom II Servers topic.
A honeypot can be described as low-interaction, high-interaction, or in between. High-interaction honeypots offer all layers of the OSI model and can be configured with real applications. The highest interaction honeypots will have emulated content with recent modification dates to fool the hacker into thinking they have compromised the real McCoy.
Low-interaction honeypots offer the network protocol stack and might allow limited interaction with ports and services. For example, the hacker or worm tries to connect to a port at the network level and is denied. As long as the honeypot captured the connecting information, it is potentially valuable. It will show what the connection attempt tried to do and reveal the source IP address and port number. Internet worms, like Slammer, and port scans can often be identified by low-interaction honeypots. Low-interaction honeypots are the easiest to create, monitor, and redeploy after a compromise.
You can create an extremely simple low-interaction honeypot by using any of the dozens of port listeners available on the Internet. A port listener opens a TCP or UDP port on a Windows computer, and then alerts the user if any attempts to connect are made. Most port listeners will list the originating IP address and may capture the probe’s data. They became popular in the Windows world as a way to monitor the activity of Internet worms and Trojan horse programs (trojans), like Back Orifice, SubSeven, and Netbus.
You can create a simple port listener using the Netcat utility. Netcat (http://www.atstake.com/research/tools/network_utilities) is known as the Swiss Army knife of the hacker world. It is used by good and bad hackers alike, and with a bit of wit and a series of command-line parameters, you can do almost anything with it. One of its most common uses is as a port listener. It can log port probes to the screen or to a text file. For example, the following Netcat command will log all probes to port 21 and save them in a text file:
nc -vv -l -p 21 > port21.log
The -vv tells Netcat to be verbose and report connection attempts to the screen, and -l tells Netcat to listen for inbound connections on the port indicated by -p. The collected data is saved to a text file called port21.log.
If you are attempting this example, press Ctrl-C to end the Netcat session, or type nc -h for the Netcat help screen.
In a test, I connected to the Netcat-initiated port via FTP from a remote computer. Here are the contents of the port21.log file:
The blank lines between anonymous and password reflect that I hit the Enter key twice after connecting, when I was acting the part of the befuddled hacker. When I FTP’d to port 21, my FTP client connected, but it did not display any text. This was expected because I didn’t tell Netcat to respond with any text when connected, although I could have told it to respond with a fake login banner. When an open port is found, if it doesn’t automatically reveal itself, it’s normal for hackers to try all sorts of keyboard commands in an attempt to get the port to react and reveal its source service. Next, I typed a common FTP login name and password just to see if I could get a reaction. I didn’t, of course, but Netcat captured what I typed and stored it to a local file. Netcat displayed the source IP address and port number of the probe attempt on the screen (because of the -vv parameters). Although I don’t think anyone would want to because of better alternatives, you could instruct Netcat to run a port listener on multiple ports and set up a makeshift honeypot. It would be better to use a real honeypot tool, but Netcat’s crude port-listening techniques are the same as those used by many low-emulation honeypots monitoring various ports.
Many honeypots offer varying levels of interaction according to the popularity of the service or port. They often come with high-interaction services, such as FTP, HTTP, and Telnet, but have only low-interaction processes for the less common ports. For instance, a honeypot may have a fully functional web server on port 80, but offer only low-interaction services for the other ports.
For many honeypots, you can define or create the interaction level by port. They come with a few default emulation scripts, which you can modify or use to build new services. For a Windows machine, it makes sense to have some sort of NetBIOS emulation service if you are worried about network share worms, like Klez and Bugbear. It all depends on what the honeypot emulation software specializes in and the objectives of the honeypot administrator.
The higher the interaction, the sweeter the honeypot, and the longer the hacker is likely to stay around. Real OS honeypots offer high-interaction opportunities.
For most honeypot administrators, their first honeypot is simply a spare computer running areal OS. The administrators install the OS as they normally would, but then leave it in an unpatched state with popular hacker holes left open. For instance, installing Windows NT Server 4.0, but leaving it at Service Pack 2 and with IIS 4.0, sets up a popularly hacked host computer. A Windows 98 machine with an unprotected shared NetBIOS folder is considered a juicy exploitation target by hackers. Which OS environment you use and where you use it are determined by your goals. Some honeypot administrators deploy fully patched systems that mimic their production environments. They are interested only in exploits that would be successful against their production machines.
The nicest thing about a real OS honeypot is that it doesn’t emulate the IP stack, OS, or applications; it’s real. How it responds to attacks will appear normal to the attacker. If you can keep the attackers from discovering the honeypot’s monitoring and control mechanisms, it will be very difficult for them to discover that it is a honeypot. Of course, giving the hackers a real system to play with also means you must take great measures to prevent them from using it to harm others.
Using real, physical computers as a honeypot can be a lot of work. First, if you want to deploy more than one honeypot, you’ll need multiple computers. Each honeypot will need a licensed copy of the OS and applications. Each machine will need its own physical space and power supply, as well as a monitor, keyboard, and mouse (or KVM device switch). Each honeypot will need to be tracked and maintained on its own. Each time any type of honeypot is compromised, it needs to be reinitialized and redeployed after the hacking session is closed for analysis. Redeploying is most time-consuming with real OS honeypots. It can mean reformatting the machine, reinstalling the OS and applications, and configuring everything back to a desired state. Although this can be done manually each time, it’s more efficient to use a backedup image file to restore the honeypot. Some administrators use Symantec’s Norton Ghost to copy from a cloned drive, use a tape restore, or employ some other image-restoration process.
Virtual honeypots began as a quick way to deploy several honeypots at once and have now evolved into complete, autonomous, digital ecosystems.
Virtual honeypot software can emulate the IP stack, OS, and applications of real systems. Once you’ve created your virtual honeypot system, it is usually easy to re-create after it has been compromised. Often, the emulation is done completely in memory. Simply restarting the honeypot virtual session reinitializes all values—presto, chango, done! No hunting down ghosted hard drives or installing multigigabyte images over the network. Virtual honeypot software allows complete honeynets to be deployed all at once, on one physical computer. One virtual honeypot system can be used to emulate thousands of systems using thousands of ports, each with a different IP address.
There are two different types of virtual honeypot systems: virtual machine (VM) and emulation.
VM honeypots use VM software to run real OS images on one computer. VMware (http://www.vmware.com) is the market leader for VM software, but Microsoft’s Virtual PC (http://www.microsoft.com/virtualpc) is quickly gaining market share. VM desktop software can run multiple, simultaneous sessions of Microsoft Windows, Linux, Novell NetWare, and other operating systems. Figure 1-3 shows an example of running VMware.
Figure 1-3: VMware running Windows NT Server 4.0 and Windows 98 on a Windows 2000 Professional computer
The number one benefit of a VM solution is that each virtual session runs real software. It’s a full version of the OS, IP stack, and applications. There are some minor differences, and some hacking tools (and viruses and worms) may not function normally in a virtual environment. Still, unless hackers are checking specifically for a VM product, they probably won’t notice.
On the downside, updating the virtual environments can be a chore if you have more than a few. At home, I run 17 different Windows honeypot systems using VMware (Windows 95, Windows 98, Windows 98 Second Edition, Windows NT Workstation 4.0, Windows NT Server 4.0, Windows 2000 Professional, Windows 2000 Server, Windows Me, Windows XP Home, Windows XP Professional, Windows Server 2003, Exchange Server 5.5, Exchange Server 2000, Exchange Server 2003, Windows Server 2003 with Terminal Server installed, IIS 5.0, and IIS 6.0). I keep all the systems up-to-date because I use the virtual systems not only to run honeypots, but also to test new security software. Every time a new Microsoft patch comes out, I need to update the relevant systems. If a Microsoft patch affects all Microsoft OSs (as the July 2003 RPC patch did), then I’m installing it 17 times, and then reburning the images for safekeeping. One patch can turn into a full day’s work for me.
Recently, I began using Microsoft’s Software Update Services (SUS) to keep my virtual systems updated. Unfortunately, SUS does not update Windows 9x or NT systems, nor does it update application software like Exchange Server. Microsoft’s upcoming SUS update, Windows Update Services (WUS), will be able to update more software components.
VM honeypots have a few other drawbacks, mostly dealing with performance. Because VM software runs a real copy of the software in a virtual OS environment, each VM session needs as much CPU, memory, and hard drive space as the stand-alone OS needs. Most of today’s Windows systems want 128MB to 256MB of RAM and 1GB to 2GB of disk space, without considering any application requirements. Running multiple VM sessions at the same time can significantly tax any system. Once the VM sessions are started, they are always slower than if they were not running in a VM environment. The biggest hit in performance seems to be in loading multiple VM sessions at once, but it improves once the sessions are all booted and running. For example, if I load five VM sessions all at once, it could take ten minutes for all five sessions to load. But once the sessions are running, I can switch between the sessions, and although I certainly notice the decrease in performance, it is tolerable. Still, I wouldn’t want to run a resource-intensive application like SQL Server or a computer-aided drafting (CAD) program while running multiple VM sessions.
Also, it is very possible to run out of memory and hard drive space after a virtual session is running. When this happens, it can be impossible to save the current image, causing all the changes to the compromised honeypot to be lost. It can be frustrating (and I have been known to scare the family dog with my yelling after such an event).
You will need a license for each honeypot that runs a Windows OS. If you use VMware or some other virtual hosting environment, you will need a license for every emulated Windows system. Some people are under the mistaken impression that virtual systems mean virtual licenses.
The second type of virtual honeypot is honeypot emulation software. Honeypot emulation software mimics the basics of the underlying OS and applications. Typically, they install as applications on top of an OS. You start the OS as you normally would, and then start the emulated honeypot, just as you would start any other application.
Honeypot emulation software is fairly easy to deploy and as easy as VM solutions in redeploying clean images. Simply restart the emulated environment, and the honeypot is back to its unaltered state.
Emulated honeypots can emulate entire systems—IP stack, OS, services, and simple applications—depending on how they are deployed and configured. If the emulated honeypot uses the host’s underlying IP stack, it means the host OS will respond to TCP, UDP, and ICMP requests instead of the honeypot software. This becomes important if a hacker is trying to identify the system (more on this in the “Manual Attacks” section later in this chapter). If your emulated honeypot mimics a Cisco router, but it runs on a Windows 2003 Server system, it could alert the hacker that a honeypot exists if it does not also emulate the IP stack of a Cisco device, too. Other emulated honeypots install device-level drivers, essentially intercepting hacker packets before they are sent to the host IP stack, or they can install their own IP stacks. These types of emulated honeypots offer a more seamless outward appearance, but they must have the intelligence to correctly emulate the fake IP stack.
To further clarify, if an emulated honeypot functions only at the application layer, it can install only services and answer requests only to ports not already running on the host computer. For example, if the host machine has NetBIOS enabled, as most Windows machines do, the application-level honeypot cannot answer NetBIOS requests. If the honeypot tries to open NetBIOS services on the PC, the emulated services will fail to load. If an emulated honeypot installs at the IP stack layer, it can answer NetBIOS requests, but then has the onus of either emulating NetBIOS services (not an easy task) or passing along legitimate tasks to the host computer. While some see application-layer honeypots as a weaker choice because they don’t emulate the host OS IP stack, if the emulated honeypot and the host OS match, there is less chance that the honeypot will be found out.
Honeyd (http://www.honeyd.org) is the most popular emulated honeypot solution. It was created as an open-source product by Niels Provos, a Ph.D. and experimental computer scientist at the University of Michigan. Honeyd is capable of emulating hundreds of OSs and IP stacks, and it can be configured with basic services, such as SMTP mail servers, FTP servers, and Telnet servers. Depending on how it’s configured, Honeyd can be used as a low- or medium-interaction honeypot. The Unix version even has the ability to interface with real external systems, like IIS and Exchange Server. The interfaced systems are considered subsystems and run in a virtual IP address space. This means subsystems will appear to the hacker as if they were running from the same host and IP address space. Using Honeyd will be a large part of this book, beginning with its installation and configuration, covered in Chapters 5 through 7.
While real OSs and VMs excel at being a honeypot, there are several benefits to deploying an emulated honeypot system:
Emulated honeypots are harder for hackers to compromise, in an unauthorized way.
They have less risk. Because emulated honeypots are not full-blown systems, they are much harder for the attacker to use in attacking other systems.
They usually cost less than other types of honeypots.
They are easier to manage than other types of honeypots.
The provide everything on one system.
It is easy to create a virtual honeynet, running dozens of emulated sessions, each with its own IP address, virtual mail server, and domain naming server.
They can respond for more than one IP address simultaneously.
Logging and monitoring for all sessions can be done from the emulation host machine.
Compromised sessions can be redeployed in an original state in seconds.
However, emulated honeypots also have disadvantages. You are limited to the types of OSs you can emulate by the honeypot emulation software, and all virtual honeypots are fairly easy to identify because of the following characteristics:
They have limited functionality.
They have “memory” fingerprints.
They have predictable registry key entries.
They often have predefined MAC ranges (VMware uses 00-50-56-xx-xx-xx).
They can have identifiable emulated BIOSs.
Their I/O ports behave in predictable ways.
They can have readily identifiable software (for example, VMware adds software called VMTools under Add/Remove Programs).
A savvy hacker could spend his initial time after a successful system exploit testing for virtual honeypot software. There are even scripts that test for the existence of honeypots. If the hacker finds out that he has invaded a honeypot, he usually gets out of there quickly. Lucky for us, most hackers aren’t aware of honeypots and think every system they break into is a real production system.
You need to decide on your goals, objectives, and time commitment before deciding on a honeypot. Table 1-1 summarizes the advantages and disadvantages of the different honeypot types.
Mimics only IP stack
Can mimic all layers of OSI model
Has all layers of OSI model
Has all layers of OSI model
Mimics OSI model layers depending on interaction level
Easier to set up
Harder to set up
Medium to hard to set up
Harder to set up
Can be easy or hard to set up
Lowest time commitment
High time commitment
High time commitment
High time commitment
Low to high time commitment
Redeployment after compromise is easy
Redeployment after compromise can be harder
Redeployment after compromise can be hard
Redeployment after compromise is very easy
Redeployment after compromise is easiest