You are on page 1of 9

Section I Honeypot Essentials Dr Anton Chuvakin WRITTEN: 2003 DISCLAIMER: Security is a rapidly changing field of human endeavor.

Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around. While known to security processionals for a long time, honeypots recently became a hot topic in information security. However, the amount of technical information available on their setup, configuration, and maintenance is still sparse as are qualified people able to run them. Higher-level guidelines, such as a need and business case determination, are similarly absent. In addition, honeypot risks, such as legal risks, are not sufficiently explored and highlighted. In this section, we will start from covering some of the honeypot (and honeynet) basics and definitions and then will outline important implementation issues. What is a honeypot? Lance Spitzner, a founder of Honeynet Project (http://www.honeynet.org) defines a honeypot as "a security resource who's value lies in being probed, attacked or compromised". Thus, a goal of such a masochistic system is to be compromised and abused. Hopefully, each time a honeypot goes up in smoke, the researcher learns a new technique. For example, you can use a honeypot to find new rootkits, exploits, or backdoors before they become mainstream. The Project further differentiates between research and production honeypots. The former are focused on gaining intelligence information about attackers and their technologies and methods, while the latter are aimed at decreasing the risk to a company IT resources and providing advance warning about the incoming attacks on the network infrastructure. Honeypots of any kind are hard to classify using the "prevention - detection - response" metaphor, but it is hoped that after reading this chapter their value will become clearer to readers. The term "honeynet" is originated in the Honeynet Project and means a network of systems with fairly standard configurations connected to the Internet. The only difference of such network from a regular production network is that all communication is recorded and analyzed, and no attacks targeted at third parties can escape the network. Sometimes, the system software is slightly modified to

help monitor encrypted communication, which often used by attackers. The systems are never "weakened" for easier hacking, but are often deployed in default configurations with minimum of security patches. They might or might not have security holes, known to the honeynet operator. Honeynet Project defines such honeypots as "high-interaction" honeypots, meaning that attackers interact with a deception system exactly as they would with a real victim machine. On the other hand, various honeypot and deception daemons are "low-interaction", since they only provide an illusion to an attacker, and the one that can hold their attention for a short time only by presented a limited simulation of a real system (such as a shell with a few commands). Such honeypots has value as an early attack indicator and for collecting statistical data, but do not yield in-depth information about the attackers. In this case, one might be able to collect data from attacks by automated worms and the initial steps of an attack launched by a human intruder. However, the illusion is limited, and none of the desired highvalue, after-penetration data can be acquired. Honeypot are also separated into client and server honeypots; honeynets and various deception daemons (such as honeyd) are server honeypots since they way for a attacker to discover and exploit them. Client honeypots or honeyclients are of the opposite type: they masquerade not as a legitimate server, but as a legitimate client system, such as a web suffer. Honeyclient might be compromised when trying to connect to a malicious or compromised server. Honeyclient are perfect for collecting web-deployed malware and web exploits. Research honeypots are usually set up with no extra effort to lure attackers blackhats locate and exploit systems on their own. It happens due to the widespread use of automatic hacking tools, such as fast multiple vulnerability scanners and automatic penetration scripts. For example, an attacker observed in a honeynet once attempted to scan 200,000 systems for a single FTP vulnerability in one night using such tools. Research honeypots are also unlikely to be used for prosecuting intruders, however researchers are known to track hacker activities using various covert techniques for a long time after the intruder broke into their honeypot. In addition, prosecution based on honeypot evidence has never been tested in the court of law. It is still wise to involve a company legal team before setting up such hacker study project. We will explore some of the risks as well as legal and ethical issues in the later sections. Overall, the honeynet is the best tool for detecting and analyzing the malicious hacker activity. The reason for that is simple: all communication to and from the honeynet is malicious by definition. No data filtering, no false positives and no false negatives (the latter might only happen if the data analysis is adequate) are obscuring the picture. Watching the honeypot provides insight on intruders' personalities and can be used to profile attackers. Similarly, honeyclients present a unique way of collecting web malware on a massive scale without manually discovering and visiting the malicious sites. Even Microsoft is using

honeyclient in its HoneyMonkey project (http://research.microsoft.com/HoneyMonkey/) What are some of the common sense prerequisites for running a honeynet? First, honeypot is a sophisticated security project, and it makes sense to take care of security basics first. If your firewall crashes or your intrusion detection system misses attacks, you are clearly not yet ready for a honeypot deployment. Running a honeypot also requires advanced knowledge in computer security, network, platform and application-level. Some of the technical requirements follow. Obviously, the compromised honeypot systems, whether client or server, should not be allowed to attack other systems or, at least, such ability should be minimized and controlled. This requirement often conflicts with a desire to create a more realistic environment for malicious hackers to "feel at home" so that they manifest a full spectrum of their behavior. Related to the above is a need for a proper separation of research honey network from a company production machines. In addition to protecting innocent third parties, similar measures should be utilized to prevent attacks against your own systems from your honeypot. Honeypot systems should also have reliable out-of-band management. The main reason for having this capability is to be able to quickly cut off the network access to and from the honeypot in case of emergency (and they do happen!) even if the main network connection is saturated by an attack. That sounds contradictory with the above statement about preventing outgoing attacks, but Murphy Law might play a trick or two and human errors can never be totally excluded. Honeynet Research has guidelines on Data Control and Data Capture for the deployed honeynet. They distill the above ideas and guidelines into a well-written document "Honeynet Definitions, Requirements, and Standards" (http://www.honeynet.org/alliance/requirements.html). The document establishes some "rules of the game", which has a direct influence on honeynet firewall rule sets and IDS policies. Data Control is a capability required to control the network traffic flow in and out of the honeynet in order to contain the blackhat actions within the defined policy. For example, rules such as 'no outgoing connections', 'limited number of outgoing connection per time unit', only specific protocols and/or locations for outgoing connections, 'limited bandwidth of outgoing connections', 'attack string filtering in outgoing connections' or their combination can be used on a honeynet. Data Control functionality should be multilayered, allow for manual and automatic intervention (such as remote disabling of the honeypot) and should make every effort to protect innocent third parties from becoming victims of attacks launched from the honeynet (and launched they will be!). Data Capture defines the information that should be captured on the honeypot system for future analysis, data retention policies and standardized data formats

which facilitate information sharing between the honeynets and cross-honeynet data processing. Cross-honeypot correlation is an extremely promising area of future research, since it allows for a creation of an early warning system about new exploits and attacks. Data Capture also covers the proper separation of honeypots from production networks to protect the attack data from being contaminated by the regular network traffic. Another important aspect of Data Capture is timely documentation of attacks and other incidents occurring in the honeypot. It is crucial for research to have a well-written log of malicious activities and configuration changes performed on the honeypot system. The trend towards deploying honeypots for network protection is just beginning. Live traffic redirection (a.k.a. bait-and-switch), shield honeypots, and other techniques are in their infancy. The most common motivation for deploying a honeypot or a honeynet is still research. Learning about attackers (even if they are just script kiddies, as in most cases of Internet-exposed honeypots) and their tools and techniques is not for everyone. However, it is extremely useful for increasing security awareness, training, and tuning security tools. The research motivation applies to honeypots exposed to public networks. On the inside, honeypots provides great value by becoming an IDS with no false positives and protects select valuable resources on the network and hosts. Creating bogus database records, files, and other attractive information and monitoring access to them is a good way to thwart some of the most expensive kinds of network abuse and intellectual property theft. While research is the most important application of honeypots, the protection aspect (for both inside and outside) is increasing in importance. Section II Honeypot Risk; Legal and Ethical Issues Running a honeypot incurs some risks as well. First, what happens if the honeypot is used to attack other parties? This question has no clear answer since there is no clear answer even to 'what happens if your production - rather than deception! - systems are used for such an attack?' It is recommended to consult your legal department for advice before embarking on the honeynet journey. The mere fact that noone has yet being sued for liability, does not mean that there is no risk of that. Other risks are related to missing some configuration safeguard and letting attackers break out. This may be partially mitigated by running a honeypot on a separate network connection, far from the live system. Another risk is running it without sufficient expertise and attention paid to the systems. It is expected that security vendors and consultancies or universities with advanced computer security programs will possess such expertise. Research honeypots will not directly impact the safety of your organization, thus

the decision to deploy it should come after all the regular security troubles are effectively disposed of. Despite the risks, running the honeypot is an exciting and educational experience, which also contributes to a state of the art in information security. What are some of the legal issues typically associated with running a honeypot? Liability risk, mentioned above, is the most common issue. Can you get sued if an attacker uses your honeynet to attack other, possible sensitive, systems? Given that there is very little case law, despite a large number of computer attacks, it is still too early to decide how high is this risk. However, the more freedom is given to the attacker for the sake of creating a realistic productionlike environment, the more risk of such liability is present. Honeyclients and lowinteraction honeypots thus have less risk. However, some say that honeyclients also carry an additional possible risk of accessing the attackers system without authorization. Still, even in the most restrictive and highly controlled environment, software bugs are not impossible and might increase the risk of an attacker breaking out of the honeynet and then doing damage to other parties (who might then sue you). Overall, the lack of case law related to such liability, whether for honeynets or for regular production systems, does not allow anyone to provide decisive guidance on this issue. Another bizarre issue that is sometimes brought up is whether the honeypot infringe upon the rights (such as the privacy right) of the hackers? While this sounds truly preposterous, the cases where burglars sued the victims who wounded them while defending their property are no less ridiculous and they actually happened! Richard Salgado, former senior counsel for the Department of Justice's computer crime unit, investigated some of the legal issues related to honeynet operation. He did confirm that "There are some legal issues here, and they are not necessarily trivial, and they're not necessarily easy." For example, in one of his media interview (see http://www.securityfocus.com/news/4004), Mr Salgato mentioned a case where an accused kidnapper who was using a cloned cell phone sued for the interception of the cell phone conversations and won. One are that he pointed at was indeed related to the legality of monitoring the attackers communications. The federal criminal law, namely the Federal Wiretap Act, does contain a felony called "interception of communications," which carries up to five years in prison punishment. The law also describes a few of the exemption from punishment. These are:

interception is permitted if one or both of the parties agreed to be monitored (consent exemption); in some states, both parties must agree to the monitoring, while in other one sides consent is sufficient computer trespasser exemption" allows government monitoring of the attacker on the compromised system with just the consent of the system owner (hacking victim); however, it only applies if government is doing the monitoring finally, "provider exemption" permits the interception if done by the system owner with the purpose of protecting their systems or other property from the attackers

In addition, state laws in the US or other countrys laws might well be more restrictive than the above US federal statutes. In some cases, privacy laws might severely restrict all the monitoring. In light of the above, it is sometimes suggested to equip the honeynet systems with warning banners that say that every access to the system is monitored and recorded. Seeing such banner and continuing to hack the system will constitute consent to be monitored. One example of such banner is presented by Lance Spitzner in his paper (http://www.securityfocus.com/infocus/1703) ######################################################### # !READ BEFORE CONTINUING! # This system is for the use of authorized users only. # By using this computer you are consenting to having # all of your activity on this system monitored and # disclosed to others. ########################################################## However, if the attacker compromises the honeypot without seeing the banner (such as via an automated tool or using the protocol that does not allow banners, such as NFS or NTP) or does not happen to understand the language that the banner is written in, the exemption will in fact not apply. Others suggest that since honeypot system is one part of such malicious communication, the monitoring is permitted even without the banner. However, this quickly leads to a legally obscure situation, especially in case if the attacker uses the honeynet for IRC communication with his friends or other third parties. Provider exemption is definitely the most promising. However, even that is not even clear from a legal standpoint since honeynet monitoring is not performed to protect the honeynet. In fact, attackers presence on the honeynet system is a

desirable activity for the operator and the monitoring is performed not to protect but to study the attacker. Thus, the risk of an attacker suing the honeynet operator is not entirely mythical. However, these risks are commonly seen as lower, compared to third party liability. Another legal issue that is mentioned sometimes in relation to honeypots is socalled entrapment. However, legal definition of entrapment only applies to law enforcement (a person is said to be entrapped if he is induced by law enforcement to commit a crime which he would otherwise not commit) and thus does not endanger any honeynet operator who are not members of a law enforcement community and do not plan to prosecute their attackers based on the evidence collected from a honeypot. On a side note, even a legality of hacking a honeypot which is set up with a sole purpose of being hacked is not clear. Apart from legal issues, some people attempt to bring up possible ethical issues with honeypot technology. According to such people, honeypots are questionable from the ethical standpoint since they induce people to attack systems. Such arguments are clearly bogus since honeynets induce people no more than all the production systems that are a) much more numerous, b) look exactly the same from the attacker point of view and c) sadly, often are more insecure than a typical honeynet. Honeypots and honeynets do not lure or provoke anybody into committing a crime, but, in reality, might dissuade people from hacking (after all, that system they will penetrate might turn out to be a honeypot where they will be analyzed) Some observers pile the honeypots with the counterstrike or hack-back technologies which use the hacker methods to get back at the attacker. While such techniques might be deemed unethical, honeypot have truly nothing to do with them. They sit passively and wait for the attacker to discover and hit them; just as the case with any production system. There is no active attraction and there is no counter-attack, just like there is no such things in the case of an intrusion detection system watching a production network. Passive monitoring of a passive system that does not advertise its presence cannot be classified as a counter-strike technology. Yet another attempt to bring ethics into the world of honeypot comes from an argument that honeypots are unethical since they somehow help to breed a better hacker by inducing the underground community to focus on anti-honeynet technologies. Where this argument falls flat is that it applies to any defensive technology, both in information security and in real-world warfare. So, should we abandon our military forces since their presence helps breed more dangerous enemies?

