Numerous computer systems are faced with network attacks every day. Most organizations use different security devices to protect their systems, like firewalls that block traffic aimed to specific destination ports, or intrusion detection system (IDS) that report alerts when the attacks are detected. However, these devices fail to provide traffic capture and analyze capabilities. A honeypot is a system aimed to solve this problem. It is defined as the security system whose value lies in being probed, attacked and compromised [1]. Honeypots have no production value and server-side honeypots even never advertise themselves but passively capture malicious behavior. Thus, the inbound traffic directed to them can be considered unauthorized and suspicious. Honeypots can be roughly classified into two categories in terms of the interaction level: low-interaction honeypot (LIH), which only implements a partial functionality of the complete system they emulate; and high-interaction honeypot (HIH) that provides a fully functional system. LIHs fail to provide fidelity but they can be deployed in large scale due to its lightweight design. HIHs can guarantee fidelity but they are impractical to be deployed for large address spaces. LIH is less risk than HIH since the adversary can compromise a HIH but not a LIH. Thus, in order to foster strengths and circumvent weakness, hybrid systems made of LIHs and HIHs are proposed.

Hybrid honeypot systems use the LIHs as the frontends [2,3], replying to attacker connection requests and establishing the TCP connections. Later, if the traffic is interesting enough, the hybrid system will perform a connection handoff and redirect the interesting traffic to the HIH. Due to the fact that most existing traffic redirection approaches only focus on connection handoff but rarely keep the destination fingerprint identical, the existing traffic redirection approaches are only capable to fraud script kiddies and automated attacks, but cannot deceive advanced intruders. In practical terms, a skilled intruder will not only observe the connection state but also check the destination fingerprint. Therefore, it is necessary to apply a transparent traffic redirection mechanism which can keep the connection state and the destination fingerprint for hybrid honeypot systems to capture interesting traffic. The objective of this paper is to design a dynamic hybrid honeypot system based traffic redirection mechanism. In order to achieve this objective two technical challenges have to be addressed: (1) to provide a transparent connection handoff by keeping the connection in the same state after takeover; (2) using dynamic hybrid honeypot system to keep the identical appearance of destination, i.e. IP address and operating system fingerprint.

The paper is organized as follows: in Sect. 2, the related work is reviewed; in Sect. 3, the dynamic hybrid honeypot system is presented; in Sect. 4, several experimental results are demonstrated; in Sect. 5, some conclusions are presented.

Hybrid honeypot systems [4,5] using GRE tunnel to connect the frontends and the backends do not show the identical-fingerprint problem, because the backends seem to be directly deployed in the production network. But all traffic is processed with two modes: discard or redirection, due to the use of frontends without interaction capability.

Bailey et al. [2] presented a globally distributed hybrid honeypot architecture which deploys LIHs as the frontend content filters and HIHs to investigate the attack traffic in detail. The system uses a connection handoff mechanism for traffic redirection. In order to avoid saving state for every connection, the connection handoff mechanism takes the decision based on the first payload of any conversation. However, the technical details about the connection handoff mechanisms were not described.

Connection handoff or mobility always needs TCP connection replay between the TCP proxy and the target. Although there are a number of ready-made TCP proxies [6,7], they cannot manipulate or analyze the packets but only redirect them. Similarly, Honeybrid gateway [3] uses the connection replay to implement traffic redirection. Nevertheless, Honeybrid unveiled their technical detail: a TCP replay proxy using libnetfilter_queue [16] to filter traffic. The connection handoff mechanism based on TCP replay is able to provide stealthy redirection for automated malwares. Lin et al. [8] proposed a secure and transparent network environment that allows the automated malwares to attack and propagate but under a stealthy control. Although the TCP/IP stateful traffic replay can facilitate transparent TCP connection handoff, it cannot solve the identical-fingerprint problem.

Some other proposals were trying to address the identical-fingerprint problem for the hybrid honeypot systems. VMI-Honeymon [9] provided a novel solution to clone-routing problem, which is a challenge to create network connectivity to identical HIHs clones without internal in-guest network reconfiguration. Because the network interface in each clone will also remain identical, sharing the same MAC and IP address of the original VM. It will cause MAC and IP collision if the clones are placed on the same network bridge. But in-guest network reconfiguration would inadvertently lead to changing the initial memory state of high-interaction honeypots. Thus, this solution retains the MAC and IP address of the original VM for each clone, and each clone is placed upon a separate network bridge. This solution indirectly addresses the identical-fingerprint problem.

