2019 IEEE 3rd Information Technology,Networking,Electronic and Automation Control Conference (ITNEC 2019)
SDN-based hybrid honeypot for attack capture
He Wang1,2
1.School of Computer Science, Beijing University of Posts
and Telecommunications
2.National Disaster Recovery Technology Engineering
Laboratory, Beijing University of Posts and
Telecommunications
Beijing, China
wanghe0605@bupt.edu.cn
Abstract—Honeypots have become an important tool for
capturing attacks. Hybrid honeypots, including the front end and
the back end, are widely used in research because of the
scalability of the front end and the high interactivity of the back
end. However, traditional hybrid honeypots have some problems
that the flow control is difficult and topology simulation is not
realistic. This paper proposes a new architecture based on SDN
applied to the hybrid honeypot system for network topology
simulation and attack traffic migration. Our system uses the
good expansibility and controllability of the SDN controller to
simulate a large and realistic network to attract attackers and
redirect high-level attacks to a high-interaction honeypot for
attack capture and further analysis. It improves the deficiencies
in the network spoofing technology and flow control technology
in the traditional honeynet. Finally, we set up the experimental
environment on the mininet and verified the mechanism. The test
results show that the system is more intelligent and the traffic
migration is more stealthy.
Keywords—CyberSecurity澯 Honeypot; SDN; Traffic migration;
Topology simulation
I. INTRODUCTION
Honeypot [1] is a kind of active defense technology and it
is a security tool that is expected to be attacked. It deploys
some hosts and network services to trick attackers into attack.
Then we capture attack behavior and analyze attack strategies
in honeypot to enhance security protection capabilities of
production network. Honeypots can be classified into two
categories: low-interaction honeypots (LIH) like honeyd [2]
and high-interaction honeypots (HIH) depending on the level
of interaction. A low-interaction honeypot simulating some
features, such as the network stack, is not a real operating
system, so an attacker cannot fully control the system, yet it's
easy to deploy. The high-interaction honeypot is the actual
operating system, which can have more interaction information
with the attacker. However, the high-interaction honeypot is
expensive to deploy and maintain, which is easy to cause
serious damage by attackers.
Some researchers proposed hybrid honeypot architectures
[3~5] combining the advantages of two honeypots. Hybrid
honeypots typically contain multiple front ends (low-
interaction honeypots) that can simulate tens of thousands of IP
to attract attackers and back-ends (high-interaction honeypots)
which can interact deeply with the attacker to get detailed
978-1-5386-6243-4/19/$31.00 ©2019 IEEE
Bin Wu1,2
1.School of Cyberspace Security, Beijing University of
Posts and Telecommunications
2.National Disaster Recovery Technology Engineering
Laboratory, Beijing University of Posts and
Telecommunications
Beijing, China
binwu@bupt.edu.cn
attack information. Therefore, we could analyze more valuable
traffic to strengthen the production network. However, the
traditional hybrid honeypot architecture has difficulty in
system flow control, and the physical machine deployment is
inconvenient. In the face of a changing network environment, it
is impossible to make targeted adjustments to network traffic
changes to obtain effective information.
Software Defined Networking (SDN) [6~8] is a new
network architecture designed to separate the functionality that
determines the direction of traffic (control plane) from the
underlying systems that forward traffic to selected targets (data
plane). SDN brings good traffic control and programmability to
the network, and can dynamically configure the data plane
according to the needs of network administrators. At present,
there are many researches on information security in SDN,
such as intrusion detection, but the research on honeypot is still
in its infancy, and mostly concentrate in the research of high-
interaction honeypots [9~10].
This paper gives full play to the advantages of hybrid
honeypots, and proposes a new hybrid honeypot architecture
based on SDN, which improves the shortcomings of network
spoofing technology and flow control technology in traditional
honeynet. Described as follows:
x An attack traffic migrating mechanism is proposed. It
classifies different attack types based on SDN. For low-
level attacks such as scan detection, we import into low-
interval interactive simulation groups to attract attackers,
and for high-level attacks, we need to further classify
and determine the location where the attack moved to.
At this point we implement traffic filtering and attack
directed capture.
x A network topology simulation model combining SDN
is proposed. The virtual Open vSwitch (OVS) is used to
simulate the function of the router, which increases the
network fidelity. Combined with the low-interaction
honeypot, it solves the problem of high cost of high-
interaction honeynet deployment and large-scale
simulation topology.
The structure of this paper is organized as follows: Section
2 proposes an SDN-based hybrid honeypot architecture
including attack traffic migration mechanism, topology
simulation model and topology simulation algorithm. Section 3
1602
presents the experiments and shows the testing results; finally, The cooperative relationship of each module is as shown in
section 4 presents some conclusions and suggest future work. the Fig. 2. After new attack packets reach the SDN controller,
the attack classification module which uses snort an open
II. SDN-BASED HYBRID HONEYPOT ARCHITECTURE source intrusion detection framework classifies the attack and
obtains the attack type of source IP. Snort checks the payload
The SDN hybrid honeypot architecture consists of four for the suspicious mode on the basis of its rule format, and
parts: Openflow switch and SDN controller (attack traffic outputs the alarm to the database through msg. The alarm rule
migration module), low-high interactive simulation group format is as shown in the Fig. 3. Then, the honeypot selection
(topology simulation model) and high-interaction honeypot module distinguishes the attack type according to the output
group, as shown in Fig. 1. The Openflow switch and SDN information of the msg. If the attack is low-level, such as
controller implement the attack migration mechanism to make scanning and detecting, it is forwarded to low-high interaction
decisions on attack traffic. The low-high interactive simulation honeypots by modifying the flow table to cope with the
group implements a topology simulation model that uses maximum resource saving; if it is high-level attack, the SDN
virtual OVS nodes and controllers to simulate the main controller need to judge which kind of attack is to determine
functions of the router. The high-interaction honeypot group is which specific honeypot enabled according to the configuration
configured with honeypots with specific services to record file. In this process, corresponding IP and mac addresses are
attacks and alerts. The attack traffic migration mechanism and needed to be modified in the flow table to migrate traffic to an
topology simulation model will be introduced below. environment that the attacker wants.澳
Ċ low-high interactive
Ċ simulation group

