AsIDPS: Auto-Scaling Intrusion Detection and
Prevention System for Cloud
Junchi Xing∗ , Haifeng Zhou∗ , Jinfan Shen∗ , Kai Zhu∗ , Yansong Wang† , Chunming Wu∗ and Wei Ruan‡
∗ College of Computer Science and Technology, Zhejiang University
† ZTE Corporation
‡ College of Control Science and Engineering, Zhejiang University
Email: {jcxing, zhouhaifeng, jinfanshen, zhukai7713, wuchunming, ruanwei}@zju.edu.cn,
wang.yansong@zte.com.cn
Abstract—Distributed Denial-of-Service (DDoS) attack has
been a “nightmare” for cloud. A countermeasure is to establish
an Intrusion Detection and Prevention System (IDPS) for cloud.
Nevertheless, current IDPSes fail to achieve the detection and
prevention in a flexible and lightweight way. In this paper, we
propose a novel scheme of IDPS for overcoming the above prob-
lem, termed as Auto-scaling IDPS (AsIDPS). AsIDPS is based
on Software-Defined Networking (SDN) and Docker container
technologies. It first detects abnormal traffic based on the flow
statistics collected in SDN switches in real-time. By the SDN
controller, the abnormal traffic will be directed to the created
Docker containers with Snort running on them for further
detection and clean-up. Particularly, the Docker containers can
be automatically scaled out or scaled down on demand. The Snort
will also deliver an alert to the SDN controller if it detects attack
traffic so as to perform a countermeasure if necessary. Benefitting
from the flexible network management offered by SDN and the
lightweight Docker container, AsIDPS is able to build a flexible
and lightweight defense against DDoS attack in cloud. Based on
our prototype implementation, we validate the effectiveness of
AsIDPS in defending DDoS attack, and also verify its flexibility
and lightweight.
Index Terms—Cloud, IDPS, DDoS, SDN, Docker container
I. I NTRODUCTION
Cloud computing develops rapidly in recent years owing
to its remarkable characteristics, e.g., on-demand self-service,
broadband network access, resource pooling, rapid elasticity,
and measured service [1], [2]. More and more applications
ranging from high computation-intensive applications down
to lightweight applications [3] are developed and deployed
based on cloud computing. Meanwhile, the security of cloud
computing is gradually becoming the primary barrier of its
further development. Among its security requirements, the
availability is most critical since the core function of cloud
computing is to provide on-demand services of different levels
for numerous users [4]. The primary threat to the availability
This work is supported by the National Key Research and Development
Program of China (2016YFB0800102, 2016YFB0800201), the Science and
Technology Project of State Grid Corporation of China (52110118001F), the
Key Research and Development Program of Zhejiang Province (2017C01064,
2017C01055, 2018C01088, 2018C03052), Ministry of Industry and Informa-
tion Technology of China for Testing, Solution Verification and Application
Promotion of Industrial Information Physics System and the Fundamental
Research Funds for the Central Universities (2016XZZX001-04). (Corre-
sponding Author: Wei Ruan. ruanwei@zju.edu.cn, Chunming Wu. wuchun-
ming@zju.edu.cn)
978-1-5386-2321-3/18/$31.00 ©2018 IEEE
of cloud computing is from the Denial-of-Service (DoS)
attack and its distributed version, i.e., Distributed Denial-of-
Service (DDoS) attack, making cloud service unavailable to
its intended users by draining the system or network resource
[5], [6].
A current countermeasure is to establish an Intrusion Detec-
tion and Prevention System (IDPS) inheriting both detection
and prevention capability against DDoS attack for cloud [7].
However, there are several challenges to establish an eligible
IDPS for cloud. First, since the cloud services and users are
numerous, an eligible IDPS should be transparent to them
and should not largely impact the performance of those cloud
services. Second, on account of the uncertainty of traffic in
cloud, the location and the volume of abnormal traffic could
change at any time, an eligible IDPS should be flexible to
adjust itself for accommodating the change. Third, because
DDoS attack against cloud will bring huge attack traffic,
e.g., 500 Gbps [8], and thus an eligible IDPS should be as
lightweight as possible to tackle huge attack traffic with low-
cost and quick-response characteristics.
The remarkable advantages of Software-defined network
(SDN), e.g., logically centralized control, global network view,
dynamic update of forwarding rules, and software-based traffic
analysis, bring a relatively easier way to detect and prevent
DDoS attack [9], and some SDN based methods are proposed
to overcome the above challenges, e.g., OpenSAFE [10], NICE
[11], SnortFlow [12], SDNIPS [7], DaMask [5], and [13].
However, the IDPSes mentioned above are static, lacking
the flexibility that an eligible cloud IDPS needs. In addition,
DEIDtect [14] and BroFlow [15] are able to elastically allocate
the compute resource to IDPS. Nevertheless, their flexibility
is still not satisfying because they are unable to adjust the
placement of IDPS. Moreover, none of the above works
proposes a lightweight IDPS with low-cost and quick-response
characteristics. It follows that the challenges remain till date.
In this paper, we propose a novel scheme of IDPS termed
as Auto-scaling IDPS (AsIDPS) to guard cloud against DoS
and DDoS attacks in a flexible and lightweight way. With the
aid of Chi-square test [16], it first detects abnormal traffic
based on the flow statistics collected in SDN switches in
real-time. Afterwards, according to the location and volume
of the abnormal traffic, it then creates corresponding Docker
containers (with Snort [17] running on them) to handle the
207
abnormal traffic, and the abnormal traffic will be directed by
the SDN controller to those created Docker containers. Finally,
after further process by Snort, the attack traffic among the
abnormal traffic is cleaned up, and the legitimate traffic is
directed to its original targets. The Snort will also delivers an
alert to the SDN controller when it detects attack traffic so as
to perform a countermeasure if necessary.
Benefitting from the flexible network management offered
by SDN and the lightweight Docker container, AsIDPS is
able to build a flexible and lightweight defense against DDoS
attack for cloud. The flexible characteristic of AsIDPS lies
in its ability of auto-scaling steering by the SDN controller
according to the location and the volume of abnormal traffic.
Besides, the auto-scaling capability of AsIDPS brings efficient
resource utilization. The lightweight characteristic of AsIDPS
lies in the advantages of Docker containers: rapid application
deployment, minimal overhead and easy means to manage.
These advantages make AsIDPS guarantee the low-cost and
quick-response requirement to tackle the attack in cloud.
The main contributions of this paper are as follows.
• We propose a novel scheme of IDPS to guard cloud
against DoS and DDoS attacks in a flexible and
lightweight way based on SDN and Docker container
technologies.
• We describe the components, architecture and workflow
of the proposed scheme in detail.
• We validate the effectiveness of the proposed scheme in
defending DoS and DDoS attacks, and also verify its
flexible and lightweight characteristics.
The rest of this paper is presented as follows. In Section II,
we introduce the background and related work. The proposed
AsIDPS architecture is then introduced in Section III. This is
followed by an evaluation of the proposed method in Section
IV. In Section V, we conclude the paper.
II. BACKGROUND AND R ELATED W ORK
This section gives an overview over helpful and relevant
works which contribute to our study.
A. Advantages of Container-based IDPS
The IDPSes [7], [12], [13], [15] run inside XEN VM or
OpenStack VM. However, VM consumes a great amount of
cloud resource. This leads to resource inefficiency in the VM-
based approach [18]. Container has many unique advantages,
such as rapid application deployment, portability across ma-
chines, lightweight footprint and minimal overhead, etc [19],
[20]. Docker [21] container provides so called container virtu-
alization, enabling an IDPS application and its dependencies to
run as an isolated process inside a virtual environment. We can
fix the IDPS application and its dependencies into an “image”
by the Command-Line Interface (CLI), i.e., “docker -commit”.
We adopt Snort as the IDPS application inside Docker which
can be “docker -run” based on the fixed image. In our study,
we profit from the following advantages of Docker container
to establish our IDPS:
• Rapid application deployment: The application inside
Docker is able to be created based on the pre-prepared
978-1-5386-2321-3/18/$31.00 ©2018 IEEE 208
image, simplifying the procedure of application deploy-
ment. Besides, we measured that it takes less than 0.2
second to create the IDPS application inside Docker.
Therefore, such rapid application deployment satisfies the
requirement of auto-scaling in real time.
• Minimal overhead: All container-based systems have a
near-native performance of CPU, memory, disk and net-
work [22], which provides low cost to tackle a large
volume of attack in cloud.
• Easy means to manage: All of the Docker containers are
under the control of the container daemon. Thus SDN
application is capable of adjusting the placement and
the number of Docker containers on demand by steering
container daemon via CLI.
B. Related Work
To establish the IDPS for cloud, several SDN based ap-
proaches have been proposed because of the capabilities of
SDN, which make it easy to detect and to prevent DDoS attack
in cloud environments [9]. Opensafe [10] is a system utilizing
both OpenFlow and Snort technology but the authors focus
on how to route traffic to monitoring appliances, rather than
provide a comprehensive detection and prevention solution.
NICE [11] is an SDN-based IDPS solution to deploy attack
graph, so as to dynamically generate appropriate countermea-
sures to enable the IDPS in the cloud environment. Snortflow
[12] proposed an IDPS based on the Snort tool. The Snort
agent is merged into the management domain on the XEN
hypervisor, using the network programmability enabled by
Openflow to reconfigure the whole cloud environment. SD-
NIPS [7] is an SDN-based IPS security solution in XEN cloud,
which coordinates the IPS agents in Dom 0 and Dom U by
means of the manipulation of data plane of SDN. DaMask [5]
separates the enterprises network traffic from the main network
by virtualizing the network, and uses SDN-based network
monitoring and control mechanism to control and configure
their defense mechanisms more effectively. [13] designed a
cloud platform IPS based on SDN, and implemented it on
OpenStack, combined with SDN. It further showed the result
surpasses the conventional IPS in respects efficiency and CPU
utilization. However, these IDPSes are static, lacking the
flexibility that an eligible cloud IDPS needs.
DEIDtect [14] is an elastic intrusion detection framework
that decouples the location of the protected network from IDPS
in the cloud and enterprise network. Security professional, or
the system by itself, determines the need to realize another
tap point inside the network and spin up another IDS instance
in the cloud platform to monitor this new tap point. Unfortu-
nately, this approach lacks a dynamic placement of IDPS, and
also does not consider the aspect of lightweight. BroFlow [15]
is another elastic IDPS for SDN in virtualized environment.
BroFlow uses Bro traffic analyzer and policy language for
network events. BroFlow models and proposes a heuristic
optimization on the IDPS sensor placement problem, so as
to reduce the number of sensors and maximize the network
coverage. But BroFlow is incapable of automatically updating
compute resource allocation to IDPS in real time, meanwhile
it demonstrates no characteristic of lightweight.
 III. A RCHITECTURE AsIDPS
