Entropy-based denial-of-service attack detection ... - Wiley Online Library

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 Published online 3 August 2015 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/cpe.3590

SPECIAL ISSUE PAPER

Entropy-based denial-of-service attack detection in cloud data center Jiuxin Cao1,2,*,† , Bin Yu1,2 , Fang Dong1,2 , Xiangying Zhu1,2 and Shuai Xu1,2 2 Key

1 School of Computer Science and Engineering, Southeast University, Nanjing, Jiangsu 210096, China Laboratory of Computer Network and Information Integration (Southeast University), Ministry of Education, Nanjing, Jiangsu, 210096, China

SUMMARY Cloud data centers today usually lack network resource isolation. Meanwhile, it is easy to deploy and terminate large number of malicious virtual machines in a few seconds, while the administrator is probably difficult to identify these malicious virtual machines immediately. These features open doors for attackers to launch denial-of-service (DoS) attacks that target at degrading the quality of cloud service. This paper studies an attack scenario that malicious tenants use cloud resources to launch DoS attack targeting at data center subnets. Unlike traditional data flow-based detections, which heavily depend on the pattern of data flows, we propose an approach that takes advantage of virtual machine status including CPU usage and network usage to identify the attack. We notice that malicious virtual machines exhibit similar status patterns when attack is launched. Based on this observation, information entropy is applied in monitoring the status of virtual machines to identify the attack behaviors. We conduct our experiments in the campus-wide data center, and the results show our detection system can promptly and accurately response to DoS attacks. Copyright © 2015 John Wiley & Sons, Ltd. Received 26 May 2015; Revised 4 July 2015; Accepted 16 June 2015 KEY WORDS:

cloud data center; DoS attack; information entropy; attack detection

1. INTRODUCTION Cloud computing emerges as an attractive model because it offers relatively unlimited computing and network resources. The cost mainly depends on the usage and demand. The resulting on-demand model of computing allows providers to achieve better resource utilization through statistical multiplexing and avoids the costs of resource over-provisioning through dynamic scaling [1]. While the economic case for cloud computing is compelling, the security challenges it poses are equally striking. Security has emerged as arguably the most significant barrier to faster and more widespread adoption of cloud computing [1]. Based on the fact that computation, storage, and network resources are shared in the cloud, adversary may take advantage of this sharing environment to launch attacks against the confidentiality, integrity, availability, and accountability of the service. Denial-of-service (DoS) attack now is a major security risk in cloud computing environment. Cloud security alliance has pointed out that DoS ranks fifth among cloud threats in the year 2013 [2]. Many prior studies like [3–5] have been carried out on defense of the traditional DoS attack, while this paper focuses on the DoS attack that takes vulnerability of sharing network in cloud environment. The adversary can find the bottleneck and saturate it, as a result, the network performance of *Correspondence to: Jiuxin Cao, School of Computer Science and Engineering, Southeast University, Sipailou, Nanjing, China, 210096. † E-mail: [email protected] Copyright © 2015 John Wiley & Sons, Ltd.

5624

J. CAO ET AL.

this bottleneck deteriorates, hence affecting other virtual machines (VMs) within this subnet. This kind of attack is practical because of the following three reasons. Firstly, data center network is typically grossly under-provisioned [6], typical designs are under-provisioned by a factor of 2.5:1 to 8:1 [7]. Secondly, network, similar to CPU and memory, is critical and shared resource in the cloud. However, unlike other resources, it is more difficult to share, because the network allocation of a VM X depends not only on the VMs running on the same machine with X but also on the other VMs that X communicates with and the cross traffic on each link used by X [8]. Thirdly, the VMs in the cloud are easy to be deployed and terminated. As cloud provides a convenient way for tenants to create identical (in terms of hardware resource) VMs, it is able to deploy and terminate malicious VMs in a few seconds. The network topology we studied is shown in Figure 1. It is a typical architecture of today’s data center, which consists of either two-level or three-level trees of switches or routers [9]. Subnets of R3, R4, R5, and R6 consist of switches and 20–40 servers, which are the edges of the network [9]. R3, R4, R5, and R6 are called aggregation routers as they connect terminal equipment with core network. The function of this layer is to bridge core routers with edges of the network. Even though current network architecture supports multipath routing with Equal-cost multi-path routing (ECMP) [10], the number of paths supported is typically small [6]. R1 and R2 are called core routers as these routers connect all the aggregation routers together to form the whole network. For simplicity, we assume that the core routers have 10-Gbps ports; aggregation routers have 10 Gbps for uplink and 1 Gbps for downlink; and servers and switches have 1-Gbps ports. Uplinks of routers R3, R4, R5, and R6 are easily saturated as uplink capacities are much smaller than the aggregate subnet capacity. Adversary may fill these bottlenecks with large amount of data flows to degrade the service quality. For example, links a and b are considered as the attack targets. To saturate links a and b, the adversary employs some VMs, which run on server Hl to Hm in R3’s subnet (here, we use the term subnet loosely, in this paper, we refer the hosts that indirectly connect to a router as part of the subnet of the router), then sends enough data from R3’s subnet to any other subnets (e.g., R4 and R5). After links a and b are saturated, little legitimate traffic will reach the hosts in R3’s subnet, as a result, service quality in subnet R3 degrades a lot, this kind of attack has pervasive impacting on the whole subnet, as VMs are in a fate-sharing environment. Based on the fact that malicious VMs should send packages to the bottleneck at the same time, it is obvious that malicious VMs present similar status patterns when the attack is launched. We apply information entropy in monitoring the status of a cluster of VMs to identify attacks. Unlike data flow-based DoS detection addressed in [11] and [12], our approach does not need to investigate each data package and thus avoids the disadvantages of data package analysis, which usually has high response latency, high workload, and high false positive rate. Our study is based on a real data

Figure 1. Data center topology. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5625