Fig. 3. Snort alarm format

LIH
topology simulation model
Topology The flow table lifecycle management module determines
management

Packet parsing/
the effective time of the flow table in the OpenFlow switch.
generation This module maintains the flow table meta information that is
HIH
Protocol
resolution in effect. Meta information includes the flow table valid time,
Virtual controller
Flow table
generation
the number of hit flow tables, and the protocol type. When a
Attacker
Openflow switch flow table exceeds the threshold set in the flow table meta
SDN controller
high-interaction information, the SDN controller deletes or changes the flow
honeypot
entry to prevent the expired flow table from affecting the
Attack traffic migration
HTTP1
normal attack and migration process.
Flow table life
Attack HTTP2
cycle
class ifi cation
management
OVS
B. SDN-based topology simulation model
Ss h1
SDN controller
OVS
topology management module
Ss h2
Routing info Device manager
Link manager
calculation
Fig. 1. SDN-based hybrid honeypot architecture Bandwid
Loss
th Timer Protocol Port

A. Attack traffic migration mechanism

The attack traffic migration mechanism mainly utilizes the Packet Protocol engine Packet
flexible data control capability of the SDN controller to paser LLDP ARP generator database
achieve the redirection of attack packets. The attack traffic is ICMP RIP
determined by the SDN controller, and the Openflow switch
forwards according to the flow table. Flow
Packet in
generator Packet out
Low level attack low-high int eractive simulation
(Scan or detect) group
Fl ow m od

Openflow switch Highly int eractive

honeypot group OpenFlow switch
Attacker
Flow1
Web attack Web honeypot
High level attack receiver Flow2 sender
SM TP attack
SM TP honeypot

