INTERCEPT+: SDN Support for Live
Migration-based Honeypots
Ayumu Hirata∗ , Daisuke Miyamoto† , Masaya Nakayama† , Hiroshi Esaki∗∗ Graduate School of Engineering

The University of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656 JAPANayumu@hongo.wide.ad.jp, hiroshi@wide.ad.jp† Information Technology Center

The University of Tokyo
2-11-16 Yayoi, Bunkyo-ku, Tokyo, 113-8658 JAPANdaisu-mi@nc.u-tokyo.ac.jp, nakayama@nc.u-tokyo.ac.jp

Abstract—This paper introduces a novel honeypot for web
application. Recently, web applications have been the target ofnumerous cyber attacks. In order to catch up new vulnerabilities
in the applications, using a honeypot system is a feasible solution.
However, there remains difficulty for developing a lure-able,
protect-able, and deception-able honeypot for web applications.
In this paper, we present an approach in which attackers will
be automatically isolated from the real web server to the honey
web server. The key features are employing migration techniques
to create a virtual machine as a honey web server, making thehoneypot to equip the same memory and storage devices of
the real systems, and controlling network traffic with OpenFlow
in order to isolate honeypots from the real server. This paper
also shows our design and implementation of INTERCEPT+, acomponent of honeypot systems for web applications.
Keywords—Honeypot, Web application, Live Migration, OpenFlow

I.

I NTRODUCTION

Web applications have become one of the popular targets
for cyber attacks. This is due to several reasons; for one, theweb applications manage a wide array of information including financial data, medical records, social security, therefore
attacks aim at stealing the information [1]. Another reason
provided by McAfee [2] is the ease of exploitation of web
vulnerabilities, combined with the proliferation of low-grade
software applications written by inexperienced developers.
According to the report from OWASP [3], web vulnerabilities
allow a remote attacker to execute injection attacks, e.g., SQL
injection [4] and/or Cross Site Scripting [5] attacks that input
malicious codes to pose web hijacking, information leakage,malware infection, and so on.
A web application firewall (WAF) is one of the solutions
against attacks which filters suspicious code injection. Generally, it inspects the application layer so it usually comesas an appliance type or as a server module [6]. There areseveral algorithms for distinguishing suspicious codes fromHTTP request. The one is rule-based filtering, which checks
the HTTP request with the database of known attack patterns.
Besides the protection via blacklisting, WAF usually supports

whitelisting; with active whitelisting, the rule set of the WAF
describes the exact behavior of the application [7]. Different
from the rule-based methods, heuristics-based methods calculate the likelihood of being a malicious code and compare thelikelihood with the defined discrimination threshold.
Unfortunately, it still remains challenges while preventing
code injection attacks. The rapid development of web applications arises numerous program bugs, the cause of web
vulnerabilities. Building a perfect blacklist is therefore tediouswork. In the case of the whitelisting, the issue is that it requires
WAF operators to maintain rules of the legitimate input andoutput for the applications. The core issue in heuristics-based
methods is detection accuracy. To achieve higher detection
accuracy, monitoring injection attacks and analysis of them
are necessary.
Herein, we present a server-type, honeypot systems forobserving web attacks. Theoretically, honeypots are decoy
systems to gather information regarding an attacker, and have
deception and luring capabilities. A honeypot offers some
services that appear perfectly normal to the attackers, andlooks alike as if the system has honey, e.g., valuable data.
Our motivation is to collect the information related to cyberattacks toward web applications using the honeypot.
Our developed INTERCEPT+ is a component of honeypot
for web applications. INTERCEPT+ is designed for tailoring ahoney web server by creating a perfect copy of the legitimate
server with live migration techniques. INTERCEPT+ alsoenables to isolate attackers’ traffic with the OpenFlow-based
system. Since our honeypot has the perfect copy of the real
server, the pair of media access control (MAC) address and IP
address is the same as that of the real server. In order to avoid
MAC and/or IP address conflicts, INTERCEPT+ induces theattack packets to the honeypot regardless of the addresses.
We show, by the preliminary evaluation in this paper, that
Live-Migration technique used in INTERCEPT+ can makeits perfect copy in short time and it makes almost no data
corruption. We also show that our developed OpenFlow-based
packet forwarder can correctly control the packets from normal
users and attackers.

TABLE I: Interaction Level
Interaction
Actual OS / applications
Risk
Operational cost
Performance

low
no
low
low
low

high
yes
high
high
high

NormalUser

