Advertisement

DDoS prevention using third party auditor in cloud computing

  • Rajat SaxenaEmail author
  • Somnath Dey
Original Article

Abstract

Distributed denial of service (DDoS) attack is one of the prominent risk factors for the development of cloud service. It is a very hard task for novice cloud users to identify the real source of DDoS attack because the attacker spoofs the Internet Protocol and Media Access Control addresses. To address this problem, we propose a third party auditor-based packet traceback approach. The method uses Weibull distribution for analyzing the source of the DDoS attack. The approach provides an efficient and fruitful solution because of its strong identification factor. The identification factor depends on the weaknesses left by the intruder. We analyze the traffic pattern to generate attack alert for different cloud users. The advantage of this approach is that it reduces the overhead on the cloud user. With the help of Weibull distribution, we can easily obtain the availability, reliability and median life of DDoS defense in the cloud environment. To demonstrate our approach, we implement an application based on Hadoop and MapReduce framework. We tested this application based on various parameters. Our method has shown the tremendous improvement over the other state of the art methods. The experimental results are included to show the effectiveness of the proposed method for DDoS attack prevention and mitigation.

Keywords

Cloud computing Distributed denial of service (DDoS)  Attack Third party auditor (TPA) Weibull distribution Packet traceback 

1 Introduction

Cloud computing [4] is the on-demand exercise of remote servers over the network, which is hosted on the Internet to process, store and organize the data rather than a local server or a personal computer. Cloud [1] provides promising service provision of software, platform, and infrastructure. Dynamic workload assignment, heterogeneous system support, resource and service management, integration with data management tools, separate administrator, developer, and end-user interfaces, visibility and reporting are the necessary criteria of cloud computing. Continuous Internet support is required to develop a cloud infrastructure because the availability, reliability and its security are the primary concern for any cloud service provider (CSP).

Denial of service (DOS) attack [2] is one of the primary fundamental threat to cope up with cloud infrastructure. In a DOS attack, an associate trespasser tries to stop legitimate users from accessing the information or services. This trespasser could also be ready to prevent an authorized cloud user from using available cloud resources and services by targeting user‘s personal computer and its network connection.

On the other hand, distributed denial of service (DDOS) attack [2] is an upgraded version of DOS attack. DDoS is a collaborative attack on the availability and functionality of a victim cloud through multiple corrupted systems. Multiple damaged systems are used for targeting and corrupting a victim cloud to build a DDOS attack. After stealing the control, an associate intruder imposes these compromised systems on sending a large number of malicious packets on the victim cloud. In this distributed approach, multiple systems have used by the attacker to launch DOS attack. During the DDoS attack, multiple compromised systems of cloud act as victim systems.

The primary objective of the DDoS attack is to crash the victim cloud. Often, the unrevealed intention behind this attack is to restrict the available resources and dissolute the highly demanded services of the victim cloud. Thus, it accomplishes harassment of the victims due to huge financial loss. The attacker malfunctions the confidentiality of the victim and uses their valuable data for the malicious purpose. Apart from all these, acquiring the popularity in the hacker’s community is also an ambitious reason for these attacks.

In cloud environment [3], all malicious attackers, which are affected by the intruders, send a large number of malicious packets directly to the victim cloud servers. As a result, the entire network has flooded with attack messages instead of legitimate packets. Thus, availability of cloud storage servers for the authorized users would be spurious, because attack packets have been flooded with cloud storage server. It is also possible that attackers can manipulate the content of the valid packets. It would damage the services of a victim cloud server. In the cloud scenario, the user might have the limited bandwidth and computation resources. The expectation of the cloud user for the cloud resources is that they must always be available to him. Any downtime of services may lead to user dissatisfaction. Thus, we require a robust and efficient technique to detect and prevent DDoS attack in a cloud environment.

In this paper, we suggest a concurrent approach for DDoS defense in the cloud environment. This defense mechanism has been based on Weibull probability distribution with the third party auditors (TPAs). We obtain the real-time attack alerts from the traffic pattern. This pattern demonstrates all the alternative path to the origin source from the victim. It helps us to find the origin source of the attack. Thus, we can able to block the systems lying in the path source of this attack. We can easily get the median life, reliability, and availability of DDoS defense with this distribution.

Contributions of this paper are as follows:
  1. 1.

    We have surveyed on a large number of DDoS attack in cloud computing and classify them based on infrastructure and application-bug levels.

     
  2. 2.

    We have also presented the survey on the different DDoS attack tools, which are used to identify and prevent a DDoS attack in cloud environment.

     
  3. 3.

    We have the study on all possible prevention and mitigation techniques, which are supposed to be a solution to a DDoS attack on cloud environment. We have discussed their merits and demerits by their properties.

     
  4. 4.

    We have proposed an effective DDoS prevention and mitigation technique, which overcomes all demerits of previous techniques.

     
  5. 5.

    We have analyzed our technique based on various security and performance parameters and showed the effectiveness of our approach.

     

2 Literature survey

There are several types of DDoS attack which affect the availability and functionality of the cloud services. Broadly, DDoS attacks can be categorized into two classes [20]:
  1. 1.

    Bandwidth depletion attack: It is also known as “Brute Force Attack.” In this type of attack [25], a significant number of malicious and spurious user’s requests consume all the Internet bandwidth that aggregates and overwhelms the entire Internet traffic. It is a massive distributed attack and it involves thousands number of nodes. Further, it can be classified into two subcategories such as flood attack and amplification attack. Zombie is an Internet connected computer that has been compromised by the intruder. It performs the malicious task on the victim side with the help of remote connectivity. The zombies initiate flood attacks which send a significant amount of traffic to the victim system that simply blocks the legal services. It depends on User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP) packets. In the amplification attack, Zombies or attackers send many messages to a broadcast IP address. It results in a lot of reply message at the end of victims system because, in the subnet, each address includes a response to the broadcast message.

     
  2. 2.

    Resource depletion attack It is also known as “Semantic or Vulnerability Attack. ” In this type of attack [25], a malicious attacker creates and exploits the vulnerability in the resource and generates the resource starvation conditions. With this condition, legitimate user cannot be able to access required resources. This type of attack uses Hyper Text Transfer Protocol (HTTP), Hyper Text Transfer Protocol Secure (HTTPS) or Domain Name System (DNS) to exploit the vulnerability of cloud.

     