center, which uses OpenStack suite [13] as its cloud management tool. The main contributions of this paper are summarized as follows.  Study the DoS attacks launched by malicious tenants that target at cloud data center bottlenecks within real cloud environment based on OpenStack.  Propose a detection mechanism that applies VMs’ status including CPU and network usage to identify DoS attack in data center.  Implement an entropy-based DoS attack detection system. Within the real cloud environment, we evaluate the performance of our model and demonstrate that information entropy can be applied to distinguish malicious VMs. The remainder of this paper is organized as follows. Section 2 discusses related work and background. Sections 3 and 4 introduce methods we apply to detect the attacks. The architecture of attack detection system and experiments are discussed in Sections 5 and 6. Section 7 closes the paper with conclusion and perspectives for future work. 2. RELATED WORK AND BACKGROUND Recently, sharing the cloud network resource has been studied by many papers. Guo et al. [14] and Chen et al. [15] address the issue of bandwidth allocation in cloud data center. Although allocation policies have been proposed and have good performance with legitimate requests, they do not have a good tolerance of attack, where adversary can easily find the vulnerabilities and attack the network. Data flow analysis applied in DoS attack detection is proposed by the authors in [16–20]. However, they share the common defects of data flow analysis on DoS attack detection like large response latency, high workload, and low efficiency in cloud environment. Yu et al. [11] demonstrate that information entropy theory has a number of advantages over data flow-based DoS attack detection— it is efficiently scalable, robust against packet pollution, and independent of attack traffic patterns [11]. Furthermore, we demonstrate that information entropy can also be applied to analyze cloud data center VMs’ status. Liu [6] discusses the practicability of launching this form of DoS attack in detail. An improved probe gap model called loaded spread pair estimator is proposed to estimate the bandwidth. When the insufficient of the bandwidth is detected, the affected applications will migrate to the other subnets. However, their approach does not prevent the attack from the source. Because the VM assignment algorithm may change over time and it is different across cloud vendors, Liu’s [6] results show that it is still weak at preventing high-frequency attack that targets at different subnets. Francois in paper [12] applies MapReduce to analysis IP flow. Although the MapReduce algorithm is time saving, three defects can be concluded. Firstly, the deployment of MapReduce and employing so many servers to do the traffic analysis are cost prohibitive. Secondly, the system may have a relatively high response latency, as it should collect enough IP flow before the attack is identified. Thirdly, the performance of the system heavily depends on the attack feature, as the target of attack can be any VM within the subnet, it is more difficult to distinguish the attack flow from benign traffic. To identify this kind of DoS attack is not easy. Firstly, to provide secure environment for the tenants and monitor all the traffic on aggregation and core routers is unpractical in cloud data center. As the attack patterns vary from each other, there does not exist a detection algorithm suitable for all patterns. Although MapReduce [12] is proposed to analyze the traffic, the cost to deploy this system on most of the routers is unreasonable. Secondly, this kind of attack is easy to be deployed and terminated. The adversary can pretend as a legitimate tenant and create the optimal VM it needs for launching the attack and then clone this malicious VM as many as he needs. After finishing the attack, the adversary can terminate all the VMs and tear down the links to the victim bottleneck. As the IP addresses are shared among tenants, even with system log, it is difficult for the administrators to identify the adversary. Thirdly, it is difficult to trace the attack. Because the target of this DoS attack is network bottleneck, the destination of target flow can be any host, which is in target subnet. For instance, in Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5626

J. CAO ET AL.

Figure 1, an adversary wants to degrade the quality of a web service in R3’s subnet, he would firstly employ some VMs running on Hl, Hn, Hm, or Hk in R3’s subnet. Then he sends enough data to any host in R4, R5, and R6. As the attacker sends data to different destinations, it is difficult for traditional flow analysis-based detection system to identify the attack. The method proposed by Yu et al. [11] shows low efficiency in this scenario. Compared with the aforementioned approaches, the advantages of our approach can be addressed in three aspects: (1) Our approach has no overhead gain on network infrastructures (e.g., routers, switches, and gateways) as there is no need to sample data flows from network infrastructures. (2) Our approach is swift, as problem scale of hundreds of VMs’ status analysis is much smaller than that of thousands of data flows pattern analysis. (3) Our approach is more effective. As we judge the malicious VMs by their status, we get rid of vulnerability that malicious VMs forge plenty of data flows with different IP source addresses. 3. ENTROPY-BASED DENIAL-OF-SERVICE ATTACK DETECTION MODULE A typical network structure of cloud environment is shown in Figure 2. A subnet consists of a network node, some compute nodes and switches. Different subnets are linked through network nodes. Three communication scenarios exist. The first is that VMs communicate with VMs on the same compute node (VMs communicate within subnet 1’s left box). Under this scenario, the network bandwidth is shared with VMs that communicate within the same compute node. The second is that VMs communicate with VMs residing on different compute nodes but in the same subnet (VMs communicate between the left and middle boxes within subnet 1). In this scenario, network bandwidth is affected by the local switch, that is to say, in terms of network, VMs on different compute nodes are independent from each other. The last is that VMs in subnet 1 communicate with VMs in subnet 2, and thus, all the traffic should go through the network node. Obviously, network node under this scenario could be the DoS attack target, as the over subscription is common in network node. To adopt entropy-based DoS attack detection, three preconditions should be satisfied.  The number of VMs within a subnet is large enough.

Figure 2. Cloud network topology. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5627

 The proportion of malicious VMs within a subnet is large enough.  Per-VM status is stable for a given time interval. When applying information entropy to describe the subnet running status, the number of VMs should be large enough because information entropy is a statistic methodology. The number of VMs has significant impact on the detection system performance. According to our observation, if the number of VMs is less than 30, the detection system cannot work properly. Fortunately, with conventional network architectures and protocols, a single layer 2 domain has about a few hundred servers in IP subnet [21]. Meanwhile, to make full use of computation and network resources, cloud service providers trend to aggregate VMs in one subnet. If the scale of subnet is relatively small, an approach to make up this shortage is that we sample the subnet’s VMs multi-times as one entropy calculation epoch. We will demonstrate the effectiveness of this approach in Section 6. The proportion of malicious VMs is another factor that affects the detection system. Small malicious VMs’ proportion leads to small entropy variation. If the entropy variation is not obvious enough, the system cannot distinguish the attack from the data center status-normal fluctuation. In other words, too small malicious VMs’ proportion generates false positive and false negative. In a commodity data center, aggregate router has 10-Gbps bandwidth that aggregates and transfers packets between the leaf switches [9], and the bandwidth of VMs in commodity cloud ranges from 220 to 820 Mbps [22–25]. Based on these facts, we believe that even with large background traffic, the proportion of malicious VMs to launch an effective DoS attack must surpass 10%. It is obvious that malicious VMs have similar running status because these VMs should send packages at the same time to saturate the bottleneck. As the cloud resource is shared among different tenants, and different tenants assign different tasks on different VMs, it is obvious that different nonattack VMs have different running status. Take network traffic volume for example, after intensive experiments, Meng et al. [26] address the uneven distribution of traffic volumes from VMs, that is to say, volume traffic is quite different among different tenants, the traffic pattern is basic consistent with its business pattern. The stability of per-VM traffic has also been proved by Meng et al. [26]. They address that 82–92% of VMs, no less than 80% of the entire set of time intervals, are stable, which means for a given VM, the traffic volume has its own fluctuation idiosyncrasy. Furthermore, we figure out that not only per-VM traffic but also per-VM status is stable in a large timescale. The stability of per-VM status ensures that the false positive rate varies in a small range. Overall, these three preconditions hold in most of modern data centers. We denote a status tuple S t at on the monitored subnet by < CP Uu ; IOu ; NETu ; t >, where CP Uu , IOu , and NETu are the variables of the VM’s CPU usage, IO, and network throughput of the VM, respectively, and t is the current time stamp. In cloud data center, as we sample CPU usage every second, CP US 2 [0; 1000] means that CPU usage varies from idle statue 0 ms in the sample interval to full use in the sample interval. For example, CP Us D 400 means that in 1 s, the CPU consumes 400 ms for calculation and the rest 600 ms for standby. IOu 2[0; Mi o ] means that Input/output (IO) throughput varies from 0 Mbit/s to Max Mbit/s. NETu 2 [0; Mnet ] means that net interface throughput varies from 0 KB/s to Max KB/s. The maximal IO and network interface throughputs are determined by subnet and compute nodes configurations. It is observed that different types of VMs have different S t at . We investigate some typical applications that run on VMs and obtain Table I. Table I shows that different applications have different Table I. Stat of different application VMs. Type Science computing Web service Web download service File service Mail service DoS attack