The rest of paper is organized as follows. Section II briefly
explain related work, and section III designs the architectureof the honeypot for web applications. Section IV and V implement INTERCEPT+, our proposed honeypot aspects fromthe migration-based honeypot and OpenFlow-based packet
forwarder, in respectively. Section VI shows the preliminary
evaluation of INTERCEPT+ and section VII discusses themissing piece toward the suitable honeypot. We finally summarize our contribution in section VIII.
II.

Attacker

OpenFlow
Controller
OpenFlow
SwitchReal Web Server

Honey Web Server

Real Database

Honey Database

R ELATED W ORK

Honeypot systems can be categorized into four types,
namely (i) high-interaction client-type honeypot, (ii), lowinteraction client-type honeypot, (iii) high-interaction servertype honeypot, and (iv) low-interaction server-type honeypot.
The type, server or client, means that the honeypot systems
work as server or client computer. The key characteristics of
the interaction was explained in many articles [8]–[10], andthe summary is shown in Table I.
The client-type honeypot systems are used to discover
new vulnerabilities in the client side systems, such as client
OSes, web browsers and their plugins. The honeypot systems
usually crawl suspicious web content, allow malicious content
to exploit the system, and observe the attack methodologies.
For examples of the type (i), HoneyClient [11], CaptureHPC [12], and Marionette [13] are used to analyze malicious
URLs for blacklisting. If a system, which was composed ofthe latest version of Windows, Internet Explorer and plugins,
was compromised while browsing, it can be assumed that
there was new vulnerability in the system and the honeypot
succeeded to find it. Instead of using the actual systems, thetype (ii) honeypot systems such as Honey-C [14] and MonkeySpider [15] mimic the client OSes, IP stacks and applications.
While the attacks target particular applications, it can reduce
the risk for compromising. However, the observable information during the attacks tends to be limited in comparison to
the high-interaction honeypot, as shown in Table I.
The server-type honeypot systems aim at obtaining new
vulnerabilities by monitoring the trials of attack, penetration,and intrusion. In order to collect these events, the honeypot systems need to induce the malicious people to be targeted of theattacks. Since the type (iii) honeypot systems are faced to therisk for compromising, the abilities including containment arenecessary. Referring to [16], we will explain the requirementsof the honeypot systems. In the case of type (iv), the honeypot
systems run tools aiming at emulated vulnerable systems. For
example, Nepenthes [17] and Deception Toolkit [18] mimic
the vulnerable applications. Unfortunately, there are several
tools [19], [20] for identifying the systems remotely, therefore,
the attacker are easily aware that their targeted system ishoneypot.

Fig. 1: Concept of High-interaction Server-type Honeypot for
web applications

III.

D ESIGN OF H ONEYPOT FOR WEB APPLICATIONOur grand goal is to develop a novel honeypot system forweb applications. In order to discover new vulnerability of web
applications, honeypot systems facilitate to collect new attack
methodology.
A. Requirements
Along with our survey described in section II, we define thefollowing abilities that honeypot systems for web application
should equip.
•

Luring ability
Due to the nature of honeypot, the system must be
attractive for attackers.

•

Protection ability
The system must equip protection capability against
the attacks. Containment must be work for preventing
the abuse of the systems.

•

Deception ability
The system must have deception capability, in otherwords, attackers cannot distinguish that their targeted
system is honeypot.

In the context of the honeypot systems for web applications, we decide to employ high-interaction server-type
honeypot systems. Since web attacks often require to login
to web applications before their execution, the low-interaction
honeypots are required to emulate many web applications. It
might be tedious, because this task is equal to make the cloneof the targeted application.

B. Components

TABLE II: Specification of Physical Machines