The DDoS defense mechanism can be divided into four stages: monitoring, detection, prevention,and mitigation. In monitoring, a defender uses various tools to gather network information for execution of protection. The detection step analyzes the executed system for obtaining the source of malicious traffic to cause the perception of attack.

The prevention suggests secure services and intercepts the malicious cause that creates the critical situation of attack. Finally, the mitigation evaluates the ultimate effect of the attack and determine the correct response system to manage the DDoS attack effectively. These four steps complete the life cycle of the DDoS defense system shown in Fig. 1.

To monitor and detect any DDoS attack, analysis of attack characteristics of any tool helps us efficiently. Table 1 summarizes the different tools for monitoring and detecting the DDoS attacks. These tools use UDP, ICMP and Transmission Control Protocol (TCP) to implement detection and protection of DDoS attack. However, some of these tools use channel encryption for security. Thus, detection of such attacks is very difficult.

Trinoo is a UNIX-based tool which help attackers to understand the possible structure, function for defense and anatomy of the DDoS attack. One problem with this tool is that attacker cannot spoof their source address. Tribe flood network (TFN) [5] is a collection of the various computer programs to perform the DDoS attack on victim side. These programs had been written by a security expert and hacker named “Mixter”
Fig. 1

Life cycle of DDoS defence system

Table 1

Comparative analysis of different DDoS attack tools

Tool name

Possible attacks

Packet format used to launch attack

Channel encryption

Trinoo

Bandwidth depletion, remote buffer overrun exploitation

UDP

Yes

Tribe flood network (TFN) [5]

Both bandwidth and resource depletion

UDP, TCP SYN, ICMP echo request and ICMP directed broadcast

No

TFN2K [6]

Bandwidth depletion, resource depletion and mix attacks

UDP, TCP SYN and ICMP

Yes (Key Based CAST-256 Algorithm)

Stacheldraht [8]

Both bandwidth and resource depletion

UDP, TCP SYN, ICMP echo request and ICMP directed broadcast

Yes (Symmetric Key)

Mstream [7]

Bandwidth depletion

TCP RST, ICMP and TCP with ACK flag set

No

Shaft [6]

Both bandwidth and resource depletion

UDP, TCP, ICMP

No

Trinity [9]

Both bandwidth and resource depletion

UDP, TCP SYN, TCP Null TCP RST and TCP with ACK flag set

No

Knight [10]

Both bandwidth and resource depletion

UDP, SYN and pointer flooder

No

Kaitan [10]

Both bandwidth and resource depletion

UDP, TCP SYN and TCP PUSH + ACK

No

BlackEnergy [11]

Both bandwidth and resource depletion

HTTP, HTTPS, XML

Yes

Low-orbit ion cannon (LOIC) [12]

Both bandwidth and resource depletion

HTTP, HTTPS and XML

Yes

Aldi Botnet [12]

Both bandwidth and resource depletion

HTTP, HTTPS and XML

Yes

Stacheldraht [8] is a malware that is written by “Random” for Solaris and Linux systems. Because of this malware, each affected system acts as a DDoS agent. Mstream [7] is a three-tiered DDoS tool that overburdens the CPU and restricts the network bandwidth. This tool is based on UNIX operating system and exploits many web services by utilizing TCP and UDP vulnerabilities.

The shaft [6] tool was initially recovered as a binary tool, and then in the source form as an agent. If a system is affected with the shaft, then its distributed nature adds “ Many to One Relationship” and many nodes are altered, modified or lost their identity. Trinity [9] is a binary agent system that is installed on a LINUX system. It alerts about the list of connected port servers. It helps attackers to drop any kind of web service.

Knight [10] and Kaitan [10] are Internet Relay Chat (IRC)-based tools that are used for UDP flood attack SYN attacks. They are used as an urgent pointer flooder and perform the massive type of DDoS attack on victim side. BlackEnergy [11] is a Web-based attack tool that can launch different types of DDoS attacks and controls the bots using minimum syntax and structure. It is developed by a Russian hacker, who steal very confidential data from secret agency of Russia.

Low-Orbit Ion Cannon (LOIC) [12] is open source and network stress testing tool whose application on the network may be a DDoS attack. It is initially developed by Praetox Technologies and written in C# language. Aldi Botnet [12] is a popular botnet ransomware that helps professional hackers to perform DDoS attacks and steal valuable and confidential information from secret agencies of Switzerland, Germany, and Austria in 2012.

The prevention and mitigation have used as rate limiting or filtering techniques for DDoS defense, which can be reconfigured as collaborative and non-collaborative approaches.

Rate limiting methods are very convenient to deploy and provision for network nodes. These methods set dynamic and flexible threshold for filtering the malicious traffic. They are very useful in the detection of many false positives. The primary disadvantage of this method is its coarse grain filtering, which eliminates the legitimate traffic. Because of it, the detector cannot filter the malicious traffic completely.

Filtering techniques are very flexible in adding and removing the IP addresses. They are very convenient for provisioning the network nodes. The main difficulty with the filtering techniques is that they are not able to distinguish between legitimate and malicious traffic generated from the same source. Another problem with filtering techniques is that they are not able to detect all malicious address.

The non-collaborative approaches use reconfiguration for elastic and efficient DDoS defense. It is a distributed and reliable solution because users can create different instances of Virtual Machines (VMs) in various data centers. The major difficulty with this approach is to put defense mechanism in the right place for defense. It requires precise information and orchestration about the network topology and resources for the selection of right place.