SDN controller
Flown
Flow table life SSH attack SSH honeypot
cycle management
Attack Fig. 4. SDN-based topology simulation model
class ification

Honeypot selection
In the SDN hybrid honey network architecture, an SDN-
based topology simulation model is proposed in the low-high
Fig. 2. Attack trafficmigration mechanism interactive simulation group, as shown in the Fig. 4. The
Openflow switch is responsible for receiving the data layer

1603
data, packaging packet that cannot match the flow table into a
packet-in request and sending it to the controller. After the
SDN controller finishes processing, the result is returned to the
switch through the packet-out message.
The SDN controller is mainly composed of topology
management module, packet parser, packet generator, protocol
engine and flow table generator.
x The topology management module is responsible for
maintaining the virtual topology information and
managing the running topology, including the
management of the switches and the router status. The
database is used to store the port IP address, MAC
address, and mask of the virtual topology switch. And it
also stores packet loss rate and router status. The
routing info calculation module calculates the
information that should be replied according to the
content of the requested protocol and the host
information in the domain and sends the information to
the packet generator. Topology simulation algorithm is
proposed in this module, and we will introduce it in
detail in the section II-C. At the same time, the topology
manager maintains a timer, sends out a routing status
notification periodically, and generates information to
be sent on time.
x The packet parser receives the packet-in message and
invokes the protocol parser to parse the message type
and the source switch. For information needed to be
calculate, the module notifies the topology manager to
calculate and reply.
x The packet generator is responsible for invoking the
protocol parser to generate a corresponding package
according to the requirements of the topology manager
and the packet parser. The packet-out message is
delivered to the switch of the specified ID, and the
switch sends a reply packet from the designated port.
x The protocol parser is a knowledge base of the protocol
and is responsible for the format of the storage protocol.
x The flow table generator is responsible for generating a
flow table for each switch in the domain, including
intra-domain routing tables calculated by the topology
manager, data control flow tables, TTL modified flow
tables, and ARP proxy flow tables. Fow tables are sent
to switches by generating a flow-mod message.
C. Principle of topology simulation algorithm
ARP simulation: The Openflow switch is a device that
works at the data link layer, so it does not have an IP address
and cannot automatically answer ARP requests. Therefore, In
order to implement topology simulation, we must implement
ARP protocol simulation first. When the ARP request packet
enters the switch, the switch matches the ARP protocol code
(arp_op) and the ARP request destination IP address (arp_tpa)
through the ARP flow table. If the data packet matches the
arp_op and the arp_tpa is the same as the virtual IP address of
the switch port, the flow table matches successfully. Packet
generator constructs a new data packet, moving the original
1604
packet source IP (arp_spa) and MAC (arp_sha) to the
destination IP and MAC, and writing the IP and MAC of this
port to the source IP and MAC. Finally, newly constructed data
packet is returned.
ICMP simulation: The processing of the ICMP protocol by
the algorithm mainly includes two aspects: one is the most
common ICMP echo request, and the other is ICMP timeout
processing. For the ping package, the algorithm generates an
Echo reply with “Type = 0” and “Code = 0”. For packets with
TTL timeout, the algorithm generates a TTL timeout reply with
type 11 (0x0b), code 0 and the 64-byte original timeout packet.
RIP protocol simulation: The system provides a reply to the
RIP protocol. A path can only be allowed up to 15 routers in
which is suitable for small and medium-sized networks. A
timer in the controller is used to construct a RIP response
packet for each switch running RIP in the domain every 30
seconds. The controller also constructs a response packet when
receiving a RIP route request packet, which is sent to the
switch from the designated port through the packet-out
message.
III. EXPERIMENT
Mininet [11] is a lightweight software-defined network
testing platform, and supports various protocols such as
OpenFlow and OpenvSwitch. It has good hardware consistency
and high scalability, and can highly customize the network
structure. Code developed under this platform can be easily
migrated to a real environment濁 We use mininet as the
development platform, and Floodlight [12] as the SDN
controller to implement our hybrid honeypot system. Topology
simulation and attack migration modules have been added to
the original modules of Floodlight.
A. Attack traffic migration experiment
The experiment builds attack traffic migration module on
the mininet platform. We bridge the virtual NIC to the physical
NIC and connect it to a switch port, while the other port
connects to three servers that one deploys low-interaction
honeypot (192.168.216.128) honeyd simulating web services,
and the other two deploy high-interaction honeypots
(192.168.216.144/192.168.216.145) with web and sql
vulnerabilities. Fig. 5 is attack traffic migration experiment
deployment diagram.
6'1FRQWUROOHU
$WWDFNHU
 2SHQ)ORZVZLWFK