Our concept of the honeypot system is shown in Figure 1.
In order to meet the luring requirements, it employs the actual
web applications. A router normally sends to all web requests
to the real web server. However, when suspicious web requests
are detected, the router sends to the requests to the honey web
server. This can meet the protection requirements hence theattacks must not be harm to the real web server.
The one of the difficult point is that a honey web servermust have the same state to a real server. In other words, thehoney server is required to have the same memory of the real
server regarding to the login state, as well as files of web
content including applications. We consider such case that theattacker are required to login to web applications before theattacking. Since the attacker’s login process is not different
to the normal one, this procedure might be done in the real
server. After completing the login procedure, the attacker sends
suspicious requests to the web application, and the requests
are forwarded to the honey web server by the router. To deal
with such requests for the honey web server, the server must
know the attacker’s login state as same as the real server.
Otherwise, the honey server may return some error messages
to the attacker; the attacker can have a chance to be aware ofthat they are quarantined to the honey systems. It cannot meetthe deception requirement.
In order to meet the deception requirement, we decided toexperiment with migration techniques. They enable a virtual
machine to be physically moved from one physical machine
to another in a transparent way [21]. It also enables to create
the complete memory and storage copy of the real web server.
Another one of the difficult points is address duplication.
Since the migrated virtual machine has the same MAC and
IP address of the real server, it must be considered for theway of forwarding suspicious web requests to our proposed
honeypot. Generally, a network router (L3 router) decides next
hop for each packet regarding to the destination IP address, anda network switch (L2 switch) finally decides the destination
with the MAC address. Therefore, the conflicts of IP and/or
MAC address causes that the suspicious web requests are notdelivered to the honeypot.
Instead of the traditional network routers/switches, we
decide to employ a Software-Defined Network (SDN) architecture which enables flexible traffic management. Within
the architecture, packet forwarding decisions are controlled
by the OpenFlow protocol; an OpenFlow Switch (OFS) asks
OpenFlow Controller (OFC) to deal with any packets when the
OFS attempts to forward the packets. An OFC is an applicationthat manages flow control and dictates how the OFS handles
matching packets. As shown in Figure 1, the network switches
behind the host OSes of both the real and honey web servers
should be capable to the OpenFlow protocol and work as an
OFS. For benign requests, the OFS sends them to the real web
server. Oppositely, the OFS forwards a request to the honey
web server whenever the request seems to be suspicious.
There still remains such problems that determination of
suspicious requests, prevention of data leakage, avoidanceof data corruption, and migration in short time period. For
identifying suspicious requests, the likelihood of being an
attack, which can be calculated by the heuristics-based WAF,

CPU
MemoryDisk
NIC

Sender PC
Intel(R) i7-3610QM
2.30 GHz
8 GB
1 TB ATARealTek RTL-8169(Gigabit Ethernet)

Receiver PCIntel(R) i5-2450M
2.50 GHz
4 GB
500 GB ATA
RealTek RTL-8169(Gigabit Ethernet)

is useful. This is just a case, but if there is slight possibilityof the attack, the router in Figure 1 can forward packets to thehoney web server. Even if the normal transaction is forwarded
to the honey server, it must not be lost because the honey server
can observe the transaction. Due to the honey server has thesame state of the real server, it must not penalize normal users’convenience.
In order to prevent data leakage, it can be considered toseparate databases for real and honey web servers. The real
database has entire tables and records, and the honey databasehas limited tables and records that are related to the user who
logged in to the web applications. While the honey databaseshould not contain the records to other users, the risk of dataleakage might be thwarted.
The missing pieces are avoidance of data corruption
and migration in short time period. This paper also discusses
on development of the system in corresponding to these two
problems.
IV.

I MPLEMENTATION OF L IVE M IGRATION - BASEDH ONEYPOTIn our study, we setup Ubuntu 13.04, Kernel-based Virtual
Machine modules to two physical machines; their specifications are shown in Table II. We have modified QEMU [22]source codes. Due to the nature of migration techniques, amigration-source VM will power off to prevent a possible data
corruption. Whenever our implement continues to run a source
VM after migration, both suppression of the state change inthe VM and prevention of the data corruption are necessary.
In order to keep source VM running after migration, we
modified the state of source VM will be changed when vm
stop force state() and runstate set() are called via
migration.c. It works fine, so the rest of problem is the data
corruption.
At first, we used Full Live Block Migration (FLBM) for
preventing data corruption. FLBM supports the entire disk
copying, therefore, the source VM and destination VM haverespectively their own virtual disk images. It enables that thesource and destination VM have the same content in entire
memory and block devices as well as avoiding data corruption.
However, FLBM requires a lot of time due to the copying
full disk images during migration procedure. It might not begood solution for honeypot, because an attacker would feelsomething is not normal.
Different from FLBM, it was feasible to use of Incremental
Live Block Migration (ILBM). In the “incremental” mode,
only the blocks that were modified are migrated. QEMU’s disk
image utility supports to create a snapshot image file. Insteadof FLBM, ILBM can dramatically reduce the time during livemigration, but it still needs couple of time; it can be assumed
that these times are required for verifying disk consistency andfor memory migration.
In order to reduce the time for verifying disk consistency,
we tested LiveBackup [23] and DriveBackup [24]; the former
enables the destination VM periodically polls the source VMs
to the data which might be backup, and the latter enables topush the data from the source VM to the destination VM.
However, these tools are designed for backup, due to that they
only work when the source VM is surely powered off. If thesource VM kept running, we confirmed that the data corruption
or critical system failure occurred.
Instead of using backup tools, we observed that combination of NFS and advanced multi layered unification filesystem(AUFS) [25] worked fine. AUFS is a implementationof Union File Systems, which provides the function, called
branch, to unite several directories into a single virtual filesystem. Based on the solution, we conducted our experiment asfollows.
1) Setup snapshot image files
In order to reduce the further copy-on-write process,we decided to use snapshot. Besides to this, the source
physical machine (PM) and the destination PM have thesame base image file for the snapshot image file, anduse the base image file to the same directory path in thephysical machine. For example, if the destination PM puts
the base image file into /root directory, the source PM
also puts the base image file into /root.
2) Sharing snapshot
The source PM creates the snapshot and place the file
into NFS server. The destination PM mounts the the
NFS server as a read only file systems, and configure
AUFS directory. For example, a NFS server exports /nfs
directory and the destination PM mounts the place as aread-only file system, e.g, /ronfs. The PM then mounts/nfs as an AUFS system, in which /ronfs is a read
only directory and any other directory, e.g., /tmp is awritable directory.
Instead of ILBM, this methodology employs copy-on-write
to keep consistency of the VM disk image files between
the source and destination VMs. We observed that the copyon-write process will be started after the memory migration
finished.
Finally, we employ Kemari [26] for reducing the time formemory migration. Kemari provides the feature of the fault
tolerance for KVM, and makes the memory migration to bedone in the background. The feature also enables the reductionof the time for migrating memory in INTERCEPT+.
Therefore, our prototype implementation is developed bymodifying the latest version of Kemari. The figure 2 demonstrates how INTERCEPT+ works for the sender and thereceiver VMs. The sender (physical machine) runs the VM asshown in Figure 2a and the receiver also runs the VM as shownin Figure 2b with enabling Kemari’s fault tolerant feature.
The sender also starts the fault tolerant migration via sender’s
QEMU monitor console with specifying the IP address of thereceiver. In the case of Kemari, the sender VM still runs after
finishing migration; the receiver VM does not start, but is