Application 2
AsIDPS refers to an IDPS to secure cloud against DoS and Container
Controller plane SDN Controller
DDoS attacks based on SDN and Docker container. In this 4
Daemon

section, we present the high level architecture of AsIDPS. 3

First, we introduce the components that AsIDPS incorporates. 6
8

Then, we describe the architecture of AsIDPS with two 1

1
5 Snort Application
Snort Application
Docker
different attack scenarios. At last, we depict the workflow of DoS Attacker
1 Docker
Container
7 Container
AsIDPS. Distributing Switch
AsIDPS Agent
Detected Switch

A. AsIDPS Components Data plane

Detected Switch
AsIDPS Agent: It is a Docker container atop which Snort Detected Switch
Server
runs. More specifically, we set Snort as in-line mode. In this
mode, Snort first receives the abnormal traffic for detection. Legitimate User
Cloud

Upon attack traffic detected, Snort drops it and alerts AsIDPS !"#
Application. In contrast, it passes the legitimate traffic to its
Data Flows
original target. To create an AsIDPS Agent, Snort is regarded Controlling Flows

as the application of Docker container. It has already been AsIDPS

written and set, and we fix it as an image during its running Application 2

Container
time after the initialization phase. Therefore once an AsIDPS Controller plane SDN Controller Daemon
4
Agent has been deployed, the related Snort application will
3
work immediately. 8
AsIDPS Application: It is serving as the “brain” of AsIDPS, 1 Snort Application
1 5 Snort Application
Docker
running atop the SDN controller.