On the other hand, the collaborative approach used push-back and cooperative firewalls that identify and reach the closest source of the attack. It appraised robust and distrusted defense and mitigation architecture. The main difficulty with this approach is collaboration and trust established between the different domains. Another difficulty is its inability to automatically adjust defense mechanism based on the complexity and variety of DDoS attack.

Rajan et al. [15] described an approach that favors authorized traffic over the malicious traffic. This scheme uses suspicious assignment and scheduler for DDoS prevention. The suspect traffic diagnosis of DDoS attack of this approach is around 0.1 s–10 s.

Chu et al. [16] presented OpenFlow-based DDoS defender for automatic self-defense. In this scheme, two static thresholds were used. When these thresholds met, it is the sign of DDoS attack. The diagnosis time of suspicious traffic related to the DDoS attack for this approach is around 0.8 s–14 s.

Choi et al. [18] proposed the Content-Oriented Networking Architecture (CONA) that examines the requested content and initiate the countermeasure for DDoS attack. The diagnosis time of suspicious traffic related to the DDoS attack for this approach is around 0.6 second to 16 seconds.

Braga et al. [17] propose a lightweight traffic flow feature that uses Self-Organizing Maps (SOM) based neural network for flow prediction. This network uses an OpenFlow NOX controller for transformation and analysis of classifier modules. This module is efficient, scalable, and updated to address new vulnerabilities.

Lua et al. [19] presented an intelligent, fast flux swarm network that reorganized the system and provides maximum availability to all clients and servers. In this scheme, a parallel optimization algorithm runs for constant reconfiguration of the swarm network, which provides efficient DDoS detection in the cloud environment.

Zarger et al. [24] demonstrated a new approach for distributed, collaborative defense against the DDoS attack. This method detects the high volume of malicious traffic during the DDoS attack. It also detects the closer source of the attack. The diagnosis time of suspicious traffic related to the DDoS attack for this approach is around 0.7 second to 20 seconds.

Yao et al. [21] suggested Virtual Source Address Validation Edge (VAVE) that expands the Software Defined Networking NOX (SDN-NOX) controller on the virtual machines for flow check entries, filtering, and validation for DDoS prevention. The VAVE modules validate the incoming packet and take decisions.

Dou et al. [22] suggested a confidence-based filtering (CBF) technique for cloud computing. It produces a simple profile in the normal (non-attack) period. In this approach, each packet is examined based on some correlation parameters. The examination result declares the detail of malicious packets.

Shin et al. [23] presented a framework “FRESCO” that produces a prototype of the application to help with detection and mitigation of security modules. The design of “FRESCO” has been built on OpenFlow switch security modules. This security module merges the services and give an effective defense for complex networks. FRESCO provides an Application Programming Interface (API) to develop, access, and generate statistics of network flow.

Lee et al. [25] suggested a collaborative defense model called as “CoDef” for prevention of DDoS attack. Collaborative routing and rate control are the two underlying mechanisms of this approach. It have based on special route controller for the participation of every Application Server (AS). The AS helps us in the categorization of high priority flow, low-priority flow, and filtered flow, which played a measurable role in the prevention of DDoS attack.

Yu et al. [26] described a defense reconfiguration mitigation technique which works with multiple parallel Individual Pocketed Spring (IPS) system. This method adds new features to service reconfiguration mitigation approach and provides the maximum availability for all clients and servers. It identifies malicious traffic efficiently and decreases the number of service VMs and IPSs when it reduces malicious DDoS traffic.

Saxena et al. [2] proposed a TPA, which is called “Cloud Shield.” It used Dempster–Shafer Theory (DST) to analyze all packets for the detection of the origin of DDoS attack. It is very easy to deploy and elastic in the selection of the right place for collaboration. It also detects the case of IP spoofing.

Table  2 shows the comparative analysis of the above methods for DDoS Defense.
Table 2

Comparative analysis of different DDoS defense schemes

Techniques

Mitigation Policy

Protection at Source end

Protection at Core

Protection at Victim end

Strategy Model

Mitigation Scheme

Chu et al. [16]

Non-collaborative

No

Yes

No

Static

Rate limiting

Braga et al. [17]

Non-collaborative

No

Yes

No

Static

Filtering

Choi et al. [18]

Non-collaborative

No

Yes

No

Static

Rate limiting

Lua et al. [19]

Non-collaborative

No

No

Yes

Network reconfiguration

filtering

Yao et al. [21]

Non-collaborative

Yes

No

No

Static

Filtering

Dou et al. [22]

Non-collaborative

No

No

Yes

Static

Filtering

Shin et al. [23]

Non-collaborative

No

Yes

Yes

Defense reconfiguration

filtering

Zarger et al. [24]

Collaborative

Yes

Yes

No

Cooperative firewalls

Rate limiting

Lee et al. [25]

Collaborative

Yes

No

No

Push-back

Rate limiting

Yu et al. [26]

Non-collaborative

No

No

No

Hybrid reconfiguration

filtering

Saxena et al. [2]

Collaborative

Yes

No

Yes

Cooperative firewalls

Rate limiting

To address the limitations of previous approaches, we extend the work of Saxena et al. [2] and try to provide more efficient and scalable solution for DDoS defense. The primary objectives of this extension are the following:
  1. 1.

    To find the correct place for the systematic orchestration and collaboration to establish DDoS defense.

     
  2. 2.

    To find an effective DDoS defense mechanism that will adjust in case of severity and variation in DDoS attacks automatically.

     
  3. 3.

    To find the origin source of the attack for blocking, even in the case of IP spoofing.

     
  4. 4.

    To conduct security and performance analysis for valid proof of reliability and fault tolerance of the approach.

     
Fig. 2

Cloud Warrior: our approach for packet traceback

3 Proposed scheme