Algorithm 1 Pseudo Code of the OpenFlow-based Packet
Forwarder
for all packets do
Read the list of suspicious IP addresses
if incoming packets from Internet thenif the source IP address is listed thenSend signals to finish live migration
Forward the packet to the honey web server
else
Forward the packet to the real web serverend ifelse if outgoing packets from the real web server thenif the destination IP address is listed thenDiscard the packet
else
Forward the packet to the Internet
end ifelse if outgoing packets from the honey web server thenif the destination IP address is listed thenForward the packet to the Internet
else
Discard the packet
end ifend ifend forTABLE III: Specification of Physical Machines
CPU
MemoryDisk
NIC

OpenFlow PC
Intel Core i7-3632QM
2.20 GHz
8 GB
500 GB ATA
RealTek RTL8111/8168/8411(Gigabit Ethernet)

suspended. After the receiver VM starts, the sender disables
the fault tolerant feature and stops the sender VM by callingvm_stop(0) from migrate_ft_trans_error() function in migration.c. As we mentioned above, we commentout the vm_stop() function not to power-off the VM. In
addition, we also modify the receiver for remotely starting theVM. Instead of inputting command in the receiver’s console,
INTERCEPT+ accepts the signal for launching the VM, as
shown in Figure 2b.
V.

I MPLEMENTATION OF THE O PEN F LOW- BASED PACKETFORWARDER

This section demonstrates our implementation of
OpenFlow-based packet forwarder. We installed the functionsof OFC and OFS to one PC, its specification is shown in
Table III. We chose RYU [27], a python framework for OFC,
to develop our implementation as an OpenFlow application.
We also selected Open vSwitch [28] for OFS. The OpenFlow
PC has three network interface cards. One is used for theexternal connection, one is for connecting to the real web
server and the other is for the honeypot web server.
The pseudo code of our implementation is shown in
Algorithm 1. As we described in section III, it usually forwards all packets from the Internet to the real web server.
Besides, all packets from the real server are also forwarded
# ./qemu-system-x86_64-drive file=/nfs/debian-kvm001.qcow2,if=virtio-boot d -enable-kvm -monitor stdio -vnc :0(qemu) migrate -d kemari:tcp:192.168.1.2:4444

(a) Sender (192.168.1.1)

# ./qemu-system-x86_64-drive file=/nfs/debian-kvm001.qcow2,if=virtio-boot d -enable-kvm -monitor stdio -vnc :0-incoming kemari:tcp:0:4444# kill -256 (pid)(b) Receiver (192.168.1.2)

Fig. 2: Demonstration of INTERCEPT+ system