Reconfiguration is a challenge for most security technologies including honeypot as well. Static honeypot systems lack the capability to reconfigure the decoy on the fly, while dynamic honeypots are able to improve the honeypot deployment according to the specific events [10,11]. Figure 1 presents an overview of our dynamic hybrid honeypot system architecture which has been proposed by our previous work [12].

An overview of the dynamic hybrid honeypot system architecture

Full size image

We applies several specialized tools as the components for hosting the dynamic hybrid honeypot system but our ideas are not limited to these tools. For the future research, other advanced tools can replace the current tools in the architecture. In this paper, we focus on the honeypot deployment tools and the Honeybrid gateway, while the other detailed descriptions of the architecture can refer to our previous work [12].

3.1Honeypot Deployment Tools

The system uses Honeyd [13] as the LIHs creation tool, VNX [14] to deploy HIHs and create virtual networks.

Honeyd is a low-interaction virtual honeypot framework, which allows quickly deploying virtual honeypots. It can emulate fingerprints of several operating systems. It also provids a UNIX socket located in/var/run/honeyd.sock to communicate with the inner workings of Honeyd with a script made of Honeyd commands. Thus, using this socket, users can create a client socket to reconfigure the Honeyd based honeypots on the fly, for example, to create and delete any template or even any service.

VNX is employed by our system architecture due to (i) its scalability in creating very complex HIHs; (ii) its ability to automatize the execution of commands inside virtual machines; and (iii), its support for multiple virtualization platforms like KVM, which allows emulating various operating systems under X86 architecture for HIHs. The new version of VNX has developed the capability of dynamic configuration. VNX can automatically reconfigure the scenario through processing an XML syntax based reconfiguration file. One part of the running scenario will be redeployed without impacting on the rest part.

Due to Honeyd and VNX using different configuration languages, we proposed a technology independent honeynet description language (TIHDL) [15] to generally describe and configure the heterogeneous honeynets consisting of Honeyd based LIHs and VNX based HIHs.

3.2Honeybrid Gateway

The revised Honeybrid gateway [3] is employed as the data capture and control tool in our architecture. The Honeybrid gateway includes a Decision Engine and a Redirection Engine which are in charge of orchestrating the filtering and the redirection between frontends and backends. The Decision Engine is used to select interesting traffic and the Redirection Engine is used to transparently redirect the traffic. In order to implement such functionality, like most traditional TCP proxies, the original Honeybrid gateway applies the TCP relay mechanism as the left part of Fig. 2 shows.

Illustration of the traffic redirection mechanisms

Full size image

The main drawback of the original Honeybrid gateway is that it is not able to distinguish the automated attacks from the human manual attacks. More accurately speaking, it neglects the attacks generated by advanced intruders. In the original design, a pair of LIH and HIH use different IP addresses, and the Honeybrid gateway can transparently redirect the traffic from the LIH to the corresponding HIH by connection handoff. It is useful to catch the automated malware but if the attack is from an intelligent adversary, he can easily detect the traffic redirection by simply checking the IP address of final compromised system. If the destination IP address is different from the original target IP address, the adversary can realize that he is accessing a honeypot. We will address this problem by improving transparent traffic redirection between LIH and HIH based on the dynamic hybrid honeypot system. In order to guarantee such functionality, we have to address the following two questions: how to perform connection handoff and how to keep the identical fingerprint.

The answer to the first question is to preserve the presence of states in the communication. This task has been finished in the original Honeybrid gateway. For the second requirement, it is necessary to guarantee the identical IP address and the fingerprint of the pair of LIH and HIH. The right part of Fig. 2 summarizes the revised mechanism involved in the redirection. The Redirection Engine works in three phases:

Phase 1: Incoming packets from the attacker are forwarded to the LIH while being inspected by the Decision Engine;

Phase 2: If the Decision Engine flags the connection as worth redirecting, it sends a signal to the Redirection Engine to switch off the LIH and switch up the corresponding HIH. When the HIH is ready to take over, the Redirection Engine starts replaying the connection to the HIH;

Phase 3: When the connection between the Honeybrid gateway and the HIH is established, packets are proxied between the attacker and the HIH. Thanks to the update of TCP headers of all packets proxied during this phase, the attacker believes it still communicates with the original target from the connection initialized in phase 1.