In this section, we describe our “Cloud Warrior (CW)” mechanism for successful detection and prevention of DDoS attack. It is a packet traceback approach based on TPA which provides an interface between cloud users and CSP. Many attackers may flood the network with various malicious packets that may collapse the whole structure of the systems. Figure 2 shows the model representation of Cloud Warrior.

3.1 Cloud Warrior

The CW is an independent, active and trustworthy entity that filters malicious traffic from legitimate traffic and identifies the actual source of DDoS with an accurate prediction model. CW contains various essential components that stimulate the private cloud architecture. The components of CW architecture are shown in Figure 3 and describe as follows:
  • Internet

    To initiate the cloud service, the cloud users use Internet for provisioning the resources from the CSPs.

  • Front-end Server

    The front-end server deployed a cloud fusion unit (CFU), which we have configured with the help of Cloudera CDH 5.3.0-0 [13]. This server has two Ethernet connections eth0 and eth1. eth0 was connected to a public switch, which provides CSP services to the front end server. eth1 was connected to a private switch for deployment of a virtual private cloud.

  • Virtual Private Cloud

    CW is a private cloud of four nodes (or VMs) connected to the front end server with a private switch. The Citrix Xen Server 6.2.0 [14] manages all four nodes within the “Networking Mode” because this mode perfectly delivers the advanced features of virtualization.

Fig. 3

Cloud Warrior architecture

The Weibull distribution is the essential key element for CW operations. We used Weibull distribution because it provides a variable reliability function. With this function, we can easily observe and detect DDoS attack in cloud environment.

3.2 Weibull distribution

The Weibull distribution [27] is a continuous probability distribution for the probability theory and statistics. Mathematically, this distribution is defined by the Probability Distribution Function (PDF). The PDF has widely used in data analysis. The mathematical expression of the Weibull PDF with three parameter expressions is as follows:
$$\begin{aligned} F(T)= \frac{\beta }{ \eta } .\left( \frac{T-\gamma }{\eta }\right) ^{\beta -1}. e^{-(\frac{T-\gamma }{\eta }})^{\beta } \end{aligned}$$
(1)
where F(T) \(\ge \) 0 , T \(\ge \) 0 or \(\gamma \), \(\beta \) > 0 , \(\eta \) 0 , \(- \infty< \eta < \infty \) , and
  • \(\beta \) is the shape parameter, also known as the Weibull slope.

  • \(\eta \) is the scale parameter.

  • \(\gamma \) is the location parameter.

The Weibull reliability function is given by
$$\begin{aligned} R(T)= e^{-(\frac{T-\gamma }{\eta }})^{\beta } \end{aligned}$$
(2)
The Weibull failure rate function is given by
$$\begin{aligned} \lambda (T)= \frac{F(T) }{ R(T)}= \frac{\beta }{ \eta } .\left( \frac{T-\gamma }{\eta }\right) ^{\beta -1} \end{aligned}$$
(3)
The Weibull mean life or mean time to failure (MTTF) is given by
$$\begin{aligned} \overline{T}=\gamma + \eta . \tau \left( \frac{1}{\beta }+1\right) \end{aligned}$$
(4)
where \(\tau \) (*) is the Gamma function. The Gamma function is defined as
$$\begin{aligned} \tau (n) = \int _{0}^{\infty } e^{-x}. x^{n-1} \mathrm{d}x \end{aligned}$$
(5)
The equation for the median life, or \(\beta _{50}\) life, for the Weibull distribution is given by
$$\begin{aligned} \widetilde{T}=\gamma +\eta (ln2)^{\frac{1}{\beta }} \end{aligned}$$
(6)
Fig. 4

Bathtub curve of failure rate

We design the implementation architecture for the security and reliability with the help of “Bathtub curve. ” We observe that when Weibull distribution is \(\beta \)\(\prec \) 1, failure rate decreases with time. It called as early life failures with respect to time. When \(\beta \) close to 1 or equal to 1, Weibull distribution has a relatively constant failure time. It indicates useful life with random failure. When Weibull distribution is \(\beta \)\(\succ \) 1, failure rate increases with time. It also called as Wear out failure. If we comprise all three conditions, then it forms “Bathtub Curve” [29], which is shown in Fig. 4.

The operations of Cloud Warrior have described as follows:
  1. 1.

    Observation For the remark, four virtual nodes have used that are equipped with Snort IDS tools and configured with Weibull distribution. These nodes generate the attack alerts and packet floods. The front end server converts alerts and packet floods into the basic probability assessments (BPAs) which are stored in the NoSQL database. This conversion is described in Algorithm  1:

     
  1. 2.

    Detection To detect the DDoS attack, we analyze the Transmission Control Protocol (TCP), Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP) packets with the help of three-valued logic {True, False, (True, False)}. This three-valued logic bifurcates the TCP-flood, UDP-flood and ICMP-flood attacks. We observed Weibull Failure Rate function, Weibull MTTF and Median life of the affected server for the successful actual source detection of the DDoS attack. Attack assessment is the part of front end server and it occupies the CFU. It fuses the three-valued logic and combined results of VMs for observing the impact of DDoS flood attack. These results are described in Table 3:

     
Table 3

Three-valued logic result for four virtual nodes

 

\(v_{1}\)

\(v_{2}\)

\(v_{3}\)

\(v_{4}\)

\(v_{1}\)

\(\vee \)

T

F

(TF)

\(v_{2}\)

T

T

T

T

\(v_{3}\)

F

T

F

(TF)

\(v_{4}\)

(TF)

(TF)

T

(TF)