to the Internet. To implement these functions, the forwarderchecks the list of suspicious IP addresses for each packet.
If the source IP address of the packet was listed, the packet
would be forwarded to the honey web server. Oppositely, theimplementation continues to work as usual.
We considered such case that the suspicious packets could
be detected. The OpenFlow-based packet forwarder immediately ran OS commands for sending signals on the host OS ofthe honey web server, in order to prepare the honey web server.
It then forwarded all packets with suspicious source IP addressfrom the Internet to the honey web server, after live migration
was finished. This implementation was also designed to isolate
the real server from the attacker. It discarded all packets withthe suspicious destination IP address from the real web serverto the Internet. In the case of outgoing packets from the honey
web server, the forwarder did oppositely.
In addition to that, the forwarder also needed to retrieve thelist of the suspicious IP addresses. Our implementation simply
read a file for retrieving the address list.
VI.

E VALUATIONThis section provides our evaluation results. Section VI-A
shows the performance of the migration-based honeypot, andsection VI-B analyzes the latency of the OpenFlow-based
packet forwarder.
A. Live Migration-based honeypot
The requirements of the INTERCEPT were avoidance ofdata corruption and migration in short time period. The section
show the detail conditions of the preliminary evaluation inwhich we used two physical machines as shown in Table II.
This evaluation employed three strategies for launchinga honey server, namely Incremental Live Block Migration(ILBM), Live Memory Migration (LMM) with using AUFS
for copying block devices, and INTERCEPT+, our modified
version of Kemari with AUFS. We also prepared four typesof snapshot images, whose size were 20, 50, 100, and 500
MegaBytes (MB) in respectively. Note that 20 MB is theminimum size for the snapshot image file in our experiment.
Based on the above conditions, we measured the time
for launching virtual machines. For the cases of LMM with
AUFS and INTERCEPT+, we compared the timestamp of thesnapshot images created by copy-on-write with the time whichstarted the migration. As for the case of ILBM, we manually
measured the turn around time by calculating from the started
time and the completed time. The results are summarized in

Figure 3a, 3b, 3c, and 3d, where x axis denotes three cases, andy axis denotes the turn around time while creating honeypot.
Note that our x axis range for each box graph is limited to the
20 seconds, for readability.
When the disk size was 20 MB, we observed that the minimum average of the turn around time was 2.00 seconds in thecase of INTERCEPT+, followed by LMM with AUFS (11.72)
and finally ILBM (14.90). In order to compare the responses
in a less biased way, we performed Analysis of Variance(ANOVA) and Welch’s t-test (p < 0.05) for INTERCEPT+
and ILBM, and the result showed that there was statisticaldifference between the two turn around times in between INTERCEPT+ and ILBM (p ≒ 1.40E − 32(< 0.05), ν = 18). In
addition to the INTERCEPT+ and LMM with AUFS, there also
found statistical difference (p ≒ 7.62E − 33(< 0.05), ν = 18).
Even if the disk size was 500 MB, the minimum averageof the turn around time was 43.23 seconds in the case of
INTERCEPT+, followed by LMM with AUFS (53.22) andfinally ILBM (56.51). According to our ANOVA results, we
performed Student’s t-test (p < 0.05) for INTERCEPT+ and
ILBM and found the statistical difference (p ≒ 3.78E − 16(<0.05), ν = 11.86). There was also statistical difference between INTERCEPT+ and LLM with AUFS (p ≒ 4.00E−23(<0.05), ν = 18).
We also verified whether or not the data corruption occurred, and observed that there was no data corruption in
all cases. Aspect from these observations, INTERCEPT+
succeeded to meet our requirements, avoidance of data
corruption and migration in short time period. However, we
also found that the turn around time increases if the snapshot
file size became bigger. We will discuss this problem in
section VII-B.
B. OpenFlow-based packet forwarder
In this section we performed the results of our preliminary
evaluation. We analyzed the latency of the OpenFlow-based
forwarder system.
At first we observed the packets under the normal situationin which no attackers exist. Secondly, assuming the IP 10.0.0.1
is detected as an attacker, we observed the packets. The VM
migration takes place just when the first packet from 10.0.0.1
arrived. Then the signal is sent to the honeypot and packets
from the attacker is sent to the honeypot server. On bothsituation, we dumped packets at the client’s side. This isbecause we needed to know whether this honeypot system has
ability to hide themselves from attackers, who is at client’s
side. Of course, we verified that normal users can access to the

20
0

5

10

15

20
15
10
5
0

ILBM

LMM+AUFS INTERCEPT+ILBM(b) 50MB Snapshot

5

40

45

10

50

15

55

20

60

25

(a) 20MB Snapshot

LMM+AUFS INTERCEPT+ILBM

LMM+AUFS INTERCEPT+ILBM(c) 100MB Snapshot

LMM+AUFS INTERCEPT+(d) 500MB Snapshot