CPU

Network

Disk IO

Very high Medium High Low Low Low

Burst traffic Low High High Low Very high

Medium Low High Medium Low Very low

VMs, virtual machines. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5628

J. CAO ET AL.

S t at , which gives a way to use S t at to identify malicious VMs from monitored subnets, and it is critical to work out a parameter that takes advantage of S t at for entropy calculation. Let N be the network throughput NETu and C be the CPU usage CP Uu . We denote ˇ as N=C . Three reasons can be concluded to take ˇ as VMs’ status measurement. First, we investigate network status in the data center and find CPU usage and network throughput that are direct parameters to reflect the VMs’ status. Employing unnecessary parameters like IO throughput may confuse the attack identification system. In our experiment, we have observed that IO throughput is not accurate enough to represent the File Transfer Protocol (FTP) server workload, as FTP server may cache the popular data in memory. Second, using single parameter may induce misjudgment. Based on our observation, we find that compared with file transfer server, pure web server usually has higher CPU usage, however relatively low network throughput. It can be seen that with the growth of amount of current visitors, the CPU usage time climbs up in web server scenario; however, in file transfer scenario, direct memory access would take most of the workload, and the increase of CPU usage time does not ascend obviously with the growth of visitors. Using single parameter to measure these quite different scenarios is not reasonable. Third, from ˇ, we can figure out the different application scenarios in data center. For non-standby VMs, if ˇ is low, we can classify this VM as CPU intensive. On the other hand, high ˇ indicates network-intensive applications. VMs with relatively low ˇ have rare possibility to be the malicious VMs in our scenario, as malicious VMs unlikely send few data with relatively high CPU usage, so VMs with high ˇ have high possibility to be identified as malicious VMs. In the following paragraphs, we demonstrate how ˇ is applied for entropy calculation. For a given time t , we denote Bt as the set of ˇ Bt D ¹ˇvm1 ; ˇvm2 ; : : : ; ˇvmn º

(1)

We denote ˇvm1 to ˇvmn as ˇ from the first VM to the last VM in the subnet and t as the time stamp of B, as different applications running on different VMs and thus ˇvmi have high possibility to be quite different from ˇvmk . it is defined as the interval to classify ˇ into different groups, and the set of i is denoted as I I D ¹i1 ; i2 ; : : : ; in ; ih º

(2)

We denote n as the number of elements in I . Let ik be an element in I , where k 2 Œ1; n, and we define ik D ¹x j a < x 6 bº, where a and b are the lower and upper bounds of the given interval, respectively. ih is called the hidden interval, few non-attack VMs fall into this interval. Hidden interval is not calculated in DoS attack, thus to amplify the entropy variation when under attack. In DoS detection system, the rule to design intervals is letting ˇ distribute more evenly among each interval except ih in non-attack scenario. In other words, the number of ˇ in each i except ih should trend to be the same. In non-attack scenario, the even distribution of ˇ can maximize the entropy in non-attack scenario, as a result, the detection system can identify the small-scale attack more easily. Based on our experiment, two phenomenon can be observed. First, for a given time scale, the status of non-attack VMs is stable. Second, most of the VMs have different ˇ at different time of day, this phenomenon can be explained by variation of VM load at different time. At daytime, most of the VMs have high network throughput, while during the period between late at night (after 2:00 AM) and before dawn (before 5:00 AM), the network throughput is relatively low. We take different sample sets, which represent different time of day, to work out the parameters of each interval that let each non-attack VM be distributed evenly in i, and apply that I we obtain from sample sets to entropy calculation. The boundary of each interval i can be determined as follows. Firstly, we sort Bt in ascending order. In our data center, we filter out VMs that have ˇ < 15, we denote k, m as the number of element in I and the number of element in Bt , so the expected number of ˇ in each interval is m=k. We split the ordered Bt into k groups. In each group, as ˇ is in ascending order, so the lower bound is the value of the first ˇ in its group, and the upper bound is the value of the last ˇ in its group. It is obvious that VMs in data center are stable, so the parameter we obtained can be applied Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5629

to classify VMs’ status into different categories. For the hidden interval ih , the lower bound is the value of the last ˇ in ordered Bt , and the upper bound can be set as the infinity (the ˇ that is larger than any VMs in this data center could have). Let nk be the number of ˇ that falls in interval k, we define nk as nk D

m X

xj

(3)

j D1

where m is the number of elements in Bt and xj is defined as ² xj D

1; ˇvmj 2 ik 0; ˇvmj … ik

(4)

Based on the large number theorem, we have the probability in each interval i as follows: nk pk D Pn

j D1

nj

(5)

where pk gives the proportion of ˇ that falls in interval k. For a given time t , let n be the number of elements in I , we define log 0 D 1 and the entropy of subnet as follows: ht D 

n X

pk  logpk

(6)

kD1

We denote the subnet’s entropy sequence by H D ¹ht j t º, where t is the time stamp of the subnet’s entropy. Let n be the number of elements in interval I , based on the characteristics of the entropy function, we obtain the upper and lower bounds of ht as follows: 0 6 ht 6 logn