The assessment of results maximizes the DDoS true-positive alarm rates and minimizes the false-positive alarm rate. It is possible by the time-invariant transition probabilities. If i and j are the independent and time invariant probability of occurring an event at the time n and \(n+1\), then the following equations show their values.
$$\begin{aligned} Pr \{ X_{n+1}= & {} x_{n+1}|X_{n}=x_{n} \} = Pr \{X_{2}=x_{n+1}| X_{1}=x_{n}\} \end{aligned}$$
(7)
$$\begin{aligned} Pr \{ X_{n+1}= & {} j |X_{n}= i \} = Pr \{X_{2}=j| X_{1}=i\} = P_{ij} \end{aligned}$$
(8)

4 Analysis

In this section, first, we set a test plan in our scheme. After that, we will introduce a hybrid test model of Agent Handler (AH) model [30], Internet Relay Chat (IRC) model [30] and Web-based model [30]. With this test model, we detect the prominent DDoS attack in cloud environment.

4.1 Test plan

We have designed to test our scheme with the following plan and configuration.
  1. 1.

    A website was used for testing, which is hosted on the cloud server. For this purpose, we used a commercial website “http://www.healthcont.com/,” which is hosted on Amazon AWS.

     
  2. 2.

    Backtrack tools are used to perform the attacks on this website.

     
  3. 3.

    One machine was configured as a TPA. It works as “ Cloud Warrior” private cloud that is implemented using Cloudera CDH 5.3.0-0 [13].

     
  4. 4.

    TPA collect the log of servers. In this log, we analyze and monitor the packet traffic for various services. There are lots of TCP and UDP ports available for different cloud services. We choose TCP port no. 445, 6886, 16888, 11740, 23791,23830, 23980, and 23981 because we found the huge amount of traffic on these ports. Similarly, we also analyze the UDP packet traffic on UDP port no. 53, 1863, 13347, 20284, 20339, 23981, 31327, 40971, and 42847.

     
  5. 5.

    We also include the comparison based on different performance and security parameters for proposed technique with other methods.

     

4.2 Test model

Our test model is based on the hybrid test model of AH, IRC, and web-based model, which observes the botnet and darknet domain of IP addresses in cloud environment. A bot is a software application that executes and runs the automated tasks over the internet. Bots perform tasks faster from the human being in both ways simple and structurally repetitive. A botnet is composed of a group of Bots, which are the programs operating in an automated way, also commonly refer to the hosts that are compromised by any means of malware.

Darknet is a set area of unused IP addresses. In Dark-net, no application service (i.e. web and email service) is worked promptly. Thus, the user cannot be able to transfer packets to the darknet except some misconfiguration packets. If the discovery methods are based on round robin or random schedule, then few of the packets are transferred toward the darknet. It is possible in scan attack that attacker transmits packets to the vulnerable system. We consider that each packet transmits to the darknet that is an illegal packet. So, the darknet is effective criteria to explore the changing attack.

Observation Period: At the current time, we use /24 darknet traffic. So, the number of addresses is 256. Our observation to this network area is from \(1^{st}\) November 2016 to \(30^{th}\) November 2016.

Our observation on date \(30^{th}\) November 2016 is described in Table  4.
Table 4

The number of arrival packets on date \(30^{th}\) November 2016

Time

Number of arrival packets

13:45:03–13:50:57

69

13:50:58–13:55:59

49

13:56:00–14:01:23

87

14:01:24–14:05:30

127

14:05:31–14:10:30

161

14:10:31–14:15:30

47

14:15:31–14:20:30

120

14:20:31–14:25:30

173

14:25:31–14:30:30

165

14:30:31–14:35:30

67

14:35:31–14:40:30

79

14:40:31–14:45:30

61

Fig. 5

Test model

All the details of the test model support the description given in Fig. 5. Although this process is different from the traditional approaches described in Table  1, it works more efficiently in cloud environment.
  1. 1.

    With the help of the observation of botnet and darknet, an attacker initiates any DDoS flood attack and generates service unavailability on the site of CSP.

     
  2. 2.

    Due to this reason, cloud users are unable to get services.

     
  3. 3.

    After service unavailability, cloud users forward all packets’ log details to CW, who is a trusted TPA for packet traceback.

     
  4. 4.

    It detects the reason and source of attack also in the case of DNS and IP spoofing. We efficiently used DNS cache probing for this purpose. It is a well-known fact that most of the network services are used DNS names for identification of their servers. So, DNS resolution is one of the pre-requisite steps for connection of server to any client.

    In DNS cache probing, for each request of DNS name of interest, we examine at regular intervals the cache(s) of the DNS resolver(s) for the network(s) of interest and the observed cache hits. For each cache probe, a cooperative resolver will report a hit if it is in its cache or missed otherwise. A cache hit is successful if at least one client made a request for that entry; otherwise, it is flushed out. We can efficiently estimate the probes that reveal the sequence of start and end times in the resolver servers. At this time, a direct result sends the combined queries from all clients to the resolver server.

    With a time to live (TTL) entry, for a DNS entry \(S \), we estimate the aggregate rate \(\gamma \) as follows: we probe the cache resolver at the rate of one probe per TTL. For this, we capture the sequence of start and end times in the resolver cache and for probe p, cache probe time is \(T_\mathrm{{p}}\), resolver return time \(T_\mathrm{{l}}\) until the cached entry is expired. Thus, for a TTL, most recent start time (refresh time) \(T_{r}\) can be calculated using the following Eq. 9:
    $$\begin{aligned} T_\mathrm{{r}} = T_\mathrm{{p}} - (\mathrm{{TTL}} - T_\mathrm{{l}}) \end{aligned}$$
    (9)
     
  5. 5.

    In last, CW notifies exact details of the attack to the CSP.

     
Fig. 6

Trellis diagram

Trellis diagram [28] define the session time of virtual nodes, which ordered in vertical slices. At an instance, each node is connected to at least one node at an earlier time and at least one node at a later time. The trellis diagram is shown in Figure  6 to identify the path and actual source of DDoS attack with the help of detection process.