Fig. 3: The average turn around time in the cases of Incremental Live Brock Migration(ILBM), Live Memory Migration with
AUFS (LMM+AUFS), and Kemari-based Live Memory Migration with AUFS (INTERCEPT+).

real web server simultaneously even when the attacker exists
and is directed to the honeypot.
The packet dumps taken by Wireshark [29] are shown in
Figure 4. As shown in the figure, these two situation madealmost no difference. The first row from the left shows the time
the packets were observed. The value 0 stands for the sendingtime of first TCP SYN packet. The second and third rows are
the source and destination IP address respectively. The fourthis protocol. The packets for the TCP three way handshake are
TCP, and other packets related to HTTP protocol are shownas HTTP. The last row is the packet information. It shows the
SYN, ACK flags about the TCP, while HTTP methods aboutthe HTTP packets.
As a result, this system can correctly control the attack
traffic to the honeypot web server, and causes almost no

latency.
VII.

D ISCUSSION

A. Collection of attacks
Our motivation is to collect the information related tocyber attacks toward web applications using the honeypot. Thissection explains about the content of the information.
As shown in Figure 1, our concept contains detecting asuspicious request, creating a honey web server, preparing
honey database, forwarding the request to the created server,
and observing the behavior. Imagine if the request can bedetected attacks without doubt. When the attack was wellknown and contained particular phrases that cause injection
attacks, the rule-based detection can identify that the request

TIME
00.01780.01790.01800.0308Source IP
10.0.0.1
172.16.0.10
10.0.0.1
10.0.0.1
172.16.0.10

Destination IP
172.16.0.10
10.0.0.1
172.16.0.10
172.16.0.10
10.0.0.1

Protocol
TCP
TCP
TCP
HTTP
TCP

Information[SYN][SYN, ACK][ACK]GET HTTP/1.1
[ACK]

TIME
0
0.02420.02430.02430.0364

Source IP
10.0.0.1
172.16.0.10
10.0.0.1
10.0.0.1
172.16.0.10(a) Normal Packets

Destination IP
172.16.0.10
10.0.0.1
172.16.0.10
172.16.0.10
10.0.0.1

Protocol
TCP
TCP
TCP
HTTP
TCP

Information[SYN][SYN, ACK][ACK]GET HTTP/1.1[ACK](b) Attack Packets

Fig. 4: Packets dumps at client’s sideis determinately attack. In this case, the information of theattack is not so new.

and the snapshot, might be necessary to keep the size of thesnapshot to be reasonable.

Aside from the well known attacks, we want to analyze
suspicious attacks with honeypot. As we mentioned in section I, heuristics-based methods calculate the likelihood of
being a malicious code and compare the likelihood with thedefined discrimination threshold. Assuming if the calculated
score 0 means benign and 1 means attacks, and sore 0.5 is thethreshold. For example, given calculated score 0.9 (> 0.5),
it would be detected as attack rather than benign. However,even if the calculated score is 0.1, it might contain some
suspiciousness. By observing the activity during the request,
we considered that there is a potential chance for collecting
new cyber threats.

The other solution is that use of rapid migration techniques.
INTERCEPT+ needs to replicate the VM instance rather
than migration, so we need to carefully choose the suitable
techniques to avoid data corruption. As well as as Kemari’s
fault tolerant functions, which do memory migration in the
background manner, the fault tolerant functions for block disk
image might be feasible. Actually, cloud storage techniquessuch as GlusterFS [30] and/or Sheepdog [31] have the fault
tolerant features and replicate the disk images in the storage
network. By modifying their replication functions, there ispossibility for creating the perfect copy of VMs in very shorttime period even if the disk size is large.

Due to the fear of false positive, which is to label benign
request as attack, a suspicious request might not be blocked.
Instead, our approach seamlessly quarantines the suspicious
request to the honey web server. Even if the false positive
occurred, the service for the benign user of the web application
would be continued without losing any convenience when
following two conditions are met: (i) the honey web server
has the same memory and disk information of the real server,and (ii) the honey database equips the information that usedby this benign user. If the honey database has limited tables
and records that are related to the user who logged in to the
web applications, as we explained in section III, INTERCEPT+
might not penalize users’ convenience even if the false positive
error occurred.

Toward development of honeypot for web applications,
INTERCEPT+ needs to interconnect to other modules, namelydetermination modules for suspicious requests. On the integration of INTERCEPT+ and the remaining module, it needs
to define the temporal requirements. The required time fordetection, direction and preparation of honeypot might becalculated along with each requirement, but it is beyond thescope of this paper.