(7)

The lower bound is reached when all the ˇ are in one interval, that is to say, pk D 1, 1 6 k 6 n and pj D 0; j D 1; 2;    ; n; j 6D k. The upper bound is reached when all VMs distribute evenly in all intervals, that is to say, p1 D p2 D    D pn D n1 . 4. ANALYSIS OF ENTROPY-BASED DENIAL-OF-SERVICE ATTACK DETECTION MODULE In this section, we analyze the entropy-based Dos attack module and address three rules we obtain from attack detection module. In the first rule, we conclude that entropy drops when attack comes. The relationship between attack VMs proportion and entropy is introduced in the second rule. The third rule illustrates the weak correlation between detection system precision and calculation of ˇ. Rule 1. Compared with non-attack scenario, the entropy of VMs’ status drops when the attack starts, in other words, h1 .t / > h2 .t /, where h1 .t / and h2 .t / are entropies in non-attack and attack scenarios, respectively. Discussion. We know that entropy reaches the maximum when the VMs’ status are well distributed in each interval, namely, p1 D p2 D    D pN , and it reaches the minimum when the distribution is extremely uneven. The entropy is a monotonic function [27], when the attack happens, let ik be the interval that malicious VMs fall in, with the increase of pk , probability of intervals except pk drop, the distribution of VMs’ status trends to be uneven, as a result, entropy drops compared with non-attack scenario. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5630

J. CAO ET AL.

Rule 2. Based on the malicious VMs’ proportion, the entropy can be estimated when the subnet is under attack. We have addressed the stability of per-VM status in Section 3. System administrator can estimate the malicious VMs that need to lunch the attack and furthermore estimate the entropy threshold for the attack. Discussion. We denote n as the number of elements in interval I . From the entropy definition, it is obvious that entropy is irrelevant with the order of p. As the parameters of I is determined by the sample set, and malicious VMs’ status is quite different from non-attack VMs, so malicious VMs rarely fall into intervals that non-attack VMs fall in. We name interval that malicious VMs fall in as ih and denote ph as the value of the hidden interval. The rest of the VMs are almost distributed evenly in the rest of the intervals with a deviation factor ı (ı reflects the quality of our ˇ classification module), so the value of each interval except ih is .1  ph /  N11 . In order to make the presentation shorter, we take pr to represent .1  ph /  N11 . We obtain formula 8 as follows. n n X X pi  logpi D ph  log ph  pr  log pr  ı  i D1

i D2

(8) D ph  log ph  .n  1/  pr log pr  ı 1  ph D ph  log ph  .1  ph /log ı n1 From formula 8, it can be addressed that the entropy consists of three parts. The first part is the calculation from the intervals im in which malicious VMs reside in. We name this interval as hidden interval because this interval is not calculated in entropy calculation. Meanwhile, few ˇ fall into this interval in non-attack scenario, while certain amount of ˇ fall into this interval when under attack. We apply hidden interval to optimize our detection system performance. The second part is the ideal entropy from the rest intervals denoted as Ir . The last part is the factor ı, which indicates the deviation between the real VMs distribution and ideal VMs distribution. This factor results from the hypothesis that the non-attack VMs distribute in Ir evenly. As ph can be derived from the subnet communication capacity and interfaces throughput of each compute node, the entropy under attack can be estimated. Let Ea be the ideal entropy. We denote Ea as log .n  1/. That is to say, we do not take hidden interval into ideal entropy calculation. This definition is different from the standard maximum entropy, as hidden interval is not calculated. The deviation between real and ideal entropy indicates how well the VMs are distributed in each interval. Ea is applied to increase the accuracy of entropy estimation. Rule 3. In DoS attack detection, within a certain range, the correlation between the detection system performance and number of samples for each calculation is weak. We sample the data center twice and we obtain sets B1 and B2 . We denote ns ,  as the number of ˇ from B1 and B2 and ratio of ns =J (we denote J as the number of VMs from B1 and B2 ), respectively, ns is weak, when 0:7 6  6 1:3. Because hidden interval is not calculated in our detection system, the system performance is only affected by non-hidden intervals, the system performances are similar in both attack and non-attack scenarios. For simplicity, we only discuss the entropy variation in non-attack scenario. Discussion. For simplicity, we take Bt and its neighbor Bt C1 for discussion. It is obvious that entropy is determined by ˇ proportion in each interval, not only determined by the number of ˇ in a given time, and for a non-attack data center, the status of VMs is stable and approximately well distributed in set I . Based on these facts, we can prove formula 9 to be true. h¹p1 ; p2 ; : : : ; pn º  h¹p10 ; p20 ; : : : ; pn0 º

(9)

where p1 ; p2 ; : : : ; pn is calculated from Bt and p10 ; p20 ; : : : ; pn0 is calculated from C , where C D ¹Bi ; Bi C1 º, i is a random given time. As the data center is stable at a given short time slot, for p in Bi C1 , it can be regarded as some VMs’ ˇ migrate from one interval ij to another new interval ik , Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5631

