Proceedings of the International Conference on Computer and Communication Engineering 2008 May 13-15, 2008 Kuala Lumpur, Malaysia Countermeasure for Detection of Honeypot Deployment Lai-Ming Shiue 1, Shang-Juh Kao 2 1 Department of Applied Mathematics 2 Department of Computer Science and Engineering National Chung-Hsing University, Taiwan Email: lmshiue@amath.nchu.edu.tw Abstract In this paper, a deceptive system, called honeyanole, is developed to escape from honeypot hunting as well as to collect attacking information. In honeyanole, three phases of collection, redirection and deception are implemented. In the collection phase, four types of attacking information are gathered for cross analysis to build up the blacklist. Upon the blacklist being developed, two redirection techniques, layer-2 and layer-3 redirection, are employed to dynamically transmit incoming traffic to a production or a deception server in the redirection phase. Finally, the deception server could transparently capture the attacking behaviors in the deception phase. With honeyanole, we can effectively prevent honeypot deployment from hunting, build an early warning system, and enhance the system defense. I. INTRODUCTION As threats to network security increase with the exponential growth, the traditional defensive systems, such as firewall and intrusion detection systems, is insufficient. Honeypots [1-4], a deceptive approach, are introduced to trap hackers. Without being noticed by hackers, attacking information is gathered and analyzed in order to trace attacking behaviors. There are two approaches to classify honeypots [5-7], depending upon either the deployment purpose or the interactions with the honeypot. Regarding with the purpose of deployment, a honeypot could be constructed for the production or research purpose. Based on the interactions with the honeypot, a honeypot could be either low-interaction or highinteraction. No matter how a honeypot is classified, either by purpose or by interaction, only when the deployment is transparent, honeypot approach is useful. Since the essential task of the honeypot strategy is to make indistinguishable to attackers between a deceptive system and a regular host, how to not expose the honeypot deployment becomes critical. In general, deception detection [8] could be service support detection, connection feature detection, or system level detection. Service support detection [9, 10] launches all kinds of service requests to check for a honeypot. Usually, an emulated service can be easily examined as a deceptive system. Connection feature detection [10] refers to remotely test a target host and collect the transmission features, such as latency, error, and protocol header. Through the connection features analysis, a fabricated operating system or a virtual network interface can easily be discovered. For instance, a high detection rate of recognizing a low-interaction honeypot was reported in [11] by using Neyman-Pearson decision theory to analyze information collected from round trip time of icmp and tcp connections. And, Mukkamala et al [9] demonstrated that high detection accuracy (higher than 95%) can be derived in identifying a honeypot by using SVMs to analyze 49 various features of tcp connections. System level features, such as type of physical devices, type of file systems, and the memory usage of hidden programs, are required to detect [12, 13] a high-interaction honeypot, no matter the real system is deployed at a physical or virtual machine. There already exists some collection tool for high-interaction honeypots, for instance the Sebek [14], which works in the kernel module to monitor system call invocations and record data of interest. In [15], the NoSEBrEak project has shown that Sebek can be detected and disabled. Briefly, the three deception detection techniques for discovering different types of honeypot systems can be listed as in Table 1. 978-1-4244-1692-9/08/$25.00 2008 IEEE 595
TABLE I. Interactio n Level DETECTABILITY OF DECEPTION DETECTION METHODS Machine Type Connection Feature Detection Method Service Support low virtual detectable detectable high System Level undetectabl e virtual detectable undetectable detectable physical undetectable undetectable detectable While the development of a honeypot system focuses on the integration and analysis of attacking information, the exposure of honeypot deployment will make the deceptive system to be invalid. A common countermeasure against the deployment exposure is to redirect the connection to avoid directly interacting with a honeypot. The redirection technique is to decompose Internet traffic into two destinations: a production server or a honeypot. In general, the direction of traffic flows is decided upon the intrusion detection engine. In [16], a bait & switch honeypot router is constructed at the network layer and uses network address translation (NAT) to dispatch the traffic flows. However, such a pure layer- 3 redirection could easily slow down non-attacking service connections and the deployment could be revealed via the latency trace, such as via the icmp protocol. In [17], a redirection module in honeypot system at the data link layer is presented to lure suspicious traffic into a honeypot system via changing the MAC address. Unfortunately, when the layer-2 redirection is implemented in a connection oriented network, the sequence number failure due to the reconnection operation makes the honeypot system to be suspicious. In this paper, a deceptive system, called honeyanole, is developed to escape from honeypot hunters as well as to collect attacking information to enhance further defense. In this system, non-attacking service connections and probing connections are monitored and transmitted, while the attacking service connections are transparently redirected to the fabricated system for the attacking process collection. Finally, the system implementation and its evaluation are reported. II. THE HONEYANOLE SYSTEM In honeyanole, both layer-2 and layer-3 redirection mechanisms are employed to dynamically transmit incoming traffic flows for the purpose of resisting the detection of honeypot hunters as well as collecting and analyzing attacking information. We categorize network connections into regular service requests, probe requests, and attacking service requests. Under the layer-2 redirection, regular service connections and probe requests are directed to the real system. In this case, the redirection latency is insignificant, and hence the honeypot is not suspicious to honeypot hunters. Once an attacking service connection is discovered, layer-3 redirection is active and the connection is redirected to the fabricated system. There are three phases in honeyanole: collection phase, redirection phase, and deception phase. The main task of collection phase is to build a blacklist of possible attackers to support the redirection server. As shown in Figure 1, all traffic flows from Internet to production server will be mirrored to the detection module for intrusion inspecting. The information of possible attackers will be gathered by collection module from detection module and other three defensive systems, including the illegal access log, the record of probes, and exchanged defensive information. Mirrored Traffic attacking information from other systems Detection Collection Analysis Figure 1. s inside the collection phase. redirection server Decision After the collection, the alerts of attacking information for eliminating the same attack and incurring a new threat based on alert type, source address, and target address are raised. Then, the analysis module performs the correlation of collected attacking information to predefine attack scenarios, such as network scans, port scans, or vulnerability attacks. Upon finishing the analysis, the decision module would build an orderly list of possible attackers according to temporal information and involved services. Finally, a blacklist is distributed to redirection server dynamically. For redirection, the server with external, internal, and redirection interfaces are designated to connect to Internet, a production network, and a deception server respectively. When an incoming traffic arrives from Internet interface, redirection module will transmit it to a production server or a deception server with the aid of the blacklist. Operational flows of the redirection module can be depicted in Figure 2. 596
Three deception programs, honeyd [20], honeytrap[21] and linux with sebek [14], are deployed as deception servers. In order to validate the feasibility of the honeyanole, several tests in the test environments of direct, bait & switch, and honeyanole were conducted as shown in Figure 4. Apache web server was employed as the production server and Microsoft web application stress tool was adopted to generate http connections from the traffic generator. Figure 2. Operation flows of redirection module. Deception Agent Production Server If an incoming traffic is a probe or its source address does not appear in the blacklist, the layer-2 redirection would forward the traffic to a production server via the internal interface without changing any packet s content. However, if an incoming traffic has its source address appearing in the blacklist, the layer- 3 redirection will take place. With layer-3 redirection, target masquerade changes the target address of incoming packets into the deception server before layer-3 forwarding. And, TTL masquerade adjusts the value of ttl in IP header to conceal from the action of layer-3 forwarding. Similarly, the outgoing packets will be adjusted accordingly. The deception phase is responsible to capture the intrusive processes. With honeyanole, various types of honeypots systems can be deployed as deception servers. Adopting a high-interaction honeypot can obtain more intrusive information and easily suffer from deployment disclosure by system level detections, while a low-interaction honeypot could be discovered by service support detections. How to precisely predict an intrusion, more specifically honeypot detection, is the key feature to deception detection. By combining the above three phases, honeyanole system is built as shown in Figure 3. Therefore, how to build an effective and accurate blacklist is an imperative task. All traffic to production server, including service connections and attacks, are mirrored to detection module to execute an intrusive inspection. The alert generated by the detection module is also the main part of attacking information. Traffic defensive information exchange Black List Detection Collection Redirection Server Collection Server Redirection Decision Analysis Figure 3. The global view of honeyanole. Figure 4. Test case network layout. Deception Server Defensive System III. SYSTEM EVALUATION Following the honeyahole architecture, we carried out the implementation in slackware linux environment. Iptables [18] and snort [19] are employed as the redirection and detection modules respectively. A. Connection Latency Test As for examining connection delay generated by both layer-2 and layer-3 redirections, the first test is to measure the connection latency in various situations. 597
598
REFERENCES [1] F. Raynal, Y. Berthier, P. Biondi, and D. Kaminsky, "Honeypot Forensics, Part I: Analyzing the Network", IEEE Security & Privacy, vol. 2, pp. 72-78, Jul-Aug 2004. [2] F. R. Raynal, Y. Berthier, P. Biondi, and D. Kaminsky, "Honeypot Forensics, Part II: Analyzing the Compromised Host", Ieee Security & Privacy, vol. 2, pp. 77-80, Sep-Oct 2004. [3] A. Chuvakin, "Honeynets: High Value Security Data", in Network Security. vol. 2003, 2003, pp. 11-15. [4] R. McGrew, "Experiences with Honeypot Systems: Development, Deployment, and Analysis", in HICSS '06. Proceedings of the 39th Annual Hawaii International Conference on 2006, pp. 220a-220a. [5] DFN-CERT, "European Network of Affined Honeypots - Survey on the state-of-the-art", Report Number: D0.1, 2005. [6] R. Tber, "A Practical Comparison of Low and High Interactivity Honeypots", in Information Security Institute. vol. Master Australia Queensland University of Technology, 2005, p. 51. [7] H. Artaila, H. Safab, M. Sraja, I. Kuwatlya, and Z. Al-Masria, "A Hybrid Honeypot Framework for Improving Intrusion Detection Systems in Protecting Organizational Networks", Comuters & Security, vol. 25, pp. 274-288, 2006. [8] N. Krawetz, "Anti-honeypot Technology", in IEEE Security & Privacy. vol. 2, 2004, pp. 76-79. [9] S. Mukkamala, K. Yendrapalli, R. Basnet, M. K. Shankarapani, and A. H. Sung, "Detection of Virtual Environments and Low Interaction Honeypots", 2007, pp. 92-98. [10] P. Defibaugh-Chavez, R. Veeraghattam, M. Kannappa, S. Mukkamala, and A. H. Sung, "Network Based Detection of Virtual Environments and Low Interaction Honeypots", in Proceedings of the 2006 IEEE SMC, Workshop on Information Assurance, 2006, pp. 283-289. [11] F. Xinwen, Y. Wei, D. Cheng, T. Xuejun, K. Streff, and S. Graham, "On Recognizing Virtual Honeypots and Countermeasures", 2006, pp. 211-218. [12] T. Holz and F. Raynal, "Detecting Honeypots and Other Suspicious Environments", 2005, pp. 29-36. [13] N. C. Rowe, "Measuring the Effectiveness of Honeypot Counter-Counterdeception", in HICSS '06. Proceedings of the 39th Annual Hawaii International Conference on 2006, pp. 129c-129c. [14] M. A. Davis, "Sebek", 3.0.4 ed New York, USA: The Honeynet project, 2003. [15] M. Dornseif, T. Holz, and C. N. Klein, "NoSEBrEaK - Attacking Honeynets", 2004, pp. 123-129. [16] L. Carter, "Setting Up a Honeypot Using a Bait and Switch Router": SANS' Information Security Reading Room, 2004. [17] Y. Geng, R. Chun-ming, and P. Lei, "A Novel Approach for Redirecting in Honeypot Systems", The Journal of China Universities of Posts and Telecommunications, vol. 12, 2005. [18] P. Russell, "iptables", netfilter, http://www.netfilter.org/, 2007. [19] M. Roesch, "Snort", Snort Sourcefire, 2007. [20] R. Chandran and S. Pakala, "Simulating Networks with Honeyd", 2003. [21] Honeytrap: http://honeytrap.mwcollect.org/, 2007. 599