The estimation of average rate \(\gamma \), for a sufficient refresh events R and consecutive refresh times \(T_{r_{1}}, T_{r_{2}}, \ldots , T_{r_{R}}\), and the time between consecutive refresh events of the entry \(S \) as observed from the output process \(\varDelta T_{r}\) (\( \varDelta T_{r_{i}} = T_{r_{i}}-T_{r_{i-1}}\) ) were calculated as
$$\begin{aligned} \gamma \approx \frac{R}{ \sum _{i=1}^{R} \varDelta T_{r} } \end{aligned}$$
(10)
Table 5

Experimental configuration

Number of samples (R)

100

Actual number of clients

100

Confidence

95%

Acceptable estimation error (e)

20%

Table 6

Experimental results

Result parameters

http://www.healthcont.com/

TTL

1200 s

Cache probing rate

1 query every 20 min

Acceptable estimation error (e)

20%

Actual number of clients (n)

4

Estimated number of clients (\(\hat{n}\))

13

Estimated mean aggregate rate (\(\gamma \))

18

Client mean query rate (\(\gamma _{c}\))

0.43 query per hour

We perform our experiment with system] setting given in Table  5. If we choose Gamma distribution, then an aggregate mean rate of \(\gamma = n \cdot \gamma _{c}\). Thus, the number of expected clients n for a given \(\gamma \) by \(n = \frac{\gamma }{\gamma _{c}}\). Table  6 describes the experimental results with the above setting.

4.3 Port analysis

We observe the packet traffic pattern on the TCP port no. 445, 6886, 16888, 11740, 23791,23830, 23980, and 23981. We also analyze the UDP packet traffic pattern on UDP port no. 53, 1863, 13347, 20284, 20339, 23981, 31327, 40971, and 42847. Since most of the services and web traffic are available through these ports, we choose these specific ports.

We provide the rate of the destination port with the detection packets in Figure 7. The top values for the both graphs have the vulnerability to attack. Thus, an attacker attempts to exploit this vulnerability and expands the infection. We consider that each packet has the certain intention to reach darknet area when it has many collaborated s-IPs and same size of packets.
Fig. 7

Rate of destination port a TCP, b UDP

Fig. 8

Traffic behavior: a before attack, b after attack

In our method, the value of threshold \(\lambda \) set manually for detection of collaborative behavior. Thus, we manually discover the collaborative behavior of attack from its packet. The number of detected behavior of the collaborative packet is 1078 on TCP and 4674 on UDP. Thus, the cut rate for used traffic data is 96.56% for TCP and 90.54% for UDP and we have succeeded in reducing many packets.

The maximum execution time for TCP is 117 [s] and UDP is 25 [s]. Similarly, average execution time is 109 [s] and UDP is 16 [s]. We analyze this traffic pattern in darknet area. We also need to take care of the scale of collaborative behavior and transmission time of packet on the group of s-IPs and number of d-IPs in the darknet.

In our method, a threshold value is maintained for assessment of the packets. With the help of the threshold value, a DDoS attack is measured for all packet captured during monitoring. A depletion threshold value measures the highest and average value of packets under the attack.

To calibrate the threshold or tolerance factor z, We calculate the probability (p) for each source (or destination) address (port) \(x_{i}\) as follows:
$$\begin{aligned}&p(x_{i})\nonumber \\&= \frac{\mathrm{{Number~of~ packets~with}}~x_{i}~\mathrm{{as ~a~source~(or~destination)~address~ (Port)}}}{\mathrm{{Total~ Number~ of~Packets}}}\nonumber \\\ \end{aligned}$$
(11)
We accumulate this probability for the total number of source (or destination)address (port) as the packet traffic behavior. We observe this packet traffic behavior before and under the traffic. Figure 8 shows the traffic behavior under this conditions.

4.4 Performance parameters

The best option to analyze the performance of any method is observing the performance parameters. We have observed many performance parameters of our approach and compare this with other methods.