B. Deception ability
This section explains about deception ability. We developed
INTERCEPT+ to create a perfect copy of environment for web
applications based on virtualization techniques. To the best of
our knowledge, it would be difficult that honey web server
has the same memory of the real web server, including TCP
session state and web application session information, without
using VM.

C. Control of packets
In this section, we discuss remaining issues of the
OpenFlow-based packet forwarder. As we mentioned in section III, all IP packets are controlled by the OpenFlow protocol.
The packets of other protocols such as Address Resolution
Protocol (ARP) are treated as follows in this implementation.
ARP packets from the external connection is sent to both thereal and honey server and ARP packets from the real/honeyserver are forwarded to the external connection. This may
occur conflicts. This makes a possibility that an attacker canbe aware of something unusual.

The remain issue is time for creating the copy of VMs. If
it requires a lot of times, remote attackers will be aware ofunusual or strange behavior of the web servers.

The other issue is caused of our isolation. Since the honey
web server is isolated to the real web server and its surrounding
systems, and hence, this leads an attacker to feel different.
Even if the attacker intends to use this web server as a step
stone of other attacks, our isolation prohibits the attacker tolaunch another attack from the isolated server.

Our INTERCEPT+ was designed to reduce the time for
migration; use of Kemari and its fault tolerant feature to reduce
the time for memory migration, and use of AUFS and its copyon-write feature for live block migration. The rest of time is thetime for copy-on-write in AUFS. The creation time increases
when the size of the snapshot disk image file becomes larger.
The periodical “re-basing”, the procedure of merging the base

The way for dealing with these problems are beyond
the work of this paper. In these problems, we assumed thatthe attacker can successfully gain control for injecting OS
commands. In this case, it can be regarded that the honeypot
usually has already finished its role. From the viewpoint ofcollecting new vulnerabilities in web applications, these issue
were not critical to meet with deception ability.

VIII.

C ONCLUSION

The paper introduced INTERCEPT+, a component of thehoneypot for web applications. To meet the requirements of
the honeypot, we explored the suitable solution and discovered
the missing piece, which can avoid the data corruption as
well as finishing the migration in short time period. While
we employed server-type and high-interaction as a honeypot
architecture, the honeypot system created the perfect copy of
the actual system. Hence the honeypot had the same memoryand disk content of the actual system, web attackers would not
be aware of that they were forwarded to honeypot even they
checked any TCP and/or web sessions.

[5]

S. Cook, “A Web Developer’s Guide to Cross Site Scripting,” Availableat:
http://www.sans.org/reading-room/whitepapers/securecode/
web-developers-guide-cross-site-scripting-988, The SANS Institute,Tech. Rep., Jan 2003.

[6]

I. M. Kim, “Using Web Application Firewall to detectand block common web application attacks,” Availableat:
http://www.sans.org/reading-room/whitepapers/webservers/
web-application-firewall-detect-block-common-web-application-attacks-33831,
The SANS Institute, Tech. Rep., Nov 2011.

[7]

M. Dermann, M. Dziadzka, B. Hemkemeier, A. Hoffmann, A. Meisel,
M. Rohr, and T. Schreiber, “Best Practices: Use of Web Application
Firewalls,” The Open Web Application Security Project, Tech. Rep.,
2008.

[8]

A. Mairh, D. Barik, K. Verma, and D. Jena, “Honeypot in Network
Security - A Survey,” in Proceedngs of the International Conference
on Communication, Computing & Security, Oct 2011, pp. 600–605.

[9]

F. Pouget and T. Holz, “A Pointillist Approach for Comparing Honeypots,” in IEEE Conference on Detection of Intrusions and Malware &Vulnerability Assessment, Jul 2005.

We also surveyed several solutions of virtual machine
environments and developed our own virtual machine systems.
At first, we chose QEMU and modified its source codes,
and used the incremental live block migration for creatinghoney web server. Next, we employed AUFS instead of using
incremental live block migration in order to reduce the time forcompleting live block migration. Further, we modified Kemari
and its fault tolerance feature, to reduce the time of the memory
migration. We also observed that the creation of the honey
web server could be done in few seconds when the size of thesnapshot was reasonable.

[10] K. Lin, L. Kyaw, and P. Gyi, “Hybrid Honeypot System for Network
Security,” World Academy of Science, Engineering and Technology,
vol. 24, pp. 266–270, 2008.

We finally implemented an OpenFlow-based packet forwarder. Even if our live migration approach arose address
duplication, we verified that our implementation could forward
the packet to the suitable destination regardless of the duplicated address. We also evaluated its performance and measured
the effectiveness. The result showed that we could correctly
control the attack and normal packets to our honeypot system.