…
Snort Application
1 Docker
Snort Application
Container
Docker
Snort Application
Container Docker
1) Detection: AsIDPS Application obtains the global view 1
Container
Docker
Container
Container
of the network by collecting the flow statistics in the Detected DDoS Attackers
6
AsIDPS Agent
Detected Switch
Switches (switches on the edge of the network) periodically.
Data plane
Base on these flow statistics, AsIDPS Application detects Detected Switch
Distributing Switch

whether there is abnormal traffic from endusers of cloud with Detected Switch 7

the aid of Chi-square test [16]. If abnormal traffic detected,

it determines the number of the AsIDPS Agents required
in accordance with the abnormal traffic. Then it will use
CLI to steer Container Daemon to deploy serval identical
AsIDPS Agents as many as the determined number. Moreover,
AsIDPS Application will make sure that all of the required
AsIDPS Agents have been deployed successfully by checking
the returned value from the CLI.
2) Forwarding: Sequentially, the AsIDPS Application cre-
ates a brand-new switch named Distributing Switch for dis-
tributing the abnormal traffic to the AsIDPS Agents. To for-
ward the abnormal traffic, the Distributing Switch is deployed
between the Detected Switch where abnormal traffic occurs
and the AsIDPS Agents, and also links to them, respectively.
Then the AsIDPS Application installs two rules into the
Distributing Switch. Specifically, relying on multi-path routing
with group table [23], the first rule instructs the switch to dis-
tribute abnormal traffic to the AsIDPS Agents averagely. And
the second rule instructs the switch to forward the legitimate
traffic sent back by the AsIDPS Agents to the Detected Switch.
Also it installs two rules into the Detected Switch. The first
rule instructs the switch to forward the abnormal traffic to
the the Distributing Switch for further detection and clean-
up. And the second rule instructs the switch to forward the
legitimate traffic sent back by the Distributing Switch to its
original targets.
3) Countermeasure: Once the AsIDPS Application ac-
quires alerts from AsIDPS Agents, it manages the alerts [24].
Based on the managed results, the AsIDPS Application then
Detected Switch
Legitimate User
Cloud
Server
!$#
Fig. 1: AsIDPS Architecture.
takes some specific actions such as installing rules to block
the traffic from attackers.
Container Daemon: It scales out or scales down AsIDPS
Agents based on the instruction from AsIDPS Application.
B. Architecture of AsIDPS
The architecture of AsIDPS is depicted in Figure 1 with
two different attack scenarios. More specifically, a server is
deployed inside the cloud, attackers and legitimate users are
linked to it through a Detected Switches of the cloud network.
Figure 1 (a) shows a DoS scenario. AsIDPS Application
inquiries the Detected Switch attaching a DoS attacker, i.e.,
attacker-side, to collect statistics of every single entered flow,
so that it is in time to discover an abnormal situation.
Figure 1 (b) shows a DDoS scenario. In case a more
sophisticated attacker launches a DDoS attack based on low-
rate DoS attacks which can not be detected in the attacker-
side. For this purpose, AsIDPS Application collects statistics
of all the flow in the Detected Switch targeting the server, i.e.,
server-side.