Therefore, the Honeybrid gateway controls not only the data but also the honeypots. Before it replays the connection, it must switch off the LIH and spin up the corresponding HIH. It is important to notice that while most of the network attacks can be redirected through this mechanism, some specific attack processes are out of the scope of current architecture. These processes include connections based on cryptographic protocols such as SSH or HTTPS. However, in such cases, specific services and IP addresses can be configured to forward directly to the farm of HIHs.

The transparent traffic redirection mechanism should be evaluated in two ways: firstly, it should be tested if an adversary could fingerprint the redirection; secondly, the performance of redirection mechanism should be verified under heavy traffic.

First of all, for the functional verification we use the telnet service to test the transparent redirection mechanism as Fig. 3 shows.

Testing scenario

Full size image

The telnet server runs on a HIH. The attacker uses the telnet client to connect a LIH (10.1.0.2), and the Honeybrid gateway can handoff the connection to the HIH. The messages shown on the attacker side are as follows:

It shows the attacker has connected into the HIH. However, the possible problem is the latency caused by starting a HIH. We tested the duration to start or wake up a VNX based HIH. VNX can deploy KVM based virtual machine and LXC based virtual machine. The delay is very short to start up a LXC based virtual machine (less than 1 s). But the virtual machine based on LXC can only emulate the Linux operation system using the same Linux kernel of the host. Thus, this method lacks of fidelity.

The virtual machine based on KVM can emulate various operating systems. A virtual machine emulated by VNX has five states. They are undefined, defined, running, suspended and hibernated. VNX provides functions that can switch a virtual honeypot from one state to any other state. The average startup latency of KVM based HIH from different states is shown in Table 1. To start up or reboot a KVM based HIH will take 40 s, which could result in time out of connection request. To wake up a hibernated HIH still needs 13 s, so it is not a good choice either. A suspended HIH spins up only within 1.5 s, which has the shortest delay. Therefore, the approach for KVM based HIHs is to start up a group of HIHs and then keep them into suspended state. When the interesting traffic is decided to be redirected, the corresponding suspended HIH should wake up to provide service.

Secondly, for the performance evaluation we use the network bandwidth measurement tool namely Iperf to test the HIH with using Honeybrid and without using Honeybrid. Figure 4 illustrates the bandwidth comparison.

Bandwidth test by Iperf

Full size image

The figure shows that the bandwidths under different numbers of parallel TCP connections. It is normal that the more number which the concurrent TCP connections have, the less value that the bandwidth has. Under the function of Honeybrid gateway, the bandwidth of TCP connection between the attacker and HIH is much less than the bandwidth when there is no Honeybrid gateway. It proves that the gateway greatly limits the bandwidth of TCP connection due to its processing on every packet.

We also designed a test based on the SMTP to monitor the latency of the first push packets arriving at the HIH under different rates of incoming connections. An SMTP server (Postfix) was installed in HIHs. An SMTP client script was installed on the remote attacker. The script consists of the following sequence of five SMTP commands:

The experiment consisted of running the automated SMTP client script at different rates, from a single connection per second up to 100 concurrent connections per second. We just record the duration for all the first push packet of each connection arriving at the backend. The experimental result was shown in Fig. 5.

Connection latency

Full size image

The first push packet including payload arriving at the backend means the TCP connection between the attacker and HIH has been established. So the timestamp of the first push packet arriving at the network interface of the backend can be used to calculate the duration for establishing TCP connection. The experimental result shows that the connections with packet processing of Honeybrid gateway can cause much more latency than the normal connections, and the effect will become much more obvious when the number of concurrent connections is increasing.

Therefore, the proposed transparent traffic redirection mechanism is effective. Although there are some approaches to detect honeypots through performance testing, for example, testing the connection latency, the performance reduction caused by the packet processing of Honeybrid gateway is still reasonable.

In this paper, a novel dynamic hybrid honeypot system based traffic redirection mechanism is proposed in order to solve the identical-fingerprint problem. The proposed system architecture employs several virtualized tools to approach the task. The mechanism uses libnetfilter_queue to process packets and uses the switch between LIHs and HIHs to avoid fingerprint detection. The experimental results show that the mechanism is functional effective and the performance depends on the processing rate of Honeybrid gateway. In the future, firstly we will try to improve the performance of Honeybrid gateway to reduce the risk of being detected. Secondly, we will try to apply this mechanism to some large-scale honeypot systems in order to facilitate resource efficiency as well.