1. Detection rate (\(D_\mathrm{{R}}\)or sensitivity

Detection rate or sensitivity is the measurement fraction of attack pattern that is correctly detected and selected. It is the ratio of true positives to the sum of true positives and false negatives.
$$\begin{aligned}&\mathrm{{Detection~rate}}~(D_\mathrm{{R}}) = \mathrm{{Sensitivity}} \nonumber \\&\quad = \frac{\mathrm{{True~positives}}}{\mathrm{{True~positives}} + \mathrm{{False~negatives}}} \nonumber \\&\quad = \frac{T_\mathrm{{P}}}{T_\mathrm{{P}} + F_\mathrm{{N}}}, \end{aligned}$$
(12)
where \(T_\mathrm{{P}}\) are the true positives (correctly selected) and \(F_\mathrm{{N}}\) = are the false negatives (mistakenly rejected).

2. Specificity

Specificity is the measurement fraction of attack pattern that was correctly rejected. It is the ratio of true negatives to the sum of true negatives and false positives.
$$\begin{aligned}&\mathrm{{Specificity}} = \frac{\mathrm{{True~ Negatives}}}{\mathrm{{True~Negatives}}+ \mathrm{{False~Positives}}} \nonumber \\&\quad = \frac{T_\mathrm{{N}}}{T_\mathrm{{N}} + F_\mathrm{{P}}}, \end{aligned}$$
(13)
where \(T_\mathrm{{N}}\) are the true negatives (correctly rejected) and \(F_\mathrm{{P}}\) are the false positives (mistakenly selected).

3. False alarm rate

False alarm rate is the measurement fraction of attack pattern that is mistakenly selected. It is the ratio of false positives to the sum of true negatives and false positives.
$$\begin{aligned}&\mathrm{{False~alarm~rate}} =(1-\mathrm{{Specificity}})\nonumber \\&\quad = \frac{\mathrm{{False~positives}}}{\mathrm{{True~negatives}}+ \mathrm{{False~positives}}} \nonumber \\&\quad = \frac{F_\mathrm{{P}}}{T_\mathrm{{N}} + F_\mathrm{{P}}}, \end{aligned}$$
(14)
where \(T_{N}\) are the true negatives (correctly rejected) and \(F_{P}\) are the false positives (mistakenly selected).
Table 7

Parameters assessment of our approach

Total sample

True Positives

True negatives

False positives

False negatives

Sensitivity

Specificity

False alarm rate

Accuracy

Accuracy

100

63

26

5

6

0.9130

0.8387

0.1613

0.89

89

200

123

59

9

9

0.9318

0.8676

0.1324

0.91

91

300

193

83

11

13

0.9369

0.8830

0.1170

0.92

92

400

287

93

13

7

0.9769

0.8774

0.1226

0.95

95

500

383

89

16

12

0.9696

0.8476

0.1524

0.944

94.4

600

452

118

19

11

0.9762

0.8613

0.1387

0.95

95

700

492

183

15

10

0.9801

0.9242

0.0758

0.9643

96.43

800

557

217

17

9

0.9841

0.9274

0.0727

0.9675

96.75

900

617

248

21

14

0.9778

0.9219

0.0781

0.9611

96.11

1000

713

261

10

16

0.9781

0.9631

0.0369

0.974

97.4

Fig. 9

Sensitivity comparison of our approach with other methods

Fig. 10

Specificity comparison of our approach with other methods

Fig. 11

False alarm rate comparison of our approach with other methods

Fig. 12

Accuracy comparison of our approach with other methods

4. Accuracy

Accuracy or classification Rate (\(C_\mathrm{{R}}\)) is the ratio of true classified events (\(T_\mathrm{{P}}+ T_\mathrm{{N}}\)) to the total number of actually occurred events (\(T_\mathrm{{P}}+F_\mathrm{{P}}+ T_\mathrm{{N}}+F_\mathrm{{P}}\)).
$$\begin{aligned}&\mathrm{{Accuracy}} = \mathrm{{Classification~rate}} (C_\mathrm{{R}})\nonumber \\&\quad = \frac{T_\mathrm{{P}}+ T_\mathrm{{N}}}{T_\mathrm{{P}}+F_\mathrm{{P}}+ T_\mathrm{{N}}+F_\mathrm{{P}}}, \end{aligned}$$
(15)
where \(T_\mathrm{{P}}\) are the true positives (correctly selected), \(F_\mathrm{{P}}\) are the false positives (mistakenly selected), \(T_\mathrm{{N}}\) are the true negatives (correctly rejected) and \(F_\mathrm{{N}}\) are the false negatives (mistakenly rejected).
$$\begin{aligned} \mathrm{{Accuracy}} (\mathrm{{in}}~\%) = \frac{T_\mathrm{{P}}+ T_\mathrm{{N}}}{T_\mathrm{{P}}+F_\mathrm{{P}}+ T_\mathrm{{N}}+F_\mathrm{{P}}} \times 100 \end{aligned}$$
(16)
Table  7 describes the parameter assessment of our approach. It demonstrates that when the threshold value \(\lambda \) and the number of total sample increase, then the sensitivity, specificity, and accuracy also increase. Only the false alarm rate was decreased because the number of false positives was decreased for the total number of samples and the threshold value \(\lambda \).
If we choose threshold value \(\lambda \) = 0.91, the total number of samples = 1000, and the number of users =100, then we found the following interesting results.
  1. 1.

    Detection rate (\(D_\mathrm{{R}}\)) or sensitivity: We have to compute the detection rate (\(D_\mathrm{{R}}\)) or Sensitivity for our approach and compare it with other methods (Saxena et al. [2], Zarger et al. [24], and Lee et al. [25]). The comparison is shown in Fig. 9. We found that our approach was higher (\(D_\mathrm{{R}}\)) than other methods because it has higher true positives than other methods.

     
  2. 2.

    Specificity We have to compute the specificity for our approach and compare it with other methods (Saxena et al. [2], Zarger et al. [24], and Lee et al. [25]). The comparison is shown in Figure 10. We found that our approach has higher specificity than other methods because it has higher true negatives than other methods.

     
  3. 3.

    False alarm rate We have to compute the false alarm rate for our approach and compare it with the other methods (Saxena et al. [2], Zarger et al. [24], and Lee et al. [25]). The comparison is shown in Fig. 11. We found that our approach has lower false alarm rate than other methods because it has less false positives than other methods.

     
  4. 4.

    Accuracy We have to compute the accuracy for our approach and compare it with other methods (Saxena et al. [2], Zarger et al. [24], and Lee et al. [25]). The comparison is shown in Fig. 12. We found that our approach has higher accuracy than other methods because it has higher true positives and true negatives than other methods.

     

5 Conclusions

In this paper, we have proposed a collaborative approach for DDoS detection and prevention based on TPAs. This method uses Weibull distribution for DDoS detection and prevention. Three-valued logic value of Weibull distribution makes it ideally suited for cloud storage. Easy DDoS prevention in the cloud environment is possible by Cloud Warrior. We have discussed security service model of our approach and their prevention criteria in the cloud environment. It helps to ensure security to much extent. We also addressed the issue of IP spoofing. Our approach shows tremendous improvement from state-of-the-artwork in the area of DDoS detection and prevention in the cloud environment. This technique prevents different DDoS attacks with less overhead.

Notes

Acknowledgements

The authors would like to thank the Indian Institute of Technology Indore for their financial and infrastructure support.

References

  1. 1.
    Saxena, R., Dey, S.: collaborative approach for data integrity verification in cloud computing, In: SNDS 2014, Communications in Computer and Information Science (CCIS), vol. 420, pp. 1–15. Springer, Berlin (2014)Google Scholar
  2. 2.
    Saxena, R., Dey, S.: Cloud shield: effective solution for DDoS in cloud, In: IDCS 2015, Lecture Notes in Computer Science (LNCS), vol. 9258, pp. 3–10. Springer, Berlin (2015)Google Scholar
  3. 3.
    Ruj, S., Saxena R.: Securing cloud data. In: Cloud computing with e-science applications, ISBN:978-1-4665-9115-8, pp. 41–72. CRC Press, Boca Raton (2015)Google Scholar
  4. 4.
    Saxena, R., Dey, S.: Cloud Audit: A Data Integrity Verification Approach for Cloud Computing, Procedia Computer Science, vol. 89, pp. 142–151, ISSN 1877-0509.  https://doi.org/10.1016/j.procs.2016.06.024 (2016)
  5. 5.
    Dittrich D.: The tribe flood network, distributed denial of service attack tool (1991). http://staff.washington.edu/dittrich/misc/tfn.analysis
  6. 6.
    Dietrich N.L.S., Dittrich, D.: Analyzing distributed denial of service tools: the Shaft Case. In: Proceedings 14th Systems Administration Conference (LISA 2000), Louisiana, USA, December 3–8, pp. 12 (2000)Google Scholar
  7. 7.
    Dittrich G.W.D., Dietrich, S., Long, N.: The mstream, Distributed denial of service attack tool (2000). http://staff.washington.edu/dittrich/misc/mstream.analysis.txt
  8. 8.
    Dittrich, D.: The stacheldraht, distributed denial of service attack tool (1999). http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
  9. 9.
    Hancock, B.: Trinity v3, a DDoS tool, hits the streets. Comput. Secur. 19, 574–574 (2000)Google Scholar
  10. 10.
  11. 11.
    Nazario, J.: Black Energy DDoS Bot Analysis, Arbor Networks (2007). http://atlas-public.ec2.arbor.net/docs/BlackEnergy+DDoS+Bot+Analysis.pdf
  12. 12.
    Sert, A.: DDoS and Security Reports: The Arbor Networks Security Blog (2011). http://ddos.arbornetworks.com/2012/02/ddos-tools/
  13. 13.
  14. 14.
  15. 15.
    Ranjan, S., Swaminathan, R., Uysal, M., Nucci, A., Knightly, E.: DDoS-shield: DDoS-resilient scheduling to counter application layer attacks. In: IEEE/ACM Transactions on Networking, vol. 17, no. 1, pp. 26–39.  https://doi.org/10.1109/TNET.2008.926503 (2009)
  16. 16.
    YuHunag, C., MinChi, T., YaoTing, C., YuChieh, C., YanRen, C.: A novel design for future on-demand service and security. In: 2010 IEEE 12th International Conference on Communication TechnologyGoogle Scholar
  17. 17.
    Braga, R., Mota, E., Passito, A.: Lightweight DDoS flooding attack detection using NOX/OpenFlow. In: 35th IEEE Conference on Local Computer Networks (LCN), pp. 408–415. IEEE October (2010)Google Scholar
  18. 18.
    Choi, Y.: Implementation of content-oriented networking architecture (CONA): a focus on DDoS countermeasure. In: Proceedings of European NetFPGA Developers Workshop (2010)Google Scholar
  19. 19.
    Lua, R., Yow, K.C.: Mitigating DDoS attacks with transparent and intelligent fast-flux swarm network. In: IEEE Network, vol. 25, no. 4, pp. 28–33 (2011)Google Scholar
  20. 20.
    Mirkovic, J., Reiher, P.: A taxonomy of DDoS attack and DDoS defense mechanisms. In: ACM Sigcomm Computer Communication Review, vol. 34, no. 2, pp. 39–53 (2004)Google Scholar
  21. 21.
    Yao, G., Bi, J., Xiao, P.: Source address validation solution with OpenFlow/NOX architecture. In: The 19th IEEE International Conference on Network Protocols (ICNP), pp. 7–12 (2011)Google Scholar
  22. 22.
    Dou, W., Chen, Q., Chen, J.: A confidence-based filtering method for DDoS attack defense in cloud environment. Future Gener. Comput. Syst. 29(7), 1838–1850 (2012)CrossRefGoogle Scholar
  23. 23.
    Shin, S. , Porras, P., Yegneswaran, V., Fong, M., Gu, G., Tyson, M.: FRESCO: modular composable security services for software-defined networks. In: Proceedings of the 20th Annual Network and Distributed System Security Symposium (NDSS) (2013)Google Scholar
  24. 24.
    Zargar, S.T., Joshi, J.: A collaborative approach to facilitate intrusion detection and response against DDoS attacks. In: The Sixth International Conference on Collaborative Computing: Networking, Applications and Work Sharing (CollaborateCom), p. 1–8 (2010)Google Scholar
  25. 25.
    Lee, S.B., Kang, M.S., Gligor, V.D.: CoDef: collaborative defense against large-scale link-flooding attacks, In: Proceedings of the Ninth ACM Conference on Emerging Networking Experiments and Technologies. pp. 417–28 (2013)Google Scholar
  26. 26.
    Yu, S., Tian, Y., Guo, S., Wu, D.: Can we beat DDoS attacks in clouds? IEEE Trans. Parallel Distrib. Syst. 25(9), 2245–2254 (2014)CrossRefGoogle Scholar
  27. 27.
    Lai, C.D., Xie, M., Murthy, D.N.P.: A modified Weibull distribution. IEEE Trans. Reliab. 52(1), 33–37 (2003)CrossRefGoogle Scholar
  28. 28.
  29. 29.
  30. 30.
    Specht S.M., Lee, R.B.: Distributed denial of service: taxonomies of attacks, tools, and countermeasures. In: ISCA PDCS, September, pp. 543–550 (2004)Google Scholar

Copyright information

© Springer Nature Switzerland AG 2019

Authors and Affiliations

  1. 1.Cloud Computing Lab, Department of Computer Science and EngineeringIndian Institute of Technology IndoreIndoreIndia

Personalised recommendations