Another issue that honeypot technologies face is fingerprinting. Fingerprinting is when an attacker identifies a honeypot for its true purpose: a system designed to be attacked. For most organizations, mitigating signature detection is important. Once identified, a honeypot may lose its value. For example, if an attacker discovers a honeypot that is used to detect attacks, the attacker now knows to avoid any more activity with that system. Even worse, he may communicate that finding to other blackhats, who also now know to avoid detection by avoiding the honeypots. Signature detection is even more devastating for research honeypots. Attackers may avoid it or, worse, knowingly attack it with the intent to feed it bad information, compromising its central purpose and value. In some situations, honeypot detection may be desirable, especially for deception or deterrence. With deception, the intent is to confuse the attacker. If a blackhat attacks a system and discovers that the system is a honeypot, this may confuse or deter him. The attacker may then be concerned that other systems within the organization are honeypots. When he discovers what he believes is a vulnerable service, he may be concerned that in reality such a vulnerable service is in actuality a honeypot. Some honeypot solutions will identify themselves when they detect an attack as a method of deterrence. For example, Specter can be configured to identify itself as a honeypot to an attacker and to notify a detected attacker that an alert has been sent to security authorities.
Fingerprinting may be a good thing or a bad thing, depending on the value or intent of your honeypot. For most honeypot deployments, detection decreases the honeypot's value. These are the three most effective measures for reducing detection.
• Modifying honeypot behavior • Blending with the environment • Developing realism
Modifying honeypot behavior applies mainly to commercial or prepackaged honeypot solutions. Any honeypot solution you can download and install has the potential for signatures. If you download or purchase a honeypot solution and use it for your organization, there is no reason a blackhat cannot access and learn the same technology. Such solutions may have standard configurations or specific behaviors that can be identified. Once these signatures are recognized, honeypots can be detected. For example, a default installation of a honeypot may come with ten emulated services. An attacker can identify these ten services, the version of each emulated service, and then use that known fingerprint to identify the honeypot solution. The key to avoiding this type of detection is modifying the functionality and identity of the honeypot solution you are facing. After installing a honeypot, modify the default setting. Disable some services that you most likely do not need, and modify services that you do. You might want to start up customized services, such as adding your own port listeners, discussed in Chapter 9. The goal is to create unique characteristics that make the honeypots more difficult to identify. Homemade honeypots do not have this problem, since each is unique.
The second method to avoiding detection is blending the honeypot to your organization. If your organization is running a specific operating system type, you most likely want your honeypot to have the same OS, be it real or emulated. For example, if your organization exclusively uses Windows-based operating systems, then you do not want a honeypot that appears to be a FreeBSD system. If your systems or applications use specific banners, modify your honeypots to have the same banners. Customize the honeypots to appear as a natural extension of your organization.
Last, realism is critical. Honeypots can easily be detected if they do not behave like real systems. This is especially true of emulated honeypots. For example, a honeypot may emulate a Solaris operating system, but the true operating system of the honeypot is Windows based. When an attacker connects to an emulated service, the honeypot acts like a Solaris server. However, if the attacker uses advanced operating system detection
techniques, such as analyzing the IP stack of the honeypot, the attacker may identify the system as a Windows- based OS. These discrepancies in operating system types can be used to identify the honeypot. These issues are especially true of honeypots that emulate services. Honeypots that are based on real operating systems, such as Honeynets or the commercial honeypot ManTrap, reduce these problems by running real operating systems.
Summary
This chapter has provided a guideline for implementing your honeypot optimally for your environment. To summarize, you must take the following steps.
1. Identify your goals and the value you expect the honeypot to deliver. Be as specific as possible. Your goals will directly affect most of the subsequent decisions you have to make regarding your honeypots. Determining if you want a production or research solution will help you define those goals.
2. Select an appropriate honeypot solution, or create your own, based on the goals and values you identified. Keep in mind the criteria, the level of interaction—commercial or homemade—and the platform you prefer.
3. Determine the number of honeypots you need. You may be constrained by budget issues. Also, the more you deploy, the more you have to maintain. Organizations tend to deploy multiple production honeypots while only deploying one or two research honeypots.
4. Determine where on your network to deploy your honeypots. Optimal placement depends on your goals. In general, production systems go behind perimeter defenses. Traditionally, research honeypots go in front of perimeter defenses, but more and more are also being deployed internally.
5. Determine what kind of data and how much of it you want your honeypots to capture. Select your honeypot to collect as much information as possible on each probe or attack it receives. Also, consider whether supplementary tools such as a sniffer or NAT will be helpful in this task.
6. Design and implement an appropriate logging and maintenance system for the information your honeypots collect. For large organizations with multiple honeypots, this may require a separate honeypot management network.
7. Identify risks your honeypot may introduce to your organizations, and take steps to mitigate them. Using the lowest level of interaction, deploying secured platforms, and reducing fingerprinting are among the ways you can manage risk.
Keep in mind that implementing your honeypot is only half the battle. Once your honeypot has been deployed, you have to maintain it. This is the topic of the next chapter.
References
[1] Snort, OpenSource IDS Solution http:///www.snort.org
[2] ACID (Analysis Console for Intrusion Databases). OpenSource solution for managing logs. http://www.cert.org/kb/acid/
[3] Demarc. Solution for centralized logging and management http://www.demarc.org [4] Commercial solution for centralized logging http://www.netforensics.com
Chapter 13. Maintaining Your Honeypot
Okay, you have just deployed your shiny new honeypot! Now what? Honeypots are not a fire and forget solution. They require constant care and feeding. Implementation is only half the battle. To achieve the full potential of honeypot technologies, there are a variety of issues to maintaining the system. Alerting mechanisms have to be customized and monitored to ensure that the right people are getting the correct information. Organizations need to clearly define a process for reacting to honeypot attacks and compromises. What exactly do you do when a honeypot has been attacked? Data has to be captured, analyzed, and archived. Honeypots have to be updated to patch any existing vulnerabilities and to react to new threats.
This chapter covers four areas of maintaining honeypots.
• Alert detection— some of the best ways to configure and receive alerts. Without proper alert mechanisms, a honeypot has very little, if any, value.
• Response policies— what types of honeypot activity you will react to and how. Without defined policies, critical information can be lost or destroyed.
• Data analysis— a process for turning collected data into valuable information. • Updates— how to ensure that your honeypot stays current to new threats and attacks.
Alert Detection
Regardless of your honeypot's purpose, alerting is a key component to its value. Alerts generated by prevention honeypots notify organizations to be on the lookout for other attacks. The attacker may have been confused or deterred, but that does not mean he won't be coming back. For detection honeypots, alerting is the primary mission, to identify suspicious activity and notify the proper individuals. For incident response, organizations will want to react to an attack as fast as possible. The sooner they can access the compromised honeypots, the greater the value of the collected evidence. Alerting for research honeypots is especially critical. The purpose of research honeypots is to gather information, which is often sensitive. Regardless of the purpose of your honeypot, effective alerting is critical for its value.