978-1-5386-2321-3/18/$31.00 ©2018 IEEE 209

C. Workflow of AsIDPS
We depict the workflow of AsIDPS in Figure 1.
(1) AsIDPS Application collects the flow statistics in De-
tected Switch periodically.
(2) AsIDPS Application sends a instruction to Container
Daemon for scaling. The instruction specifies the number of
AsIDPS Agents requiredto in accordance with the abnormal
traffic.
(3) Container Daemon creates AsIDPS Agents according to
the the received instruction.
(4) Container Daemon informs AsIDPS Application that the
required AsIDPS Agents have been deployed successfully.
(5) AsIDPS Application creates a Distributing Switch and
installs rules into it.
(6) AsIDPS Application installs rules into the related De-
tected Switch.
(7) The abnormal traffic from the Detected Switch will be
forwarded to AsIDPS Agents through the Distributing Switch.
Then the legitimate traffic sent back by AsIDPS Agents will
be forwarded to the Detected Switch, in turn, and will be
forwarded to its original targets.
(8) The AsIDPS Agents deliver alerts to AsIDPS Applica-
tion so to perform further countermeasures.
IV. E VALUATION
In this section, we evaluate AsIDPS by simulations. We
show that:
1) AsIDPS is effective against DoS and DDoS attacks and
is transparent to legitimate users in cloud as well.
2) Facing different scenarios, AsIDPS is flexible to scale
out or scale down its AsIDPS Agents accordingly.
3) AsIDPS is lightweight, characterized by quick-response
and low-cost while tackling attack.
Here we briefly describe our testbed, topologies, and attack
configurations:
• Testbed: For the experiments we used a server with 16GB
of memory and Intel 4-core i5-5287u 2.0GHz processors,
running Ubuntu 16.04. We used Docker containers to sim-
ulate the endusers of cloud. The containers are linked by
OpenvSwitches to construct a Docker cloud environment
(the data plane of SDN). And we adopted Ryu [25] as
the controller to construct the control plane.
• Topologies: Experimental network topology is designed
based on a canonical tree [26], as shown in Figure 2.
Inside the cloud, one legitimate server provides web
services for endusers. The endusers include one legitimate
user, one DoS attacker and 100 DDoS attackers.
• Attack traffic: Using Hping3 [27] tool, both DoS and
DDoS attackers are able to perform SYN flooding attack
to the server.
• Legitimate traffic: And we used Scapy tool [28] to craft
requesting packets with complete three handshakes for
simulating traffic of legitimate users.
A. DoS Attack
1) Scenario of DoS Attack: We first measured the effec-
tiveness of AsIDPS against a simple DoS attack. Based on
978-1-5386-2321-3/18/$31.00 ©2018 IEEE 210
[29], we obtained that the requesting rate for a popular web
site is usually less than 10 requests/s. Thus in this scenario,
we made the DoS attacker launch attack to the server at the
rate of 10 packets/s. The relationship between paths and ports
inside the Detected Switch is shown as Figure 3.
We measured the flow statistics of Switch A which serves
as the Detected Switch for the DoS attacker. Figure 4 shows
the rate of flows varying with time.
From time 0 to t1, attack traffic enters Switch A via port 1,
then it is forwarded to port 2 based on predefined flow rules.
Thus the blue curve indicates the rate of the attack traffic. Note
that, the rate of the attack traffic has been around 10 packets/s,
which means the attack has been carried out.
From time t1 to t2, indicated by the red curve, the rate
of the traffic from port 1 is forwarded to port 3 at the rate
around 10. This means according to the latest rule installed by
the AsIDPS Application, the AsIDPS Agents have been auto-
scaled out and the abnormal traffic is forwarded to AsIDPS
Agents successfully. After the traffic cleaning up by AsIDPS
Agents, the remaining legitimate traffic indicated by the green
curve, will be sent back to port 4 of Switch A and be forwarded
to port 2 as predefined at a low rate. As depicted in Figure 4,
the rate of abnormal traffic is greatly reduced, validating the
effectiveness of AsIDPS.
From time t2 to t3, the traffic from port 1 is blocked, so that
there is no flow from port 1 existing in Switch A. However,
the flow of port 4 to port 2 exists because the AsIDPS Agents
still work. At time t3, AsIDPS Agents start to be scaled down,
so that the flow of port 4 to port 2 disappears.
2) Scenario of Legitimate Flash Crowd: Next, we used
flash crowd to show the transparency of AsIDPS to legitimate
traffic as a pairwise test to the scenario aforementioned. Flash
crowd is legitimate traffic but showing the characteristic of
attack traffic. So that such traffic is regarded as abnormal traffic
which will be directed to the AsIDPS Agents. In this scenario,
we made the legitimate user send packets with complete three
handshakes to the server at the rate of 10 packets/s.
We measured the flow statistics of Switch B which serves
as the Detected Switch to the legitimate user. Figure 5 shows
the rate of flows varying with time. From time 0 to t1, the
blue curve indicates the rate of the flash crowd. From time t1
to t3, the rate of the flow leaving port 3 (the red curve) and
the flow entering port 4 (the green curve) are approximately
same, which shows that the AsIDPS Agents have cleaned up
no legitimate traffic. At time t3, the rate of the traffic has been
back to normal, then AsIDPS Agents start to scale down, and
the traffic (the blue curve) is forwarded based on predefined
flow instruction.
3) Flexibility of AsIDPS: Furthermore, we counted the
number of AsIDPS Agents of the two scenarios above, as
Figure 6 illustrates. At time t1, AsIDPS scales out in both
scenarios. However, the time for scaling down reflects to the
significant difference. At time t2, AsIDPS starts to scale down
in the the DoS scenario because it has been blocked the attack
traffic and needs no AsIDPS Agents anymore. While at time
t3, AsIDPS starts to scale down in the legitimate flash crowd
scenario because the rate of the traffic has been back to normal.
 Core