[14] C. Seifert, I. Welch, and P. Komisarczuk, “HoneyC-The Low-Interaction
Client Honeypot,” Available at http://www.mcs.vuw.ac.nz/cseifert/blog/
images/seifert-honeyc.pdf, Victoria University of Wellington, Tech.
Rep., 2006.

The rest of work is to improve the performance of ourdeveloped INTERCEPT+. There still remains the problem,i.e., the difference of the temporal requirements, but we willdevelop the suitable honeypot for web applications regarding
to the rapid migration techniques in our future work.
ACKNOWLEDGMENT
This research has been supported by the Strategic International Collaborative R&D Promotion Project of the Ministry ofInternal Affairs and Communication, Japan, and by the European Union Seventh Framework Programme (FP7/2007-2013)
under grant agreement No. 608533 (NECOMA). The opinions
expressed in this paper are those of the authors and do notnecessarily reflect the views of the Ministry of Internal Affairs
and Communications, Japan, or of the European Commission.
R EFERENCES
[1]

[2]

[3]

[4]

J. Purcell, “Web Based Attacks,” Available at: http://www.sans.org/
reading-room/whitepapers/application/web-based-attacks-2053,
The
SANS Institute, Tech. Rep., 2007.
M. Andrews, “Web Security 101 - introduction,” Available at: http://
www.mcafee.com/in/resources/audio/foundstone/websec101-intro.html,
McAfee, Tech. Rep., 2008.
OWASP, “OWASP Top 10 for 2013 - The Ten Most Critical Web Application Security Risks,” The Open Web Application Security Project,
Tech. Rep., 2013.
S. McDonald, “SQL Injection: Modes of Attack, Defence, and Why It
Matters,” Available at: http://www.sans.org/reading-room/whitepapers/
securecode/sql-injection-modes-attack-defence-matters-23, The SANS
Institute, Tech. Rep., Apr 2002.

[11] MITRE, “Honeyclient Project.”[12] The Client Honeynet Project, “Capture-HPC,” Avaiable at: http://
client-honeynet.org/.
[13] M. Akiyama, M. Iwamura, Y. Kawakoya, K. Aoki, and M. Itoh, “Design
and Implementation of High Interaction Client Honeypot for Drive-byDownload Attacks,” IEICE Transactions, vol. 93, no. B(5), pp. 1131–
1139, 2010.

[15] The Monkey-Spider project, “Monkey-Spider,” Availabel at: http://monkeyspider.sourceforge.net/.
[16] L. Spitzner, Honeypots: Tracking Hackers, 1st ed.
2002.

Addison Wesley,[17] P. Baecher, M. Koetter, T. Holz, and M. Dornseif, “The Nepenthes
Platform: An Efficient Approach to Collect Malware,” in Proceedingsof the 9th International Symposium On Recent Advances In Intrusion
Detection, Sep 2006.
[18] F. Cohen, “Deception Toolkit,” Available at: http://www.all.net/dtk/
index.html.
[19] Nmap, “Free security scanner for network exploration & security
audits,” Available at: http://nmap.org/.
[20] M. Zalewski, “p0f,” Available at: http://lcamtuf.coredump.cx/p0f.shtml.
[21] C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach,
I. Pratt, and A. Warfield, “Live Migration of Virtual Machines,” inProceedings of the 2nd Symposium on Networked Systems Design and
Implementation, May 2005.
[22] F. Bellard, “QEMU, a Fast and Portable Dynamic Translator,” inProceedings of the USENIX Annual Technical Conference, Apr 2005,
pp. 41–46.
[23] J. Sundar, “Livebackup - A Complete Solution for making Full andIncremental Disk Backups of Running VMs,” Available at: http://wiki.
qemu.org/Features/Livebackup.
[24] K. Wolf, “block: drive-backup live backup command,” Available
at: http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg04448.
html.
[25] J. R. Okajima, “Advanced multi layered unification filesystem,” Available at: http://aufs.sourceforge.net.
[26] K. Ohmura and S. Moriai, “Kemari Project,” Available at: http://www.
osrg.net/kemari/.
[27] Nippon Telegraph and Telephone Corporation, “Ryu Network Operating
System,” Available at: http://osrg.github.com/ryu, 2012.
[28] Open vSwitch, “Production Quality, Multilayer Open Virtual Switch,”
Available at: http://openvswitch.org.

[29] G. Combs, “Wireshark, Go Deep,” Available at: https://www.wireshark.
org/about.html, 2006.
[30] Gluster, Inc., “GlusterFS,” Available at: http://www.gluster.org.

[31] Sheepdog Project, “Sheepdog Project,” Available at: http://sheepdog.
github.io/sheepdog.