where j and k are random variables from Œ1; n (we name these VMs as migration VMs). As there is no attack, the number of migration VMs is small. For non-attack data center, two conclusions can be drawn from the aforementioned analysis. Let pk and pj be the random interval proportion calculated from Bt , and pk0 and pj0 be the interval proportion variables calculated from C , firstly, pk0 is close to pk as few VMs migrate in or out the interval they used to reside in, so the number of elements in C and the number of ˇ in each given interval are both almost doubled compared with Bt . Secondly, pk is close to pj , and pk0 is close to pj0 as the VMs are approximately well distributed, and the migration number is small. To prove the correctness of formula 9, the feature of function plogp should be studied. As p 2 Œ0; 1, we only study the function in interval Œ0; 1. Obviously, it is nonsingular for all positive p. For p between 0 and 1, it is negative and reaches its minimal value at e 1 [28]. The function has the value 0 as its limit at p D 0, and the liner factor p easily dominates the singular logarithm when p is far away from e 1 . From parameters’ analysis of I , we believe, to obtain enough accuracy in entropy detection system, that the number of elements in I is more than 4, and the VMs in non-attack scenario are almost distributed evenly, for most cases, p  N1 , where N is the number of elements in I , that is to say, p obtains its value around N1 . The derivative of plogp is logp C C , where C is the constant. From the two aforementioned conclusions, logp C C varies in a small range and thus plogp trends to be linear when x fluctuates in a small range. As the function plogp is almost linear (in reality, the ratio of malicious VMs is much small than e 1 ), the gain caused by the migration into the interval and the loss caused by the migration out the interval cancel out, the entropy of the system approximately keeps the same. Furthermore, let C 0  C , that is to say, part of C is calculated. Formula 9 can also be applied in this scenario. The deviation is not only from the aforementioned analysis but also from the difference in the number of elements from C and C 0 . It is obvious that the number of elements (ns ) in C 0 is controlled by . For pj calculation in non-attack scenario, with 0:7 6  6 1, less than 30% of ns are not calculated compared with B, as a result, entropy of C 0 is close to entropy of B. On the other hand, with 1 6  6 1:3, no more than 30% of extra ns are calculated compared with B, so entropy of C 0 is close to entropy of B. As a result, ns has limited influence on the entropy. The experiments on the relationship between ns and detection system performance are presented in Section 6. 5. ARCHITECTURE OF DENIAL-OF-SERVICE DETECTION SYSTEM The cloud data center DoS attack detection system we apply is shown in Figure 3. The whole system is divided into four layers: cloud infrastructure layer, cloud infrastructure management layer, attack detection layer, and administrator management layer. Cloud infrastructure layer is the fundamental to offer cloud service and is the layer to be monitored. We deploy Openstack-based cloud infrastructure in our campus data center with 32 servers. In order to offer maximum network flexibility, Openflow-based switches are employed to implement network vitalization. Cloud infrastructure management layer offers the functions like VM management, system images management, and cloud network management. With the help of standard virtualization Application programming interface (API) (libvirt), a log audit module is invented to retrieve VMs’ running status with certain period of time. Attack detection layer is the core of the system. Administrator management layer has two dependent components, one is the cloud resources management module, and the other is the cloud tenant management module. Cloud resources management module is responsible for offering APIs for VM running mode management (start, stop, suspend and migrate the VMs), cloud image management, cloud storage management, and cloud network management. Cloud tenant management module is responsible for offering APIs for assigning different authorities for different roles and role management. For instance, with the help of cloud tenant management module, we can assign network management staff authority of creating, deleting, or modifying virtual network infrastructure, but no access to manage the cloud image. The attack detection layer consists of three modules. They are the VM status gathering module, the attack identify module, and the cloud control module. In the VM status gathering module, VMs’ status, such as CPU usage, IO, and network throughput, is gathered and stored in VM status database, it communicates with log audit module in the cloud Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5632

J. CAO ET AL.

Figure 3. Cloud DoS attack detection architecture.

infrastructure management layer through standard remote process call interface. System administrator has the privilege to set the sample period. This module will retrieve the status of each VM that resides in the monitored subnet asynchronously. It filters out the idle VMs, which have few IO, network throughputs, and CPU usage, and then stores the rest of the VM status into database. Another function of status gathering module is to update the system ˇ classification sample set. We have addressed that the VMs’ status vary with different time of day. The updating of samples gives change to let our attack identify module update its parameters’ consistency with the variation of data center status. Our system is smart enough to learn and alter its parameters according to the real environment without any interference. In the attack identify module, VMs’ status are queried from database, and entropy detection algorithm is applied to work out the data center entropy. This module maintains an entropy queue, when the latest entropy comes in, the oldest entropy leaves the queue. The queue acts as a slide window, in the window, we verify the distribution of entropy variables and identify the DoS attack. Details about the detection method are discussed in Section 6. The result of the detection is reported in the cloud control module. In the cloud control module, actions are taken based on the entropy detection result. This module mainly has three tasks. Firstly, it queries the result from attack identify module. Secondly, based on Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5633

the result, it applies policies that are adopted by the cloud data center administrators. All the actions are carried out through remote process call offered by cloud infrastructure layer. Thirdly, it reports the detection result to the administrator management layer. 6. EXPERIMENT AND RESULT In this section, we firstly address the existence of DoS attack in the cloud and study the impact of the attack under different scenarios. Secondly, we demonstrate that our system has a swift response to DoS attack and evaluate our system performance. Experiment setup. We deploy our Openstack experiments’ environment with 32 IBM HS22 servers (2.66-GHZ CPU *12 core, 24-GB memory, 1-Gbps network interface). Two of the servers serve as the Openstack network nodes, one server serves as the Openstack control node, and the rest as Openstack compute nodes. The experiment network topology is shown in Figure 2. Two subnets are created and connected to the external network through two network nodes, respectively. In our experiments, network node in subnet 2 is the target to be saturated. Each network node has 1-Gbps bandwidth by default. With a large amount of data that go through network node in subnet 2, network node in subnet 2 could be saturated, and the communication between subnets 1 and 2 would degrades a lot. Network benchmark tool Iperf is applied to probe the throughput of the network. 6.1. Experiment 1: number of malicious virtual machines versus network performance In the cloud environment, we firstly investigate the correlation between the number of malicious VMs and the network performance. We employ a certain amount of VMs in subnet 1 to send a large amount of data to subnet 2. Each VM has 35-Mbps bandwidth, and to make the experiment fair, we set all Transmission Control Protocol (TCP) window sizes as 256 KB. Figure 4(a) shows the TCP throughput of network node in subnet 2 under different attack scales. It can be seen that TCP throughput behavior is similar although attack scales vary from each other. For all the attack scenarios, when the attack arrives, the network performance degrades a lot, and during the attack, the network performance is stable. As each attack VM has 35-Mbps bandwidth, and throughput of network node is 1Gbps, 30 attack VMs almost use up all the bandwidth, which is verified by the experiment. A total of 10 attack VMs take 350-Mbps bandwidth, and the network throughput under this scenario is around 500 Mbps, which is also verified in Figure 4(a). From the two aforementioned experiments, we can draw the conclusion that the number of VMs needed to launch the attack can be estimated based on the network condition. Figure 4(b) shows the FTP client throughput under different attack scales. With the growth of attack scale, the FTP throughput drops dramatically. Attacks in different background communication scenarios have similar behaviors. For a light workload subnet, about 25 malicious VMs can

Figure 4. Network performance under attack. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5634

J. CAO ET AL.