Aggregation

Edge
Switch A Switch B Switch C

… … … … …
1 Legitimate Server
{
{

{
{
{
1 DoS 1 Legitimate User
Attacker
20 DDoS 20 DDoS 20 DDoS 20 DDoS 20 DDoS
Attackers Attackers Attackers Attackers Attackers

Fig. 2: Experimental network topology.

Snort Application
Docker 20
Container Flow: Port 1 to Port 2
Flow: Port 1 to Port 3
15 Flow: Port 4 to Port 2

Distributing Switch Rate(packet/s)

Port 3 Port 4 10

Port 2(DoS Scenario) t1 t2 t3

Port 1(DoS Scenario)
Port 2(DDoS Scenario) Port 1(DDoS Scenario) 5
Detected Switch

Abnormal traffic 0
0 5 10 15 20 25 30
End User Server Time(s)

Fig. 3: Relationship between paths and ports. Fig. 5: Rate of flow while legitimate flash crowd.

20 10
Flow: Port 1 to Port 2 DoS Attack
Flow: Port 1 to Port 3 Flash Crowed
15 Flow: Port 4 to Port 2
# of IPDS Agent
Rate(packet/s)

10 5
t1 t2 t3
t1 t2 t3
5

0 0
0 5 10 15 20 25 30 0 5 10 15 20 25 30
Time(s) Time(s)
Fig. 4: Rate of flow while DoS attack. Fig. 6: Number of AsIDPS Agents.

B. DDoS Attack t2, AsIDPS Agents start to detect and clean up attack traffic.
1) Scenario of DDoS Attack: As for DDoS attack, based It is clearly that AsIDPS can tackle a DDoS attack of 500
on [30], the average attack rate is 500 packets/s. Therefore we packer/s effectively within 30 seconds. It means that AsIDPS
made each DDoS attacker launch an attack to the server at the covers the characteristic of responsive.
rate of 5 packets/s, and the total rate is 500 packets/s. Also 2) Resource consumption: We chose the CPU consumption
we made the legitimate user send packets to the server at the as a reference measure. For keeping the normal operation of
rate of 2 packet/s. We measured the rate of flow in Switch C. the testbed, the upper bound of the CPU consumption is set
As Figure 7 shows, at time t4, there is only the traffic from below 50%. We adjusted the rate of DDoS attack and measured
the legitimate user left. Unlike the scenario of DoS attack, at the CPU consumption. Figure 8 shows AsIDPS can handle a
time t1, AsIDPS Agents start to be scaled out, and until time large number of DDoS packets without consuming too much

978-1-5386-2321-3/18/$31.00 ©2018 IEEE 211

 [7] T. Xing, Z. Xiong, D. Huang, and D. Medhi, “Sdnips: Enabling software-
800 defined networking based intrusion prevention system in clouds,” in
Flow: Port 2 to Port 1 International Conference on Network and Service Management, 2015,
Flow: Port 2 to Port 3 pp. 308–311.
600 Flow: Port 4 to Port 1 [8] A. Networks, “Worldwide infrastructure security report volume xi,”
Rate(packet/s)

https://www.arbornetworks.com/images/documents/WISR2016 EN
Web.pdf, 2015.
400 t2 t4 [9] Q. Yan, F. R. Yu, Q. Gong, and J. Li, “Software-defined networking
t1 t3
(sdn) and distributed denial of service (ddos) attacks in cloud computing
environments: A survey, some research issues, and challenges,” IEEE
200 Communications Surveys and Tutorials, vol. 18, no. 1, pp. 602–622,
2016.
[10] J. R. Ballard, I. Rae, and A. Akella, “Extensible and scalable network
0 monitoring using opensafe,” in Internet Network Management Confer-
0 5 10 15 20 25 30 ence on Research on Enterprise NETWORKING, 2010, pp. 8–8.
Time(s) [11] C. J. Chung, P. Khatkar, T. Xing, J. Lee, and D. Huang, “Nice: Network
intrusion detection and countermeasure selection in virtual network
Fig. 7: Rate of flow while DDoS attack. systems,” IEEE Transactions on Dependable and Secure Computing,
vol. 10, no. 4, pp. 198–211, 2013.
[12] T. Xing, D. Huang, L. Xu, C. J. Chung, and P. Khatkar, “Snortflow:
A openflow-based intrusion prevention system in cloud environment,”
in Second Geni Research and Educational Experiment Workshop, 2013,
50 pp. 89–92.
[13] Y. Chi, T. Jiang, X. Li, and C. Gao, “Design and implementation of cloud
CPU Consumption(%)

40 platform intrusion prevention system based on sdn,” in 2017 IEEE 2nd

30
20
10
0 munications, vol. 71, no. 11-12, pp. 595–605, 2016.
0 500 1000 1500 2000
Attack Rate(packet/s)
Fig. 8: CPU consumption while DDoS attack.
resource.
V. C ONCLUSION
In this paper, we have proposed a novel scheme of IDPS for
cloud, and term it as Auto-scaling IDPS (AsIDPS). AsIDPS is
based on SDN and Docker container technologies. Benefitting
from the flexible network management offered by SDN and
the lightweight Docker containers, AsIDPS is able to build
a flexible and lightweight IDPS against DDoS attack in the
cloud. Particularly, the Docker containers can be automati-
cally scaled out or scaled down on demand. Based on our
prototype implementation, we have validated the effectiveness
of AsIDPS in defending DDoS attack, and also have verified
its flexibility and lightweight.
R EFERENCES
[1] G. Pallis, “Cloud computing: The new frontier of internet computing,”
IEEE Internet Computing, vol. 14, no. 5, pp. 70–73, 2010.
[2] P. Mell and T. Grance, “The nist definition of cloud computing,”
Communications of the Acm, vol. 53, no. 6, pp. 50–50, 2011.
[3] M. Almorsy, J. Grundy, and I. Mller, “An analysis of the cloud
computing security problem,” arXiv preprint arXiv:1609.01107, 2016.
[4] Z. Xiao and Y. Xiao, “Security and privacy in cloud computing,” IEEE
Commun. Surveys Tuts., vol. 15, no. 2, pp. 843–859, 2013.
[5] B. Wang, Y. Zheng, W. Lou, and Y. T. Hou, “Ddos attack protection in
the era of cloud computing and software-defined networking,” Computer
Networks, vol. 81, no. C, pp. 308–319, 2015.
[6] L. D., “As cloud use grows so will rate of ddos attacks.” InfoWorld.
February 5th, 2013.
International Conference on. IEEE, 2017, pp. 847–852.
[14] P. K. Shanmugam, N. D. Subramanyam, J. Breen, C. Roach, and J. V. D.
Merwe, “Deidtect: towards distributed elastic intrusion detection,” in
Proceedings of the 2014 ACM SIGCOMM workshop on Distributed
cloud computing, 2014, pp. 17–24.
[15] M. A. Lopez, D. M. F. Mattos, and O. C. M. B. Duarte, “An elastic
intrusion detection system for software networks,” Annals of Telecom-
2500 3000 [16] F. Y. Leu and I. Lin, “A dos/ddos attack detection system using
chi-square statistic approach,” Journal of Systemics Cybernetics and
Informatics, vol. 8, no. 2, 2010.
[17] Snort, https://www.snort.org/.
[18] S. He, L. Guo, Y. Guo, C. Wu, M. Ghanem, and R. Han, “Elastic
application container: A lightweight approach for cloud resource pro-
visioning,” in IEEE International Conference on Advanced Information
NETWORKING and Applications, 2012, pp. 15–22.
[19] D. Liu and L. Zhao, “The research and implementation of cloud comput-
ing platform based on docker,” in International Computer Conference
on Wavelet Active Media Technology and Information Processing, 2015,
pp. 475–478.
[20] K. T. Seo, H. S. Hwang, I. Y. Moon, O. Y. Kwon, and B. J. Kim, “Per-
formance comparison analysis of linux container and virtual machine
for building cloud,” in NETWORKING and Communication, 2014, pp.
105–111.
[21] Docker, https://docs.docker.com/.
[22] M. G. Xavier, M. V. Neves, F. D. Rossi, T. C. Ferreto, T. Lange, and
C. A. F. De Rose, “Performance evaluation of container-based virtual-
ization for high performance computing environments,” in Euromicro
International Conference on Parallel, Distributed and Network-Based
Processing, 2013, pp. 233–240.
[23] Lab: OpenFlow Multiple Path at kvm in GNS3, http://suhu.dlinkddns.
com/Howto-Install/OpenFlow-MultiplePath.html.
[24] E. M. Chakir, Y. I. Khamlichi, and M. Moughit, “Alert management for
snort ids using pattern matching,” in International Workshop on New
Services and Networks Wnsn, 2016.
[25] Ryu, http://ryu.readthedocs.io/en/latest/index.html.
[26] M. Al-Fares, A. Loukissas, and A. Vahdat, “A scalable, commodity data
center network architecture,” 2008, pp. 63–74.
[27] Hping3, http://www.hping.org/.
[28] Scapy, http://www.secdev.org/projects/scapy/.
[29] S. Yu, Y. Tian, S. Guo, and D. O. Wu, “Can we beat ddos attacks in
clouds,” IEEE Transactions on Parallel and Distributed Systems, vol. 25,
no. 9, pp. 2245–2254, 2014.
[30] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and S. Savage,
“Inferring internet denial-of-service activity,” Acm Transactions on Com-
puter Systems, vol. 24, no. 2, pp. 115–139, 2006.

978-1-5386-2321-3/18/$31.00 ©2018 IEEE 212