Now, even if we concluded that in many US jurisdictions it will be legal to capture the network traffic on your honeynet, isnt it unethical to eavesdrop on people, even if they are criminal attackers? Fortunately, this question was decided long ago, probably when the first network sniffer, tcpdump, was written. If eavesdropping on criminals is unethical, than indeed most of the modern network security technologies are unethical tool. That will include network intrusion detection systems, network intrusion prevention systems, network-based anomaly systems, network forensic tools, email antivirus tools and even regular network sniffers (which are used for network performance troubleshooting) all the above technologies essentially eavesdrop or sniff the network in order to accomplish their mission. Honeypots are not different they use the same network monitoring methods to accomplish the same goal: network awareness and, eventually, network protection. Finally, the most illogical ethical argument comes from the claim that attackers dont deserve to be deceived and that the good guys (i.e. the security professionals) should not use any deception techniques due to such methods being unethical by definition. After all, everybody teaches their kids that lying is wrong, then why is it ethical to build a computer system that pretends to be a vulnerable host and, in essence, deceives every criminal who connects to it. Those who pose this argument are misguided about the passive nature of most honeypots. After all, if one increases the monitoring on a production upon detecting a suspicious activity and then discovers and studies the attacker who compromised it, nothing unethical takes places. Honeynet is the same system that is deployed just like any production computer system, but with increased monitoring and data capture tools. The attacker who chooses to compromise it definitely runs a risk of being discovered and then monitored; it is just such risk is a 100% certainty on a honeypot. Now, deploying a vulnerable system that can be used to harm others and not taking steps to prevent such harm is clearly unethical. However, honeypot is not an example of such a system due to data control requirements which are meant to prevent exactly that damage to 3rd parties. In light of this, most of the ethical issues around honeynets are clearly artificial and the benefits of this security technology far outweigh any possible ethical concerns, even if they were real. References: 1. Lance Spitzner Honeypots: Are They Illegal? http://www.securityfocus.com/infocus/1703 2. Lance Spitzner The Value of Honeypots, Part Two: Honeypot Solutions and Legal Issues http://www.securityfocus.com/infocus/1498 ABOUT THE AUTHOR:

This is an updated author bio, added to the paper at the time of reposting in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.