:HE VTO :HE VTO +RQH\G
  
Fig. 5. The diagram of attack traffic migration experiment deployment
First, the attacker uses the scanning tool to scan
192.168.216.128’s open ports. It is observed that port 80 is
open. Then access web services and perform sql injection
attacks. At this time, the attack traffic migrating module has
already migrating the attack traffic to the high-interaction
honeypot. We capture packets on the attacker side and the
high-interaction honeypot end respectively. It can be seen that
On the attacker side, there is no abnormality in the IP address
192.168.216.128 scan and sql injection attack, but the actual
sql injection attack packets have been redirected to
192.168.216.144.
B. Topological simulation experiment
6'1FRQWUROOHU
$WWDFNHU 5RXWHU 2SHQ)ORZVZLWFK

7RSRVLPXODWLRQVHUYHU

Fig. 6. The diagram of topology simulation experiment deployment
Fig. 6 is the diagram of topology simulation experiment
deployment. A virtual network is sent to the topology
simulation server as shown in the Fig. 7. The gateways of each
subnet are 172.16.0.1, 192.168.0.1, and 135.0.0.1. The
honeypot Host IP is 192.168.0.201~192.168.0.203,
172.16.0.201~172.168.0.203, 135.0.0.201 ~ 135.0.0.203.
Fig. 7. Virtual network topology
We use the attack test machine 10.0.0.1 to detect
172.16.0.202 before the router simulation with ping and
trancert respectively. The test results showed that there was no
response to timeout as shown in the Fig. 8 and Fig. 9.
Fig. 8. Ping result before route simulation
Fig. 9. Trancert result before route simulation
1605
After the simulation of routing, another ping is used for
capturing packets on port 20.0.0.100 of R1. As shown in the
Fig. 10 and Fig 11, the port sends routing information of four
devices to the attacking host in the domain. The ping request
was responded, and the TTL was also modified in response to
the route simulation expectations.
Fig. 10. RIP protocol reply after route simulation
Fig. 11. Ping result after route simulation
Finally, compared with the situation before the topology
simulation, the honeynet could be scanned from the angle of
the attacker. The comparison results are shown in the Fig. 12.
The functions of ARP, ICMP and dynamic protocol routing are
proved through the experiments. It can be concluded that the
system implements the topology simulation function.
Fig. 12. The results of Topology simulation before and after nmap scan
C. Performance
For performance evaluation, we designed a simple SMTP-
based test to monitor the delay of the first packet arriving at the
honeypot. An SMTP server is installed in the honeypot. The
remote attacker installed the SMTP client script, and the script
content is to send a greeting message.
The experiment built two different experimental
environments, one uses the honeybrid gateway and the other
uses the SDN controller for attack migration. Next, we run the
SMTP client script at a rate of 10 connections per second and
record the duration of the first push packet for each connection
to the honeypot. The experimental results in different cases are
shown in Fig. 13.
Fig. 13. Connection latency raised by diffirent approaches
The results of the experimental show that Honeybrid
gateway and SDN controller applications cause similar delays.
Our SDN controller requires Snort to intelligently classify,
resulting in more delay than the Honeybrid gateway that only
categorizes the IPTABLES rules. However, our honeynet
system has low delay during the attack traffic migration phase,
because we merely need to modify the openflow flow table,
avoiding replaying the TCP connection to redirect traffic, and
do it between local systems.
Fig. 14 shows a grouped I/O plot of a honeypot, which uses
different mechanisms. The selected time interval is 100ms, so
the graph represents the number of packets processed per
100ms for the honeypot. During this time, we can observe that
when we use our SDN controller application, the packet I/O is
evenly distributed. Honeybrid's packet I/O allocation is clearer
than the other. Therefore, if the opponent uses the difference in
packet I/O performance to detect redirection, our mechanism is
more invisible than the Honeybrid gateway method.
Fig. 14. Packet I/O graph of honeypot under different mechanisms
1606
IV. CONCLUSIONS
This paper proposes a new architecture based on SDN
applied to the hybrid honeypot system, combined with the
characteristics of high and low interactive honeypots for
network topology simulation and attack traffic migration. The
system can simulate a large and realistic network to attract
attackers, and redirect high-level attacks to a high-interaction
honeypot for attack capture and further analysis. The SDN
controller provides network topology simulation in the hybrid
honey network and provides high-precision data control in the
entire attack traffic migration, which improves the deficiencies
in the network spoofing technology and flow control
technology in the traditional honey network. Finally, we set up
the experimental environment on the mininet and verified the
mechanism we proposed. The test results show that the system
is more intelligent and the traffic migration is more stealthy.
In the future, we will migrate the SDN-based hybrid
honeypot architecture to the real honeypot system and improve
the test scenario.
REFERENCES
[1] M. Nawrocki, M. W¨ahlisch, C. Schmidt, T. C. andKeil, and J.
Sch¨onfelder, “A survey on honeypot software and data analysis,”
ArXive-prints, Aug. 2016.
[2] N. Provos, “A virtual honeypot framework,” in Proceedings of the 13th
Conference on USENIX Security Symposium (SSYM’04), Berkeley,
CA, USA, 2004, pp. 1–14.
[3] X. Jiang and D. Xu, “Collapsar: A vm-based architecture for network
attack detention center.” in USENIX Security Symposium, 2004, pp.15–
28.
[4] M. Bailey, E. Cooke, D. Watson, F. Jahanian, and N. Provos, “A hybrid
honeypot architecture for scalable network monitoring,” Technical
Report CSE-TR-499-04, University of Michigan, 2004.
[5] G. Portokalidis and H. Bos, “Sweetbait: Zero-hour worm detection and
containment using low-and high-interaction honeypots,” Computer.
[6] ZHENG Y R, SHI G W, LUO W B, et al. Software Defined Networking:
a New Trend of Networking [C]//Applied Mechanics and Materials.
2014:685-688.
[7] DUAN Q, ANSARI N, TOY M. Software-Defined Network
VirtualizationL:An Architectural Framework for Integrating SDN and
NFV for Service Provisioning in Future Networks[J]. IEEE Network,
2016,30(5):10-16.
[8] WOOD T, RAMAKRISHNAN K K, HWANG J,etal. Toward a
Software-Based Network:Integrating Software Defined Networking and
Network Function Virtualization[J]. IEEE Network, 2015, 29(3):36-41.
[9] HAN, Wonkyu, et al. HoneyMix: toward SDN-based intelligent
honeynet. In: Proceedings of the 2016 ACM International Workshop on
Security in Software Defined Networks & Network Function
Virtualization. ACM, 2016. p. 1-6.
[10] Kyung N Z S, Han W, Tiwari N, et al. HONEYPROXY: Design and
Implementation of Next-Generation Honeynet via SDN[C]//IEEE
Conference on Communications and Network Security (CNS). 2017.
[11] de Oliveira R L S, Schweitzer C M, Shinoda A A, et al. Using mininet
for emulation and prototyping software-defined
networks[C]//Communications and Computing (COLCOM), 2014 IEEE
Colombian Conference on. IEEE, 2014: 1-6.
[12] Project Floodlight[OL]. http://www.projectfloodlight.org/