make the FTP throughput under 5 Mbps. However, 15 attack VMs are enough to make the FTP throughput under 5 Mbps with 600-Mbps bandwidth capacity. For 400-Mbps subnet, about 11 malicious VMs can make the FTP communication stall. In Figure 4(b), we can figure out that in a subnet with high network workload, a small amount of malicious VMs is enough to launch the attack, and with the increase of malicious VMs, the network performance drops dramatically. From experiment 1, two conclusions can be addressed. Firstly, this kind of DoS can saturate the cloud data center network node, thus degrade the service quality of cloud data center. Secondly, based on the background bandwidth, cloud data center administrators can figure out the number of VMs that needed to launch the attack, and the DoS identification entropy threshold can be figured out accordingly. 6.2. Denial-of-service detection system performance evaluations In the following experiments, we first evaluate the stability of entropy in non-attack data center, then we evaluate the impact of different parameters on our detection system. Finally, we evaluate our detection system in DoS attack scenario and discuss the impact of system parameters on the accuracy of our detection system. 6.3. Experiment 2: calculation of entropy and its stability This experiment is to study the entropy distribution in the cloud data center. As it is discussed in Section 3, we define parameter ˇ as the network throughput divided by CPU usage time. In our data center, we investigate 50 VMs’ performances, some VMs are employed as Hadoop nodes, and some are served as text editor or physical simulators. The rest are mainly web servers or files sharing servers. As rule 3 has discussed, the number of ˇ has weak correlation with attack detection system performance. We sample these VMs twice (100 samples) as one minimal entropy calculation epoch. We believe that ˇ 6 15, which means that consuming more than 1 ms on sending or receiving 15-KB network data cannot be employed by adversary. Based on our samples, 64% of VMs in our data center have ˇ under 15, so 36% VMs could be suspects. Based on the sample set, we divide our intervals into two parts: hidden interval and non-hidden interval as ((15,20],(20,30],(30,35],(35,40],(45,50],(50,55],(55,60],(60,65],(65,100],(100,C1). The first 10 intervals are presented as non-hidden intervals, and the last is the hidden interval. We sample our data center for a period, and the result is shown in Figure 5(a). Figure 5(a) shows the entropy versus time in the non-attack data center. The average of these entropy samples is 1.9709, and the ideal entropy is 2.3026. A gap can be identified between ideal entropy and reality. This gap indicates the deviation between the real distribution and ideal distribution, in non-attack scenario, it indicates the performance of parameter learning system to some extent. Figure 5(b) shows that as the entropy fluxes within a small range and the monitored system is stable, the entropy distribution should be close to normal distribution. We apply the quantile– quantile plot to check the validity of normal distribution for our entropy set. Figure 5(b) indicates

Figure 5. Entropy variation and distribution. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5635

that the distribution of entropy is very close to normal distribution. Most of the dots are close to line y D m C ax except for the extreme head and tail, where m and a are the mean and standard deviation of the entropy set, respectively. In Figure 5(b), variable r denotes the square root of the coefficient of determination. Applying Kolmogorov–Smirnov test with significance level 0.05, the probability to reject the hypothesis that the entropy set is a normal distribution is 0.2348. It is can be addressed that the entropy of the cloud data center is stable in non-attack scenario. This phenomenon can be interpreted as the stability of VMs. The stability of data center ensures the accuracy of the attack identify system. Although VM status in cloud data center vary in a certain range, entropy as a statistic way weakens the individual fluctuation. 6.4. Experiment 3: impact of sample numbers on each epoch of entropy measurement Rule 3 demonstrates that the number of ˇ for entropy calculation has limited impact on the data center entropy detection when  varies between 0.7 (inclusive) and 1.3 (inclusive). In this experiment, we demonstrate the rightness of rule 3 in practice. We have traced our data center, which has 35 VMs that have ˇ > 15 for a period and obtains 6800 ˇ samples, we divide these samples into three groups. We denote ns as the number of ˇ in each calculation epoch. It can be observed that although ns is different, when  varies between 0.7 and 1.3, the entropy variables are close, the trends are similar, and they all obey normal distribution with the same significance level; however, when  is larger than 1.3, entropy variation cannot reflect real data center status. We assign ns as 25 ( D 0:71, we set  close to lower bound deliberately to enlarge the difference between groups 1 and 2), 35 ( D 1:0), and 55 ( D 1:57, we set  larger than the upper bound to give an invalid detection case), thus, 6800 samples can be divided into 272, 194, and 123 entropy calculation epoches, respectively. The entropy variables of each group are calculated and plotted in Figure 6. It can be observed that even group 2 has 10 more samples than group 1 for each entropy calculation, the entropy variables are very close, and the trends are similar. Before the 81st entropy sample, the average entropy variables both swing between 1.7 and 1.9, and after the 81st sample, they both swing between 1.9 and 2.1. Group 3 has 20 more samples than group 1 for each entropy calculation, and the entropy variables are different to some extent. Entropy variation in group 3 can be divided into two stages, in the first stage before the 30th sample, the average entropy is between 1.9 and 2.0 and climbs quickly from 2.1 to 2.2 after the 30th sample in stage 2. The slow entropy average growth can be observed with the growth of the number of ˇ in different groups. More moderate fluctuations can be observed in group 3 compared with group 1 and group 2. We perform more detailed discussions to answer these phenomena. Discussion. The entropy average increases with the growth of ns monotonously. We believe that there are two reasons for this phenomenon. The first reason is that with the increase in the number of ˇ samples, the weight of individual ˇ decreases, thus impairs the impact of individual ˇ sample. The second reason is that with the growth of statistic scale, the distribution of ˇ samples is more

Figure 6. Entropy variation with different entropy calculation groups. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5636

J. CAO ET AL.

even and stable. According to entropy definition, the more even the distribution is, the larger the entropy becomes. The entropy fluctuation is more moderate in group 3 compared with groups 1 and 2. We believe that this is caused by the statistic scale. As the weight for each ˇ sample in entropy calculation is equal, for small ns , each sample can make a great impact on the entropy calculation, so the entropy varies in a wider range. On the other hand, the impact of individual in large ˇ sample set is weakened by the amount of samples, as a result, small fluctuation range can be observed in that scenario. From the comparison of groups 1 and 2 in Figure 6, it can be seen that when ns varies in a small range, the entropy variations and trends are almost the same. While in group 3, with  > 1:3, entropy variation has significant difference compared with groups 1 and 2. According to the raw VMs’ status analysis, we draw the conclusion that entropy samples in group 3 cannot reflect the real data center status anymore, in other words, detection result with  > 1:3 is invalid. The wide variation range of  demonstrates that our detection system is robust with different system parameters. 6.5. Experiment 4: attack detection in data center In this experiment, we test the performance of our DoS attack detection system through DoS attacks in our data center. The monitored data center has 85 VMs, and the data center is mainly used for web hosting service, file service, and computing service like Hadoop. In this data center, about 19% of VMs are at standby mode with few IO traffic and few CPU usage. As the experiments are conducted in real production environment, each DoS attack lasts 1 min to avoid the influence on other tenants, we firstly launch the DoS attack with 10 malicious VMs, and after a period, we launch two attacks based on 20 malicious VMs. The result from our detection system is shown in Figure 7. To verify that hidden interval has little impact on normal status and great impact on attack status, we draw the gap between entropy calculated with hidden interval and without hidden interval at the bottom part of Figure 7. Discussion. In Figure 7, three attacks can be identified. The system has a quick response to attack when the attack comes as system entropy drop dramatically. System entropy bounces back to normal level when the attack stops. The attack scale can be observed in Figure 7, under 10 malicious VMs’ attacks, the entropy drops around 1.5; however, under 20 malicious VMs’ attacks, the entropy drops around 1.1. The advantage of hidden interval can be observed in Figure 7, when the data center is free from attack, the gap between these two entropy variables is almost zero. However, under attack, the gap increases a lot. It can be seen that hidden interval enlarges the entropy when attack comes, as a result, the system can identify the attack more easily. Essentially, hidden interval highlights the impact of attack VMs while impairs the impact of VM status changes belonging to non-hidden intervals. Attack identification. As it is shown in Figure 7, the entropy distribution obeys normal distribution as the data center is stable. When the attack comes, the balance of data center would be broken, as a result, for a given time slot, entropy variables do not obey normal distribution thus indicating that the

Figure 7. Subnet entropy under attack. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5637

status of data center has changed. If the variation is larger than the attack entropy threshold, the DoS attack can be identified. We apply a slide window to separate entropy sequence into small groups, and in each entropy window, we apply Kolmogorov–Smirnov test to check whether these entropy variables obey normal distribution. When the balance of data center is broken, entropy threshold as further checked will be applied to verify whether the data center is under attack. Attack entropy threshold. Here, we discuss how we apply rule no. 2 to work out the entropy threshold for a data center. The threshold works as a sign indicating the proportion of VMs that fall into hidden interval. The proportion of VMs can be determined, as the background network traffic can be easily probed and the maximum bandwidth of VMs is already known. We apply rule no. 2 and obtain the threshold roughly indicating the proportion of malicious VMs with formula 10. T D

n X

pi  logpi  .ph  log ph /

i D1

1  ph ı n1 1  ph D .1  ph /log  .Ea  El / n1

D .1  ph /log

(10)

where T denotes the threshold we set to detect the DoS attack, Ea denotes the system ideal entropy, and El denotes the average entropy from non-attack entropy window. As the hidden interval is not calculated, T is calculated from the system entropy minus the value of the hidden interval. The threshold has two components. The first is the accumulation value from non-hidden intervals, and the second is the deviation from the hypothesis that all non-attack VMs are distributed evenly. In reality, we apply Ea -El to minimize the deviation. The whole formula stands for the entropy threshold for the DoS attack with the attack VMs’ proportion of Ph . 6.6. Experiment 5: detection system performance In this section, we evaluate the speed and accuracy of our detection system. As it is shown in formula 10, the main inaccuracy of the system results from the hypothesis that when under attack, all nonattack VMs are distributed evenly. We carry out some attacks at different time of day to evaluate our detection system under different data center usage backgrounds. For 10 malicious VMs’ attack scenarios, we have an average real entropy of 1.56294, and the threshold is 1.6818. For 20 malicious VMs’ attack scenarios, we have average real entropy of 1.089647, and the threshold is 1.07996. We draw the system real entropy and threshold calculated from formula 10 in Figure 8. It can be observed that when under attack, even the sample data center at different time, the entropy varies in a small range. This feature demonstrates the stability of the attack and data center. The accuracy of the detection system is measured by the significant level of the gap between the real entropy and the threshold we set. The small gap between the real entropy and threshold demonstrates that our system has high accuracy in DoS attack detection. Compared with Figure 8(a), Figure 8(b) has

Figure 8. Real entropy versus threshold. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

5638

J. CAO ET AL.

smaller gap between real entropy and threshold, that is to say, the system has better performance in detecting larger scale of DoS attack. The significant level of false positive and false negative is directly affected by the distribution of VMs in I . When the threshold is bigger than the real entropy, false positive generates, while when the threshold is smaller than the real entropy, false negative generates. The more evenly distributed the non-attack VMs are, the smaller significant level of error rate is. The response speed of the detection system mainly depends on two aspects. One is the data center sample rate, the other is the time consumption on entropy calculation. Obviously, entropy can be calculated instantly, as a result, the speed of our detection system mainly depends on the sample rate. System administrators have full control on attack detection latency. Low-detection latency means high sample rate on each monitored node meanwhile increasing the system workload. Data center administrators should work out a proper sample rate based on the acceptable detection latency and overhead on each monitored node. The detection system performance is affected by the following factors. The first factor is the scale of data center and scale of the attack. It is observed that false positive rate surpasses 75% when the size of Bt is smaller than 30, as small statistic set enlarges the weight of each VM, normal entropy fluctuation may be regarded as attack, as a result, false negative and false positive both exist in our detection system. The second factor is the number of ˇ in entropy calculation epoch. Experiment 3 demonstrates that our detection system has a good tolerance of this parameter. Although entropy average grows with the increase of ns , based on our experiments, system detection accurate is almost the same when we set 0:7 6  6 1:3. The third factor is the design of I , as our entropy threshold is based on the precondition that VMs are almost well distributed in each interval, unreasonable I would degrade the system performance significantly. It is obvious that false negative and false positive are generated with the growth of ı. For a data center, at different time, ı varies in a small range with the fluctuation of data center status. Fortunately, with sample set updating mechanism, in most cases, our learning system has the ability to keep ı 6 0:4. Overall, as the three preconditions usually hold in modern data center, we believe that our system is robust with different application scenarios. 7. CONCLUSION AND FUTURE WORKS This paper studies the possibility of DoS attack in cloud data center and identifies the attack as malicious VMs in similar status patterns using information entropy. We deploy our detection system in our data center, and the experiment results show that our detection system has a good performance for DoS attack detection. With this detection mechanism, DoS attack can be identified. We will explore the mechanism to avoid the attack in the future. The unreasonable network resources allocation leads to this kind of attack, if we could reallocate the network resources according to the VMs’ running pattern, this kind of DoS attack may be eliminated. We believe that information entropy applied here as an approach for attack detection also can be applied to guide the cloud data centers balancing their workload among different zones. For a given zone, different types of VMs that reside together may reduce the competition for the same critical resources, thus improving the efficiency of the whole data center. ACKNOWLEDGEMENT

This work was supported by the National Key Basic Research Program (973 Program) of China under grant no. 2010CB328104; the National Natural Science Foundation of China under grants nos. 61272531, 61202449, 61272054, 61370207, 61370208, 61300024, 61320106007, 61472081; the China high technology 863 program under grant no. 2013AA013503; the China Specialized Research Fund for the Doctoral Program of Higher Education under grant no. 2011009213002; the Jiangsu Provincial Science and Technology Plan Program under grant no. SBY2014020139-10; Key Laboratory of Computer Network and Information Integration of Ministry of Education of China under Grants No. 93K-9; and the Jiangsu Provincial Key Laboratory of Network and Information Security under grant no. BM2003201. Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe

ENTROPY-BASED DENIAL OF SERVICE ATTACK DETECTION IN CLOUD DATA CENTER

5639

REFERENCES 1. Chen Y, Paxson V, Katz RH. Whats new about cloud computing security 2010; 20(2010):2010–2015. University of California, Berkeley Report No. UCB/EECS-2010-5 January. 2. The notorious nine: cloud computing top threats in, 2013. (Available from: https://cloudsecurityalliance.org/ download/the-notorious-nine-cloud-computing-top-threats-in-2013) [Accesed on February 2015]. 3. Lei A, Youchan Z. The solution of DDOS attack based on multi-agent. Educational and Information Technology (ICEIT), 2010 International Conference on, vol. 2. IEEE, Chongqing, China, 2010; V2–530. 4. Yu S, Tian Y, Guo S, Wu D. Can we beat DDOS attacks in clouds? IEEE Transactions on Parallel & Distributed Systems, 2013. 5. Chonka A, Xiang Y, Zhou W, Bonti A. Cloud security defence to protect cloud computing against HTTP-DoS and XML-DoS attacks. Journal of Network and Computer Applications 2011; 34(4):1097–1107. 6. Liu H. A new form of DOS attack in a cloud and its avoidance mechanism. Proceedings of the 2010 ACM Workshop on Cloud Computing Security Workshop, ACM, CCSW’10, Chicago, Illinois, USA, October 8, 2010; 65–76. 7. Cisco data center infrastructure 2.5 design guide. (Available from: http://www.cisco.com/univercd/cc/td/doc/solution/ dcidg21.pdf) [Accessed on February 2015]. 8. Popa L, Kumar G, Chowdhury M, Krishnamurthy A, Ratnasamy S, Stoica I. Faircloud: sharing the network in cloud computing. Proceedings of the ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, ACM, Helsinki, Finland, 2012; 187–198. 9. Al-Fares M, Loukissas A, Vahdat A. A scalable, commodity data center network architecture. ACM SIGCOMM Computer Communication Review 2008; 38(4):63–74. 10. Hopps CE. Analysis of an equal-cost multi-path algorithm. Internet Engineering Task Force (IETF), Adelaide, Australia, 2000. 11. Yu S, Zhou W, Doss R, Jia W. Traceback of DDoS attacks using entropy variations. IEEE Transactions on Parallel and Distributed Systems 2011; 22(3):412–425. 12. Francois J, Wang S, Bronzi W, State R, Engel T. Botcloud: detecting botnets using mapreduce. 2011 IEEE International Workshop on Information Forensics and Security (WIFS), IEEE, 2011; 1–6. 13. Openstack website. (Available from: http://www.openstack.org) [Accessed on November 2014]. 14. Guo J, Liu F, Tang H, Lian Y, Jin H, Lui JC. Falloc: fair network bandwidth allocation in IAAS datacenters via a bargaining game approach. Proceedings of IEEE ICNP, Göttingen, Germany, 2013; 1–10. 15. Chen Y, Wu X, Cao Q, Yang X, Benson T. Bigpi: sharing link pools in cloud networks[J], TR2013-01, Department of Computer Science, Duke University. 16. Lonea AM, Popescu DE, Tianfield H. Detecting DDoS attacks in cloud computing environment. International Journal of Computers Communications & Control 2013; 8(1):70–78. 17. Modi C, Patel D, Borisaniya B, Patel H, Patel A, Rajarajan M. A survey of intrusion detection techniques in cloud. Journal of Network and Computer Applications 2013; 36(1):42–57. 18. Modi CN, Patel D. A novel hybrid-network intrusion detection system (H-NIDS) in cloud computing. 2013 IEEE Symposium on Computational Intelligence in Cyber Security (CICS), IEEE, Singapore, 2013; 23–30. 19. Chen Z, Dong W, Li H, Cao J, Zhang P, Chen X. Collaborative network security in multi-tenant data center for cloud computing. Tsinghua Science and Technology 2014; 1(009):82–94. 20. Chen Z, Han F, Cao J, Jiang X, Chen S. Cloud computing-based forensic analysis for collaborative network security management system. Tsinghua Science and Technology 2013; 18(1):40–50. 21. Greenberg A, Hamilton J, Maltz DA, Patel P. The cost of a cloud: research problems in data center networks. ACM SIGCOMM Computer Communication Review 2008; 39(1):68–73. 22. Giurgiu A. Network performance in virtual infrastrucures, February 2010. (Available from: http://staff.science.uva. nl/delaat/sne-2009-2010/p29/presentation.pdf) [Accessed on March 2015]. 23. Li A, Yang X, Kandula S, Zhang M. Cloudcmp: comparing public cloud providers. Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement, ACM, Melbourne, Australia, 2010; 1–14. 24. Schad J, Dittrich J, Quiané-Ruiz JA. Runtime measurements in the cloud: observing, analyzing, and reducing variance. Proceedings of the VLDB Endowment 2010; 3(1–2):460–471. 25. Wang G, Ng T. The impact of virtualization on network performance of amazon ec2 data center. INFOCOM, 2010 Proceedings, IEEE, San Diego, CA,USA, 2010; 1–9. 26. Meng X, Pappas V, Zhang Li. Improving the scalability of data center networks with traffic-aware virtual machine placement. INFOCOM, 2010 Proceedings IEEE, IEEE, San Diego, CA,USA, 2010; 1–9. 27. Cover TM, Thomas JA. Elements of Information Theory. John Wiley & Sons: NJ, USA, 2012. 28. William H. Press Numerical Recipes 3rd Edition: The Art of Scientific Computing. Cambridge University Press: Cambridge, United Kingdom, 2007.

Copyright © 2015 John Wiley & Sons, Ltd.

Concurrency Computat.: Pract. Exper. 2015; 27:5623–5639 DOI: 10.1002/cpe